On 18/07/2021 18.21, Ed Greshko wrote:
On 18/07/2021 15:56, Eyal Lebedinsky wrote:
>
>
> On 18/07/2021 17.03, Ed Greshko wrote:
>> On 18/07/2021 12:31, Eyal Lebedinsky wrote:
>>> On 18/07/2021 11.18, Eyal Lebedinsky wrote:
>>>> This was brought up before, but today again it bit me. There was a glibc
update (fc34)
>>>> which provides a new nsswitch.conf with this line
>>>> hosts: files myhostname resolve [!UNAVAIL=return] dns
>>>> which caused all the aliases I had for my server to fail because my local
dns was not looked up.
>>>>
>>>> Had to again remove the '[!UNAVAIL=return]' stanza.
>>>>
>>>> Is this issue being fixed? I found this
>>>> https://bugzilla.redhat.com/show_bug.cgi?id=1717384
>>>> which suggests nsswitch.conf will become a fedora file (not glibc) and
hopefully better, but this log
>>>> has now been open for a long time.
>>>>
>>>> Regards
>>>
>>> Thanks for the workarounds proposed, and ATM some such are needed, but what I
am after is
>>> finding out what permanent solution is planned for fedora.
>>>
>>> Sadly, I already use a number of scripts to deal with personal preferences
and alike,
>>> and I understand that not all of my needs will ever be provided by the
distributed
>>> packages (and their configurations).
>>>
>>
>> My second question to you is how did you modify nsswitch.conf?
>
> vi
Well, that's the problem
>
>> I asked this, since I'm sure I was doing some testing in this area sometime
back. Maybe it relation to your
>> issues.
>>
>> Anyway, thaf file contains
>>
>> #hosts: files myhostname mdns4_minimal [NOTFOUND=return] dns
>> hosts: files myhostname mdns4_minimal [NOTFOUND=return] resolve dns
>> #hosts: files myhostname mdns4_minimal [NOTFOUND=return] resolve
[!UNAVAI=ret
>> urn] dns
>>
>>
>> I modified that file based on the instructions contained in the file.
>>
>> # If you want to make changes to nsswitch.conf please modify
>> # /etc/authselect/user-nsswitch.conf and run 'authselect apply-changes'.
>
> I do not see these instructions anywhere. Where are you seeing them?
In /etc/nsswitch.conf which is a symlink.
[egreshko@meimei etc]$ ll nsswitch.conf
lrwxrwxrwx. 1 root root 29 Jul 14 16:01 nsswitch.conf -> /etc/authselect/nsswitch.conf
I have:
$ ll /etc/nsswitch.conf
-rw-r--r-- 1 root root 2150 Jul 18 00:08 /etc/nsswitch.conf
$ ll /etc/authselect/nsswitch.conf
ls: cannot access '/etc/authselect/nsswitch.conf': No such file or directory
>> The owner of that file is glibc.
>>
>> glibc was recently updated.
>
> Yes
>
>> [root@f34k2 etc]# dnf history glibc
>> ID | Command line | Date and time | Action(s) |
Altered
>>
----------------------------------------------------------------------------------
>> 40 | -y --refresh update | 2021-07-15 03:23 | Upgrade | 84
<
>> 19 | -y --refresh update | 2021-06-21 12:18 | ?, E, I, O, U | 172
><
>>
>> And the file remained unchanged.
>>
>> So, I am wondering if you're doing something a bit differently?
>
> Original nsswitch.conf had
> hosts: files myhostname resolve [!UNAVAIL=return] dns
> now that I modified it, it has
> hosts: files myhostname resolve dns
>
> /etc/authselect/user-nsswitch.conf has
> hosts: files myhostname mdns4_minimal [NOTFOUND=return] resolve
[!UNAVAIL=return] dns
>
> $ sudo authselect apply-changes
> No existing configuration detected.
>
> I never used authselect and do not know what it does or how to manage it.
>
I think all the issues you're having is that glibc expects nsswitch.conf to be
managed by authselect. And, apparently, in your case it isn't.
So, you should check to what is contained in
[egreshko@meimei authselect]$ pwd
/etc/authselect
[egreshko@meimei authselect]$ ls
authselect.conf nsswitch.conf user-nsswitch.conf
custom password-auth user-nsswitch.conf.bak
dconf-db postlogin user-nsswitch.conf-orig
dconf-locks smartcard-auth
fingerprint-auth system-auth
[eyal@e7:/etc/authselect]$ ls
custom user-nsswitch.conf user-nsswitch.conf.bak
Then move your old /etc/nsswitch.conf file aside. Create the needed
symling and then make the adjustments you want
as described in the new nsswitch.conf.
man authselect
may be helpful.
Maybe, but it looks as if my setup is fundamentally different. And it is the same in two
f34 machines here.
Both were upgraded for many years so a modern setup probably never got in.
Thanks
--
Eyal Lebedinsky (fedora(a)eyal.emu.id.au)