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