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

[Victor Rodriguez]

On Thu, Sep 12, 2019 at 1:42 PM Dominig ar Foll (Intel Open Source)
<dominig.arfoll at fridu.net> wrote:
>
> 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.
>

Agree

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

Ok, I see that as a valid solution. I would like to ask feedback from
Bin and team

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

We do have 219 in centOS

# systemctl --version
systemd 219

http://mirror.starlingx.cengn.ca/mirror/starlingx/master/centos/latest_build/outputs/RPMS/std/

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

Thanks for the log, it is much more clear for me the need for this change.

Thanks
>
> _______________________________________________
> Starlingx-discuss mailing list
> Starlingx-discuss at lists.starlingx.io
> http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss