Proposed F19 Feature: Fedora Upgrade - using yum

[Lennart Poettering]

On Thu, 24.01.13 21:15, Simo Sorce (simo at redhat.com) wrote:

> On Fri, 2013-01-25 at 00:12 +0100, Lennart Poettering wrote:
> > I mean, here's an example: let's say openssl is updated, which is
> > pulled
> > in by a ton of other things, for example the libc NSS LDAP module. The
> > libc NSS is used by at least half of all processes running on your
> > system,
> > and they all dlopen() the NSS module. So how do you now figure out
> > which
> > ones that are and how do you then figure out what the heck you need to
> > do to get them restarted?
> > 
> A) there is no 'libc NSS LDAP module', nss_ldap is not part of libc and
> is also deprecated on its own in favor of nss_ldapd and others.

Not part of libc? uh? no, of course not. It's still a module that is
loaded into libc via the libc NSS scheme, which is the point I am making
here...

And anyway you are missing the point here... this is just an
example. It's not particularly hard to come up with a different
example. Just think of some other NSS module, that uses some
library. Because of NSS its's loaded into half of our processes, all
they have to do is invoke gethostbyname() and the module and all
depending libaries are mapped in, and how would ever detect that?

> B) Luckily we solved this case with SSSD, and this is exactly one of the
> use cases we wanted to solve with it. The sssd client side that gets
> loaded in processes has been made extremely simple and the protocol
> fixed in stone exactly so that you can upgrade SSSD and it's
> dependencies and even change sssd's configuration w/o having to restart
> applications.

Well you "fixed" a tiny facet of the issue. As it turns out however sssd
is not the only service we ship, is not the only package we ship, it's
not the only NSS module we ship, and update nss_sssd is still not
possible either...

> So I would remove the nsswitch problem, for the most part (we still have
> some nsswitch things sssd does not handle like hostname resolution, but
> we may take that over as well if really necessary.

Dude, sssd is not the only NSS module in the world, and NSS not the only
interface that uses dlopen(). Look at PAM, at gstreamer loading codecs,
at iconv loading char maps, gtk loading gtk modules, pulseaudio loading
pa modules, python loading any module, apache loading a module, gvfs
loading gvfs modules, ppp loading some module, ...

There's no way to determine those deps from the outside.

Lennart

-- 
Lennart Poettering - Red Hat, Inc.