[-] dix get_dev in namespaced environments

[df7cb]

Commit cd9ab29 fixed device selection in environments that have
multiple devices, but unfortunately broke it on apt.postgresql.org,
where the tests are running in network namespaces via veth/ceth devices.
This fixes the detection to support both.

[df7cb]

The problem here was that /sys/class/net/* lists all the devices from the host system, but inside the network namespace, only one is present (and moreover, it has the wrong end of the ceth/veth pair). "ip link" has the correct list.

[tpo]

On my laptop:

$ cat pre 
ARPHRD_ETHER=1

    for dev in /sys/class/net/* ; do
        test ! -e "$dev/address" && continue
        test "`cat $dev/address`" = "00:00:00:00:00:00" && continue
        test "`cat $dev/type`" != "$ARPHRD_ETHER" && continue
        basename "$dev"
        break
    done

$ cat post  
ip -oneline link show | grep link/ether | grep -v 00:00:00:00:00:00 | cut -d ":" -f2 | cut -d "@" -f 1

$ source pre
docker0

$ source post
 wlo1
 docker0

So the new version of the code does not strictly behave like the old code: it does not check the network type.

Is that relevant?

[df7cb]

Hmm, true. On my laptop, the first one returns eth0, while the new one returns

 eth0
 wlan2
 veth1

We should probably just append | head -n1 to the new version since that one actually fixes a problem on apt.postgresql.org.

[tpo]

Hi @df7cb

Hmm, true. On my laptop, the first one returns eth0, while the new one returns

 eth0
 wlan2
 veth1

We should probably just append | head -n1 to the new version since that one actually fixes a problem on apt.postgresql.org.

Is it guaranteed, that ip -oneline link show outputs the Ethernet interfaces first? As before: I'm not sure my critique is relevant, since I haven't checked in which context this code gets used. I just know that network interface naming in modern Linux systems is quite incomprehensible to me so I wouln't be suprised at all, if udev or whoever is responsible for naming would name the Ethernet interface zaziki99 and the WLAN interface aleph1 and thereby possibly returning the WLAN interface first in the list...

But as I said, no idea if my criticism is relevant. I'm just observing that the code before and after do not behave in the same way.

[df7cb]

I don't know about any ordering constraints, but I'd say the old for dev in /sys/class/net/* code didn't care about that either, so it won't change the quality of the result.

[df7cb]

Is it guaranteed, that ip -oneline link show outputs the Ethernet interfaces first? As before: I'm not sure my critique is relevant, since I haven't checked in which context this code gets used. I just know that network interface naming in modern Linux systems is quite incomprehensible to me so I wouln't be suprised at all, if udev or whoever is responsible for naming would name the Ethernet interface zaziki99 and the WLAN interface aleph1 and thereby possibly returning the WLAN interface first in the list...

WLAN interfaces are ether as well, so that wouldn't make a difference. From what I can tell, all that's relevant here is that we find an interface that has an IP that can be used for testing.

[pashagolub]

hey there. Sorry for such a delay. Tough time, eh.

So is this PR still valid and should be applied?

Best regards

[df7cb]

Hi Pavlo,
yes it still fixes the test problems we've had with vip-manager on apt.postgresql.org.
Christoph

[pashagolub]

Thanks Christoph!

Merged! 👍

[df7cb]

Thanks!

[pashagolub]

Speaking of apt.postgresql.org...

@df7cb are you using scripts/files from package folder or do you have your own?

The reason is I want to establish GHA workflow for automatic packaging/building and want to know if I'm allowed make some changes to those files.

We are preparing the v2-beta with some breaking changes and I'm trying to figure out what exactly I can drop/change but to leave everybody happy

[df7cb]

The packaging files are there: https://salsa.debian.org/postgresql/vip-manager/-/tree/master/debian

We are not using anything from the package except for what gets invoked by the normal build system, i.e. what gets invoked by dh $@ --buildsystem=golang --with=golang: https://salsa.debian.org/postgresql/vip-manager/-/blob/master/debian/rules