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.