Linux PAM
When reviewing the instructions for PAM, I see we are moving the libraries from /lib to /usr/lib. Why? Surely we need the PAM libraries to be available if /usr is not mounted. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Linux-PAM
Funny how some things work out. The BLFS book was just recently changed to make cracklib a required dependency of Linux-PAM. I didn't think too much about it. However, tonight I screwed up and forgot to install cracklib before installing Linux-PAM. And PAM installed just fine. The configure log shows it looked for fascistcheck and didn't find it and just plowed along. Everything installed just fine. I'll BZ this unless someone has information to the contrary. -- Randy rmlscsi: [GNU ld version 2.15.94.0.2 20041220] [gcc (GCC) 3.4.3] [GNU C Library stable release version 2.3.4] [Linux 2.6.10 i686] 21:17:00 up 10 days, 7:21, 4 users, load average: 0.00, 0.00, 0.00 -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: Linux PAM
Bruce Dubbs wrote: > When reviewing the instructions for PAM, I see we are moving the libraries > from > /lib to /usr/lib. Why? Surely we need the PAM libraries to be available if > /usr is not mounted. Look closer. The libraries required for PAM are not moved. What are moved are the .so and .la files. All the instructions are clearly documented in the "Command Explanations" section. -- Randy -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: Linux PAM
Randy McMurchy wrote: > Bruce Dubbs wrote: >> When reviewing the instructions for PAM, I see we are moving the libraries >> from >> /lib to /usr/lib. Why? Surely we need the PAM libraries to be available if >> /usr is not mounted. > > Look closer. The libraries required for PAM are not moved. What are > moved are the .so and .la files. All the instructions are clearly > documented in the "Command Explanations" section. Ahh, yes. Thanks for the cluebat. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Linux-PAM nitpicks
Hi all, Linux-PAM installs the following libraries into the /lib directory: libpam, libpamc and libpam_misc. Both static and dynamic libs are installed. The instructions move the .a libs to /usr/lib and create .so symlinks to the /lib/libname.so.0.78 files in /usr/lib as well. What I'm curious about is why the .so symlinks are created as there are already these .so symlinks in /lib. Typically, the .so symlinks in /lib are removed and appropriate symlinks in /usr/lib are then made. However, with Linux-PAM we end up so .so symlinks in both /lib and /usr/lib. Should the /lib .so symlinks be removed? If not, do we need to create these same symlinks in /usr/lib? -- Randy rmlinux: [GNU ld version 2.15.91.0.2 20040727] [gcc (GCC) 3.4.1] [GNU C Library 2004-07-01 release version 2.3.4] [Linux 2.6.8.1 i686] 22:27:00 up 16 days, 6:16, 8 users, load average: 0.00, 0.02, 0.00 -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: Linux-PAM
Randy McMurchy wrote: Funny how some things work out. The BLFS book was just recently changed to make cracklib a required dependency of Linux-PAM. I didn't think too much about it. However, tonight I screwed up and forgot to install cracklib before installing Linux-PAM. And PAM installed just fine. The configure log shows it looked for fascistcheck and didn't find it and just plowed along. Everything installed just fine. I'll BZ this unless someone has information to the contrary. Why don't you just change it to a recommended dependency? -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: Linux-PAM
Bruce Dubbs wrote these words on 03/12/05 22:29 CST: > Why don't you just change it to a recommended dependency? Good idea. The only reason I BZ'd it was so that I didn't forget to do it. I'll be making many BLFS updates tomorrow. All of the ones I have assigned to me, and ImageMagick for sure. Perhaps some more if there is a need. -- Randy rmlscsi: [GNU ld version 2.15.94.0.2 20041220] [gcc (GCC) 3.4.3] [GNU C Library stable release version 2.3.4] [Linux 2.6.10 i686] 22:45:00 up 10 days, 8:49, 4 users, load average: 0.00, 0.00, 0.00 -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: Linux-PAM
Randy McMurchy wrote: Bruce Dubbs wrote these words on 03/12/05 22:29 CST: Why don't you just change it to a recommended dependency? Good idea. The only reason I BZ'd it was so that I didn't forget to do it. I'll be making many BLFS updates tomorrow. All of the ones I have assigned to me, and ImageMagick for sure. Perhaps some more if there is a need. Excellent. I'm still going over the firewalling. It's a long section, but I'm almost done. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Linux PAM/Shadow
Hi all, I'll try and be as concise as possible and get right to the point. The new version of Linux-PAM (see a previous post) has an issue with Shadow. Brief description: PAM installs libraries in /lib (which it should), including .la files. This is new to PAM (it uses libtool and auto* a bit heavier now). These .la files are moved to /usr/lib (as always is done in LFS and BLFS). Hardcoded in these .la files is "libdir='lib'". This apparently causes some problems when you then recompile Shadow. Shadow claims the .la files have been moved and aborts the build with an error (during the 'make'). Here are possible solutions. I'm looking for opinions as to what would be best. 1. Delete the .la files and everything is fine. Best as I can tell, .la files aren't really necessary. 2. Do a simple sed on the .la files and change the 'lib' to '/usr/lib' and everything is fine. 3. Currently the default for PAM is installation of libraries in /lib and the modules in /lib/security. We could pass 'libdir=/usr/lib' *and* 'securedir=/lib/security' to configure, then move the .so.0.81.1 and .so.0 files from /usr/lib to /lib and everything would be fine. There may be other solutions perhaps, but I didn't check into any more. I am in favor of #2. Your opinion is solicited. Thanks. -- Randy rmlscsi: [GNU ld version 2.15.94.0.2 20041220] [gcc (GCC) 3.4.3] [GNU C Library stable release version 2.3.4] [Linux 2.6.10 i686] 16:57:00 up 65 days, 2:21, 3 users, load average: 0.00, 0.00, 0.05 -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Linux Pam 0.99.3.0
Just a note to those who plan to use the latest version of pam, the library versions you need to link to are now libpam.so.0.81.2 and libpam_misc.so.0.81.2, libpamc.0.81.0 remains unchanged, as do the instructions for compiling and installing it. -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: Linux-PAM nitpicks
Randy McMurchy wrote: Hi all, Linux-PAM installs the following libraries into the /lib directory: libpam, libpamc and libpam_misc. Both static and dynamic libs are installed. The instructions move the .a libs to /usr/lib and create .so symlinks to the /lib/libname.so.0.78 files in /usr/lib as well. What I'm curious about is why the .so symlinks are created as there are already these .so symlinks in /lib. Typically, the .so symlinks in /lib are removed and appropriate symlinks in /usr/lib are then made. However, with Linux-PAM we end up so .so symlinks in both /lib and /usr/lib. Should the /lib .so symlinks be removed? If not, do we need to create these same symlinks in /usr/lib? Programs like login use PAM and must have the PAM libraries available even if /usr is not mounted, so the .so files must be available in /lib. Symlinks within or to /lib are ok. However, I do not know of a reason for the .so files to be in /usr/lib either as a symlink or a regular file. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: Linux-PAM nitpicks
Bruce Dubbs wrote these words on 02/21/05 23:04 CST: > Programs like login use PAM and must have the PAM libraries available > even if /usr is not mounted, so the .so files must be available in /lib. > Symlinks within or to /lib are ok. It is my understanding that the .so files, like the .a files are only used for linking during compilation of other programs. For instance, in LFS the shadow package installs all the libs in /lib, but the .so files are removed and resymlinked in /usr/lib. The .a files are moved to /usr/lib. To me, there's no difference in the shadow libs and the pam libs. They're both required for login, even if /usr is not mounted. -- Randy rmlinux: [GNU ld version 2.15.91.0.2 20040727] [gcc (GCC) 3.4.1] [GNU C Library 2004-07-01 release version 2.3.4] [Linux 2.6.8.1 i686] 23:16:00 up 16 days, 7:05, 8 users, load average: 0.03, 0.03, 0.09 -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: Linux-PAM nitpicks
Randy McMurchy wrote: Bruce Dubbs wrote these words on 02/21/05 23:04 CST: It is my understanding that the .so files, like the .a files are only used for linking during compilation of other programs. Incorrect. They are loaded when the program is loaded. If they are already in memory, they do not need to be loaded again -- they are reused. Thats the advantage of dynamically loaded libraries (dll) or shared objects (so). When building with static (.a) libraries, the code is inserted into the program at link time. There is never a resson to have static libraries in /lib, but it should have any shared object that is needed by programs in /bin or /sbin. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: Linux-PAM nitpicks
Bruce Dubbs wrote these words on 02/21/05 23:31 CST: > Randy McMurchy wrote: >>It is my understanding that the .so files, like the .a files are only >>used for linking during compilation of other programs. > > Incorrect. They are loaded when the program is loaded. If they are > already in memory, they do not need to be loaded again -- they are > reused. Thats the advantage of dynamically loaded libraries (dll) or > shared objects (so). Perhaps I'm not making myself clear here. First of all, I realize what the purpose of the dynamic libs are for, and the difference between them and static libs. However, for the sake of clarity, I'll outline what I meant. PAM installs these libs in /lib: libpam.so.0.78 libpamc.so.0.78 libpam_misc.so.0.78 Then there are symlinks to these libraries: libpam.so.0 libpam.so others not displayed Now, my understanding is that the binary library and the symlink with the major number are required in /lib. The symlink without a major or minor number (the .so) symlink can be in /usr/lib. Like LFS does the Shadow libraries. You didn't address that part of my last post, and to me, what you say above contradicts the LFS installation of Shadow where the binary and the symlink with a major number is in /lib and the .so symlink is in /usr/lib. -- Randy rmlinux: [GNU ld version 2.15.91.0.2 20040727] [gcc (GCC) 3.4.1] [GNU C Library 2004-07-01 release version 2.3.4] [Linux 2.6.8.1 i686] 23:36:00 up 16 days, 7:25, 8 users, load average: 0.04, 0.04, 0.05 -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: Linux-PAM nitpicks
Bruce Dubbs wrote: Randy McMurchy wrote: Hi all, Linux-PAM installs the following libraries into the /lib directory: libpam, libpamc and libpam_misc. Both static and dynamic libs are installed. The instructions move the .a libs to /usr/lib and create .so symlinks to the /lib/libname.so.0.78 files in /usr/lib as well. What I'm curious about is why the .so symlinks are created as there are already these .so symlinks in /lib. Typically, the .so symlinks in /lib are removed and appropriate symlinks in /usr/lib are then made. However, with Linux-PAM we end up so .so symlinks in both /lib and /usr/lib. Should the /lib .so symlinks be removed? If not, do we need to create these same symlinks in /usr/lib? Programs like login use PAM and must have the PAM libraries available even if /usr is not mounted, so the .so files must be available in /lib. Symlinks within or to /lib are ok. However, I do not know of a reason for the .so files to be in /usr/lib either as a symlink or a regular file. -- Bruce .so files belong in /usr/lib .so.version belong in /lib. -- -- [EMAIL PROTECTED] [EMAIL PROTECTED] LFS User # 2577 Registered Linux User # 299986 -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: Linux-PAM nitpicks
Jim Gifford wrote these words on 02/21/05 23:57 CST: > .so files belong in /usr/lib .so.version belong in /lib. And to further clarify, .so *symlinks* belong in /usr/lib. Binaries that are named somelibname.version.so may belong in /lib. -- Randy rmlinux: [GNU ld version 2.15.91.0.2 20040727] [gcc (GCC) 3.4.1] [GNU C Library 2004-07-01 release version 2.3.4] [Linux 2.6.8.1 i686] 00:00:00 up 16 days, 7:49, 8 users, load average: 0.01, 0.12, 0.11 -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: Linux-PAM nitpicks
Jim Gifford wrote: .so files belong in /usr/lib .so.version belong in /lib. I'm not sure what you are saying here Jim. If the library file is either referenced as a symlink or a regular file by an excutable file in /bin or /sbin, it needs to be in /lib. There should be no links from /lib to a location outside of /lib. The rule here is that the programs must be execuatable if /usr is not mounted. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: Linux-PAM nitpicks
Bruce Dubbs wrote these words on 02/22/05 00:27 CST: > Jim Gifford wrote: > >>.so files belong in /usr/lib .so.version belong in /lib. > > I'm not sure what you are saying here Jim. If the library file > is either referenced as a symlink or a regular file by an excutable file > in /bin or /sbin, it needs to be in /lib. There should be no links from > /lib to a location outside of /lib. The rule here is that the programs > must be execuatable if /usr is not mounted. So I can get a better handle on what you're trying to drive at Bruce, let's use the /bin/login program as an example. [EMAIL PROTECTED]: ~ > ldd /bin/login linux-gate.so.1 => (0xe000) libmisc.so.0 => /lib/libmisc.so.0 (0x4003b000) libshadow.so.0 => /lib/libshadow.so.0 (0x4004c000) libcrypt.so.1 => /lib/libcrypt.so.1 (0x40063000) libpam.so.0 => /lib/libpam.so.0 (0x40091000) libpam_misc.so.0 => /lib/libpam_misc.so.0 (0x4009a000) libc.so.6 => /lib/libc.so.6 (0x4009d000) libdl.so.2 => /lib/libdl.so.2 (0x401b3000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x4000) How does the libpam.so symlink factor into *any* requirement of the login program? -- Randy rmlinux: [GNU ld version 2.15.91.0.2 20040727] [gcc (GCC) 3.4.1] [GNU C Library 2004-07-01 release version 2.3.4] [Linux 2.6.8.1 i686] 00:38:00 up 16 days, 8:27, 8 users, load average: 0.03, 0.04, 0.02 -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: Linux-PAM nitpicks
Randy McMurchy wrote: Bruce Dubbs wrote these words on 02/22/05 00:27 CST: Jim Gifford wrote: .so files belong in /usr/lib .so.version belong in /lib. I'm not sure what you are saying here Jim. If the library file is either referenced as a symlink or a regular file by an excutable file in /bin or /sbin, it needs to be in /lib. There should be no links from /lib to a location outside of /lib. The rule here is that the programs must be execuatable if /usr is not mounted. So I can get a better handle on what you're trying to drive at Bruce, let's use the /bin/login program as an example. [EMAIL PROTECTED]: ~ > ldd /bin/login linux-gate.so.1 => (0xe000) libmisc.so.0 => /lib/libmisc.so.0 (0x4003b000) libshadow.so.0 => /lib/libshadow.so.0 (0x4004c000) libcrypt.so.1 => /lib/libcrypt.so.1 (0x40063000) libpam.so.0 => /lib/libpam.so.0 (0x40091000) ^^^ libpam_misc.so.0 => /lib/libpam_misc.so.0 (0x4009a000) libc.so.6 => /lib/libc.so.6 (0x4009d000) libdl.so.2 => /lib/libdl.so.2 (0x401b3000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x4000) How does the libpam.so symlink factor into *any* requirement of the login program? Do a ls -l /lib/libpam* Don't you have something like: lrwxrwxrwx 1 root root14 /lib/libpam.so.0-> libpam.so.0.78 -rwxr-xr-x 1 root root 30448 /lib/libpam.so.0.78 The program accesses the symlink, which must be available in /lib. The link accesses the file which also must be in /lib. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: Linux-PAM nitpicks
Bruce Dubbs wrote: Jim Gifford wrote: .so files belong in /usr/lib .so.version belong in /lib. I'm not sure what you are saying here Jim. If the library file is either referenced as a symlink or a regular file by an excutable file in /bin or /sbin, it needs to be in /lib. There should be no links from /lib to a location outside of /lib. The rule here is that the programs must be execuatable if /usr is not mounted. -- Bruce I had a long discussion with a lot of people on this issue. The actualy libaries get installed into /lib, but the symlinks for those libraries (.so) are in /usr/lib. Tushar and others corrected me on this issue in the past. Look in lfs-dev from when I changed the shadow and readline to use --libdir. -- -- [EMAIL PROTECTED] [EMAIL PROTECTED] LFS User # 2577 Registered Linux User # 299986 -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: Linux-PAM nitpicks
Jim Gifford wrote: Bruce Dubbs wrote: Jim Gifford wrote: .so files belong in /usr/lib .so.version belong in /lib. I'm not sure what you are saying here Jim. If the library file is either referenced as a symlink or a regular file by an excutable file in /bin or /sbin, it needs to be in /lib. There should be no links from /lib to a location outside of /lib. The rule here is that the programs must be execuatable if /usr is not mounted. -- Bruce I had a long discussion with a lot of people on this issue. The actualy libaries get installed into /lib, but the symlinks for those libraries (.so) are in /usr/lib. Tushar and others corrected me on this issue in the past. Look in lfs-dev from when I changed the shadow and readline to use --libdir. If /usr is not mounted and an executable needs a .so library defined by one of those symlinks placed on /usr/lib/, how does the program find it? -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: Linux-PAM nitpicks
Bruce Dubbs wrote: Jim Gifford wrote: Bruce Dubbs wrote: Jim Gifford wrote: .so files belong in /usr/lib .so.version belong in /lib. I'm not sure what you are saying here Jim. If the library file is either referenced as a symlink or a regular file by an excutable file in /bin or /sbin, it needs to be in /lib. There should be no links from /lib to a location outside of /lib. The rule here is that the programs must be execuatable if /usr is not mounted. -- Bruce I had a long discussion with a lot of people on this issue. The actualy libaries get installed into /lib, but the symlinks for those libraries (.so) are in /usr/lib. Tushar and others corrected me on this issue in the past. Look in lfs-dev from when I changed the shadow and readline to use --libdir. If /usr is not mounted and an executable needs a .so library defined by one of those symlinks placed on /usr/lib/, how does the program find it? -- Bruce It's part of the ld-2.3.4.so file, it checks the ld.so.cache file. To see where the symlink was created, and have a dynamic link that's valid. That's why most packages run ldconfig after the library install so the correct file could be found. Here is a little information I found */lib/ld-linux.so.** ELF dynamic linker/loader */etc/ld.so.cache* File containing a compiled list of directories in which to search for libraries and an ordered list of candidate libraries. -- [EMAIL PROTECTED] [EMAIL PROTECTED] LFS User # 2577 Registered Linux User # 299986 -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: Linux-PAM nitpicks
On Tue, Feb 22, 2005 at 12:48:27AM -0600, Bruce Dubbs wrote: > > lrwxrwxrwx 1 root root14 /lib/libpam.so.0-> libpam.so.0.78 > -rwxr-xr-x 1 root root 30448 /lib/libpam.so.0.78 I think this is where the confusion is. .so symlinks != .so.version symlinks. .so.version is what ldd references whereas from what I understand a program that needs the lib at compile time looks for just the plain .so unless a version-dependent check is required by the program being built, in which case it will likely look for .so.version. If the above understanding is correct, then .so.version should be in /lib if required at boot, and all .so links should be in /usr/lib because they are *only* used at compile time. With that said, though, it seems bad for organization to put a real lib in /lib only to obfuscate things by putting links to it in /usr/lib. I don't know why it is done that way except to keep /lib small, but if a lib is in /lib, so should *all* it's links be, IMO. Again, this is only for organization. I just don't see the benefit of splitting them up and causing us to have 2 dirs to work with for the same library. -- Archaic Want control, education, and security from your operating system? Hardened Linux From Scratch http://www.linuxfromscratch.org/hlfs -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: Linux-PAM nitpicks
Bruce Dubbs wrote: Jim Gifford wrote: Bruce Dubbs wrote: Jim Gifford wrote: .so files belong in /usr/lib .so.version belong in /lib. I'm not sure what you are saying here Jim. If the library file is either referenced as a symlink or a regular file by an excutable file in /bin or /sbin, it needs to be in /lib. There should be no links from /lib to a location outside of /lib. The rule here is that the programs must be execuatable if /usr is not mounted. -- Bruce I had a long discussion with a lot of people on this issue. The actualy libaries get installed into /lib, but the symlinks for those libraries (.so) are in /usr/lib. Tushar and others corrected me on this issue in the past. Look in lfs-dev from when I changed the shadow and readline to use --libdir. If /usr is not mounted and an executable needs a .so library defined by one of those symlinks placed on /usr/lib/, how does the program find it? -- Bruce This comes up every so often.. Check the lfs-dev archives from February 2002, and read through the thread titled "ncurses installation commands". Here's where it starts: http://archives.linuxfromscratch.org/mail-archives/lfs-dev/2002-February/023335.html Mabe check this thread too: http://archives.linuxfromscratch.org/mail-archives/lfs-dev/2002-February/023335.html There is also some relevant info in the Debian policy manual (not that we're Debian): http://www.debian.org/doc/debian-policy/ch-sharedlibs.html Jack Brown -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: Linux-PAM nitpicks
Archaic wrote: On Tue, Feb 22, 2005 at 12:48:27AM -0600, Bruce Dubbs wrote: lrwxrwxrwx 1 root root14 /lib/libpam.so.0-> libpam.so.0.78 -rwxr-xr-x 1 root root 30448 /lib/libpam.so.0.78 I think this is where the confusion is. .so symlinks != .so.version symlinks. .so.version is what ldd references whereas from what I understand a program that needs the lib at compile time looks for just the plain .so unless a version-dependent check is required by the program being built, in which case it will likely look for .so.version. If the above understanding is correct, then .so.version should be in /lib if required at boot, and all .so links should be in /usr/lib because they are *only* used at compile time. Great explanation.. With that said, though, it seems bad for organization to put a real lib in /lib only to obfuscate things by putting links to it in /usr/lib. I don't know why it is done that way except to keep /lib small, but if a lib is in /lib, so should *all* it's links be, IMO. Again, this is only for organization. I just don't see the benefit of splitting them up and causing us to have 2 dirs to work with for the same library. The problem is that if you have lib-something.so in /lib and lib-something.a in /usr/lib, then when a package goes looking for lib-something to link into it's package it looks to /usr/lib sees the lib-something.a file and then stops looking any further and links against the static library instead of the dynamic one. I suppose we _could_ move all the lib-something.a and lib-something.la files to /lib as well, but then how big would /lib be by the time you finished with, oh lets say, Glibc! Besides I'm not even sure if the linker would do the right thing if everything is in /lib or if at least some of it has to be in /usr/lib. (besides it's not like we move the includes to /include and *.so symlinks kind of fall under that umbrella) Jack Brown -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: Linux-PAM nitpicks
On Tue, Feb 22, 2005 at 03:27:02AM -0600, Jack Brown wrote: > > Great explanation.. Thanks. :) > The problem is that if you have lib-something.so in /lib and > lib-something.a in /usr/lib, then when a package goes looking for > lib-something to link into it's package it looks to /usr/lib sees the > lib-something.a file and then stops looking any further and links > against the static library instead of the dynamic one. Aha! So there is a method to this madness. I hereby reject my claim to organization. :) -- Archaic Want control, education, and security from your operating system? Hardened Linux From Scratch http://www.linuxfromscratch.org/hlfs -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: Linux-PAM nitpicks
Archaic wrote: On Tue, Feb 22, 2005 at 03:27:02AM -0600, Jack Brown wrote: Great explanation.. Thanks. :) The problem is that if you have lib-something.so in /lib and lib-something.a in /usr/lib, then when a package goes looking for lib-something to link into it's package it looks to /usr/lib sees the lib-something.a file and then stops looking any further and links against the static library instead of the dynamic one. Aha! So there is a method to this madness. I hereby reject my claim to organization. :) OK. So let me summarize, at least for BLFS. 1. All .a files go in /usr/lib unless there is a specific (rare) movement to a package specific directory (X, KDE, etc). 2. .so.version files go in /usr/lib by default. The exceptions are as follows: a. Movement to a package specific directory as in 1. b. Movement to /lib for programs in /bin and /sbin 3. Links to .so.version files should go in both /usr/lib and /lib for reasons stated above. Note: a quick check of SuSE and RedHat shows policy consistent with this. For BLFS, the only packages that I see affected by 2b and 3 are PAM and shadow. These could affect login under a recovery scenario where /usr is not available. Is this consistent with everyone's understanding? -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: Linux-PAM nitpicks
Bruce Dubbs wrote these words on 02/22/05 10:28 CST: > 3. Links to .so.version files should go in both /usr/lib and /lib for > reasons stated above. Note: a quick check of SuSE and RedHat shows > policy consistent with this. > > Is this consistent with everyone's understanding? No. I don't understand why the .so symlinks linked to the .so.version file needs to be in both /usr/lib and /lib. -- Randy rmlinux: [GNU ld version 2.15.91.0.2 20040727] [gcc (GCC) 3.4.1] [GNU C Library 2004-07-01 release version 2.3.4] [Linux 2.6.8.1 i686] 10:45:00 up 16 days, 18:34, 8 users, load average: 0.08, 0.12, 0.05 -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: Linux-PAM nitpicks
Randy McMurchy wrote: I don't understand why the .so symlinks linked to the .so.version file needs to be in both /usr/lib and /lib. I don't either. The .so symlinks (no version) are used only at linking time. -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: Linux-PAM nitpicks
Randy McMurchy wrote: Bruce Dubbs wrote these words on 02/22/05 10:28 CST: 3. Links to .so.version files should go in both /usr/lib and /lib for reasons stated above. Note: a quick check of SuSE and RedHat shows policy consistent with this. Is this consistent with everyone's understanding? No. I don't understand why the .so symlinks linked to the .so.version file needs to be in both /usr/lib and /lib. I read the thread that Jack gave and Gerard wants to keep the links in both places: /usr/lib because they are needed and /lib for consistency. After all, this is primarily an LFS issue and only marginally a BLFS issue. Additionally, I suspect they are needed on /lib in the case that ld.so.cache becomes unavailable for some reason. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: Linux-PAM nitpicks
Bruce Dubbs wrote these words on 02/22/05 11:23 CST: > I read the thread that Jack gave and Gerard wants to keep the links in > both places: /usr/lib because they are needed and /lib for consistency. >After all, this is primarily an LFS issue and only marginally a BLFS > issue. Additionally, I suspect they are needed on /lib in the case that > ld.so.cache becomes unavailable for some reason. Well, then, I suppose the LFS gang needs to all get on the same page. The Readline and Shadow instructions don't agree with what you say above. Furthermore, here's the million dollar question: When we update BLFS to go to Shadow-4.0.7, do we install it as LFS does, or do we install it differently (include the .so symlink in /lib)? To me, however the Shadow instructions are done in BLFS, the PAM instructions should match. -- Randy rmlinux: [GNU ld version 2.15.91.0.2 20040727] [gcc (GCC) 3.4.1] [GNU C Library 2004-07-01 release version 2.3.4] [Linux 2.6.8.1 i686] 11:28:00 up 16 days, 19:17, 8 users, load average: 0.04, 0.07, 0.08 -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: Linux-PAM nitpicks
Randy McMurchy wrote: Well, then, I suppose the LFS gang needs to all get on the same page. The Readline and Shadow instructions don't agree with what you say above. All the linker scripts that come with GNU binutils search /lib before /usr/lib; if you put a .so (non-versioned) symlink into /lib, then the one in /usr/lib is pointless, it will never get used. Also, ldconfig will not keep that link updated, because its target is not in the same directory. My opinion is that the .so and .so.version symlinks should only be in the directory where the actual shared object resides. -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: Linux-PAM nitpicks
Randy McMurchy wrote:
Bruce Dubbs wrote these words on 02/22/05 11:23 CST:
I read the thread that Jack gave and Gerard wants to keep the links in
both places: /usr/lib because they are needed and /lib for consistency.
After all, this is primarily an LFS issue and only marginally a BLFS
issue. Additionally, I suspect they are needed on /lib in the case that
ld.so.cache becomes unavailable for some reason.
Well, then, I suppose the LFS gang needs to all get on the same page.
The Readline and Shadow instructions don't agree with what you say
above.
As I look at LFS 6.0, I see:
mv /usr/lib/lib{shadow,misc}.so.0* /lib
ln -sf ../../lib/libshadow.so.0 /usr/lib/libshadow.so
ln -sf ../../lib/libmisc.so.0 /usr/lib/libmisc.so
and
mv /usr/lib/lib{readline,history}.so.5* /lib
ln -sf ../../lib/libhistory.so.5 /usr/lib/libhistory.so
ln -sf ../../lib/libreadline.so.5 /usr/lib/libreadline.so
Which seems consistent to me.
Furthermore, here's the million dollar question:
When we update BLFS to go to Shadow-4.0.7, do we install it as LFS does,
or do we install it differently (include the .so symlink in /lib)?
Looking at LFS and BLFS, I believe the instructions are consistent now.
Of course we are adding PAM, so there is some difference. Do you see
an issue that I don't?
I do see a minor issue that is related. The lines:
mv /bin/sg /usr/bin &&
mv /bin/vigr /usr/sbin &&
mv /usr/bin/passwd /bin &&
rm /bin/groups &&
./configure --libdir=/usr/lib still installs programs in /bin it
appears. We don't have explainations for these commands. Also, does it
install passwd in /usr/bin? Seems inconsistent.
To me, however the Shadow instructions are done in BLFS, the PAM
instructions should match.
Match or be consistent? As I said, I think we are consistent now.
-- Bruce
--
http://linuxfromscratch.org/mailman/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
Re: Linux-PAM nitpicks
Bruce Dubbs wrote these words on 02/22/05 12:11 CST:
> As I look at LFS 6.0, I see:
> mv /usr/lib/lib{shadow,misc}.so.0* /lib
> ln -sf ../../lib/libshadow.so.0 /usr/lib/libshadow.so
> ln -sf ../../lib/libmisc.so.0 /usr/lib/libmisc.so
>
> and
>
> mv /usr/lib/lib{readline,history}.so.5* /lib
> ln -sf ../../lib/libhistory.so.5 /usr/lib/libhistory.so
> ln -sf ../../lib/libreadline.so.5 /usr/lib/libreadline.so
>
> Which seems consistent to me.
We're just not on the same page here. Perhaps someone else needs
to jump in and explain it in a manner different than I. Others
(Kevin and Jim) are understanding what I'm saying.
Bruce, you are not.
This is the last time I'll try, otherwise, let's just forget about
it. It's really not that big of a deal.
But in the LFS versions of both Shadow and Readline the unversioned
.so symlink is in /usr/lib. The other files related to the libraries
are in /lib.
In the PAM instructions, the unversioned .so file is both in /usr/lib
and /lib.
This is not consistent.
--
Randy
rmlinux: [GNU ld version 2.15.91.0.2 20040727] [gcc (GCC) 3.4.1]
[GNU C Library 2004-07-01 release version 2.3.4] [Linux 2.6.8.1 i686]
12:16:00 up 16 days, 20:05, 9 users, load average: 0.10, 0.06, 0.01
--
http://linuxfromscratch.org/mailman/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
Re: Linux-PAM nitpicks
Pardon my jumping in here but all of this discussion about PAM reminded me of an issue from a while back regarding segmentation faults with PAM/Shadow/Cracklib (as seen in the threads linked to below). Someone on IRC was having the same sort of issues just yesterday. Has this matter been solved? http://archives.linuxfromscratch.org/mail-archives/blfs-support/2004-August/051475.html http://archives.linuxfromscratch.org/mail-archives/blfs-dev/2005-January/008987.html Mike -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: Linux-PAM nitpicks
Randy McMurchy wrote: We're just not on the same page here. This is the last time I'll try, otherwise, let's just forget about it. It's really not that big of a deal. The devil is in the details and we all need to understand. If I'm wrong, I want to know. But in the LFS versions of both Shadow and Readline the unversioned .so symlink is in /usr/lib. The other files related to the libraries are in /lib. Looking at an LFS6 install: $ ls -l /lib/libread* /lib/libsha* /usr/lib/libread* /usr/lib/libsha* lrwxrwxrwx 1 root root 18 Jan 17 09:32 /lib/libreadline.so.5 -> libreadline.so.5.0 -rwxr-xr-x 1 root root 206725 Jan 17 15:54 /lib/libreadline.so.5.0 lrwxrwxrwx 1 root root 18 Jan 17 15:45 /lib/libshadow.so.0 -> libshadow.so.0.0.0 -rwxr-xr-x 1 root root 47905 Jan 17 15:54 /lib/libshadow.so.0.0.0 -rw-r--r-- 1 root root 261142 Jan 17 15:54 /usr/lib/libreadline.a lrwxrwxrwx 1 root root 26 Jan 17 09:33 /usr/lib/libreadline.so -> ../../lib/libreadline.so.5 -rw-r--r-- 1 root root 717482 Jan 17 15:45 /usr/lib/libshadow.a -rwxr-xr-x 1 root root804 Jan 17 15:45 /usr/lib/libshadow.la lrwxrwxrwx 1 root root 24 Jan 17 15:46 /usr/lib/libshadow.so -> ../../lib/libshadow.so.0 I think you are saying that there is no link in /usr/lib: libreadline.so.5 libshadow.so.0 Is that correct? Checking further, cracklib is a prereq for PAM and it dow not install any links or files in /usr/lib. However, following the book's instructions for PAM we have: $ ls -l /lib/libpam* /usr/lib/libpam* lrwxrwxrwx 1 root root 11 Feb 22 13:44 /lib/libpam.so -> libpam.so.0 lrwxrwxrwx 1 root root 14 Feb 22 13:44 /lib/libpam.so.0 -> libpam.so.0.78 -rwxr-xr-x 1 root root 85919 Feb 22 13:44 /lib/libpam.so.0.78 lrwxrwxrwx 1 root root 16 Feb 22 13:44 /lib/libpam_misc.so -> libpam_misc.so.0 lrwxrwxrwx 1 root root 19 Feb 22 13:44 /lib/libpam_misc.so.0 -> libpam_misc.so.0.78 -rwxr-xr-x 1 root root 20559 Feb 22 13:44 /lib/libpam_misc.so.0.78 lrwxrwxrwx 1 root root 12 Feb 22 13:44 /lib/libpamc.so -> libpamc.so.0 lrwxrwxrwx 1 root root 15 Feb 22 13:44 /lib/libpamc.so.0 -> libpamc.so.0.78 -rwxr-xr-x 1 root root 25306 Feb 22 13:44 /lib/libpamc.so.0.78 -rw-r--r-- 1 root root 147712 Feb 22 13:44 /usr/lib/libpam.a lrwxrwxrwx 1 root root 24 Feb 22 13:44 /usr/lib/libpam.so -> ../../lib/libpam.so.0.78 -rw-r--r-- 1 root root 22078 Feb 22 13:44 /usr/lib/libpam_misc.a lrwxrwxrwx 1 root root 29 Feb 22 13:44 /usr/lib/libpam_misc.so -> ../../lib/libpam_misc.so.0.78 -rw-r--r-- 1 root root 30802 Feb 22 13:44 /usr/lib/libpamc.a lrwxrwxrwx 1 root root 25 Feb 22 13:44 /usr/lib/libpamc.so -> ../../lib/libpamc.so.0.78 This puts a single .so file in /usr/lib for each pam library. I don't see the inconsistency with LFS. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: Linux-PAM nitpicks
Bruce Dubbs wrote these words on 02/22/05 13:50 CST:
> This puts a single .so file in /usr/lib for each pam library. I don't see
> the inconsistency with LFS.
You are overlooking what I've been talking about since I started
this thread. :-)
I think the following example is going to clarify this finally for
you:
[EMAIL PROTECTED]: ~ > ls -l {,/usr}/lib/lib{read,shadow}*.so
ls: /lib/libread*.so: No such file or directory
ls: /lib/libshadow*.so: No such file or directory
lrwxrwxrwx 1 root root 26 Sep 28 19:34 /usr/lib/libreadline.so ->
../../lib/libreadline.so.5
lrwxrwxrwx 1 root root 24 Oct 6 07:57 /usr/lib/libshadow.so ->
../../lib/libshadow.so.0
[EMAIL PROTECTED]: ~ >
[EMAIL PROTECTED]: ~ >
[EMAIL PROTECTED]: ~ > ls -l {,/usr}/lib/libpam*.so
lrwxrwxrwx 1 root root 11 Oct 5 16:19 /lib/libpam.so -> libpam.so.0
lrwxrwxrwx 1 root root 16 Oct 5 16:19 /lib/libpam_misc.so -> libpam_misc.so.0
lrwxrwxrwx 1 root root 12 Oct 5 16:19 /lib/libpamc.so -> libpamc.so.0
lrwxrwxrwx 1 root root 24 Oct 5 16:20 /usr/lib/libpam.so ->
../../lib/libpam.so.0.77
lrwxrwxrwx 1 root root 29 Oct 5 16:20 /usr/lib/libpam_misc.so ->
../../lib/libpam_misc.so.0.77
lrwxrwxrwx 1 root root 25 Oct 5 16:20 /usr/lib/libpamc.so ->
../../lib/libpamc.so.0.77
See the difference?
There are no .so files in /lib for Readline and Shadow. There is for
PAM. This is what I've been trying to say all along.
Additionally, the PAM .so files are in *both* directories. They are
not for Readline and Shadow.
--
Randy
rmlinux: [GNU ld version 2.15.91.0.2 20040727] [gcc (GCC) 3.4.1]
[GNU C Library 2004-07-01 release version 2.3.4] [Linux 2.6.8.1 i686]
14:13:00 up 16 days, 22:02, 8 users, load average: 0.11, 0.06, 0.01
--
http://linuxfromscratch.org/mailman/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
Re: Linux-PAM nitpicks
On February 22, 2005 01:18 pm, Randy McMurchy wrote: > See the difference? > > There are no .so files in /lib for Readline and Shadow. There is for > PAM. This is what I've been trying to say all along. > > Additionally, the PAM .so files are in *both* directories. They are > not for Readline and Shadow. Let me jump in here also and bring up the thread that Jack pointed out. That thread dated from February 2002, three years ago now. It's a little dated in that things have changed since. The *.so files go in /usr/lib only, not in both /lib and /usr/lib. The *.so.* files (add the major versoin number to it) might go in /lib if they are required before /usr is mounted or should be available in case of /usr partition corruption per standard conventions. PAM has /lib/libpam.so files which don't belong in /lib. These are compile-time and link-time libraries only. There's no need for them to be in /lib. The runtime libraries are libpam.so.version (libpam.so.0 in this case) and do belong in /lib. -- Gerard Beekmans /* If Linux doesn't have the solution, you have the wrong problem */ -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: Linux-PAM nitpicks
Randy McMurchy wrote: I think the following example is going to clarify this finally for you: There are no .so files in /lib for Readline and Shadow. There is for PAM. This is what I've been trying to say all along. Additionally, the PAM .so files are in *both* directories. They are not for Readline and Shadow. OK. I think I finally see what you are saying. From my previous post: lrwxrwxrwx 1 root root 11 Feb 22 13:44 /lib/libpam.so -> libpam.so.0 lrwxrwxrwx 1 root root 16 Feb 22 13:44 /lib/libpam_misc.so -> libpam_misc.so.0 lrwxrwxrwx 1 root root 12 Feb 22 13:44 /lib/libpamc.so -> libpamc.so.0 are unnecessary. And should be in /usr/lib only. I think we then need to also remove /lib/libcrack.so -> libcrack.so.2.7 -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: Linux-PAM nitpicks
Gerard Beekmans <[EMAIL PROTECTED]> wrote in news:[EMAIL PROTECTED]: > On February 22, 2005 01:18 pm, Randy McMurchy wrote: >> See the difference? >> >> There are no .so files in /lib for Readline and Shadow. There is for >> PAM. This is what I've been trying to say all along. >> >> Additionally, the PAM .so files are in *both* directories. They are >> not for Readline and Shadow. > > Let me jump in here also and bring up the thread that Jack pointed > out. That thread dated from February 2002, three years ago now. It's a > little dated in that things have changed since. The *.so files go in > /usr/lib only, not in both /lib and /usr/lib. The *.so.* files (add > the major versoin number to it) might go in /lib if they are required > before /usr is mounted or should be available in case of /usr > partition corruption per standard conventions. > > PAM has /lib/libpam.so files which don't belong in /lib. These are > compile-time and link-time libraries only. There's no need for them to > be in /lib. The runtime libraries are libpam.so.version (libpam.so.0 > in this case) and do belong in /lib. > hmm... [EMAIL PROTECTED] /1]$ ldd /bin/sleep linux-gate.so.1 => (0xe000) libm.so.6 => /lib/libm.so.6 (0xb7fc5000) librt.so.1 => /lib/librt.so.1 (0xb7fbd000) libc.so.6 => /lib/libc.so.6 (0xb7eaf000) /lib/ld-linux.so.2 (0xb7fec000) libpthread.so.0 => /lib/libpthread.so.0 (0xb7e9d000) [EMAIL PROTECTED] /]$ ls -l /lib/libm* -rwxr-xr-x 1 root root 146040 Feb 11 20:48 /lib/libm-2.3.4.so lrwxrwxrwx 1 root root 13 Feb 11 22:14 /lib/libm.so.6 -> libm-2.3.4.so -rwxr-xr-x 1 root root 13724 Feb 11 20:48 /lib/libmemusage.so [EMAIL PROTECTED] /]$ file /lib/libm-2.3.4.so /lib/libm-2.3.4.so: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), stripped How does that gel with the paragraphs above? libm-2.3.4.so is the actual runtime library, not only the compile\linking library... -- - Steve Crosby -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: Linux-PAM nitpicks
Steve Crosby wrote these words on 02/22/05 19:56 CST: > How does that gel with the paragraphs above? libm-2.3.4.so is the actual > runtime library, not only the compile\linking library... Though I'm not certain Gerard was just talking about symlinks named *.so, I was. The whole point of this discussion was what to do with *symlinks* named *.so. -- Randy rmlinux: [GNU ld version 2.15.91.0.2 20040727] [gcc (GCC) 3.4.1] [GNU C Library 2004-07-01 release version 2.3.4] [Linux 2.6.8.1 i686] 20:06:00 up 17 days, 3:55, 8 users, load average: 0.86, 0.54, 0.20 -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: Linux-PAM nitpicks
On February 22, 2005 07:07 pm, Randy McMurchy wrote: > Though I'm not certain Gerard was just talking about symlinks named > *.so, I was. The whole point of this discussion was what to do with > *symlinks* named *.so. Yes I meant symlinks though I didn't specify it. We can't of course control actual library files that are named improperly. Well, I suppose we could fix that during the installations of the packages but I'm not sure if we should start to do such a thing. -- Gerard Beekmans /* If Linux doesn't have the solution, you have the wrong problem */ -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: Linux-PAM nitpicks
Steve Crosby wrote: hmm... [EMAIL PROTECTED] /1]$ ldd /bin/sleep linux-gate.so.1 => (0xe000) libm.so.6 => /lib/libm.so.6 (0xb7fc5000) librt.so.1 => /lib/librt.so.1 (0xb7fbd000) libc.so.6 => /lib/libc.so.6 (0xb7eaf000) /lib/ld-linux.so.2 (0xb7fec000) libpthread.so.0 => /lib/libpthread.so.0 (0xb7e9d000) [EMAIL PROTECTED] /]$ ls -l /lib/libm* -rwxr-xr-x 1 root root 146040 Feb 11 20:48 /lib/libm-2.3.4.so lrwxrwxrwx 1 root root 13 Feb 11 22:14 /lib/libm.so.6 -> libm-2.3.4.so -rwxr-xr-x 1 root root 13724 Feb 11 20:48 /lib/libmemusage.so [EMAIL PROTECTED] /]$ file /lib/libm-2.3.4.so /lib/libm-2.3.4.so: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), stripped How does that gel with the paragraphs above? libm-2.3.4.so is the actual runtime library, not only the compile\linking library... -- - Steve Crosby The problem is here is just that Glibc is a bit weird with how they name their libraries for whatever reason. If you notice there is an "unversioned *.so symlink" in /usr/lib. On my system I get: /usr/lib/libm.so -> ../../lib/libm.so.6 So, things still work the same, just the naming is a bit off. Here's how I look at it: You go to compile something, it decides that it want's libm and starts off looking at /usr/lib to see what it can find. It comes across a file /usr/lib/libm.so which is linked to a file called /lib/libm.so.6. based on this it tells the linker to link the resulting binary to a file named /lib/libm.so.6. When you run the program it sees that it need to load up the file /lib/libm.so.6 and in doing so ends up following the symlink and ends up actually loading /lib/libm.2.3.4.so in the process. Some months later you decide to upgrade Glibc to version 2.3.5 (I'll make the assumption the 2.x.x versions are ABI compatible). so now you have: /usr/lib/libm.so -> ../../lib/libm.so.6 /lib/libm.so.6 -> libm.2.3.5.so /usr/libm.2.3.4.so (the old left over lib) /usr/libm.2.3.5.so (the newley installed lib) Now when we run the binary it will try to load /lib/libm.so.6 again, but this time, it ends up using libm.2.3.5.so instead, and libm.2.3.4.so just gets left by the way side.. Then, a while later you decide to install the brand new Glibc 3.0! (Glibc is probably a bad example cause Glibc 3.0 seems to me like something out of science fiction..) ..Now, you end up with this: /usr/lib/libm.so -> ../../lib/libm.so.7 /lib/libm.so.6 -> libm.2.3.5.so /lib/libm.so.7 -> libm.3.0.so (oooh this is new!) /usr/libm.2.3.4.so (now old and crusty) /usr/libm.2.3.5.so (also crusty) /lib/libm.3.0.so (brand spanking new lib with incompatible ABI) So now if you run the binary you made at the start it will use (tada) _the same old lib as before!_ ie. it will look to libm.so.6 (because that was hardcoded at compile time) and see it _still_ points to libm.2.3.5.so. _However_ if you were to compile it over again the linker would start off (again) by looking for libm.so, starting in /usr/lib, it would see that it now points to /lib/libm.so.7 and hardcode that into the new binary instead. Then when the new binary is run it will follow libm.so.7 and see that it now needs to use /lib/libm.3.0.so instead. I hope that helps a bit. Jack Brown -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: Linux-PAM nitpicks
Jack Brown wrote these words on 02/23/05 23:39 CST: > Steve Crosby wrote: >>hmm... > [snip headache inducing material :-)] > I hope that helps a bit. Geez. No offense, but that was pretty tough reading. How 'bout this instead: If you upgrade Glibc, start over from scratch. :-) -- Randy rmlinux: [GNU ld version 2.15.91.0.2 20040727] [gcc (GCC) 3.4.1] [GNU C Library 2004-07-01 release version 2.3.4] [Linux 2.6.8.1 i686] 23:43:00 up 18 days, 7:32, 7 users, load average: 0.17, 0.08, 0.02 -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: Linux-PAM nitpicks
Jack Brown wrote: Here's how I look at it: You go to compile something, it decides that it want's libm and starts off looking at /usr/lib to see what it can find. It comes across a file /usr/lib/libm.so which is linked to a file called /lib/libm.so.6. based on this it tells the linker to link the resulting binary to a file named /lib/libm.so.6. When you run the program it sees that it need to load up the file /lib/libm.so.6 and in doing so ends up following the symlink and ends up actually loading /lib/libm.2.3.4.so in the process. One small correction, Actually it tells the linker to hardcode libm.so.6 without the full path (whoops). Then it looks for libm.so.6 starting in /usr/lib, then in /lib. (and then I guess it starts searching through /etc/ld.so.cache for libs that are in directories specified in /etc/ld.so.conf, assuming ldconfig has been run since they were installed) Jack Brown -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: Linux-PAM nitpicks
Randy McMurchy wrote: Jack Brown wrote these words on 02/23/05 23:39 CST: Steve Crosby wrote: hmm... [snip headache inducing material :-)] I hope that helps a bit. Geez. No offense, but that was pretty tough reading. How 'bout this instead: If you upgrade Glibc, start over from scratch. :-) Sorry, Glibc is probably the least "real world" example because you probably would start over, but what I said applies to any lib, not just Glibc. Jack Brown -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Linux-PAM man pages
Hi all, I'm noticing that Linux-PAM is installing some man (8) pages in the root of the filesystem. It's happened on several systems I've recently installed, and I see it happened on Anduin. If someone else can confirm this, I'll change the book to move the installed pages from /man/man8/ to where they belong in /usr/share/man/man8. What is so weird is that some of the man (8) pages installed by Linux-PAM are in the proper place, but somehow 3 pages are installed in the root of the filesystem. -- Randy rmlscsi: [GNU ld version 2.15.94.0.2 20041220] [gcc (GCC) 3.4.3] [GNU C Library stable release version 2.3.4] [Linux 2.6.10 i686] 19:14:00 up 15 days, 5:18, 6 users, load average: 0.10, 0.07, 0.05 -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Linux-PAM (new version)
Hi all, Worked with the newest Linux-PAM for a bit and have discovered that much has changed. I'm not sure about functionality yet, as I've not reinstalled Shadow and attempted to use PAM's services. My feeling is that functionality hasn't really changed though. What has changed is the build method. And more importantly, I cannot get the static libraries to build. In the past we've always passed --enable-static-libpam and it would build static versions of libpam, libpamc and libpam_misc. However, that parameter is no longer available and there is now --enable-static. But this doesn't work because if you use it on a current LFS SVN system, the build will fail. Other than that, things seem to be just fine. I'm going to reinstall Shadow right now, but wanted to get a head-start on feedback from you guys about only building the dynamic libraries. I'm not sure the static libs are even needed. Seems to me every package that links to the pam libraries, does it dynamically. If anyone has any issues about updating Linux-PAM and not including the static libs, please reply with why you think the static libraries are necessary. Thanks. -- Randy rmlscsi: [GNU ld version 2.15.94.0.2 20041220] [gcc (GCC) 3.4.3] [GNU C Library stable release version 2.3.4] [Linux 2.6.10 i686] 15:25:01 up 65 days, 49 min, 3 users, load average: 0.03, 0.39, 0.52 -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: Linux PAM/Shadow
Randy McMurchy wrote: > Hi all, > > I'll try and be as concise as possible and get right to the point. > The new version of Linux-PAM (see a previous post) has an issue > with Shadow. Brief description: > > PAM installs libraries in /lib (which it should), including .la files. > This is new to PAM (it uses libtool and auto* a bit heavier now). > These .la files are moved to /usr/lib (as always is done in LFS and > BLFS). Hardcoded in these .la files is "libdir='lib'". > > This apparently causes some problems when you then recompile Shadow. > Shadow claims the .la files have been moved and aborts the build with > an error (during the 'make'). > > Here are possible solutions. I'm looking for opinions as to what > would be best. > > 1. Delete the .la files and everything is fine. Best as I can tell, > .la files aren't really necessary. > > 2. Do a simple sed on the .la files and change the 'lib' to '/usr/lib' > and everything is fine. > > 3. Currently the default for PAM is installation of libraries in > /lib and the modules in /lib/security. We could pass 'libdir=/usr/lib' > *and* 'securedir=/lib/security' to configure, then move the > .so.0.81.1 and .so.0 files from /usr/lib to /lib and everything would > be fine. I think #2 or #3 are both reasonable as, from your description, they do the same thing. Is this something that should be addressed upstream? -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: Linux PAM/Shadow
On 11/28/05, Randy McMurchy <[EMAIL PROTECTED]> wrote: > 1. Delete the .la files and everything is fine. Best as I can tell, > .la files aren't really necessary. > > 2. Do a simple sed on the .la files and change the 'lib' to '/usr/lib' > and everything is fine. > > 3. Currently the default for PAM is installation of libraries in > /lib and the modules in /lib/security. We could pass 'libdir=/usr/lib' > *and* 'securedir=/lib/security' to configure, then move the > .so.0.81.1 and .so.0 files from /usr/lib to /lib and everything would > be fine. #3 is the correct soultion (how we normally do for all other packages). For #1 the book would have to explain why the libtool files are removed for a single package when these same useless files are left intact for other packages. #2 does not sound "technically correct":) -- Tushar Teredesai mailto:[EMAIL PROTECTED] http://www.linuxfromscratch.org/~tushar/ -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: Linux PAM/Shadow
Tushar Teredesai wrote these words on 11/28/05 17:46 CST: > #3 is the correct soultion (how we normally do for all other > packages). Agreed, and how I'm going to do my next round of testing. -- Randy rmlscsi: [GNU ld version 2.15.94.0.2 20041220] [gcc (GCC) 3.4.3] [GNU C Library stable release version 2.3.4] [Linux 2.6.10 i686] 17:50:01 up 65 days, 3:14, 3 users, load average: 0.08, 0.09, 0.17 -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: Linux PAM/Shadow
Bruce Dubbs wrote these words on 11/28/05 17:41 CST: > I think #2 or #3 are both reasonable as, from your description, they do > the same thing. Apparently I am mistaken. Though it worked in testing, removing the source tree and starting over gets me errors in Shadow's make complaining that "cannot find library 'lib/libpam.la'". This was using #2. I'll just reinstall PAM using those extra switches and manually move the libs that need to be in /lib. > Is this something that should be addressed upstream? I don't believe. I'll do some more testing and get back at you. -- Randy rmlscsi: [GNU ld version 2.15.94.0.2 20041220] [gcc (GCC) 3.4.3] [GNU C Library stable release version 2.3.4] [Linux 2.6.10 i686] 17:46:00 up 65 days, 3:10, 3 users, load average: 0.14, 0.06, 0.17 -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Linux-PAM "include system-auth"
Hi all, I thought I had the include syntax down for the Linux-PAM conf files, but I'm still a bit lost. More and more I'm seeing (this from an installed file from the PolicyKit package): auth include system-auth accountinclude system-auth password include system-auth sessioninclude system-auth I don't have a problem understanding what they're doing, but I'm not certain how to create, and what to put in the "system-auth" file. I can't find a good example anywhere. A bit more of my lack of knowledge appears here: http://wiki.linuxfromscratch.org/blfs/ticket/2805 Any help would be appreciated. -- Randy rmlscsi: [bogomips 1003.24] [GNU ld version 2.16.1] [gcc (GCC) 4.0.3] [GNU C Library stable release version 2.3.6] [Linux 2.6.14.3 i686] 12:36:00 up 19 days, 4:59, 1 user, load average: 0.46, 0.29, 0.11 -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: Linux-PAM man pages
On Thu, 2005-03-17 at 19:17 -0600, Randy McMurchy wrote: > I'm noticing that Linux-PAM is installing some man (8) pages in the > root of the filesystem. It's happened on several systems I've recently > installed, and I see it happened on Anduin. > > If someone else can confirm this, I'll change the book to move the > installed pages from /man/man8/ to where they belong in > /usr/share/man/man8. I can confirm this as well on several systems. I say put the instructions in to work around. It is strange that most of the man pages get placed in the correct place, but not those few. Gabe signature.asc Description: This is a digitally signed message part -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: Linux-PAM man pages
Randy McMurchy wrote: Hi all, I'm noticing that Linux-PAM is installing some man (8) pages in the root of the filesystem. It's happened on several systems I've recently installed, and I see it happened on Anduin. If someone else can confirm this, I'll change the book to move the installed pages from /man/man8/ to where they belong in /usr/share/man/man8. What is so weird is that some of the man (8) pages installed by Linux-PAM are in the proper place, but somehow 3 pages are installed in the root of the filesystem. Confirmed. Looks like we can do a sed to fix it though. I don't really have the time right now, but I took a quick peek anyway. The only place where this could be coming from is mandir=$PREFIX/man. Using 'mandir' instead of 'MANDIR'. Only place I can see this coming from is in modules/Simple.Rules. That looks to be the culpret. I'll look more when I get back tonight if you don't get it first. Thanks. -- DJ Lucas -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: Linux-PAM man pages
DJ Lucas wrote these words on 03/17/05 19:34 CST: > Confirmed. Looks like we can do a sed to fix it though. I don't really > have the time right now, but I took a quick peek anyway. The only place > where this could be coming from is mandir=$PREFIX/man. Using 'mandir' > instead of 'MANDIR'. Only place I can see this coming from is in > modules/Simple.Rules. That looks to be the culpret. I'll look more > when I get back tonight if you don't get it first. That would be great DJ. If we could get this into the book before 6.0, it would be a big bonus. It kinda sucks having man pages installed to /man in the root of the filesystem. I'm going to BZ this just in case neither of us get around to it before it's forgotten. -- Randy rmlscsi: [GNU ld version 2.15.94.0.2 20041220] [gcc (GCC) 3.4.3] [GNU C Library stable release version 2.3.4] [Linux 2.6.10 i686] 19:55:01 up 15 days, 5:59, 6 users, load average: 0.01, 0.01, 0.00 -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: Linux-PAM man pages
Randy McMurchy wrote: DJ Lucas wrote these words on 03/17/05 19:34 CST: I'll look more when I get back tonight if you don't get it first. That would be great DJ. If we could get this into the book before 6.0, it would be a big bonus. It kinda sucks having man pages installed to /man in the root of the filesystem. Change of plans so I'll fix it in a few moments. -- DJ Lucas -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: Linux-PAM man pages
DJ Lucas wrote: Confirmed. Looks like we can do a sed to fix it though. I don't really have the time right now, but I took a quick peek anyway. The only place where this could be coming from is mandir=$PREFIX/man. Using 'mandir' instead of 'MANDIR'. Only place I can see this coming from is in modules/Simple.Rules. That looks to be the culpret. I'll look more when I get back tonight if you don't get it first. Agreed. It looks like sed -i -e 's/mandir/MANDIR/g' modules/Simple.Rules will do it. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: Linux-PAM "include system-auth"
Message: 1 > Date: Thu, 26 Feb 2009 12:41:43 -0600 > From: Randy McMurchy > Subject: Linux-PAM "include system-auth" > To: BLFS Development List > Message-ID: <49a6e267.3030...@linuxfromscratch.org> > Content-Type: text/plain; charset=ISO-8859-1 > > Hi all, > > I thought I had the include syntax down for the Linux-PAM conf files, but > I'm still a bit lost. More and more I'm seeing (this from an installed > file from the PolicyKit package): > > auth include system-auth > accountinclude system-auth > password include system-auth > sessioninclude system-auth > > I don't have a problem understanding what they're doing, but I'm not > certain how to create, and what to put in the "system-auth" file. I can't > find a good example anywhere. > > A bit more of my lack of knowledge appears here: > http://wiki.linuxfromscratch.org/blfs/ticket/2805 > > Any help would be appreciated. > > My only guess is this refers to /etc/pam.d/other which is pams default file if a service isn't listed in its usual /etc/pam.d/servicename file, so perhaps its an attempt to create default setup for LFS in case a user installs pam but doesn't bother with any additional configuration? I'm assuming that no patch has been applied to pam to make it look for a file called 'defaults' rather than 'other'. Btw, I only pick up the digest for blfs, so if I seem to go silent, I'm not ignoring anybody. Regards Phill -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: Linux-PAM "include system-auth"
On Thu, Feb 26, 2009 at 10:41 AM, Randy McMurchy wrote: > Hi all, > > I thought I had the include syntax down for the Linux-PAM conf files, but > I'm still a bit lost. More and more I'm seeing (this from an installed > file from the PolicyKit package): > > auth include system-auth > account include system-auth > password include system-auth > session include system-auth > > I don't have a problem understanding what they're doing, but I'm not > certain how to create, and what to put in the "system-auth" file. I can't > find a good example anywhere. > > A bit more of my lack of knowledge appears here: > http://wiki.linuxfromscratch.org/blfs/ticket/2805 I think (and I'm almost 100% sure) that DJ was referring to the same concept, but calling it default instead of system-auth. Here's what fedora's looks like: authrequired pam_env.so authsufficientpam_unix.so nullok try_first_pass authrequisite pam_succeed_if.so uid >= 500 quiet authrequired pam_deny.so account required pam_unix.so account sufficientpam_localuser.so account sufficientpam_succeed_if.so uid < 500 quiet account required pam_permit.so passwordrequisite pam_cracklib.so try_first_pass retry=3 passwordsufficientpam_unix.so sha512 shadow nullok try_first_pass use_authtok passwordrequired pam_deny.so session optional pam_keyinit.so revoke session required pam_limits.so session [success=1 default=ignore] pam_succeed_if.so service in crond quiet use_uid session required pam_unix.so and here's paldo's much simpler version for reference: http://paldo.org/paldo/sources/Linux-PAM/pam-system-auth-20060303 The way it works is that when your service does: auth include system-auth session include system-auth it pulls the auth section from system-auth for the auth phase. Then it pulls the session section from system-auth for the session phase. The system-auth name is (I believe) a holdover from the early days of the pam include implementation where an included file could only contain a certain authorization phase (probably bungling terms at this point). So, DJ's pam.d/default is probably more correct, but pam.d/system-auth allows you to fit in with the world more easily. The idea is that there are common modules you always want to run, such as pam_unix.so. It also allows you to establish your cracklib password defaults in one location, if you'd like. You can always augment your service with other things. session include system-auth session optional pam_console.so -- Dan -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: Linux-PAM "include system-auth"
Dan Nicholson wrote these words on 02/27/09 09:08 CST: > [again snip all of Dan's fine words] Thanks for the help, Dan. This clears it up a bunch for me. -- Randy rmlscsi: [bogomips 1003.24] [GNU ld version 2.16.1] [gcc (GCC) 4.0.3] [GNU C Library stable release version 2.3.6] [Linux 2.6.14.3 i686] 09:38:01 up 20 days, 2:01, 1 user, load average: 0.36, 0.08, 0.03 -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: Linux-PAM and Bekkeley DB
On 30/10/11 09:43, Jeremy Huntwork wrote: > On Oct 29, 2011, at 5:52 PM, Wayne Blaszczyk wrote: > >> The Linux-PAM build fails for me, most likely due to the Bekkeley DB >> upgrade to 5.2.26. >> I get the following error: >> >> .libs/pam_userdb.o: In function `user_lookup': >> /sources/Linux-PAM-1.1.3/modules/pam_userdb/pam_userdb.c:159: undefined >> reference to `__db_ndbm_open' > > > Try building db with --enable-dbm. > > JH > Thanks, that worked. As mentioned by DJ in the previous post, I think this should be included in the standard build. Regards, Wayne. -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: Linux-PAM and Bekkeley DB
Wayne Blaszczyk wrote: > On 30/10/11 09:43, Jeremy Huntwork wrote: >> On Oct 29, 2011, at 5:52 PM, Wayne Blaszczyk wrote: >> >>> The Linux-PAM build fails for me, most likely due to the Bekkeley DB >>> upgrade to 5.2.26. >>> I get the following error: >>> >>> .libs/pam_userdb.o: In function `user_lookup': >>> /sources/Linux-PAM-1.1.3/modules/pam_userdb/pam_userdb.c:159: undefined >>> reference to `__db_ndbm_open' >> >> Try building db with --enable-dbm. > Thanks, that worked. As mentioned by DJ in the previous post, I think > this should be included in the standard build. I don't generally use PAM, so I don't mind any changes to it. I'm curious though. What do others get from PAM? I don't see any advantages over plain shadow for a direct terminal or ssh login unless you have a lot of different users trying to login and you are trying to control that via ldap. For me where there are only a very few users, e.g. 3 on a server, PAM just gets in the way. I feel the same way about tcpwrappers and xinetd. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: Linux-PAM and Bekkeley DB
On Sun, 30 Oct 2011 12:02:53 -0500 Bruce Dubbs wrote: > Wayne Blaszczyk wrote: > > On 30/10/11 09:43, Jeremy Huntwork wrote: > >> Try building db with --enable-dbm. > > > Thanks, that worked. As mentioned by DJ in the previous post, I think > > this should be included in the standard build. > > I don't generally use PAM, so I don't mind any changes to it. I think Wayne was actually suggesting a change to the way berkeley-db is installed > I'm curious though. What do others get from PAM? Personally I install PAM so I can use pam_faildelay.so with ssh to set an arbitrary amount of time between login attempts. Brute force attacks are not practical if the script has to wait 2 minutes for each password it tries. Andy -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: Linux-PAM and Bekkeley DB
> I don't generally use PAM, so I don't mind any changes to it. I'm > curious though. What do others get from PAM? I don't see any > advantages over plain shadow for a direct terminal or ssh login unless > you have a lot of different users trying to login and you are trying to > control that via ldap. > > For me where there are only a very few users, e.g. 3 on a server, PAM > just gets in the way. > > I feel the same way about tcpwrappers and xinetd. > >-- Bruce I only install it due to some required dependency, gnome-screensaver I think. If it wasn't for that, I wouldn't install it myself either. Wayne. -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: Linux-PAM and Bekkeley DB
On 10/30/2011 12:02 PM, Bruce Dubbs wrote: > Wayne Blaszczyk wrote: >> On 30/10/11 09:43, Jeremy Huntwork wrote: >>> On Oct 29, 2011, at 5:52 PM, Wayne Blaszczyk wrote: >>> >>>> The Linux-PAM build fails for me, most likely due to the Bekkeley DB >>>> upgrade to 5.2.26. >>>> I get the following error: >>>> >>>> .libs/pam_userdb.o: In function `user_lookup': >>>> /sources/Linux-PAM-1.1.3/modules/pam_userdb/pam_userdb.c:159: undefined >>>> reference to `__db_ndbm_open' >>> Try building db with --enable-dbm. >> Thanks, that worked. As mentioned by DJ in the previous post, I think >> this should be included in the standard build. > I don't generally use PAM, so I don't mind any changes to it. I'm > curious though. What do others get from PAM? I don't see any > advantages over plain shadow for a direct terminal or ssh login unless > you have a lot of different users trying to login and you are trying to > control that via ldap. > > For me where there are only a very few users, e.g. 3 on a server, PAM > just gets in the way. > > I feel the same way about tcpwrappers and xinetd. > > -- Bruce Were you wanting to remove it from the book? -- DJ Lucas -- This message has been scanned for viruses and dangerous content, and is believed to be clean. -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: Linux-PAM and Bekkeley DB
DJ Lucas wrote: > On 10/30/2011 12:02 PM, Bruce Dubbs wrote: >> Wayne Blaszczyk wrote: >>> On 30/10/11 09:43, Jeremy Huntwork wrote: >>>> On Oct 29, 2011, at 5:52 PM, Wayne Blaszczyk wrote: >>>> >>>>> The Linux-PAM build fails for me, most likely due to the Bekkeley DB >>>>> upgrade to 5.2.26. >>>>> I get the following error: >>>>> >>>>> .libs/pam_userdb.o: In function `user_lookup': >>>>> /sources/Linux-PAM-1.1.3/modules/pam_userdb/pam_userdb.c:159: undefined >>>>> reference to `__db_ndbm_open' >>>> Try building db with --enable-dbm. >>> Thanks, that worked. As mentioned by DJ in the previous post, I think >>> this should be included in the standard build. >> I don't generally use PAM, so I don't mind any changes to it. I'm >> curious though. What do others get from PAM? I don't see any >> advantages over plain shadow for a direct terminal or ssh login unless >> you have a lot of different users trying to login and you are trying to >> control that via ldap. >> >> For me where there are only a very few users, e.g. 3 on a server, PAM >> just gets in the way. >> >> I feel the same way about tcpwrappers and xinetd. > Were you wanting to remove it from the book? No. I can see where all those could be useful to some users. I was just stating an opinion about when those packages are useful. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: Linux-PAM man pages (OT)
DJ Lucas wrote these words on 03/17/05 20:10 CST: > Change of plans so I'll fix it in a few moments. So, dude, how's that new baby? (sigh). My babies are now 18 and 11 years old. -- Randy rmlscsi: [GNU ld version 2.15.94.0.2 20041220] [gcc (GCC) 3.4.3] [GNU C Library stable release version 2.3.4] [Linux 2.6.10 i686] 20:19:01 up 15 days, 6:23, 6 users, load average: 0.06, 0.03, 0.01 -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
[blfs-dev] Fix Linux-PAM libraries location
Versioned libraries in /lib, non-versioned libraries in /usr/lib.
Patch in the attachment.
--
Note: My last name is not Krejzi.
Index: postlfs/security/linux-pam.xml
===
--- postlfs/security/linux-pam.xml (revision 12387)
+++ postlfs/security/linux-pam.xml (working copy)
@@ -138,6 +138,8 @@
./configure --prefix=/usr \
--sysconfdir=/etc \
+--libdir=/usr/lib \
+--enable-securedir=/lib/security \
--docdir=/usr/share/doc/Linux-PAM-&linux-pam-version; \
--disable-nis &&
make
@@ -177,7 +179,14 @@
make install &&
-chmod -v 4755 /sbin/unix_chkpwd
+chmod -v 4755 /sbin/unix_chkpwd &&
+
+for file in pam pam_misc pamc
+do
+ mv -v /usr/lib/lib${file}.so.* /lib &&
+ ln -sfv ../../lib/$(readlink /usr/lib/lib${file}.so) /usr/lib/lib${file}.so
+done
+
@@ -184,6 +193,12 @@
Command Explanations
+ --enable-securedir=/lib/security:
+ This switch sets install location for the
+ PAM modules.
+
+
+
--disable-nis: This switch disables building
of the Network Information Service/Yellow Pages support in
pam_unix and pam_access modules. Remove it if you have installed
--
http://linuxfromscratch.org/mailman/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
[blfs-dev] BLFS - Version 2012-09-25: Linux pam
If you are using DESTDIR linux-pam 1.1.6 needs this patch from gentoo >From d7e6b921cd34f7ad8fc4d05065c75d13ba330896 Mon Sep 17 00:00:00 2001 From: Tomas Mraz Date: Fri, 17 Aug 2012 14:46:40 +0200 Subject: [PATCH] Add missing $(DESTDIR) when making directories on install. MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit modules/pam_namespace/Makefile.am: Add missing $(DESTDIR) when making $(namespaceddir) on install. modules/pam_sepermit/Makefile.am: Add missing $(DESTDIR) when making $(sepermitlockdir) on install. Signed-off-by: Diego Elio Pettenò --- modules/pam_namespace/Makefile.am |2 +- modules/pam_sepermit/Makefile.am |2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git modules/pam_namespace/Makefile.am b/modules/pam_namespace/Makefile.am index a28f196..ebb00f3 100644 --- modules/pam_namespace/Makefile.am +++ modules/pam_namespace/Makefile.am @@ -40,7 +40,7 @@ if HAVE_UNSHARE secureconf_SCRIPTS = namespace.init install-data-local: - mkdir -p $(namespaceddir) + mkdir -p $(DESTDIR)$(namespaceddir) endif diff --git modules/pam_sepermit/Makefile.am b/modules/pam_sepermit/Makefile.am index cfc5594..bc82275 100644 --- modules/pam_sepermit/Makefile.am +++ modules/pam_sepermit/Makefile.am @@ -35,7 +35,7 @@ if HAVE_LIBSELINUX securelib_LTLIBRARIES = pam_sepermit.la install-data-local: - mkdir -p $(sepermitlockdir) + mkdir -p $(DESTDIR)$(sepermitlockdir) endif if ENABLE_REGENERATE_MAN noinst_DATA = README pam_sepermit.8 sepermit.conf.5 -- 1.7.8.6 -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
