shadow-4.0.9 errors persist

Randy McMurchy LFS-User at
Sat Aug 6 11:41:32 PDT 2005

[cc'd to BLFS-Dev]

Harris Christian D SSgt 1 CS/SCBAM wrote these words on 08/06/05 13:28 CST:

> Is there a specific reason why the editing of the logins.def file
> was placed at the bottom of the page instead of before the
> warning? Had it been before the warning, I would not have wasted
> 2 days on the issue. If there is not reason I will suggest it
> to the (B)LFS staff.

I have been following this thread with interest and have taken note
about the issue you raised. I am glad you resolved your problem *and*
I'm glad it happened (though I'm sorry you lost a couple of days).

I'm glad it happened because we can now see what we have to do to
*fix* this issue. The new PAM/Shadow stuff was just introduced into
the book a week or so ago, so it has not had much testing by the
community. And, because you have gone through what you did, it is
not too late to fix the upcoming 6.1 book to address this issue.

Now, to answer your question. The stuff about login.def is at the
bottom of the page as this should only be accomplished after the
Shadow package has been successfully installed. These changes would
cripple some of Shadow's functionality if you have to go back and
install Shadow without PAM.

The login.def file is installed in LFS, not BLFS, so the BLFS
instructions wouldn't recreate this file (though it would be simple
to do so, and maybe we should).

So, there's a couple of things we can do.

1) Move the login.def changes up in the instructions *and* install
the default login.def file during the installation section of Shadow,

2) Add some text to the warning message that some of the configuration
errors are expected.

I prefer #1.

> Also, as I am still a little paranoid, is there a way to ensure that
> the PAM/shadow integration was 100% successful other then 
> being able to log in with no errors? I would like to be sure that by 
> commenting out the variables, I did not open some security hole, 
> or cripple my system in a way that not apparent right away. 

Good points. Something we can consider adding to the development
version of BLFS, however, testing the installation of packages isn't
something we really do, unless there is a test suite provided by
the package.

Bottom line is this, I suppose: We kind of figure if a person is
installing a package, he should be able to test out its functionality
without step-by-step instructions. He should have a reason *why* he
is installing it, and the knowledge to ensure that it works as


rmlscsi: [GNU ld version 20041220] [gcc (GCC) 3.4.3]
[GNU C Library stable release version 2.3.4] [Linux 2.6.10 i686]
13:27:01 up 126 days, 13:00, 2 users, load average: 0.15, 0.25, 0.43

More information about the blfs-support mailing list