Re: [systemd-devel] bind-mount of /run/systemd for chrooted bind9/named
Hi Marc, why is it suggested to run `named` within its own chroot? For security reasons? This can be achieved much easier with systemd native options. Something like `/etc/systemd/system/named.service` ```ini [Unit] Description=Internet domain name server After=network.target [Service] Type=notify User=named DynamicUser=true ExecStart=/usr/bin/named -f -c /etc/named/named.conf ExecReload=/usr/bin/kill -HUP $MAINPID NoExecPaths=/ ExecPaths=/usr/bin/named /usr/bin/kill AmbientCapabilities=CAP_NET_BIND_SERVICE ProtectSystem=full ProtectHome=yes RuntimeDirectory=%p StateDirectory=%p CacheDirectory=%p LogsDirectory=%p ConfigurationDirectory=%p [Install] WantedBy=multi-user.target ``` Make sure `directory` in `/etc/named/named.conf` points to `/var/lib/named`. Further security considerations may apply. Testing is necessary. BR Silvio
[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] PAMName=login, systemctl stop
On 03.07.2023 14:17, Lennart Poettering wrote: On Mo, 03.07.23 10:58, Valentijn Sessink (valent...@sessink.nl) wrote: Now my remaining question is probably so very basic, that you sort of missed it: my "session" is started from a script and so I'm probably able to stop all services in the session from within this script - if I knew how to find "it": "it" being "the thing to stop", i.e. "my own session" or something like that. I.e. the script should kill itself and all its children. logind's session ID you'll find in the $XDG_SESSION_ID env var. you can use this to kill your own session: loginctl kill-session $XDG_SESSION_ID It is not defined here on Ubuntu 22.04 with GNOME 42 that is using systemd for session management. It *is* defined in GDM session worker, but as actual session processes are not children of it (they are started by systemd) this variable is not inherited. if you want to know which systemd unit your process belongs to use: ps --pid $$ -o unit= Lennart -- Lennart Poettering, Berlin
Re: [systemd-devel] PAMName=login, systemctl stop
On Mo, 03.07.23 10:58, Valentijn Sessink (valent...@sessink.nl) wrote: > Now my remaining question is probably so very basic, that you sort of missed > it: my "session" is started from a script and so I'm probably able to stop > all services in the session from within this script - if I knew how to find > "it": "it" being "the thing to stop", i.e. "my own session" or something > like that. I.e. the script should kill itself and all its children. logind's session ID you'll find in the $XDG_SESSION_ID env var. you can use this to kill your own session: loginctl kill-session $XDG_SESSION_ID if you want to know which systemd unit your process belongs to use: ps --pid $$ -o unit= Lennart -- Lennart Poettering, Berlin
Re: [systemd-devel] PAMName=login, systemctl stop
Hi Lennart, hi list, On 03-07-2023 10:47, Lennart Poettering wrote: I can get the CGroup and session scope with "systemctl status "; but I still can't figure out what to stop then. So how can I finish this "spawned off" session - the one that started from a "PAMName=login" option in the service file? I am not sure I grok your question. From your answer I'd guess you did. But we do not provide a way currently to associate session scope units with the service units they have been created by. There's no nice way to go from one to ther other. OK, that's important information. Now my remaining question is probably so very basic, that you sort of missed it: my "session" is started from a script and so I'm probably able to stop all services in the session from within this script - if I knew how to find "it": "it" being "the thing to stop", i.e. "my own session" or something like that. I.e. the script should kill itself and all its children. Would that be possible? I simply don't know how to "find my own session and kill it" from within my own session - and I wouldn't know how to stop it either. To rephrase: how should a session commit suicide if it really wants to? ;-) Does that help? (Or is the answer "no you can't - seek help" ;-) Best regards, Valentijn
Re: [systemd-devel] PAMName=login, systemctl stop
On Fr, 30.06.23 15:11, Valentijn Sessink (valent...@sessink.nl) wrote: > Hi, > > On 28-06-2023 18:04, Lennart Poettering wrote: > > > "PAMName=login", then starts a script and a few (old X11 related) > > > programs. > [...]>> Is there a way to amend the service file to stop these children? > > Not really, from systemd's PoV they are part of the login session, not > > the original service anymore. > > I have tried to get my head around this but I couldn't find how to proceed, > i.e. how to kill of the session. > > I can get the CGroup and session scope with "systemctl status "; > but I still can't figure out what to stop then. So how can I finish this > "spawned off" session - the one that started from a "PAMName=login" option > in the service file? I am not sure I grok your question. But we do not provide a way currently to associate session scope units with the service units they have been created by. There's no nice way to go from one to ther other. You can terminate service units via "systemctl stop", and you can terminate session scope units the same way, but there's no mechanism to relate one to the other. And I am not sure that's even unconditionally desirable, because typically scopes and the services they are spawned from might have different lifecycles, i.e. the sessions are fine with surviving if the invoking service dies. Lennart -- Lennart Poettering, Berlin
