[TUHS] Re: Version 256 of systemd boasts '42% less Unix philosophy' The Register

[Steffen Nurpmeso <steffen@sdaoden.eu>]

Bakul Shah via TUHS wrote in
 <653E15D7-DD66-414C-94F3-A74B4EE3DD10@iitbombay.org>:
 |On Jun 16, 2024, at 8:57 PM, ron minnich <rminnich@gmail.com> wrote:
 |> I'm curious, as to the original topic of this discussion: can anyone \
 |> justify systemd-homed and how it works? Does that even look like \
 |> 0% of a unix idea?
 |
 |I am not a fan of systemd (or linux) and don't follow their excesses/adv\
 |entures but I am not a fan of how BSD does initialization & brings \
 |up services either. They don't quite get all the dependencies right \
 |for all the possible combinations of devices etc.  Its /etc/rc.d/* \
 |system is pretty clunky -- I tend to think any time you are repeating \

Now even more since they started to add a "jail-this-service"
variable, ie containerization by setting a variable.

 |more or less the same boilerplate code in many files, something worth \
 |abstracting is hiding in there.
 |
 |I like how launchd  treats a service as an object (more than just a \
 |program but also the auxiliary files and scripts). For me it was a \
 |lightbulb moment (like realizing how a function operates in an environme\

To me -- it turned off my light as i tried to "do something", but
could not figure out how; i somehow managed to create the XML file
necessary.  I am happy to have forgotten what it was about.  Ah,
wait, voila:

  $ v ~/arena/misc/macosx-plist-use.txt
  
  <?xml version="1.0" encoding="UTF-8"?>
  <!DOCTYPE plist PUBLIC "-//Apple Computer//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
  <plist version="1.0">
  <dict>
          <key>Label</key>
          <string>com.bell-labs.plan9.u9fs</string>
          <key>Program</key>
          <string>/usr/bin/u9fs</string>
          <key>ProgramArguments</key>
          <array>
                  <string>u9fs</string>
                  <string>-l</string>
                  <string>/var/log/u9fs.log</string>
                  <string>-a</string>
                  <string>p9any</string>
                  <string>/opt/plan9</string>
          </array>
          <key>Sockets</key>
          <dict>
                  <key>Listeners</key>
                  <dict>
                          <key>SockServiceName</key>
                          <string>9pfs</string>
                  </dict>
          </dict>
          <key>inetdCompatibility</key>
          <dict>
                  <key>Wait</key>
                  <false/>
          </dict>
  </dict>
  </plist>
  
   To cause this to be run on system start, this should be
   installed as /Library/LaunchDaemons/9pfs.plist. Installing
   instead in /Library/LaunchAgents will cause it to be run only
   when a user is logged in, while $HOME/Library/LaunchAgents will
   cause it to be run only when that particular user is logged in.
  
   In order to start the listner it must first be ``loaded''
  $ sudo launchctrl load /path/to/9pfs.plist
  
   If you are running the Mac OS X firewall you will need to add
   an entry pass the 9pfs protocol in:
  SystemPreferences->Sharing->Firewall

I give you ten points for configuration lightbulb moments!
So nice and easy, also for human consumption once written.

  ...
 |What I want is to be able to map all my computers and compute clusters \
 |into a single virtual machine -- where storage, IO and computing resources \
 |may be added / removed without taking the whole VM down, and where \
 |each display/input user interface is a window on the same underlying \
 |VM and all sharing is under my control. Plan9 does a bit of this but \
 |that experiment ended too early. Apple is tending in this direction \
 |though not cleanly (+ I don't want to rely on a faceless behemoth corp \
 |that may trample on my data without even meaning to).

I had that dream somewhen spoken out in a FreeBSD IRC channel
a few years back.  It *could* be that the new per-service-jails do
it a bit like that, via nullfs mounting, that deep i have not
looked into it yet.
But my idea was that the base system is mounted partially, and you
would specify the PKGs you want in the jail, and that only the
files of the given pkgs are actually visible in the jail.

I use something a bit similar for some boxed things here on Linux,
with overlayfs; however, after

    mount -n -t overlay -o upperdir=${rundir}/storage,lowerdir=/,workdir=${rundir}/work \
            overlayfs ${rundir}/root || exit 21

i then start rm(1) removal of some files, eg

    rm -rf \
            ${rundir}/root/boot \
            ${rundir}/root/home \
            ${rundir}/root/media \
            ${rundir}/root/opt \
            ${rundir}/root/root \
            ${rundir}/root/run \
            ${rundir}/root/var \

plus over-mounting things like dev

    # devtmpfs fully populates instead, including log socket etc!!
    #mount -n -t devtmpfs dev ${rundir}/root/dev || exit 50
    mount -n -t tmpfs -o nosuid,noexec dev ${rundir}/root/dev || exit 50

etc etc etc.  That is *not* what i meant.
That idea is old, i have not yet managed it to create a shareable
root system, which is then *per-se* overlay mounted, even by the
system itself.  (That is: the base is shared by the base system
and containers, which then add onto what they want and need.  It
could even be mounted as a base for real VMs.)

Regarding systemd my only hope is that Linux remains usable
without it.  It seems more and more require the systemd
infrastructure in order to function, i have heard.
That "super / sudo / doas / [BSD] su -c" replacement that systemd
just recently added, somehow i followed a link to the github or so
issue where this was discussed, and i still hear the lead
developer of AlpineLinux ask for a separate udev, a part that
anyone needs, i think he did not even get an answer.  Which
deterred me further.  (I think the AlpineLinux lead developer's
name is pretty well-known in that society.)  Hmm.  It *could* be
that it was in fact in another issue that turned fixed linked-in
libraries like compressors like xz (the backdoor there, you know)
into dlopen()-managed mess, via kinda marshalling.  There.
Whatever.
Btw i did not sent out another email last week

  Jim Capp wrote in
   <1403506.1536.1718310415450.JavaMail.root@zimbraanteil>:
   |https://nosystemd.org/

  It is the pride and ignorance of the billion dollars that pay lots
  of developers on the Linux front that makes me sad.

  For example, on ossec-, we repeatedly see an OpenSUSE employee,
  who seems to get paid for doing security audits, publish security
  advisories.  That is (mostly seems to be) a one man show.
  Of course, many things happen behind the scenes, in bug trackers
  etc.  But i track fulldisclosure and ossec- for way over a decade.

  And "the same is true" for the boot and daemon monitoring
  environment.

  On FreeBSD, for example, one programmer is working to integrate
  "jail"ing
    (FreeBSD jails: twenty+ years ago it was a precondition in some
    system calls, looking for "is-jailed", plus dedicated network
    stack etc; usually (i hate it) also with its dedicated file
    system aka mounts etc. etc)
  into daemon startup aka the rc system, so you (that seems to be
  the idea) just set a rc.conf variable and the service is "boxed"
  in a jail automatically.

  If you look at all the rotten data in the Linux login etc (with
  PAM or not, etc etc), just a few programs in the startup process,
  but it is too much to keep them in line

Yeah!  [.] with modern achievements like PR_SET_CHILD_SUBREAPER to
move entire process hierarchies to dedicated zombie collectors and
such that is to say, with capabilities and all that, which systemd
makes easy, via easy text config files.  Ie, namespace containment
(aka network stack etc isolation), at your fingertips.
But per se a stacked call like

        cd /
        ip netns exec ${netns} \
                /usr/bin/env -i AUTHDISPLAY=${AUTHDISPLAY} DISPLAY=${DISPLAY} TERM=${TERM} XAUTHORITY=${XAUTHORITY} \
                        /usr/bin/unshare --ipc --uts --pid --fork --mount --mount-proc ${kill_child} ${rooter} ${prog} &
        pid=${!}
        [ -d /sys/fs/cgroup/_box_web ] && printf '%s\n' ${pid} > /sys/fs/cgroup/_box_web/cgroup.procs

#       if [ ${netns} = secweb ] || [ ${netns} = priwse ]; then
                wait $pid
                cleanup_setup
#       fi
        exec 7>&-

can (add capabilities) do the very same thing.

Btw there is an init-on-steroids [1] from the guy who took
maintainership of sysklogd quite some years ago (used by my Linux
distro ever since), it can also supervise, use cgroups, etc.
I plan to try it out for years, but since i realized i have to go
second line i have written some scripts, and then just call in via
SysV or OpenRC, or what.

I mean, i have no problem with the notification stuff of systemd,
it is now even included in OpenSSH (optionally, in
openbsd-compat/port-linux.c), but i mean the PID file things are
used for decades, and with "daemons and zombies are reparented to
a configured subreaper process" (instead of PID 1), and with the
fully capable but not systemd integrated udev (all "looser" Linux
distributions "have to use" eudev).  Ah!  Talking too much!!

  [1] https://github.com/troglobit/finit

--steffen
|
|Der Kragenbaer,                The moon bear,
|der holt sich munter           he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)