[arch-general] Arch Linux support in puppet

[Thomas S Hatch]

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.