On Mon, Mar 14, 2011 at 10:43 AM, C Anthony Risinger <anthony@extof.me>wrote:
On Mon, Mar 14, 2011 at 11:15 AM, Thomas S Hatch <thatch45@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
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
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
On Mon, Mar 14, 2011 at 11:32 AM, C Anthony Risinger <anthony@extof.me> wrote: like this 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.