#systemd

jonny101@pod.geraspora.de

Years ago I was wondering what this init freedom thing was all about. Today in the wakes of regreSSHion and xzUtils it dawns on me.

This article has been written in 2022 but could not be more up to date today.

#gnu #linux #foss #init #freedom #devuan #debian #backdoor #systemd

The fight for Init Freedom

Distro Walk – Devuan

Devuan, with its promise of Init Freedom, provides users an alternative to systemd as an init process.

Long-time Linux users may remember a time when Debian was viewed as a collection of anarchists, with radical ideas about voting and decision-making. At times, Debian was even the lone dissenter among distributions about decisions made by the Free Software Foundation. However, over the years, Debian has developed its own hierarchy along the way to becoming the source for some two-thirds of active distributions. Today, the Debian derivative most reminiscent of early Debian is Devuan [1], which forked from Debian in 2014 over how decisions were made and the technical connotations of using systemd. Recently, two Devuan developers – fsmithred, who builds the live images and helps with support, and golinux, the community manager – took the time to recall Devuan's past and why their issues are still relevant today. Because Devuan lacks a formal hierarchy, they emphasize that their remarks are "unofficially official."

In 2014, major Linux distributions were transitioning from SysVinit to systemd as an init process – init being the first process to start on a system and the one that manages other processes. Ubuntu had started using Upstart a decade earlier with little controversy. By contrast, systemd was controversial from its earliest days. To start with, systemd is much more than an init system. Rather, as contributor dasein described on the Debian User Forums, "calling systemd an init system is like calling an automobile a cup holder" [2]. That is, while systemd includes the functions of an init system, dasein said systemd is also "an effort to recreate large portions of existing userspace (including login, job scheduling, and networking, just to name a few) inside a single process traditionally reserved for the sole purpose of starting *nix userspace. (Just in case it isn't clear, there is a huge difference between starting userspace (init) and being userspace (systemd).)"

From this perspective, not only is systemd overkill, but it is a violation of the basic tenet of Unix development that an application does only one thing and does it very well. As Christopher Barry stated in the Linux Kernel Archive, this philosophy is what makes Linux "a collection of simple modular components that could be plugged together at will to do real work" [3] – an operating system that is both flexible and accessible. Just as importantly, a modular structure allows the pieces to be assembled in different ways, so that each distribution can be unique. By contrast, systemd imposes a structure on all Linux systems that reduces variety – which is convenient in some ways, but needlessly limiting in time-honored ways.

As expected, the Debian mail forums debated these perspectives extensively. Unsurprisingly, the discussion culminated in a General Resolution among Debian users, with many Debian officials favoring systemd. The winning option was to use systemd, but at the same time, a more general resolution to favor systemd placed last – a decided ambiguity. Although rarely stated in so many words, much of the dissatisfaction implied that the decision to use systemd was imposed by the Debian hierarchy upon the general membership.

Whether this implication was valid is besides the point. Many believed it was. On November 24, 2014, the Devuan fork was announced. The intention was "to produce a reliable and minimalist base distribution that stays away from the homogenization and lock-in promoted by systemd" [4].
Introducing Init Freedom

Rather than being seen as simply an anti-systemd project, Devuan calls its position Init Freedom (Figure 1). The name invokes Richard Stallman's four essential freedoms, although the idea itself might seem less basic. Devuan's Init Freedom page [5] simply defines the idea as being "about restoring a sane approach to PID1 [init] that respects portability, diversity, and freedom of choice," assuming that the value of these goals is self-evident.
Figure 1: Devuan supports a choice of init alternatives.

In practice, Init Freedom means supporting a choice of init freedoms. Although systemd advocates often maintain that supporting multiple init systems would make packaging more difficult, from its first release, Devuan has continually added init alternatives without any apparent difficulties. Today, in addition to the default SysVinit, Devuan lists six alternatives: OpenRC, runit, sinit, s6, 66-devuan, and Shepherd, and it is open to considering others. Fsmithred suggests that most people simply use sysVinit, although OpenRC and runit, which use SysVinit scripts, are also available. Scripts are also being developed for runit and to extend usability of other shipped alternatives. For those interested in learning more, discussion can be found on the Dev1 Galaxy Forum [6] and on Devuan's IRC channel [7].

In addition, the Init Freedom page lists other Linux distributions that offer systemd-free alternatives, as well as other Unices such as the BSD Family. DistroWatch also offers a search filter for distros without systemd – currently, 97, a total far higher than many might suspect, although it includes only a handful of major distributions, such as MX Linux, Alpine Linux, and KNOPPIX [8]. Devuan keeps in close touch with these distributions, especially on the Dev1 Galaxy Forum.

Fsmithred adds that, "We rely heavily on Debian. Most of the packages in Devuan are unchanged from Debian. We only fork packages that require systemd. There is collaboration between Devuan and Debian on a few packages, and we occasionally send bug fixes or patches upstream to Debian for packages we do not fork."
Beyond Init Freedom

Devuan is usually referred to in terms of Init Freedom – often with the obviously mistaken assumption that it is a lost cause. However, Devuan also features Docker images and community-developed ARM packages. Chimaera, the latest Devuan release, also includes an option to not install PulseAudio to enable simultaneous speech synthesis in both a graphical and console session. In addition, at least one Devuan-derivative exists, Maemo Leste, whose goal is "to provide a free and open source Maemo experience on mobile phones and tablets like the Nokia N900, Motorola Droid 4, Motorola Bionic, PinePhone, PineTab, Allwinner tablets, and more" [9]. Although Devuan might be a niche distribution, clearly it is a thriving one.

But can Devuan's cause become mainstream? It's not impossible. Linux is in an era in which large parts of it are being written. If PulseAudio can be replaced with PipeWire – which is currently happening – then systemd's obsolescence is not impossible, either. Meanwhile, for those who disagree with the majority, Devuan provides a workable alternative, while keeping the early spirit of Debian alive.

Source: https://www.linux-magazine.com/Issues/2022/260/Devuan

adolar@diaspora.psyco.fr

I had mentioned the new #systemd version 256 recently, because its announcement came with the proud comment that it got rid of much Unix philosophy. There is a new minor version, because a number of people suddenly had their home directories deleted - which was entirely as desired, according to one of the main developers.

Systemd 256.1 Fixes "systemd-tmpfiles" Unexpectedly Deleting Your /home Directory - Phoronix https://www.phoronix.com/news/systemd-tmpfiles-purge-drama

Over on Mastodon and a systemd bug report, users were surprised that running "systemd-tmpfiles --purge" will delete all files/folders created by a tmpfiles.d configuration file even with the default behavior of /home being created by one. Thus those trying to do system maintenance without reading the man page could find their /home data deleted.

Initially the bug report was shot down by systemd developer Luca Boccassi of Microsoft with:
So an option that is literally documented as saying "all files and directories created by a tmpfiles.d/ entry will be deleted", that you knew nothing about, sounded like a "good idea"? Did you even go and look what tmpfiles.d entries you had beforehand?

Maybe don't just run random commands that you know nothing about, while ignoring what the documentation tells you? Just a thought eh

Wow, just wow. "On your knees and worship the new Windows registry we brought to Linux, even though you worms don't deserve it!" When I get a new computer, I will definitely switch to a distro without systemd, perhaps even earlier...

wazoox@diasp.eu

Systemd haters have a point

#linux #systemd #security

from https://serverfault.com/questions/1159599/how-to-change-the-ssh-server-port-on-ubuntu

Ubuntu has been using systemd-sockets for some time now, which makes the port configuration in the SSH server configuration obsolete.

To change the port of the SSH server, the systemd configuration for ssh.socket must be changed or supplemented. The configuration adjustment is made by creating a *.conf file in the directory /etc/systemd/system/ssh.socket.d/.

Create conf file to extend the default config:
systemctl edit ssh.socket
or
vim /etc/systemd/system/ssh.socket.d/override.conf

    [Socket]
    ListenStream=
    ListenStream=2222

The line ListenStream= is required that port 22 is no longer used. Without this line, the SSH server would then be accessible via port 22 (default) and 2222.

WHAT THE ACTUAL FUCK? systemd silently overrides SSH configuration with obscure parameters, and silently keeps default parameters active? WHO THE FUCK IS THE DANGEROUS MORON who imagined this ? What other services are similarly hobbled silently ?

rainerhgw@diasp.org

How do I set a property in #systemd?

I have:

root@mx1:~# systemctl show postfwd | grep ^CanReload
CanReload=yes

I want to change that to no.
The fine manual says:
```
set-property UNIT PROPERTY=VALUE...
Set the specified unit properties at runtime where this is
supported. This allows changing configuration parameter properties
such as resource control settings at runtime. Not all properties
may be changed at runtime, but many resource control settings
(primarily those in systemd.resource-control(5)) may. The changes
are applied immediately, and stored on disk for future boots,
unless --runtime is passed, in which case the settings only apply
until the next reboot. The syntax of the property assignment
follows closely the syntax of assignments in unit files.

       Example: systemctl set-property foobar.service CPUWeight=200
But when I follow the example I get:

root@mx1:~# systemctl set-property postfwd.service CanReload=no
Unknown assignment: CanReload=no
```