Steve, On Tue, Aug 07, 2012 at 05:04:56PM -0700, Steve Langasek wrote: > On Tue, Aug 07, 2012 at 10:43:39PM +0200, Ivo De Decker wrote: > > Package: pam > > Version: 1.1.3-7.1 > > User: multiarch-de...@lists.alioth.debian.org > > Usertags: multiarch > > > When examining pam multiarch issues, I noticed this error (in > > /var/log/auth.log): > > > PAM unable to dlopen(pam_smbpass.so): /lib/security/pam_smbpass.so: cannot > > open shared object file: No such file or directory > > > The modules are not in /lib/security anymore (but in > > /lib/<triplet>/security). > > Pam should log the error with the path where the module is supposed to be. > > How does PAM know the path where the module is supposed to be? It's not in > either path - PAM knows this because it's checked both. And not all pam > module packages in the archive are converted for multiarch. Why should PAM > use one path over the other in the error message?
It could log both. And the idea is that all modules will move to multiarch paths (eventually). But I agree that simply changing the path isn't really correct either. The current error is especially confusing if the modules are used by daemons from different architectures: If you try to log in via one architecture, it works, while it doesn't for the other arch. The error mentions a path that doesn't exists, so it doesn't give an indication why it works for one service and not for the other. If you mention the multiarch path, it gives an indication that the daemon has a different architecture and that you need to install the pam module for this arch. But as pam tries 2 different paths, the only correct way is probably to log that both paths don't exists. Cheers, Ivo -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
