Ann: vera 0.93 released

[Sam]

vera is an alternative init daemon supervisor (PID 1) that uses containers.
Containers allow reliable, foolproof shutdown and termination of started
services. vera was developed on Slackware 15.0. It is capable of booting and
shutting down a stock installation of Slackware 15.

https://github.com/svarshavchik/vera/releases/tag/0.93

Changes: as a proof of concept, this release adds an extra feature on top of
the stock Slackware installation: an optional system/networkmanager-wait-
online container for Slackware systems that use NetworkManager. This
container runs /usr/bin/nm-online, from the NetworkManager package before
starting rc.inet2 services. Other distributions have something similar, this
implements it for Slackware.

[Luis Mendes]

Hi,

Post by Sam
vera is an alternative init daemon supervisor (PID 1) that uses
containers. Containers allow reliable, foolproof shutdown and
termination of started services. vera was developed on Slackware 15.0.
It is capable of booting and shutting down a stock installation of
Slackware 15.
https://github.com/svarshavchik/vera/releases/tag/0.93
Changes: as a proof of concept, this release adds an extra feature on
top of the stock Slackware installation: an optional
system/networkmanager-wait- online container for Slackware systems that
use NetworkManager. This container runs /usr/bin/nm-online, from the
NetworkManager package before starting rc.inet2 services. Other
distributions have something similar, this implements it for Slackware.

I didn't know about vera or other similar package for other Linux distros.
What problems does it try to solve.
I don't use to get problems shutting down started services.

Does it improve security by isolating the services?

[Sam]

Post by Luis Mendes
I didn't know about vera or other similar package for other Linux distros.
What problems does it try to solve.
I don't use to get problems shutting down started services.

There are a few minor networkmanager-related issues that affect a small
minority, that vera fixes.

Post by Luis Mendes
Does it improve security by isolating the services?

No, there is no process isolation.

vera offers more features that are available from sysvinit. Of course, if
all one's doing is running a base Slackware system, with no customization,
there won't be much here.

[#Paul]

Post by Sam
vera is an alternative init daemon supervisor (PID 1) that uses containers.

Where do these containers come from? I assume they are built in
to vera? If so, what properties or restrictions do they have?
Might they be useful for containerizing other processes?

I did have a look at the github, but am none the wiser.

#Paul

[Sam]

Post by #Paul

Post by Sam
vera is an alternative init daemon supervisor (PID 1) that uses containers.

Where do these containers come from? I assume they are built in
to vera?

vera creates them. They are kernel containers. vera uses the current cgroup2
container API. systemd is using the original "version 1" kernal containers.

See the cgroups(7) man page for all the gory details.

Post by #Paul
If so, what properties or restrictions do they have?

The containers are unrestricted. Their main benefit is that they make it
trivial to shut down what's been started. Any process forked off from an
existing process in a container runs in the same container. So, when you
want to stop a started service, it's a no-brainer. It's possible to do other
things with containers, like limit the maximum number of processes per
container, mitigating any potential fork-bombs, or set the maximum amount of
RAM processes in the container could use.

Slackware already uses containers, in the form of the elogind service (since
it's based off systemd code elogind uses version 1 kernel containers). This
is for the same reason if you log out and has something running in the
background it's going to get killed. elogind creates a container for your
login session. When you log out everything in the container get killed.

Post by #Paul
Might they be useful for containerizing other processes?

You can define your own. Here's one for ntpd (that gets automatically
created when vera gets installed):

name: rc.ntpd
description: /etc/rc.d/rc.ntpd
starting:
type: forking
command: /etc/rc.d/rc.ntpd start
stopping:
type: manual
command: /etc/rc.d/rc.ntpd stop
before:
- rc.autofs
x-chmod-script: /etc/rc.d/rc.ntpd
Version: 1

Create something similar, that looks like that, that starts or stops
whatever you want. Or, leave off the stop command entirely, and all started
processes will be terminated upon demand.

(x-chmod-script is specific to Slackware's default initscripts, and keeps
this in sync with what initscripts thinks is enabled, or not, and "before"
is for ordering stuff at shutdown, ignore that, or specify your own explicit
order if you create multiple containers)

[Henrik Carlqvist]

Post by Sam
Slackware already uses containers, in the form of the elogind service
(since it's based off systemd code elogind uses version 1 kernel
containers). This is for the same reason if you log out and has
something running in the background it's going to get killed. elogind
creates a container for your login session. When you log out everything
in the container get killed.

I had to make a quick test, this does not seem to apply to ssh sessions
on a rather stock Slackware 15.0:

-8<--------------------------------------
***@munin:~> sleep 2000 &
[1] 31437
***@munin:~> exit
logout
Connection to munin closed.
nazgul:~> ssh munin
Last login: Thu Apr 18 18:29:19 2024 from 192.168.43.9
Linux 5.15.19.

There is more simplicity in the man who eats caviar on impulse than in the
man who eats Grap-Nuts on principle.
-- G.K. Chesterton

***@munin:~> ps -auxwww | grep sleep
henca 31437 0.0 0.0 2976 1588 ? S 07:36 0:00 sleep
2000
henca 31481 0.0 0.0 3984 2148 pts/1 S+ 07:36 0:00 grep
sleep
***@munin:~>
-8<--------------------------------------

So in the example above my sleep background process survived a logout.

regards Henrik

[Sam]

Post by Henrik Carlqvist

Post by Sam
Slackware already uses containers, in the form of the elogind service
(since it's based off systemd code elogind uses version 1 kernel
containers). This is for the same reason if you log out and has
something running in the background it's going to get killed. elogind
creates a container for your login session. When you log out everything
in the container get killed.

I had to make a quick test, this does not seem to apply to ssh sessions
-8<--------------------------------------
[1] 31437
logout
Connection to munin closed.
nazgul:~> ssh munin
Last login: Thu Apr 18 18:29:19 2024 from 192.168.43.9
Linux 5.15.19.
There is more simplicity in the man who eats caviar on impulse than in the
man who eats Grap-Nuts on principle.
-- G.K. Chesterton
henca 31437 0.0 0.0 2976 1588 ? S 07:36 0:00 sleep
2000
henca 31481 0.0 0.0 3984 2148 pts/1 S+ 07:36 0:00 grep
sleep
-8<--------------------------------------
So in the example above my sleep background process survived a logout.

This looks like a bug, somewhere. I repeated this experiment, and grepped
/sys/fs/cgroup/elogind/*/cgroup.procs, and that cgroup still exists, with
sleep's pid in it.

That's the whole purpose of elogind, as I understand it. The very first
bullet point of the elogind man page says:

• Keeping track of users and sessions, their processes and their idle
state

I don't know "keeping track" means, then. Additionally, each ssh session
creates a new cgroup in /sys/fs/cgroup/elogind, and the old ones don't get
cleaned up. Even if I kill the sleeping pid, its cgroup is left behind and
remains empty.

The only thing I can think of is perhaps the intent here is not to clean up
at logout but provide the means to terminate the session on demand.

However, "loginctl list-sessions" no longer shows the sshd session after
logging out, despite its container being there with the sleeping process in
it.

I repeated the same experiment on Fedora, with systemd.

- After logging off, "loginctl list-session" continued to show the container
with the sleeping pid in it, but it's status shown as "closing".

- After killing the pid, the session was gone, and the container in
/sys/fs/cgroup was automatically removed (the container hierarchy is more
complicated, with full systemd, but the general idea is the same).

That's as much investigation I could complete before having my morning
coffee. At least on Fedora, the equivalent modus operandi seems to be: don't
kill the lingering processes automatically, but provide the means to
terminate them on demand. I don't think elogind is managing to do this
correctly, quite…

[Henrik Carlqvist]

don't kill the lingering processes automatically, but provide the means
to terminate them on demand. I don't think elogind is managing to do
this correctly, quite…

At least in some situations I can see a point in being able to start
background processes or daemons which stays around after logout. A simple
example would be system processes like ntpd, httpd or ftpd which you for
some reason might need to restart on a remote machine.

Doing ssh to such a remote machine and then su to root to run something
like "/etc/rc.d/rc.httpd restart" you would not want apache to get killed
once you logout from the ssh session.

There is a command called nohup which I have never used because the
functionality of nohup is built into tcsh which I use for my shell. One
of the intentions of nohup is to be able to leave background processes
after logging out.

regards Henrik

[Sam]

Post by Henrik Carlqvist
At least in some situations I can see a point in being able to start
background processes or daemons which stays around after logout. A simple
example would be system processes like ntpd, httpd or ftpd which you for
some reason might need to restart on a remote machine.

You also mentioned nohup, and this was the traditional reason why it came
into existence. Unix had a concept of controlling terminal groups or process
groups (which still exists in Linux), and when the process group lead PID
terminated all processes in the group got a SIGHUP. That was the earliest
way to implement the termination of all processes at logout.

But there were situations where one specifically wanted a process to survive
a logout. Enter nohup: it just blocked SIGHUP and executed the command.

The arms race began. Processes started to get coded specifically to ignore
SIGHUP, whether or not you wanted them to. This eventually evolved into
cgroups and what we have here.

Post by Henrik Carlqvist
Doing ssh to such a remote machine and then su to root to run something
like "/etc/rc.d/rc.httpd restart" you would not want apache to get killed
once you logout from the ssh session.

Which is why the ideal solution is to make arrangements with your pid 1
supervisor to do this for you.

This just gave me an idea…