Re: libnss-db and /usr/lib/* libraries
On Thursday 11 of August 2005 11:35, Tim Dijkstra wrote: $ ldd /usr/lib/libnss_db.so.2 | grep /usr libdb-4.3.so = /usr/lib/libdb-4.3.so (0xb7e1) So the system can't unmount /usr partition on poweroff process. I wonder if I should link statically the BDB library. The other distros works that way. It might be a problem if the libdb4.3 package will be updated and then the libnss-db should be recompiled. Another thing is the PIC and non-PIC stuff, so I'm afraid that I would need the libdb4.3-pic package which doesn't exist yet. What do you think? This is probably bug http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=120340 Should it be fixed with replacing #!/bin/sh with #!/bin/dash in /e/i/umountfs ? I thougt the problem was not the /e/i/umountfs but /etc/init.d/rc script which also uses /bin/bash so /usr/lib/libdb-4.3.so library... If umountfs is the only blocker, it could be splitted into umountfs and i.e. remountrootro. I think it could solve the problem. -- .''`.Piotr Roszatycki, Netia SA : :' :mailto:[EMAIL PROTECTED] `. `' mailto:[EMAIL PROTECTED] `- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: libnss-db and /usr/lib/* libraries
On Fri, 12 Aug 2005 10:23:41 +0200 Piotr Roszatycki [EMAIL PROTECTED] wrote: On Thursday 11 of August 2005 11:35, Tim Dijkstra wrote: $ ldd /usr/lib/libnss_db.so.2 | grep /usr libdb-4.3.so = /usr/lib/libdb-4.3.so (0xb7e1) So the system can't unmount /usr partition on poweroff process. I wonder if I should link statically the BDB library. The other distros works that way. It might be a problem if the libdb4.3 package will be updated and then the libnss-db should be recompiled. Another thing is the PIC and non-PIC stuff, so I'm afraid that I would need the libdb4.3-pic package which doesn't exist yet. What do you think? This is probably bug http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=120340 Should it be fixed with replacing #!/bin/sh with #!/bin/dash in /e/i/umountfs ? dash is optional so you can't do that anyway. I thougt the problem was not the /e/i/umountfs but /etc/init.d/rc script which also uses /bin/bash so /usr/lib/libdb-4.3.so library... If umountfs is the only blocker, it could be splitted into umountfs and i.e. remountrootro. I think it could solve the problem. I think any bash-script running at umount time will give you this problem, so yes also rc. So only installing dash as /bin/sh will help you for sure. Anything else would be a work-a-round for #120340, which stays a bug IMHO. grts Tim -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: libnss-db and /usr/lib/* libraries
On Thu, 11 Aug 2005, Piotr Roszatycki wrote: Hi. The problem is important not only for libnss-db package but also for libnss-ldap, libnss-mysql and others. $ ldd /usr/lib/libnss_db.so.2 | grep /usr libdb-4.3.so = /usr/lib/libdb-4.3.so (0xb7e1) Well, IMHO anything used by libnss needs to either be statically linked (and make 200% sure that: 1. you *WILL* update next-day it if security fixes or other major updates to any of the statically linked libraries are released -- this is a total pain. 2. any dynamic libraries needed are in /lib, and *all* of them use versioned symbols 3. all of the nss module AND static AND dynamic libs are thread-safe AND reentrant-safe ) Otherwise you have a critical bug in the system, waiting to happen. If you can't get all of the above to be true, it is time to remove that particular libnss module from Debian. libnss modules are *extremely* critical to the system. They are implicitly linked to *EVERY* running binnary that is linked against libc (instead of, say, dietlibc). -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: libnss-db and /usr/lib/* libraries
Henrique de Moraes Holschuh [EMAIL PROTECTED] writes: On Thu, 11 Aug 2005, Piotr Roszatycki wrote: Hi. The problem is important not only for libnss-db package but also for libnss-ldap, libnss-mysql and others. $ ldd /usr/lib/libnss_db.so.2 | grep /usr libdb-4.3.so = /usr/lib/libdb-4.3.so (0xb7e1) Well, IMHO anything used by libnss needs to either be statically linked (and make 200% sure that: 1. you *WILL* update next-day it if security fixes or other major updates to any of the statically linked libraries are released -- this is a total pain. 2. any dynamic libraries needed are in /lib, and *all* of them use versioned symbols 3. all of the nss module AND static AND dynamic libs are thread-safe AND reentrant-safe ) Otherwise you have a critical bug in the system, waiting to happen. If you can't get all of the above to be true, it is time to remove that particular libnss module from Debian. libnss modules are *extremely* critical to the system. They are implicitly linked to *EVERY* running binnary that is linked against libc (instead of, say, dietlibc). I believe nss modules are even dlopened in a static libc. There is no way to link them in static. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: libnss-db and /usr/lib/* libraries
On Fri, Aug 12, 2005 at 11:07:09AM -0300, Henrique de Moraes Holschuh wrote: 2. any dynamic libraries needed are in /lib, and *all* of them use versioned symbols Look at the earlier discussions about libnss-ldap. You'd quickly find half of /usr/lib being moved to /lib. I do not think this is desirable... Otherwise you have a critical bug in the system, waiting to happen. No. You have a configuration problem. Just document that if you are using bash as /bin/sh, then the only NSS modules you can use safely during shutdown are the ones supplied by glibc (that means files, dns, nis, nisplus, hesiod and compat). Any other NSS modules will likely to cause trouble during shutdown if bash is in the picture. If you can't get all of the above to be true, it is time to remove that particular libnss module from Debian. No, it's just time to realize the consequences and special requirements of complex NSS setups. libnss modules are *extremely* critical to the system. They are implicitly linked to *EVERY* running binnary that is linked against libc (instead of, say, dietlibc). Yep, and that means they pose special configuratuion requirements for the system (like avoiding using bash as /bin/sh). Gabor -- - MTA SZTAKI Computer and Automation Research Institute Hungarian Academy of Sciences - -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: libnss-db and /usr/lib/* libraries
On Fri, Aug 12, 2005 at 04:41:01PM +0200, Goswin von Brederlow wrote: I believe nss modules are even dlopened in a static libc. There is no way to link them in static. I believe Henrique didn't mean the NSS modules being static, just linking all dependant libraries statically into the NSS module (so the NSS module itself would not directly depend on any other shared library). But that will not help NSS modules that try to dlopen other modules themselves (like libnss_ldap which opens SASL authentication modules dynamically). Gabor -- - MTA SZTAKI Computer and Automation Research Institute Hungarian Academy of Sciences - -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: libnss-db and /usr/lib/* libraries
On Fri, 12 Aug 2005, Goswin von Brederlow wrote: I believe nss modules are even dlopened in a static libc. There is no way to link them in static. I mean the nss module itself should be either static, or using only stuff in /lib. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
libnss-db and /usr/lib/* libraries
Hi. The problem is important not only for libnss-db package but also for libnss-ldap, libnss-mysql and others. $ ldd /usr/lib/libnss_db.so.2 | grep /usr libdb-4.3.so = /usr/lib/libdb-4.3.so (0xb7e1) So the system can't unmount /usr partition on poweroff process. I wonder if I should link statically the BDB library. The other distros works that way. It might be a problem if the libdb4.3 package will be updated and then the libnss-db should be recompiled. Another thing is the PIC and non-PIC stuff, so I'm afraid that I would need the libdb4.3-pic package which doesn't exist yet. What do you think? -- .''`.Piotr Roszatycki, Netia SA : :' :mailto:[EMAIL PROTECTED] `. `' mailto:[EMAIL PROTECTED] `- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: libnss-db and /usr/lib/* libraries
On Thu, 11 Aug 2005 10:17:27 +0200 Piotr Roszatycki [EMAIL PROTECTED] wrote: Hi. The problem is important not only for libnss-db package but also for libnss-ldap, libnss-mysql and others. $ ldd /usr/lib/libnss_db.so.2 | grep /usr libdb-4.3.so = /usr/lib/libdb-4.3.so (0xb7e1) So the system can't unmount /usr partition on poweroff process. I wonder if I should link statically the BDB library. The other distros works that way. It might be a problem if the libdb4.3 package will be updated and then the libnss-db should be recompiled. Another thing is the PIC and non-PIC stuff, so I'm afraid that I would need the libdb4.3-pic package which doesn't exist yet. What do you think? This is probably bug http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=120340 grts Tim -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
