Hey Matt! Sorry for the late reply. On rare occassions, I treat my long
weekends as actual holidays and stay away from my computer entirely.
--On Saturday, September 01, 2007 10:19:35 AM +1000 Matthew Palmer
<[EMAIL PROTECTED]> wrote:
On Fri, Aug 31, 2007 at 11:39:46AM -0700, Digant C Kasundra wrote:
Our Debian systems already have certs in /etc/puppet/ssl. Installing
the latest puppet client package seems to destroy those certs and create
new ones.
It shouldn't *destroy* them. In your case, it should just perform an
unscheduled and unexpected destructive backup to an ill-specified
location... <grin>
Yeah, I forgot to edit that paragraph after we located the certs.
The above doesn't work b/c many of us are still using puppetd.conf and
Which you shouldn't be using any more...
True, but there is a chicken and egg problem of wanting to get everyone off
of 0.22.4 and onto 0.23.2 before messing with the config files.
therefore, this moves our ssl certs over to /var/lib/puppet/ssl (which is
the wrong place for certs but that is another discussion entirely)
Actually I'd say that's a conversation we need to have first, because if
/etc/puppet/ssl is the right place for Puppet CAs and certs, then the
problem can go away very easily. However, I've thought about it pretty
hard, and /etc/puppet/ssl seems like entirely the wrong place for this
data.
Puppet cert data is not admin-managed in any meaningful sense (any more
than, say, MTA mail queues) so it doesn't fit the FHS definition for
/etc. It's variable, so /var seems reasonable, but it's not state
information (so /var/state is out), it's non-recreatable (so /var/cache
is out), and it's not spool data (so /var/spool is out).
Deferring to upstream convention is a non-starter, since upstream's
default $vardir is *still* /var/puppet, so I'm not swayed by arguments
that "upstream knows best".
Well, just because puppet provides a mechanism to maintain the certs
doesn't mean they can't be managed by administrators. We will be moving
away from using puppetca and towards a centralized cert and keytab
management system to maintain such files.
Besides, I would argue that certs aren't variable at all, unless you are
the puppetca. If your puppet client is changing certs on a regular basis,
there is something screwy going on. Instead, certs are like kerberos
keytabs: you setup them up once and shouldn't have to change them very
often, based on your expiration timeframes. And kerberos keytabs are, of
course, in /etc.
The transition can be managed safely with Puppet quite easily, actually.
Our manifest fragment for it looks something like this:
package { puppet: version => '0.23.2-3' }
file { "/etc/puppet/puppet.conf": source => "puppet://..." }
file { "/etc/puppet/puppetd.conf": ensure => absent, require =>
Package[puppet] } file { "/etc/puppet/puppetca.conf": ensure => absent,
require => Package[puppet] } file { "/etc/puppet/puppetmasterd.conf":
ensure => absent, require => Package[puppet] }
True, but we want to do that after, we roll to the new version. Probably
doesn't matter, but that's just what I had planned.
(Keep in mind, since we don't use puppet.conf yet, having been on 0.22.4
until now, the package drops in the puppet.conf and then looks at it
and says "Ah, that's where you want these certs so I'll move them for
you" but when we run puppet, it sees our puppetd.conf and looks for the
certs in /etc/puppet/ssl, doesn't find them, so recreates them.
Yeah, I was a bit hesitant about doing it the way I did it because of that
very problem, but every other way of doing it seemed to suck more. I
could remove (or rename) all of the other .conf files, but that would
presumably piss people off even more (and quite rightly so!). I could
possibly have modified all of the other .conf files to set ssldir
explicitly What I'd hoped would happen (which, in retrospect, was
probably pretty dumb) was that everyone would have upgraded to 0.23.2-1
and migrated away from the now-deprecated puppetd.conf.
I could edit all of the other .conf files to add ssldir if it wasn't
already set and only make the move if all of the .conf files had ssldir
set as desired. I didn't do it that way initially because I have a
(possibly slightly irrational) fear of editing conffiles because it's not
"the Debian way", but the more I think about it, the more I'm starting to
think it might be a goer (or at least the best of a bad bunch of options).
Do you have any preference, or another suggestion?
- Matt
Assuming people were already at 0.23.2-1 was a pretty heavy assumption. If
not now, certainly in future, you'll probably find that people very often
skip a few release or five (as is usual in our case) between upgrades.
Smooth transitions are important.
I would prefer that the package not try to manage anything like certs
unless this is a fresh install. That would be my preference. Leave it up
to people who are upgrading to update their systems. But as for the cert
location, I still think /var is the wrong place. Certs are very static
(we've never changed a cert on a built system), so /etc is the right place,
in my mind.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
