[Starlingx-discuss] [multi os] Need of systemd for adoption of flock services in other os

[Dominig ar Foll (Intel Open Source)]

On 12/09/2019 19:37, Victor Rodriguez wrote:
> ...
> The proposal would be to have most of the existing services handled by
> SM via systemd in order to deprecate the sysvinit scripts. SM will
> directly manage the services, via systemd commands. A bit of rewrite
> to current scripts might be necessary. This way there is a consistent
> set of scripts/unit/service files. So, SM would need to be extended to
> understand systemd interactions
Victor,

all modern distros are using systemD and today if I look at the Warning
raised by OpenSUSE build system (OBS), [build error log at the end of
this email], it is clear that the current mix of systemD/init.d/direct
script calls, will not pass any distro QA as it is.
I already had to tweak rpmlintrc to reduce the badness in order to get
packages to be accepted to be published by the OBS.
But for me the fundamental issue is not on how bad is look but how
dangerous it is from a security point of view.

SystemD is by far the best way to start a service to be run in
isolation. We can restrict the privileges, enforce cgroup limits,
isolate via namespaces.
When it come to provide a secure system, it's by far the easiest launch
and maintain processes with reduced attack surface.

Now in StrarlingX we have many processes which are to be started and
controlled by the Service  Manager (SM).
What we should do, is to modify SM in order for SM to use SystemD calls
to start services which are to be monitored by SM.
For those services, we shall not let systemD deamon starts them
automatically, nor to monitor them for potential restart (easy, just a
config).
We can still use automatic dependency to let systemD start underlying
required service (not managed by SM) where it make sense.

Replacing direct script calls to start service in SM, by calls to
systemD cannot be that complex for someone who know where the calls are
hidden in the code.
We could do a hack by having an init script to call systemD but that
would be a mistake as trouble shooting errors would become very messy,
security latency poor.

The best would be to use systemD library API calls (requires systemD >=
219 not an issue for OpenSUSE but what about CentOS) in order to do the
equivalent of systemctl start service_name at unit_number.service without
using system(), popen(), or exec() what would lake the system, safer,
quicker and easier to debug.


-- 
Dominig ar Foll
Senior Software Architect
Intel Open Source Technology Centre

---------- rpmlint report building worker-utils ------------
[    3s] RPMLINT report:
[    3s] ===============
[    3s] worker-utils.noarch: W: no-reload-entry /etc/init.d/cpumap_functions.sh
[    3s] worker-utils.noarch: W: no-reload-entry /etc/init.d/task_affinity_functions.sh
[    3s] In your init script (/etc/rc.d/init.d/your_file), you don't have a 'reload'
[    3s] entry, which is necessary for good functionality.
[    3s] 
[    3s] worker-utils.noarch: W: no-status-entry /etc/init.d/cpumap_functions.sh
[    3s] In your init script (/etc/rc.d/init.d/your_file), you don't have a 'status'
[    3s] entry, which is necessary for good functionality.
[    3s] 
[    3s] worker-utils.noarch: W: suse-deprecated-init-script /etc/init.d/affine-platform.sh
[    3s] worker-utils.noarch: W: suse-deprecated-init-script /etc/init.d/affine-tasks.sh
[    3s] worker-utils.noarch: W: suse-deprecated-init-script /etc/init.d/cpumap_functions.sh
[    3s] worker-utils.noarch: W: suse-deprecated-init-script /etc/init.d/task_affinity_functions.sh
[    3s] SysV init scripts are deprecated. Please migrate to systemd service files.
[    3s] 
[    3s] worker-utils.noarch: W: suse-missing-rclink affine-platform.sh
[    3s] worker-utils.noarch: W: suse-missing-rclink affine-tasks
[    3s] worker-utils.noarch: W: suse-missing-rclink affine-tasks.sh
[    3s] worker-utils.noarch: W: suse-missing-rclink cpumap_functions.sh
[    3s] worker-utils.noarch: W: suse-missing-rclink task_affinity_functions.sh
[    3s] The package contains an init script or systemd service file but lacks the
[    3s] symlink /usr/sbin/rcFOO -> /usr/sbin/service
[    3s] 
[    3s] worker-utils.noarch: W: suse-systemd-shadowed-initscript affine-platform.sh
[    3s] The package contains both an init script and a systemd service file. Please
[    3s] decide for one.
[    3s] 
[    3s] 2 packages and 0 specfiles checked; 0 errors, 13 warnings.