On 1/25/21 12:04 PM, Yasha Karant wrote:
The question is: what mechanism? The reality today for Linux systems as deployed at scale mostly is SystemD. The question -- a question that goes well beyond what started as an exchange about EL 8 -- is what goes forward? SystemD as it currently stands is too delicate and too vulnerable to compromise, either within itself or in terms of the processes/subsystems it "controls", despite the large scale deployment of SystemD. ...
This statement begs some proof (preferably a formal code audit) of the stated opinion that systemd is too 'delicate' and vulnerable to compromise. Anecdotal evidence or counting LoC and saying 'more LoC = automatically more vulnerable' need not apply. Of course, all code is vulnerable, but the implication is that systemd is by nature more vulnerable because $reason where $reason is something other than a formal audit.
I asked a question to which I have not seen an answer: does a SystemD configuration (plain text files in the SystemD design) from two similar hardware platforms but different Linux distros (say, EL and LTS) interoperate, or require significant rewriting to produce the "same results"? In other words, are the valuable concepts of portability and re-usability (do not reinvent the wheel, another engineering turn of phrase) met in practice with SystemD?
The systemd unit files are more portable than old initscripts, in my experience. The determining factors will be whether the distributions' engineers pick the same names for the services started by the unit file and if the paths to executables are the same or not. The main differences here are the same as the differences in the locations of files between the major branches of the Linux filesystem hierarchy; Debian and derivatives will be different from Red Hat and derivatives, to pick the two top examples.
Old initscripts were and are highly dependent upon the functions sourced from the distribution's function library for initscripts, as well as paths and daemon/service name; chkconfig metadata differences; and, of course, they are executing as root in the system shell, and shell quoting and escaping syntax becomes critical (the initscript for an autossh instance, for instance, with say a half dozen reverse tunnels; I have a few of those around here). I wrote a few for PostgreSQL for use on several different RPM-based systems; there was quite a variety, and SuSE did things differently from Red Hat which did things differently from TurboLinux (one of the targets of my packaging), and others did things yet more differently. It's possible to write initscripts to be very portable, but it is harder than writing a unit file that can be portable, as far as I can see. But I do always reserve the right to be wrong.
In practice a unit file from an upstream project, especially if the project uses /opt/$progname or /usr/local/{bin|lib}, will be very portable across distributions. This I have experienced; a single unit file can pretty easily be written to work across all systemd distributions unless it needs some distribution-specific daemon/service or feature.
