That's a new one.
-
That's a new one. Upgraded my router from Debian bookworm to trixie and all of the sysctls (including rather important ones like ipv4 and ipv6 forwarding) that I had set in /etc/sysctl.conf no longer applied, the file was moved to a .bak but not migrated to whatever Debian is trying to force me onto instead.
But overall far from the most painful distro upgrade I've had. I was worried all of my NICs would change names (again) and I'd have to rebuild my whole firewall configuration.
-
That's a new one. Upgraded my router from Debian bookworm to trixie and all of the sysctls (including rather important ones like ipv4 and ipv6 forwarding) that I had set in /etc/sysctl.conf no longer applied, the file was moved to a .bak but not migrated to whatever Debian is trying to force me onto instead.
But overall far from the most painful distro upgrade I've had. I was worried all of my NICs would change names (again) and I'd have to rebuild my whole firewall configuration.
(considering I have a dual 100G NIC, a dual 1G NIC, a VPN tunnel, and close to 20 VLAN subinterfaces, that would have taken... a while)
-
That's a new one. Upgraded my router from Debian bookworm to trixie and all of the sysctls (including rather important ones like ipv4 and ipv6 forwarding) that I had set in /etc/sysctl.conf no longer applied, the file was moved to a .bak but not migrated to whatever Debian is trying to force me onto instead.
But overall far from the most painful distro upgrade I've had. I was worried all of my NICs would change names (again) and I'd have to rebuild my whole firewall configuration.
@azonenberg@ioc.exchange afair it wants you to move it to sysctl.d - or at least that's what a recent ubuntu upgrade at $dayjob mandated. it's moronic, it had no need to be done, but that's debian for you
-
@azonenberg@ioc.exchange afair it wants you to move it to sysctl.d - or at least that's what a recent ubuntu upgrade at $dayjob mandated. it's moronic, it had no need to be done, but that's debian for you
@domi like the refactoring is dumb but i don't mind it.
what i do mind is it breaking rather than moving all of my config to sysctl.d/legacy.conf or something and letting me split it out if and when i want
-
@domi like the refactoring is dumb but i don't mind it.
what i do mind is it breaking rather than moving all of my config to sysctl.d/legacy.conf or something and letting me split it out if and when i want
@domi (I'm very much old school on a bunch of things, I still configure stuff in /etc/network/interfaces and add new wifi networks to my laptop by editing /etc/wpa_supplicant/wpa_supplicant.conf in nano)
-
@domi like the refactoring is dumb but i don't mind it.
what i do mind is it breaking rather than moving all of my config to sysctl.d/legacy.conf or something and letting me split it out if and when i want
@azonenberg@ioc.exchange i do mind it, because it's yet another distro changing something for no reason and fragmenting a good feature
guess it's fine if you use/administer one box, or boxen on one distro. but I touch at least three distros in prod, sometimes more for local fucking around, and it's exhausting to go round and remember about all the stupid papercuts that maintainers implemented for their own amusement. this is certainly not making it any better
-
@domi (I'm very much old school on a bunch of things, I still configure stuff in /etc/network/interfaces and add new wifi networks to my laptop by editing /etc/wpa_supplicant/wpa_supplicant.conf in nano)
@azonenberg@ioc.exchange I stopped using /etc/network/interfaces because there are at least 2 incompatible implementations in current use, and neither has really good docs for itself...
wpa_supplicant.conf is fine tho, I do that too. (albeit through wpa_gui most of the time)
-
@azonenberg@ioc.exchange i do mind it, because it's yet another distro changing something for no reason and fragmenting a good feature
guess it's fine if you use/administer one box, or boxen on one distro. but I touch at least three distros in prod, sometimes more for local fucking around, and it's exhausting to go round and remember about all the stupid papercuts that maintainers implemented for their own amusement. this is certainly not making it any better
@domi What i mean is, I dislike backend refactoring a lot less than I dislike breakage.
When they changed network device enumeration every release several times in a row? THAT bothered me.
Little things like changing package names between releases or moving a config file, if the migration is done properly, generally don't cost me any time.
-
@domi What i mean is, I dislike backend refactoring a lot less than I dislike breakage.
When they changed network device enumeration every release several times in a row? THAT bothered me.
Little things like changing package names between releases or moving a config file, if the migration is done properly, generally don't cost me any time.
@azonenberg@ioc.exchange oh, also: all my non-dayjob boxes run with net.ifnames=0, which returns the previous "non-predictable" device names, a move which has likely elongated my life by a good year or two
-
@azonenberg@ioc.exchange oh, also: all my non-dayjob boxes run with net.ifnames=0, which returns the previous "non-predictable" device names, a move which has likely elongated my life by a good year or two
@domi I don't mind predictable names if they are actually predictable since I tend to have a LOT of nics.
But if it's enp3s0 and then I update and it's suddenly eno1, then next release it's enp6s0, and I add a new SSD and it's enp5s0 now? That's not good.
-
@domi I don't mind predictable names if they are actually predictable since I tend to have a LOT of nics.
But if it's enp3s0 and then I update and it's suddenly eno1, then next release it's enp6s0, and I add a new SSD and it's enp5s0 now? That's not good.
@azonenberg@ioc.exchange i would take predictable names if they'd resolve to
en<MAC>by default -
@azonenberg@ioc.exchange i would take predictable names if they'd resolve to
en<MAC>by default@domi @azonenberg I should write this udev rule :^) (actually can you? I'm not sure udev is mac-aware) -
@azonenberg@ioc.exchange i would take predictable names if they'd resolve to
en<MAC>by default@domi That would be awesome, since it would also (unlike the current "predictable" ones) be stable if you moved the nic between slots, something I have to do sometimes
-
@domi @azonenberg I should write this udev rule :^) (actually can you? I'm not sure udev is mac-aware)
@toast @azonenberg@ioc.exchange probably not, but I bet you can do some hacks to extract a MAC anyways
-
@toast @azonenberg@ioc.exchange probably not, but I bet you can do some hacks to extract a MAC anyways
@domi @azonenberg hmm, you might be able to? cursory reading of udev(7) suggests ATTR{} is a thin layer over sysfs, and in sysfs you have device/address which contains the MAC… -
@domi @azonenberg hmm, you might be able to? cursory reading of udev(7) suggests ATTR{} is a thin layer over sysfs, and in sysfs you have device/address which contains the MAC…
@domi @azonenberg@ioc.exchange hello from enx5847[censored]
I was going to go into the deep end but turns out the same script used for "predictable inames" actually exports this information too, but never uses it in the default script
looks like so to get this working:ACTION!="add", GOTO="net_name_slot_end" SUBSYSTEM!="net", GOTO="net_name_slot_end" NAME!="", GOTO="net_name_slot_end" IMPORT{cmdline}="net.ifnames" ENV{net.ifnames}=="0", GOTO="net_name_slot_end" NAME=="", ENV{ID_NET_NAME_MAC}!="", NAME="$env{ID_NET_NAME_MAC}" LABEL="net_name_slot_end"save as /etc/udev/rules.d/80-net-name-slot.rules
the line starting withNAME==""is the only important one realistically
it does look like$attr{address}should also match but then you have to add the en/wl/etc prefix yourself (which could probably be done using KERNEL==… I might poke at that after my meeting) -
@toast @azonenberg@ioc.exchange probably not, but I bet you can do some hacks to extract a MAC anyways
@domi @toast @azonenberg it is! I do this in my laptop's udev config:
SUBSYSTEM=="net", ACTION=="add", ATTR{address}=="84:ba:59:38:80:77", NAME="eth-onboard"
SUBSYSTEM=="net", ACTION=="add", ATTR{address}=="34:99:71:00:0f:63", NAME="eth-dock"
SUBSYSTEM=="net", ACTION=="add", ATTR{address}=="a0:d3:65:a8:1f:ba", NAME="wlan0" -
That's a new one. Upgraded my router from Debian bookworm to trixie and all of the sysctls (including rather important ones like ipv4 and ipv6 forwarding) that I had set in /etc/sysctl.conf no longer applied, the file was moved to a .bak but not migrated to whatever Debian is trying to force me onto instead.
But overall far from the most painful distro upgrade I've had. I was worried all of my NICs would change names (again) and I'd have to rebuild my whole firewall configuration.
@azonenberg Fwiw it was mentioned in the release notes - https://www.debian.org/releases/trixie/release-notes/issues.en.html#etc-sysctl-conf-is-no-longer-honored
-
@azonenberg Fwiw it was mentioned in the release notes - https://www.debian.org/releases/trixie/release-notes/issues.en.html#etc-sysctl-conf-is-no-longer-honored
@cmm11 failing to move the existing sysctl.conf to the new location is still a bug imo
-
R relay@relay.infosec.exchange shared this topic
