Hello!
I have a question about the openid_url in chef 0.7.8: Why does it’s
default point to port 444? I had chef-server and -client version 0.7.0
already up and running, and everything was using Port 443. Version 0.7.8
can also be configured to use only 443. So, what’s the idea behind the
second port and virtual host in apache, when it has the same
configuration as the first one? What’s the benefit? I see only the
disadvantage that you need to open two ports in your firewall between
server and client, if there is one.
Regards,
Claus
Hiya!
On 22/08/2009, at 10:09 PM, Claus Divossen wrote:
Hello!
I have a question about the openid_url in chef 0.7.8: Why does it's
default point to port 444? I had chef-server and -client version 0.7.0
already up and running, and everything was using Port 443. Version
0.7.8
can also be configured to use only 443. So, what's the idea behind the
second port and virtual host in apache, when it has the same
configuration as the first one? What's the benefit? I see only the
disadvantage that you need to open two ports in your
firewall between
server and client, if there is one.
Two SSL ports are required as we can't do name-based vhosting on SSL
yet, and we identified an issue with the way OpenID works internally
with Ruby's net/http; the gist of the problem is that when the OpenID
consumer performs the redirection step your load-balancer (Apache,
Nginx, ..) will generally try and pass that connection back into
itself - the same, originating ruby application (mongrel, thin,
passenger..) - since the ruby part isn't expecting this, it blocks
indefinitely, resulting in timeouts and a 'critical mass' of about 15
concurrent authentications.
Running the OpenID URL on a separate port (the important part is the
separate load-balancer configuration) allows Apache or Nginx to
correctly pass the connections around with no indeterminate blocking,
timeouts, or upper-bounds.
I can understand the pain regarding opening an additional firewall
port; however all internal (Registrations) usage of OpenID will be
removed in 0.8.0 and replaced with an EC2-style key pair
authentication system rendering all of these problems, workarounds and
associated discussions moot 
Hope this helps,
--
AJ Christensen, Software Engineer
Opscode, Inc.
E: aj@opscode.com
Hi!
On Sat, 2009-08-22 at 22:30 +1200, Arjuna Christensen wrote:
Two SSL ports are required as we can't do name-based vhosting on SSL
yet, and we identified an issue with the way OpenID works internally
with Ruby's net/http; the gist of the problem is that when the OpenID
consumer performs the redirection step your load-balancer (Apache,
Nginx, ..) will generally try and pass that connection back into
itself - the same, originating ruby application (mongrel, thin,
passenger..) - since the ruby part isn't expecting this, it blocks
indefinitely, resulting in timeouts and a 'critical mass' of about 15
concurrent authentications.
So, this blocking occurs only with too many concurrent authentications?
This would explain why using the same port works for me, because I'm
still testing (and learning) and have only a handful of nodes running.
however all internal (Registrations) usage of OpenID will be removed
in 0.8.0 and replaced with an EC2-style key pair authentication system
rendering all of these problems, workarounds and associated
discussions moot
That's good to hear! I hope that the web interface user's login will
also get rid of Open ID. We are using Chef on an internal site, behind
firewalls with no direct internet access, and I was quite annoyed that I
had to set up an OpenID server just to log in to the admin interface.
Best Regards,
Claus
On Sat, Aug 22, 2009 at 3:54 PM, Claus
Divossenclaus.divossen@t-online.de wrote:
. We are using Chef on an internal site, behind
firewalls with no direct internet access, and I was quite annoyed that I
had to set up an OpenID server just to log in to the admin interface.
Same here, I can't wait for 0.8.0 to hit the shelves.
--
$ echo "kpfmAdpoofdufevq/dp/vl" | perl -pe 's/(.)/chr(ord($1)-1)/ge'
On Aug 22, 2009, at 5:54 PM, Claus Divossen wrote:
That's good to hear! I hope that the web interface user's login will
also get rid of Open ID. We are using Chef on an internal site, behind
firewalls with no direct internet access, and I was quite annoyed
that I
had to set up an OpenID server just to log in to the admin interface.
For what it's worth, as an alternative to setting up an OpenID
server, you can create an OpenIDRegistration (the same thing each of
your Nodes has) for use as an admin account. This may be hackish, and
may not work at 0.8.0 and beyond, but it's working fine for me in the
meantime.
http://github.com/matthewtodd/skillet/blob/
e0ec8343827ce7257e761db032f9c331dcf1fb82/config/environments/
development.rb#L15-24
I'm kind of cheating by hooking into the Merb::Bootloader. For a more
standard Chef server instance, I suppose you could run something like
this, totally off the top of my head and never-been-run, caveat lector:
#!/usr/bin/env ruby
require 'rubygems'
require 'chef'
Chef::Config.from_file('/etc/chef/server.rb')
admin_account = Chef::OpenIDRegistration.new
admin_account.name = 'admin'
admin_account.set_password 'foo'
admin_account.validated = true
admin_account.admin = true
admin_account.save
And then you can log in as <your Chef::Config[:openid_url]>/openid/
server/node/admin.
Cheers! -- Matthew
Does anyone know when 0.8.0 may be ready?
Cheers,
Joel
On Mon, Aug 24, 2009 at 1:03 PM, Joel Merrickjoel.merrick@gmail.com wrote:
Does anyone know when 0.8.0 may be ready?
We're working on it now. It's a pretty heavy re-factoring of the Chef
Server, shoring up some of the APIs that we didn't like (or just plain
punted on.) So the short answer is "when it's ready", the long answer
is we're hoping to have a candidate out in September.
We're on the hook to write a longer email with the details of all that
is going in to 0.8, as well.
Adam
--
Opscode, Inc.
Adam Jacob, CTO
T: (206) 508-7449 E: adam@opscode.com
On Mon, Aug 24, 2009 at 10:09 PM, Adam Jacobadam@opscode.com wrote:
On Mon, Aug 24, 2009 at 1:03 PM, Joel Merrickjoel.merrick@gmail.com wrote:
Does anyone know when 0.8.0 may be ready?
We're working on it now. It's a pretty heavy re-factoring of the Chef
Server, shoring up some of the APIs that we didn't like (or just plain
punted on.) So the short answer is "when it's ready", the long answer
is we're hoping to have a candidate out in September.
We're on the hook to write a longer email with the details of all that
is going in to 0.8, as well.
Adam
No worry, look forward to the release!
--
$ echo "kpfmAdpoofdufevq/dp/vl" | perl -pe 's/(.)/chr(ord($1)-1)/ge'