Chef-server on a VM


#1

Ohai Chefs,

Why does the omnibus chef-server deb not work by default on a VM?

I’m following http://docs.opscode.com/chef/install_server_scenario_vm.html but at the end, if I hit the webserver on port 80 it redirects me to the VM’s hostname, which is obviously not accessible from outside of the VM unless I edit my hostsfile.

I’m wondering why it’s set like that by default; it seems like an anti-pattern. Also, how do I change this behaviour?

Other than that, the omnibus package is a breeze to install. Fantastic job!

  • cassiano

#2

Yea - I recently noticed the same thing when testing on a VM - I ended up
using the chef-server community cookbook and in there are series of
options you can change - including the hostname and a few hundred other
options.

On Thu, Feb 28, 2013 at 10:01 AM, Cassiano Leal cassianoleal@gmail.comwrote:

Ohai Chefs,

Why does the omnibus chef-server deb not work by default on a VM?

I’m following http://docs.opscode.com/chef/install_server_scenario_vm.htmlbut at the end, if I hit the webserver on port 80 it redirects me to the
VM’s hostname, which is obviously not accessible from outside of the VM
unless I edit my hostsfile.

I’m wondering why it’s set like that by default; it seems like an
anti-pattern. Also, how do I change this behaviour?

Other than that, the omnibus package is a breeze to install. Fantastic job!

  • cassiano

#3

Hmm… I’ll try that, then. Still, it’s a bit annoying that the guide on docs.opscode.com doesn’t work.

I was under the impression that the cookbook had not been updated to work with Chef 11, since it says:
REQUIREMENTS

Chef ~> 0.10.0, 10.0 is required.

on README.md:slight_smile:

Also, the guide on docs.opscode does not mention how to configure knife.rb (hosted chef has the option to download a pre-configured one). Not even the API URL is mentioned in the doc (used to be http://host:4000, now it’s https://host).

  • cassiano

On Thursday, February 28, 2013 at 12:06, Pete Cheslock wrote:

Yea - I recently noticed the same thing when testing on a VM - I ended up using the chef-server community cookbook and in there are series of options you can change - including the hostname and a few hundred other options.

https://github.com/opscode-cookbooks/chef-server/blob/master/attributes/default.rb#L27

On Thu, Feb 28, 2013 at 10:01 AM, Cassiano Leal <cassianoleal@gmail.com (mailto:cassianoleal@gmail.com)> wrote:

Ohai Chefs,

Why does the omnibus chef-server deb not work by default on a VM?

I’m following http://docs.opscode.com/chef/install_server_scenario_vm.html but at the end, if I hit the webserver on port 80 it redirects me to the VM’s hostname, which is obviously not accessible from outside of the VM unless I edit my hostsfile.

I’m wondering why it’s set like that by default; it seems like an anti-pattern. Also, how do I change this behaviour?

Other than that, the omnibus package is a breeze to install. Fantastic job!

  • cassiano

#4

It’s a reasonable default for most situations – the alternative is to use the IP Address, which is actively icky as well.

Adam

From: Cassiano Leal <cassianoleal@gmail.commailto:cassianoleal@gmail.com>
Reply-To: "chef@lists.opscode.commailto:chef@lists.opscode.com" <chef@lists.opscode.commailto:chef@lists.opscode.com>
Date: Thursday, February 28, 2013 7:01 AM
To: "chef@lists.opscode.commailto:chef@lists.opscode.com" <chef@lists.opscode.commailto:chef@lists.opscode.com>
Subject: [chef] chef-server on a VM

Ohai Chefs,

Why does the omnibus chef-server deb not work by default on a VM?

I’m following http://docs.opscode.com/chef/install_server_scenario_vm.html but at the end, if I hit the webserver on port 80 it redirects me to the VM’s hostname, which is obviously not accessible from outside of the VM unless I edit my hostsfile.

I’m wondering why it’s set like that by default; it seems like an anti-pattern. Also, how do I change this behaviour?

Other than that, the omnibus package is a breeze to install. Fantastic job!

  • cassiano

#5

Out of curiosity, why redirect in the first place? :slight_smile:

  • cassiano

On Thursday, February 28, 2013 at 14:06, Adam Jacob wrote:

It’s a reasonable default for most situations – the alternative is to use the IP Address, which is actively icky as well.

Adam

From: Cassiano Leal <cassianoleal@gmail.com (mailto:cassianoleal@gmail.com)>
Reply-To: "chef@lists.opscode.com (mailto:chef@lists.opscode.com)" <chef@lists.opscode.com (mailto:chef@lists.opscode.com)>
Date: Thursday, February 28, 2013 7:01 AM
To: "chef@lists.opscode.com (mailto:chef@lists.opscode.com)" <chef@lists.opscode.com (mailto:chef@lists.opscode.com)>
Subject: [chef] chef-server on a VM

Ohai Chefs,

Why does the omnibus chef-server deb not work by default on a VM?

I’m following http://docs.opscode.com/chef/install_server_scenario_vm.html but at the end, if I hit the webserver on port 80 it redirects me to the VM’s hostname, which is obviously not accessible from outside of the VM unless I edit my hostsfile.

I’m wondering why it’s set like that by default; it seems like an anti-pattern. Also, how do I change this behaviour?

Other than that, the omnibus package is a breeze to install. Fantastic job!

  • cassiano

#6

A more normal redirect pattern I have seen is to save the host name from
the request parameter and simply change the scheme from http to https…

here’s how we do it on an F5:

HTTP::redirect https://[HTTP::host][HTTP::uri]

I’m not sure off hand what the proper syntax is for nginx or apache, but it
should be straightforward

-Jesse

On Thu, Feb 28, 2013 at 12:36 PM, Cassiano Leal cassianoleal@gmail.comwrote:

Out of curiosity, why redirect in the first place? :slight_smile:

  • cassiano

On Thursday, February 28, 2013 at 14:06, Adam Jacob wrote:

It’s a reasonable default for most situations – the alternative is to
use the IP Address, which is actively icky as well.

Adam

From: Cassiano Leal cassianoleal@gmail.com
Reply-To: "chef@lists.opscode.com" chef@lists.opscode.com
Date: Thursday, February 28, 2013 7:01 AM
To: "chef@lists.opscode.com" chef@lists.opscode.com
Subject: [chef] chef-server on a VM

Ohai Chefs,

Why does the omnibus chef-server deb not work by default on a VM?

I’m following
http://docs.opscode.com/chef/install_server_scenario_vm.html but at the
end, if I hit the webserver on port 80 it redirects me to the VM’s
hostname, which is obviously not accessible from outside of the VM unless I
edit my hostsfile.

I’m wondering why it’s set like that by default; it seems like an
anti-pattern. Also, how do I change this behaviour?

Other than that, the omnibus package is a breeze to install. Fantastic
job!

  • cassiano

#7

Are you saying that the redirection only occurs if I hit http, not https? That would be helpful.

  • cassiano

On Thursday, February 28, 2013 at 15:07, Jesse Campbell wrote:

A more normal redirect pattern I have seen is to save the host name from the request parameter and simply change the scheme from http to https…

here’s how we do it on an F5:

HTTP::redirect https://[HTTP::host][HTTP::uri]

I’m not sure off hand what the proper syntax is for nginx or apache, but it should be straightforward

-Jesse

On Thu, Feb 28, 2013 at 12:36 PM, Cassiano Leal <cassianoleal@gmail.com (mailto:cassianoleal@gmail.com)> wrote:

Out of curiosity, why redirect in the first place? :slight_smile:

  • cassiano

On Thursday, February 28, 2013 at 14:06, Adam Jacob wrote:

It’s a reasonable default for most situations – the alternative is to use the IP Address, which is actively icky as well.

Adam

From: Cassiano Leal <cassianoleal@gmail.com (mailto:cassianoleal@gmail.com)>
Reply-To: "chef@lists.opscode.com (mailto:chef@lists.opscode.com)" <chef@lists.opscode.com (mailto:chef@lists.opscode.com)>
Date: Thursday, February 28, 2013 7:01 AM
To: "chef@lists.opscode.com (mailto:chef@lists.opscode.com)" <chef@lists.opscode.com (mailto:chef@lists.opscode.com)>
Subject: [chef] chef-server on a VM

Ohai Chefs,

Why does the omnibus chef-server deb not work by default on a VM?

I’m following http://docs.opscode.com/chef/install_server_scenario_vm.html but at the end, if I hit the webserver on port 80 it redirects me to the VM’s hostname, which is obviously not accessible from outside of the VM unless I edit my hostsfile.

I’m wondering why it’s set like that by default; it seems like an anti-pattern. Also, how do I change this behaviour?

Other than that, the omnibus package is a breeze to install. Fantastic job!

  • cassiano

#8

that is what happens for me, yes.

if i connect to http://chef-app01.ops.sub.domain (default port 80), it
redirects me to https://chef-app01.ops (default port 443), which doesn’t
exist… but if i connect directly to https://chef-app01.ops.sub.domain, it
works fine.

it would be great if it didn’t break on redirect, but I don’t know where
the code is to fix that…

On Thu, Feb 28, 2013 at 1:23 PM, Cassiano Leal cassianoleal@gmail.comwrote:

Are you saying that the redirection only occurs if I hit http, not https?
That would be helpful.

  • cassiano

On Thursday, February 28, 2013 at 15:07, Jesse Campbell wrote:

A more normal redirect pattern I have seen is to save the host name from
the request parameter and simply change the scheme from http to https…

here’s how we do it on an F5:

HTTP::redirect https://[HTTP::host][HTTP::uri]

I’m not sure off hand what the proper syntax is for nginx or apache, but
it should be straightforward

-Jesse

On Thu, Feb 28, 2013 at 12:36 PM, Cassiano Leal cassianoleal@gmail.comwrote:

Out of curiosity, why redirect in the first place? :slight_smile:

  • cassiano

On Thursday, February 28, 2013 at 14:06, Adam Jacob wrote:

It’s a reasonable default for most situations – the alternative is to
use the IP Address, which is actively icky as well.

Adam

From: Cassiano Leal cassianoleal@gmail.com
Reply-To: "chef@lists.opscode.com" chef@lists.opscode.com
Date: Thursday, February 28, 2013 7:01 AM
To: "chef@lists.opscode.com" chef@lists.opscode.com
Subject: [chef] chef-server on a VM

Ohai Chefs,

Why does the omnibus chef-server deb not work by default on a VM?

I’m following
http://docs.opscode.com/chef/install_server_scenario_vm.html but at the
end, if I hit the webserver on port 80 it redirects me to the VM’s
hostname, which is obviously not accessible from outside of the VM unless I
edit my hostsfile.

I’m wondering why it’s set like that by default; it seems like an
anti-pattern. Also, how do I change this behaviour?

Other than that, the omnibus package is a breeze to install. Fantastic
job!

  • cassiano

#9

You need to have a CN that matches the FQDN of your chef-server for
SSL to work properly.
-s

On Thu, Feb 28, 2013 at 1:37 PM, Jesse Campbell hikeit@gmail.com wrote:

that is what happens for me, yes.

if i connect to http://chef-app01.ops.sub.domain (default port 80), it
redirects me to https://chef-app01.ops (default port 443), which doesn’t
exist… but if i connect directly to https://chef-app01.ops.sub.domain, it
works fine.

it would be great if it didn’t break on redirect, but I don’t know where the
code is to fix that…

On Thu, Feb 28, 2013 at 1:23 PM, Cassiano Leal cassianoleal@gmail.com
wrote:

Are you saying that the redirection only occurs if I hit http, not https?
That would be helpful.

  • cassiano

On Thursday, February 28, 2013 at 15:07, Jesse Campbell wrote:

A more normal redirect pattern I have seen is to save the host name from
the request parameter and simply change the scheme from http to https…

here’s how we do it on an F5:

HTTP::redirect https://[HTTP::host][HTTP::uri]

I’m not sure off hand what the proper syntax is for nginx or apache, but
it should be straightforward

-Jesse

On Thu, Feb 28, 2013 at 12:36 PM, Cassiano Leal cassianoleal@gmail.com
wrote:

Out of curiosity, why redirect in the first place? :slight_smile:

  • cassiano

On Thursday, February 28, 2013 at 14:06, Adam Jacob wrote:

It’s a reasonable default for most situations – the alternative is to use
the IP Address, which is actively icky as well.

Adam

From: Cassiano Leal cassianoleal@gmail.com
Reply-To: "chef@lists.opscode.com" chef@lists.opscode.com
Date: Thursday, February 28, 2013 7:01 AM
To: "chef@lists.opscode.com" chef@lists.opscode.com
Subject: [chef] chef-server on a VM

Ohai Chefs,

Why does the omnibus chef-server deb not work by default on a VM?

I’m following http://docs.opscode.com/chef/install_server_scenario_vm.html
but at the end, if I hit the webserver on port 80 it redirects me to the
VM’s hostname, which is obviously not accessible from outside of the VM
unless I edit my hostsfile.

I’m wondering why it’s set like that by default; it seems like an
anti-pattern. Also, how do I change this behaviour?

Other than that, the omnibus package is a breeze to install. Fantastic
job!

  • cassiano

#10

I’m trying to run a chef-server on a vagrant VM for local development. Not very worried about SSL working properly as long as I can use it. :slight_smile:

Still, apart from receiving a warning of a name mismatch, what else will break in that case?

  • cassiano

On Thursday, February 28, 2013 at 15:52, Sean OMeara wrote:

You need to have a CN that matches the FQDN of your chef-server for
SSL to work properly.
-s

On Thu, Feb 28, 2013 at 1:37 PM, Jesse Campbell <hikeit@gmail.com (mailto:hikeit@gmail.com)> wrote:

that is what happens for me, yes.

if i connect to http://chef-app01.ops.sub.domain (default port 80), it
redirects me to https://chef-app01.ops (default port 443), which doesn’t
exist… but if i connect directly to https://chef-app01.ops.sub.domain, it
works fine.

it would be great if it didn’t break on redirect, but I don’t know where the
code is to fix that…

On Thu, Feb 28, 2013 at 1:23 PM, Cassiano Leal <cassianoleal@gmail.com (mailto:cassianoleal@gmail.com)>
wrote:

Are you saying that the redirection only occurs if I hit http, not https?
That would be helpful.

  • cassiano

On Thursday, February 28, 2013 at 15:07, Jesse Campbell wrote:

A more normal redirect pattern I have seen is to save the host name from
the request parameter and simply change the scheme from http to https…

here’s how we do it on an F5:

HTTP::redirect https://[HTTP::host][HTTP::uri]

I’m not sure off hand what the proper syntax is for nginx or apache, but
it should be straightforward

-Jesse

On Thu, Feb 28, 2013 at 12:36 PM, Cassiano Leal <cassianoleal@gmail.com (mailto:cassianoleal@gmail.com)>
wrote:

Out of curiosity, why redirect in the first place? :slight_smile:

  • cassiano

On Thursday, February 28, 2013 at 14:06, Adam Jacob wrote:

It’s a reasonable default for most situations – the alternative is to use
the IP Address, which is actively icky as well.

Adam

From: Cassiano Leal <cassianoleal@gmail.com (mailto:cassianoleal@gmail.com)>
Reply-To: "chef@lists.opscode.com (mailto:chef@lists.opscode.com)" <chef@lists.opscode.com (mailto:chef@lists.opscode.com)>
Date: Thursday, February 28, 2013 7:01 AM
To: "chef@lists.opscode.com (mailto:chef@lists.opscode.com)" <chef@lists.opscode.com (mailto:chef@lists.opscode.com)>
Subject: [chef] chef-server on a VM

Ohai Chefs,

Why does the omnibus chef-server deb not work by default on a VM?

I’m following http://docs.opscode.com/chef/install_server_scenario_vm.html
but at the end, if I hit the webserver on port 80 it redirects me to the
VM’s hostname, which is obviously not accessible from outside of the VM
unless I edit my hostsfile.

I’m wondering why it’s set like that by default; it seems like an
anti-pattern. Also, how do I change this behaviour?

Other than that, the omnibus package is a breeze to install. Fantastic
job!

  • cassiano

#11

I have it working on mine… you’ll need to

I have mine set to 10.9.8.1

a) set up the local /etc/hosts
b) hack your bento defs to stick the same line in your /etc/hosts
(ks.cfg for centos, etc)
c) set up local software mirrors for full effect
d) reap the awesome.

misc notes -

  • list clients
    knife client list -k admin.pem -u admin -s https://localhost

  • add a client
    b vagrant ssh -c ‘sudo bash -c "export EDITOR=which cat ; knife
    client create developer-laptop -a -k /etc/chef-server/admin.pem -u
    admin -s https://localhost -f /etc/chef-server/developer-laptop.pem"
    2>&1>/dev/null’

  • delete client
    b vagrant ssh -c ‘sudo bash -c “export EDITOR=which cat ; knife
    client delete -y developer-laptop -k /etc/chef-server/admin.pem -u
    admin -s https://localhost” 2>&1>/dev/null’

  • get client.pem
    b vagrant ssh -c ‘sudo cat /etc/chef-server/developer-laptop.pem’ >
    /opt/chef/dev.lap/.chef/developer-laptop.pem

  • get validator
    b vagrant ssh -c ‘sudo cat /etc/chef-server/chef-validator.pem’ >
    /opt/chef/dev.lap/.chef/chef-validator.pem

enjoy!

-s

On Thu, Feb 28, 2013 at 1:59 PM, Cassiano Leal cassianoleal@gmail.com wrote:

I’m trying to run a chef-server on a vagrant VM for local development. Not
very worried about SSL working properly as long as I can use it. :slight_smile:

Still, apart from receiving a warning of a name mismatch, what else will
break in that case?

  • cassiano

On Thursday, February 28, 2013 at 15:52, Sean OMeara wrote:

You need to have a CN that matches the FQDN of your chef-server for
SSL to work properly.
-s

On Thu, Feb 28, 2013 at 1:37 PM, Jesse Campbell hikeit@gmail.com wrote:

that is what happens for me, yes.

if i connect to http://chef-app01.ops.sub.domain (default port 80), it
redirects me to https://chef-app01.ops (default port 443), which doesn’t
exist… but if i connect directly to https://chef-app01.ops.sub.domain, it
works fine.

it would be great if it didn’t break on redirect, but I don’t know where the
code is to fix that…

On Thu, Feb 28, 2013 at 1:23 PM, Cassiano Leal cassianoleal@gmail.com
wrote:

Are you saying that the redirection only occurs if I hit http, not https?
That would be helpful.

  • cassiano

On Thursday, February 28, 2013 at 15:07, Jesse Campbell wrote:

A more normal redirect pattern I have seen is to save the host name from
the request parameter and simply change the scheme from http to https…

here’s how we do it on an F5:

HTTP::redirect https://[HTTP::host][HTTP::uri]

I’m not sure off hand what the proper syntax is for nginx or apache, but
it should be straightforward

-Jesse

On Thu, Feb 28, 2013 at 12:36 PM, Cassiano Leal cassianoleal@gmail.com
wrote:

Out of curiosity, why redirect in the first place? :slight_smile:

  • cassiano

On Thursday, February 28, 2013 at 14:06, Adam Jacob wrote:

It’s a reasonable default for most situations – the alternative is to use
the IP Address, which is actively icky as well.

Adam

From: Cassiano Leal cassianoleal@gmail.com
Reply-To: "chef@lists.opscode.com" chef@lists.opscode.com
Date: Thursday, February 28, 2013 7:01 AM
To: "chef@lists.opscode.com" chef@lists.opscode.com
Subject: [chef] chef-server on a VM

Ohai Chefs,

Why does the omnibus chef-server deb not work by default on a VM?

I’m following http://docs.opscode.com/chef/install_server_scenario_vm.html
but at the end, if I hit the webserver on port 80 it redirects me to the
VM’s hostname, which is obviously not accessible from outside of the VM
unless I edit my hostsfile.

I’m wondering why it’s set like that by default; it seems like an
anti-pattern. Also, how do I change this behaviour?

Other than that, the omnibus package is a breeze to install. Fantastic
job!

  • cassiano

#12

oh, and now’s probably a good time to get an SSD
=)

On Thu, Feb 28, 2013 at 2:13 PM, Sean OMeara someara@gmail.com wrote:

I have it working on mine… you’ll need to

I have mine set to 10.9.8.1

a) set up the local /etc/hosts
b) hack your bento defs to stick the same line in your /etc/hosts
(ks.cfg for centos, etc)
c) set up local software mirrors for full effect
d) reap the awesome.

misc notes -

  • list clients
    knife client list -k admin.pem -u admin -s https://localhost

  • add a client
    b vagrant ssh -c ‘sudo bash -c "export EDITOR=which cat ; knife
    client create developer-laptop -a -k /etc/chef-server/admin.pem -u
    admin -s https://localhost -f /etc/chef-server/developer-laptop.pem"
    2>&1>/dev/null’

  • delete client
    b vagrant ssh -c ‘sudo bash -c “export EDITOR=which cat ; knife
    client delete -y developer-laptop -k /etc/chef-server/admin.pem -u
    admin -s https://localhost” 2>&1>/dev/null’

  • get client.pem
    b vagrant ssh -c ‘sudo cat /etc/chef-server/developer-laptop.pem’ >
    /opt/chef/dev.lap/.chef/developer-laptop.pem

  • get validator
    b vagrant ssh -c ‘sudo cat /etc/chef-server/chef-validator.pem’ >
    /opt/chef/dev.lap/.chef/chef-validator.pem

enjoy!

-s

On Thu, Feb 28, 2013 at 1:59 PM, Cassiano Leal cassianoleal@gmail.com wrote:

I’m trying to run a chef-server on a vagrant VM for local development. Not
very worried about SSL working properly as long as I can use it. :slight_smile:

Still, apart from receiving a warning of a name mismatch, what else will
break in that case?

  • cassiano

On Thursday, February 28, 2013 at 15:52, Sean OMeara wrote:

You need to have a CN that matches the FQDN of your chef-server for
SSL to work properly.
-s

On Thu, Feb 28, 2013 at 1:37 PM, Jesse Campbell hikeit@gmail.com wrote:

that is what happens for me, yes.

if i connect to http://chef-app01.ops.sub.domain (default port 80), it
redirects me to https://chef-app01.ops (default port 443), which doesn’t
exist… but if i connect directly to https://chef-app01.ops.sub.domain, it
works fine.

it would be great if it didn’t break on redirect, but I don’t know where the
code is to fix that…

On Thu, Feb 28, 2013 at 1:23 PM, Cassiano Leal cassianoleal@gmail.com
wrote:

Are you saying that the redirection only occurs if I hit http, not https?
That would be helpful.

  • cassiano

On Thursday, February 28, 2013 at 15:07, Jesse Campbell wrote:

A more normal redirect pattern I have seen is to save the host name from
the request parameter and simply change the scheme from http to https…

here’s how we do it on an F5:

HTTP::redirect https://[HTTP::host][HTTP::uri]

I’m not sure off hand what the proper syntax is for nginx or apache, but
it should be straightforward

-Jesse

On Thu, Feb 28, 2013 at 12:36 PM, Cassiano Leal cassianoleal@gmail.com
wrote:

Out of curiosity, why redirect in the first place? :slight_smile:

  • cassiano

On Thursday, February 28, 2013 at 14:06, Adam Jacob wrote:

It’s a reasonable default for most situations – the alternative is to use
the IP Address, which is actively icky as well.

Adam

From: Cassiano Leal cassianoleal@gmail.com
Reply-To: "chef@lists.opscode.com" chef@lists.opscode.com
Date: Thursday, February 28, 2013 7:01 AM
To: "chef@lists.opscode.com" chef@lists.opscode.com
Subject: [chef] chef-server on a VM

Ohai Chefs,

Why does the omnibus chef-server deb not work by default on a VM?

I’m following http://docs.opscode.com/chef/install_server_scenario_vm.html
but at the end, if I hit the webserver on port 80 it redirects me to the
VM’s hostname, which is obviously not accessible from outside of the VM
unless I edit my hostsfile.

I’m wondering why it’s set like that by default; it seems like an
anti-pattern. Also, how do I change this behaviour?

Other than that, the omnibus package is a breeze to install. Fantastic
job!

  • cassiano

#13

Okay…

so it seems that I spoke to soon.

on chef 11.0.4, I was able to just specify the full and complete name with
https and it worked.
not on chef 11.0.6 I can do everything except for work with cookbooks, it
appears the bookshelf redirects me regardless.

I tried changing the fqdn of the server and reconfiguring chef, but it is
still doing it. arg…

On Thu, Feb 28, 2013 at 2:16 PM, Sean OMeara someara@gmail.com wrote:

oh, and now’s probably a good time to get an SSD
=)

On Thu, Feb 28, 2013 at 2:13 PM, Sean OMeara someara@gmail.com wrote:

I have it working on mine… you’ll need to

I have mine set to 10.9.8.1

a) set up the local /etc/hosts
b) hack your bento defs to stick the same line in your /etc/hosts
(ks.cfg for centos, etc)
c) set up local software mirrors for full effect
d) reap the awesome.

misc notes -

  • list clients
    knife client list -k admin.pem -u admin -s https://localhost

  • add a client
    b vagrant ssh -c ‘sudo bash -c "export EDITOR=which cat ; knife
    client create developer-laptop -a -k /etc/chef-server/admin.pem -u
    admin -s https://localhost -f /etc/chef-server/developer-laptop.pem"
    2>&1>/dev/null’

  • delete client
    b vagrant ssh -c ‘sudo bash -c “export EDITOR=which cat ; knife
    client delete -y developer-laptop -k /etc/chef-server/admin.pem -u
    admin -s https://localhost” 2>&1>/dev/null’

  • get client.pem
    b vagrant ssh -c ‘sudo cat /etc/chef-server/developer-laptop.pem’ >
    /opt/chef/dev.lap/.chef/developer-laptop.pem

  • get validator
    b vagrant ssh -c ‘sudo cat /etc/chef-server/chef-validator.pem’ >
    /opt/chef/dev.lap/.chef/chef-validator.pem

enjoy!

-s

On Thu, Feb 28, 2013 at 1:59 PM, Cassiano Leal cassianoleal@gmail.com
wrote:

I’m trying to run a chef-server on a vagrant VM for local development.
Not

very worried about SSL working properly as long as I can use it. :slight_smile:

Still, apart from receiving a warning of a name mismatch, what else will
break in that case?

  • cassiano

On Thursday, February 28, 2013 at 15:52, Sean OMeara wrote:

You need to have a CN that matches the FQDN of your chef-server for
SSL to work properly.
-s

On Thu, Feb 28, 2013 at 1:37 PM, Jesse Campbell hikeit@gmail.com
wrote:

that is what happens for me, yes.

if i connect to http://chef-app01.ops.sub.domain (default port 80), it
redirects me to https://chef-app01.ops (default port 443), which
doesn’t

exist… but if i connect directly to https://chef-app01.ops.sub.domain,
it

works fine.

it would be great if it didn’t break on redirect, but I don’t know
where the

code is to fix that…

On Thu, Feb 28, 2013 at 1:23 PM, Cassiano Leal cassianoleal@gmail.com
wrote:

Are you saying that the redirection only occurs if I hit http, not
https?

That would be helpful.

  • cassiano

On Thursday, February 28, 2013 at 15:07, Jesse Campbell wrote:

A more normal redirect pattern I have seen is to save the host name from
the request parameter and simply change the scheme from http to https…

here’s how we do it on an F5:

HTTP::redirect https://[HTTP::host][HTTP::uri]

I’m not sure off hand what the proper syntax is for nginx or apache, but
it should be straightforward

-Jesse

On Thu, Feb 28, 2013 at 12:36 PM, Cassiano Leal <cassianoleal@gmail.com

wrote:

Out of curiosity, why redirect in the first place? :slight_smile:

  • cassiano

On Thursday, February 28, 2013 at 14:06, Adam Jacob wrote:

It’s a reasonable default for most situations – the alternative is to
use

the IP Address, which is actively icky as well.

Adam

From: Cassiano Leal cassianoleal@gmail.com
Reply-To: "chef@lists.opscode.com" chef@lists.opscode.com
Date: Thursday, February 28, 2013 7:01 AM
To: "chef@lists.opscode.com" chef@lists.opscode.com
Subject: [chef] chef-server on a VM

Ohai Chefs,

Why does the omnibus chef-server deb not work by default on a VM?

I’m following
http://docs.opscode.com/chef/install_server_scenario_vm.html

but at the end, if I hit the webserver on port 80 it redirects me to the
VM’s hostname, which is obviously not accessible from outside of the VM
unless I edit my hostsfile.

I’m wondering why it’s set like that by default; it seems like an
anti-pattern. Also, how do I change this behaviour?

Other than that, the omnibus package is a breeze to install. Fantastic
job!

  • cassiano

#14

Are you doing this in Vagrant?

Use fqdn.example.com as the config.vm.host_name.
That’ll cause ‘fqdn.example.com’ to be set as the hostname in the
kernel like god intended.

-s

On Thu, Feb 28, 2013 at 4:02 PM, Jesse Campbell hikeit@gmail.com wrote:

Okay…

so it seems that I spoke to soon.

on chef 11.0.4, I was able to just specify the full and complete name with
https and it worked.
not on chef 11.0.6 I can do everything except for work with cookbooks, it
appears the bookshelf redirects me regardless.

I tried changing the fqdn of the server and reconfiguring chef, but it is
still doing it. arg…

On Thu, Feb 28, 2013 at 2:16 PM, Sean OMeara someara@gmail.com wrote:

oh, and now’s probably a good time to get an SSD
=)

On Thu, Feb 28, 2013 at 2:13 PM, Sean OMeara someara@gmail.com wrote:

I have it working on mine… you’ll need to

I have mine set to 10.9.8.1

a) set up the local /etc/hosts
b) hack your bento defs to stick the same line in your /etc/hosts
(ks.cfg for centos, etc)
c) set up local software mirrors for full effect
d) reap the awesome.

misc notes -

  • list clients
    knife client list -k admin.pem -u admin -s https://localhost

  • add a client
    b vagrant ssh -c ‘sudo bash -c "export EDITOR=which cat ; knife
    client create developer-laptop -a -k /etc/chef-server/admin.pem -u
    admin -s https://localhost -f /etc/chef-server/developer-laptop.pem"
    2>&1>/dev/null’

  • delete client
    b vagrant ssh -c ‘sudo bash -c “export EDITOR=which cat ; knife
    client delete -y developer-laptop -k /etc/chef-server/admin.pem -u
    admin -s https://localhost” 2>&1>/dev/null’

  • get client.pem
    b vagrant ssh -c ‘sudo cat /etc/chef-server/developer-laptop.pem’ >
    /opt/chef/dev.lap/.chef/developer-laptop.pem

  • get validator
    b vagrant ssh -c ‘sudo cat /etc/chef-server/chef-validator.pem’ >
    /opt/chef/dev.lap/.chef/chef-validator.pem

enjoy!

-s

On Thu, Feb 28, 2013 at 1:59 PM, Cassiano Leal cassianoleal@gmail.com
wrote:

I’m trying to run a chef-server on a vagrant VM for local development.
Not
very worried about SSL working properly as long as I can use it. :slight_smile:

Still, apart from receiving a warning of a name mismatch, what else
will
break in that case?

  • cassiano

On Thursday, February 28, 2013 at 15:52, Sean OMeara wrote:

You need to have a CN that matches the FQDN of your chef-server for
SSL to work properly.
-s

On Thu, Feb 28, 2013 at 1:37 PM, Jesse Campbell hikeit@gmail.com
wrote:

that is what happens for me, yes.

if i connect to http://chef-app01.ops.sub.domain (default port 80), it
redirects me to https://chef-app01.ops (default port 443), which
doesn’t
exist… but if i connect directly to
https://chef-app01.ops.sub.domain, it
works fine.

it would be great if it didn’t break on redirect, but I don’t know
where the
code is to fix that…

On Thu, Feb 28, 2013 at 1:23 PM, Cassiano Leal cassianoleal@gmail.com
wrote:

Are you saying that the redirection only occurs if I hit http, not
https?
That would be helpful.

  • cassiano

On Thursday, February 28, 2013 at 15:07, Jesse Campbell wrote:

A more normal redirect pattern I have seen is to save the host name
from
the request parameter and simply change the scheme from http to
https…

here’s how we do it on an F5:

HTTP::redirect https://[HTTP::host][HTTP::uri]

I’m not sure off hand what the proper syntax is for nginx or apache,
but
it should be straightforward

-Jesse

On Thu, Feb 28, 2013 at 12:36 PM, Cassiano Leal
cassianoleal@gmail.com
wrote:

Out of curiosity, why redirect in the first place? :slight_smile:

  • cassiano

On Thursday, February 28, 2013 at 14:06, Adam Jacob wrote:

It’s a reasonable default for most situations – the alternative is to
use
the IP Address, which is actively icky as well.

Adam

From: Cassiano Leal cassianoleal@gmail.com
Reply-To: "chef@lists.opscode.com" chef@lists.opscode.com
Date: Thursday, February 28, 2013 7:01 AM
To: "chef@lists.opscode.com" chef@lists.opscode.com
Subject: [chef] chef-server on a VM

Ohai Chefs,

Why does the omnibus chef-server deb not work by default on a VM?

I’m following
http://docs.opscode.com/chef/install_server_scenario_vm.html
but at the end, if I hit the webserver on port 80 it redirects me to
the
VM’s hostname, which is obviously not accessible from outside of the VM
unless I edit my hostsfile.

I’m wondering why it’s set like that by default; it seems like an
anti-pattern. Also, how do I change this behaviour?

Other than that, the omnibus package is a breeze to install. Fantastic
job!

  • cassiano

#15

I’m just running chef server on a regular vmware virtual machine.
everything was happy on 11.0.4, just upgraded to 11.0.6 about half an hour
ago and now all my nodes are failing to pull down their cookbooks

On Thu, Feb 28, 2013 at 4:06 PM, Sean OMeara someara@gmail.com wrote:

Are you doing this in Vagrant?

Use fqdn.example.com as the config.vm.host_name.
That’ll cause ‘fqdn.example.com’ to be set as the hostname in the
kernel like god intended.

-s

On Thu, Feb 28, 2013 at 4:02 PM, Jesse Campbell hikeit@gmail.com wrote:

Okay…

so it seems that I spoke to soon.

on chef 11.0.4, I was able to just specify the full and complete name
with
https and it worked.
not on chef 11.0.6 I can do everything except for work with cookbooks, it
appears the bookshelf redirects me regardless.

I tried changing the fqdn of the server and reconfiguring chef, but it is
still doing it. arg…

On Thu, Feb 28, 2013 at 2:16 PM, Sean OMeara someara@gmail.com wrote:

oh, and now’s probably a good time to get an SSD
=)

On Thu, Feb 28, 2013 at 2:13 PM, Sean OMeara someara@gmail.com wrote:

I have it working on mine… you’ll need to

I have mine set to 10.9.8.1

a) set up the local /etc/hosts
b) hack your bento defs to stick the same line in your /etc/hosts
(ks.cfg for centos, etc)
c) set up local software mirrors for full effect
d) reap the awesome.

misc notes -

  • list clients
    knife client list -k admin.pem -u admin -s https://localhost

  • add a client
    b vagrant ssh -c ‘sudo bash -c "export EDITOR=which cat ; knife
    client create developer-laptop -a -k /etc/chef-server/admin.pem -u
    admin -s https://localhost -f /etc/chef-server/developer-laptop.pem"
    2>&1>/dev/null’

  • delete client
    b vagrant ssh -c ‘sudo bash -c “export EDITOR=which cat ; knife
    client delete -y developer-laptop -k /etc/chef-server/admin.pem -u
    admin -s https://localhost” 2>&1>/dev/null’

  • get client.pem
    b vagrant ssh -c ‘sudo cat /etc/chef-server/developer-laptop.pem’ >
    /opt/chef/dev.lap/.chef/developer-laptop.pem

  • get validator
    b vagrant ssh -c ‘sudo cat /etc/chef-server/chef-validator.pem’ >
    /opt/chef/dev.lap/.chef/chef-validator.pem

enjoy!

-s

On Thu, Feb 28, 2013 at 1:59 PM, Cassiano Leal <
cassianoleal@gmail.com>

wrote:

I’m trying to run a chef-server on a vagrant VM for local
development.

Not
very worried about SSL working properly as long as I can use it. :slight_smile:

Still, apart from receiving a warning of a name mismatch, what else
will
break in that case?

  • cassiano

On Thursday, February 28, 2013 at 15:52, Sean OMeara wrote:

You need to have a CN that matches the FQDN of your chef-server for
SSL to work properly.
-s

On Thu, Feb 28, 2013 at 1:37 PM, Jesse Campbell hikeit@gmail.com
wrote:

that is what happens for me, yes.

if i connect to http://chef-app01.ops.sub.domain (default port 80),
it

redirects me to https://chef-app01.ops (default port 443), which
doesn’t
exist… but if i connect directly to
https://chef-app01.ops.sub.domain, it
works fine.

it would be great if it didn’t break on redirect, but I don’t know
where the
code is to fix that…

On Thu, Feb 28, 2013 at 1:23 PM, Cassiano Leal <
cassianoleal@gmail.com>

wrote:

Are you saying that the redirection only occurs if I hit http, not
https?
That would be helpful.

  • cassiano

On Thursday, February 28, 2013 at 15:07, Jesse Campbell wrote:

A more normal redirect pattern I have seen is to save the host name
from
the request parameter and simply change the scheme from http to
https…

here’s how we do it on an F5:

HTTP::redirect https://[HTTP::host][HTTP::uri]

I’m not sure off hand what the proper syntax is for nginx or apache,
but
it should be straightforward

-Jesse

On Thu, Feb 28, 2013 at 12:36 PM, Cassiano Leal
cassianoleal@gmail.com
wrote:

Out of curiosity, why redirect in the first place? :slight_smile:

  • cassiano

On Thursday, February 28, 2013 at 14:06, Adam Jacob wrote:

It’s a reasonable default for most situations – the alternative is to
use
the IP Address, which is actively icky as well.

Adam

From: Cassiano Leal cassianoleal@gmail.com
Reply-To: "chef@lists.opscode.com" chef@lists.opscode.com
Date: Thursday, February 28, 2013 7:01 AM
To: "chef@lists.opscode.com" chef@lists.opscode.com
Subject: [chef] chef-server on a VM

Ohai Chefs,

Why does the omnibus chef-server deb not work by default on a VM?

I’m following
http://docs.opscode.com/chef/install_server_scenario_vm.html
but at the end, if I hit the webserver on port 80 it redirects me to
the
VM’s hostname, which is obviously not accessible from outside of the
VM

unless I edit my hostsfile.

I’m wondering why it’s set like that by default; it seems like an
anti-pattern. Also, how do I change this behaviour?

Other than that, the omnibus package is a breeze to install.
Fantastic

job!

  • cassiano