3

I have installed chef-server on an Ubuntu 12.10 system using the official .deb package for that release. After the installation had finished I run

chef-server-ctl test

Which reported success, 0 failures.

The server - an Amazon EC2 instance - has 1 network interface, which has an internal address assigned to it. Let's say the IP address is 10.223.92.58 and hostname -f returns something like:

ip-10-223-92-58.eu-west-1.compute.internal

However, AWS EC2 allows accessing the server from the internet using 53.242.31.23 or DNS ec2-53-242-31-23.eu-west-1.compute.amazonaws.com.

In order to allow access via the Public DNS name I added the following lines to /etc/chef-server/chef-server.rb:

lb[:enable] = "false"
lb[:web_ui_fqdn] = "ec2-53-242-31-23.eu-west-1.compute.amazonaws.com"

nginx[:server_name] = "ec2-53-242-31-23.eu-west-1.compute.amazonaws.com"
nginx[:url] = "https://ec2-53-242-31-23.eu-west-1.compute.amazonaws.com"
nginx[:enable_non_ssl] = "true"

I can access the server using https://ec2-53-242-31-23.eu-west-1.compute.amazonaws.com and reach the login page. The login page will then redirect me (after successful login) to the user edit page, in order to change my password. (That's by design).

Problem:

The redirect to the user edit page will not work, as the user controller (or every other controller) will complain about a non existing session and redirect me to the login page again and again. The problem does not exist if I try to access the page from it's local DNS domain name or IP. Am I missing some configuration values?

4 Answers 4

3

I am using Chef on Azure but I believe I've discovered the correct setting for this.

@hek2mgl was very close, but his method will be overwritten everytime you reconfigure, which I don't think is practical.

In your /etc/chef-server/chef-server.rb file, add the following line:

chef_server_webui['cookie_domain'] = 'FQDN'

Where "FQDN" is your fully qualified domain name "myserver.mydomain.net", etc.

After saving this file, $ sudo chef-server-ctl reconfigure

After it completes, if you scroll up a little, under "Recipe: chef-server::default" you'll see it load your setting:

...
"session_key": "_sandbox_session",
"cookie_domain": "all",
"cookie_domain": "myserver.mydomain.net",
...

Now navigating to WebUI using myserver.mydomain.net allows you to log in.

2
  • Looks like you made it! :)
    – hek2mgl
    Jun 24, 2014 at 21:05
  • Glad I could help!
    – DonBecker
    Jun 24, 2014 at 22:08
3

I just became aware of this question, so I thought I'd chime in. I'm an engineer with Chef who has looked into this issue.

The accepted answer on this is the correct way you can get around this issue. Note that following the accepted answer will also allow you to reconfigures and keep the setting the same, since that is an issue in another one of the answers. You do not need to make all the changes that hek2mgl tried. Setting the cookie domain is enough.

Full details on my investigation can be found in our old ticketing system here: https://tickets.opscode.com/browse/CHEF-5301

This issue has also been opened in our GitHub issues here: https://github.com/opscode/chef/issues/1780

If anyone has any suggestions on how we can configure the server out of the box to avoid this, I'd appreciate it if you'd chime in on the GitHub issue, as I don't currently understand the exact cause of this issue. It appears to be a strange interaction between Rails, cookie domains, and modern browsers (this issue seems to only affect Chrome and Firefox, not Safari or IE, at the moment anyway). If you read the links I provided you can see all the details that I know.

Thanks.

2
  • 1
    Thanks for your feedback. I really appreciate this infos. Currently I'm not responsible for a chef server, that's why I unfortunately haven't something to test atm and I fear that I can't help much with fixing the problem
    – hek2mgl
    Aug 8, 2014 at 15:54
  • We've continued looking into this at Chef. This should be fixed with the 11.1.4 release of the Open Source Chef server. See the changelog here: github.com/opscode/omnibus-chef-server/blob/master/CHANGELOG.md
    – Mark Mzyk
    Aug 12, 2014 at 14:29
1

I had this same problem, and I solved it by putting the elastic IP into my /etc/hosts with a name entry that matched my server hostname and the name I was using in DNS, and ran chef-server-ctl reconfigure.

Edit: this solution then broke cookbook uploads for me, and I had to relearn the good old AWS lesson that it's the private IP you must put in /etc/hosts. After a reconfigure both problems remained solved.

1
  • Sorry for un-accept, but @DonBecker's answer looks like the more specific solution to this problem..
    – hek2mgl
    Jun 24, 2014 at 21:06
0

Finally I could solve the problem. It was related to the session settings of the chef-server-webui application.

I had to explicitly specify the session domain ec2-53-242-31-23.eu-west-1.compute.amazonaws.com in the file:

/opt/chef-server/embedded/service/chef-server-webui/config/initializers/session_store.rb

ChefServerWebui::Application.config.session_store :cookie_store, :key => '_sandbox_session', :domain => 'ec2-53-242-31-23.eu-west-1.compute.amazonaws.com'

Just using :domain => all like in the original file will not work.

Then restart chef-server to apply the settings:

chef-server-ctl restart

Note: Do not chef-server-ctl reconfigure, this will override the settings again.

2
  • Are you able to run reconfigure then in the future? Or do you have to go back and manually edit the session_store.rb file each time you reconfigure?
    – DonBecker
    Jun 19, 2014 at 18:55
  • @DonBecker No, this would override the changes. It is a time since I solved this and I had nothing more to do with it since then. I guess there are better solutions.
    – hek2mgl
    Jun 19, 2014 at 19:07

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .