5
edits
Changes
From SME Server
Jump to navigationJump to search
mLine 3:
Line 3: − + + Line 25:
Line 26: − + − + Line 33:
Line 34: − + + Line 169:
Line 171: − + + Line 230:
Line 233: − + + Line 339:
Line 343: − + − + − + − + − + − + − + + Line 385:
Line 390: − + − + − + + + − + − + − + + + Line 400:
Line 409: − + − + − + + + − + + − + + − + − + + − + − + Line 428:
Line 442: − + + − + Line 440:
Line 455: − + − + Line 462:
Line 477: − − + − systemcl start myservice.service+ Line 476:
Line 490: − + Line 512:
Line 526: − + Line 518:
Line 532: − + − + − + − + + − * start − * stop − * reload − * restart − * try-restart − * reload-or-restart − * reload-or-try-restart − + − * We will have all our service unit files in /usr/lib/systemd/system/+ − * They should all be required by sme-server.target in the [Install]+ − * For as long as possible we will avoid templating .service files and/or their modification in /usr/lib/systemd/system/servicename.service.d/50koozali.conf+ + + + + + − + + + + + Line 565:
Line 582: − + + Line 573:
Line 591: − + + Line 588:
Line 607: − + + Line 601:
Line 621: − + − + − + + Line 611:
Line 632: − + Line 652:
Line 673: − + Line 659:
Line 680: − + Line 679:
Line 700: − +
expand-template /etc/systemd/system/preset/49-koozali.preset to expand-template /etc/systemd/system-preset/49-koozali.preset and systemcl to systemctl
A cli wrapper for the command service /sbin/e-smith/service has been created so that only initscripts which exist in run-level 7 can be run. This ensures that the supervised service is run, if one exists, and protects against running e.g. "service httpd restart" directly. The wrapper will also choose between an sv command for runit processes or a regular call to /etc/rc.d/init.d/ scripts.
A cli wrapper for the command service /sbin/e-smith/service has been created so that only initscripts which exist in run-level 7 can be run. This ensures that the supervised service is run, if one exists, and protects against running e.g. "service httpd restart" directly. The wrapper will also choose between an sv command for runit processes or a regular call to /etc/rc.d/init.d/ scripts.
* /sbin/e-smith/service
*/sbin/e-smith/service
<syntaxhighlight lang="bash">
<syntaxhighlight lang="bash">
#! /bin/sh
#! /bin/sh
</syntaxhighlight>
</syntaxhighlight>
=== Version 10 on: boot process and service control ===
===Version 10 on: boot process and service control===
==== Current SME10 alpha boot process and service control ====
====Current SME10 alpha boot process and service control====
Systemd is the new Linux standard to handle services and service monitoring and is enforced upstream. Systemd will supersede all /etc/rc.d/init.d/ scripts and calls to /usr/sbin/service.
Systemd is the new Linux standard to handle services and service monitoring and is enforced upstream. Systemd will supersede all /etc/rc.d/init.d/ scripts and calls to /usr/sbin/service.
From there we could continue in this way, or try to move as many processes as we can to systemd. That works, but is even more complex than it was in the previous SME versions. Additionally we can not guarantee—without further scripts—that an issued ''systemctl start httpd'' would be blocked.
From there we could continue in this way, or try to move as many processes as we can to systemd. That works, but is even more complex than it was in the previous SME versions. Additionally we can not guarantee—without further scripts—that an issued ''systemctl start httpd'' would be blocked.
* new startup with console see /usr/share/perl5/vendor_perl/esmith/console/startup.pm
*new startup with console see /usr/share/perl5/vendor_perl/esmith/console/startup.pm
<syntaxhighlight lang="perl">
<syntaxhighlight lang="perl">
package esmith::console::startup;
package esmith::console::startup;
</syntaxhighlight>
</syntaxhighlight>
* a new /sbin/e-smith/service
*a new /sbin/e-smith/service
<syntaxhighlight lang="bash" line="1">
<syntaxhighlight lang="bash" line="1">
#! /bin/sh
#! /bin/sh
</syntaxhighlight>
</syntaxhighlight>
* And the current controlService perl function from /usr/share/perl5/vendor_perl/esmith/util.pm
*And the current controlService perl function from /usr/share/perl5/vendor_perl/esmith/util.pm
<syntaxhighlight lang="perl" line="1">
<syntaxhighlight lang="perl" line="1">
=pod
=pod
</syntaxhighlight>
</syntaxhighlight>
=== Systemd Integration: Options and possibilities ===
===Systemd Integration: Options and possibilities===
This section is intended to open up a discussion concerning options and possibilities, in order to facilitate choosing the optimal SME approach to systemd.
This section is intended to open up a discussion concerning options and possibilities, in order to facilitate choosing the optimal SME approach to systemd.
Issues to solve :
Issues to solve :
* SME vs. upstream
* make unit files aware of service status in e-smith db configuration
*SME vs. upstream
* have our services boot in the right sequence
*make unit files aware of service status in e-smith db configuration
* journald vs rsyslogd
*have our services boot in the right sequence
* plain file log vs special file format
*journald vs rsyslogd
* enabling /disabling /masking services
*plain file log vs special file format
*enabling /disabling /masking services
'''Table 1. Load path when running in system mode (<code>--system</code>).''' <ref>https://www.freedesktop.org/software/systemd/man/systemd.unit.html</ref>
'''Table 1. Load path when running in system mode (<code>--system</code>).''' <ref>https://www.freedesktop.org/software/systemd/man/systemd.unit.html</ref>
|}
|}
==== Generators ====
====Generators====
There have been suggestions about using a generator, it is not clear how and why it would help. This approach would be more complex. and according to the doc<ref>https://www.freedesktop.org/software/systemd/man/systemd.generator.html#</ref>:
There have been suggestions about using a generator, it is not clear how and why it would help. This approach would be more complex. and according to the doc<ref>https://www.freedesktop.org/software/systemd/man/systemd.generator.html#</ref>:
* Units written by generators are removed when the configuration is reloaded. That means the lifetime of the generated units is closely bound to the reload cycles of '''systemd''' itself.
* Generators should only be used to generate unit files and symlinks to them, not any other kind of configuration. Due to the lifecycle logic mentioned above, generators are not a good fit to generate dynamic configuration for other services. If you need to generate dynamic configuration for other services, do so in normal services you order before the service in question.
*Units written by generators are removed when the configuration is reloaded. That means the lifetime of the generated units is closely bound to the reload cycles of '''systemd''' itself.
*Generators should only be used to generate unit files and symlinks to them, not any other kind of configuration. Due to the lifecycle logic mentioned above, generators are not a good fit to generate dynamic configuration for other services. If you need to generate dynamic configuration for other services, do so in normal services you order before the service in question.
systemctl daemon-reload has be run after each modification of a unit. Hence generated files by generators will be erased and generators rerun. <ref>https://www.freedesktop.org/software/systemd/man/systemctl.html#daemon-reload</ref>
systemctl daemon-reload has be run after each modification of a unit. Hence generated files by generators will be erased and generators rerun. <ref>https://www.freedesktop.org/software/systemd/man/systemctl.html#daemon-reload</ref>
==== Overriding the upstream vendor preset : templated unit files, or not? And where? ====
====Overriding the upstream vendor preset : templated unit files, or not? And where?====
The reference is the example of a service unit provided by the upstream vendor.
The reference is the example of a service unit provided by the upstream vendor.
* Should we simply create a template and expand it over the unit.service in /lib/systemd/system/
* Or offer a different way to override upstream vendor settings?
*Should we simply create a template and expand it over the unit.service in /lib/systemd/system/
*Or offer a different way to override upstream vendor settings?
Furthermore should we template our file to point to /lib/ or to /etc/?
Furthermore should we template our file to point to /lib/ or to /etc/?
Thus the questions arise:
Thus the questions arise:
* Where: /etc or /lib/
* What: use a template or not
*Where: /etc or /lib/
* How: overwrite, or selective overriding
*What: use a template or not
*How: overwrite, or selective overriding
Looking at the options:
Looking at the options:
==== Create unit files in /etc/systemd/system/ or in /lib/systemd/system/? ====
====Create unit files in /etc/systemd/system/ or in /lib/systemd/system/?====
:As a vendor we should work in /lib/systemd/system/, but as an admin helper we might want to play in /etc/systemd/system/ and rather offer a way for admin to use our template-custom or config db.
:As a vendor we should work in /lib/systemd/system/, but as an admin helper we might want to play in /etc/systemd/system/ and rather offer a way for admin to use our template-custom or config db.
==== Template or not? ====
====Template or not?====
:The simplest way to override a service could be to simply template the file /lib/systemd/system/servicename.service and expand it every time a reconfiguration or a boot occurs.
:The simplest way to override a service could be to simply template the file /lib/systemd/system/servicename.service and expand it every time a reconfiguration or a boot occurs.
:Going further, we could ensure the stability of the system by setting this in
:Going further, we could ensure the stability of the system by setting this in
:/etc/systemd/system/servicename.service
:/etc/systemd/system/servicename.service
===== unitname.d/file.conf versus overwrite uniname.service =====
=====unitname.d/file.conf versus overwrite uniname.service=====
:From reading and inspection of a few systems, a dot d folder could be created both in etc and lib.
:From reading and inspection of a few systems, a dot d folder could be created both in etc and lib.
:There are two methods of overriding vendor settings in unit files:
:There are two methods of overriding vendor settings in unit files:
::First, copying the unit file from <code>/usr/lib/systemd/system</code> to <code>/etc/systemd/system</code> and modifying the chosen settings.
::First, copying the unit file from <code>/usr/lib/systemd/system</code> to <code>/etc/systemd/system</code> and modifying the chosen settings.
::Second, one can create a directory named <code>''<code>unit</code>''.d/</code> within <code>/etc/systemd/system</code> and place a drop-in file there <code>''<code>name</code>''.conf</code> that only changes the specific settings one is interested in. Note that multiple such drop-in files are read if present, processed in lexicographic order of their filename.
::Second, one can create a directory named <code>''<code>unit</code>''.d/</code> within <code>/etc/systemd/system</code> and place a drop-in file there <code>''<code>name</code>''.conf</code> that only changes the specific settings one is interested in. Note that multiple such drop-in files are read if present, processed in lexicographic order of their filename.
:The advantage of the second method is that one only overrides the settings one specifically wants, where updates to the unit by the vendor automatically apply. This has the disadvantage that some future updates by the vendor might be incompatible with the local changes.<ref>https://www.freedesktop.org/software/systemd/man/systemd.unit.html</ref>
:The advantage of the second method is that one only overrides the settings one specifically wants, where updates to the unit by the vendor automatically apply. This has the disadvantage that some future updates by the vendor might be incompatible with the local changes.<ref>https://www.freedesktop.org/software/systemd/man/systemd.unit.html</ref>
===== Uninstalling/masking unwanted/conflicting services: firewalld example =====
=====Uninstalling/masking unwanted/conflicting services: firewalld example=====
:We can plan to uninstall firewalld for example, but some packages will reinstall as a requirement. It might even be started, which could conflict with masq.
:We can plan to uninstall firewalld for example, but some packages will reinstall as a requirement. It might even be started, which could conflict with masq.
=== Systemd current implementation ===
===Systemd current implementation===
Previously we had sysvinit services and supervised services under Daemontool and Runit.
Previously we had sysvinit services and supervised services under Daemontool and Runit.
The idea is to stop to have the Bootstrap Console start services.
The idea is to stop to have the Bootstrap Console start services.
==== default target: sme-server.target ====
====default target: sme-server.target====
We use our own target.
We use our own target.
==== system-preset ====
====system-preset====
The use of system presets is the basis of our method of handling the systemd services under Koozali SME Server.
The use of system presets is the basis of our method of handling the systemd services under Koozali SME Server.
</syntaxhighlight>This will ensure that on every run, all services explicitly enabled or disabled in the configuration db are declared this way in systemd, and if they are not in the db they are controlled according to what is declared in other /lib/systemd/system-preset/* files.
</syntaxhighlight>This will ensure that on every run, all services explicitly enabled or disabled in the configuration db are declared this way in systemd, and if they are not in the db they are controlled according to what is declared in other /lib/systemd/system-preset/* files.
Any services not explicitly declared there will be disabled (/lib/systemd/system-preset/99-default-disable.preset). So If you want a service to run you need to declare it at the very least with :<syntaxhighlight lang="bash">
Any services not explicitly declared there will be disabled (/lib/systemd/system-preset/99-default-disable.preset). So If you want a service to run you need to declare it at the very least with :<syntaxhighlight lang="bash">
db configuration set myservice service status enabled
db configuration set myservice service status enabled
expand-template /etc/systemd/system/preset/49-koozali.preset
expand-template /etc/systemd/system-preset/49-koozali.preset
/etc/e-smith/events/actions/systemd-default
/etc/e-smith/events/actions/systemd-default
systemctl start myservice.service
</syntaxhighlight>
</syntaxhighlight>
</syntaxhighlight>
</syntaxhighlight>
==== service-status ====
====service-status====
We run as ExecStartPre a call to a script preventing any unwanted launch of a disabled service. This is basic and just fails the service with a message at any attempt to start it. This deals with the case that it has been started manually, or has been enabled, and prevents an event from running to disable it before reboot (is this correct?)
We run as ExecStartPre a call to a script preventing any unwanted launch of a disabled service. This is basic and just fails the service with a message at any attempt to start it. This deals with the case that it has been started manually, or has been enabled, and prevents an event from running to disable it before reboot (is this correct?)
</syntaxhighlight>
</syntaxhighlight>
==== services2adjust ====
====services2adjust====
Runit and Sysvinit were allowing some signals that are not handled anymore by systemd. We will have to replace those.
Runit and Sysvinit were allowing some signals that are not handled anymore by systemd. We will have to replace those.
for the following we could use <code>kill --signal=</code>
for the following we could use <code>kill --signal=</code>
* sigusr1
* sigusr2
*sigusr1
* sigterm
*sigusr2
* sighup
*sigterm
*sighup
On the other hand, systemd offers some interesting new solutions :
On the other hand, systemd offers some interesting new solutions :
=== Service migration ===
*start
*stop
*reload
*restart
*try-restart
*reload-or-restart
*reload-or-try-restart
===Service migration===
===== Previous pure Syvinit service, with a provided systemd unit =====
*We will have all our service unit files in /usr/lib/systemd/system/
*They should all be required by sme-server.target in the [Install]
*For as long as possible we will avoid templating .service files and/or their modification in /usr/lib/systemd/system/servicename.service.d/50koozali.conf
=====Previous pure Syvinit service, with a provided systemd unit=====
If we are lucky we can simply use the ones provided as a replacement, we add a service.d/50koozali.conf for the service and alter it in the way we need.
If we are lucky we can simply use the ones provided as a replacement, we add a service.d/50koozali.conf for the service and alter it in the way we need.
Usually we then create 3 fragments
Usually we then create 3 fragments
* /etc/e-smith/templates/usr/lib/systemd/system/nut-monitor.service.d/50koozali.conf/20unit
*/etc/e-smith/templates/usr/lib/systemd/system/nut-monitor.service.d/50koozali.conf/20unit
<syntaxhighlight lang="bash">
<syntaxhighlight lang="bash">
[Unit]
[Unit]
</syntaxhighlight>
</syntaxhighlight>
* /etc/e-smith/templates/usr/lib/systemd/system/nut-monitor.service.d/50koozali.conf/40service
*/etc/e-smith/templates/usr/lib/systemd/system/nut-monitor.service.d/50koozali.conf/40service
<syntaxhighlight lang="bash">
<syntaxhighlight lang="bash">
[Service]
[Service]
ExecStart=/bin/sv u helo
ExecStart=/bin/sv u helo
</syntaxhighlight>
</syntaxhighlight>
* /etc/e-smith/templates/usr/lib/systemd/system/nut-monitor.service.d/50koozali.conf/80install
*/etc/e-smith/templates/usr/lib/systemd/system/nut-monitor.service.d/50koozali.conf/80install
<syntaxhighlight lang="bash">
<syntaxhighlight lang="bash">
[Install]
[Install]
Finally, think to remove any remains of previous sysvinit as it might prevent the service to enable in /etc/systemd/system-preset/49-koozali.preset. to enable the service all the conditions should be met:
Finally, think to remove any remains of previous sysvinit as it might prevent the service to enable in /etc/systemd/system-preset/49-koozali.preset. to enable the service all the conditions should be met:
* a key $key in configuration db should exist as type=service and status=enabled
* a file $key.service should exist in /usr/lib/systemd/system/ or in /etc/systemd/system/
*a key $key in configuration db should exist as type=service and status=enabled
* there should be no file /etc/rc.d/init.d/$key nor /etc/rc.d/init.d/supervise/$key
*a file $key.service should exist in /usr/lib/systemd/system/ or in /etc/systemd/system/
*there should be no file /etc/rc.d/init.d/$key nor /etc/rc.d/init.d/supervise/$key
{{Warning box|1=we use preset-all to enable our services, however there is a bug in systemd up to v236 (up to Rhel8). With this bug drop in configuraiton file sin *.service.d/ are ignored when systemctl search for [Install] content to do preset-all.
{{Warning box|1=we use preset-all to enable our services, however there is a bug in systemd up to v236 (up to Rhel8). With this bug drop in configuraiton file sin *.service.d/ are ignored when systemctl search for [Install] content to do preset-all.
As a result our WantedBy=sme-server.target are igored
As a result our WantedBy=sme-server.target are igored
# does not work with templated unit (@.service)}}
# does not work with templated unit (@.service)}}
===== Previous pure Syvinit service, without a provided systemd unit =====
=====Previous pure Syvinit service, without a provided systemd unit=====
Here is the example of masq : /lib/systemd/system/masq.service<syntaxhighlight lang="bash">
Here is the example of masq : /lib/systemd/system/masq.service<syntaxhighlight lang="bash">
[Unit]
[Unit]
</syntaxhighlight>
</syntaxhighlight>
===== Previous Runit service, with a provided systemd unit =====
=====Previous Runit service, with a provided systemd unit=====
If we are lucky we can simply use the ones provided as a replacement, we add a service.d/50koozali.conf for the service and alter it in the way we need.
If we are lucky we can simply use the ones provided as a replacement, we add a service.d/50koozali.conf for the service and alter it in the way we need.
see [[#Previous pure Syvinit service, with a provided systemd unit]] for reference...
see [[#Previous pure Syvinit service, with a provided systemd unit]] for reference...
===== Previous Runit service, without a provided systemd unit =====
=====Previous Runit service, without a provided systemd unit=====
example of wan : /lib/systemd/system/wan.service<syntaxhighlight lang="bash">
example of wan : /lib/systemd/system/wan.service<syntaxhighlight lang="bash">
[Unit]
[Unit]
</syntaxhighlight>
</syntaxhighlight>
=== References ===
===References===
<references />
<references />
[[Category:SME10-Development]]
[[Category:SME10-Development]]
