[Freedombox-discuss] Chef and Puppet experts?

FreedomBox-Discuss.NeoPhyte_Rep at OrdinaryAmerican.net FreedomBox-Discuss.NeoPhyte_Rep at OrdinaryAmerican.net
Thu Sep 15 11:47:04 UTC 2011

On Thu, Sep 15, 2011 at 12:41 AM, Philip Hands - phil at hands.com wrote:
> On Wed, 14 Sep 2011 11:07:49 -0700, FreedomBox-Discuss.NeoPhyte_Rep at OrdinaryAmerican.net wrote:
> ...
>> > Using any of Puppet/Chef/cfengine to achieve the same effect is
>> > effectively just an attempt to side-step the edict against one package
>> > modifying the conffiles of another (which would be another way of doing
>> > this) -- while that edict is sometimes inconvenient, it's there for good
>> > reason so one should be very cautious before ignoring it.
>> I'm sorry, but I'm new around here. ("here" being the Debian project.)
>>  Can you point us to that edict?
> [note: not all configuration files are tagged as conffiles -- conffiles
> are a special case where the package manager has been told that it's in
> charge of ensuring that the files not be damaged during upgrades:
>  http://www.debian.org/doc/debian-policy/ch-files.html#s-config-files ]
> Section 3, paragraph 3, of this:
>  http://release.debian.org/squeeze/rc_policy.txt
>        Packages must not modify other packages' configuration files
>        except by an agreed upon APIs (eg, a /usr/sbin/update-foo command).
> rc_policy.txt is the list of things that would have justified a release
> critical bug in the latest stable release -- I failed to find it in the
> general policy docs, but note that the same thing is also mentioned here:
>    http://www.debian.org/doc/packaging-manuals/upgrading-checklist.txt
>          * updated section about `Configuration files': packages may not
>          touch other packages' configuration files
> in 1997.  Perhaps it's so fundamental that it doesn't need to be written
> down in policy -- I suppose it's just a special case of the fact that
> packages shouldn't tread on other package's files.
>> I'm eager to learn the Debian way, but it's quite difficult to find
>> where to start studying what some folks seem to believe is common
>> knowledge.
> Yes, I was a little surprised to find out that that wasn't spelled out
> explicitly in the policy (unless I'm just being a bit dim).
>> I can understand it might have something to do with security and how
>> best to implement reliable code.  Am I on the right track?
> It's more to do with the reliability -- it's very difficult for the user
> to work out why they ended up in a particular state if you have one
> package editing another's conffiles, since the final state is likely to
> depend upon the order that packages were installed/removed.  The
> resulting confusion is bad for the user, and thus bad for our bug
> tracking system.
> Of course, this is only for packages in Debian itself -- people often
> achieve the same effect as having puppet or whatever by having a
> site-local repository of packages that depend on loads of packages and
> have postinst scripts that tweak all sorts of stuff, flouting policy
> completely -- that's fine, but those packages are not something that
> would get uploaded to Debian.
> People have even made packages to make building such packages easier:
>  http://debathena.mit.edu/config-packages/
> This might be of interest too:
>  http://wiki.debian.org/ConfigPackages
> Cheers, Phil.

OK, Good.  I've definitely got some reading to do.

Uh, about that other issue I keep trying to raise:

Preseeding seems to work for configuring an initial installation and
reconfiguring after a reasonable attempt to upgrade automagically, but
what is/are the tool(s) for monitoring the stability of the system and
for working the recovery from an identified attack?  Does Debian
implement a Trusted Computing Base (TCB) or something similar?  (I
understand the TCB to be a checksum type approach on verifying the
stability of a core set of operating system files.)

More information about the Freedombox-discuss mailing list