Replies: 3 comments
-
Right now I can set the system's hostname by applying a manifest with the following action:
There could be a sysrc action with a couple of functions: Sysrc action, function "set": The next two examples are functionally equivalent and would do the same thing accomplished by command.run above:
Results in: sysrc -f /etc/rc.conf hostname=s1.example.org
=> sysrc hostname=s1.example.org Two more examples, including one showing why specifying a file might be useful:
=> sysrc keymap="de.kbd" A handy "shortcut" function could be for the very common case of enabling services: Sysrc action, function "enable": Examples:
=> sysrc apache24_enable=YES
=> sysrc apache24_enable=YES apache24_flags=-DSSL Something like this could be useful for modularization: Exposing more general functions for advanced use for cases where that's really needed but also convenient alternatives for the common cases. The manual command.run function certainly does the trick, but this is not very devopsy at all. Sysrc.set is already much better, but the user has to know the expected format like foo_enable. The last one is pretty much all one could wish for in terms of service startup management. There are probably many other cases where such a thing makes sense: Provide advanced functions that can do powerful things but also simpler ones that take most of the needless work away for common tasks (and makes those less error-prone, too). |
Beta Was this translation helpful? Give feedback.
-
Hmm. What about using a similar approach like ansible does in its ansible.builtin.service module and boil it down to a common set of rules? I would provide implementations for each individual init system, which will be autodetected and then call the correct one. In the case we would like to have a more granular action, we could expose the individual init system via its own action! |
Beta Was this translation helpful? Give feedback.
-
SaltStack and Ansible both do this really well, so +1 to leaning on those |
Beta Was this translation helpful? Give feedback.
-
This is not meant to push for #13 being implemented but rather to provide some input for the discussion that mainly takes place in #75 currently. Here's a somewhat long introduction for the reason that probably not everybody is familiar with the less common init systems.
On Linux, Comtrya will certainly need a
systemd
provider for service management and probably anopenRC
one is a good idea, too, as that's the second most popular init system right now (e.g. Gentoo, Alpine Linux and more). For macOS it'slaunchd
and for the non-POSIX platform I have no idea. 😇As far as I know, all the Linux init systems, including
runit
,s6-init
(to name two more) and of course venerablesysv-init
itself, follow the System-V quirk of abusing the filesystem for system configuration (i.e. enabling services by placing symlinks somewhere). Except for GhostBSD (which has adopted OpenRC), all BSDs use therc.d
init system (Slackware Linux uses kind of a middle ground but is closer to the BSD scheme).The rc.d init system takes the classical approach from Research UNIX (the obsolete
flat rc
model) further by splitting up rc and integrating init scripts somewhat similar to those of sysv-init. What makes this init system very much different from the others is how it is controlled: No symlinks, no prefixed numbers or anything. There's a central file,/etc/rc.conf
, where the startup process is defined basically using shell variables. For system services there's e.g. the following line in/etc/defaults/rc.conf
:The respective init script,
/etc/rc.d/cron
, checks for that variable and starts the service only if it is set to YES. To change startup behavior, it's enough to override the default setting via/etc/rc.conf
:This is why service management on rc.d-based systems is split into two parts: Service startup management and service runtime management. Runtime management is done with the
service(8)
command e.g. like this:service cron stop
.Startup configuration used to be dealt with like this:
echo 'cron_enable="NO"' >> /etc/rc.conf
. This works as the last definition always wins, but changing things often would of course clutter your rc.conf. As a lot of people could not be bothered to fire up an editor, FreeBSD 9.x introduced the nicesysrc(8)
utility for that task:sysrc cron_enable=NO
would do the same thing as the above echo command if cron_enable was not yet defined in rc.conf. If it already was there, sysrc would not append another line but change the existing one. This useful command will write to rc.conf by default but can also be used to insert or change such definitions in other files.The next post will present a couple of examples of what I could imagine the service startup service management to be like. It will start with a more general function and then proceed to a more specific one which could use the former by basically parameterizing it.
Beta Was this translation helpful? Give feedback.
All reactions