[Freedombox-discuss] Chef and Puppet experts?
José Manuel Canelas
jcanelas at gmail.com
Tue Sep 20 00:04:37 UTC 2011
On 09/15/2011 06:44 PM, Jonas Smedegaard wrote:
> On 11-09-15 at 05:59pm, José Manuel Canelas wrote:
>> On 09/15/11 08:41, Philip Hands 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.
>>> Section 3, paragraph 3, of this:
>>> Packages must not modify other packages' configuration files
>>> except by an agreed upon APIs (eg, a /usr/sbin/update-foo
>>> * 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.
>> Except that this is not the case. With configuration management
>> tools (puppet, cfengine, chef, there are more), it is not the
>> package that is treading on other packages files, it is the user
>> (or sysadmin) that is changing those files. The tool only applies
>> the rules that the user tells it to.
> You are right that above are *packaging* rules.
> CFengine, Puppet, Chef, FAI, etc. are excellent helper tools for
> system administration.
> An essential goal of FreedomBox, however, is to be dead easy to use.
> Which in my experience means avoid the system administrator role!
> You may disagree with me. Others do - including the main developer
> of Skolelinux, Petter Reinholdtsen. Watch between 31:20 and 33:31
> of this:
What we talk about there is Debian bug#311188 which Petter disagrees
> with me is a violation of Debian policy, but agrees is causing
> Skolelinux to not be automatically upgradeable from one stable
> release to the next.
> I do not want to tell our users that the way to upgrade to a newer
> version of FreedomBox is to flash is!
I listened to the talk, put some thinking into it, and realized that
your point (and other people's probably) is that the policy allows for
seamless upgrades. When configuration files are changed, human
intervention will probably be needed at upgrade time, which we'd like to
avoid because that's a system administrator right there. This is a real
More information about the Freedombox-discuss