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

Bug#1003342: marked as done (libc6: NIS client not working after update to libc6:amd64 2.33-1)

Your message dated Sun, 7 Aug 2022 23:05:36 +0200
with message-id <YvApIHpn71FENIsI@aurel32.net>
and subject line Re: Bug#1003342: libc6: NIS client not working after update to libc6:amd64 2.33-1
has caused the Debian Bug report #1003342,
regarding libc6: NIS client not working after update to libc6:amd64 2.33-1
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact owner@bugs.debian.org
immediately.)


-- 
1003342: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1003342
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems
--- Begin Message --- 
Package: libc6
Version: 2.33-1
Severity: normal

Hi,

After the update of libc6 2.32-5 -> 2.33-1, NIS users are not recognized 
by the system anymore. The NIS setup was working OK before this upgrade, 
which just included (according to aptitude):

REMOVE (PURGE)] libjson-c4:amd64 0.13.1+dfsg-9
[UPGRADE] glibc-doc:amd64 2.32-5 -> 2.33-1
[UPGRADE] glibc-doc-reference:amd64 2.32-1 -> 2.33-1
[UPGRADE] libc-bin:amd64 2.32-5 -> 2.33-1
[UPGRADE] libc-dev-bin:amd64 2.32-5 -> 2.33-1
[UPGRADE] libc-l10n:amd64 2.32-5 -> 2.33-1
[UPGRADE] libc6:amd64 2.32-5 -> 2.33-1
[UPGRADE] libc6-dbg:amd64 2.32-5 -> 2.33-1
[UPGRADE] libc6-dev:amd64 2.32-5 -> 2.33-1
[UPGRADE] libc6-dev-i386:amd64 2.32-5 -> 2.33-1
[UPGRADE] libc6-dev-x32:amd64 2.32-5 -> 2.33-1
[UPGRADE] libc6-i386:amd64 2.32-5 -> 2.33-1
[UPGRADE] libc6-x32:amd64 2.32-5 -> 2.33-1
[UPGRADE] locales:amd64 2.32-5 -> 2.33-1
[UPGRADE] nscd:amd64 2.32-5 -> 2.33-1
==

"ypcat passwd" works fine, as before. "finger username" does not work. 
The system has libnss-nis and libnss-nisplus previously installed. The 
usual usual instructions in /usr/share/doc/nis/nis.debian.howto.gz were 
verified and they are still implemented as suggested (no changes). This 
happens on multiple client systems, where the behavior seems to be 
reproducible. "ypwhich" works normally.

Doing a "strace finger username" and checking the differences between a 
working system (still libc6 2.32-5) and a nonworking system (with libc6 2.33-1):

In the old system, after

  openat(AT_FDCWD, "/lib/x86_64-linux-gnu/libnss_compat.so.2", O_RDONLY|O_CLOEXEC) = 3
  ...
  close(3)

there is a call to

  openat(AT_FDCWD, "/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3
  ...
  close(3)                                = 0
  openat(AT_FDCWD, "/lib/x86_64-linux-gnu/libnss_nis.so.2", O_RDONLY|O_CLOEXEC) = 3
  ...
  close(3)

In the updated system (libc6 2.32-5), after the call to 
libnss_compat.so.2, there is no following call to libnss_nis.so.2 or 
/etc/ld.so.cache, although /lib/x86_64-linux-gnu/libnss_nis.so.2 exists, 
and points to libnss_nis.so.2.0.0.

I can provide more information, if necessary.

Thanks for looking into this,

Nuno.


-- System Information:
Debian Release: bookworm/sid
  APT prefers testing
  APT policy: (700, 'testing'), (650, 'unstable'), (610, 'stable-security'), (600, 'stable'), (300, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 5.15.0-2-amd64 (SMP w/24 CPU threads)
Locale: LANG=pt_PT.UTF8, LC_CTYPE=pt_PT.UTF8 (charmap=UTF-8) (ignored: LC_ALL set to pt_PT.UTF8), LANGUAGE=pt:pt_BR:en
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages libc6 depends on:
ii  libgcc-s1  11.2.0-13

Versions of packages libc6 recommends:
ii  libidn2-0  2.3.2-2

Versions of packages libc6 suggests:
ii  debconf [debconf-2.0]  1.5.79
ii  glibc-doc              2.33-1
ii  libc-l10n              2.33-1
ii  libnss-nis             3.1-4
ii  libnss-nisplus         1.3-4
ii  locales                2.33-1

-- debconf information:
  glibc/disable-screensaver:
* glibc/restart-services: smbd ssh exim4 cups cron atd
  glibc/kernel-not-supported:
* libraries/restart-without-asking: false
* glibc/upgrade: true
  glibc/restart-failed:
  glibc/kernel-too-old:

--- End Message ---
--- Begin Message --- 
Version: 2.34-experimental0

On 2022-01-16 10:10, Nuno Oliveira wrote:
> * Aurelien Jarno <aurelien@aurel32.net> [2022-01-09 22:59]:
> > Hi,
> > 
> > On 2022-01-08 17:15, Nuno Oliveira wrote:
> > > Package: libc6
> > > Version: 2.33-1
> > > Severity: normal
> > > 
> > > Hi,
> > > 
> > > After the update of libc6 2.32-5 -> 2.33-1, NIS users are not recognized
> > > by the system anymore. The NIS setup was working OK before this upgrade,
> > > which just included (according to aptitude):
> > > 
> > > REMOVE (PURGE)] libjson-c4:amd64 0.13.1+dfsg-9
> > > [UPGRADE] glibc-doc:amd64 2.32-5 -> 2.33-1
> > > [UPGRADE] glibc-doc-reference:amd64 2.32-1 -> 2.33-1
> > > [UPGRADE] libc-bin:amd64 2.32-5 -> 2.33-1
> > > [UPGRADE] libc-dev-bin:amd64 2.32-5 -> 2.33-1
> > > [UPGRADE] libc-l10n:amd64 2.32-5 -> 2.33-1
> > > [UPGRADE] libc6:amd64 2.32-5 -> 2.33-1
> > > [UPGRADE] libc6-dbg:amd64 2.32-5 -> 2.33-1
> > > [UPGRADE] libc6-dev:amd64 2.32-5 -> 2.33-1
> > > [UPGRADE] libc6-dev-i386:amd64 2.32-5 -> 2.33-1
> > > [UPGRADE] libc6-dev-x32:amd64 2.32-5 -> 2.33-1
> > > [UPGRADE] libc6-i386:amd64 2.32-5 -> 2.33-1
> > > [UPGRADE] libc6-x32:amd64 2.32-5 -> 2.33-1
> > > [UPGRADE] locales:amd64 2.32-5 -> 2.33-1
> > > [UPGRADE] nscd:amd64 2.32-5 -> 2.33-1
> > > ==
> > > 
> > > "ypcat passwd" works fine, as before. "finger username" does not work.
> > > The system has libnss-nis and libnss-nisplus previously installed. The
> > > usual usual instructions in /usr/share/doc/nis/nis.debian.howto.gz were
> > > verified and they are still implemented as suggested (no changes). This
> > > happens on multiple client systems, where the behavior seems to be
> > > reproducible. "ypwhich" works normally.
> > > 
> > > Doing a "strace finger username" and checking the differences between a
> > > working system (still libc6 2.32-5) and a nonworking system (with libc6 2.33-1):
> > > 
> > > In the old system, after
> > > 
> > >   openat(AT_FDCWD, "/lib/x86_64-linux-gnu/libnss_compat.so.2", O_RDONLY|O_CLOEXEC) = 3
> > >   ...
> > >   close(3)
> > > 
> > > there is a call to
> > > 
> > >   openat(AT_FDCWD, "/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3
> > >   ...
> > >   close(3)                                = 0
> > >   openat(AT_FDCWD, "/lib/x86_64-linux-gnu/libnss_nis.so.2", O_RDONLY|O_CLOEXEC) = 3
> > >   ...
> > >   close(3)
> > > 
> > > In the updated system (libc6 2.32-5), after the call to
> > 
> > I guess you mean 2.33-1 here.
> > 
> > > libnss_compat.so.2, there is no following call to libnss_nis.so.2 or
> > > /etc/ld.so.cache, although /lib/x86_64-linux-gnu/libnss_nis.so.2 exists,
> > > and points to libnss_nis.so.2.0.0.
> > 
> > Thanks for the detail analysis. I can confirm the same issue. It has
> > been fixed by this upstream commit:
> > 
> > https://sourceware.org/git/?p=glibc.git;a=commit;h=9b456c5da968ee832ea4b2b73a18a5bf6d2118a6
> > 
> > Unfortunately, due to symbols changes, it is not backportable to glibc
> > 2.33 easily without potentially breaking other NSS modules during
> > upgrade.
> > 
> > On the other hand, the problem is already fixed in glibc 2.34 (currently
> > in experimental), so the easiest fix might be to get glibc 2.34 ready to
> > be uploaded to unstable.
> > 
> 
> Hi Aurelien,
> 
> I can also confirm that this bug is not present in 2.34-0experimental2.
> 

It took time, but glibc 2.34 is finally in unstable. I am therefore
closing the bug.

Regards
Aurelien

-- 
Aurelien Jarno                          GPG: 4096R/1DDD8C9B
aurelien@aurel32.net                 http://www.aurel32.net

--- End Message ---
Reply to: