The actual proposed fix (and also quick) is to change the /etc/nsswitch.conf to include
passwd: compat systemd
group: compat [SUCCESS=merge] systemd
shadow: compat systemd
to make the systemd dynamic users work on Leap, same as on Tumbleweed. See https://bugzilla.suse.com/show_bug.cgi?id=1230638
/etc/nsswitch.conf should no longer exist, and the correct settings are in /usr/etc/nsswitch.conf
If you have an older installation, you will have a broken /etc/nsswitch.conf file left over that should have been deleted by a package update. Just delete it and things will work.
Thank you!
My way worked but I do have /usr/etc/nsswitch.conf
I’ll rename mine and see how it goes. I assume you’re correct and my /etc/nsswitch.conf came from the flatpak being installed, or something. I had never looked at it. I installed the flatpak then removed it and installed the Tumbleweed version of cockpit.
That’s incorrect. /usr/etc/nsswitch.conf contains the default settings and is overridden by the custom settings in the /etc/nsswitch.conf. Any changes in the /usr/etc/nsswitch.conf will be lost on update.
You can inspect the package (or delete the file and reinstall the package) to confirm this for yourself, that file is not installed by the package any more. It was installed by a previous version of the package, and was left behind when the location of the file was changed. You can confirm this from the package history on OBS, and see the reasoning for this explained on bugzilla.
In short, the reasoning is that, as is the common convention, the file in /etc will override the file in /usr/etc, so if the package modified the file in /etc, which was the package’s configuration, it may be modifying user configuration, which would be bad, as it should only modify its own file, in /usr/etc.
You seem familiar with this concept, just not its application to this case.
And if the user didn’t make any custom settings, then they can still have that file there, with the same invalid old configuration as OP and I, the left-over default config from years ago, which no longer works, being treated as user configuration, overriding the defaults in /usr/etc, which would work.
If they did make custom settings then I don’t need to explain that to them, do I?
I did not say to make changes to the file in /usr/etc so I don’t see how this is relevant.
My way worked but I do have /usr/etc/nsswitch.conf
So here’s the catch: that way works, now, but later, that file is gonna be the old one that doesn’t get updated and has busted old config in it, again.
If you put that file there on purpose then by all means yeh, of course, leave it there and edit it - but I presume if you did that, I don’t need to tell you how it came to have the wrong settings in it, you’d already refer to upstream settings in /usr and know it was out of sync, rather than looking at bugzilla, and you likely wouldn’t be advertising this oopsy on the forums
I’ll rename mine and see how it goes.
Renaming’s a much better idea. Honestly ‘just delete it’ was a bit flippant, sorry. I followed a link here by accident, saw you in the sidebar with this obscure bug I’d come across, and wanted to help, but was rushing it, because I was anticipating trolls…for…some reason… I’m glad you caught the vibe of those poorly worded instructions. Good luck.
Yeah, it’s ok. I did track the file down to glibc but I missed the /usr/ in the front of /etc/. I learned a long time ago to go look where a file came from, then mis-read it. It was 2AM. I also overlooked thart there were two files. I kept it in case they decide a custom configuration is needed for Cockpit with some new add-ons or something .
I was ready to clean up but did check things before doing it:
$ sudo zypper search --provides /usr/etc/nsswitch.conf
i+ | glibc | Standard Shared Libraries (from the GNU C Library) | package
$ sudo zypper search --provides /etc/nsswitch.conf
i+ | glibc | Standard Shared Libraries (from the GNU C Library) | package
$ rpm -ql glibc | grep nsswitch
/etc/nsswitch.conf
/usr/etc/nsswitch.conf
Just before doing this I did a zypper dup and got the kwallet updates, so Tumbleweed is up-to-date and both files are present and part of the glibc package.
glibc does not ship /etc/nsswitch.conf. Read what RPM “ghost” files are.
Even non-ghost files may be excluded from installing. rpm -ql shows every file listed in the package metadata, whether this file is actually present on the system or not.
This is exactly the problem. There kinda aren’t any, but it will own and protect files that already exist there, and people who did not put that file there, are finding it there.
Since the package can’t safely fix this ever now, as it can’t know if it’s really user config, or if it is actually just a leftover; now the only way is for the user to fix it, either by updating their custom config, or by removing the leftover.
The former is no big deal, because that’s obviously something that user knows about and can handle, they did it in the first place and they can do it again.
But the latter, the latter is expecting what might be a normie end-user who may not ever have been capable of editing that file, now has to a) learn how and worse b) discover that they need to, by discovering a failing cockpit when they replace YaST, and searching until they find a correct answer somewhere that explains why cockpit is RIP and what to do about it.
This conundrum is the reason why I felt compelled to help out here.
It has occurred to me that maybe some user might have some obscure software which for some reason expects to find nsswitch.conf in /etc. I have seen one (only one, but that’s more than zero) example of this I can imagine maybe it might happen to a flatpak with it’s own bundled glibc but looks for config from the external glibc (why would it do that?)? Anyway…
If one actually needs that file to exist in /etc but does not have any need for special configuration beyond the openSUSE defaults, rather than copying the file there, one might just symlink it to the one in /usr/etc. That way it’ll get updated and avoid failures like this one with cockpit, later.
The account will fail to register, and no further info is given, and no chance to enter a password.
You can start linphone with linphone --verbose and it will show:
[16:53:56:176][Info]Core:linphone: resconf dns_nssconf_loadpath error [/etc/nsswitch.conf]: No such file or directory
[16:53:56:176][Error]Core:linphone: Error loading dns server addresses.
[16:53:56:176][Info]Core:linphone: resconf dns_nssconf_loadpath error [/etc/nsswitch.conf]: No such file or directory
[16:53:56:176][Error]Core:linphone: Error loading dns server addresses.
[16:53:56:176][Info]Core:linphone: resconf dns_nssconf_loadpath error [/etc/nsswitch.conf]: No such file or directory
[16:53:56:176][Error]Core:linphone: Error loading dns server addresses.
This can be worked around with sudo ln -s /usr/etc/nsswitch.conf /etc/nsswitch.conf
And I’ll be forwarding this issue to the above bugzilla so hopefully (probably not, because how?) it can be fixed…
Surprisingly, that happens even with the package from Factory, uncontained.
Just for informational purposes, here’s the upstream issues I’ve updated regarding this (sorry, I thought I’d linked them both already… other related issues are cross-linked in the bugs’ ‘see also’ lists)
I’m glad you caught the vibe of those poorly worded instructions. Good luck.