[Pkg-puppet-devel] consensus on ubuntu patches?

micah anderson micah at riseup.net
Tue Feb 23 23:18:10 UTC 2010


On Tue, 23 Feb 2010 10:26:46 -0800, Nigel Kersten <nigel at explanatorygap.net> wrote:
> Are we all happy with the ubuntu patches and willing to merge them in?

Not that anyone is planning on doing this yet, but I would like to ask
that we not upload another version of the packages (at least without
priority => medium) until the current debian version has migrated to
squeeze. Right now 0.25.4-1 is in squeeze, which is unfortunate, as the
-2 fixes were somewhat important (I think that the priority should have
been medium on that last upload). The transition is supposed to happen
in approximately 3 days, if things go well.

About the ubuntu patches, here are some comments (should I send these in
response to the bugs? It seems a shame to not put them there, so the
original submitter can see them).

etckeeper
---------

 this functionality exists in puppet already with
clientbucket/filebucket, but I guess some people might want to use
etckeeper for this purpose. I admit, it is an interesting idea. There
are some potential security issues with etckeeper that people who are
using it should be aware of, but are appropriately detailed in the
etckeeper README.

I cannot think of a scenario where someone might have etckeeper
installed, but not want this to happen after every puppet run.

Do we have any idea what happens if etckeeper is installed, but
'etckeeper init' has not been run? 

What about a Suggests: etckeeper in debian/control? I didn't see that in
the patch, or any information in a README that indicates that someone
could use etckeeper with the package. The missing documentation makes me
feel like this is too much of a hidden feature, a simple one or two
lines in the README.Debian would suffice IMHO.


ship template dirs
------------------

This seems like a good change. It makes me think that we should consider
also shipping a modules directory, as the best-practice seems to be be
putting everything as possible into modules now days.

purge all puppet directories
----------------------------

Ok, this one scares me, only because it makes me worry that we would
remove someone's hard work that they've spent crafting recipes in
/etc/puppet. Is there any way we can use ucf or similar to *only* remove
the package files that the admins have not touched, instead of rm
-rf'ing the whole thing? Or at least a debconf question that requires
confirmation before nuking it (like in the mysql package's removal of
/var/lib/mysql which contains your database data). 

The /var/log puppet directory clearly needs to go.

the /var/lib/puppet directory purge is also a little scary, has anyone
tried this to see if it is the right thing to do? Remember, that
directory contains SSL certificates/keys, sometimes facter bits, and
people have used it for config-file snippet assembly. Just by looking at
this change, I cannot say for sure if it is the right thing to do, I
think we'd need to try it, and purge in a number of different scenarios
to be sure its ok, just to be safe.

micah
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/pkg-puppet-devel/attachments/20100223/ad382938/attachment.pgp>


More information about the Pkg-puppet-devel mailing list