pid_eins

pid_eins, 2 days ago

@gnubyte nobody is taking sudo away. It's about offering something better for OSes that don't have to care about legacy so much.

pid_eins, 2 days ago

It relies on TCP as network transport, which is great for remote operation around the globe but really sucks for local communication with a VM and similar, as it usually requires delegation of an address space, dhcp lease, dns and so on, which while manageable are certainly a major source of mistakes, fragility and headaches. In particular it means that logging into a system to debug networking doesnt really work since without working networking you cant even log in. Sad!

pid_eins, 2 days ago

Thing is though, that there are better ways to communicate locally: AF_VSOCK is an alternative to AF_INET/AF_INET6 for local communication between VMs and hosts. In many ways it behaves very similar to TCP. It is similar enough so that you can just do ssh-via-AF_VSOCK. As opposed to AF_INET/AF_INEt6 it requires next to no configuration, your really just have to enable the knob in your VMM, and have a somewhat non-ancient Linux distribution as guest.

pid_eins, 2 days ago

And ssh-via-AF_VSOCK is precisely what we are doing in systemd v256: a small new unit generator (i.e. a plugin that extends systemd's unit tree dynamically) detects if AF_VSOCK is available and sshd is installed, and if so binds AF_VSOCK/port 22 to sshd, via socket activation. Or in other words: in environments where AF_VSOCK is a thing, sshd will now just work, without any extra configuration and at minimal cost of resources (because lazy socket activation rocks).

pid_eins, 2 days ago

Binding sshd to AF_VSOCK is one thing, but it would be useless if we couldn't also connect to it via an ssh client. Hence v256 also includes a small client-side plugin for ssh that makes it possible to connect to such a VM by specifying "ssh vsock/$CID" (where $CID is the vsock address — one of which each VM gets automatically assigned).

pid_eins, 2 days ago

And there's more: the generator also binds sshd to two AF_UNIX sockets for good measure given we are already at it and it's easy. One is a socket in /run/host/ if that exists and is a mount point — which is a scheme defined for full-OS containers: the idea ist that the container manager makes that dir also available on the host, so that you can connect from the host to the container via ssh-over-AF_UNIX without bothering with network config and setup.

pid_eins, 2 days ago

The other one is at a generic socket in /run/ which happens always, and can be used to acquire privs locally.

This automatic ssh-via-AF_VSOCK logic is particularly useful in conjunction with the notification mechanism detailed in installment 3, i.e. sd_notify() notifications from PID 1 to its VMM via AF_VSOCK.

pid_eins, 2 days ago

Because it means a VMM can start a VM, wait for the X_SYSTEMD_UNIT_ACTIVE=ssh-access.target sd_notify() message and then immediately connect to the VM via ssh-over-AF_VSOCK. Reliably, without wasting time, without retries, without network config and setup, without preparing the guest much (well you do have to add sshd to it), just like that.

And that's all for this time. We still have more to cover, hence stay tuned.

pid_eins, 1 day ago

@NekkoDroid So there's a programmable rate limit on socket units. If you hit that too often we assume that something is wrong (i.e. that the service in question dies quickly after activation and never can process its connections). Hence, in order to not consume unbounded CPU we will eventually give up trying to activate the service. This safety feature can be seen as a DoS, if there simply are very high amounts of connections, the rate limit is hit too after all, it cannot…

pid_eins, 1 day ago

@NekkoDroid …distinguish between very high number of attempts because of misconfiguration or because of valid connection attempts.

Now, the this ratelimit was configurable since a long long time, people just never bothered to. You can simply turn it off in the socket unit via TriggerLimitIntervalSec=/TriggerLimitBurst=.

So, the DoS never really was a DoS, it was at best a misconfiguration.

With v255 we added a separate ratelimit to socket units that behaves differently, btw.

pid_eins, 1 day ago

@NekkoDroid Specifically, there's now PollLimitIntervalSec=, PollLimitBurst=. If this rate limiting is hit, then the effect is not that the socket unit will be put in a failed state, but instead we'll just stop watching the socket for the rest of the time window. Once the time passed we'll start watching again. This basically means, that if the system is hit with a flood of connection attempts, we'll pause processing them for a while, and then return processing them after the configurable…

pid_eins, 1 day ago

@NekkoDroid … time window passed.

With that in effect I think we should be really safe and robust against DoS, because we actually never deny service, but at the same time we also don't let our CPU use grow unbounded.

Does that make any sense?

pid_eins, 1 day ago

@kccqzy yes.

pid_eins, 3 days ago

@jamesh it doesn't show up in melpa if I do M-x package-list-packages however… Seems MELPA is hosed on Fedora Emacs?

pid_eins, 3 days ago

@jamesh ah, indeed. thanks. that worked.

didn't realize the difference between those repositories...

ELPA seems kinda useless though? requires copyright assignment, uh? what is this, 1995? but meh, sounds like something typically gnu...

pid_eins, 3 days ago

Which types of sleep are available depends on various parameters. On functionality of the hardware, on security settings, on available swap space and more.

systemd exposes all four modes listed above via high D-Bus calls in systemd-logind, and via systemctl commands. Desktop UIs so far were expected to figure out which of the methods to use, and maybe implement a fallback scheme. This is less than ideal, in particular as inhibitor schemes would trigger multiple times…

pid_eins, 3 days ago

…if fallbacks are necessary.

With v256 we did something about this: there's now a new D-Bus call and systemctl command, which we just called "sleep". It's supposed to abstract this mess away, and just get the job done, according to what is available, and based on system-level configuration in /etc/systemd/sleep.conf if needed.

This relieves tools and desktops to bother what precisely to when suspending, and just make the system "sleep" and let the lower layers of the stack then figure…

pid_eins, 3 days ago

…out what to precisely do.

Hence, in your mind, please rewire "systemctl suspend" to now become "systemctl sleep".

And that's all for now. Stay tuned for installment Nr. 13.

pid_eins, 3 days ago

@dinfuehr we increase the version number when we do a new release.

pid_eins, 4 days ago

@jntesteves yes, typo.

pid_eins, 4 days ago

@breiti well, the scheme leaves unanswered what happens to network devices that are not tagged for any network management service. My assumption is that based on user config one of them takes possession of all untagged devices. networkd by default doesn't, NM by default does. Thus in this combination at least we should be good, you can just leave networkd running together with NM and in the default config everything should be fine.