[arch-general] Arch Linux support in puppet

[Lee Burton]

Append is okay (most likely dependencies are already in place for a
service), but it would be nice to specify dependencies / ensure
necessary services are running.  We should allow the module writer /
administrator to specify these dependencies so they can specify custom
depends/etc.  The logic should allow one to specify logical "or"
statements (say wicd vs network manager vs netcfg vs network) and
should try to place the puppet configured service after all of its
dependencies adding them to the line if possible (OR statements may
make this hard... perhaps a default to add if one isn't present?) or
producing some sort of error/exception.  The point should be to give
the admin full control of what happens to his / her rc.conf ;)
-Lee

On Mon, Mar 14, 2011 at 12:58, Thomas S Hatch <thatch45 at gmail.com> wrote:
> On Mon, Mar 14, 2011 at 10:43 AM, C Anthony Risinger <anthony at extof.me>wrote:
>
>> On Mon, Mar 14, 2011 at 11:32 AM, C Anthony Risinger <anthony at extof.me>
>> wrote:
>> > On Mon, Mar 14, 2011 at 11:15 AM, Thomas S Hatch <thatch45 at gmail.com>
>> wrote:
>> >> I am posting this to venture an opinion, and see if anyone has any ideas
>> on
>> >> how best to handle this situation.
>> >>
>> >> I am working with the puppet developers to help improve Arch Linux
>> support
>> >> in puppet (for those of you unfamiliar with puppet, it is an amazingly
>> >> crucial component in datacenter management - http://www.puppetlabs.com
>> ).
>> >>
>> >> Puppet can automate the starting and stopping of systems services as
>> well as
>> >> managing if they are set to start on boot. In most Linux distributions
>> >> flagging a system service to start on boot is done with an application
>> like
>> >> chkconfig and the order in which the system services start up is pre
>> >> determined by the distribution.
>> >> Arch Linux uses a much simpler approach to system services, the DAEMONS
>> >> array in the rc.conf. The problem faced with an automation system in
>> this
>> >> scope is that the boot order of services is not predetermined.
>> >>
>> >> Right now the best idea we have been able to come up with is to have
>> puppet
>> >> simply append the named services to the end of the DAEMONS array in the
>> >> rc.conf, but I wanted to ask the community if anyone had any alternative
>> >> ideas on how this could be done.
>> >>
>> >> The ticket containing the discussion on the matter can be found here:
>> >> https://projects.puppetlabs.com/issues/6697
>> >
>> > i haven't had a chance to really sink time into it quite yet, but i
>> > have a moderately sized network i manage at w3rk and implementing
>> > puppet is high on my list of improvements -- am also considering using
>> > arch for hypervisor deployments due to the simplicity of spinning a
>> > custom environment.
>> >
>> > anyway ... could we just bypass rc.conf and add some additional logic
>> > to initscripts to load from a directory?  example:
>> >
>> > /et/rc.daemons/@002-ntpd -> /etc/rc.d/ntpd
>> > /et/rc.daemons/@004-sshd -> /etc/rc.d/sshd
>> >
>> > initscripts could `echo /et/rc.daemons/*` if the DAEMONS variable is
>> > missing? does that simplify things or cause more issue?
>> >
>> > the other idea i had is a little more heavyweight, but we could use
>> > the augeas tool ( http://augeas.net/ ) to perform the rc.conf update
>> > directly; i'm fairly confident either that tool or something very
>> > similar is the future of all automated config editing, at least i hope
>> > it is, because `sed` is just a bad bad solution.  i don't know puppets
>> > plans, but i wouldn't be surprised to see puppet depend on it, because
>> > it would be a good fit.
>>
>> ... oooooor we use systemd which provides things like `systemctl enable
>> foo` ...
>>
>> i have deployed it to my private servers and my various
>> laptops/netbooks/etc with great success; quite frankly, it's pretty
>> awesome, and simple to manage ... should be hitting the main repos any
>> day now (if not already?) due to recent inclusion of util-linux-2.19.
>>
>> not exactly OOTB though (yet ... bwa hahahahaha >:-)
>>
>> C Anthony
>>
>
> As for augeas, puppet will not have any problems parsing the array in the
> rc.conf file. I agree with Aaron, that adding extra components to the Arch
> runlevel would be something we should avoid.
>
> As for systemd, after working with the insides of Upstart, I am
> VERY cautious about systemd, and I am honestly a little upset about it, I
> don't like the idea that Red Hat changing the runlevel space could pressure
> us into having to use systemd, I like the Arch runlevel the way it is, and I
> think that managing service startup with something like systemd will most
> likely be a bad thing. But I have not spent as much time as I should with
> systemd to make a final conclusion there.
> But regardless, this should support the Arch style runlevel.
>
> I do think that if it is possible to determine the ordering based on the
> requires statements of other services that would be great, or maybe even to
> implicitly state the index of the service:
>
> index => 4,
>
> would set the value as the 4th thing to start.
>



-- 
Lee Burton
lburton at mrow.org
301 910 0246