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:
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
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.
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