On Wed, Sep 05, 2007 at 11:51:04AM -0700, Digant C Kasundra wrote: > --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: > >>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?
Nope. There is a good reason to have the CA's $ssldir in /var, and no good reason to have everyone else's $ssldir in /etc, so why not go for consistency? > 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. To answer your question below, yes, I do think that SSH host keys are in the wrong place, but it's a very long-standing precedent in that instance, and given the pain and suffering we've seen here, I'm not about to suggest a similar amount of confusion but on every single Debian machine out there. I should have made the change for Puppet a long time ago (I was considering doing it before even the Puppet RPMs made the move, and that was in June of last year). > 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. So, what's the frequency of change that's necessary for a file to qualify for /var? Once a week? Once a month? Once a year? I'm fairly certain I'd have files in /var that haven't changed since I installed this machine here two years ago; conversely, I change /etc/hosts probably weekly. Should I take those never-modified files from /var and put them in /etc or /usr, and move my /etc/hosts into /var because it changes frequently? My point? The rate of change of a file is an irrelevant consideration for /var. > >>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. I give you explicit permission to report a stunningly high-severity bug if an upgrade of Puppet wipes out a custom puppet.conf. That should *really* never happen. > >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. > > 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. There's an argument *against* putting them in /etc though: "because they're not configuration files". As per FHS 2.3, "The /etc hierarchy contains configuration files. A "configuration file" is a local file used to control the operation of a program". An SSL certificate no more controls the operation of Puppet than a JPG controls the operation of an image viewer. In contrast, "/var contains variable data files.". A certificate sounds a lot like a data file to me. > I also cannot find any other package that currently does that. If the precedent is that strong, perhaps it should be codified by policy. Though I'd be willing to wager that the thinking on SSL certs is that, since admins fiddle with them, they're de-facto config files. Since admins don't, in the general perfect-world case, fiddle with Puppet certificates (except through puppetca) the same exemption cannot be made in this case. - Matt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
