[systemd-devel] Getting rid of the /run/credentials mount
Hi, the aide (https://github.com/aide/aide) tool builds checksums of files on the system and sends an alert if things change on the system. In the Debian package, this is done from cron. I would like to move that to a systemd timer and in passing use some of systemd's security features. Here is my service: [Unit] Description=dailyaide check StartLimitIntervalSec=7200 StartLimitBurst=1 [Service] Type=oneshot User=root Group=root Environment="CREDENTIALS_DIRECTORY=/nonexistent" ProtectSystem=strict ProtectClock=yes ProtectKernelModules=no ProtectKernelLogs=yes ProtectControlGroups=yes PrivateDevices=no ProtectKernelTunables=yes ProtectControlGroups=yes ProtectHome=read-only ReadWritePaths=/run/aide /var/lib/aide /var/log/aide /var/spool/exim4 /var/log/exim4 /var/tmp /tmp RestrictRealtime=yes RestrictSUIDSGID=yes PrivateTmp=no ExecStartPre-=/bin/umount /run/credentials ExecStart=/usr/local/sbin/dailyaidecheck --systemdservice You might see that I have tried some things to get rid of the mount of /run/credentials which allows an attacker to hide something in /run/credentials without aide being able to see it because it gets some temporary filesystem mounted over that path. Unfortunately, neither of those tricks have worked, and my /run/credentials/foo that I created before starting my service remains undetected. What do I do to disable the credentials mechanism in my service? Greetings Marc -- ----- Marc Haber | "I don't trust Computers. They | Mailadresse im Header Leimen, Germany| lose things."Winona Ryder | Fon: *49 6224 1600402 Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600421
Re: [systemd-devel] Getting rid of the /run/credentials mount
On Thu, Aug 25, 2022 at 11:37:12PM +0300, Topi Miettinen wrote: > On 25.8.2022 22.42, Marc Haber wrote: > > on the system and sends an alert if things change on the system. In the > > Debian package, this is done from cron. I would like to move that to a > > systemd timer and in passing use some of systemd's security features. > > Here is my service: > > > > What do I do to disable the credentials mechanism in my service? > > You could use TemporaryFileSystem=/run together with a few BindPaths= for > the required directories. For example, on my setup the user doesn't see all > cruft in global /run: > $ ls /run > dbus/ firejail/ systemd/ udev/ user/ > > See also > https://github.com/systemd/systemd/pull/21748 > for some thoughts on tentative new directive PrivateRun= or something > similar. My intention is the opposite. I want (and need!) my process to see what is actually in /run. Nothing should be hidden away. The process itself doesn't use anything in /run, but I want it to be able to detect changes. Greetings Marc -- - Marc Haber | "I don't trust Computers. They | Mailadresse im Header Leimen, Germany| lose things."Winona Ryder | Fon: *49 6224 1600402 Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600421
Re: [systemd-devel] Getting rid of the /run/credentials mount
On Fri, Aug 26, 2022 at 07:28:37AM +0200, Marc Haber wrote: > On Thu, Aug 25, 2022 at 11:37:12PM +0300, Topi Miettinen wrote: > > On 25.8.2022 22.42, Marc Haber wrote: > > > on the system and sends an alert if things change on the system. In the > > > Debian package, this is done from cron. I would like to move that to a > > > systemd timer and in passing use some of systemd's security features. > > > Here is my service: > > > > > > What do I do to disable the credentials mechanism in my service? > > > > You could use TemporaryFileSystem=/run together with a few BindPaths= for > > the required directories. For example, on my setup the user doesn't see all > > cruft in global /run: > > $ ls /run > > dbus/ firejail/ systemd/ udev/ user/ > > > > See also > > https://github.com/systemd/systemd/pull/21748 > > for some thoughts on tentative new directive PrivateRun= or something > > similar. > > My intention is the opposite. I want (and need!) my process to see what > is actually in /run. Nothing should be hidden away. The process itself > doesn't use anything in /run, but I want it to be able to detect changes. I filed an enhancement issue, https://github.com/systemd/systemd/issues/24508 Greetings Marc -- - Marc Haber | "I don't trust Computers. They | Mailadresse im Header Leimen, Germany| lose things."Winona Ryder | Fon: *49 6224 1600402 Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600421
[systemd-devel] bind-mount of /run/systemd for chrooted bind9/named
Hi, this is a user-level question from someone who wants to make use of systemd but has not quite grown the gut feeling about which way is the right way to go. I am running bind 9 on more than a handful of systems providing name services as recursive and/or authoritative name servers. As it has ben recommended for two decades, I run bind in a chroot, using its own feature to chroot itself after starting up (-t /path/to/chroot). In Debian bookworm, the systemd units that come with Debian's bind9 package have recently changed from Type=simple to Type=notify. Combined with named -t, this means that systemd will never notice that the name daemon has correctly started up unless systemd's notify socket is also reachable in the chroot. This in turn means that bind is continuosly restarted by systemd. As a quick fix, I issue moiunt --bind /run/systemd /path/to/chroot/run/systemd manually. I am currently wondering which way is the preferred way to achive this in a more clean way: (1) go fully systemd That would mean to get rid of bind's -t option completely but use systemd's RootDirectory directive instead. I have not tried this but I think that the bind community might be reluctant to support a setup like that. In advantage, I could use the BindReadOnlyPaths directive to directly manage the necessary bind mount to make the notify socket accessible. (2) try to preserve the classic setup That would probably mean having a /etc/systemd/system/var-local-bind-run-systemd.mount with the contents: | [Mount] | What=/run/systemd | Where=/var/local/bind/run/systemd | Type=none | Options=bind | | [Install] | WantedBy=bind9.service and adding a RequiresMountsFor=/var/local/bind/run/systemd to the bind9.service. This works as intended when I start up bind9, but when stopping the name daemon, the bind mount still lingers around. I have not fully understood the necessary systemd magic to have var-local-bind-run-systemd.mount stopped whenever bind9.service stops. How would I do that? How would you solve this issue? Method (1), Method (2), or one that I didn't think of yet? Greetings Marc -- ----- Marc Haber | "I don't trust Computers. They | Mailadresse im Header Leimen, Germany| lose things."Winona Ryder | Fon: *49 6224 1600402 Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600421
Re: [systemd-devel] bind-mount of /run/systemd for chrooted bind9/named
On Mon, Jul 03, 2023 at 11:21:22PM +0200, Silvio Knizek wrote: > why is it suggested to run `named` within its own chroot? For security > reasons? This can be achieved much easier with systemd native options. That feature is two decades older than systemd, and name server operators are darn conservative. Greetings Marc -- - Marc Haber | "I don't trust Computers. They | Mailadresse im Header Leimen, Germany| lose things."Winona Ryder | Fon: *49 6224 1600402 Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600421
Re: [systemd-devel] bind-mount of /run/systemd for chrooted bind9/named
Hi Lennart, thanks for this helpful answer. On Tue, Jul 04, 2023 at 10:37:55AM +0200, Lennart Poettering wrote: > On Mo, 03.07.23 20:52, Marc Haber (mh+systemd-de...@zugschlus.de) wrote: > > (1) go fully systemd > > That would mean to get rid of bind's -t option completely but use > > systemd's RootDirectory directive instead. I have not tried this but I > > think that the bind community might be reluctant to support a setup like > > that. In advantage, I could use the BindReadOnlyPaths directive to > > directly manage the necessary bind mount to make the notify socket > > accessible. > > I'd generally advise this, as it means you can drop caps like > CAP_SYS_ADMIN and so on right-away, i.e. all the stuff that chroot() > means. That would, however, mean to have the bind binary and all libraries in the chroot as well, which means either a lot of copying or a lot of bind mounting into the chroot, introducing a number of challenges regarding updates etc. Using bind's -t option is charming here because it just needs configuration, persistent data and a few auxillary files in the chroot. This has become harder nowadays since bind loads some libraries with dlopen() after the chroot, so at least those .so files need to be in the chroot. > You don't need to explicitly mount the notify socket if you use this > btw, systemd will do this for you automatically if you combined > RootDirectory= and Type=notify. That is nice to know. > > (2) try to preserve the classic setup > > That would probably mean having a > > /etc/systemd/system/var-local-bind-run-systemd.mount with the contents: > > | [Mount] > > | What=/run/systemd > > | Where=/var/local/bind/run/systemd > > | Type=none > > | Options=bind > > | > > | [Install] > > | WantedBy=bind9.service > > and adding a RequiresMountsFor=/var/local/bind/run/systemd to the > > bind9.service. > > It should suffice bind mounting just the notify socket, not the full > dir. Is it intended behavior that an empty file is left at the "mount point" (what Where= points to) after the unit was stopped? > You could also use a hybrid approach: let systemd bind mount this for > your service (and thus set up a minimal namespaced env for your > service, but with the root where it normally is), and then still let > bind do its own chroot() thing inside of it). I do not quite understand exactly what that means, how would I do that? What is "this" in the "mount this" part of sentence? > Generally speaking: its typically a better idea to rely on proper fs > mount namespacing (i.e. decoupling mount tables of services and host) > rather than plain chroot() (where they aren't decoupled). If bind only > does chroot(), then I think using systemd's namespacing is the much > better choice. Where would I read up on systemd namespacing? Are you refering to what is explained in the "Sandboxing" chapter of systemd.exec(5), like ProtectSystem, ReadWritePaths etc? So I would basically set ProtectSystem=strict ReadWritePaths=/var/local/chroot/bind/pathlist (all paths that bind needs to actually write to) and then finally ExecStart=/path/to/bind -f -t /var/local/chroot/bind ? Is that what you mean? If I set ProtectHome=yes, how do I give the user that bind runs as access to its homedir? Is ReadWritePaths= the solution? > > This works as intended when I start up bind9, but when stopping the name > > daemon, the bind mount still lingers around. I have not fully understood > > the necessary systemd magic to have var-local-bind-run-systemd.mount > > stopped whenever bind9.service stops. How would I do that? > > You can do Wants= from bind to the mount unit. And then do > StopWhenUnneeded= in the mount unit, to release it when not needed. StopWhenUnneeded was what I needed. So I currently have: [7/5031]mh@drop:~ $ sudo systemctl cat named # /lib/systemd/system/named.service [Unit] Description=BIND Domain Name Server Documentation=man:named(8) After=network.target Wants=nss-lookup.target Before=nss-lookup.target RequiresMountsFor=/var/local/chroot/bind/run/systemd [Service] Type=notify EnvironmentFile=-/etc/default/named ExecStart=/usr/sbin/named -f $OPTIONS ExecReload=/usr/sbin/rndc reload ExecStop=/usr/sbin/rndc stop Restart=on-failure [Install] WantedBy=multi-user.target Alias=bind9.service [8/5030]mh@drop:~ $ and 1 [9/5031]mh@drop:~ $ sudo systemctl cat var-local-chroot-bind-run-systemd.mount # /etc/systemd/system/var-local-chroot-bind-run-systemd.mount [Unit] StopWhenUnneeded=true [Mount] What=/run/systemd Where=/var/local/chroot/bind/run/systemd Type=none Options=bind [10/5032]mh@drop:~ $ (test system, I don't usually edit files in /lib/systemd, I know about the override mechanisms). Agai
Re: [systemd-devel] bind-mount of /run/systemd for chrooted bind9/named
Hi Lennart,
On Mon, Jul 10, 2023 at 10:28:52AM +0200, Lennart Poettering wrote:
> On So, 09.07.23 20:14, Marc Haber (mh+systemd-de...@zugschlus.de) wrote:
>
> > > It should suffice bind mounting just the notify socket, not the full
> > > dir.
> >
> > Is it intended behavior that an empty file is left at the "mount point"
> > (what Where= points to) after the unit was stopped?
>
> We need an inode we can overmount, and given that this is in /run/
> (hence inherently ephemeral) and a fixed path it shouldn't matter.
So this is intended. Good to know. I stumbled upon that.
> > If I set ProtectHome=yes, how do I give the user that bind runs as
> > access to its homedir? Is ReadWritePaths= the solution?
>
> ProtectHome= is about /home/ only, i.e. regular ("human") users, not
> about system users (i.e. uid < 1K). Your bind should *not* run as
> regular user, but as a system user of course, hence ProtectHome= is
> something you can just set, and don't need to be concerned about the
> system user's home dir.
In Debian, bind runs as user bind, which gets created as a system user
(uid < 1K, yes), and with /var/cache/bind as its home directory, which
is the directory where, for example, slave zone files get written to.
So, the running process needs to be able to access its "home directory"
during its operation even after dropping root.
> > [Mount]
> > What=/run/systemd
> > Where=/var/local/chroot/bind/run/systemd
> > Type=none
> > Options=bind
>
> Note that /run/ should always be a tmpfs, hence unless you mount a
> tmpfs to /var/local/chroot/bind/run/ first, the above is a bit ugly.
>
> Instead of this .mount unit, consider using in the .service file:
>
> TemporaryFileSystem=/var/local/chroot/bind/run
> BindPaths=/run/systemd/notify:/var/local/chroot/bind/run/systemd/notify
Ah, of course. I obviously didn't read BindPath's documentation
thoroughly enough. That is of course way better. Thanks for helping me
to read the docs.
Greetings
Marc
--
-
Marc Haber | "I don't trust Computers. They | Mailadresse im Header
Leimen, Germany| lose things."Winona Ryder | Fon: *49 6224 1600402
Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600421
Re: [systemd-devel] bind-mount of /run/systemd for chrooted bind9/named
On Mon, Jul 10, 2023 at 12:11:01PM +0200, Lennart Poettering wrote: > ProtectHome= protects /home/, nothing else. Hence you can use it, and > it should not collide with bind's use of the home dir, because it's > not in /home. > > Actually, correcting myself: use ReadOnlyBindPaths= for this. clients > cann still connect to sockets on read-only fs just fine, but you take > the privs away to chmod() or chown() the inode that way. So you get > another line of defense that way. Thank you, all my questions are answered for the time being. Your help is appreciated. Greetings Marc -- ----- Marc Haber | "I don't trust Computers. They | Mailadresse im Header Leimen, Germany| lose things."Winona Ryder | Fon: *49 6224 1600402 Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600421
[systemd-devel] Securing bind with systemd methods (was: bind-mount of /run/systemd for chrooted bind9/named)
that in my ansible. And setuid is setuid32 on 32 bit archs like armhf, # so I had to template _that_ for my Banana Pi. SystemCallFilter=~@mount @swap @raw-ip @resources @reboot @privileged @obsolete @module @debug @cpu-emulation @clock SystemCallFilter=chroot setuid SystemCallArchitectures=native [Install] WantedBy=multi-user.target # strangely, this alias only holds if the unit is enabled. If the unit # is disabled, the alias is not available which was kind of a surprise. Alias=bind9.service Generally, the error messages I received during the debugging phase were not very helpful. I frequently had to resort to strace -p 1 to find out what exactly went wrong trying to start named. For example, there is no exact feedback when the daemon is being terminated because of a SystemCallFilter violation, I'd like the system call in question to be part of the log. The same applies to directives regarding sandboxing, when paths are given in the directive. My way to debug was either randomly removing some of the directives to narrow down the possible error range, or stracing again to find out what my daemon tried before it was terminated. Those things might be out of scope for systemd, I simply don't know. With this unit, systemd-analyze security named is now down to "1.9 OK", I think it was > 9 with the standard unit. Thanks for your help, I wanted to give something back. I'll probably suggest this unit for the Debian package once it has reached some stability. Greetings Marc -- - Marc Haber | "I don't trust Computers. They | Mailadresse im Header Leimen, Germany| lose things."Winona Ryder | Fon: *49 6224 1600402 Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600421
Re: [systemd-devel] Securing bind with systemd methods (was: bind-mount of /run/systemd for chrooted bind9/named)
On Tue, Jul 18, 2023 at 01:10:16AM +0300, Mantas Mikulėnas wrote: > On Mon, Jul 17, 2023, 15:44 Marc Haber > wrote: > > # /lib is necessary here, or execve will fail without indication for > > # reason - that was a surprise and hard to debug because even strace > > # didnt hint me towards the real issue > > ExecPaths=/usr/sbin/named /usr/sbin/rndc /lib > > > > This one in particular is not a systemd issue: I never claimed it to be. > All dynamically linked > binaries are executed through /lib/ld-linux*.so as their "interpreter". > (`file` will show the exact path.) I wish that had a dedicated errno, > though. That would be /usr/lib/x86_64-linux-gnu/ld-linux-x86-64.so.2 on my system (only output of find /lib /usr/lib -name 'ld-lin*'), and adding that to ExecPaths doesnt allow my Executable to run. So it must be something else (possibly in addition). Greetings Marc -- ----- Marc Haber | "I don't trust Computers. They | Mailadresse im Header Leimen, Germany| lose things."Winona Ryder | Fon: *49 6224 1600402 Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600421
Re: atop package
On Thu, Dec 14, 2023 at 11:10:14AM +0530, jai wrote: > *root@dummyhost:~# systemctl status atopacct.service● atopacct.service - > Atop process accounting daemon Loaded: loaded > (/lib/systemd/system/atopacct.service; enabled; vendor preset: enabled) > Active: failed (Result: protocol) since Thu 2023-12-14 12:10:00 WIB; 49s > ago Docs: man:atopacctd(8)Dec 14 12:10:00 smartpesantren2 systemd[1]: > Starting Atop process accounting daemon...Dec 14 12:10:00 smartpesantren2 > atopacctd[367437]: /run/pacct_shadow.d: File existsDec 14 12:10:00 > smartpesantren2 systemd[1]: atopacct.service: Can't open PID file > /run/atopacctd.pid (yet?) after start: No such file or directoryDec 14 > 12:10:00 smartpesantren2 systemd[1]: atopacct.service: Failed with result > 'protocol'.Dec 14 12:10:00 smartpesantren2 systemd[1]: Failed to start Atop > process accounting daemon.* This formatting is completely mangled, what are you doing there? > The systemctl status shows error that /run/atopacctd.pid is missing. > I executed "ln -s /run/atop.pid /run/atopacctd.pid" to create symlink of > atopacctd.pid from atop.pid and then restarted the atopacct.service which > fixed the problem. atop and atopacctd are different daemons that happen to come from the same package. Symlinking one pidfile to the other is like to cause other problems than the one you seem to "solve". > But is this the proper way to solve this issue? The proper way would be to ask the maintainers of the atop package you're using, and not to complain on the _development_ mailing list of a nearly unrelated upstream project. It would at least help if you mention the version of the package you're using. Greetings Marc P.S.: I happen to be the maintainer of the atop package in Debian, the distribution that Ubuntu uses as a technical base. The package you're using is likely to closely resemble what I built for Debian, but I never saw that kind of misbehavior. -- - Marc Haber | "I don't trust Computers. They | Mailadresse im Header Leimen, Germany| lose things."Winona Ryder | Fon: *49 6224 1600402 Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600421
Re: [systemd-devel] How to ensure a systemd unit waits for ntpd to sync before starting?
On Tue, Apr 02, 2019 at 10:17:26AM +0200, Lennart Poettering wrote: > Well packaged NTP servers should have a separate .service unit that > waits until an NTP sync is reached. For example, systemd's own > systemd-timesyncd.service comes with a companion > systemd-time-wait-sync.service that does this. systemd-time-wait-sync.service invokes /lib/systemd/systemd-time-wait-sync do to the actual wait, which is an ELF binary. While this is a valid approach to do this, an interested used will now need to download the systemd souces, unpack them, search for the source for the binary just to find out what this service actually does. To adapt it to wait for something else, one needs to whack out a compiler. IMO, this is a classic case of "doing this scripted is way easier and more flexible". Please consider for the future. Greetings Marc -- ----- Marc Haber | "I don't trust Computers. They | Mailadresse im Header Leimen, Germany| lose things."Winona Ryder | Fon: *49 6224 1600402 Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600421 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] How to ensure a systemd unit waits for ntpd to sync before starting?
On Tue, Apr 02, 2019 at 12:32:58PM +0200, Lennart Poettering wrote: > I thought people have noticed by now that systemd is really about > removing unnecessary shell scripts from all clean system boot > codepaths. The problem is that millions of professional systems administrators do violently disagree. I have seen unit files full of bash -c and quoting hell. Your work. Be proud of it. Greetings Marc -- ----- Marc Haber | "I don't trust Computers. They | Mailadresse im Header Leimen, Germany| lose things."Winona Ryder | Fon: *49 6224 1600402 Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600421 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] networkd - how to (partially) manage OpenVPN interfaces?
Hi, when I run an OpenVPN interface, OpenVPN manages the interface itself: It handles creation, destruction and assignment of the IP address. The IP address can be controlled by the remote site, so the OpenVPN daemon is kind of the only thing that can configured the Interface. I would, however, like systemd-resolved to ask DNS servers that are reachable over the VPN for certain domains, such as ka51.zugschlus.de. Dumping a tun0.network containing: [Match] Name=tun0 [Network] Domains=~ka51.zugschlus.de DNS=2a01:238:4071:3281::35:100 DNS=2a01:238:4071:328e::35:100 DHCP=no IPv6AcceptRA=no into /e/s/n doesn't work since that clears up the IP addresses that OpenVPN has correctly assigned. Can I have the advantages of systemd-resolved on an Interface that is not fully managed by systemd-networkd? Greetings Marc -- - Marc Haber | "I don't trust Computers. They | Mailadresse im Header Leimen, Germany| lose things."Winona Ryder | Fon: *49 6224 1600402 Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600421 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] networkd - how to (partially) manage OpenVPN interfaces?
Hi, On Mon, Sep 16, 2019 at 12:54:23PM +0200, Marc Haber wrote: > when I run an OpenVPN interface, OpenVPN manages the interface itself: > It handles creation, destruction and assignment of the IP address. The > IP address can be controlled by the remote site, so the OpenVPN daemon > is kind of the only thing that can configured the Interface. > > I would, however, like systemd-resolved to ask DNS servers that are > reachable over the VPN for certain domains, such as ka51.zugschlus.de. > > Dumping a tun0.network containing: > [Match] > Name=tun0 > > [Network] > Domains=~ka51.zugschlus.de > DNS=2a01:238:4071:3281::35:100 > DNS=2a01:238:4071:328e::35:100 > DHCP=no > IPv6AcceptRA=no > > into /e/s/n doesn't work since that clears up the IP addresses that > OpenVPN has correctly assigned. No hints? Is this behavior - maybe - a bug? Greetings Marc -- ----- Marc Haber | "I don't trust Computers. They | Mailadresse im Header Leimen, Germany| lose things."Winona Ryder | Fon: *49 6224 1600402 Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600421 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] networkd - how to (partially) manage OpenVPN interfaces?
Hi Susant, On Wed, Sep 25, 2019 at 05:56:23PM +, Susant Sahani wrote: > On 22/09/19, 5:35 PM, "systemd-devel on behalf of Marc Haber" > mh+systemd-de...@zugschlus.de> wrote: > On Mon, Sep 16, 2019 at 12:54:23PM +0200, Marc Haber wrote: > > when I run an OpenVPN interface, OpenVPN manages the interface itself: > > It handles creation, destruction and assignment of the IP address. The > > IP address can be controlled by the remote site, so the OpenVPN daemon > > is kind of the only thing that can configured the Interface. > > > > I would, however, like systemd-resolved to ask DNS servers that are > > reachable over the VPN for certain domains, such as ka51.zugschlus.de. > > > > Dumping a tun0.network containing: > > [Match] > > Name=tun0 > > > > [Network] > > Domains=~ka51.zugschlus.de > > DNS=2a01:238:4071:3281::35:100 > > DNS=2a01:238:4071:328e::35:100 > > DHCP=no > > IPv6AcceptRA=no > > > > into /e/s/n doesn't work since that clears up the IP addresses that > > OpenVPN has correctly assigned. > > No hints? Is this behavior - maybe - a bug? > > Did you tried with KeepConfiguration=? That is not yet in the Man Page on my system. Is it alreay there in systemd 242? Greetings Marc -- - Marc Haber | "I don't trust Computers. They | Mailadresse im Header Leimen, Germany| lose things."Winona Ryder | Fon: *49 6224 1600402 Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600421 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] networkd - how to (partially) manage OpenVPN interfaces?
On Thu, Sep 26, 2019 at 09:16:53AM +, Susant Sahani wrote: > On 26/09/19, 11:49 AM, "Marc Haber" wrote: > > > > Did you tried with KeepConfiguration=? > > That is not yet in the Man Page on my system. Is it alreay there in > systemd 242? > > This is in 243. I'll have to wait then. Thanks. Greetings Marc -- ----- Marc Haber | "I don't trust Computers. They | Mailadresse im Header Leimen, Germany| lose things."Winona Ryder | Fon: *49 6224 1600402 Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600421 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Unit dependencies for socket activated services
Hallo, when I want a normal service to be started only after the networks is ready, I put |[Unit] |After=network-online.target |Wants=network-online.target into the service unit. Now I have a socket activated service which I know won't properly start (but claim readiness) if started before the network is ready. Would I put those two lines into foo.service or foo.socket? Grüße Marc -- -- !! No courtesy copies, please !! - Marc Haber | " Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom " | Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] disable EDNS in systemd-resolved
Hi, how would I disable EDNS in systemd-resolved? Some recursive DNS servers (for example in public hotspots) choke on queries with EDNS options. I didn't find anything about this in the systemd-resolved or resolvectl manual pages for systemd 244. Greetings Marc -- - Marc Haber | "I don't trust Computers. They | Mailadresse im Header Leimen, Germany| lose things."Winona Ryder | Fon: *49 6224 1600402 Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600421 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] disable EDNS in systemd-resolved
On Fri, Dec 27, 2019 at 11:25:20AM +0200, Mantas Mikulėnas wrote: > On Fri, Dec 27, 2019 at 10:52 AM Marc Haber > wrote: > > how would I disable EDNS in systemd-resolved? Some recursive DNS servers > > (for example in public hotspots) choke on queries with EDNS options. > > > > I don't think there is a configuration option, but resolved *should* > automatically detect lack of EDNS support (grep the system log for > "feature"). Do the queries simply time out, or do they get rejected? > > Make sure you don't have DNSSEC support set to "yes", since it depends on > EDNS. The DNS recursor of the Hotsplots network that I will use in the next three days just returns an authoritative NXDOMAIN. Yes, that's broken. I still need my system to handle the situation. Greetings Marc -- ----- Marc Haber | "I don't trust Computers. They | Mailadresse im Header Leimen, Germany| lose things."Winona Ryder | Fon: *49 6224 1600402 Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600421 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Networkd - how to augment an already configured interface
Hi, for a rather complex tunneling setup on a system that uses systemd-networkd and OpenVPN, I am trying to use networkd to augment the Interface that has been configured by OpenVPN. In OpenVPN, a daemon is started with a service unit, which connects to a remote side and creates a tunX interface and configures it according to what the other side says. The other side can push basic configuration like IP address and routes that go into the main routing table, but I need a RoutingPolicyRule and addiitonal Routes pushed into the configuration. I tried writing the following tunX.network unit: [Match] Name=tun1 [Network] Description=tun1 tunnel to old torres DHCP=no IPForward=yes IPv6AcceptRA=no [Route] Destination=0::/0 Gateway=2a01:238:4071:3202::1 Table=202 [RoutingPolicyRule] Priority=32100 From=2a01:238:4071:3280::/59 Table=202 [RoutingPolicyRule] Priority=32101 From=2a01:238:4071:32b0::/62 Table=202 but it looks like networkd wants full control over the network interface and flushes the IP addresses from the working interface, leaving it in a non-functional state. Is there any way to (a) tell networkd to just add the configuration from the unit to the already interface without cleaning up first, or (b) to have part of systemd just execute a single .network unit, probably as a sidekick unit that I can use to add configuration to my OpenVPN configuration? Or am I better off by just taking things away from systemd-networkd completely and use an "up" script from the OpenVPN configuration? Hoping for your opinions and a good discussion, cheers, Marc -- - Marc Haber | "I don't trust Computers. They | Mailadresse im Header Leimen, Germany| lose things."Winona Ryder | Fon: *49 6224 1600402 Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600421 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Networkd - how to augment an already configured interface
On Thu, Mar 12, 2020 at 06:24:48PM +, Susant Sahani wrote: > https://www.freedesktop.org/software/systemd/man/systemd.network.html#KeepConfiguration= Stupid me, I forgot that I already had this issue back last year. And I still don't have a later systemd. Please forget that I asked. Greetings Ma "this is now documented" rc -- ----- Marc Haber | "I don't trust Computers. They | Mailadresse im Header Leimen, Germany| lose things."Winona Ryder | Fon: *49 6224 1600402 Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600421 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Are Pathnames in /tmp/systemd-private-foo predictable?
Hi, I am wondering where the 32 xdigit number in pathnames like systemd-private-27aa635a15cf4da0a7ebda10f25c3950-chrony.service-9DShFi/ comes from. I always had the impression that it's the systemd/dbus machine id, but that does not seem to be the case. Is that just an arbitrary random number, or can it be predicted in a way? Greetings Marc -- - Marc Haber | "I don't trust Computers. They | Mailadresse im Header Leimen, Germany| lose things."Winona Ryder | Fon: *49 6224 1600402 Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600421 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Are Pathnames in /tmp/systemd-private-foo predictable?
On Mon, Jun 14, 2021 at 09:59:24AM +0200, Lennart Poettering wrote: > It's the boot ID, i.e. /proc/sys/kernel/random/boot_id. We include it > in the name so that we can distinguish such dirs of the current boot > from those of earlier boots (which can be retained because of abnormal > shutdown or so). In the latter case we can safely remove them to avoid > collecting left-over directories. Thanks for the explanation, I appreciate that. Greetings Marc -- ----- Marc Haber | "I don't trust Computers. They | Mailadresse im Header Leimen, Germany| lose things."Winona Ryder | Fon: *49 6224 1600402 Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600421 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Emergency mode if non-critical /etc/fstab entries are missing
On Mon, Sep 26, 2016 at 10:52:50AM +1300, Sergei Franco wrote: > The emergency mode assumes console access, which requires physical access, > which is quiet difficult if the machine is remote. It does also assume knowledge of the root password, which is in enterprise environments not often the case. Enterprises usually have root passwords stowed away in a safe, behind a three-headed guard dog, requiring management approval, and > 2 eyes mechanisms, and usually have password-changing processes attached that touch other machines sharign the same root password as well (for example because the root password hash is stamped into the golden image). Many enterprise environments that I know have their processes geared in a way that the root password is not needed in daily operation. Login via ssh key, privilege escalation via sudo. systemd requiring the root password because some tertiary file system doesn't mount is a nuisance for those environments. Some sites have resorted to adding "nofail" to all fstab lines just to find themselves with the next issue since the initramfs of some distributions doesn't know this option yet. Greetings Marc -- ----- Marc Haber | "I don't trust Computers. They | Mailadresse im Header Leimen, Germany| lose things."Winona Ryder | Fon: *49 6224 1600402 Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600421 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Emergency mode if non-critical /etc/fstab entries are missing
On Sun, Sep 25, 2016 at 08:09:20PM -0400, Dave Reisner wrote: > Making bootup potentially interactive in this manner is strictly worse > than dumping you into emergency mode. At least with emergency mode, you > might be able to add dependencies to emergency.target such that, for > example, an sshd comes up and an admin can login to the remote box. Is there an example around for doing so? This looks way interesting. Greetings Marc -- ----- Marc Haber | "I don't trust Computers. They | Mailadresse im Header Leimen, Germany| lose things."Winona Ryder | Fon: *49 6224 1600402 Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600421 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Emergency mode if non-critical /etc/fstab entries are missing
On Thu, Nov 03, 2016 at 10:55:35PM +0100, Lennart Poettering wrote: > On Mon, 26.09.16 07:02, Marc Haber (mh+systemd-de...@zugschlus.de) wrote: > > On Mon, Sep 26, 2016 at 10:52:50AM +1300, Sergei Franco wrote: > > > The emergency mode assumes console access, which requires physical access, > > > which is quiet difficult if the machine is remote. > > > > It does also assume knowledge of the root password, which is in > > enterprise environments not often the case. Enterprises usually have > > root passwords stowed away in a safe, behind a three-headed guard dog, > > requiring management approval, and > 2 eyes mechanisms, and usually > > have password-changing processes attached that touch other machines > > sharign the same root password as well (for example because the root > > password hash is stamped into the golden image). > > > > Many enterprise environments that I know have their processes geared > > in a way that the root password is not needed in daily operation. > > Login via ssh key, privilege escalation via sudo. > > > > systemd requiring the root password because some tertiary file system > > doesn't mount is a nuisance for those environments. > > > > Some sites have resorted to adding "nofail" to all fstab lines just to > > find themselves with the next issue since the initramfs of some > > distributions doesn't know this option yet. > > "nofail" has been around as long as fstab has been around really. It's > not a systemd invention. I cannot say anything about that, I don't have any non-systemd machines left. However, that machines stop booting and require the root password is a totally new experience for me that came with systemd. Greetings Marc -- - Marc Haber | "I don't trust Computers. They | Mailadresse im Header Leimen, Germany| lose things."Winona Ryder | Fon: *49 6224 1600402 Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600421 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Emergency mode if non-critical /etc/fstab entries are missing
On Sun, Nov 06, 2016 at 09:28:59AM +0300, Andrei Borzenkov wrote: > 1. The behavior that if filesystem from /etc/fstab fails to mount, boot > is stopped and administrator intervention is required existed long > before systemd. I have never seen this. > 2. Password is requested not by systemd, but by command that it starts > to present shell. Default is sulogin. You are free to override it with > anything you want, including /bin/sh. Again, sulogin was often default > in this case before systemd as well. Yes, that right. Before the systemd era, systems usually continued to boot in case (1) until they hit something hard and unmoving. systemd systems stop voluntarily. Greetings Marc -- ----- Marc Haber | "I don't trust Computers. They | Mailadresse im Header Leimen, Germany| lose things."Winona Ryder | Fon: *49 6224 1600402 Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600421 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] How to disable Predictable Network Interface Names using a drop-in?
On Fri, Jan 20, 2017 at 02:51:00PM +, Patrick Schleizer wrote: > I've learned about the kernel parameter and symlink ways to disable > predictable network interface names. What would be the "symlink way"? Will predictable network names still play nice with the old udev way? I cannot make my brain remember that my notebook has enp0s25 and wlp3s0, and would like to have eth0 and wlan0 again (or net0 and net1, or wired0 and wless0, if it is a bad idea to move the interfaces back to the kernel namespaces), while keeping the advantage of having predictable network names for USB network interfaces that I regularly plug in as well. Will placing a /etc/udev/rules.d/70-persistent-network.rules that renames enp0s25 to wired0 and wlp3s0 to wless0 play nice, it is that asking for trouble? Greetings Marc -- ----- Marc Haber | "I don't trust Computers. They | Mailadresse im Header Leimen, Germany| lose things."Winona Ryder | Fon: *49 6224 1600402 Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600421 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] How to disable Predictable Network Interface Names using a drop-in?
On Mon, Feb 06, 2017 at 09:56:30PM +0100, Lennart Poettering wrote: > On Sat, 21.01.17 21:20, Marc Haber (mh+systemd-de...@zugschlus.de) wrote: > > On Fri, Jan 20, 2017 at 02:51:00PM +, Patrick Schleizer wrote: > > > I've learned about the kernel parameter and symlink ways to disable > > > predictable network interface names. > > > > What would be the "symlink way"? > > Linking the relevant .link file to /dev/null in /etc. What if there is no .link file and the Interfaces just come up as enp8s0 and wlp2s0 > However, if you pick your own names outside of the kernel's > namespaces, then all is good, and that's actually what we > recommend. (Though I'd do it by dropping in some .link files with the > right [Match] sections to make this happen, not bother with udev > rules, but either works) [2/5147]mh@swivel:~ $ cat /etc/systemd/network/lanc0.link [Match] MACAddress=f0:de:f1:b0:03:20 [Link] Name=lanc0 [3/5148]mh@swivel:~ $ ip --oneline link show | grep f0:de:f1:b0:03:20 2: enp0s25: mtu 1500 qdisc pfifo_fast state DOWN mode DEFAULT group default qlen 1000\link/ether f0:de:f1:b0:03:20 brd ff:ff:ff:ff:ff:ff [4/5149]mh@swivel:~ $ My ethernet is still enp0s25, what am I doing wrong? Greetings Marc -- - Marc Haber | "I don't trust Computers. They | Mailadresse im Header Leimen, Germany| lose things."Winona Ryder | Fon: *49 6224 1600402 Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600421 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] How to disable Predictable Network Interface Names using a drop-in?
Hi, On Mon, Feb 20, 2017 at 05:42:19PM +0100, Lennart Poettering wrote: > On Mon, 20.02.17 17:38, Lennart Poettering (lenn...@poettering.net) wrote: > > Consider naming the file 50-lanc0.link or so, so that it takes > > precedence over 99-default.link if that's shipped by your distro. If > > it isn't, please contact your downstream distro for help (see above). > > BTW, all of the above is documented in systemd.link(5). My > recommendation is always to check the documentation first. Just to put and end to this, with proper numbering things are just fine now. Having this part ot systemd working in lexical order was just a surprise, I didn't expect that. Btw, the word "link" is multiply used in IT, so one can expect people to think of the wrong meaning of the word if one uses it without more explanation. Greetings Marc -- ----- Marc Haber | "I don't trust Computers. They | Mailadresse im Header Leimen, Germany| lose things."Winona Ryder | Fon: *49 6224 1600402 Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600421 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] systemd-networkd and openvswitch?
Hi, is there any possibility to nicely integrate openvswitch to a system that runs systemd-networkd? While I understand that there does not currrently seem to be native openvswitch support in systemd-networkd, maybe somebody has written unit files to bring up the openvswitch before systemd-networkd kicks in? The reason I am trying to do this is that openvswitch is advertised as being capable to switch an entire dot1q VLAN trunk through to a VM, something that a standard Linux bridge doesn't seem to do. Any comments about this? Greetings Marc -- - Marc Haber | "I don't trust Computers. They | Mailadresse im Header Leimen, Germany| lose things."Winona Ryder | Fon: *49 6224 1600402 Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600421 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-networkd and openvswitch?
Hi Richard, thanks for your insights. In the mean time, I was successful in bridging an VLAN trunk to a VM with the native linux bridge, and thus do not need Openvswich in my project any more. Your mail will be helpful to others in the future. ftr, one needs to define the VLANs on the hosts as well, and the VLAN definition needs to be on the _bridge_, not the ethernet. I guess that the Linux bridge code uses the VLANs defined on the bridge as kind of VLAN filter for the poor. Greetings Marc -- - Marc Haber | "I don't trust Computers. They | Mailadresse im Header Leimen, Germany| lose things."Winona Ryder | Fon: *49 6224 1600402 Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600421 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [ANNOUNCE] Git development moved to github
On Tue, Jun 09, 2015 at 01:02:43PM +0200, Lennart Poettering wrote: > On Mon, 01.06.15 22:43, Michael Biebl (mbi...@gmail.com) wrote: > > > 2015-06-01 20:12 GMT+02:00 David Herrmann : > > > Hi > > > > > > As of today we've disabled git-push to fd.o. The official development > > > git repository is now at github [1]. > > > > What about the bug tracker? Will it remain at fdo's bugzilla. I have > > to admit I'm not a huge fan of github's bug tracker. > > I am not a fan of bz either... > > I think for now we prefer github, but will leave bz open, and we will > not migrate bugs. As it looks at the moment, freedesktop.org doesnt want new bugs to be filed in their Bugzilla. At least it is no longer possible to open new bugzilla requests for systemd there. Would you prefer bugzilla requests to be moved over to github issues by people interested in those requests/issues being addressed, or do old bugzilla requests have the same chance of being looked at by somebody able to address them as github issues? Greetings Marc -- - Marc Haber | "I don't trust Computers. They | Mailadresse im Header Leimen, Germany| lose things."Winona Ryder | Fon: *49 6224 1600402 Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600421 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] How to properly write an "umbrella" unit
Hi, I am trying to systemd'ize a daemon which is useful to be run in two instances. It is usually the case that both instances need to be started and stopped simultaneously, and the local admin would want a _single_ command to start and stop both instances. Therefore, an "umbrella" is needed. As a beginner, I have written: nifty.target: [Unit] Description=nifty Server (all protocols) After=network.target [Install] WantedBy=multi-user.target nifty-v4.service: [Unit] Description=nifty Server for IPv4 (niftyd4.conf) After=network.target PartOf=nifty.target [Service] ExecStart=/usr/sbin/niftyd -f -4 -q -cf /etc/nifty/niftyd4.conf [Install] WantedBy=nifty.target nifty-v6.service: [Unit] Description=nifty Server for IPv6 After=network.target PartOf=nifty.target [Service] ExecStart=/usr/sbin/niftyd -f -6 -q -cf /etc/nifty/niftyd6.conf [Install] WantedBy=nifty.target This works as designed. Unfortunately, my Distribution's build tools don't handle package-provided targets too well, and I feel that using a target here is kind of wrong anyway. Can I write my nifty.target as a service? I have seen in this case nifty.service files with Exec=/bin/true to basically create a no-op service, but that's ugly. If I move my service to a nifty@.service, how would I start two instances from a single shell command? How would one handle this situation in the clear, recommended way? Greetings Marc -- ----- Marc Haber | "I don't trust Computers. They | Mailadresse im Header Leimen, Germany| lose things."Winona Ryder | Fon: *49 6224 1600402 Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600421 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] How to properly write an "umbrella" unit
Hi Alexandre, thanks for your fast answer and correctly guessing my Distribution ,-) On Tue, Jul 21, 2015 at 02:13:12PM +0200, Alexandre Detiste wrote: > Le mardi 21 juillet 2015, 13:43:48 Marc Haber a écrit : > > This works as designed. Unfortunately, my Distribution's build tools > > don't handle package-provided targets too well, and I feel that using > > a target here is kind of wrong anyway. > > Hi, > > Package-provided targets works well, > but by default debhelper will try to enable everything. In my case, dh_systemd_enable doesn't install the file: dh_systemd_enable --verbose -pisc-dhcp-server --name=isc-dhcp-server.target echo "# Automatically added by dh_systemd_enable">> debian/isc-dhcp-server.postinst.debhelper sed "s/#UNITFILE#/isc-dhcp-server-v6.service/" /usr/share/debhelper/autoscripts/postinst-systemd-enable >> debian/isc-dhcp-server.postinst.debhelper echo '# End automatically added section' >> debian/isc-dhcp-server.postinst.debhelper echo "# Automatically added by dh_systemd_enable">> debian/isc-dhcp-server.postinst.debhelper sed "s/#UNITFILE#/isc-dhcp-server-v4.service/" /usr/share/debhelper/autoscripts/postinst-systemd-enable >> debian/isc-dhcp-server.postinst.debhelper echo '# End automatically added section' >> debian/isc-dhcp-server.postinst.debhelper echo "# Automatically added by dh_systemd_enable">> debian/isc-dhcp-server.postinst.debhelper sed "s/#UNITFILE#/isc-dhcp-server-v4-old.service/" /usr/share/debhelper/autoscripts/postinst-systemd-enable >> debian/isc-dhcp-server.postinst.debhelper echo '# End automatically added section' >> debian/isc-dhcp-server.postinst.debhelper echo "# Automatically added by dh_systemd_enable"> debian/isc-dhcp-server.postrm.debhelper.new sed "s/#UNITFILES#/isc-dhcp-server-v6.service isc-dhcp-server-v4.service isc-dhcp-server-v4-old.service/" /usr/share/debhelper/autoscripts/postrm-systemd >> debian/isc-dhcp-server.postrm.debhelper.new echo '# End automatically added section' >> debian/isc-dhcp-server.postrm.debhelper.new cat debian/isc-dhcp-server.postrm.debhelper >> debian/isc-dhcp-server.postrm.debhelper.new mv debian/isc-dhcp-server.postrm.debhelper.new debian/isc-dhcp-server.postrm.debhelper (grep -s -v misc:Depends debian/isc-dhcp-server.substvars; echo "misc:Depends=debconf (>= 0.5) | debconf-2.0, init-system-helpers (>= 1.18~)") > debian/isc-dhcp-server.substvars.new mv debian/isc-dhcp-server.substvars.new debian/isc-dhcp-server.substvars dh_installinit -Nisc-dhcp-server install -d debian/isc-dhcp-relay/etc/init.d install -p -m755 debian/isc-dhcp-relay.init.d debian/isc-dhcp-relay/etc/init.d/isc-dhcp-relay echo "# Automatically added by dh_installinit">> debian/isc-dhcp-relay.postinst.debhelper sed "s/#SCRIPT#/isc-dhcp-relay/;s/#INITPARMS#/defaults/;s/#ERROR_HANDLER#/exit \$?/" /usr/share/debhelper/autoscripts/postinst-init >> debian/isc-dhcp-relay.postinst.debhelper echo '# End automatically added section' >> debian/isc-dhcp-relay.postinst.debhelper echo "# Automatically added by dh_installinit">> debian/isc-dhcp-relay.prerm.debhelper sed "s/#SCRIPT#/isc-dhcp-relay/;s/#INITPARMS#/defaults/;s/#ERROR_HANDLER#/exit \$?/" /usr/share/debhelper/autoscripts/prerm-init >> debian/isc-dhcp-relay.prerm.debhelper echo '# End automatically added section' >> debian/isc-dhcp-relay.prerm.debhelper echo "# Automatically added by dh_installinit"> debian/isc-dhcp-relay.postrm.debhelper.new sed "s/#SCRIPT#/isc-dhcp-relay/;s/#INITPARMS#/defaults/;s/#ERROR_HANDLER#/exit \$?/" /usr/share/debhelper/autoscripts/postrm-init >> debian/isc-dhcp-relay.postrm.debhelper.new echo '# End automatically added section' >> debian/isc-dhcp-relay.postrm.debhelper.new cat debian/isc-dhcp-relay.postrm.debhelper >> debian/isc-dhcp-relay.postrm.debhelper.new mv debian/isc-dhcp-relay.postrm.debhelper.new debian/isc-dhcp-relay.postrm.debhelper dh_installinit -pisc-dhcp-server --error-handler=true #dh_systemd_start isc-dhcp-server.target and dh_systemd_enable's code specialcasing service, socket, and tmpfile, but not target, gave me the impression that target files are unsupported. My debian/rules is: override_dh_installinit: dh_systemd_enable -pisc-dhcp-server --name=isc-dhcp-server-v4 dh_systemd_enable -pisc-dhcp-server --name=isc-dhcp-s
Re: [systemd-devel] How to properly write an "umbrella" unit
On Tue, Jul 21, 2015 at 01:40:31PM +0100, Colin Guthrie wrote: > In this case, I'd perhaps recommend NOT including [Install] sections fir > your two .service files and instead make your "make install" action > write symlinks into /usr/lib/systemd/system/nifty.target.wants.d/ thus > the user could never disable the individual components of your daemon > themselves and thus not need to rely on distro scripts to create them at > install time. No, I'd like to give the local admin an option to disable parts of course. My work is about choice and robustness. Greetings Marc -- ----- Marc Haber | "I don't trust Computers. They | Mailadresse im Header Leimen, Germany| lose things."Winona Ryder | Fon: *49 6224 1600402 Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600421 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] How to properly write an "umbrella" unit
On Tue, Jul 21, 2015 at 02:20:39PM +0100, Dimitri John Ledkov wrote: > And then people can do e.g.: > systemctl enable nifty@4.service nifty@6.service > systemctl start nifty@*.service > systemctl stop nifty@*.service As I mentioned in my original mail, this is explictly not wanted, as most users will have to start and stop both instances together. We cannot make our lives simpler at the cost of our users. And yes, this is true for both systemd upstream and software packagers, a transitive relationship. Greetings Marc -- ----- Marc Haber | "I don't trust Computers. They | Mailadresse im Header Leimen, Germany| lose things."Winona Ryder | Fon: *49 6224 1600402 Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600421 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] How to properly write an "umbrella" unit
On Tue, Jul 21, 2015 at 09:42:38PM +0200, Michael Biebl wrote: > Have a look at the openvpn package in Debian. It implements something > like you have in mind. > There are multiple openvpn@.service instances and a single > openvpn.service which can be used by the admin to start/stop/restart > them. That uses a generator, which is somewhat oversized for the question at hand. And it's a service with ExecStart=/bin/true which is a hackish workaround. But if that's the way to go, I'm fine with it. Greetings Marc -- ----- Marc Haber | "I don't trust Computers. They | Mailadresse im Header Leimen, Germany| lose things."Winona Ryder | Fon: *49 6224 1600402 Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600421 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Policy Routing on a machine using systemd-networkd
Hi, I would like to do policy routing on a router with ~ 10 interfaces running Debian Linux and systemd. Networking is managed with ferm and systemd-networkd. I now need Policy Routing. What is the recommended way to handle the usual knot of iptables, ip rule and ip route statement in a clear and beautiful way in a systemd environment? As far as I know, systemd-network has not yet implemented policy routing, so the canonical way (for me, as a systemd newbie) to implement this would be a sysv init script containing the needed commands. What would be the "correct" way to do this in a systemd setup? Actually, I need something that does the following: o prevent a default route from being present in the main table (either by preventing it from being set in the first place or removing it idempotently) o Establish a number of iptables rules to set fwmarks o Establish a number of extra routing tables with a set of rules o Establish a number of ip rule rules regarding source IP ranges or fwmarks. How would I do that in systemd? Am I doing ok with a Type=oneshot service unit with a bunch of ExecStart Options? Or is there another recommended way? Greetings Marc -- - Marc Haber | "I don't trust Computers. They | Mailadresse im Header Leimen, Germany| lose things."Winona Ryder | Fon: *49 6224 1600402 Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600421 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Query regarding "EnvironmentFile"
On Fri, Dec 18, 2015 at 05:00:32PM +0100, Michael Biebl wrote: > and then tell admin to use systemctl edit > [Unit] > Environment=OPTS=-baz How would I do the equivalent of systemctl edit with a declarative configuration management tool like puppet? Greetings Marc -- ----- Marc Haber | "I don't trust Computers. They | Mailadresse im Header Leimen, Germany| lose things."Winona Ryder | Fon: *49 6224 1600402 Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600421 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Query regarding "EnvironmentFile"
On Tue, Dec 15, 2015 at 05:59:11PM +, Simon Peeters wrote: > Why not do like normal people and use configmanagement to put the > right apache config on the right host? > This whole "-D testserver" and "" looks like an > ugly workaround for a lacking configmanagment system. And what is your business in deliberately breaking those ugly setups? If you want to educate people, be a teacher. If you want to bully people into doing things your way, be a team leader. Greetings Marc -- ----- Marc Haber | "I don't trust Computers. They | Mailadresse im Header Leimen, Germany| lose things."Winona Ryder | Fon: *49 6224 1600402 Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600421 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Query regarding "EnvironmentFile"
On Fri, Dec 11, 2015 at 03:59:54PM +0100, Reindl Harald wrote: > EnvironmentFile is a great way to make units flexible with sane > defaults and i am *not* talking about upstream or distributions here > > so taking away that option gains you nothing but breaks things for > no valid reason - it would only confirm people which hesitate to > adopt systemd because the fear that they can't rely on capabilities > it brings now because they may flippantly disappear Amen. Greetings Marc -- ----- Marc Haber | "I don't trust Computers. They | Mailadresse im Header Leimen, Germany| lose things."Winona Ryder | Fon: *49 6224 1600402 Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600421 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Query regarding "EnvironmentFile"
On Sun, Dec 20, 2015 at 02:34:15PM +0100, Tomasz Torcz wrote: > On Sun, Dec 20, 2015 at 02:30:30PM +0100, Marc Haber wrote: > > On Fri, Dec 18, 2015 at 05:00:32PM +0100, Michael Biebl wrote: > > > and then tell admin to use systemctl edit > > > [Unit] > > > Environment=OPTS=-baz > > > > How would I do the equivalent of systemctl edit with a declarative > > configuration management tool like puppet? > > You have to make sure directory /etc/systemd/system/nfs-ganesha.service.d/ > exists, then inside you create something.conf file with above content. Is that the documented interface equivalent to systemctl edit? Does the stability promise apply? > Afterwards you need to issue "systemctl daemon-reload" (or send signal > to PID1) to have the changes read. That's a regression over the old-fashioned way, but doable. Greetings Marc -- - Marc Haber | "I don't trust Computers. They | Mailadresse im Header Leimen, Germany| lose things."Winona Ryder | Fon: *49 6224 1600402 Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600421 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Policy Routing on a machine using systemd-networkd
*nudge* Is there really no option about this rather common issue? Greetings Marc On Tue, Dec 15, 2015 at 01:20:34PM +0100, Marc Haber wrote: > I would like to do policy routing on a router with ~ 10 interfaces > running Debian Linux and systemd. Networking is managed with ferm and > systemd-networkd. > > I now need Policy Routing. What is the recommended way to handle the > usual knot of iptables, ip rule and ip route statement in a clear and > beautiful way in a systemd environment? > > As far as I know, systemd-network has not yet implemented policy > routing, so the canonical way (for me, as a systemd newbie) to > implement this would be a sysv init script containing the needed > commands. > > What would be the "correct" way to do this in a systemd setup? > > Actually, I need something that does the following: > > o prevent a default route from being present in the main table (either > by preventing it from being set in the first place or removing it > idempotently) > o Establish a number of iptables rules to set fwmarks > o Establish a number of extra routing tables with a set of rules > o Establish a number of ip rule rules regarding source IP ranges or > fwmarks. > > How would I do that in systemd? Am I doing ok with a Type=oneshot > service unit with a bunch of ExecStart Options? Or is there another > recommended way? -- - Marc Haber | "I don't trust Computers. They | Mailadresse im Header Leimen, Germany| lose things."Winona Ryder | Fon: *49 6224 1600402 Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600421 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Query regarding "EnvironmentFile"
On Mon, Dec 21, 2015 at 10:18:05PM +0100, Kai Krakow wrote: > Thus: Please maintainers and developers, remove it. Do not let Lennart > remove this useful option to force others into removing your shitty > cruft. This is exactly why systemd is the top one most hated piece of open source software. We are not here to be educated about the one and only right way of doing things. Unix used to be about choice. Too bad that we allowed this to be no longer the case. Linux is no longer about choice. Linux nowadays is about what the systemd people want. Too bad that we gave the systemd people the power of forcing us to run our systems their way. Man kann manchmal echt nicht genug essen wie man in dieser Welt kotzen möchte. Merry Christmas. -- ----- Marc Haber | "I don't trust Computers. They | Mailadresse im Header Leimen, Germany| lose things."Winona Ryder | Fon: *49 6224 1600402 Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600421 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Query regarding "EnvironmentFile"
On Mon, Dec 21, 2015 at 11:14:43PM +0100, Kai Krakow wrote: > I cannot see anything here in the thread which would disallow continue > using non-systemd installations. The problem is that many concepts of systemd are really nice. Once wants to have things like that. The problem is that a minoriy of concepts and the attitude of the makers make working with systemd a constant source of increased blood pressure and a strong urge to break something expensive just to get rid of the aggression. -- - Marc Haber | "I don't trust Computers. They | Mailadresse im Header Leimen, Germany| lose things."Winona Ryder | Fon: *49 6224 1600402 Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600421 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Thoughts about /etc/crypttab keyscript options
Hi, I was recently bitten by the issue that systemd does not support the keyscript= option in /etc/crypttab. I don't know whether keyscript= is a Debian extension, but the migration to systemd (which was pulled in by some new version of - I think - Network Manager) broke my system's boot process, leaving me with all my filesystems locked since already the root fs used to be unlocked by a keyscript. I have read the thread (from 2012?) where those things were discussed here and I understand that I should replace my keyscript with a passwort agent. Things would then work like this: (1) systemd would try to unlock the root file system and place a ask.xxx file in /run/systemd/ask-password (2) All running PasswordAgents (including my, non-interactive one and all interactive ones) would act on that ask.xxx file. (3) The interactive password agents would present an interactive password request. (4) My PasswordAgent indicates taking responsibility by unlinking the ask.xxx file from /run/systemd/ask-password. The interactive password agents will remove their interactive requests then. The user will therefore see the password request popping up for a very short period of time, if at all. (5) Should my PasswordAgent need a password to act itself (like a PIN for a hardware device, for example), it would place its own ask.xxx file in /run/systemd/ask-password. The interactive PasswordAgents would act on that, obtain the password/PIN interactively from the user and return it to my PasswordAgent. (6) My PasswordAgent would then obtain the password for the file system itself and return it to systemd which can now proceed to unlock the file system. Am I understanding things correctly so far? If so, this leaves the task to write "my" PasswordAgent. I have found some example code in python for a password agent. To use this to unlock the root fs, an entire python installation would need to go in my initramfs, right? And if I want to keep things simple, the best idea would be to write my PasswordAgent in a compiled language which would only need the binary and its libs in the initramfs, right? Is there code for an example PasswordAgent in C++ which I can use as a template? I am quite reluctant to write a program which needs to to complex string processing and is bound to run as root in C because my C experience is somewhat lacking. Can you please recommend a way to allow me to migrate to systemd? Without keyscript= being supported in /etc/crypttab, I need to replace my 50 line key script written in POSIX shell and would like to keep things simple. Thank you very much for your consideration. Greetings Marc -- ----- Marc Haber | "I don't trust Computers. They | Mailadresse im Header Leimen, Germany| lose things."Winona Ryder | Fon: *49 621 31958061 Nordisch by Nature | How to make an American Quilt | Fax: *49 621 31958062 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Thoughts about /etc/crypttab keyscript options
Hi, did I reach the wrong mailing list? Is there better forum to get systemd working with something resembling my current setup? Greetings Marc On Mon, Jul 21, 2014 at 10:46:21AM +0200, Marc Haber wrote: > From: Marc Haber > Subject: Thoughts about /etc/crypttab keyscript options > To: systemd-devel@lists.freedesktop.org > Date: Mon, 21 Jul 2014 10:46:21 +0200 > User-Agent: Mutt/1.5.21 (2010-09-15) > > Hi, > > I was recently bitten by the issue that systemd does not support the > keyscript= option in /etc/crypttab. I don't know whether keyscript= is > a Debian extension, but the migration to systemd (which was pulled in > by some new version of - I think - Network Manager) broke my system's > boot process, leaving me with all my filesystems locked since already > the root fs used to be unlocked by a keyscript. > > I have read the thread (from 2012?) where those things were discussed > here and I understand that I should replace my keyscript with a > passwort agent. Things would then work like this: > > (1) > systemd would try to unlock the root file system and place a ask.xxx > file in /run/systemd/ask-password > > (2) > All running PasswordAgents (including my, non-interactive one and > all interactive ones) would act on that ask.xxx file. > > (3) > The interactive password agents would present an interactive password > request. > > (4) > My PasswordAgent indicates taking responsibility by unlinking the > ask.xxx file from /run/systemd/ask-password. The interactive password > agents will remove their interactive requests then. The user will > therefore see the password request popping up for a very short period > of time, if at all. > > (5) > Should my PasswordAgent need a password to act itself (like a PIN for > a hardware device, for example), it would place its own ask.xxx file > in /run/systemd/ask-password. The interactive PasswordAgents would > act on that, obtain the password/PIN interactively from the user and > return it to my PasswordAgent. > > (6) > My PasswordAgent would then obtain the password for the file system > itself and return it to systemd which can now proceed to unlock the > file system. > > > Am I understanding things correctly so far? > > > If so, this leaves the task to write "my" PasswordAgent. I have found > some example code in python for a password agent. > > To use this to unlock the root fs, an entire python installation would > need to go in my initramfs, right? And if I want to keep things > simple, the best idea would be to write my PasswordAgent in a compiled > language which would only need the binary and its libs in the > initramfs, right? > > Is there code for an example PasswordAgent in C++ which I can use as a > template? I am quite reluctant to write a program which needs to to > complex string processing and is bound to run as root in C because my > C experience is somewhat lacking. > > Can you please recommend a way to allow me to migrate to systemd? > Without keyscript= being supported in /etc/crypttab, I need to replace > my 50 line key script written in POSIX shell and would like to keep > things simple. > > Thank you very much for your consideration. > > Greetings > Marc > > -- > - > Marc Haber | "I don't trust Computers. They | Mailadresse im Header > Leimen, Germany| lose things."Winona Ryder | Fon: *49 621 31958061 > Nordisch by Nature | How to make an American Quilt | Fax: *49 621 31958062 -- - Marc Haber | "I don't trust Computers. They | Mailadresse im Header Leimen, Germany| lose things."Winona Ryder | Fon: *49 6224 1600402 Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600420 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Thoughts about /etc/crypttab keyscript options
On Wed, Aug 13, 2014 at 06:42:13PM +0200, Lennart Poettering wrote: > On Wed, 13.08.14 16:43, Marc Haber (mh+systemd-de...@zugschlus.de) wrote: > > did I reach the wrong mailing list? Is there better forum to get > > systemd working with something resembling my current setup? > > No, this is the right place. But I just have a huge backlog of threads > to reply to on the ML. I am slowly working on catching up now, in > preparation for a new release. Ok, I'll sit back quietly ;-) Maybe somebody else cares to comment? Greetings Marc -- ----- Marc Haber | "I don't trust Computers. They | Mailadresse im Header Leimen, Germany| lose things."Winona Ryder | Fon: *49 6224 1600402 Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600420 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Thoughts about /etc/crypttab keyscript options
Hi Lennart, thanks for your thoughts. On Thu, Aug 14, 2014 at 07:44:59PM +0200, Lennart Poettering wrote: > On Mon, 21.07.14 10:46, Marc Haber (mh+systemd-de...@zugschlus.de) wrote: > > (4) > > My PasswordAgent indicates taking responsibility by unlinking the > > ask.xxx file from /run/systemd/ask-password. The interactive password > > Well, so far it is the querier that removes the file, not the agent... I see. What would happen if I remove the file myself? > > To use this to unlock the root fs, an entire python installation would > > need to go in my initramfs, right? And if I want to keep things > > simple, the best idea would be to write my PasswordAgent in a compiled > > language which would only need the binary and its libs in the > > initramfs, right? > > Yes. Correct. If you want to stick something into the initrd, I'd always > do things in C (or shell if you must), but nothing else. > > > Is there code for an example PasswordAgent in C++ which I can use as a > > template? I am quite reluctant to write a program which needs to to > > complex string processing and is bound to run as root in C because my > > C experience is somewhat lacking. > > Not aware of an C++ code. There's a vala one, and of course the one we > ship in systemd itself in C, but c++ i cannot help you with, sorry. Is it possible to write a PasswordAgent in shell? Example code please ;) > > Can you please recommend a way to allow me to migrate to systemd? > > Without keyscript= being supported in /etc/crypttab, I need to replace > > my 50 line key script written in POSIX shell and would like to keep > > things simple. > > > > Thank you very much for your consideration. > > I fear I don#t have an easy suggestion. What kind of device do you > actually want to make work here? some smartcard or so? That's the vision, yes. At the moment, my keyscript unlocks a small LUKS partition on the disk and takes the key for the root fs from there. That's just a placeholder for a future more complicated setup. With Debian's initramfs, unlocking the small LUKS partition works transparently even with plymouth. This is real functionality being lost in the systemd migration. > I think in the long run we should somehow work towards the direction to > make things like that just work, for common devices like smartcards and > other auth tokens... First step to do that would be to implement support for the keyscript= option in /etc/crypttab as this is the canonical place to hook into on non-system systems. At least it's the case on Debian, I don't know about Red Hat, Fedora and other distributions. The PasswordAgent stuff is really neat, but complicated due to the socket communication, and it's far from being a drop-in replacement. Greetings Marc -- - Marc Haber | "I don't trust Computers. They | Mailadresse im Header Leimen, Germany| lose things."Winona Ryder | Fon: *49 6224 1600402 Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600420 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Thoughts about /etc/crypttab keyscript options
Hi, On Thu, Aug 14, 2014 at 08:09:05PM +0200, David Herrmann wrote: > That is, to solve your problem, I'd recommend to make systemd allow > external scripts like "keyscript=" before placing *.ask files (or some > other hookup or configuration, if scripts are not suitable for that). If systemd would support keyscript=, migration would be painless. I am absolutely in favor of that ;-) Greetings Marc, unfortunately too bad a C programmer to write a patch -- ----- Marc Haber | "I don't trust Computers. They | Mailadresse im Header Leimen, Germany| lose things."Winona Ryder | Fon: *49 6224 1600402 Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600420 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Thoughts about /etc/crypttab keyscript options
On Thu, Aug 14, 2014 at 08:18:10PM +0200, Lennart Poettering wrote: > On Thu, 14.08.14 20:10, Marc Haber (mh+systemd-de...@zugschlus.de) wrote: > > > Not aware of an C++ code. There's a vala one, and of course the one we > > > ship in systemd itself in C, but c++ i cannot help you with, sorry. > > > > Is it possible to write a PasswordAgent in shell? Example code please > > ;) > > Probably possible, after all bash allows you to talk to unix sockets and > stuff. And you could probably put the protocol together with carefully > crafted echo lines, but I know of nobody who has done that so far... There is also the daemonizing and inotify part... > > > I fear I don#t have an easy suggestion. What kind of device do you > > > actually want to make work here? some smartcard or so? > > > > That's the vision, yes. At the moment, my keyscript unlocks a small > > LUKS partition on the disk and takes the key for the root fs from > > there. That's just a placeholder for a future more complicated setup. > > Not following. You place a key for a LUKS partition on another LUKS > partition? What's the benefit of that? Inception? ;-) It's actually part of a two-factor-authentification for the poor. The part to know is the key to the LUKS parition, the part to have is an USB key. The key script hashes part of the key found on the USB key and part of the key found on the LUKS partition on the hard disk together to build the actual key to unlock the root fs. I use this scheme for so long that I don't even remember why I implemented it this way, but I guess it was because the logic to unlock a LUKS fs from initramfs was already in place and could be used as-is to unlock the key-part-holding LUKS partition instead of the actual root fs that it was intended for. But I also know of people who use a keyscript to unlock LUKS file systems with the key stored in the system's TPM or on a crypto card. I have never looked into the details of those implementations (having that saved for a long winter night), but I guess that those people will also be pretty hosed on a systemd-based Debian. > > First step to do that would be to implement support for the keyscript= > > option in /etc/crypttab as this is the canonical place to hook into on > > non-system systems. At least it's the case on Debian, I don't know > > about Red Hat, Fedora and other distributions. > > Well, I am really not convinced that this is a well-defined > interface. Even in your case you have to wait for two devices at least, > right? a synchronous shell callout won't solve that for you since > there's no guarantee that the second LUKS device has already shown up, > or am I missing something? It may be possible that /etc/crypttab is processed sequentially which would obviously not be the case with systemd. So you have a point here. > As mentioned we really should redesign the whole thing around the kernel > keyring anyway, I am really conservative in adding support for Debian's > keyscript thingy upstream now. (That of course shouldn't stop Debian > from adding this downstream) It didn't occur to me that /etc/crypttab's keyscript= option was a Debianism. I educated myself in the mean time. I'm going to yell at the Debian systemd team now ;-) > > The PasswordAgent stuff is really neat, but complicated due to the > > socket communication, and it's far from being a drop-in replacement. > > Well, it's really easy in C I figure, but admittedly not in shell... It would be significantly easier if there were boilerplate code to derive from. To a non-adept programmer, adapting the boilerplate would probably lead to enough buffer overflow vulnerabilities anyway ;-) Greetings Marc -- - Marc Haber | "I don't trust Computers. They | Mailadresse im Header Leimen, Germany| lose things."Winona Ryder | Fon: *49 6224 1600402 Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600420 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Thoughts about /etc/crypttab keyscript options
On Fri, Aug 15, 2014 at 01:30:32PM +0200, Lennart Poettering wrote: > On Fri, 15.08.14 12:56, Marc Haber (mh+systemd-de...@zugschlus.de) wrote: > > > > Is it possible to write a PasswordAgent in shell? Example code please > > > > ;) > > > > > > Probably possible, after all bash allows you to talk to unix sockets and > > > stuff. And you could probably put the protocol together with carefully > > > crafted echo lines, but I know of nobody who has done that so far... > > > > There is also the daemonizing and inotify part... > > > > > > > I fear I don#t have an easy suggestion. What kind of device do you > > > > > actually want to make work here? some smartcard or so? > > > > > > > > That's the vision, yes. At the moment, my keyscript unlocks a small > > > > LUKS partition on the disk and takes the key for the root fs from > > > > there. That's just a placeholder for a future more complicated setup. > > > > > > Not following. You place a key for a LUKS partition on another LUKS > > > partition? What's the benefit of that? Inception? ;-) > > > > It's actually part of a two-factor-authentification for the poor. The > > part to know is the key to the LUKS parition, the part to have is an > > USB key. > > The part to have is trivially easy to copy, so why do the excercise > at all? Sounds more like theatre to me... Because I still hope to have that in a more secure way in the near future. > > But I also know of people who use a keyscript to unlock LUKS file > > systems with the key stored in the system's TPM or on a crypto card. I > > have never looked into the details of those implementations (having > > that saved for a long winter night), but I guess that those people > > will also be pretty hosed on a systemd-based Debian. > > I think supporting TPM or smartcards out of the box is very desirable to > have upstream. Yes, and that should be done in a modular way so that even exotic (or broken) schemes can be plugged in. > I am not convinced though that Debian's keyscript= logic is really > that well designed that I want to update it upstream. You don't need to. I falsely thought that this was general functionality and not a Debianism. Greetings Marc -- - Marc Haber | "I don't trust Computers. They | Mailadresse im Header Leimen, Germany| lose things."Winona Ryder | Fon: *49 6224 1600402 Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600420 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Need Advice about MaxConnections on ssh.socket
Hi, I am using ssh.socket to invoke ssh servers. What is not running cannot fail: [Unit] Description=OpenBSD Secure Shell server socket Before=ssh.service Conflicts=ssh.service ConditionPathExists=!/etc/ssh/sshd_not_to_be_run [Socket] ListenStream=22 Accept=yes [Install] WantedBy=sockets.target One of my systems is rather frequently target of scans, which the socket unit doesn't like. Here an excerpt from the log: Feb 11 02:42:40 gancho systemd[1]: Started OpenBSD Secure Shell server per-connection daemon (221.229.220.180:38738). Feb 11 02:42:42 gancho systemd[1]: ssh@10262-85.214.162.66:22-221.229.220.180:38738.service: Succeeded. Feb 11 02:42:52 gancho systemd[1]: ssh.socket: Too many incoming connections (64), dropping connection. (repeat 135 (sic!) times) Feb 11 02:42:52 gancho systemd[1]: ssh.socket: Trigger limit hit, refusing further activation. Feb 11 02:42:52 gancho systemd[1]: ssh.socket: Failed with result 'trigger-limit-hit'. Feb 11 02:42:52 gancho systemd[1]: Started OpenBSD Secure Shell server per-connection daemon (2.57.122.26:56488). (repeat 63 times) Feb 11 02:42:53 gancho systemd[1]: ssh@10285-85.214.162.66:22-2.57.122.26:56106.service: Succeeded. (repeat 63 times) The machine is one of my older boxes, running Debian oldoldstable with systemd 241. I have cross-checked systemd.socket(5) with more recent systemd versions, and the rate limiting configuration with MaxConnections= isn't documented differently in current systemd versions. I see the same issue on systems running a recent systemd version as well. MaxConnections=: The maximum number of connections to simultaneously run services instances for, when Accept=yes is set. If more concurrent connections are coming in, they will be refused until at least one existing connection is terminated. This setting has no effect on sockets configured with Accept=no or datagram sockets. Defaults to 64. Actual behavior looks a bit different: Once the socket unit has failed with "trigger-limit-hit", the socket doesn't listen any more and manual intervention is needed, restarting the socket unit, before one is able to log in again. In this case, this was possible since the machine has LOM, but not all my machines have that. Am I reading the documentation wrong? If I understand the manpage correctly, the issue is supposed to reset itself and the socket is supposed to listen again. That does not seem to be the case, I think the ssh.socket unit is into a permanently failed state. Can systemd be configured to reset the unit automatically after, for example, two hours? I'd rather not have a dedicated timer unit to reset the socket every second hour. I would love to hear your opinion. Greetings Marc -- ----- Marc Haber | "I don't trust Computers. They | Mailadresse im Header Leimen, Germany| lose things."Winona Ryder | Fon: *49 6224 1600402 Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600421
Re: [systemd-devel] Generators, Targets and Stater Units - I am holding it wrong?
On Mon, Jun 23, 2025 at 12:47:35AM +0200, Nils Kattenbeck wrote: it has been a while since working with generators but I think the correct solution is to ensure that the system-presets are configured such that you generated units are enabled by default. Debian for example has a fallback which applies a default preset of disabled for all units unless specifically listed as enabled-by-default So you are suggesting that I use, for example, a 50-console-log.preset which has a single line "enable console-log.target"? What would that preset to when the target is not there? Greetings Marc -- - Marc Haber | "I don't trust Computers. They | Mailadresse im Header Leimen, Germany| lose things."Winona Ryder | Fon: *49 6224 1600402 Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600421
[systemd-devel] Generators, Targets and Stater Units - I am holding it wrong?
Hi, the following works, but I doubt that it is a nice way to do it. I have a generator that generates a number of service, and I want all of those services automatically started at boot. I have: $ sudo systemctl cat console-log-8.service [sudo] password for mh on hover: # /run/systemd/generator/console-log-8.service # generated by console-log.generator [Unit] Description=page tty8 After=console-log.target [Service] ... [Install] WantedBy=console-log.target $ sudo systemctl cat console-log-9.service # /run/systemd/generator/console-log-9.service # generated by console-log.generator [Unit] Description=page tty9 After=console-log.target [Service] ... [Install] WantedBy=console-log.target $ sudo systemctl cat console-log.target # /run/systemd/generator/console-log.target # generated by console-log.generator [Unit] Description=Pull in all console-log units After=multi-user.target Wants=console-log-9-var-log-syslog-syslog.service Wants=console-log-8-var-log-exim4-mainlog.service [Install] WantedBy=multi-user.target $ sudo systemctl cat console-log-starter.service # /etc/systemd/system/console-log-starter.service [Unit] Description=Start console-log.target at boot After=multi-user.target [Service] Type=oneshot ExecStart=/bin/systemctl start console-log.target RemainAfterExit=yes [Install] WantedBy=multi-user.target $ The console-log-starter.service is the only persistent thing, all others are generated (including the target since the target lists all generated services). So I cannot enable them. The console-log-starter.service is the first unit that I can actually enable. When I search on the Internet I read that the generator should generate "the Wanted" Symlinks itself, but the docs also say that the generator can't write outside its target directories. And I don't have a clue which symlinks I am supposed to generate in the generator. And in the running system I don't see any symlinks regarding my units other than the /etc/systemd/system/multi-user.target.wants/console-log-starter.service -> /etc/systemd/system/console-log-starter.service one that was generated when I enabled the start service. Am I supposed to ln -s /etc/systemd/system/console-log-8.service /etc/systemd/system/multi-user.target.wants/console-log-8.service and ln -s /etc/systemd/system/console-log-9.service /etc/systemd/system/multi-user.target.wants/console-log-9.service? How am I supposed to do this correctly? Or is my entire approach wrong? Greetings Marc -- ----- Marc Haber | "I don't trust Computers. They | Mailadresse im Header Leimen, Germany| lose things."Winona Ryder | Fon: *49 6224 1600402 Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600421
Re: [systemd-devel] Generators, Targets and Stater Units - I am holding it wrong?
On Mon, Jun 23, 2025 at 09:16:58AM +0300, Andrei Borzenkov wrote: /run/systemd/generator/console-log-starter.service.wants/console-log-9.service -> /run/systemd/generator/console-log-9.service So your recommendation is to do away with the target, keep the enabled static starter.service and add the want symlinks from the generator? Greetings Marc -- ----- Marc Haber | "I don't trust Computers. They | Mailadresse im Header Leimen, Germany| lose things."Winona Ryder | Fon: *49 6224 1600402 Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600421
Re: [systemd-devel] Generators, Targets and Stater Units - I am holding it wrong?
On Mon, Jun 23, 2025 at 09:34:34AM +0300, Andrei Borzenkov wrote: 23.06.2025 09:28, Marc Haber wrote: On Mon, Jun 23, 2025 at 09:16:58AM +0300, Andrei Borzenkov wrote: /run/systemd/generator/console-log-starter.service.wants/console-log-9.service -> /run/systemd/generator/console-log-9.service So your recommendation is to do away with the target, keep the enabled static starter.service and add the want symlinks from the generator? I was answering the "generators are not allowed to write in /etc". Thank you for pointing out this misunderstanding on my side. I appreciate that. Do you also have a recommendation about the best way to reach my goal of my units to be started automatically on system boot? Greetings Marc -- ----- Marc Haber | "I don't trust Computers. They | Mailadresse im Header Leimen, Germany| lose things."Winona Ryder | Fon: *49 6224 1600402 Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600421
Re: [systemd-devel] Generators, Targets and Stater Units - I am holding it wrong?
Hi Lennart, thank you for trying to help. tl;dr setting the symlinks accomplishes the intended behavior. On Mon, Jun 23, 2025 at 01:27:24PM +0200, Lennart Poettering wrote: On So, 22.06.25 22:30, Marc Haber (mh+systemd-de...@zugschlus.de) wrote: I am not sure I follow. What are you trying to do? Do you want that the service units you generated are automatically activated at boot without any further admin step? Yes. The admin step is putting the configuration into the file that the generator reads. It is a reimplementation of my first Debian package, console-log, leveraging systemd's flexibility instead of putting everything in an initscript on steroids (that was back in 2000) that allows you to have a less syslog on tty9 and a less maillog on tty8, for example. Or do you want that there's an explicit enablement step the user has to do via "systemctl enable"? No. If you do not want that extra step, then just do create a symlink from the service units you generate (which you generate into one of the thre params that a generator gets passed via argv[], let's call the one you picked $TARGET) to the multi-user.target.wants/ subdir. i.e. add something like this to your generator code: mkdir -p $TARGET/multi-user.target.wants ln -s ../console-log-8.service $TARGET/multi-user.target.wants/console-log-8.service ln -s ../console-log-9.service $TARGET/multi-user.target.wants/console-log-9.service Did that, works fine. Thanks. But then again I really don't grok what you are trying to do, maybe I misread your intentions entirely. No, you didn't. This was very helpful. The documentation in systemd.generator(7) is a bit terse in that regard. I am not sure whether one can assume that a person reading this can makes sense from "the usual .wants/ and .requires/ symlinks". That part of systemd is usually abstracted away via the systemctl enable interface so people might use systemd daily and still not have the fact that this is controlled by symlinks in the filesystem on their radar. I'd add a few more words to that regard any maybe even an example. Greetings Marc -- ----- Marc Haber | "I don't trust Computers. They | Mailadresse im Header Leimen, Germany| lose things."Winona Ryder | Fon: *49 6224 1600402 Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600421
Re: [systemd-devel] How to lock two instances of a templated service against each other
On Tue, Jul 29, 2025 at 10:20:31AM +0100, Barry Scott wrote: Is it possible to use After= or Before= in template services to order them? Wouldnt that make them just start all at once? Greetings Marc -- - Marc Haber | "I don't trust Computers. They | Mailadresse im Header Leimen, Germany| lose things."Winona Ryder | Fon: *49 6224 1600402 Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600421
[systemd-devel] How to lock two instances of a templated service against each other
Hi, I have a template service unit which runs a oneshot service that generates both high CPU and high I/O load for a couple of minutes. The service is templated a couple of times and runs from an, also templated timer. In another use case, I have independent services that generate high CPU and high I/O. In both cases, it has been measured that total processing time is quicker when one lets the jobs run one after the other instead of having them conurrently compete over same set of resources. The measurement results are even more clear when the data is stored on HDDs due to head movement and disk rotation latency. I would like to lock them against each other that only one of those services runs concurrently at a time, and other instances that might have been requested while one is still running are delayed until everyhing is "free". Missing a job because one other is already running would be a bug. The solution one finds on the net is to use flock(1) in the ExecStart* options, often making wrapper scripts necessary. I find this clumsy and un-systemd-like and would not like to do that. Does systemd offer a better solution for this? Greetings Marc -- - Marc Haber | "I don't trust Computers. They | Mailadresse im Header Leimen, Germany| lose things."Winona Ryder | Fon: *49 6224 1600402 Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600421
Re: [systemd-devel] How to lock two instances of a templated service against each other
On Tue, Jul 29, 2025 at 11:05:38AM +0100, Luca Boccassi wrote: https://www.freedesktop.org/software/systemd/man/devel/systemd.slice.html#ConcurrencySoftMax= That looks really interesting. Sadly, my favorite distribution will release its next stable version in two weeks with systemd 257, so this particular thing which was added in systemd 258 will most likely not be available for me for a while. And, frankly, I think YOU know that. That being said, I currently don't make much sense from this future documentation. Would I need to refer to all my service units in my .slice file or can a service assign itself to a slice from its own unit? Greetings Marc -- - Marc Haber | "I don't trust Computers. They | Mailadresse im Header Leimen, Germany| lose things."Winona Ryder | Fon: *49 6224 1600402 Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600421
Re: [systemd-devel] How to lock two instances of a templated service against each other
Hi, On Wed, Jul 30, 2025 at 08:28:34PM +0100, Barry Scott wrote: On 30 Jul 2025, at 09:00, Marc Haber wrote: I find the entire Before/After and Wants/Requires incredibly powerful but also hard to grasp. I am not a newbie to systemd but this is something that I have not fully understood yet. The description in `man systemd.unit` seem to describe these accurately. Have you read that man page? I take offense from the implications that come from your answer and refrain from engaging further. -- - Marc Haber | "I don't trust Computers. They | Mailadresse im Header Leimen, Germany| lose things."Winona Ryder | Fon: *49 6224 1600402 Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600421
Re: [systemd-devel] How to lock two instances of a templated service against each other
Hi, On Wed, Jul 30, 2025 at 07:31:56AM +0300, Andrei Borzenkov wrote: 29.07.2025 11:30, Marc Haber wrote: Hi, I have a template service unit which runs a oneshot service that generates both high CPU and high I/O load for a couple of minutes. The service is templated a couple of times and runs from an, also templated timer. In another use case, I have independent services that generate high CPU and high I/O. It is unclear what you want I apologize for not making myself clear. Let me try doing this with "traditional" things. I have a unknown number of processes that would be one-shot services in systemd lingo. Some of them are equal but differently parametrized, others are completely different. I want only one of the to run at at time, and if another one wants to start while one is still running, I want the new one to wait. In the classic way all those services would know the path to a shared lock and run with flock(1) --exclusive with a very high value for --timeout. This is probably what I'll do with my systemd 257 system. I think that the new systemd 258 slice semantics might help, but I won't have that for a few years. So I'll probably use the flock thing in ExecStart. From what I understand, in Before=/After= you need to know what the processes are and you need to define an order in which they'll run. That's not what I want. But I might have misunderstood that and would appreciate an example of what the suggestion is. I find the entire Before/After and Wants/Requires incredibly powerful but also hard to grasp. I am not a newbie to systemd but this is something that I have not fully understood yet. Greetings Marc -- ----- Marc Haber | "I don't trust Computers. They | Mailadresse im Header Leimen, Germany| lose things."Winona Ryder | Fon: *49 6224 1600402 Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600421
