[Solved] Tracking down arch interface configuration files.

GaKu999 · 2020-09-17 03:06:31

RageBanken wrote:

Do the files in /usr/lib/systemd/network/ get overwritten or recreated when running a system update?

Yes, the better approach is to override it with a link to '/dev/null' in '/etc/systemd/network/99-default.link', if you really want to nuke it...

# ln -sf /dev/null /etc/systemd/network/99-default.link

Any reason in particular?
You can change the behavior instead of nullifying it, just copy into the same path, and edit to suit your needs.

Last edited by GaKu999 (2020-09-17 03:07:03)

RageBanken · 2020-09-17 03:08:56

Thanks for the reply!

I saw that, but I'm not understanding why there's a need to do the symlink to null. Wouldn't simply deleting it be enough then use my own specific configurations - either there or under /etc?

Edit: Nevermind, it was in the next paragraph that that file ships with the system. Got it, thanks!

Last edited by RageBanken (2020-09-17 03:10:13)

GaKu999 · 2020-09-17 03:09:07

solskog wrote:

Which means it will not be touched again during system update.

systemd masking has nothing to do with pacman...
Deleting the file in nonsensical, if you are already masking it.

GaKu999 · 2020-09-17 03:10:45

RageBanken wrote:

I saw that, but I'm not understanding why there's a need to do the symlink to null. Wouldn't simply deleting it be enough then use my own specific configurations - either there or under /etc?

As I said, copy to '/etc/systemd/network/99-default.link' and edit to suit your needs.
It will override the system default.

solskog · 2020-09-17 03:11:05

symlink to /dev/null is the systemd's way to mask/unmask a service, which can be restored easily when needed.

RageBanken · 2020-09-17 03:12:30

Got it! The short answer is, "yes it gets replaced on system update"! Hence the need to not just delete but create the mask.

Thanks for the help! Marking as solved!

seth · 2020-09-17 07:18:15

Do NOT delete /usr/lib/systemd/network/99-default.link - this will either be restored or cause an error on the next update.
The proper way is to leave it intact and shadow (mask) it in /etc/systemd/network - the copy in /usr/lib/systemd/network will then be ignored by systemd (ie. what GaKu999 told you)
Symlinking it to /dev/null (anywhere, but again: hands off the files in /usr/lib/systemd/network as they're under pacman control) will simply cause the systemd default behavior (which is not what you want) so make a copy in /etc/systemd/network, edit that and (from your other thread) swap "slot" an "onboard".

For the records: this is still not systemd-networkd related ;-)

GaKu999 · 2020-09-17 14:43:29

seth wrote:

For the records: this is still not systemd-networkd related ;-)

Since he didn’t told what was annoying him I only mentioned how to do what he wanted the right way.

Now if he uses iwd and is annoyed by wlanx, then he needs to mask 80-iwd.link IIRC.

But I bet there are side effects, the devs want wlanx for a reason maybe...

seth · 2020-09-17 14:55:31

The comment was regarding the title of this thread and his assumptions in his other thread - he wants to reorder the predictable NIC naming, that's not related to any managing service (and afaiu iwd only causes a race condition that prevents the renaming because the device is used when udev tries to rename it)

GaKu999 · 2020-09-17 15:17:06

I guess it’s to late now to rename the thread...

seth wrote:

he wants to reorder the predictable NIC naming

It seems he wants to nuke the alt names.
AFAIK the reason is not technical...

Anyways everyone is free to mess up with their system as long as they don’t use one of the heathens.

eschwartz · 2020-09-17 18:08:17

RageBanken wrote:

So I tracked down the /usr/lib/systemd/network/99-default.link file. Since I want none of the behavior described as it is in that file (at all, not just overridden in /etc/systemd/network/) I need to edit or just outright delete that file.
My question: Do the files in /usr/lib/systemd/network/ get overwritten or recreated when running a system update?
Edit: Solution is "yes" and "need to mask it to prevent it being replaced."

I'm confused why this thread exists. Not only is it permissible to continue discussing your issue in the original thread, this very question was answered there:

https://bbs.archlinux.org/viewtopic.php … 4#p1926454

eschwartz wrote:

Arch did not add anything, Arch packages the systemd / udev software and *that* added an override.
You are welcome to remove the systemd file if that's what you want, but it will get added back on every pacman -Syu that updates systemd. So I strongly advise you to learn to live with "add[ing] an override to an override."

WorMzy · 2020-09-17 22:14:18

Indeed, please do not cross-post, RageBanken.

Merging...

RageBanken · 2020-09-25 09:12:04

Apologies, WorMzy. I didn't view it as a cross-post. I'll be more careful about that.

To be clear for people asking. I do want to change the behavior of the system, beyond just the naming. This system must not try to hand out identifiers or even acknowledge any communication device connected unless explicitly configured. Just masking the file with an override is insufficient. The behavior must not be there to fall back on at all.

From what I'm seeing from people's responses is that I'm going to have to write a script to run on update to ensure that file (and any others like it) get immediately nuked after pacman -Syu finishes.

Again, I consider the base of what I was asking solved. Thank you all for your help and information!

Edit: Sorry for the bump from this reply! It was unintended! >_<

Last edited by RageBanken (2020-09-25 09:49:08)

seth · 2020-09-25 12:14:41

RageBanken wrote:

This system must not try to hand out identifiers or even acknowledge any communication device connected unless explicitly configured. Just masking the file with an override is insufficient. The behavior must not be there to fall back on at all.

Shadowing /usr/lib/systemd/network/99-default.link in /etc will override that file permanently and allows you to control how the predictable name is determined (preferring slot and eliminating the alternate name)
"Masking" the file this way is utterly sufficient and there's no "fallback bahavior" beyond that either.

I'm however not sure what "or even acknowledge any communication device connected" is supposed to mean. If you don't want the hardware to be even probed or a driver being loaded, you'll have to blacklist it and if you don't want it to be considered by networkmanager or whatever, you'll have to blacklist it there. But this has nothing to do w/ the original topic, revolving around the predictable name policy.

RageBanken wrote:

From what I'm seeing from people's responses is that I'm going to have to write a script to run on update to ensure that file (and any others like it) get immediately nuked after pacman -Syu finishes.

Where do you want to get that idea from?
It's about as wrong™ (bad) as a solution could be. Just "nuking" /usr/lib/systemd/network/99-default.link will lead to the udev default behavior for sure - which is apparently not what you want.

RageBanken · 2020-09-25 14:04:38

seth wrote:

"Masking" the file this way is utterly sufficient and there's no "fallback bahavior" beyond that either.

If anything happens to the symlink providing the mask (aka, I screw it up or something/someone else removes it) that behavior must not be available. Even though udev is going to be modified as well, configuration files for unwanted behavior still must not be there. (I know, I know, not the way you folks would normally do it. Me neither, but this is a special case project with weird/paranoid constraints.)

seth wrote:

If you don't want the hardware to be even probed or a driver being loaded, you'll have to blacklist it
...
Just "nuking" /usr/lib/systemd/network/99-default.link will lead to the udev default behavior for sure

You're absolutely correct. And blacklisting all communication devices not already present is one of the (many) steps I'm working on right now.

Thank you for your help, the part I needed a hand with is solved. (No seriously, thank you!)

seth · 2020-09-25 14:14:26

fwwi: Not "symlink" - forget post #26.

# cp /usr/lib/systemd/network/99-default.link /etc/systemd/network/99-default.link
# vim /etc/systemd/network/99-default.link # edit as you like

Whatever happens to /usr/lib/systemd/network/99-default.link, the values in /etc/systemd/network/99-default.link take precedence and at least the distro has no business touching that path.

weird/paranoid constraints

This is arbitrary.
If somethingbad™ can happen to /etc/systemd/network/99-default.link, somethingbad™ can happen to pretty much everything. Granted root access, I can un/load random kernel modules, rename NICs every 1337 seconds, re-route traffic, replace the udev binary - and much worse.

RageBanken · 2020-09-25 14:57:40

seth wrote:

If somethingbad™ can happen to /etc/systemd/network/99-default.link, somethingbad™ can happen to pretty much everything. Granted root access, I can un/load random kernel modules, rename NICs every 1337 seconds, re-route traffic, replace the udev binary - and much worse.

Very true. Also you're absolutely right that it's arbitrary. My usual preference would be to just configure NetworkManager & DNSMasq, then go crack a cold one. However, once I get this system set up how they want it, it get's swapped out with one of our own to keep and the mortgage gets paid for a month. I can't exactly turn it down. So for the time being, thank you for your patience with my 'arbitrary' configuration needs!

Arch Linux

#26 2020-09-17 03:06:31

Re: [Solved] Tracking down arch interface configuration files.

#27 2020-09-17 03:08:56

Re: [Solved] Tracking down arch interface configuration files.

#28 2020-09-17 03:09:07

Re: [Solved] Tracking down arch interface configuration files.

#29 2020-09-17 03:10:45

Re: [Solved] Tracking down arch interface configuration files.

#30 2020-09-17 03:11:05

Re: [Solved] Tracking down arch interface configuration files.

#31 2020-09-17 03:12:30

Re: [Solved] Tracking down arch interface configuration files.

#32 2020-09-17 07:18:15

Re: [Solved] Tracking down arch interface configuration files.

#33 2020-09-17 14:43:29

Re: [Solved] Tracking down arch interface configuration files.

#34 2020-09-17 14:55:31

Re: [Solved] Tracking down arch interface configuration files.

#35 2020-09-17 15:17:06

Re: [Solved] Tracking down arch interface configuration files.

#36 2020-09-17 18:08:17

Re: [Solved] Tracking down arch interface configuration files.

#37 2020-09-17 22:14:18

Re: [Solved] Tracking down arch interface configuration files.

#38 2020-09-25 09:12:04

Re: [Solved] Tracking down arch interface configuration files.

#39 2020-09-25 12:14:41

Re: [Solved] Tracking down arch interface configuration files.

#40 2020-09-25 14:04:38

Re: [Solved] Tracking down arch interface configuration files.

#41 2020-09-25 14:14:26

Re: [Solved] Tracking down arch interface configuration files.

#42 2020-09-25 14:57:40

Re: [Solved] Tracking down arch interface configuration files.

Board footer