Re: [systemd-devel] How does the mount process of systemd-homed work?
Hello Jörg, On 24/09/2019 11:16, Jörg Kastning wrote: > Hello to Lennart and this list, > > I watched the recording of Lennarts talk at the All Systems Go > (https://cfp.all-systems-go.io/ASG2019/talk/VSQRXA/) and would like to > ask some questions about the new way to process user home directoties > and authentication. [snip] > Lennart said there is plenty of documentation about the JSON struct. I > didn't find any on the Internet. Could you please point my nose to it? Code and documentation are here https://github.com/poettering/systemd/tree/homed I think that all your questions are answered by the documentation. Cheers, Dan ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] org.freedesktop.systemd1.manage-units - which unit?
In JS-based polkit rules, the action usually comes with 'unit' and 'verb'
polkit variables -- according to src/core/dbus-unit.c:
if (action.id == "org.freedesktop.systemd1.manage-unit" &&
action.lookup("unit") == "foo.service") { return polkit.Result.YES; }
In older polkit versions which use .pkla rules, variables are not available
at all.
On Thu, Sep 26, 2019 at 6:15 PM Ian Pilcher wrote:
> I am writing a PolicyKit rule to allow a non-root user to restart a
> service (via D-bus). It looks like this will be the
> org.freedesktop.systemd1.manage-units "action", but I can't see a way to
> determine *which* unit is being managed (or what the action is - start/
> stop/restart/reload).
>
> Are there any variables associated with this action that my rule can
> use? If not, is there any way to give a particular user permission to
> perform only some actions on only some units?
>
> Thanks!
>
> --
>
> Ian Pilcher arequip...@gmail.com
> "I grew up before Mark Zuckerberg invented friendship"
>
>
> ___
> systemd-devel mailing list
> systemd-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/systemd-devel
--
Mantas Mikulėnas
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Empty /sys/fs/cgroup/cpu directory post reboot
Hello Tarana. On Wed, Sep 11, 2019 at 12:17:51PM +, " TARANA, YASHASHVI " wrote: > I noticed that, once, after reboot, the directory /sys/fs/cgroup/cpu > was empty. The directories for indvidual cgroups are only created based on demand (the directory path suggests you use the legacy or hybrid hierarchy). Any unit which requires some of the CPU controller functionality will trigger building of the hierarchy. By contrast, if there is no such unit, systemd will not bother creating the directories for the CPU hierarchy. > However, after rebooting again, it once again had the original > contents. It seems that the latter boot must have started a unit that wasn't active before and that required the CPU controller. HTH, Michal signature.asc Description: Digital signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] org.freedesktop.systemd1.manage-units - which unit?
I am writing a PolicyKit rule to allow a non-root user to restart a service (via D-bus). It looks like this will be the org.freedesktop.systemd1.manage-units "action", but I can't see a way to determine *which* unit is being managed (or what the action is - start/ stop/restart/reload). Are there any variables associated with this action that my rule can use? If not, is there any way to give a particular user permission to perform only some actions on only some units? Thanks! -- Ian Pilcher arequip...@gmail.com "I grew up before Mark Zuckerberg invented friendship" ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Make systemd-localed modify the kernel commandline for the initrd keymap?
Hello Hans, Thanks for starting this discussion. Looking at this from a Fedora/Dracut POV, I think we should look at this as the start of implementing a configuration-only initramfs, (something Matthew Garret has been advocating for a while) rather than making this a vconsole.conf/plymouth specific solution. On Thu, Sep 26, 2019 at 12:43 PM Hans de Goede wrote: > Hi, > > On 26-09-2019 11:53, Michael Chapman wrote: > > On Thu, 26 Sep 2019, Hans de Goede wrote: > >> Hi, > >> > >> On 26-09-2019 11:10, Michael Chapman wrote: > >>> On Thu, 26 Sep 2019, Hans de Goede wrote: > >>> [...] > I believe that the best alternative is to have localed append / update > a rd.vconsole.keymap=foo argument to the kernel commandline, to > override > the vconsole.conf KEYMAP setting, but only in the initrd (so that > later > runtime changes when booted still work). > > The way I see this working is that localed does a read-modify-write of > all the BLS .conf files under /boot/loader/entries and updates their > "options" line to have rd.vconsole.keymap=foo appended or updated if > already present.Hi, > >>> > >>> To be honest, I really do think having the initrd rebuilt completely > is a > >>> better approach... but I do not think localed should be directly > >>> responsible for that. > >> > >> As I already mentioned there are 2 issues with rebuilding the initrd: > >> > >> 1) It might break booting the system and, assuming we rebuild the initrd > >> for all installed kernels on a locale change, then their will not be > >> an older one to fallback to as there normally is, which is BAD. > >> > >> 2) We are moving (and in case of rpmostree based distros already > shipping) > >> to pre-generated (on the distros buildsys) initrds, which likely will > >> also be signed. > >> > >> How do you propose to solve these 2 issues? > > > > Hmm, these are good points. I do like the idea of using a > > locally-generated overlay initrd though. > > Ok, looking at: > https://github.com/fedora-silverblue/issue-tracker/issues/3 > > It seems that this might be the preference of the silverblue > developers too and Javier also seems to favor that, so I guess > the first thing to do is to give that approach a try. > > I've added a comment to: > https://github.com/fedora-silverblue/issue-tracker/issues/3 > asking the silverblue devs to confirm that the overlay initramfs > is still their preferred approach, once that is confirmed I will > give this a try by manually creating on overlay initramfs and then > we will see from there. > > Regards, > > Hans > > -- Alberto Ruiz Engineering Manager - Desktop Hardware Enablement Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Make systemd-localed modify the kernel commandline for the initrd keymap?
Hi, On 26-09-2019 11:53, Michael Chapman wrote: On Thu, 26 Sep 2019, Hans de Goede wrote: Hi, On 26-09-2019 11:10, Michael Chapman wrote: On Thu, 26 Sep 2019, Hans de Goede wrote: [...] I believe that the best alternative is to have localed append / update a rd.vconsole.keymap=foo argument to the kernel commandline, to override the vconsole.conf KEYMAP setting, but only in the initrd (so that later runtime changes when booted still work). The way I see this working is that localed does a read-modify-write of all the BLS .conf files under /boot/loader/entries and updates their "options" line to have rd.vconsole.keymap=foo appended or updated if already present.Hi, To be honest, I really do think having the initrd rebuilt completely is a better approach... but I do not think localed should be directly responsible for that. As I already mentioned there are 2 issues with rebuilding the initrd: 1) It might break booting the system and, assuming we rebuild the initrd for all installed kernels on a locale change, then their will not be an older one to fallback to as there normally is, which is BAD. 2) We are moving (and in case of rpmostree based distros already shipping) to pre-generated (on the distros buildsys) initrds, which likely will also be signed. How do you propose to solve these 2 issues? Hmm, these are good points. I do like the idea of using a locally-generated overlay initrd though. Ok, looking at: https://github.com/fedora-silverblue/issue-tracker/issues/3 It seems that this might be the preference of the silverblue developers too and Javier also seems to favor that, so I guess the first thing to do is to give that approach a try. I've added a comment to: https://github.com/fedora-silverblue/issue-tracker/issues/3 asking the silverblue devs to confirm that the overlay initramfs is still their preferred approach, once that is confirmed I will give this a try by manually creating on overlay initramfs and then we will see from there. Regards, Hans ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Make systemd-localed modify the kernel commandline for the initrd keymap?
On Thu, 26 Sep 2019, Hans de Goede wrote: > Hi, > > On 26-09-2019 11:10, Michael Chapman wrote: > > On Thu, 26 Sep 2019, Hans de Goede wrote: > > [...] > >> I believe that the best alternative is to have localed append / update > >> a rd.vconsole.keymap=foo argument to the kernel commandline, to override > >> the vconsole.conf KEYMAP setting, but only in the initrd (so that later > >> runtime changes when booted still work). > >> > >> The way I see this working is that localed does a read-modify-write of > >> all the BLS .conf files under /boot/loader/entries and updates their > >> "options" line to have rd.vconsole.keymap=foo appended or updated if > >> already present. > > > > To be honest, I really do think having the initrd rebuilt completely is a > > better approach... but I do not think localed should be directly > > responsible for that. > > As I already mentioned there are 2 issues with rebuilding the initrd: > > 1) It might break booting the system and, assuming we rebuild the initrd > for all installed kernels on a locale change, then their will not be > an older one to fallback to as there normally is, which is BAD. > > 2) We are moving (and in case of rpmostree based distros already shipping) > to pre-generated (on the distros buildsys) initrds, which likely will > also be signed. > > How do you propose to solve these 2 issues? Hmm, these are good points. I do like the idea of using a locally-generated overlay initrd though. > > There are a lot of reasons the initrd needs to be rebuilt. Changing the > > system locale is just one of them. It seems unreasonable to have every > > tool know how to append boot parameters. > > Actually there are not that many reasons, Note that all other config info > needed for the initrd, like the rootfs UUID, which raid/lvm members to > assemble, etc. is already on the kernel commandline, so it seems logical > to put the locale (which is config info) there too and pre systemd at least > Fedora was already doing this. Perhaps I've been overly eager to rebuild the initrd on my systems when changing files under /etc. I think that's because I've seen just how much Dracut copies into the initrd, and I always get the feeling that if I forget to rebuild it something will break on the next reboot... Just to pick an example, I was fiddling around with /etc/udev/rules.d files a little while ago. I just assumed I'd need to rebuild the initrd for those. Perhaps a more common example is /etc/crypttab. That certainly needs to be in the initrd if the root filesystem is encrypted. So I guess I'm already in the habit of rebuilding the initrd when modifying config in /etc that might be needed on boot, and changing the locale wouldn't be any different. > > I would be a lot happier seeing a "well-known" binary that various things > > can call to rebuild the initrd, somewhat akin to the kernel-install we > > have already. That way distributions can plug in whatever tooling they use > > for initrds (e.g. dracut, initramfs-tools, ...) > > So maybe we need a well-known binary to update the kernel-commandline ? I think that would be useful just generally. ___ 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
Re: [systemd-devel] Make systemd-localed modify the kernel commandline for the initrd keymap?
Hi, On 26-09-2019 11:10, Michael Chapman wrote: On Thu, 26 Sep 2019, Hans de Goede wrote: [...] I believe that the best alternative is to have localed append / update a rd.vconsole.keymap=foo argument to the kernel commandline, to override the vconsole.conf KEYMAP setting, but only in the initrd (so that later runtime changes when booted still work). The way I see this working is that localed does a read-modify-write of all the BLS .conf files under /boot/loader/entries and updates their "options" line to have rd.vconsole.keymap=foo appended or updated if already present. To be honest, I really do think having the initrd rebuilt completely is a better approach... but I do not think localed should be directly responsible for that. As I already mentioned there are 2 issues with rebuilding the initrd: 1) It might break booting the system and, assuming we rebuild the initrd for all installed kernels on a locale change, then their will not be an older one to fallback to as there normally is, which is BAD. 2) We are moving (and in case of rpmostree based distros already shipping) to pre-generated (on the distros buildsys) initrds, which likely will also be signed. How do you propose to solve these 2 issues? There are a lot of reasons the initrd needs to be rebuilt. Changing the system locale is just one of them. It seems unreasonable to have every tool know how to append boot parameters. Actually there are not that many reasons, Note that all other config info needed for the initrd, like the rootfs UUID, which raid/lvm members to assemble, etc. is already on the kernel commandline, so it seems logical to put the locale (which is config info) there too and pre systemd at least Fedora was already doing this. I would be a lot happier seeing a "well-known" binary that various things can call to rebuild the initrd, somewhat akin to the kernel-install we have already. That way distributions can plug in whatever tooling they use for initrds (e.g. dracut, initramfs-tools, ...) So maybe we need a well-known binary to update the kernel-commandline ? Regards, Hans ___ 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 Mark, 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. Susant -- - 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] Make systemd-localed modify the kernel commandline for the initrd keymap?
On Thu, 26 Sep 2019, Hans de Goede wrote: [...] > I believe that the best alternative is to have localed append / update > a rd.vconsole.keymap=foo argument to the kernel commandline, to override > the vconsole.conf KEYMAP setting, but only in the initrd (so that later > runtime changes when booted still work). > > The way I see this working is that localed does a read-modify-write of > all the BLS .conf files under /boot/loader/entries and updates their > "options" line to have rd.vconsole.keymap=foo appended or updated if > already present. To be honest, I really do think having the initrd rebuilt completely is a better approach... but I do not think localed should be directly responsible for that. There are a lot of reasons the initrd needs to be rebuilt. Changing the system locale is just one of them. It seems unreasonable to have every tool know how to append boot parameters. I would be a lot happier seeing a "well-known" binary that various things can call to rebuild the initrd, somewhat akin to the kernel-install we have already. That way distributions can plug in whatever tooling they use for initrds (e.g. dracut, initramfs-tools, ...) Perhaps even just a new kernel-install verb, e.g: kernel-install refresh KERNEL-VERSION [KERNEL-IMAGE] ? ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] watchdog and sd_notify between host and container systemd etc inits
Hi, I'd like to run systemd as init on host but run various containers and some of them with their own container side systemd init. Then I'd like to have sd_notify and watchdog available to check the health of the systemd init in the container. I trust the init in the container to check the health of all the services and processes running there. If systemd init in the container fails to respond to watchdog, then I'd like to restart only the container, not the whole host system. For the container systemd watchdog, I've proposed patch: https://github.com/systemd/systemd/pull/13643 Comments to the PR mention that sd_notify support would be better, but AFAIK it uses the PID of processes and thus doesn't work with another systemd init as PID 0 in the container PID namespace. Thus we inveted a simple fifo between host init and container init where container writes MACHINE and HOSTNAME as watchdog ping. This works well with a custom watchdog manager on host and systemd init in an LXC container. These don't seem to fit very well to systemd, and we'd also like to know sd_notify type things like when is the container in running state, which systemd nspawn does provide, but I have use cases also for LXC containers... So, could you provide some ideas and/or feedback how this kind of functionality could/should be implemented with systemd? Cheers, -Mikko ___ 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 Mon, Sep 16, 2019 at 2:14 PM Marc Haber wrote: > 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. > > [...] > > Can I have the advantages of systemd-resolved on an Interface that is > not fully managed by systemd-networkd? > There are post-up scripts for OpenVPN which can load DNS configuration into systemd-resolved: https://github.com/jonathanio/update-systemd-resolved https://packages.debian.org/sid/openvpn-systemd-resolved -- Mantas Mikulėnas ___ 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
