New Cloudera installation: Hue - Bad Request (400)

[#1]

after a new cloudera installation (exactelly the same way I've already installed several times) when I try to access hue, I get the following error: Bad Request (400)

I've inserted (not helping) allowed_hosts=* in hue.ini.

In cloudera manager the hue service is shown as green.

With netstat -tunlp | grep 8888 => everything is fine:

tcp        0      0 10.132.0.2:8888         0.0.0.0:*               LISTEN      10519/python2.7

ps -ax | grep 8592
8592 ? Sl 0:09 python2.7 /opt/cloudera/parcels/CDH-5.10.0-1.cdh5.10.0.p0.41/lib/hue/build/env/bin/hue runcherrypyserver
14500 pts/0 S+ 0:00 grep --color=auto 8592

Installtion is in google cloud Ubuntu 14.04 LTS with one master (4cpu 26gb) one node (2cpu 13gb) 

Any advice would be appreciated

Best regards

Georges-Louis

[#2]

seems that nobody is reading the full topic so ill trie to summarize a bit.

tested System:  Ubuntu 14 /Debian 8 /CentOS7
Cloud env: aws ec2 and gcloud comuting (! i think here is the problem CLOUD)

Installing like install path A(POC) with clouderamanager.bin or installpath B with embedded database.

Cloudera Manager and other apps are running well and are useable!
Only the hue app is not accessable from another host. 
When i curl/wget the hue URL from the shell of the ec2 machine it is working but via clientbrowser from my notebook it didnt.

SOLUTION: 

Via ClouderaManager open the Hue Config -> advanced and search the property with "hue_safety_valve.ini" in the description text and add following lines:

[desktop]

allowed_hosts=*

save-> restart hue service -> happy hueing!

@romanir there was a typo in your solution thats why it didnt work!
@Allbeware there a two "security config parts" use the one with "hue_safety_valve.ini" in the description!


thanks for your help @ all

[#3]

@kfc

I asked my questions to clarify who was having the issue that the OP had.

After installing using the embedded DB it didn't properly run the sycndb command. The OP had the correct syntax and right location. He was not able to sync the db or access Hue. His fix was to set up a MySQL instance and use that.

It is still possible related but his issue seemed to indicate that something went wrong with the install using the embedded DB.

I am glad that you got your issue resolved.

[#4]

....removed content since it was posted prematurely.  Full post follows...

[#5]

@mbigelow,

There are two issues here:

(1)

This is seen in the error log of Hue:

ProgrammingError: column beeswax_savedquery.is_redacted does not exist
LINE 1: ...ry"."is_auto", "beeswax_savedquery"."is_trashed", "beeswax_s...

(2)

When trying to access the Hue UI, the browser sees the following error:

Bad Request (400)

The first issue cannot be the direct cause of the second.  Bad Request (400) is returned by django and django does not look at beeswax tables.  In my tests, I also saw the "column beeswax_savedquery.is_redacted does not exist" but saw no problems and noted that the "migrate" scripts worked fine.

Evidence can be observed with the following steps for a Cloudera Manager managed CDH:

# export HUE_CONF_DIR=/var/run/cloudera-scm-agent/process/`ls -lrt /var/run/cloudera-scm-agent/process/ |awk '{print $9}' |grep HUE_SERVER| tail -1`

# HUE_IGNORE_PASSWORD_SCRIPT_ERRORS=1 HUE_DATABASE_PASSWORD=<password> /opt/cloudera/parcels/CDH/lib/hue/build/env/bin/hue migrate --list

The output shows (via the stars) what migration scripts have been run successfully.  Even though I got the "column does not exist" error, my embedded Hue db shows success:

beeswax
(*) 0001_initial
(*) 0002_auto__add_field_queryhistory_notify
(*) 0003_auto__add_field_queryhistory_server_name__add_field_queryhistory_serve
(*) 0004_auto__add_session__add_field_queryhistory_server_type__add_field_query
(*) 0005_auto__add_field_queryhistory_statement_number
(*) 0006_auto__add_field_session_application
(*) 0007_auto__add_field_savedquery_is_trashed
(*) 0008_auto__add_field_queryhistory_query_type
(*) 0009_auto__add_field_savedquery_is_redacted__add_field_queryhistory_is_reda
(*) 0009_auto__chg_field_queryhistory_server_port
(*) 0010_merge_database_state
(*) 0011_auto__chg_field_savedquery_name
(*) 0012_auto__add_field_queryhistory_extra
(*) 0013_auto__add_field_session_properties
(*) 0014_auto__add_field_queryhistory_is_cleared

CONCLUSION

Unless we find evidence to the contrary, what I see is this:

(1)

Bad Request (400) is likely resolved by configuring "allowed_hosts" to allow access from the domain the browser is reporting.

(2)

The "column beeswax_savedquery.is_redacted does not exist" error is likely due to a minor coding issue that we can work to resolve.  It appears that the "sync" operation looks for the "is_redacted" column on first run before the "migrate" scripts are run to add it.  See in the following file:

/opt/cloudera/parcels/CDH/lib/hue/apps/beeswax/src/beeswax/migrations/0009_auto__add_field_savedquery_is_redacted__add_field_queryhistory_is_reda.py

def forwards(self, orm):
    # Adding field 'SavedQuery.is_redacted'
    db.add_column('beeswax_savedquery', 'is_redacted',
                 self.gf('django.db.models.fields.BooleanField')(default=False),
                 keep_default=False)

I know that was a lot of information, but I wanted to make sure that we treated the column issue and the Bad Request issue separately. 

Regards,

Ben

[#6]

@bgooley

I concur and excellent write up.

[#7]

As a quick follow-up, I opened an internal Cloudera Jira so we can review how to address that 'sync' exception.  Hue dev team will have a look.  It appears innocuous, but we'll make sure.

[#8]

Just to confirm:

Adding:

[desktop]

allowed_hosts=*

as indicated in this post solved my bad request problem.

Thank you for the solution.

[#9]

I would like to understand what security risk this change addresses.  From what I can tell, this will adversly impact any cloud deployment that is using default cloud-provided domain names (ie AWS with default VPC configuration) and it will not affect any environment (ie on-premesis) where the clients are in the same domain as Hue.  The only situation that I have been able to imagine is one where Hue is sitting on the public Internet at hue.domain with a very loose firewall (if any) but we want only clients (laptop.domain) to be served.

Can the Hue Team elaborate on how allowed_hosts=".domain" can possibly help my customers and why every AWS install I do with 5.10 will require me to revert to allowed_hosts="*"?

[#10]

@mjarnold,

I posted this somewhere else earlier and I think it will help answer your question:

Workaround to revert to pre-CDH 5.10 behavior:

• Edit Hue Service Advanced Configuration Snippet (Safety Valve) for hue_safety_valve.ini
• add allowed_hosts in the [desktop] section like so:

[desktop]
allowed_hosts=*

• Restart Hue

NOTE: The goal in changing the default to something more restrictive was to improve security. Now that we are aware of the security measure, if desired, restriction can be added via a comma-separated list of hosts and IPs like this:

[desktop]
allowed_hosts=.cloudera.com,0.0.0.0,172.31.114.79

See the following on how to configure if you choose that route:

https://docs.djangoproject.com/en/1.10/ref/settings/#allowed-hosts

To round out the above explanation, before CDH 5.10, "allowed_hosts=*" was the default.  We tried changing the default to help promote security as outlined in the above Django page.

Since our change to allowed_hosts to help enhance security had unanticipated negative experiences for existing users, we are reverting the CDH default to "allowed_hosts=*".  We'll opt to document it better and also build in validation warnings in Cloudera Manager to strongly recommend not leaving "allowed_hosts=*" unless that is the desired configuration.

The security risk is described in the django documentation (see the link above).

Ben

[#11]

@bgooley,

So to clarify my assumptions and (mis)understandings:

The allowed_hosts setting is not checking the HTTP client's DNS domain.  It is the Hue webserver framework (ie Django) checking the HTTP Host: header that the client sends.

In my case of AWS VPC with default public subnet configuration, my web browser thinks I am talking to ec2-54-50-32-4.compute-1.amazonaws.com and sends that as the Host: header.  The Hue server sees that, expecting something more like ip-10-1-2-3.ec2.internal, and replies with the "Bad Request (400)" to the client.

[#12]

Hey Ben, 

Many many thanks!! We had the same error [400] with CM 5.9 with embedded PostGRESql db. 

I confirm that this has resolved our issue. 

A gist of out setup: 

Platform: AWS, 4 x t2.medium, 50GiB EBS

OS: CentOS 6 with updates HVM

Thanks again!!

[#13]

Got the same problem on Ubuntu 14.04. CDH 5.10. 

5.9 works fine. 

So this problem should be easily reproduced. 

[#14]

Hello,

I am receiving the same error message on one of our installationas as well.

Running version:

5.10.0-1.cdh5.10.0.p0.41

[#15]

same problem here

i am getting " server not found " when i open hue web UI, and i tried to access with the external ip address:8888, i am getting "Bad Request(400) ".

i have been trying to debug the error but no use

have you solved your error ? if yes can you share the solution that helps alot

Thank you

[#16]

The answer is one post above....