[systemd-devel] nspawn, ipvlan and documentation

[Ede Wolf]

Hello,


I would like to confirm, wether I am reading the nspawn documentation 
correctly or wether I am confusing things.

For ipvlan, it reads:

'Create an "ipvlan" interface of the specified Ethernet network 
interface and add it to the container.'


I understand this the way, that the equivalent to:

ip link add link eth0 name ifipvlan type ipvlan

is being done by nspawn. So I proivide the eth0 interface as the 
argument to --network-ipvlan=


This kind of works, however, the interface inside the container always 
has mode L2.


In case, my interpretation so far is correct, how do I specify the 
ipvlan mode (L3S instead of the default L2)?


Or is my only chance to create an ipvlan mode l3 interface on the host 
and assign it to the container using the --network-interface=ifipvlan 
switch?


Thanks

Ede

Re: [systemd-devel] networkd RA being ignored unless promiscous

[Ede Wolf]

Stupid me: For some strange reason I've had Multicast set to no in the 
link section. That should explains everything.
Sometimes, one focuses too long too much on wrong things to see the 
obvious. Probably assuming, when comparing, not having set Multicast at 
all equals "no". I does not.




Am 03.07.24 um 09:46 schrieb Ede Wolf:

Hello,

I am having two machines that receive their ipv6 address and their 
default route via RA, both on the same physikal link, as is the router.


While one works as expected, the other machine behaves in a way, that it 
gets it's default route after restarting networkd, but once that has 
expired, it get's deleted - despite quite a lot RA having been send way 
beforehand by the router, confirmed with tcpdump (and seen on the other 
machine as well, where the expire counter gets frequently reset 
accordingly).


Wether I am waiting 30 minutes or thee hours, it seems, subsequent RA 
are completely being ignored.
Unless, now for the strage part, I set that corresponding interface into 
promiscous mode.
Being promiscous, suddenly RA are being honored again, the default route 
gets reinstalled and the expire timer gets reset with each subsequent RA.
Removing the promiscous mode and again the route lifetime counts down to 
zero and gets deleted.


So in short, expect the inital RA after restarting networkd subsequent 
RA seem to be ignored unless the interface is in promiscous mode. I've 
compared the ipv6 sysctl of the interface of the machine that works with 
that spooky one, no real differences.


This certainly is not a  general networkd issue, but maybe someone has 
an idea, what network configuration parameters I might have to recheck. 
And since restarting networkd does temporarily fix the issue, I've 
thought, maybe this might be the right place to start.


Thanks

Ede

[systemd-devel] networkd RA being ignored unless promiscous

[Ede Wolf]

Hello,

I am having two machines that receive their ipv6 address and their 
default route via RA, both on the same physikal link, as is the router.


While one works as expected, the other machine behaves in a way, that it 
gets it's default route after restarting networkd, but once that has 
expired, it get's deleted - despite quite a lot RA having been send way 
beforehand by the router, confirmed with tcpdump (and seen on the other 
machine as well, where the expire counter gets frequently reset 
accordingly).


Wether I am waiting 30 minutes or thee hours, it seems, subsequent RA 
are completely being ignored.
Unless, now for the strage part, I set that corresponding interface into 
promiscous mode.
Being promiscous, suddenly RA are being honored again, the default route 
gets reinstalled and the expire timer gets reset with each subsequent RA.
Removing the promiscous mode and again the route lifetime counts down to 
zero and gets deleted.


So in short, expect the inital RA after restarting networkd subsequent 
RA seem to be ignored unless the interface is in promiscous mode. I've 
compared the ipv6 sysctl of the interface of the machine that works with 
that spooky one, no real differences.


This certainly is not a  general networkd issue, but maybe someone has 
an idea, what network configuration parameters I might have to recheck. 
And since restarting networkd does temporarily fix the issue, I've 
thought, maybe this might be the right place to start.


Thanks

Ede

Re: [systemd-devel] configuring nspawn private network (mtu & mac)

[Ede Wolf]

Got it. On the host I need to match OriginalName, not Name, in the link 
file. Then I am able to set the macaddress and the mtu.


Since I am not sure, how stable those names are (as in 
vb-webserver@if3), is there maybe a way I have missed to label the 
interface names in the .nspawn file to later reference them in the .link 
file?




Am 01.07.24 um 16:07 schrieb Ede Wolf:

Hello,

I am having two container connected via private network to a bridge with 
a mtu of 8k.


However the .nspawn generated interfaces have the default mtu of 1500. 
And while I can manually adjust the mtu to 8k using the ip link command, 
I am wondering, wethere there is a way to specify the mtu right in first 
place?


Having "MTUBytes=8192" inside the containers host0.network does not do 
the trick. While the mtu inside the container is shown as 8k, the hosts 
still lists the interface with an mtu of 1500 - and this of course 
creates problems.


And, while we are at it, is there a way to specify the mac as well?

Thanks

Ede

[systemd-devel] configuring nspawn private network (mtu & mac)

[Ede Wolf]

Hello,

I am having two container connected via private network to a bridge with 
a mtu of 8k.


However the .nspawn generated interfaces have the default mtu of 1500. 
And while I can manually adjust the mtu to 8k using the ip link command, 
I am wondering, wethere there is a way to specify the mtu right in first 
place?


Having "MTUBytes=8192" inside the containers host0.network does not do 
the trick. While the mtu inside the container is shown as 8k, the hosts 
still lists the interface with an mtu of 1500 - and this of course 
creates problems.


And, while we are at it, is there a way to specify the mac as well?

Thanks

Ede

Re: [systemd-devel] networkd : ipv6 prefix delegation

[Ede Wolf]

Yes, this. There's no benefit to disabling link-local addressing, and
doing so can definitely break other IPv6 features. I've never seen an
explicitly-configured link-local address before, but I'd be really
surprised if it worked as a replacement for the
automatically-generated link-local address.


Manually configured link local adresses are quite common on routers.
And there is no reason, why it should not work, but having simpler 
addresses on gateways can make some sense.


After all, where is the difference between a random, a RFC7217 stable 
private or manual address?


To emphasise it again: It is not about disabling link local addressing, 
that is not, what the stanza does, it is about optionally disabling 
_auto_configuration.

Re: [systemd-devel] networkd : ipv6 RA (not prefix delegation)

[Ede Wolf]

Am 05.09.22 um 19:45 schrieb Arian van Putten:
Just thinking out loud here but aren't RA messages are sent as link 
local multicast messages? How can it send them if you disable link local 
addressing?


Yes, RA are being sent as ll multicast. But the interface  does have a 
valid link local address. LinkLocalAddressing= refers to 
autoconfiguration (according to the documentation on freedesktop), not 
to the disablement of link local adresses.
A link local address ist of course required, I just happen to configure 
it manually, not via autoconfiguration.


Unless I miss something fundamentally, this looks more and more like a bug.
Either we need a LinkLocalAddressing=ipv6manual option or it should be 
checked, wether a valid scope local address is being provided later on.


But of course, I may be wrong

On Mon, 5 Sept 2022, 19:14 Ede Wolf, <mailto:lis...@nebelschwaden.de>> wrote:


Am 05.09.22 um 18:34 schrieb Ede Wolf:
 > Hello,
 >
 > For a simple setup, I've tried to replace radvd with systemds
 > IPv6SendRA=true.
 >
 > Now the link supposed to send the RA of course has both a fixed
local as
 > well as fixed global (ULA) address. As it happens to be the
default gw
 > as well.
 >
 > Since the local address is being configured manually,
 > LinkLocalAddressing is consequently set to no
 >
 >
 > Now networkd complains, from the journal:
 >
 > IPv6PrefixDelegation= is enabled but IPv6 link-local addressing is
 > disabled. Disabling IPv6PrefixDelegation=.
 >
 >
 > Not sure what I am overlooking, but the SendRA is meant for other
 > clients, not for this link. Otherwise I would have set
IPv6AcceptRA to
 > true, not IPv6SendRA.
 >
 > What am I misinterpreting here?
 >
 > Thanks
 >
 > Ede

I may have mixed up terms, something that, however, does not make
things
more comprehendable to me.
I am not using DHCPv6, I would just like to announce the prefix via RA
to other clients on that link. So prefix delegation is likely something
else. I've just concluded that from the journal message.

However, my .network file has no DHCPv6 related stanzas:

[Match]
Name=brlan

[Link]
MACAddress=02:...
RequiredForOnline=yes

[Network]
Description=Bridge
LinkLocalAddressing=no
IPForward=ipv4
IPForward=ipv6
IPv6AcceptRA=no
ConfigureWithoutCarrier=true
IgnoreCarrierLoss=true
DHCPServer=yes
IPv6AcceptRA=false
IPv6SendRA=true

[Address]
Address=192.168.38.1/24 <http://192.168.38.1/24>

[Address]
Address=fe80::38:1/64
Scope=link

[Address]
Address=fde3:8b13:f1a5:38::1/64
Scope=global

[DHCPServer]
PoolOffset=200
PoolSize=32
EmitNTP=yes
NTP=192.168.38.101

[IPv6SendRA]
Managed=no
OtherInformation=no

[IPv6Prefix]
AddressAutoconfiguration=true
Prefix=fde3:8b13:f1a5:38::/64

Re: [systemd-devel] networkd : ipv6 prefix delegation

[Ede Wolf]

Am 05.09.22 um 18:34 schrieb Ede Wolf:

Hello,

For a simple setup, I've tried to replace radvd with systemds 
IPv6SendRA=true.


Now the link supposed to send the RA of course has both a fixed local as 
well as fixed global (ULA) address. As it happens to be the default gw 
as well.


Since the local address is being configured manually, 
LinkLocalAddressing is consequently set to no



Now networkd complains, from the journal:

IPv6PrefixDelegation= is enabled but IPv6 link-local addressing is 
disabled. Disabling IPv6PrefixDelegation=.



Not sure what I am overlooking, but the SendRA is meant for other 
clients, not for this link. Otherwise I would have set IPv6AcceptRA to 
true, not IPv6SendRA.


What am I misinterpreting here?

Thanks

Ede


I may have mixed up terms, something that, however, does not make things 
more comprehendable to me.
I am not using DHCPv6, I would just like to announce the prefix via RA 
to other clients on that link. So prefix delegation is likely something 
else. I've just concluded that from the journal message.


However, my .network file has no DHCPv6 related stanzas:

[Match]
Name=brlan

[Link]
MACAddress=02:...
RequiredForOnline=yes

[Network]
Description=Bridge
LinkLocalAddressing=no
IPForward=ipv4
IPForward=ipv6
IPv6AcceptRA=no
ConfigureWithoutCarrier=true
IgnoreCarrierLoss=true
DHCPServer=yes
IPv6AcceptRA=false
IPv6SendRA=true

[Address]
Address=192.168.38.1/24

[Address]
Address=fe80::38:1/64
Scope=link

[Address]
Address=fde3:8b13:f1a5:38::1/64
Scope=global

[DHCPServer]
PoolOffset=200
PoolSize=32
EmitNTP=yes
NTP=192.168.38.101

[IPv6SendRA]
Managed=no
OtherInformation=no

[IPv6Prefix]
AddressAutoconfiguration=true
Prefix=fde3:8b13:f1a5:38::/64

[systemd-devel] networkd : ipv6 prefix delegation

[Ede Wolf]

Hello,

For a simple setup, I've tried to replace radvd with systemds 
IPv6SendRA=true.


Now the link supposed to send the RA of course has both a fixed local as 
well as fixed global (ULA) address. As it happens to be the default gw 
as well.


Since the local address is being configured manually, 
LinkLocalAddressing is consequently set to no



Now networkd complains, from the journal:

IPv6PrefixDelegation= is enabled but IPv6 link-local addressing is 
disabled. Disabling IPv6PrefixDelegation=.



Not sure what I am overlooking, but the SendRA is meant for other 
clients, not for this link. Otherwise I would have set IPv6AcceptRA to 
true, not IPv6SendRA.


What am I misinterpreting here?

Thanks

Ede

[systemd-devel] systemd-nspawn: unpriviledged non systemd container

[Ede Wolf]

Hi,

not sure, wether it is appropiate to ask here, but in lack of a better 
alternative, I'll give it a go.


I am trying to boot an alpine container (openrc), works as root. but 
when changing to a user id, the bootup fails with getty error messages:


getty: console: TIOCSCTTY: Operation not permitted

and stopping the container takes over a minute.

# time systemctl stop machine-alpine.scope
real1m30,198s



I've tried either:

Capability=CAP_SYS_TTY_CONFIG [CAP_SYS_ADMIN]
Capability=all

No change, though I would like to not having to use latter one anyway.

Any ideas what I might be missing? Or maybe is this just completely out 
of scope?



Thanks

Ede




P.S.: Here's more from the containers messages, puzzling that it gets 
logged as auth facility:


Aug 16 16:28:08 alpine daemon.info init: starting pid 213, tty 
'/dev/console': '/sbin/getty 38400 console'
Aug 16 16:28:08 alpine auth.err getty[213]: TIOCSCTTY: Operation not 
permitted
Aug 16 16:28:18 alpine daemon.info init: process '/sbin/getty 38400 
console' (pid 213) exited. Scheduling for restart.
Aug 16 16:28:19 alpine daemon.info init: starting pid 214, tty 
'/dev/console': '/sbin/getty 38400 console'
Aug 16 16:28:19 alpine auth.err getty[214]: TIOCSCTTY: Operation not 
permitted
Aug 16 16:28:29 alpine daemon.info init: process '/sbin/getty 38400 
console' (pid 214) exited. Scheduling for restart.
Aug 16 16:28:30 alpine daemon.info init: starting pid 215, tty 
'/dev/console': '/sbin/getty 38400 console'
Aug 16 16:28:30 alpine auth.err getty[215]: TIOCSCTTY: Operation not 
permitted

Re: [systemd-devel] timesyncd log messages galore

[Ede Wolf]

The situation turns out to be a little different, the log messages are 
somewhat misleading.


First, my ra intervals were indeed set to high, thanks for the heads up, 
after some testing I forgot to set them back. Should have paid more 
attention way back. But those where not directly the cause.


The messages get written, if the ntp server does not respond and a ra is 
received.


Once the initial synchronisation has been done, they do not reapper, no 
matter how many ra are being subsequently received on that link.


Still not convinced, that behaviour is really helpful, as a received ra 
is not a changed network configuration (can be, but rather seldom for a 
given host) and a message, that the remote ntpd is not usable would be 
way more appropiate, but there we are.


My ntpd had an open port, but that was not usable. netcat worked, but a 
later installed ntpdate reported no suitable servers where found.

Makes me wonder, wether timedatectl could have been used as well?

Once the ntp issue had been fixed, the log messages vanished.

Just as a reference for future generations


Am 11.02.21 um 17:22 schrieb Mantas Mikulėnas:
On Thu, Feb 11, 2021 at 6:07 PM Ede Wolf <mailto:lis...@nebelschwaden.de>> wrote:


Thanks. Indeed, stopping radvd made these messages stop appearing.
Now I am no IPv6 guru, but having routeradvertisments is not too
uncommon, to the best of my knowledge.


RAs shouldn't be extremely frequent. An hour is a common interval for 
periodic RAs -- certainly not minutes or seconds.


OTOH, I am not seeing any such messages on any of my IPv6 hosts using 
timesyncd. There is a burst of "network changed" messages on boot, 
presumably in response to bridges and tunnels being set up, but the 
daemon stays quiet afterwards. Currently it has recorded 1.988s total 
CPU usage after 12 days of uptime.



So the punchline is, that timesynd is not really usable with ipv6
networks? Am I getting that correct?


No, sounds more like it's just not really usable with *your* IPv6 network.

--
Mantas Mikulėnas


___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] timesyncd log messages galore

[Ede Wolf]

Thanks. Indeed, stopping radvd made these messages stop appearing.
Now I am no IPv6 guru, but having routeradvertisments is not too 
uncommon, to the best of my knowledge.


So the punchline is, that timesynd is not really usable with ipv6 
networks? Am I getting that correct?


After all, an ra does not really change any network configuration and 
since the issue you've related to is rather old, this does not seem to 
be considered as a bug?


Especially, since the ntp in this case is ipv4 only and completely 
unrelated to ipv6. If it can reach its ntp, why those messages?


Ede



Am 10.02.21 um 22:38 schrieb Dan Nicholson:

On Wed, Feb 10, 2021 at 11:49 AM Ede Wolf  wrote:


My journal get spammed with messages from timesyncd, claiming a changed
network connection. However, I have not touched the network
configuration at all and the ntp even happens to be on the same subnet.
No DHCP either.


Back in https://bugs.freedesktop.org/show_bug.cgi?id=87505 this was
caused by router IPv6 router advertisements. Maybe you're having a
similar issue? Might be useful to do some network monitoring to see
what's happening at that time.

--
Dan



___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] timesyncd log messages galore

[Ede Wolf]

Hi,


My journal get spammed with messages from timesyncd, claiming a changed 
network connection. However, I have not touched the network 
configuration at all and the ntp even happens to be on the same subnet. 
No DHCP either.


Here two examples, 200 messages in 20 minutes uptime, or 5800 of them in 
11 hours:


# journalctl -b0 | grep "Network configuration changed, trying to 
establish connection." | wc -l

199

# uptime
 19:29:34 up 21 min,  3 users,  load average: 1,07, 1,04, 0,87

Another machine:

# journalctl -b0 | grep "Network configuration changed, trying to 
establish connection." | wc -l

5755
# uptime
 19:32:20 up 10:28,  2 users,  load average: 1.21, 1.20, 1.20

Any idea how to stop this? This has been going on for quite a while now, 
but seems to get worse.


systemd 247.3, kernel 5.4.80 and 5.10.14
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Accpetance of Environment Variables in Attributes

[Ede Wolf]

Thanks again for your in depth reply.

> it's a very different kind of language, as these specifiers are
> defined by systemd itself

Maybe someday someone will find a safe way to inject addtionally, 
arbitrary values into systemd. There are still some free letters left 
that can be prefixed with a % :)


Until then I'll stick with dedicated unit files.

Ede


Am 26.06.20 um 15:27 schrieb Lennart Poettering:

On Do, 25.06.20 20:25, Ede Wolf (lis...@nebelschwaden.de) wrote:


Does work, so %i works, $SOMETHING not. Different naming, different way of
invocation, I am aware of that, but in general it still the usage of
variables. And the likes of %H, %m or %v are some form of environment,
aren't they?


Sure, you could claim this was a very specific form of templating. But
it's a very different kind of language, as these specifiers are
defined by systemd itself and are not affected by the contents of the
unit file itself. I.e. you cannot go and say within a unit file that
%m shall now resolve to "foo", and that %v shall now be
"xyz". Instead, these expansions are defined by the unit file language
itself, not by the unit file stanzas you place them in. That
difference is quite major: the value of each specifier expansion is
already well-defined and fixed at the moment we begin parsing the unit
file (and its drop-ins) and their meaning does not change based on
anything you could put in the file.

Scripting languages that know env vars or generic templating languages
are quite different there: you come up with variables, you assign them
at the top and then you can resolve them further down. This implies a
top-down, iterative order of execution. And we don't want that. Use m4
for that or shell. It's what they do, what they are good in.

It's the distinction between declarative languages and iterative
languages. We provide shortcuts to some concepts, but that's really
it, otherwise we are declarative and never iterative.


If you want a shell, use a shell.


Given the dominance of systemd, this is only in parts realistic. This is not
meant to critisize systemd itself, just this rather bold statement. As shown
above, variables (specifiers, whatever you call them) are not shell
specific.


They are not shell specific. You could also use m4 if you want a
templating language, there's no shame in that. But systemd is
certainly not in the business of inventing yet another shell or
generic templating language.

Lennart

--
Lennart Poettering, Berlin



___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Ensuring that a unit starts before any networking

[Ede Wolf]

Just a wild guess, but I'd start with a combination of one of those:

# -


[Unit]
Description=my service

Before=network.target
Before=systemd-networkd.service
Before=network-online.target
Before=systemd-networkd-wait-online.service

...

[Install]
WantedBy=Basic.target

# -


Probably someone will kill me for the basic target, which is fine, as 
long as the proper one is provided as well, and preferably with an 
explanation :)


In fact, probably I'd create a new, dedicated target for that, like 
my.target.


And if your script HAS to be finished, for networking to be run at all, 
you might want to add a drop in to systemd-networkd.service


# -

systemctl edit systemd-networkd.service

[Unit]
Requires=my.service
After=my.service

# -

This is most likely not a final solution, but a way I would approach 
this matter and start to play.
F.e., I am not sure, wether the drop in should really be for 
systemd-networkd.service or rather network.target. Play around.


And I am assuming, you are using systemd-networkd, and not something 
else  like networkmanager, in that case you have to adapt, of course.


Until someone with proper knowledge replies, good luck and report back



Am 27.06.20 um 10:34 schrieb Mark Rogers:

This feels like something I should be easily able to answer from
documentation/Google, and failing that from somewhere like
StackOverflow, without troubling systemd-devel, but all my efforts
have thus far failed [1]

What is the correct way to ensure a script runs to completion before
any networking units start? "The Internet" is abound with people
asking the opposite question which hasn't helped my keyword-based
searches.

My use case (on a Raspberry Pi running Raspbian if it matters) is that
I have network settings stored in a database from which I generate
network configuration files (eg dhcpcd.conf) on boot, therefore they
obviously need to be in place before dhcpcd starts. (Similarly
wpa_supplicant.)

Ideally I'd like to be agnostic about the actual network stack in my
unit configuration (so not setting dependencies relating to dhcpcd,
for example) but at this point I've tried pretty much everything
without success so I'm obviously doing something stupid.

I have tried multiple approaches so far but by current service file
looks like this:

[Unit]
Description=Config generation from DB
Before=networking.service

[Service]
Type=oneshot
ExecStart=/home/mark/bin/db2config.py

[Install]
RequiredBy=network.target

[1] 
https://stackoverflow.com/questions/62574482/ensuring-that-a-systemd-unit-starts-before-any-networking
- no responses there to date, feel free to respond there for
reputation or else I'll update it when I solve it.



___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Accpetance of Environment Variables in Attributes

[Ede Wolf]

I do this today using a drop-in, because environment variables can be
set there as well. It works very well, exactly as you describe. There
is a template service unit file, and a drop-in directory for each
instance which contains a file that sets the environment variables and
also provides values for keys in the [Unit] and [Service] sections.


Would you mind to explain, what is the benefit of this approach compared 
to having a dedicated unit file for each service?

 Thanks
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Accpetance of Environment Variables in Attributes

[Ede Wolf]

what exactly stands in your way to use
ExtecStart=/usr/local/bin/myscript.sh?



Because my question was about making a template unit file more dynamic, 
not the process called by the unit.


Having an environmentfile %i.env, that a) defines the environment for 
the actual service to be called (ExecStart=myservice --$OPTIONS...) but 
b) is also able to set different limits for that other instance of the 
same service.  Because a test webserver may be more restricted in 
resources.


This way I would only have to take care of _one_ external file to get 
another instance of service foo up and running. Copy the file, change 
the few options for the unit as well as for the service in ONE place, 
startup the template. Ultra elegant and fast, especially when dealing 
with 10+ instances of the same service, that only have little variation 
like the running user, limits and one or two different service arguments.


That is why drop-ins are no help, creating those makes as much work as 
copying the unit file itself and change the unit values manually.


Would have been useful, but I've learned, it is not possible.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Accpetance of Environment Variables in Attributes

[Ede Wolf]

Thanks for the heads up, but I've just used nobody as an example here, 
because everybody knows, it is a systems user and therefore not to be 
confused. Just to make it more clear.


Generally I do like the concept of dynamic users, but there are still 
some open questions left and therefore needs some testing. Will come in 
time.


Am 25.06.20 um 14:35 schrieb Roman Odaisky:

[Service]
User=nobody


May I interject that DynamicUser=yes is generally superior to User=nobody.




___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Accpetance of Environment Variables in Attributes

[Ede Wolf]

Am 25.06.20 um 14:30 schrieb Lennart Poettering:

Nah, unless you write a shell or templating language I doubt variable
expansion is a good thing.


I am aware, that discussion here is futile, but this is contradictious, 
because:


[Unit]
Description=test service

[Service]
User=%i
Type=oneshot

ExecStart=/bin/sh -c "echo helloWorld > /tmp/test.txt"

[Install]
WantedBy=multi-user.target


Does work, so %i works, $SOMETHING not. Different naming, different way 
of invocation, I am aware of that, but in general it still the usage of 
variables. And the likes of %H, %m or %v are some form of environment, 
aren't they?




If you want a shell, use a shell.


Given the dominance of systemd, this is only in parts realistic. This is 
not meant to critisize systemd itself, just this rather bold statement. 
As shown above, variables (specifiers, whatever you call them) are not 
shell specific.


Anyway, thanks for answering.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Accpetance of Environment Variables in Attributes

[Ede Wolf]

I am not sure what made you think this works, but systemd has no


Pure logic of conclusion. Besides this being a sensible thing to be able 
to do, why is LimitMEMLOCK not causing the unit to fail, when given a 
(non existing) variable? Or, since it is no variable from a systemd 
point of view, but a mere string, why does that not cause a failure? 
$MEM should not be a valid argument to ulimit -l (or the underlying 
syscall).



but systemd has no concept of env var expansion in unit files. It's not a shell.


That is unfortunate (not the shell part, but the variable one), but 
thanks for the explanation, that helps.

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] Accpetance of Environment Variables in Attributes

[Ede Wolf]

So I have an environmentfile containing two variable definitions:

RUNASUSER=nobody
MEM=4294967296

And my service section reads:

[Service]
EnvironmentFile=/path/myfile
User=$RUNASUSER
LimitMEMLOCK=$MEM

This service failes to startup, as I cannot seem to being able to  use a 
variable for the User attribute, but I may very well for LimitMEMLOCK.


Error:

Failed to determine user credentials: No such process


And if specifying instead:

[Service]
EnvironmentFile=/path/myfile
User=nobody
LimitMEMLOCK=$MEM

Everything does work. And I am wondering, why? And moreover, is there 
any source of documentation, that lists or even explains, what 
attributes may have a variable as an argument and what do not?


As for instances/template units it would be really helpful to being able 
to set the running user in the configuration/environment file. Or at 
least have a knowledge of those settings, that do not allow this, for 
what reason ever. Especially when talking about directory settings.


___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] systemd-networkd, IPv6PrivacyExtensions=kernel, sysctl and devicenames

[Ede Wolf]

Mea culpa, I completely overlooked this. Big sorry.

And in addition I can confirm this behaviour. Doing this rename manually 
does keep the values.


I am just wondering, how can we apply that to the boot behaviour? It 
does give some meat to the thesis, that something else is going on, but 
how to find out?


At least with systemd-245/arch (not sure who is to blame) I cannot use 
the final name, and with systemd-241/deepin (debian) I cannot either, if 
the final name is a custom one through udev rule or .link file.




Am 23.05.20 um 15:13 schrieb Andrei Borzenkov:

23.05.2020 11:56, Ede Wolf пишет:


tw:~ # systemctl stop NetworkManager.service
tw:~ # ip l set dev enp0s5 down
tw:~ # cat /proc/sys/net/ipv6/conf/enp0s5/use_tempaddr
1
tw:~ # cat /proc/sys/net/ipv6/conf/enp0s5/addr_gen_mode
1
tw:~ # echo 3 > /proc/sys/net/ipv6/conf/enp0s5/addr_gen_mode
tw:~ # echo 2 > /proc/sys/net/ipv6/conf/enp0s5/use_tempaddr
tw:~ # cat /proc/sys/net/ipv6/conf/enp0s5/use_tempaddr
2
tw:~ # cat /proc/sys/net/ipv6/conf/enp0s5/addr_gen_mode
3
tw:~ # ip l set dev enp0s5 name ififif
tw:~ # ip l set dev ififif up
tw:~ # cat /proc/sys/net/ipv6/conf/ififif/use_tempaddr
2
tw:~ # cat /proc/sys/net/ipv6/conf/ififif/addr_gen_mode
3



Thanks for taking the time to demonstrate this. But it does not comapre,
as you do not remane the interface.


May 23 09:05:52 tw.0.2.15 kernel: virtio_net virtio4 ififif: renamed
from enp0s5

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel



___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] systemd-networkd, IPv6PrivacyExtensions=kernel, sysctl and devicenames

[Ede Wolf]

Given lack of errors after interface rename, settings were most probably
applied correctly.


No. According to the log, the lack of errors after the rename result 
simlpy in there are no more settings left that could be applied. Because 
they all have been tried before. And failed. sysctl.conf is most likely 
only read once during boot. And in this case that happens before the 
rename.







tw:~ # systemctl stop NetworkManager.service
tw:~ # ip l set dev enp0s5 down
tw:~ # cat /proc/sys/net/ipv6/conf/enp0s5/use_tempaddr
1
tw:~ # cat /proc/sys/net/ipv6/conf/enp0s5/addr_gen_mode
1
tw:~ # echo 3 > /proc/sys/net/ipv6/conf/enp0s5/addr_gen_mode
tw:~ # echo 2 > /proc/sys/net/ipv6/conf/enp0s5/use_tempaddr
tw:~ # cat /proc/sys/net/ipv6/conf/enp0s5/use_tempaddr
2
tw:~ # cat /proc/sys/net/ipv6/conf/enp0s5/addr_gen_mode
3
tw:~ # ip l set dev enp0s5 name ififif
tw:~ # ip l set dev ififif up
tw:~ # cat /proc/sys/net/ipv6/conf/ififif/use_tempaddr
2
tw:~ # cat /proc/sys/net/ipv6/conf/ififif/addr_gen_mode
3



Thanks for taking the time to demonstrate this. But it does not comapre, 
as you do not remane the interface. It is alway enp0s5, and therefore 
the kernel is keeping the /proc/sys/net/ipv6/conf/enp0s5/ settings.


You you would need to apply the sysctl to enp0s5, then rename it to 
lan01, then the /proc/sys/net/ipv6/conf/enp0s5/... hierachy would be 
gone and instead you would have a
/proc/sys/net/ipv6/conf/lan01/ hierachie, that would NOT inherit the 
settings you've applied to enp0s5.
From a kernel perspective point of view these two are not related at 
all, they are independent interfaces, that just appear and go. At least, 
that's what it seems like.


And that is what is happening here on boot.

systemd-sysctl applies the eth0 setting from sysctl.conf to the 
interface. It failes to to do the same for ens3, as this interface does 
not exist yet. As it is still named eth0


Then systemd renames eth0 to ens3. The eth0 settings are gone, the ones 
for ens3 are not applied any more, as systemd-sysctl has already 
processed sysctl.conf. Therefore the default values are used.


As written in a follow up, the ordering seems to be different on deepin 
linux using systemd 241 instead of arch and systemd 245.


However, even with deepin, if you rename an interface with an udev rule 
or .link file, you run into the same problems again. Just, that there 
are now three renames and sysctl is read after the second, but before 
the third rename. Same result however.




What likely happens in your case is something else changes settings
after they had been applied by udev. Notice I had to stop NetworkManager
to avoid interfering as soon as link comes up.


I do not use any other network manager but systemd-networkd. In fact, I 
do not even have any installed. netctl, the default of arch, has been 
removed straight after install.


And, in addition, journal is pretty clear about systemd-networkd doing 
the name change:


Mai 23 10:41:27 systemd-networkd[464]: ens3: Interface name change 
detected, ens3 has been renamed to eth0.
Mai 23 10:41:27 systemd-networkd[464]: eth0: Interface name change 
detected, eth0 has been renamed to ens3.



But, in case this is still true, what would be the best way to figure out?

How can we hunt down this issue?
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] systemd-networkd, IPv6PrivacyExtensions=kernel, sysctl and devicenames

[Ede Wolf]

However, all is not gold with Deepin as well, as when using a .link file 
in /etc/systemd/network to rename the interface, Deeping as well does 
not work any more. Here, eth0 aka enp0s3 aka custom lan-01:




# journalctl -b0 | grep -E 'sysctl|lan-01|enp0s3|eth0'
May 22 22:31:22 test1-PC kernel: Yama: disabled by default; enable with 
sysctl kernel.yama.*
May 22 22:31:22 test1-PC kernel: virtio_net virtio0 enp0s3: renamed from 
eth0
May 22 22:31:22 test1-PC systemd-sysctl[259]: Couldn't write 
'840b:b3d7:8121:5774:b967:1737:db42:a87b' to 
'net/ipv6/conf/lan-01/stable_secret', ignoring: No such file or directory
May 22 22:31:22 test1-PC systemd-sysctl[259]: Couldn't write '2' to 
'net/ipv6/conf/lan-01/addr_gen_mode', ignoring: No such file or directory
May 22 22:31:22 test1-PC kernel: virtio_net virtio0 lan-01: renamed from 
enp0s3
May 22 22:31:22 test1-PC systemd-networkd[267]: enp0s3: Interface name 
change detected, enp0s3 has been renamed to lan-01.

May 22 22:31:22 test1-PC systemd-networkd[267]: lan-01: Gained carrier



So we have the renaming from kernel ethx to sytemd persistent, then 
systemd-sysctl, and then again the renaming from the systemd persistent 
to the user defined .link file.


Same is true, when using an udev rule to customly rename an interface 
instead of a .link file:




root@test1-PC:~# journalctl -b0 | grep -E 'sysctl|lan-01|enp0s3|eth0'
May 22 22:41:01 test1-PC kernel: Yama: disabled by default; enable with 
sysctl kernel.yama.*
May 22 22:41:01 test1-PC kernel: virtio_net virtio0 enp0s3: renamed from 
eth0
May 22 22:41:01 test1-PC systemd-sysctl[258]: Couldn't write 
'840b:b3d7:8121:5774:b967:1737:db42:a87b' to 
'net/ipv6/conf/lan-01/stable_secret', ignoring: No such file or directory
May 22 22:41:01 test1-PC systemd-sysctl[258]: Couldn't write '2' to 
'net/ipv6/conf/lan-01/addr_gen_mode', ignoring: No such file or directory
May 22 22:41:01 test1-PC kernel: virtio_net virtio0 lan-01: renamed from 
enp0s3
May 22 22:41:01 test1-PC systemd-networkd[263]: enp0s3: Interface name 
change detected, enp0s3 has been renamed to lan-01.

May 22 22:41:01 test1-PC systemd-networkd[263]: lan-01: Gained carrier





Am 22.05.20 um 21:50 schrieb Ede Wolf:




That sounds like actual bug. What systemd version do you use?


I've just did a test with Deepin, as I've had VM flying around of that 
debian based distribution, and here it seems to work, using systemd 241 
instead of 245. systemd-sysctl is clearly called after the renaming:



May 22 21:48:46 test1-PC kernel: Yama: disabled by default; enable with 
sysctl kernel.yama.*
May 22 21:48:46 test1-PC kernel: virtio_net virtio0 enp0s3: renamed from 
eth0
May 22 21:48:46 test1-PC systemd-sysctl[259]: Couldn't write 
'840b:b3d7:8121:5774:b967:1737:db42:a87b' to 
'net/ipv6/conf/eth0/stable_secret', ignoring: No such file or directory
May 22 21:48:46 test1-PC systemd-sysctl[259]: Couldn't write '2' to 
'net/ipv6/conf/eth0/addr_gen_mode', ignoring: No such file or directory
May 22 21:48:46 test1-PC systemd-sysctl[259]: Couldn't write '2' to 
'net/ipv6/conf/eth0/use_tempaddr', ignoring: No such file or directory

May 22 21:48:46 test1-PC systemd-networkd[263]: enp0s3: Gained carrier


So here eth0 is the invalid interface, as it should be.


Not sure now wether this a regression or distribution specific. Where 
are the dependencies defined what service runs first at this early stage?


___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] systemd-networkd, IPv6PrivacyExtensions=kernel, sysctl and devicenames

[Ede Wolf]

There are other issues with either systemd-245 or arch.

When NOT using any

net.ipv6.conf.xxx.use_tempaddr=2

statements in sysctl.conf, but instead are only using

IPv6PrivacyExtensions=yes

on arch/systemd-245 this setting gets ignored. On Deepin however a 
temporary address is assigned, as expected.




Am 22.05.20 um 21:50 schrieb Ede Wolf:




That sounds like actual bug. What systemd version do you use?


I've just did a test with Deepin, as I've had VM flying around of that 
debian based distribution, and here it seems to work, using systemd 241 
instead of 245. systemd-sysctl is clearly called after the renaming:



May 22 21:48:46 test1-PC kernel: Yama: disabled by default; enable with 
sysctl kernel.yama.*
May 22 21:48:46 test1-PC kernel: virtio_net virtio0 enp0s3: renamed from 
eth0
May 22 21:48:46 test1-PC systemd-sysctl[259]: Couldn't write 
'840b:b3d7:8121:5774:b967:1737:db42:a87b' to 
'net/ipv6/conf/eth0/stable_secret', ignoring: No such file or directory
May 22 21:48:46 test1-PC systemd-sysctl[259]: Couldn't write '2' to 
'net/ipv6/conf/eth0/addr_gen_mode', ignoring: No such file or directory
May 22 21:48:46 test1-PC systemd-sysctl[259]: Couldn't write '2' to 
'net/ipv6/conf/eth0/use_tempaddr', ignoring: No such file or directory

May 22 21:48:46 test1-PC systemd-networkd[263]: enp0s3: Gained carrier


So here eth0 is the invalid interface, as it should be.


Not sure now wether this a regression or distribution specific. Where 
are the dependencies defined what service runs first at this early stage?


___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] systemd-networkd, IPv6PrivacyExtensions=kernel, sysctl and devicenames

[Ede Wolf]

Found the reason for this global issue. The not working machine had not 
been moved to SLAAC, as I've though it was, but had still been 
configured statically.


Bummer.


As a workaround I have set default values:

net.ipv6.conf.default.stable_secret=
net.ipv6.conf.default.addr_gen_mode=2
net.ipv6.conf.all.addr_gen_mode=2


But I am getting different results on two different machines. One, where 
it works even on a systemd renamed link, and one, where it is not. Still 
trying to figure out, why that is.



___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] systemd-networkd, IPv6PrivacyExtensions=kernel, sysctl and devicenames

[Ede Wolf]

Hello,

Thanks for replying. As I have written, I am using no custom .rules or 
.link file. /etc/udev/rules.d is empty and /etc/systemd/network only 
contains .network files.


But I believe the problem would not change. As wether I rename an 
interface or 99-default.link as part of systemd-networkd does it, should 
make no difference.


The problem is, that sysctl.conf is being executed before the interfaces 
get their eventual names.


What would work is disabling interface renaming alltogether by adding 
net.ifnames=0 to the kernel, but those ethx names are not reliably 
persistent. So nothing is really won here. Unless you only have one 
interface, that is.


Unless I have missed somthing, that's why I am asking, those settings 
would need to be moved  from sysctl.conf to the [Network] section of a 
corresponding unit file alltogether, so that systemd has control over it.


As a workaround I have set default values:

net.ipv6.conf.default.stable_secret=
net.ipv6.conf.default.addr_gen_mode=2
net.ipv6.conf.all.addr_gen_mode=2


But I am getting different results on two different machines. One, where 
it works even on a systemd renamed link, and one, where it is not. Still 
trying to figure out, why that is.


But the key should be to be able to set those on a per link base, what I 
have not been able to do so far at all.





Am 22.05.20 um 12:21 schrieb Kevin P. Fleming:

Do you have a udev 'persistent network device name' rules file in
/etc/udev/rules.d? Many distributions install such a rules file by
default, and this renames the interfaces to 'standard' names.

On Fri, May 22, 2020 at 3:47 AM Ede Wolf  wrote:


Hello,

I am trying to enable temporary and/or stable addresses for a link and
am most likely running into troubles with the device naming. However, I
do not change any network name myself, neither in udev nor as part or a
link file, it's just the standard system settings (from Arch, in case
that matters).

my sysctl.conf (both ens3 and eth0 refer to the same interface):


net.ipv6.conf.ens3.addr_gen_mode = 2
net.ipv6.conf.ens3.use_tempaddr = 2

net.ipv6.conf.eth0.addr_gen_mode = 2
net.ipv6.conf.eth0.use_tempaddr = 2


And the logs read:

journalctl -b0 | grep -E 'sysctl|ens3|eth0'
08:56:46 systemd[263]: systemd-sysctl.service: Executing:
/usr/lib/systemd/systemd-sysctl
08:56:46 systemd-sysctl[263]: Couldn't write '2' to
'net/ipv6/conf/ens3/addr_gen_mode', ignoring: No such file or directory
08:56:46 systemd-sysctl[263]: Couldn't write '2' to
'net/ipv6/conf/ens3/use_tempaddr', ignoring: No such file or directory
08:56:47 kernel: virtio_net virtio0 ens3: renamed from eth0
08:56:47 systemd[1]: sys-subsystem-net-devices-ens3.device: Changed dead
-> plugged
08:56:47 systemd[1]:
sys-devices-pci:00-:00:03.0-virtio0-net-ens3.device: Changed
dead -> plugged
08:56:51 systemd-networkd[459]: ens3: Interface name change detected,
ens3 has been renamed to eth0.
08:56:51 systemd-networkd[459]: eth0: Interface name change detected,
eth0 has been renamed to ens3.
08:56:51 systemd-networkd[459]: ens3: IPv6 successfully enabled
08:56:51 systemd-networkd[459]: ens3: Link UP
08:56:51 systemd-networkd[459]: ens3: Gained carrier
...


As it appears to me, the eth0 settings from sysctl.conf have been
accepted - at least no errors are logged in this regard -, but are lost,
because the interface got renamed afterwards. The ens3 interface was not
yet known at time of invoking systemd-sysctl, and therefore we get the
errors. That in turn means, the settings are not being applied.

To make things worse, in sysctl.conf I've additionally set:

net.ipv6.conf.default.stable_secret=
net.ipv6.conf.default.addr_gen_mode=2
net.ipv6.conf.all.addr_gen_mode=2


Which results in all IP address having a stable privacy scope link,
_execpt_ of course ens3. The one that would be by far most important.

What am I missing here? And insight is highly appreciated

Thanks

Ede
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] systemd-networkd, IPv6PrivacyExtensions=kernel, sysctl and devicenames

[Ede Wolf]

Hello,

I am trying to enable temporary and/or stable addresses for a link and 
am most likely running into troubles with the device naming. However, I 
do not change any network name myself, neither in udev nor as part or a 
link file, it's just the standard system settings (from Arch, in case 
that matters).


my sysctl.conf (both ens3 and eth0 refer to the same interface):


net.ipv6.conf.ens3.addr_gen_mode = 2
net.ipv6.conf.ens3.use_tempaddr = 2

net.ipv6.conf.eth0.addr_gen_mode = 2
net.ipv6.conf.eth0.use_tempaddr = 2


And the logs read:

journalctl -b0 | grep -E 'sysctl|ens3|eth0'
08:56:46 systemd[263]: systemd-sysctl.service: Executing: 
/usr/lib/systemd/systemd-sysctl
08:56:46 systemd-sysctl[263]: Couldn't write '2' to 
'net/ipv6/conf/ens3/addr_gen_mode', ignoring: No such file or directory
08:56:46 systemd-sysctl[263]: Couldn't write '2' to 
'net/ipv6/conf/ens3/use_tempaddr', ignoring: No such file or directory

08:56:47 kernel: virtio_net virtio0 ens3: renamed from eth0
08:56:47 systemd[1]: sys-subsystem-net-devices-ens3.device: Changed dead 
-> plugged
08:56:47 systemd[1]: 
sys-devices-pci:00-:00:03.0-virtio0-net-ens3.device: Changed 
dead -> plugged
08:56:51 systemd-networkd[459]: ens3: Interface name change detected, 
ens3 has been renamed to eth0.
08:56:51 systemd-networkd[459]: eth0: Interface name change detected, 
eth0 has been renamed to ens3.

08:56:51 systemd-networkd[459]: ens3: IPv6 successfully enabled
08:56:51 systemd-networkd[459]: ens3: Link UP
08:56:51 systemd-networkd[459]: ens3: Gained carrier
...


As it appears to me, the eth0 settings from sysctl.conf have been 
accepted - at least no errors are logged in this regard -, but are lost, 
because the interface got renamed afterwards. The ens3 interface was not 
yet known at time of invoking systemd-sysctl, and therefore we get the 
errors. That in turn means, the settings are not being applied.


To make things worse, in sysctl.conf I've additionally set:

net.ipv6.conf.default.stable_secret=
net.ipv6.conf.default.addr_gen_mode=2
net.ipv6.conf.all.addr_gen_mode=2


Which results in all IP address having a stable privacy scope link, 
_execpt_ of course ens3. The one that would be by far most important.


What am I missing here? And insight is highly appreciated

Thanks

Ede
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel