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

[Ray Strode]

Hi,

On Wed, Nov 28, 2018, 9:45 AM Florian Weimer <fweimer(a)redhat.com wrote:

>  /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]

Ray Strode wrote:
>  (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

[Przemek Klosowski]

On 11/29/18 8:29 AM, Kevin Kofler wrote:
>  Ray Strode wrote:
> > (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.