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>
> The above doesn't work b/c many of us are still using puppetd.conf and
Which you shouldn't be using any more...
> 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".
To me, /var/lib/puppet/ssl seems like the best place for it. If you've got
arguments to the contrary, I'm all ears (or eyes, as the case may be).
and creates
> new certs and then basically sits there until we go in and fix it.
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] }
> (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
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
