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.
different hue.ini same error.
[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=*
and btw. /etc/hue/hue.ini is exactly the same cause it links to the same dir....
thx for the link added it exactly there via CM now.
and gues what... no change bad request 400
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.
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....
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:
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:
The following shows the configuration in Cloudera Manager:
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.