Issue: Clobbering nsswitch.conf needlessly

Doing a deep dive into some aspects of what garuda-specific packages are and do, especially those in the higher priority repository, garuda itself, I started noticing some concerning issues I wanted to point out.

Specifically in garuda-hooks, there is:

  • /usr/share/libalpm/hooks/20-os-release.hook
  • /usr/share/libalpm/scripts/garuda-hooks-runner

The hook, on Install and Upgrade alters /etc/nsswitch.conf in very blunt force manners any time filesystem package gets installed or updated, clobbering anything a user may have already setup, such as things like systemd-homed potentially.

This, in my perspective thoughts, should only ever be a one-time thing, and likely very much during post-installation routines, after all the base is installed, since this hook is in fact, doing more than adjusting os-release itself. Another factor in this is that /etc/os-release itself is not even owned by any package at all, as determined by pacman -Qo /etc/os-release, which is normal. But the hook was clearly designed for os-release specifically, which is fine, but why touch nsswitch.conf in a clobbering manner?

Eric

1 Like

/etc/os-release is a symlink to /usr/lib/os-release owned by filesystem 2021.12.07-1 so I think that part of the hook should stay.

/etc/nsswitch.conf should maybe be done in garuda-migrations now that we have it. I don't know why nsswitch.conf is being modified this way in the first place tho, maybe someone here could share some insight? Relevant line: garuda-hooks-runner · master · Garuda Linux / Packages / Stable PKGBUILDs / garuda-hooks · GitLab

1 Like

Ahh, I didn't even check if os-release itself was a symlink or not, but good to know. That one, though, I can totally agree, that part of the hook is absolutely fine. My focus was more on the concern for the additional nsswitch.conf clobbering portion, which after looking at the garuda-migrations may in fact be a viable solution, however, at the same time, would it? This is usually something you only want to touch one time for system initialization, and leave it alone, let .pacsave handle informing people of changes appropriately.

Yeah, that's the point of garuda-migrations. It does every change only once and only if needed.

The nsswitch.conf change was implemented because of network and boot delays it was causing a long ways back before you joined the Garuda team @TNE. Perhaps the bug that necessitated the change has been rectified by now.

3 Likes

Huh... I'd be curious to know what was specifically causing the delays. There's a slight bit of ordering here on what to try first, but a big part is enabling of the mdns_minimal, which is specific.

Course.... Another way to partly solve this problem is come with systemd-resolved setup and configured right out of the box, remove the hooks to clobber nsswitch.conf entirely. Maybe have some install script setup the nsswitch.conf the one way the one time it should be to best work with it, perhaps in common-settings, and allow pacsave/pacnew to do it's work as intended....

So, using garuda-migrations, I'd say
Or maybe just dropping all that into iso-profiles

Actually that's done by Samba support as well
So just drop it from hooks

Hmm.. Just checked samda-support, and yes, the same clobbering is done there as well. This is basically a sledge hammer trying to solve an edge case issue, when all it's really needing to do (in samba-support's case anyway), is add 'wins' to the end of the 'hosts' line for resolution that might be resulted from WINS lookups. Quite a lot less likely these days though that truly really is, but still it can be done.

The way that Fedora does nsswitch.conf is very specific, and there's logical reasoning behind it, first-off, they use systemd-resolved so the use of 'resolve' in this line is specific TO using systemd-resolved:

hosts: files myhostname mdns4_minimal [NOTFOUND=return] resolve [!UNAVAIL=return] dns

This says, use files first, myhostname, mDNS, or continue if not found, then try systemd-resolved and if it's unavailable then continue but all other cases, stop, then finally nss-dns.

samba-support could effectively add wins, but that "resolve [!UNAVAIL=return] would never get to it if it's at the very end, if using systemd-resolved (which wouldn't actually be a bad thing either?)

-- Psi-Jack

1 Like

This is missing in arch's nsswitch.conf

And is needed to be added

So there is no other option

It has to be done

That actually in a sense kind of depends. If using avahi-daemon, yes it does add a difference. If using systemd-resolved however, with mdns turned on within it, that can actually effectively do the same thing on its own. But either way, this can and likely should be done during the installer, and left alone afterwards, except maybe, just maybe, adding wins to the last part using a properly constructed sed line to append to the end of a line, rather than replace the line entirely as is being done currently. The initial setup could write it out as need-be initially but afterwards should be refrained from manually touching it. Especially in a manner that does not make a .pacnew or .pacsave

Something like this for samba-support, for example:

sed '/^hosts: .*[^wins]/ s/$/ wins/' /etc/nsswitch.conf

Add the -i to that and it would of course make the change, but this details what it would do to simply add it, if it's not presently there.

1 Like

As for initial installation stances...

Wouldn't shared/garuda/desktop-overlay-common/etc · master · Garuda Linux / Tools / iso-profiles · GitLab be the correct place to possibly setup an initial nsswitch.conf as desired, modifying specifically the hosts line only and keeping the rest as current arch is?

1 Like

I mean, any of these settings are not going to work

oh god

Why

That's what I said yep. Oh god I remember the old times, when we didn't have a common overlay or common desktop packages before I added them

Okay! I can work out these changes and put in the MR's pretty soon then. iso-profiles for the initial overlay, removal from the samba-support, and removal from the garuda-hooks.

Maybe add a note too, regarding possibly adding wins to the nsswitch.conf?
There's a way to do that if I recall, even if it's not the most obvious way, it's still able to print something "You may need to add this if you intend to use it, etc.. after a package is installed?

And the beauty of it all, it won't effect any existing users, just no clobbering them in the long term. :slight_smile:

-- Psi-Jack

2 Likes

Annnd.. Yeah. Further looking into it. WINS, has been sunset by Microsoft themselves since Windows 2000 and up. So my final draft markup for nsswitch.conf doesn't include wins, as it's obsolete.

-- Psi-Jack

1 Like

Like i said wins is not the problem
What's needed to be added is

mdns4_minimal [NOTFOUND=return]

This is necessary

Which is not present in arch's default nsswitch.conf

Yep. Or in the case of Garuda Linux, it was using mdns_minimal which covers both ipv4 and ipv6 together. That's what I'm implementing it as in my current clones and soon to follow, merge-requests. :wink:

The reason is probably arch assumes user to use systemd-resolved

Which we don't because it's not complete and conflicts with avahi which might be neede for samba