Re: [systemd-devel] Running “telinit u” on glibc update

[Lennart Poettering]

On Mi, 16.05.18 15:01, Florian Weimer (fwei...@redhat.com) wrote:

> In Fedora, for historic reasons, we run “/sbin/telinit u” after installing a
> new glibc RPM package version.
> 
> Does this still make sense?  Should we remove the code which invokes telinit
> from the glibc package?

So I am pretty sure this is about not keeping the old .so images maps
pinned for good, i.e. so that they can be removed from disk and don't
keep the file system busy. This isn't really necessary in systemd
though, as we will always execve() from PID1 into a new process during
shutdown, which should drop all pinned pages anyway, unconditionally
and always.

Hence, no I don't think this needs to be there. I mean, I would see
value if we could unpin the old mapped .so images system-wide,
comprehensively, right away, but such a concept doesn't exist, we only
can can do this for some services, and it's racy and hence nothing we
should attempt. Doing this just for PID 1 hence doesn't really help
much, it's a drop of water on a hot stone.

Hence, please go aahead and drop it from the rpm scripts.

Lennart

-- 
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] DynamicUsers and read-only /var

[Lennart Poettering]

On Mi, 16.05.18 15:56, Simon McVittie (s...@collabora.com) wrote:

> On Wed, 16 May 2018 at 16:33:08 +0200, Antoine Pietri wrote:
> > On Wed, May 16 at 13:05 PM, Jérémy Rosen  wrote:
> > > hmm, I think you could have the whole /var as a tmpfs and use
> > > systemd-tmpfiles (man:tmpfiles.d) to initialize /var at startup by
> > > copying some template directory from a read-only location (typicalli in
> > > /usr)
> > 
> > That's another interesting workaround, but ideally we'd like to let
> > all the packages install stuff in /var/lib like they would normally,
> > and only put some tmpfs in /var after that.
> 
> The purpose of /var is that it contains variable data, so a read-only
> /var seems like a rather contradictory goal?
> 
> I think you'd really be better off redirecting the packaged
> or package-manager-produced contents of /var to /usr/var or
> /usr/share/factory/var or something (perhaps using your package
> manager's

Yes, /usr/share/factory is the recommended place for this, if you
follow tmpfiles.d logic. See the "C" specififier documentation for
tmpfiles.d, it suggests using that directory for the purpose of early
population of /var and /etc with non-empty files or dirs.

Lennart

-- 
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] DynamicUsers and read-only /var

[Lennart Poettering]

On Mi, 16.05.18 16:33, Antoine Pietri (antoine.piet...@gmail.com) wrote:

> Hi Jérémy,
> 
> On Wed, May 16 at 13:05 PM, Jérémy Rosen  wrote:
> > hmm, I think you could have the whole /var as a tmpfs and use
> > systemd-tmpfiles (man:tmpfiles.d) to initialize /var at startup by
> > copying some template directory from a read-only location (typicalli in
> > /usr)
>
> That's another interesting workaround, but ideally we'd like to let

It's not a "workaround". It's the recommended mode of operation to
support stateless systems and "factory reset" concepts, i.e. systems
that start with an empty, uninitialized /var.

Lennart

-- 
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] DynamicUsers and read-only /var

[Lennart Poettering]

On Mi, 16.05.18 13:29, Antoine Pietri (antoine.piet...@gmail.com) wrote:

> Hi,
> 
> Our organization uses a diskless setup to boot hundreds of machines
> using a read-only NFS export of their common rootfs.
> 
> To be able to run services that need to write in /var, we can't just
> have /var as a tmpfs, because it contains files installed by packages
> that are required by some services to run. Our current solution was to
> have /var in read-only, but have a list of directories where some
> services actually write (/var/log, /var/spool/mail, etc) and mount
> them as tmpfs.

Uh, if /var is read-only you kinda void your warranty. I mean, it's
already in the name that /var is "variable", no?

You are fine to make pretty much everything else read-only, but /tmp,
/var and /dev/shm really need to be writable for a normal system to
operate. They don't have to be persistant, but writable they really
should be. If you are this rule, then that's of course OK, but you get
to keep the pieces. This is even documented, very explicitly in
file-hierarchy(7).

I am not sure I grok your reason for making /var read-only
though. Note that today's systems should be mostly fine with /var
being empty at boot, as they ship enough configuration with tmpfiles.d
drop-ins so that what is missing in /var is created as needed early on
boot, and hence /var is sufficiently populated for everything to
work. If you are encounter a package that does not ship the right
tmpfiles.d/ snippets to make empty /var bootups just work, then please
consider working with the respective upstreams to fix that. It's as
easy as shipping one more drop-in file in the rpm/deb, and everybody's
life is easier.

In the unlikely case that some package needs files in /var that are
more than empty dirs/files with the right perms, then you can even
make use of tmpfiles' "factory logic" where it can automatically copy
a set of files from /usr early on, to ensure /var is properly
populated.

> This year, some services like systemd-timesyncd are shipped with
> DynamicUser=yes by default in our distribution (Archlinux), which
> means the above solution no longer works. My understanding is that
> systemd requires a writable /var to be able to symlink the state
> directory the first time it is launched.

Correct.

Lennart

-- 
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Can't connect to WiFi when the wired and the wireless interfaces are bonded

[Doron Behar]

I've found out that I'm experiencing this problem regardless of whether
the WiFi network was present or not when I booted - which is different
from what I've initially reported in my 1st message. 

I've created an issue report on systemd's issue tracker, I hope to get
more support there - https://github.com/systemd/systemd/issues/9011

On Wed, May 16, 2018 at 01:25:34PM -0400, Bruce A. Johnson wrote:
> I didn't see your in-line comments at first. I'm not part of the systemd
> development team (I'm just a "consumer", trying to give back), so I
> don't feel comfortable advising you to open a ticket, but I would at
> this point if I were you. I'll add a few more comments in-line below.
> 
> Good luck!
> 
> Bruce A. Johnson
> Herndon, Virginia
> 
> On 2018-05-16 12:34, Doron Behar wrote:
> > Currently I'm not residing at home were I use both interfaces to connect
> > to the same network, so I can't test this setup right now. In the
> > following experiments results following your suggestions, I didn't
> > connect any Ethernet cable.
> >
> >> Mantas seems to be correct that I was giving you a bum steer about
> >> putting the DHCP=Yes into 25-wireless.network. I haven't used bonding
> >> before, either. So please consider advice from someone who actually
> >> knows what he/she's doing in preference to anything I suggest.
> >>
> >> Have a look at how systemd obtains the IP address on the [presumably
> >> working] wired connection.
> >>
> >> # journalctl -b | grep DHCP
> >> May 16 15:32:47 rl-000db948364a systemd-networkd[382]: en01: DHCPv4 
> >> address 192.168.3.200/24 via 192.168.3.1
> > When I connect to the WiFi network only after boot, the command you used
> > above doesn't produce any output.
> If there is nothing from systemd-networkd about the IP address
> assignment and you having a working IP environment, it sounds like
> you're getting the IP address outside the systemd framework. That would
> probably preclude it from working with the active-backup configuration
> under systemd. I'm not sure whether wpa-supplicant does anything about
> getting an IP address, not having been there yet myself.
> >
> >> My Ethernet interface is called /en01/. I would expect your log to say
> >> it's /bond0/. Given that wireless interfaces look a lot like Ethernet
> >> interfaces, I don't see that you've done anything wrong, and maybe if
> >> you run dhcpd manually on  bond0 for diagnostic purposes, you'll see a
> >> better result in your test. The other thing would be to ping the default
> >> gateway (192.168.43.1 in your log), in case ICMP to the outside world is
> >> blocked. (The router might also block ICMP pings, though. It depends on
> >> the paranoia level of the network administrator.) If you've just brought
> >> up dhcpd, it's still running, and the IP layer is down already, that
> >> suggests to me that systemd-networkd has gotten in the way.
> > Well first of all, running `dhcpcd bond0` when I connect to the WiFi 
> > network only after
> > boot gives me this:
> >
> > dhcp6_listen: Address already in use
> > DUID 00:01:00:01:22:58:f0:ec:34:13:e8:35:48:e6
> > bond0: IAID c4:ca:ef:aa
> > bond0: soliciting an IPv6 router
> > bond0: soliciting a DHCP lease
> > bond0: no IPv6 Routers available
> >
> > And it's stuck there for a really long time..
> >
> > As for `ping`ing `192.168.43.1`, I get this output:
> >
> > connect: Network is unreachable
> >
> > My network infrastructure at the moment is a WiFi hotspot of my Android
> The gateway address would depend on the wireless network you're using,
> so if you were working from home WiFi before and are now working from a
> WiFi hotspot, there are reasonable odds the gateway address would be
> different. To find your gateway address without reading the log output
> from dhcpd, run /ip route/ and pick up the address on the default line:
> 
> $ ip route
> default via 10.100.1.1 dev en01  proto static  metric 100 
> 10.100.1.0/24 dev en01  proto kernel  scope link  src 10.100.1.64  metric 100 
> 
> In this example, the default gateway is 10.100.1.1, so if I were
> checking basic IP connectivity, I'd ping that address. (Although,
> honestly, if you have a default route, your IP is working and you're
> good to go.)
> 
> > device.
> >
> >> With wired interfaces, I swap the cable around all the time and
> >> systemd-networkd properly picks up the new IP configuration from DHCP.
> >> Maybe try a setup without the bond interface and see whether you can get
> >> IP working over wireless. I would expect systemd-networkd to gracefully
> >> handle DHCP configuration when you go out of range of the transmitter
> >> and return, or if you move to another SSID that's set up in
> >> wpa-supplicant. If that works, it suggests an issue with interface bonding.
> > As for moving away and returning to the range of a WiFi networks, it
> > should be noted that it works great without having a bonding
> > configuration - when using just a dumb `wireless.network` with:

Re: [systemd-devel] Can't connect to WiFi when the wired and the wireless interfaces are bonded

[Doron Behar]

I've found out that I'm experiencing this problem regardless of whether
the WiFi network was present or not when I booted - which is different
from what I've initially reported in my 1st message. 

I've created an issue report on systemd's issue tracker, I hope to get
more support there - 

On Wed, May 16, 2018 at 01:25:34PM -0400, Bruce A. Johnson wrote:
> I didn't see your in-line comments at first. I'm not part of the systemd
> development team (I'm just a "consumer", trying to give back), so I
> don't feel comfortable advising you to open a ticket, but I would at
> this point if I were you. I'll add a few more comments in-line below.
> 
> Good luck!
> 
> Bruce A. Johnson
> Herndon, Virginia
> 
> On 2018-05-16 12:34, Doron Behar wrote:
> > Currently I'm not residing at home were I use both interfaces to connect
> > to the same network, so I can't test this setup right now. In the
> > following experiments results following your suggestions, I didn't
> > connect any Ethernet cable.
> >
> >> Mantas seems to be correct that I was giving you a bum steer about
> >> putting the DHCP=Yes into 25-wireless.network. I haven't used bonding
> >> before, either. So please consider advice from someone who actually
> >> knows what he/she's doing in preference to anything I suggest.
> >>
> >> Have a look at how systemd obtains the IP address on the [presumably
> >> working] wired connection.
> >>
> >> # journalctl -b | grep DHCP
> >> May 16 15:32:47 rl-000db948364a systemd-networkd[382]: en01: DHCPv4 
> >> address 192.168.3.200/24 via 192.168.3.1
> > When I connect to the WiFi network only after boot, the command you used
> > above doesn't produce any output.
> If there is nothing from systemd-networkd about the IP address
> assignment and you having a working IP environment, it sounds like
> you're getting the IP address outside the systemd framework. That would
> probably preclude it from working with the active-backup configuration
> under systemd. I'm not sure whether wpa-supplicant does anything about
> getting an IP address, not having been there yet myself.
> >
> >> My Ethernet interface is called /en01/. I would expect your log to say
> >> it's /bond0/. Given that wireless interfaces look a lot like Ethernet
> >> interfaces, I don't see that you've done anything wrong, and maybe if
> >> you run dhcpd manually on  bond0 for diagnostic purposes, you'll see a
> >> better result in your test. The other thing would be to ping the default
> >> gateway (192.168.43.1 in your log), in case ICMP to the outside world is
> >> blocked. (The router might also block ICMP pings, though. It depends on
> >> the paranoia level of the network administrator.) If you've just brought
> >> up dhcpd, it's still running, and the IP layer is down already, that
> >> suggests to me that systemd-networkd has gotten in the way.
> > Well first of all, running `dhcpcd bond0` when I connect to the WiFi 
> > network only after
> > boot gives me this:
> >
> > dhcp6_listen: Address already in use
> > DUID 00:01:00:01:22:58:f0:ec:34:13:e8:35:48:e6
> > bond0: IAID c4:ca:ef:aa
> > bond0: soliciting an IPv6 router
> > bond0: soliciting a DHCP lease
> > bond0: no IPv6 Routers available
> >
> > And it's stuck there for a really long time..
> >
> > As for `ping`ing `192.168.43.1`, I get this output:
> >
> > connect: Network is unreachable
> >
> > My network infrastructure at the moment is a WiFi hotspot of my Android
> The gateway address would depend on the wireless network you're using,
> so if you were working from home WiFi before and are now working from a
> WiFi hotspot, there are reasonable odds the gateway address would be
> different. To find your gateway address without reading the log output
> from dhcpd, run /ip route/ and pick up the address on the default line:
> 
> $ ip route
> default via 10.100.1.1 dev en01  proto static  metric 100 
> 10.100.1.0/24 dev en01  proto kernel  scope link  src 10.100.1.64  metric 100 
> 
> In this example, the default gateway is 10.100.1.1, so if I were
> checking basic IP connectivity, I'd ping that address. (Although,
> honestly, if you have a default route, your IP is working and you're
> good to go.)
> 
> > device.
> >
> >> With wired interfaces, I swap the cable around all the time and
> >> systemd-networkd properly picks up the new IP configuration from DHCP.
> >> Maybe try a setup without the bond interface and see whether you can get
> >> IP working over wireless. I would expect systemd-networkd to gracefully
> >> handle DHCP configuration when you go out of range of the transmitter
> >> and return, or if you move to another SSID that's set up in
> >> wpa-supplicant. If that works, it suggests an issue with interface bonding.
> > As for moving away and returning to the range of a WiFi networks, it
> > should be noted that it works great without having a bonding
> > configuration - when using just a dumb `wireless.network` with:
> >
> > [Match]
> > Name=wlp2s0
> >
> 

Re: [systemd-devel] Can't connect to WiFi when the wired and the wireless interfaces are bonded

[Bruce A. Johnson]

I didn't see your in-line comments at first. I'm not part of the systemd
development team (I'm just a "consumer", trying to give back), so I
don't feel comfortable advising you to open a ticket, but I would at
this point if I were you. I'll add a few more comments in-line below.

Good luck!

Bruce A. Johnson
Herndon, Virginia

On 2018-05-16 12:34, Doron Behar wrote:
> Currently I'm not residing at home were I use both interfaces to connect
> to the same network, so I can't test this setup right now. In the
> following experiments results following your suggestions, I didn't
> connect any Ethernet cable.
>
>> Mantas seems to be correct that I was giving you a bum steer about
>> putting the DHCP=Yes into 25-wireless.network. I haven't used bonding
>> before, either. So please consider advice from someone who actually
>> knows what he/she's doing in preference to anything I suggest.
>>
>> Have a look at how systemd obtains the IP address on the [presumably
>> working] wired connection.
>>
>> # journalctl -b | grep DHCP
>> May 16 15:32:47 rl-000db948364a systemd-networkd[382]: en01: DHCPv4 address 
>> 192.168.3.200/24 via 192.168.3.1
> When I connect to the WiFi network only after boot, the command you used
> above doesn't produce any output.
If there is nothing from systemd-networkd about the IP address
assignment and you having a working IP environment, it sounds like
you're getting the IP address outside the systemd framework. That would
probably preclude it from working with the active-backup configuration
under systemd. I'm not sure whether wpa-supplicant does anything about
getting an IP address, not having been there yet myself.
>
>> My Ethernet interface is called /en01/. I would expect your log to say
>> it's /bond0/. Given that wireless interfaces look a lot like Ethernet
>> interfaces, I don't see that you've done anything wrong, and maybe if
>> you run dhcpd manually on  bond0 for diagnostic purposes, you'll see a
>> better result in your test. The other thing would be to ping the default
>> gateway (192.168.43.1 in your log), in case ICMP to the outside world is
>> blocked. (The router might also block ICMP pings, though. It depends on
>> the paranoia level of the network administrator.) If you've just brought
>> up dhcpd, it's still running, and the IP layer is down already, that
>> suggests to me that systemd-networkd has gotten in the way.
> Well first of all, running `dhcpcd bond0` when I connect to the WiFi network 
> only after
> boot gives me this:
>
> dhcp6_listen: Address already in use
> DUID 00:01:00:01:22:58:f0:ec:34:13:e8:35:48:e6
> bond0: IAID c4:ca:ef:aa
> bond0: soliciting an IPv6 router
> bond0: soliciting a DHCP lease
> bond0: no IPv6 Routers available
>
> And it's stuck there for a really long time..
>
> As for `ping`ing `192.168.43.1`, I get this output:
>
> connect: Network is unreachable
>
> My network infrastructure at the moment is a WiFi hotspot of my Android
The gateway address would depend on the wireless network you're using,
so if you were working from home WiFi before and are now working from a
WiFi hotspot, there are reasonable odds the gateway address would be
different. To find your gateway address without reading the log output
from dhcpd, run /ip route/ and pick up the address on the default line:

$ ip route
default via 10.100.1.1 dev en01  proto static  metric 100 
10.100.1.0/24 dev en01  proto kernel  scope link  src 10.100.1.64  metric 100 

In this example, the default gateway is 10.100.1.1, so if I were
checking basic IP connectivity, I'd ping that address. (Although,
honestly, if you have a default route, your IP is working and you're
good to go.)

> device.
>
>> With wired interfaces, I swap the cable around all the time and
>> systemd-networkd properly picks up the new IP configuration from DHCP.
>> Maybe try a setup without the bond interface and see whether you can get
>> IP working over wireless. I would expect systemd-networkd to gracefully
>> handle DHCP configuration when you go out of range of the transmitter
>> and return, or if you move to another SSID that's set up in
>> wpa-supplicant. If that works, it suggests an issue with interface bonding.
> As for moving away and returning to the range of a WiFi networks, it
> should be noted that it works great without having a bonding
> configuration - when using just a dumb `wireless.network` with:
>
> [Match]
> Name=wlp2s0
>
> [Network]
> DHCP=yes
>
>> Another thing you might do is set up .network files for the interfaces
>> that include a route metric of 0 for the wired (preferred) interface and
>> 1 for the wireless:
>>
>> [Match]
>> Name=en02
>>
>> [Network]
>> Description=WAN connection on en02
>> DHCP=yes
>>
>> [DHCP]
>> RouteMetric=1
> Adding the entry `RouteMetric=1` for the `[DHCP]` section in my
> `bonding.network` doesn't help at all.
I should have specified you'd need two separate files and no bond
interfaces. In my case, I've got 80-en01.network

Re: [systemd-devel] Can't connect to WiFi when the wired and the wireless interfaces are bonded

[Doron Behar]

Currently I'm not residing at home were I use both interfaces to connect
to the same network, so I can't test this setup right now. In the
following experiments results following your suggestions, I didn't
connect any Ethernet cable.

> Mantas seems to be correct that I was giving you a bum steer about
> putting the DHCP=Yes into 25-wireless.network. I haven't used bonding
> before, either. So please consider advice from someone who actually
> knows what he/she's doing in preference to anything I suggest.
> 
> Have a look at how systemd obtains the IP address on the [presumably
> working] wired connection.
> 
> # journalctl -b | grep DHCP
> May 16 15:32:47 rl-000db948364a systemd-networkd[382]: en01: DHCPv4 address 
> 192.168.3.200/24 via 192.168.3.1

When I connect to the WiFi network only after boot, the command you used
above doesn't produce any output.

> 
> My Ethernet interface is called /en01/. I would expect your log to say
> it's /bond0/. Given that wireless interfaces look a lot like Ethernet
> interfaces, I don't see that you've done anything wrong, and maybe if
> you run dhcpd manually on  bond0 for diagnostic purposes, you'll see a
> better result in your test. The other thing would be to ping the default
> gateway (192.168.43.1 in your log), in case ICMP to the outside world is
> blocked. (The router might also block ICMP pings, though. It depends on
> the paranoia level of the network administrator.) If you've just brought
> up dhcpd, it's still running, and the IP layer is down already, that
> suggests to me that systemd-networkd has gotten in the way.

Well first of all, running `dhcpcd bond0` when I connect to the WiFi network 
only after
boot gives me this:

dhcp6_listen: Address already in use
DUID 00:01:00:01:22:58:f0:ec:34:13:e8:35:48:e6
bond0: IAID c4:ca:ef:aa
bond0: soliciting an IPv6 router
bond0: soliciting a DHCP lease
bond0: no IPv6 Routers available

And it's stuck there for a really long time..

As for `ping`ing `192.168.43.1`, I get this output:

connect: Network is unreachable

My network infrastructure at the moment is a WiFi hotspot of my Android
device.

> With wired interfaces, I swap the cable around all the time and
> systemd-networkd properly picks up the new IP configuration from DHCP.
> Maybe try a setup without the bond interface and see whether you can get
> IP working over wireless. I would expect systemd-networkd to gracefully
> handle DHCP configuration when you go out of range of the transmitter
> and return, or if you move to another SSID that's set up in
> wpa-supplicant. If that works, it suggests an issue with interface bonding.

As for moving away and returning to the range of a WiFi networks, it
should be noted that it works great without having a bonding
configuration - when using just a dumb `wireless.network` with:

[Match]
Name=wlp2s0

[Network]
DHCP=yes

> 
> Another thing you might do is set up .network files for the interfaces
> that include a route metric of 0 for the wired (preferred) interface and
> 1 for the wireless:
> 
> [Match]
> Name=en02
> 
> [Network]
> Description=WAN connection on en02
> DHCP=yes
> 
> [DHCP]
> RouteMetric=1

Adding the entry `RouteMetric=1` for the `[DHCP]` section in my
`bonding.network` doesn't help at all.

Should I open an issue on systemd's issues tracker?

> 
> I'm using those successfully in my set-up, but the two interfaces are
> separate subnets. Still, I would expect it to work were they on the same
> subnet.
> 
> I hope this helps, and I'm looking forward to learning more from what
> you find out and what others suggest.
> 
> Bruce A. Johnson
> Herndon, Virginia
> 
> On 2018-05-16 07:10, Doron Behar wrote:
> > I agree. This is what I understood from the manual pages. I've even
> > tried to run `dhcpcd wlp2s0` manually after I've connected to the WiFi
> > network and it didn't help either. Here is `dhcpcd`'s output:
> >
> > DUID 00:01:00:01:22:58:f0:ec:34:13:e8:35:48:e6
> > wlp2s0: IAID c4:ca:ef:aa
> > wlp2s0: adding address fe80::bf80:8309:6514:f4ff
> > wlp2s0: soliciting a DHCP lease
> > wlp2s0: soliciting an IPv6 router
> > wlp2s0: offered 192.168.43.146 from 192.168.43.1
> > wlp2s0: probing address 192.168.43.146/24
> > wlp2s0: leased 192.168.43.146 for 3600 seconds
> > wlp2s0: adding route to 192.168.43.0/24
> > wlp2s0: adding default route via 192.168.43.1
> > forked to background, child pid 1142
> >
> > It does seem to be working yet I'm not really connected to the internet,
> > `ping 8.8.8.8` doesn't work.
> >
> > On Wed, May 16, 2018 at 09:14:01AM +0300, Mantas Mikulėnas wrote:
>         .     .    .
> >> I believe the individual bonded interfaces don't *need* to speak IP
> >> at all;
> >> only the 'main' bond itself does.
> >>
> >> -- 
> >> Mantas Mikulėnas
> 
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listin

Re: [systemd-devel] Can't connect to WiFi when the wired and the wireless interfaces are bonded

[Bruce A. Johnson]

Mantas seems to be correct that I was giving you a bum steer about
putting the DHCP=Yes into 25-wireless.network. I haven't used bonding
before, either. So please consider advice from someone who actually
knows what he/she's doing in preference to anything I suggest.

Have a look at how systemd obtains the IP address on the [presumably
working] wired connection.

# journalctl -b | grep DHCP
May 16 15:32:47 rl-000db948364a systemd-networkd[382]: en01: DHCPv4 address 
192.168.3.200/24 via 192.168.3.1

My Ethernet interface is called /en01/. I would expect your log to say
it's /bond0/. Given that wireless interfaces look a lot like Ethernet
interfaces, I don't see that you've done anything wrong, and maybe if
you run dhcpd manually on  bond0 for diagnostic purposes, you'll see a
better result in your test. The other thing would be to ping the default
gateway (192.168.43.1 in your log), in case ICMP to the outside world is
blocked. (The router might also block ICMP pings, though. It depends on
the paranoia level of the network administrator.) If you've just brought
up dhcpd, it's still running, and the IP layer is down already, that
suggests to me that systemd-networkd has gotten in the way.

With wired interfaces, I swap the cable around all the time and
systemd-networkd properly picks up the new IP configuration from DHCP.
Maybe try a setup without the bond interface and see whether you can get
IP working over wireless. I would expect systemd-networkd to gracefully
handle DHCP configuration when you go out of range of the transmitter
and return, or if you move to another SSID that's set up in
wpa-supplicant. If that works, it suggests an issue with interface bonding.

Another thing you might do is set up .network files for the interfaces
that include a route metric of 0 for the wired (preferred) interface and
1 for the wireless:

[Match]
Name=en02

[Network]
Description=WAN connection on en02
DHCP=yes

[DHCP]
RouteMetric=1

I'm using those successfully in my set-up, but the two interfaces are
separate subnets. Still, I would expect it to work were they on the same
subnet.

I hope this helps, and I'm looking forward to learning more from what
you find out and what others suggest.

Bruce A. Johnson
Herndon, Virginia

On 2018-05-16 07:10, Doron Behar wrote:
> I agree. This is what I understood from the manual pages. I've even
> tried to run `dhcpcd wlp2s0` manually after I've connected to the WiFi
> network and it didn't help either. Here is `dhcpcd`'s output:
>
>   DUID 00:01:00:01:22:58:f0:ec:34:13:e8:35:48:e6
>   wlp2s0: IAID c4:ca:ef:aa
>   wlp2s0: adding address fe80::bf80:8309:6514:f4ff
>   wlp2s0: soliciting a DHCP lease
>   wlp2s0: soliciting an IPv6 router
>   wlp2s0: offered 192.168.43.146 from 192.168.43.1
>   wlp2s0: probing address 192.168.43.146/24
>   wlp2s0: leased 192.168.43.146 for 3600 seconds
>   wlp2s0: adding route to 192.168.43.0/24
>   wlp2s0: adding default route via 192.168.43.1
>   forked to background, child pid 1142
>
> It does seem to be working yet I'm not really connected to the internet,
> `ping 8.8.8.8` doesn't work.
>
> On Wed, May 16, 2018 at 09:14:01AM +0300, Mantas Mikulėnas wrote:
        .     .    .
>> I believe the individual bonded interfaces don't *need* to speak IP
>> at all;
>> only the 'main' bond itself does.
>>
>> -- 
>> Mantas Mikulėnas

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

Re: [systemd-devel] DynamicUsers and read-only /var

[Simon McVittie]

On Wed, 16 May 2018 at 16:33:08 +0200, Antoine Pietri wrote:
> On Wed, May 16 at 13:05 PM, Jérémy Rosen  wrote:
> > hmm, I think you could have the whole /var as a tmpfs and use
> > systemd-tmpfiles (man:tmpfiles.d) to initialize /var at startup by
> > copying some template directory from a read-only location (typicalli in
> > /usr)
> 
> That's another interesting workaround, but ideally we'd like to let
> all the packages install stuff in /var/lib like they would normally,
> and only put some tmpfs in /var after that.

The purpose of /var is that it contains variable data, so a read-only
/var seems like a rather contradictory goal?

I think you'd really be better off redirecting the packaged
or package-manager-produced contents of /var to /usr/var or
/usr/share/factory/var or something (perhaps using your package manager's
equivalent of dpkg-divert if it has one), and using systemd-tmpfiles to
populate a tmpfs with copies or symbolic links (or possibly bind-mounting
selected directories from the read-only copy, if entire subtrees like
/var/lib/dpkg are read-only except during package manager operations).

Projects like libostree and rpm-ostree might have some useful concepts
or code for managing immutable, read-only rootfs or /usr deployments,
since that's what they do: in an ostree-based OS, /usr is an
atomically-updated immutable tree, directories like /var and /home are
locally-maintained, and /etc is a three-way merge between the old
/usr/etc, the new /usr/etc and the local /etc.

smcv

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

Re: [systemd-devel] DynamicUsers and read-only /var

[Antoine Pietri]

Hi Jérémy,

On Wed, May 16 at 13:05 PM, Jérémy Rosen  wrote:
> hmm, I think you could have the whole /var as a tmpfs and use
> systemd-tmpfiles (man:tmpfiles.d) to initialize /var at startup by
> copying some template directory from a read-only location (typicalli in
> /usr)

That's another interesting workaround, but ideally we'd like to let
all the packages install stuff in /var/lib like they would normally,
and only put some tmpfs in /var after that. I'll still keep that
solution in my mind if we have to use overlayfs and it doesn't work
for some reason.

Thanks,

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

Re: [systemd-devel] Running “telinit u” on glibc update

[Michael Biebl]

Hi Florian

2018-05-16 15:01 GMT+02:00 Florian Weimer :
> In Fedora, for historic reasons, we run “/sbin/telinit u” after installing a
> new glibc RPM package version.
>
> Does this still make sense?  Should we remove the code which invokes telinit
> from the glibc package?

We had something similar in the Debian glibc package
The background is in this bug report
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=753725

Afaiu, the telinit u was originally added so sysvinit can shutdown
cleanly and there were no open fds:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=25444

But this is not an issue with systemd/systemd-shutdown.
As the daemon-reexec was causing issues in Debian, we decided to
remove it from the glibc postinst.

Regards,
Michael
-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Running “telinit u” on glibc update

[Reindl Harald]

Am 16.05.2018 um 15:01 schrieb Florian Weimer:
> In Fedora, for historic reasons, we run “/sbin/telinit u” after
> installing a new glibc RPM package version.
> 
> Does this still make sense?  Should we remove the code which invokes
> telinit from the glibc package?

how do you come to that conclusion given it's part of systemd and
repsonsible to trigger "systemctl daemon-reexec" after said updates?

[root@buildserver:~]$ which telinit
/usr/sbin/telinit

[root@buildserver:~]$ rpm -q --file /usr/sbin/telinit
systemd-234-11.git5f8984e.fc27.x86_6
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] DynamicUsers and read-only /var

[Jérémy Rosen]

hmm, I think you could have the whole /var as a tmpfs and use 
systemd-tmpfiles (man:tmpfiles.d) to initialize /var at startup by 
copying some template directory from a read-only location (typicalli in 
/usr)


On 16/05/2018 13:29, Antoine Pietri wrote:

Hi,

Our organization uses a diskless setup to boot hundreds of machines
using a read-only NFS export of their common rootfs.

To be able to run services that need to write in /var, we can't just
have /var as a tmpfs, because it contains files installed by packages
that are required by some services to run. Our current solution was to
have /var in read-only, but have a list of directories where some
services actually write (/var/log, /var/spool/mail, etc) and mount
them as tmpfs.

This year, some services like systemd-timesyncd are shipped with
DynamicUser=yes by default in our distribution (Archlinux), which
means the above solution no longer works. My understanding is that
systemd requires a writable /var to be able to symlink the state
directory the first time it is launched.

Our only option here, if we don't want to manually disable dynamic
users in all the services, seems to be to mount /var in a
copy-on-write overlayfs. We could do that, but it's a bit cutting edge
and dangerous for us. Two years ago, overlayfs didn't even support nfs
as its lower directory, that's why we avoided it so far.

As I know you don't like to add requirements to have a writable /var,
I'd love to have your input on this issue! Is there anything we missed
that would allow us to keep using dynamic user services with a
read-only /var, or do we have to use the overlay solution?

Thanks,



--
SMILE 

20 rue des Jardins
92600 Asnières-sur-Seine


*Jérémy ROSEN*
Architecte technique
Responsable de l'expertise Smile-ECS

email jeremy.ro...@smile.fr 
phone +33141402967
url http://www.smile.eu

Twitter  Facebook 
 LinkedIn 
 Github 




Découvrez l’univers Smile, rendez-vous sur smile.eu 



eco Pour la planète, n'imprimez ce mail que si c'est nécessaire
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] Running “telinit u” on glibc update

[Florian Weimer]

In Fedora, for historic reasons, we run “/sbin/telinit u” after 
installing a new glibc RPM package version.


Does this still make sense?  Should we remove the code which invokes 
telinit from the glibc package?


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

[systemd-devel] DynamicUsers and read-only /var

[Antoine Pietri]

Hi,

Our organization uses a diskless setup to boot hundreds of machines
using a read-only NFS export of their common rootfs.

To be able to run services that need to write in /var, we can't just
have /var as a tmpfs, because it contains files installed by packages
that are required by some services to run. Our current solution was to
have /var in read-only, but have a list of directories where some
services actually write (/var/log, /var/spool/mail, etc) and mount
them as tmpfs.

This year, some services like systemd-timesyncd are shipped with
DynamicUser=yes by default in our distribution (Archlinux), which
means the above solution no longer works. My understanding is that
systemd requires a writable /var to be able to symlink the state
directory the first time it is launched.

Our only option here, if we don't want to manually disable dynamic
users in all the services, seems to be to mount /var in a
copy-on-write overlayfs. We could do that, but it's a bit cutting edge
and dangerous for us. Two years ago, overlayfs didn't even support nfs
as its lower directory, that's why we avoided it so far.

As I know you don't like to add requirements to have a writable /var,
I'd love to have your input on this issue! Is there anything we missed
that would allow us to keep using dynamic user services with a
read-only /var, or do we have to use the overlay solution?

Thanks,

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

Re: [systemd-devel] Can't connect to WiFi when the wired and the wireless interfaces are bonded

[Doron Behar]

I agree. This is what I understood from the manual pages. I've even
tried to run `dhcpcd wlp2s0` manually after I've connected to the WiFi
network and it didn't help either. Here is `dhcpcd`'s output:

DUID 00:01:00:01:22:58:f0:ec:34:13:e8:35:48:e6
wlp2s0: IAID c4:ca:ef:aa
wlp2s0: adding address fe80::bf80:8309:6514:f4ff
wlp2s0: soliciting a DHCP lease
wlp2s0: soliciting an IPv6 router
wlp2s0: offered 192.168.43.146 from 192.168.43.1
wlp2s0: probing address 192.168.43.146/24
wlp2s0: leased 192.168.43.146 for 3600 seconds
wlp2s0: adding route to 192.168.43.0/24
wlp2s0: adding default route via 192.168.43.1
forked to background, child pid 1142

It does seem to be working yet I'm not really connected to the internet,
`ping 8.8.8.8` doesn't work.

On Wed, May 16, 2018 at 09:14:01AM +0300, Mantas Mikulėnas wrote:
> On Wed, May 16, 2018 at 12:47 AM Bruce A. Johnson <
> bjohn...@blueridgenetworks.com> wrote:
> 
> > Doron,
> >
> > I don't see any mention of DHCP in  your wireless network definition, so
> > I'm dubious that your system has made any attempt at getting an IP address
> > on wlp2s0. Try adding *DHCP=yes* to the *[Network]* section of
> > 25-wireless.network.
> >
> > I haven't done a wireless setup with systemd yet, nor have I tried the
> > active-backup configuration you're working with, so I may be completely
> > wrong. Please let me know whether or not it works.
> >
> I believe the individual bonded interfaces don't *need* to speak IP at all;
> only the 'main' bond itself does.
> 
> -- 
> Mantas Mikulėnas
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel