Re: Manual intervention required: broken /etc/nsswitch.conf and /etc/resolv.conf for F33 early adopters

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Dne 10. 09. 20 v 17:32 Michael Catanzaro napsal(a):
>
> On Thu, Sep 10, 2020 at 9:24 am, Vít Ondruch <vondruch@xxxxxxxxxx> wrote:
>> Hi Michael,
>>
>> Could you please provide more details? This is content of my
>> nsswitch.conf:
>>
>>
>> ~~~
>>
>> $ grep mdns4_minimal /etc/authselect/user-nsswitch.conf
>> hosts:      files mdns4_minimal [NOTFOUND=return] dns myhostname
>> ~~~
>>
>>
>> How that happened? From what version of what package it happened? Why
>> should I do some changes manually and they are not handled
>> automatically?
>
> You're completely missing resolved from your hosts line, so you'll get
> legacy name resolution behavior via nss-dns (which is what Ubuntu does).
>
> There were multiple different bugs here, so it's a bit hard to keep
> track of them all. systemd package was being too cautious about
> deleting /etc/resolv.conf, so some users wound up with
> /etc/resolv.conf managed by NetworkManager even though systemd is
> running, which was not what I had intended. Plus we originally planned
> for resolved to handle mDNS resolution instead of avahi, but we
> discovered that it doesn't work as expected. We have hacky scripts in
> the systemd and nss-mdns packages to manage the hosts line, plus it's
> managed by authselect itself. They all have to agree on expected
> configuration and it's all a bit fragile. The systemd package script
> is careful to only touch this line if the order matches the previous
> Fedora default configuration, so we have to choose between
> automatically reordering the nss modules to fix this for users of F33
> pre-beta, vs. clobbering intentional configuration changes for users
> who actually wanted the hosts line to be different. If this had
> reached stable releases, then we'd really have to do that clobbering,
> but it didn't, so seems best to be more conservative here. These
> scripts would not be needed if we could add systemd nss modules and
> nss-mdns to the nsswitch.conf provided by the glibc package.


Thank you for the details.

And now I wonder, is there a way to restore the pristine state of these
files without touching them directly (with exception of deleting them)?
E.g.:

~~~

$ rm /etc/authselect/user-nsswitch.conf

$ sudo dnf reinstall authselect

~~~

Also I don't understand why I have files on my system which are not
owned by anything:

~~~

$ rpm -qf /etc/authselect/user-nsswitch.conf
file /etc/authselect/user-nsswitch.conf is not owned by any package

~~~

How are these files created for fresh system?

And also, is there long term vision to prevent issues, that nobody
really knows who edited which configuration file? I understand that
there is some legacy, multiple projects involved, etc. but I don't want
to care about random configuration files in /etc.


Vít

_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Users]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]

  Powered by Linux