I have an installation of chef-server_10.18.2 (I’ve lost the original
Debian package) running on Ubuntu Precise (12.04 LTS) server.
There are Chef configuration files on the path //etc/chef/. Among
the contents of this subdirectory is the file /webui.rb/. Warm and
fuzzy.
I'm able to reach the older Chef server via it web UI using my
browser and also
$ wget 16.86.192.111:4040
Using netstat, I see that this is supposed to work (and it does as I
say):
$ netstat -lntp | grep chef
tcp 0 0 0.0.0.0:4000 0.0.0.0:* LISTEN 1046/merb :
chef-se
tcp 0 0 0.0.0.0:4040 0.0.0.0:* LISTEN 1046/merb :
chef-se
I have a fresh installation of
chef-server_11.0.8-1.ubuntu.12.04_amd64.deb on Ubuntu Precise (12.04
LTS) server. The installation went without a hitch.
There are Chef configuration files on the path //etc/chef-server/. I
sort of expected this, but the contents of this subdirectory do not
include the file /webui.rb/. Cold and prickly, but I'm totally down
with progress in whatever form.
I'm unable to reach the new installation via my browser or wget,
though ps -ef tells me it's indeed running. netstat reveals that
Chef isn't listening on any port.
The delta here appears to be the Chef versions and, of course, the
contents and placement of Chef configuration.
I’m eager to launch a browser at the new server so I can get Cheffing.
What am I missing? Am I supposed to provide /webui.rb/? How otherwise do
I tell Chef to listen on 4000/4040? The older Chef install installed it
for me (and I left it at its defaults). I could not find a Chef server
10.x download at opscode, but I don’t really want to swim against
progress anyway.
Profuse thanks for any directions anyone can give to get me running.
Best regards,
Russ
On Thursday, August 29, 2013 at 9:33 AM, Russell Bateman wrote:
I have an installation of chef-server_10.18.2 (I've lost the original Debian package) running on Ubuntu Precise (12.04 LTS) server.
There are Chef configuration files on the path /etc/chef. Among the contents of this subdirectory is the file webui.rb. Warm and fuzzy.
I'm able to reach the older Chef server via it web UI using my browser and also
$ wget 16.86.192.111:4040
Using netstat, I see that this is supposed to work (and it does as I say):
$ netstat -lntp | grep chef
tcp 0 0 0.0.0.0:4000 0.0.0.0:* LISTEN 1046/merb : chef-se
tcp 0 0 0.0.0.0:4040 0.0.0.0:* LISTEN 1046/merb : chef-se
I have a fresh installation of chef-server_11.0.8-1.ubuntu.12.04_amd64.deb on Ubuntu Precise (12.04 LTS) server. The installation went without a hitch.
There are Chef configuration files on the path /etc/chef-server. I sort of expected this, but the contents of this subdirectory do not include the file webui.rb. Cold and prickly, but I'm totally down with progress in whatever form.
I'm unable to reach the new installation via my browser or wget, though ps -ef tells me it's indeed running. netstat reveals that Chef isn't listening on any port.
You ran chef-server-ctl reconfigure and it completed without error?
--
Daniel DeLeo
On Aug 29, 2013, at 11:33 AM, Russell Bateman russ@windofkeltia.com wrote:
The delta here appears to be the Chef versions and, of course, the contents and placement of Chef configuration.
Including the default ports that the Chef server listens on. With Chef 11, it's now port 80 for http and 443 for https, and both API and WebUI calls can be handled on either port -- The 4000/4040 split no longer exists.
Also note that Chef 11 uses nginx as a front-end proxy, so I think the chef-server process itself may actually listen on 127.0.0.1, and lets nginx handle the communication with the outside world -- which might include terminating the SSL connection on behalf of chef-server.
In addition, IIRC it uses a self-signed cert, and certain libraries like spice & ridley will insist on validating the SSL cert and rejecting the connection if it is not correct -- which will cause failures on self-signed certs.
Can you tell that we've recently switched from Chef 10 to Chef 11? 
--
Brad Knowles brad@shub-internet.org
LinkedIn Profile: http://tinyurl.com/y8kpxu
(Thanks, yes I had run chef-server-ctl reconfigure which completed
without error--thanks.)
I just tried it out and It was indeed talking on ports 80 and 443, so
that's cool.
I'm actually trying to reach it through a tunnel which I can nurse along
only so far by adding back in my tunneled port number after each
redirect, but that doesn't get me past the login. Oh, well, it's
probably not conceived for that use. At least it will work when I'm down
inside the firewall, so I greatly appreciate the help from both of you!
Russ
On 8/29/2013 12:20 PM, Brad Knowles wrote:
On Aug 29, 2013, at 11:33 AM, Russell Bateman russ@windofkeltia.com wrote:
The delta here appears to be the Chef versions and, of course, the contents and placement of Chef configuration.
Including the default ports that the Chef server listens on. With Chef 11, it's now port 80 for http and 443 for https, and both API and WebUI calls can be handled on either port -- The 4000/4040 split no longer exists.
Also note that Chef 11 uses nginx as a front-end proxy, so I think the chef-server process itself may actually listen on 127.0.0.1, and lets nginx handle the communication with the outside world -- which might include terminating the SSL connection on behalf of chef-server.
In addition, IIRC it uses a self-signed cert, and certain libraries like spice & ridley will insist on validating the SSL cert and rejecting the connection if it is not correct -- which will cause failures on self-signed certs.
Can you tell that we've recently switched from Chef 10 to Chef 11?
--
Brad Knowles brad@shub-internet.org
LinkedIn Profile: http://tinyurl.com/y8kpxu
Not that there was any doubt, but at home, where I'm behind the firewall
in question, I can report that the web UI is perfectly accessible.
Thanks again!
On 08/29/2013 01:43 PM, Russell Bateman wrote:
(Thanks, yes I had run chef-server-ctl reconfigure which completed
without error--thanks.)
I just tried it out and It was indeed talking on ports 80 and 443, so
that's cool.
I'm actually trying to reach it through a tunnel which I can nurse
along only so far by adding back in my tunneled port number after each
redirect, but that doesn't get me past the login. Oh, well, it's
probably not conceived for that use. At least it will work when I'm
down inside the firewall, so I greatly appreciate the help from both
of you!
Russ
On 8/29/2013 12:20 PM, Brad Knowles wrote:
On Aug 29, 2013, at 11:33 AM, Russell Bateman russ@windofkeltia.com
wrote:
The delta here appears to be the Chef versions and, of course, the
contents and placement of Chef configuration.
Including the default ports that the Chef server listens on. With
Chef 11, it's now port 80 for http and 443 for https, and both API
and WebUI calls can be handled on either port -- The 4000/4040 split
no longer exists.
Also note that Chef 11 uses nginx as a front-end proxy, so I think
the chef-server process itself may actually listen on 127.0.0.1, and
lets nginx handle the communication with the outside world -- which
might include terminating the SSL connection on behalf of chef-server.
In addition, IIRC it uses a self-signed cert, and certain libraries
like spice & ridley will insist on validating the SSL cert and
rejecting the connection if it is not correct -- which will cause
failures on self-signed certs.
Can you tell that we've recently switched from Chef 10 to Chef 11?
--
Brad Knowles brad@shub-internet.org
LinkedIn Profile: http://tinyurl.com/y8kpxu