The Puppet Labs Issue Tracker has Moved: https://tickets.puppetlabs.com

This issue tracker is now in read-only archive mode and automatic ticket export has been disabled. Redmine users will need to create a new JIRA account to file tickets using https://tickets.puppetlabs.com. See the following page for information on filing tickets with JIRA:

Bug #6697

Repair default init script path on Arch Linux

Added by Thomas Hatch about 5 years ago. Updated over 4 years ago.

Status:ClosedStart date:03/14/2011
Priority:NormalDue date:
Assignee:-% Done:

0%

Category:service
Target version:2.7.8
Affected Puppet version: Branch:
Keywords:

We've Moved!

Ticket tracking is now hosted in JIRA: https://tickets.puppetlabs.com


Description

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

History

#1 Updated by James Turnbull about 5 years ago

  • Project changed from Facter to Puppet

This is actually a Puppet issue not a Facter one.

#2 Updated by James Turnbull about 5 years ago

  • Category set to service
  • Status changed from Unreviewed to Needs More Information
  • Assignee set to Thomas Hatch

Does it use same/similar commands to BSD? Is it just the directory that is different?

#3 Updated by Thomas Hatch about 5 years ago

Ahh, the scripts should be executed like a normal bash script, aka:

/etc/rc.d/httpd {start|stop|restart}

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 :)

#4 Updated by James Turnbull about 5 years ago

So are there commands to enable and disable services? like chkconfig or enable-rc.d?

#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.

#6 Updated by James Turnbull about 5 years ago

That’s very similar to what we do with BSD. Let me see if I can modify that provider. Do you have an Arch box I can sign into and test?

#7 Updated by Thomas Hatch about 5 years ago

Yes I do, give me a second to set up a user on it for you and give you root.

I will email you the creds

#8 Updated by James Turnbull about 5 years ago

So unlike BSD the files are not added/removed from /etc/rc.d at all? The only enable/disable is done via the rc.conf file?

#9 Updated by Thomas Hatch about 5 years ago

Right, only the rc.conf file needs to be edited

#10 Updated by Thomas Hatch about 5 years ago

The vm is done, if anyone else from puppet labs wishes to use it I will make an account for them and give them the login creds.

#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.

#12 Updated by Thomas Hatch about 5 years ago

That is ugly, but functional, it is also the best idea I have been able to come up so far.

I think I am going to ask the Arch devs what they think, they may have a better idea, I will try to copy Nigel on the thread

#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.

#14 Updated by Nigel Kersten almost 5 years ago

Thomas, what’s the plan here? Are there some Arch devs who can step up and implement this?

#15 Updated by Thomas Hatch almost 5 years ago

I probably need to take care of this one, at least I need to figure out where to change the default service path to /etc/rc.d in Arch.

#16 Updated by Nigel Kersten almost 5 years ago

  • Assignee changed from Nigel Kersten to Thomas Hatch

#17 Updated by Koen Wilde over 4 years ago

I just issued a merge request on github, updating the default service path for the init provider to /etc/rc.d on Archlinux.

#18 Updated by James Turnbull over 4 years ago

  • Status changed from Needs Decision to In Topic Branch Pending Review

#19 Updated by James Turnbull over 4 years ago

  • Status changed from In Topic Branch Pending Review to Requires CLA to be signed
  • Assignee deleted (Thomas Hatch)

Hi Koen – you need to sign a Contributor License Agreement by clicking in the link in the top right menu. Thanks!

#20 Updated by Koen Wilde over 4 years ago

done:)

#21 Updated by James Turnbull over 4 years ago

  • Status changed from Requires CLA to be signed to In Topic Branch Pending Review

Awesome! Thanks!

#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.

Thomas,

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.

#23 Updated by Matthaus Owens over 4 years ago

  • Status changed from Merged - Pending Release to Closed

Released in 2.7.8rc1

Also available in: Atom PDF