[Freedombox-discuss] Chef and Puppet experts?
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.)
Reply to: