[systemd-devel] How to autoconfigure IPv4 LinkLocalAddressing
Hi, I’m using systemd_254. I my ".network" configuration file (see below), I'm expecting that the “mul0” interface will always be assigned an IPv4 link local address. The documentation for LinkLocalAddressing describes: > An IPv4 link-local address is configured when yes or ipv4 and when DHCPv4 > autoconfiguration has been unsuccessful for some time. I don't run a DHCP Client on this interface and RFC3927 (last paragraph p.8) states it should be independent of DHCP: > The assignment of an IPv4 Link-Local address on an interface is > based solely on the state of the interface, and is independent > of any other protocols such as DHCP. How do I autoconfigure an IPv4 link local address on this interface? FWIW: In case my procedure for reconfiguring is wrong, after changing the ".network" file, I run: $ networkctl reload; entworkctl reconfigure mul0; ip a show dev mul0 Here's my config file: $ networkctl cat 50-mul0.network # /lib/systemd/network/50-mul0.network [Match] Name=mul0 [Network] # DHCP=ipv4 LinkLocalAddressing=ipv4 ConfigureWithoutCarrier=true #[DHCPv4] #MaxAttempts=1 $ ip a show dev mul0 7: mul0: mtu 1500 qdisc pfifo_fast state DOWN group default qlen 1000 link/ether 00:50:b6:15:53:4d brd ff:ff:ff:ff:ff:ff altname enu1 $ networkctl status mul0 ● 7: mul0 Link File: /lib/systemd/network/99-default.link Network File: /lib/systemd/network/50-mul0.network State: no-carrier (configuring) Online state: offline Type: ether Path: platform-xhci-hcd.0.auto-usb-0:1:1.0 Driver: asix Vendor: ASIX_Elec._Corp. Model: AX88772B Alternative Names: enu1 Hardware Address: 00:50:b6:15:53:4d MTU: 1500 (max: 65535) QDisc: pfifo_fast IPv6 Address Generation Mode: none Number of Queues (Tx/Rx): 1/1 Auto negotiation: yes Speed: 100Mbps Duplex: full Port: tp Activation Policy: up Required For Online: yes Aug 31 23:28:14 sph-018-rmc systemd-networkd[3942]: mul0: DHCPv6 lease lost Aug 31 23:28:58 sph-018-rmc systemd-networkd[3942]: mul0: Reconfiguring with /lib/systemd/…ork. Aug 31 23:28:58 sph-018-rmc systemd-networkd[3942]: mul0: DHCPv6 lease lost Aug 31 23:28:58 sph-018-rmc systemd-networkd[3942]: mul0: Configuring with /lib/systemd/ne…ork. Aug 31 23:32:01 sph-018-rmc systemd-networkd[3942]: mul0: Reconfiguring with /lib/systemd/…ork. Aug 31 23:32:01 sph-018-rmc systemd-networkd[3942]: mul0: Configuring with /lib/systemd/ne…ork. Aug 31 23:50:09 sph-018-rmc systemd-networkd[3942]: mul0: Reconfiguring with /lib/systemd/…ork. Aug 31 23:50:09 sph-018-rmc systemd-networkd[3942]: mul0: Configuring with /lib/systemd/ne…ork. Aug 31 23:55:45 sph-018-rmc systemd-networkd[3942]: mul0: Reconfiguring with /lib/systemd/…ork. Aug 31 23:55:45 sph-018-rmc systemd-networkd[3942]: mul0: Configuring with /lib/systemd/ne…ork -- Thanks, Matt.
Re: [systemd-devel] [multiseat] How to make automatic ACL creation via udev "uaccess" tag work for seats other than seat0?
Am Do., 31. Aug. 2023 um 21:55 Uhr schrieb Andrei Borzenkov
:
>
> On 31.08.2023 19:22, Christian Pernegger wrote:
> There is no ID_SEAT, so this device [/dev/rfkill] ]belongs to seat0 by
> default.
It makes no sense for /dev/rfkill to belong to a specific seat,
though. GNOME at least assumes the user to have write access.
Note that while /sys/devices/virtual/misc/rfkill shows up in the
output of loginctl seat-status it cannot be attached to another seat
("Could not attach device: No such device").
Or what about /dev/kvm? Why should only seat0 have the ability to use
KVM? (It can't be attached to other seats, either.)
The dri/renderD??? device is automatically attached to the seat that
the dri/card? one is attached to (even though it isn't a child
according to the seat-status tree--funnily enough this does not happen
for the fb? device). It makes sense that the rendering bits of a card
should "belong to" the seat that has the outputs, the problem is that
this renders it inaccessible to the other seats, which it shouldn't. A
seat can access another seat's *rendering capabilities* just fine as
long as the permissions are set correctly.
Case in point, I have seat0 on a Radeon 6600, seat1 on a Zen 4
iGPU--permissions permitting, seat1 can use the dGPU for rendering as
well, AAA games included. You could argue that isn't desirable for
isolation reasons, but multiseat isn't a security measure anyway, it's
about sharing resources efficiently.
These devices have uaccess set because (all) logged-in users can, and
probably should, have access to them. Restricting them to a particular
seat may make sense for some devices, and some use cases, but it's not
a good default.
Which is why I'm asking, is there a way to make uaccess work across
seats? I'd go as far as to say this is a bug, at least for rfkill and
kvm.
I mean, the old-fashioned way, using the kvm, video, render, and
rfkill groups, works, but I like the idea of the uaccess tag
mechanism, it's more flexible, elegant (in theory).
Kind regards,
Christian Pernegger
Re: [systemd-devel] [multiseat] How to make automatic ACL creation via udev "uaccess" tag work for seats other than seat0?
On 31.08.2023 19:22, Christian Pernegger wrote: Hello, still trying to get the kinks out of my multiseat setup ... AFAICT the proper way to give local users access to devices nowadays is via udev and the "uaccess" tag: devices with this tag set should automagically get an ACL entry that gives access to users with active sessions. This works brilliantly for seat0, but not for seat1 (and above, I presume). E.g. P: /devices/virtual/misc/rfkill N: rfkill L: 0 E: DEVPATH=/devices/virtual/misc/rfkill E: SUBSYSTEM=misc E: DEVNAME=/dev/rfkill E: MAJOR=10 E: MINOR=242 E: USEC_INITIALIZED=954210 E: SYSTEMD_WANTS=systemd-rfkill.socket E: TAGS=:systemd:uaccess:seat:shared: E: CURRENT_TAGS=:systemd:uaccess:seat:shared: There is no ID_SEAT, so this device belongs to seat0 by default. At login screens: # file: dev/rfkill # owner: root # group: root user::rw- user:gdm:rw- # *** [my emph.] group::rw- mask::rw- other::rw- Logged in on seat0: At login screens: # file: dev/rfkill # owner: root # group: root user::rw- user:chris:rw- # *** ["switches" to user] group::rw- mask::rw- other::rw- Logged in on seat1 instead: # file: dev/rfkill # owner: root # group: root user::rw- user:gdm:rw- # *** [sticks to gdm] group::rw- mask::rw- other::rw- This device belongs to seat0, so it is ignored when requested to change permissions for seat1. The GNOME BT control panel doesn't work unless the logged-in user has write access to /dev/rfkill, which is how I originally came across this. But it's the same for the /dev/dri/renderD* devices. The seat to which the matching card belongs has access some other way, but the other seat does not; if you do give both seats access, both can use both cards in vulkan applications, for example. I see there are other files under /dev that have the ACL "+", looks like it's the same for them. (I wonder if that's why I can't switch virtual consoles on seat1 even though fbcon is mapped to that.) Anyway, I know I can just override the permissions or use the old group way of doing things, but I'd prefer to fix things properly. The symptoms of wrong device permissions can be insidious. You need to assign your device to the correct seat.
[systemd-devel] [multiseat] How to make automatic ACL creation via udev "uaccess" tag work for seats other than seat0?
Hello, still trying to get the kinks out of my multiseat setup ... AFAICT the proper way to give local users access to devices nowadays is via udev and the "uaccess" tag: devices with this tag set should automagically get an ACL entry that gives access to users with active sessions. This works brilliantly for seat0, but not for seat1 (and above, I presume). E.g. P: /devices/virtual/misc/rfkill N: rfkill L: 0 E: DEVPATH=/devices/virtual/misc/rfkill E: SUBSYSTEM=misc E: DEVNAME=/dev/rfkill E: MAJOR=10 E: MINOR=242 E: USEC_INITIALIZED=954210 E: SYSTEMD_WANTS=systemd-rfkill.socket E: TAGS=:systemd:uaccess:seat:shared: E: CURRENT_TAGS=:systemd:uaccess:seat:shared: At login screens: # file: dev/rfkill # owner: root # group: root user::rw- user:gdm:rw- # *** [my emph.] group::rw- mask::rw- other::rw- Logged in on seat0: At login screens: # file: dev/rfkill # owner: root # group: root user::rw- user:chris:rw- # *** ["switches" to user] group::rw- mask::rw- other::rw- Logged in on seat1 instead: # file: dev/rfkill # owner: root # group: root user::rw- user:gdm:rw- # *** [sticks to gdm] group::rw- mask::rw- other::rw- The GNOME BT control panel doesn't work unless the logged-in user has write access to /dev/rfkill, which is how I originally came across this. But it's the same for the /dev/dri/renderD* devices. The seat to which the matching card belongs has access some other way, but the other seat does not; if you do give both seats access, both can use both cards in vulkan applications, for example. I see there are other files under /dev that have the ACL "+", looks like it's the same for them. (I wonder if that's why I can't switch virtual consoles on seat1 even though fbcon is mapped to that.) Anyway, I know I can just override the permissions or use the old group way of doing things, but I'd prefer to fix things properly. The symptoms of wrong device permissions can be insidious. Kind regards, Christian Pernegger
Re: [systemd-devel] Custom Localed Configuration Location
On Di, 29.08.23 17:18, TJ Shipp (onezoo...@msn.com) wrote: > I am trying to create a system where we can change locale on a > running system (where we would have daemons subscribe to dbus and > get the properties changed messages) but need to be able to change > the location of the locale file (by default in /etc/locale.conf) as > /etc is read-only on our system. We do not support that. /etc/ is the place for configuration on Linux, and if you make that immutable you basically turn off the ability to configure things at runtime. Which is totally OK to do of course, but if this is the mode you pick you shouldn't be surprised that this is what you get. > Is there a way to change the file location to a writeable location > as I can not find any current means to do such? This is not configurable, the path /etc/locale.conf is considered API. It's not a hidden backend or so, but a primary interface to this setting. Lennart -- Lennart Poettering, Berlin
Re: [systemd-devel] Additional Locale Variables for Units and Number Format
On Di, 29.08.23 17:17, TJ Shipp (onezoo...@msn.com) wrote: > I am trying to add in support for a separate variable to change our unit > system, and having both LANG and UNITS to identify the "locale" of the system. > We are also not only looking for English versus Metric, but are looking for > mixed units as well (both Imperial and Metric hybrid), as well as looking to > add number formats (1,000.00 vs 1.000,00) > > And what is the best way to add support for a new system environment variable > such as UNITS? > > P.S. If anyone is interested in contracting to do this work, please send me a > private message outside this list. systemd-devel is not the right forum for this. Not sure what a better forum for this is, but systemd is way too low-level system stuff for that. Hence, I don't know who to suggest you to contact about this, but maybe someone at the Linux Foundation can connect you. Lennart -- Lennart Poettering, Berlin
Re: [systemd-devel] Flushing DNS caches items on clock change.
On Mi, 30.08.23 18:06, Vishwanath Chandapur (vishwa...@gmail.com) wrote: > Hi, > > We are using systemd-resolved. We observed that on clock change, > systemd-resolved is flushing all caches. > > By looking into the code we found that this is implemented primarily for > DNSSEC. > > Is there any specific reason for flushing the other cache items like mDNS, > LLMNR? Usually things like clock jumps happen on system suspend/resume cycles, VM migration and other VM management non-linearities. Quite often this coincides with network connectivity changes, and hence we should invalidate whatever information we collected so far about the network. Given this is redundant info we can reacquire this should not be an issue. Lennart -- Lennart Poettering, Berlin
Re: [systemd-devel] Assertion '!ether_addr_is_null(addr)'
On Mi, 30.08.23 15:22, Mirza Krak (mirza.k...@gmail.com) wrote: > Hi, > > Environment: > * systemd: 250.5 This release is from 2021, i.e. relatively old. The issue you are descriping is almost certainly aleady addressed in newer versions. Consider using a new version. Or contact your OS vendor, asking them to maybe backport the fix in question. Lennart -- Lennart Poettering, Berlin
Re: [systemd-devel] Is it possible to change the cgroup uid/gid for a systemd slice?
On Mi, 30.08.23 23:08, Julio Lajara (julio.laj...@protonmail.com) wrote: > Hi all, I have created a systemd slice to constrain CPU/mem > resources for a service unit. The service unit runs as root (its a > bash script) and it runs a subprocess using systemd-run that it also > runs under the same slice but a different unprivileged user. The > subprocess needs to read the cgroup memory data directly from the > sysfs tree but it cant because its owned by root. sysfs tree? You mean cgroupfs tree? But the memory attributes are world readable, so no need to chown. > Is there way I can change the permissions on it in the slice similar > to how cgcreate has the -a option to set the uid/gid for the cgroup? There's not. chowing of cgroups is pretty much about the ability to change them or create subgroups in them, but we do not allow either to client programs for slices. Lennart -- Lennart Poettering, Berlin
Re: [systemd-devel] Is it possible to change the cgroup uid/gid for a systemd slice?
On 8/31/23 1:08 AM, Julio Lajara wrote:
> Hi all, I have created a systemd slice to constrain CPU/mem resources for a
> service unit. The service unit runs as root (its a bash script) and it runs a
> subprocess using systemd-run that it also runs under the same slice but a
> different unprivileged user. The subprocess needs to read the cgroup memory
> data directly from the sysfs tree but it cant because its owned by root. Is
> there way I can change the permissions on it in the slice similar to how
> cgcreate has the -a option to set the uid/gid for the cgroup?
Can you demonstrate that? On the systems I've checked, all cgroup directories
have o=rx and all files in it o=r.
>From a very quick look, systemd seems to always be using 0755 mode:
int cg_create(const char *controller, const char *path) {
_cleanup_free_ char *fs = NULL;
int r;
r = cg_get_path_and_check(controller, path, NULL, );
if (r < 0)
return r;
r = mkdir_parents(fs, 0755);
if (r < 0)
return r;
r = RET_NERRNO(mkdir(fs, 0755));
D.
>
> Thanks,
>
--
Donald Buczek
buc...@molgen.mpg.de
Tel: +49 30 8413 1433
Re: [systemd-devel] Service not run, although enabled
> > # systemctl status bestcrypt-fs > ● bestcrypt-fs.service - Mount Bestcrypt containers > Loaded: loaded (/etc/systemd/system/bestcrypt-fs.service; enabled; > vendor preset: disabled) > Active: active (exited) (thawing) since Mon 2023-08-07 11:17:18 EEST; > 20min ago > Process: 2645396 ExecStart=/usr/local/sbin/bcmount (code=exited, > status=0/SUCCESS) >Main PID: 2645396 (code=exited, status=0/SUCCESS) > > How come that the via "ExecStart=" given bash script does not get run? > It clearly *did* run, it says bcmount was successfully executed 20 minutes earlier and the service has been active since then. Were you trying to start your service again with "systemctl start" ? Because that will do nothing when the service is already active. You'd need to stop the service first (which will cause bceject to be invoked), or use "systemctl restart" which will stop the service before starting it. Note btw that because you put "exit 0" at the end of your script it will always claim success even if the actual mount command fails. Simply removing the "exit 0" will fix that since then the script's exit code will be that of the last command executed. Another fix is adding the -e flag to #!/bin/sh which will make your script fail if any command it executes fails instead of just ignoring failures. Do you have a clue? I even changed "oneshot" into "simple", striked > "RemainAfterExit", etc. > Don't do that, Type=oneshot and RemainAfterExit=true are correct for your service. Type=oneshot means systemd will wait for the ExecStart program to exit when starting the service, i.e. your service won't be considered to have started successfully until bcmount has finished successfully. As long as bcmount is still running your service will be considered "starting" and if it takes too long then systemd will kill it with a timeout. In contrast, Type=simple means systemd will start the ExecStart program asynchronously and immediately consider the service to be active, so starting your service will always successfully complete immediately before bcmount has even started executing, and if bcmount fails then the service will just go to "failed" state afterwards. RemainAfterExit=true means that your service will continue to be considered "active" after the ExecStart program exits successfully, which is exactly what you want when this program is responsible for starting your service and then exits. When RemainAfterExit=false the ExecStart program is assumed to *be* the service, hence when it exits the service will stop (hence ExecStop will be invoked). Is there any way I can see the whole process verbosely? > You can enable debug logging in systemd using "systemctl log-level debug" and turn it back off using "systemctl log-level info". Matthijs
