The Puppet Labs Issue Tracker has Moved: https://tickets.puppetlabs.com
https://tickets.puppetlabs.com. See the following page for information on filing tickets with JIRA:
Repair default init script path on Arch Linux
|Affected Puppet version:||Branch:|
Ticket tracking is now hosted in JIRA: https://tickets.puppetlabs.com
Arch Linux uses a BSD style init, and the init scripts are located in /etc/rc.d rather than /etc/init.d This means that when running an Arch puppetmaster, a stanza setting the default service path var to /etc/rc.d is required in the site.pp
It would be nice if on Arch systems the default service path var was automatically set to /etc/rc.d
#3 Updated by Thomas Hatch about 5 years ago
Ahh, the scripts should be executed like a normal bash script, aka:
so really, it is just the directory that is different. In my deployments the service type runs just fine on the init service provider with only the path changed.
Also, I have not been able to think of a way to reliably automate the enable var in Arch, so keep that disabled (the startup daemons are managed in a bash array, so there is no predefined init script startup order – https://wiki.archlinux.org/index.php/Rc.conf#Daemons ). Once I figure something out that I think would be viable I will post a feature request.
Sorry about posting this under facter, I really need to file these bugs before 11 pm :)
#5 Updated by Thomas Hatch about 5 years ago
No, there are not, the rc script component that starts all of the services is a for loop with 2 if statements that iterates over the DAEMONS array in the rc.conf. So editing the /etc/rc.conf and adding in the service name is the same as chkconfig httpd on.
So I probably should not have compared it to a BSD runlevel process, it only follows it in philosophy.
So it would be viable if we appended the service names to the end of the DAEMONS array in the rc.conf with the ordering based on the require statements in the services, but I don’t know how viable that would be within the puppet code.
So the problem is that Arch does not set up the start up ordering of the services for you, it makes the user to do it.
#11 Updated by James Turnbull about 5 years ago
- Status changed from Needs More Information to Needs Decision
- Assignee changed from Thomas Hatch to Nigel Kersten
Okay so this is how this will have to be done:
enabled? Parse rc.conf for DAEMONS, turn value into an array and return true/false enable – add service to array and update rc.conf DAEMONS line and write/close file disable – parse rc.conf for DAEMONS, turn value into an array and delete entry for service and write/close file
That’s really damn ugly.
#13 Updated by Thomas Hatch about 5 years ago
After discussing this in the Arch mailing list and with many of the Arch Linux developers off list, this is my conclusion on how to implement this, please let me know what you think.
And after talking to some of the Arch developers it seems that while systemd is going to most likely be moved into community at some point, that there are no immediate plans to move it into the default setup.
This sounds like the normal Arch Linux approach, keep the core clean and small, yet support as much as possible.
I think that it would be foolish to set up puppet to require a systemd configured setup, since it is clear that even if Arch does move to systemd, Arch will still load daemons via the DAEMONS array in the rc.conf.
Therefore I think that what I am going to recommend to puppet labs and help implement, is that the services which are enabled by puppet be appended to the end of the DAEMONS array, and that they should always be after any services which are explicitly required by other puppet configs.
This way we can maintain a system which is compatible with the base install of Arch without adding deps, and we don’t require any changes to the runlevel. This approach should also continue to facilitate the capability of an Arch system admin to explicitly define the order in which daemons are started via puppet require statements.
I am also going to request that puppet allow another feature, that a service can be slated as “start in background” which would not start the service in the background when puppet itself starts the service, but would only add the @ symbol in front of the daemon name in the DAEMONS array.
#22 Updated by Jacob Helwig over 4 years ago
- Status changed from In Topic Branch Pending Review to Merged - Pending Release
- Target version set to 2.7.8
I cherry-picked Koen’s commits into a new topic branch based on 2.7.x, and merged them into 2.7.x in commit:809ea0af9df5624a2d20c4a0402813707760b2af. This addresses a typo, and fixes the default path to RC scripts on Archlinux.
When/if you have time to start thinking about or working on enabling/disabling services on Archlinux, could you include puppet-dev on the email thread? It’d be good to know what we can do to help, even if it’s just giving advice or pointers into the Puppet codebase.