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.ht
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 conf
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
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.
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 cu
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
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. P
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 Ima
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*
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
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
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 f
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
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 memo
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
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]
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
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
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 o
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
l
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. Th
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
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 whe
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
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 refere
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
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 s
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
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.
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?
N
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. Additionall
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,
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.
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
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?
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
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 thi
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 S
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 Readli
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,
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 dis
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
act
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)
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
rmlinu
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
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,
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 page
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
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 .
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
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 releas
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 "cann
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 s
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
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
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'.
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 o
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
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
>
>
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
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 i
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
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 erro
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'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 tha
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
>>&
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, m
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 versi
)
+++ 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; \
--dis
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:
70 matches
Mail list logo
