Support Questions
Find answers, ask questions, and share your expertise
Announcements
Alert: Welcome to the Unified Cloudera Community. Former HCC members be sure to read and learn how to activate your account here.

New Cloudera installation: Hue - Bad Request (400)

Re: New Cloudera installation: Hue - Bad Request (400)

Explorer

as written before.

Other apps like CM or resource manager are reachable and working without any problems only hue did not.

And yes as mentioned before
Adding allow_hosts=* at /etc/hue/conf/hue.ini didnt help anything.

Re: New Cloudera installation: Hue - Bad Request (400)

New Contributor

hi Romainr, can you please escalate this ticket to cloudera devOps group ?

 

THANKS

 

Best regards

Georges-Louis

Re: New Cloudera installation: Hue - Bad Request (400)

You are probably not modifying the correct hue.ini, if you use CM, please
look at the generated hue.ini from the Hue role

Re: New Cloudera installation: Hue - Bad Request (400)

New Contributor

hi Romainr,

 

allow_hosts=* at /etc/hue/conf/hue.ini didnt help anything

Highlighted

Re: New Cloudera installation: Hue - Bad Request (400)

Explorer

different hue.ini same error.

/opt/cloudera/parcels/CDH-5.10.0-1.cdh5.10.0.p0.41/lib/hue/desktop/conf
[desktop]

  # Set this to a random string, the longer the better.
  # This is used for secure hashing in the session store.
  secret_key=

  # Execute this script to produce the Django secret key. This will be used when
  # 'secret_key' is not set.
  ## secret_key_script=

  # Webserver listens on this address and port
  http_host=0.0.0.0
  http_port=8888
  allow_host=*

 

UPDATE:
 and btw. /etc/hue/hue.ini is exactly the same cause it links to the same dir....

Re: New Cloudera installation: Hue - Bad Request (400)

*Note:* To override a value in Cloudera Manager, you need to enter verbatim
each mini section from below into the Hue Safety Valve
:
Hue Service → Configuration → Service-Wide → Advanced → Hue Service
Advanced Configuration Snippet (Safety Valve) for hue_safety_valve.ini


http://gethue.com/how-to-configure-hue-in-your-hadoop-cluster/

Re: New Cloudera installation: Hue - Bad Request (400)

Explorer

thx for the link added it exactly there via CM now.

Syntax like:
allow_host=*

 

and gues what... no change bad request 400

Re: New Cloudera installation: Hue - Bad Request (400)

Super Guru

Everyone,

 

If you are using a Cloudera Manager managed cluster, then you need to set hue.ini edits in:

 

Hue Service Advanced Configuration Snippet (Safety Valve) for hue_safety_valve.ini

 

Cloudera Manager will distribute that configuration to the process directory that is used to read in the configuration for Hue when it starts. So, if you update files directly, it should not impact the configuration for Hue.

 

I would recommend testing after making the updates to the Cloudera Manager safety valve and let us know if that helps at all ... make sure you have restarted Hue.

 

As another note, I installed a clean Ubuntu 14.04 instance and then installed 5.10.  Using the embedded DB for Hue, all sync and migrations ran well and I can log into Hue with no changes.  There must be another factor here that we are not seeing.  If the safety valve update and restart does not fix the issue, I'll try to come up with some other things we can check.

 

Ben

Re: New Cloudera installation: Hue - Bad Request (400)

New Contributor

Hello,

 

We have tried to do what you have suggested and this did not resolve our issue.

Though it should not matter - we are running Centos in AWS for our Cloudera environment. 

 

Safety valve update and restart does not fix the issue....

 

Thanks! 

Re: New Cloudera installation: Hue - Bad Request (400)

Super Guru

Everyone,

 

By default, hue will do a "socket.getfqdn()" in python and then split on the dots.  If there is more than 2 items derrived from the split, then the last two elements are joined by a dot and prepended with a dot.

 

For example, if "socket.getfqdn()" returns "myhost.example.com" the returned value is:

 

.example.com

 

This means that Hue will only be accessible to clients (browsers) that are coming from the .example.com domain.

 

This mechanism used to derive the default domain is new to CDH 5.10.  In 5.9, the default was "*".  That is why we are pretty sure that explicitly setting the following in the safety valve will resolve the 400 error:

 

[desktop]

allowed_hosts=*

 

The following shows the configuration in Cloudera Manager:

 

allowed_hosts_in_cm.png

 

Hue must be restarted after making the change.

If this is done, Hue will allow access from any host/domain.

 

I know there has been a great deal of difficulty addressing the issue, but I hope that the above gives you some background on why we were focusing on allowed_hosts.

 

Please update us with your results.  So far I have not been able to find a good way of logging what caused the 400 error, but if you are using CDH 5.10, allowed_hosts is a good first try.

 

Regards,

 

Ben

 

Don't have an account?
Coming from Hortonworks? Activate your account here