Changing nsswitch.conf on a running system (was Re: /etc/nssswitch.conf is supposed to be a symlink now?)

[Ray Strode]

Hi,

/etc/nsswitch.conf is owned by glibc. It is not a symbolic link as we
ship it.
If find out which packages replaces our configuration with a symbolic
link, please file a bug against that package. If they want to take over
/etc/nsswitch.conf, this is negotiable, but it needs coordination with
the glibc package.

This is a bit of a tangent, but we probably avoid changing
/etc/nsswitch.conf on a running system at all (defer until next offline
update?) until

https://sourceware.org/bugzilla/show_bug.cgi?id=12459

gets fixed. as it stands, no long running daemon will see changes to the
file, I think, leading to potentially weird bugs sometime after authselect
is run right? (and maybe not in an obviously connected way)

Ray

[Kevin Kofler]

(defer until next offline update?)

That would be never on many systems. Most users using command-line DNF and
all users using plasma-pk-updates or dnfdragora never do offline updates by
design.

Kevin Kofler
_______________________________________________
devel mailing list -- ***@lists.fedoraproject.org
To unsubscribe send an email to devel-***@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/***@lists.

[Przemek Klosowski]

Post by Kevin Kofler

(defer until next offline update?)

That would be never on many systems. Most users using command-line DNF and
all users using plasma-pk-updates or dnfdragora never do offline updates by
design.

I, being of the old school, still try to stick to online updates, but I
came to believe that we just don't have the infinitely rolling update
capability any more, so your online updates have to be punctuated by
reboots anyway. This is true on several levels:

- kernel updates---the livepatch / ksplice capabilites are not
mainstream enough

- basic session infrastructure does not support online updates, e.g.
recent dbus discussion where people explicitly said that dbus cannot be
restarted cleanly

- application-level issues (IPC protocol or file formats, etc)

Even though my updating method does not force it, I restart my system
whenever I see that I am running a kernel that's more than one-two
behind the latest update, or when I see instability in some userland
processes I use.

I have given up trying for uptimes measured in months--in practice, my
uptimes range between weeks and months. I don't even think infinite
uptime is a reasonable goal---I'd rather work on setting my system up so
that all long-term tasks restart automatically and correctly pick up
where they left off --- I monitor/collect several extended datasets,
such as weather/soil/environmental conditions, home automation, etc.
Having said that, I definitely want control over offline/online
updating---the choice between 'interruptions all the time' and
'interruptions only when it is most annoying' is not acceptable :)

I do think there should be a clear, established way to determine when
the reboot is needed. There was "needs-restarting" from yum-utils, but
it effectively disappeared because yum-utils conflict with dnf now, and
it was a little flaky anyway.

There's a lot of gray area between the dnfdragora suggestion of
rebooting for every update, and rebooting only for Fedora N-2->N version
upgrades at the N-2 EOL. I don't know if it's practical or desirable to
automate this, but maybe there should be a package boolean marking each
upgrade as 'requiring reboot' or not; kernel and dbus upgrades would
have it always as 'YES', and other packages would reflect the judgment
of packagers.
_______________________________________________
devel mailing list -- ***@lists.fedoraproject.org
To unsubscribe send an email to devel-***@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/dev