You are not logged in.

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

GaKu999
Member
From: US/Eastern
Registered: 2020-06-21
Posts: 377

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

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)


My reposSome snippets

Heisenberg might have been here.

Offline

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

RageBanken
Member
Registered: 2020-09-16
Posts: 24

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

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)


Gate-keeping knowledge is functionally the same as burning books.
Don't have the time or can't admit you don't know?  Zip it.

Offline

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

GaKu999
Member
From: US/Eastern
Registered: 2020-06-21
Posts: 377

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

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.


My reposSome snippets

Heisenberg might have been here.

Offline

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

GaKu999
Member
From: US/Eastern
Registered: 2020-06-21
Posts: 377

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

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.


My reposSome snippets

Heisenberg might have been here.

Offline

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

solskog
Member
Registered: 2020-09-05
Posts: 247

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

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

Offline

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

RageBanken
Member
Registered: 2020-09-16
Posts: 24

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

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!


Gate-keeping knowledge is functionally the same as burning books.
Don't have the time or can't admit you don't know?  Zip it.

Offline

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

seth
Member
Registered: 2012-09-03
Posts: 16,582

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

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 ;-)

Offline

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

GaKu999
Member
From: US/Eastern
Registered: 2020-06-21
Posts: 377

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

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...


My reposSome snippets

Heisenberg might have been here.

Offline

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

seth
Member
Registered: 2012-09-03
Posts: 16,582

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

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)

Offline

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

GaKu999
Member
From: US/Eastern
Registered: 2020-06-21
Posts: 377

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

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. tongue


My reposSome snippets

Heisenberg might have been here.

Offline

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

eschwartz
Trusted User/Bug Wrangler
Registered: 2014-08-08
Posts: 3,699

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

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."


Managing AUR repos The Right Way -- aurpublish (now a standalone tool)

Offline

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

WorMzy
Forum Moderator
From: Scotland
Registered: 2010-06-16
Posts: 10,020
Website

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

Indeed, please do not cross-post, RageBanken.

Merging...


Sakura:-
Mobo: MSI X299 TOMAHAWK ARCTIC // Processor: Intel Core i7-7820X 3.6GHz // GFX: AMD Radeon RX 5700 XT // RAM: 32GB (4x 8GB) Corsair DDR4 (@ 3000MHz) // Storage: 1x 3TB HDD, 5x 1TB HDD, 2x 120GB SSD, 1x 275GB M2 SSD

Making lemonade from lemons since 2015.

Offline

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

RageBanken
Member
Registered: 2020-09-16
Posts: 24

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

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)


Gate-keeping knowledge is functionally the same as burning books.
Don't have the time or can't admit you don't know?  Zip it.

Offline

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

seth
Member
Registered: 2012-09-03
Posts: 16,582

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

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.

Offline

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

RageBanken
Member
Registered: 2020-09-16
Posts: 24

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

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!)


Gate-keeping knowledge is functionally the same as burning books.
Don't have the time or can't admit you don't know?  Zip it.

Offline

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

seth
Member
Registered: 2012-09-03
Posts: 16,582

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

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.

Offline

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

RageBanken
Member
Registered: 2020-09-16
Posts: 24

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

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!


Gate-keeping knowledge is functionally the same as burning books.
Don't have the time or can't admit you don't know?  Zip it.

Offline

Board footer

Powered by FluxBB