Summary: | Emerge on pam_krb5-1.0 fails | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Rens <lawkie> |
Component: | New packages | Assignee: | PAM Gentoo Team (OBSOLETE) <pam-bugs+disabled> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | jgonzalez.openinput, quickhelp, wisnia21 |
Priority: | High | ||
Version: | unspecified | ||
Hardware: | x86 | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: |
Patch to include errno.h in pam_krb5_auth.c
Patch to include errno.h in support.c Patch to fix up the ebuild Correct ebuild patch Updated ebuild that includes epatch line for patch to correct compile failure Patch that adds missing headers to support.c and pam_krb5_auth.c |
Description
Rens
2003-12-04 07:42:24 UTC
One hack is to temporarily place "#include <errno.h>" in /usr/include/stdio.h. Don't leave it there, though. Created attachment 23104 [details, diff]
Patch to include errno.h in pam_krb5_auth.c
This fixes the indicated problem: failure to include errno.h in
pam_krb5_auth.c. Two more patches are forthcoming; one for support.c which is
also missing errno.h, and one for the ebuild to put the patches in place.
Created attachment 23105 [details, diff]
Patch to include errno.h in support.c
As promised, patch to include errno.h in support.c
Created attachment 23106 [details, diff]
Patch to fix up the ebuild
As promised, patch to fix the 1.0 ebuild
Created attachment 23112 [details, diff]
Correct ebuild patch
Old ebuild patch was incorrect from an earlier version of my fix; this is
correct
perchance we should just move to pam_krb5 1.3? I compiled it and it works where the 1.0 did not (even after the patch was applied). perchance we should just move to pam_krb5 1.3? I compiled it and it works where the 1.0 did not (even after the patch was applied). It seems to compile for me (with the patches) The posted patches and ebuild worked fine for me too. What's the hold up guys? This is a major problem for anyone building a site that uses PAM. It shouldn't take 2 months to get a completed ebuild into the distribution -- this should get added ASAP. *** Bug 28810 has been marked as a duplicate of this bug. *** Hi. I am new to gentoo and have (nearly) the same problem - just for me it is line 23 instead of 20 ?!: pam_krb5_auth.c:418: error: `errno' undeclared (first use in this function) pam_krb5_auth.c:418: error: (Each undeclared identifier is reported only once pam_krb5_auth.c:418: error: for each function it appears in.) make: *** [pam_krb5_auth.o] Error 1 !!! ERROR: app-crypt/pam_krb5-1.0 failed. !!! Function src_compile, Line 23, Exitcode 2 !!! (no error message) --------- So why are these patches available not added to the gentoo emerge package?! Or the other way round: When will they be added? And until then everyone has to apply the patches here handish by themselves?! Greetings, tormen. more than 5 months and nothing has been done.... Created attachment 32991 [details]
Updated ebuild that includes epatch line for patch to correct compile failure
Features an epatch line to apply a fix to files support.c and pam_krb5_auth
that prevents pam_krb5 from compiling.
Brandon
Created attachment 32992 [details, diff]
Patch that adds missing headers to support.c and pam_krb5_auth.c
This is the patch used by the pam_krb5-1.0-r1.ebuild.
What is the hold up here? I did an emerge on pam_krb5 on ppc, and it STILL has the SAME BUG. Common Gentoo devs - a patch has been posted, tested and found to be working...why is this taking so long to integerate -- 7 months now??? This is ridiculous - either integrate the patch or let us know how we can contribute it to the main tree. Your users are doing everything they can to help Gentoo's development, but when stuff like this just sits around it's very frustrating. Done. sorry about the delay, but very few of us do anything with kerberos, and so properly testing it so we can put it in is very hard. I believe we have only one or two devs that do anything with kerberos, and more devs there wouldn't hurt i think. Could you please take a look at http://bugs.gentoo.org/show_bug.cgi?id=51837 ? It's also related to Kerberos and it's been almost two months since it was opened. By the way, I'm just curious about this... from what I've been reading it seems that the so called LDAPv3 (Kerberos for authentication+LDAP for authorization information+SASL authentication to LDAP+DIGEST MD5 mandatory mechanism) is the sensible way to go when setting up a central authentication and authorization server, with centralized user management, for installations with more than a few users and/or machines. That's why I tried pam_krb5. But from what you tell us, it seems that Kerberos doesn't have that much attention from the developers. I'm trying to do Gentoo for a living and from my point of view things like Kerberos are very important if you want to sell Gentoo to a medium/big sized company. So I think details like this are the difference that could make Gentoo become a possible corporate solution, or make it a toy with relative spreading due to its improved performance and ease of management thanks to portage. Please take this as constructive criticism from somebody who would like to make Gentoo even better than it is. By the way, I'm working in a howto about this issue (right now in spanish). If there is enough interest I would be happy to donate it to the Gentoo documentation, if that helps to have more users/devs involved in this. Best regards jose: it's possible to mix and match ldap configurations to suit your environment. as an example, at work (I do gentoo for money too) my setup is pure LDAPv3, all running over SSL/TLS. pam_ldap and nss_ldap provide all the data needed, incl. nfs automounts (for home directories). My ldap also supplies data to Samba as a PDC + fileserver for windows. This environment runs MacOSX, SGI Irix, Windows XP/2K, FreeBSD, and multiple distributions of Linux (no fewer than 6 distinct flavours at last count). Robin, I first went that way, using pam_ldap/nss_ldap, but then I found about Kerberos. In theory Kerberos/LDAP (pam_krb5/nss_ldap) can provide single sign-on, and that's why I gave a try to it. I must say I'm quite new to linux/unix admin so I'm exploring all these posibilities so I can offer an informed decission to any possible client. By the way... maybe we are going a bit off topic? Maybe we could take this to private or gentoo-user/gentoo-dev? |