Don Lewis truck...@freebsd.org writes:
building shared library libpam.so.5
make: don't know how to make openpam.3. Stop
*** Error code 2
Ah, yes, the man pages are generated during the release process, so you
either have to copy them over from the original contrib/openpam
directory (or export
On 11 Jan, Dag-Erling Smørgrav wrote:
Could you please try this:
# cd /usr/src/contrib
# mv openpam openpam.orig
# svn export svn://svn.des.no/openpam/trunk@526 openpam
# cd ../lib/libpam
# make depend make all make install
[snip]
building shared library libpam.so.5
make: don't know how
If at any point in this conversation I seemed to make _no sense at all_,
it was because I conflated it with a completely different OpenPAM issue
(error reporting in openpam_dynamic.c) which has been on my mind lately.
Sorry about that. I will attempt to address both issues in the next
release,
On 10 Jan, Dag-Erling Smørgrav wrote:
If at any point in this conversation I seemed to make _no sense at all_,
it was because I conflated it with a completely different OpenPAM issue
(error reporting in openpam_dynamic.c) which has been on my mind lately.
Sorry about that. I will attempt to
Could you please try this:
# cd /usr/src/contrib
# mv openpam openpam.orig
# svn export svn://svn.des.no/openpam/trunk@526 openpam
# cd ../lib/libpam
# make depend make all make install
In addition to the pam.conf issue, the major changes relative to head
are reduced log spam, improved log
Don Lewis truck...@freebsd.org writes:
The documentation says that /etc/pam.conf is only used if
/etc/pam.d/service-name isn't found, and the code appears to agree
with that, however this doesn't seem to be working as expected after
the latest import of PAM.
The culprit was this commit:
On 9 Jan, Dag-Erling Smørgrav wrote:
Don Lewis truck...@freebsd.org writes:
The documentation says that /etc/pam.conf is only used if
/etc/pam.d/service-name isn't found, and the code appears to agree
with that, however this doesn't seem to be working as expected after
the latest import of
Don Lewis truck...@freebsd.org writes:
Dag-Erling Smørgrav d...@des.no writes:
The culprit was this commit:
http://trac.des.no/openpam/changeset/487/trunk/lib/openpam_configure.c
However, I'm not confident that simply reverting this commit is the
right way to go.
Thanks for the
On 9 Jan, Dag-Erling Smørgrav wrote:
Don Lewis truck...@freebsd.org writes:
Dag-Erling Smørgrav d...@des.no writes:
The culprit was this commit:
http://trac.des.no/openpam/changeset/487/trunk/lib/openpam_configure.c
However, I'm not confident that simply reverting this commit is the
Don Lewis truck...@freebsd.org writes:
After staring at the code a lot more, I see your point about the loss of
information. The problem is that openpam_parse_chain() returns
PAM_SUCCESS whether or not if found anything, but we want the loop to
terminate when either an error is detected or if
On 9 Jan, Dag-Erling Smørgrav wrote:
Don Lewis truck...@freebsd.org writes:
After staring at the code a lot more, I see your point about the loss of
information. The problem is that openpam_parse_chain() returns
PAM_SUCCESS whether or not if found anything, but we want the loop to
terminate
I just upgraded my -CURRENT machine for the first time since
mid-November. When I rebooted, I was surprised that I was unable to log
in via either ssh or directly on the console. The diagnostics printed
to the console indicated that pam_skey.so was missing. Since that was
nuked a long time ago,
12 matches
Mail list logo
