[chef] Fwd: Bootstrap cookbooks (chef::server) and SSL certs

[Daniel DeLeo <dan@kallistec.com>]

Oops, forgot to add chef to the recipients...

---------- Forwarded message ----------
From: Daniel DeLeo <dan@kallistec.com>
Date: Mon, Jul 13, 2009 at 4:00 PM
Subject: Re: [chef] Bootstrap cookbooks (chef::server) and SSL certs
To: Adam Jacob <adam@opscode.com>


I chatted about it a bit on IRC, but I didn't get a firm answer to these particular questions. I figured out on my own that putting the notifies :restart in with the SSL certs task won't do the trick. 

The way I see it there's two approaches that could be taken here.

1) The folks on IRC mentioned that not including the SSL cert details in the chef.json file makes chef use hostname -f or similar. I also got a tip that I can use Chef's rake tasks to generate certs. So, the minimum work solution would be to just update the documentation on the walkthroughs to reflect this.

2) Fix it in the recipe. This entails (a) moving the cert task to before the apache tasks; (b) make OpenSSL an explicit package before the cert task, because you can't depend on it being installed as dependency of mod_ssl if mod_ssl is installed after the certs are generated; and (c) do some basic sanity checking on the cert parameters with a regexp and either fail or warn if they don't look right.

I guess I'm looking for a community consensus on which option would be best. I'm partial to the second option because:

* Bootstrapping is the "hello world" of Chef, so extra care should be taken to help the user. "Wow, Chef's so awesome it installs itself" is the way to build momentum for chef.

* The error messages you get if your cert is wrong are cryptic and don't give much hint that you screwed up the chef.json file.

* One of the promises of chef is being able to run it over and over until it converges, but this is impossible if the recipe creates a deadlock. Having to do ad-hoc fixes is contrary to the "chef way."

The fix is pretty easy, so I'd be more than happy to do it. Thoughts?

Thanks,

Dan DeLeo

On Mon, Jul 13, 2009 at 3:06 PM, Adam Jacob <adam@opscode.com> wrote:

Dan, did you ever get an answer to this?

Adam

On Thu, Jul 9, 2009 at 12:13 PM, Daniel DeLeo<dan@kallistec.com> wrote:
> Hi all,
> It seems that I'm incapable of correctly writing my SSL request parmeters in
> the chef.json file, this time trying on CentOS 5.3. Having made this mistake
> before (on one of the last 0.6.x releases), I tried to solve it the same
> way, by deleting the certificates in /etc/chef/certificates/*. The way the
> bootstrapping recipe works now, however, will try to start apache _before_
> it generates the certs.  This is rather tricky to fix without blowing away
> the entire apache and passenger installs.
> To reproduce on a freshly bootstrapped Chef Server:
> 1. Move your cert.pem file somewhere where apache won't find it, e.g.,
> mv chef-server.example.com.pem chef-server.example.com.pem.hidden
> 2. Stop apache with kill, apachectl, etc/init.d, service, or whatever. This
> is the state you would be in if you fat fingered your ssl details in
> chef.json and ran chef-solo to bootstrap.
> 3. Re-run chef-solo. It tries to restart apache first, apache refuses, and
> chef fails without ever (re-)generating the certificates.
> I'd like to learn something from this experience, so:
> * How does chef pull off the delayed restarts during the bootstrap? If
> ``notifies :restart, services(:service => "apache2")'' were added to the
> "create ssl certificates" recipe, would that solve everything?
> * What would be the preferred way to handle a sanity check on the
> server_ssl_req parameter. A Regexp to catch silly errors would be pretty
> trivial, but what should the response be? Does chef have any fail()
> equivalent? Is anyone using chef in such a way that the generated certs are
> irrelevant?
> Thanks,
> Daniel DeLeo

--
Opscode, Inc.
Adam Jacob, CTO
T: (206) 508-7449 E: adam@opscode.com