--On Wednesday, September 05, 2007 8:57 AM +1000 Matthew Palmer
<[EMAIL PROTECTED]> wrote:
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.
So, for consistency, you think the vast majority of systems should use the
same path as the lone puppetca one would find in an environment. Seems
backwards, doesn't it? Wouldn't you want the packages to serve, by
default, the majority of use cases and have people running a puppetca on
the box to move the certs to /var?
Apache, openssl, ssh: they all keep certs and keys in /etc. I've never
hand generated an ssh pub/priv key for a host. But it is in /etc. I think
precedence is set for using /etc. And like I said, except in the very
minor use case of running a puppetca, puppet certs will never ever change
on a system, thus making them pretty static and not variable at all.
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.
So ssh pub/priv keys are in the wrong place? And looking at the FHS 2.3, I
can't see any mention of this needing to be hand managed. I do see that
/var/lib is supposed to be variable state information, and a puppet cert is
not a state by any stretch of the imagination.
Yep, totally agree. I *did* make a mess of this, I'm quite happy to admit
it.
Hehe. It happens.
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!
Hmm, well, I don't know what to tell you. A lot of this has to do with the
changes in paths. Maybe we can just agree to disagree. I won't be keeping
certs under /var and we've pretty much finished creating and rollout out a
puppet.conf to deal with this so as long as the package doesn't replace an
existing puppet.conf, we'll be fine.
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
I haven't talked to anyone yet that agrees with /var being the place for
any kind of certificate, including Russ Allbery, who is also a Debian
maintainer. I've provided the arguments above. This has nothing to do
with whether or not we decide to use a different form of certificate
generation or not. I can't find a single argument for placing certificates
or private keys in /var. I also cannot find any other package that
currently does that. But the decision is yours to make as far as the
package goes.
-- DK
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
