On Tue, Sep 04, 2007 at 11:41:44AM -0700, Digant C Kasundra wrote:
> --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:
> >>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.
*You* might maintain your Puppet CAs by hand, but I'm pretty confident in
stating that you're a special case. Most people use the built-in CA
(probably with autosign, I'll wager). For them, the certs are magic, like
the storeconfigs database (I can -- and have -- fiddled with that in the
past. Doesn't mean I think it should be in /etc either).
> Besides, I would argue that certs aren't variable at all, unless you are
> the puppetca.
Exactly -- so the CA server should have it's $ssldir in /var then. For
consistency, you put the $ssldir in the same place for everyone, and all's
well.
> If your puppet client is changing certs on a regular basis,
> there is something screwy going on.
Sure, but there's no shortage of data that isn't *time* varying that goes
into /var.
> 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.
I haven't dealt with Kerberos in years (and even then it wasn't a very deep
usage), so your example doesn't really mean anything to me. If the admin
configures the keytabs, then it's perfectly reasonable they're in /etc. If
they're machine generated, then I'd likely conclude they're in the wrong
place.
> >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.
Using Puppet to upgrade Puppet seems like The Right Thing. It certainly
eased the pain for us quite considerably.
> 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.
Yep, totally agree. I *did* make a mess of this, I'm quite happy to admit
it.
> 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.
That sounds reasonable, however what do I do about the stock puppet.conf?
For new installs, that config file is going to be correct in it's ssldir,
however for people upgrading, who knows? If someone just rips out their
other config files (because they haven't changed them), then suddenly
they're stuffed.
The best thing I can think of is to check that there are no other
old-package-provided config files, and only move $ssldir in that instance.
But the problem there is that Puppet never shipped a puppetca.conf (for
instance), so unless people have added config files for all puppet-related
programs, *those* programs will read puppet.conf[main] and get the new
ssldir setting, whilst puppetd and puppetmasterd will read their old files
and get the wrong setting. Confusion!
> 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.
If you can make an argument, based on Debian Policy (hence the FHS), that
the certificate data should be in /etc, I'll accept it. However, "we do
things differently to everyone else at $PLACE_OF_EMPLOYMENT" and "it doesn't
change very often" are not convincing arguments for the general case.
- Matt
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
