perlgssapi-users Mailing List for Perl GSSAPI bindings (Page 4)
Brought to you by:
achimgrolms
Menu
▾
▴
perlgssapi-users — How to use the Bindings, help, feature requests
You can subscribe to this list here.
| 2006 |
Jan
|
Feb
(12) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(4) |
Sep
(26) |
Oct
(13) |
Nov
|
Dec
|
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2007 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(9) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2011 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(3) |
Jun
|
Jul
|
Aug
(2) |
Sep
|
Oct
|
Nov
|
Dec
|
| 2012 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(9) |
Dec
(4) |
| 2013 |
Jan
(1) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2016 |
Jan
|
Feb
|
Mar
(2) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(5) |
Nov
|
Dec
|
|
From: Achim G. <ac...@gr...> - 2006-08-30 16:06:46
|
On Wednesday 30 August 2006 17:31, Massimiliano Masi wrote: > MINOR::Server not found in Kerberos database I think -prodid ipmi/higgs.massicern.ch is wrong, use -prodid ipmi instead. Achim |
|
From: Massimiliano M. <mas...@ce...> - 2006-08-30 15:31:58
|
Hello,
I'm trying to develop something with perl GSSAPI.
I've two test machine, pcitadc05.cern.ch (where I'm testing the clients)
and higgs.massicern.ch, the kdc.
In the kdc, with heimdal, I've created the server
ipmi/hig...@MA...
With the getcred example, everythings seems to works:
higgs:~/.cpan/build/GSSAPI-0.23/examples# klist
klist: No ticket file: /tmp/krb5cc_0
V4-ticket file: /tmp/tkt0
klist: No ticket file (tf_util)
higgs:~/.cpan/build/GSSAPI-0.23/examples# ./getcred_hostbased.pl ipmi
using Name ipmi/hig...@MA...
Errors: Miscellaneous failure (see text)
open(/tmp/krb5cc_0): No such file or directory
higgs:~/.cpan/build/GSSAPI-0.23/examples# kinit max
ma...@MA...'s Password:
higgs:~/.cpan/build/GSSAPI-0.23/examples# ./getcred_hostbased.pl ipmi
using Name ipmi/hig...@MA...
Security context's time to live 35998 secs
seems everything is fine, type klist to see the ticket
higgs:~/.cpan/build/GSSAPI-0.23/examples# klist
Credentials cache: FILE:/tmp/krb5cc_0
Principal: ma...@MA...
Issued Expires Principal
Aug 30 16:14:26 Aug 31 02:14:26 krbtgt/MAS...@MA...
Aug 30 16:14:28 Aug 31 02:14:26 ipmi/hig...@MA...
V4-ticket file: /tmp/tkt0
klist: No ticket file (tf_util)
Then, I run the server:
higgs:~/.cpan/build/GSSAPI-0.23/examples# ./gss-server.pl ip...@hi... -port 10000 -hostname higgs.massicern.ch -keytabfile=/etc/krb5.keytab
./gss-server.pl: using [higgs.massicern.ch:10000]
SERVER set environment variable KRB5_KTNAME to FILE:/etc/krb5.keytab
Listening on port 10000 ...
SERVER::waiting for request ...
and then the client:
mascanc@pcitadc05 ~/Desktop/GSSAPI-0.23/examples $ ./gss-client.pl -hostname higgs.massicern.ch -prodid ipmi/higgs.massicern.ch
./gss-client.pl: -port not specified, defaulting to 10000
./gss-client.pl: using [ipmi/hig...@hi...:10000]
CLIENT::principal [ipmi/hig...@hi...] means going to communicate with server name [ipmi/hig...@hi...]
Use of uninitialized value in subroutine entry at ./gss-client.pl line 88.
CLIENT::Unable to initialize security context:
MAJOR::Unspecified GSS failure. Minor code may provide more information
MINOR::Server not found in Kerberos database
And the server says:
SERVER::waiting for request ...
SERVER::accepted connection from client ...
Use of uninitialized value in subroutine entry at ./gss-server.pl line 78.
SERVER::received token (length is 0):
SERVER::waiting for request ...
Have you any idea???
Thank you for your work!!!
Bye
--
Massimiliano Masi
http://www.comunidelchianti.it/~max
|
|
From: Achim G. <ac...@gr...> - 2006-02-24 02:51:37
|
On Friday 24 February 2006 03:28, you wrote: > Achim Grolms wrote: > I think it is fair to say that perlgssapi was once a module primarily > meant for use with mit krb's gssapi C headers (popular) ... but now it > has heimdal header compatibility.. I've made it compile with Heimdal in 0.14 2 weeks ago. At the moment I am waiting for feedback if the Heimdal support works correct. > I would be happy to see it evolve into a module that (on the perl side) > claims to establish a good perl language binding to the higher-level > gssapi, and (on the C side) is implemented by bridging only to the RFC's > C binding correct. > and providing implementations of missing C impl to provide the > perl functionality. eg oid_to_str is not hard to write and could be > provided in the module so that it is available regardless of heimdal or > mit underlying implementation... correct. My idead was to Write the oid_to_str equivalint in Perl itself using the Convert::ASN1 module and add a function to the XS that allows to map already ASN1 encoded otctet sets (or an array of bytes) into OIDs. That means tha maximum of flexibility. > anyway, that's just my 2c... i'll send patches next time ;) Feel free to send suggestions :-) Thank you, Achim |
|
From: David L. <Dav...@qu...> - 2006-02-24 02:29:05
|
Achim Grolms wrote:
>On Thursday 23 February 2006 05:11, you wrote:
>
>>Achim Grolms wrote:
>>
>>>The other point - how can I make the Makefile.PL
>>>to set the DHEIMDAL flag
>>>based on the output of your krb5-config command?
>>>
>>That is a good question.. I think we will try to make our krb5-config
>>emit '(Heimdal)' as part of the version string.
>>
>
>Something like "... derived from Heimdal" will work?
>
Yep. I think the change has already gone in, so in the future we will
see behaviour something like this:
$ krb5-config --version
VAS 3.0.1 (Heimdal 0.7)
>
>>Or, perhaps you could provide a switch to Makefile.PL that would
>>override the heimdal detection.
>>
>>However, it seems to me that the package currently assumes the
>>extensions are there, falling back to vanilla gssapi *only* if the word
>>Heimdal is detected.. Perhaps the logic should be reversed; i.e. build
>>conservatively, unless the extensions are detected? By extensions I mean
>>the deprecated/non-standard GSSAPI functions like oid_to_str.
>>
>
>At the moment most of the users I get mail from are using MIT Kerberos.
>The Heimdal support is new in GSSAPI.pm
>I don't want to repair things that are not broken, but you are right,
>if in future the standard behaviour becomes the default I have
>to change that and make a reverse detection.
>
>Does that work for you?
>
yes it would..
I think it is fair to say that perlgssapi was once a module primarily
meant for use with mit krb's gssapi C headers (popular) ... but now it
has heimdal header compatibility..
I would be happy to see it evolve into a module that (on the perl side)
claims to establish a good perl language binding to the higher-level
gssapi, and (on the C side) is implemented by bridging only to the RFC's
C binding and providing implementations of missing C impl to provide the
perl functionality. eg oid_to_str is not hard to write and could be
provided in the module so that it is available regardless of heimdal or
mit underlying implementation...
anyway, that's just my 2c... i'll send patches next time ;)
d
--
David Leonard
Vintela Resource Central software engineer
Quest Software; 303 Adelaide St, Brisbane, Australia; www.quest.com
Phone: (US) +1 801 655 2755
(AU) +61 7 3023 5133
|
|
From: Achim G. <ac...@gr...> - 2006-02-23 12:48:41
|
On Thursday 23 February 2006 05:11, you wrote: > Achim Grolms wrote: > >The other point - how can I make the Makefile.PL > >to set the DHEIMDAL flag > >based on the output of your krb5-config command? > > That is a good question.. I think we will try to make our krb5-config > emit '(Heimdal)' as part of the version string. Something like "... derived from Heimdal" will work? > Or, perhaps you could provide a switch to Makefile.PL that would > override the heimdal detection. > > However, it seems to me that the package currently assumes the > extensions are there, falling back to vanilla gssapi *only* if the word > Heimdal is detected.. Perhaps the logic should be reversed; i.e. build > conservatively, unless the extensions are detected? By extensions I mean > the deprecated/non-standard GSSAPI functions like oid_to_str. At the moment most of the users I get mail from are using MIT Kerberos. The Heimdal support is new in GSSAPI.pm I don't want to repair things that are not broken, but you are right, if in future the standard behaviour becomes the default I have to change that and make a reverse detection. Does that work for you? Thank you, Achim |
|
From: David L. <Dav...@qu...> - 2006-02-23 04:11:28
|
Achim Grolms wrote: >The other point - how can I make the Makefile.PL >to set the DHEIMDAL flag >based on the output of your krb5-config command? > That is a good question.. I think we will try to make our krb5-config emit '(Heimdal)' as part of the version string. Or, perhaps you could provide a switch to Makefile.PL that would override the heimdal detection. However, it seems to me that the package currently assumes the extensions are there, falling back to vanilla gssapi *only* if the word Heimdal is detected.. Perhaps the logic should be reversed; i.e. build conservatively, unless the extensions are detected? By extensions I mean the deprecated/non-standard GSSAPI functions like oid_to_str. -- David Leonard Vintela Resource Central software engineer Quest Software; 303 Adelaide St, Brisbane, Australia; www.quest.com Phone: (US) +1 801 655 2755 (AU) +61 7 3023 5133 |
|
From: Achim G. <ac...@gr...> - 2006-02-22 20:24:53
|
On Wednesday 22 February 2006 02:04, David Leonard wrote: > Achim Grolms wrote: > GSS_KRB5_NT_MACHINE_UID_NAME from xs/OID.xs's gss_nt_machine_uid_name() > > looking at it now, I guess it's a bug in xs/OID.xs and should be > GSS_C_NT_MACHINE_UID_NAME ;) I've fixed this in GSSAPI 0.19 at CPAN. Achim |
|
From: Achim G. <ac...@gr...> - 2006-02-22 12:39:15
|
On Wednesday 22 February 2006 02:04, David Leonard wrote: > Achim Grolms wrote: > looking at it now, I guess it's a bug in xs/OID.xs and should be > GSS_C_NT_MACHINE_UID_NAME ;) Ups, I think you are right. I will check that and fix the bug. The other point - how can I make the Makefile.PL to set the DHEIMDAL flag based on the output of your krb5-config command? Achim |
|
From: David L. <Dav...@qu...> - 2006-02-22 01:05:13
|
Achim Grolms wrote: >On Tuesday 21 February 2006 06:09, David Leonard wrote: > > >> +#include <gssapi_krb5.h> >> > >BTW another question: >What symbols do you need from gssapi_krb5.h? > >GSSAPI.xs defines all Kerberos5 related symbols inline. > >What symbols are missing in not including gssapi_krb5.h? > GSS_KRB5_NT_MACHINE_UID_NAME from xs/OID.xs's gss_nt_machine_uid_name() looking at it now, I guess it's a bug in xs/OID.xs and should be GSS_C_NT_MACHINE_UID_NAME ;) -- David Leonard Vintela Resource Central software engineer Quest Software; 303 Adelaide St, Brisbane, Australia; www.quest.com Phone: (US) +1 801 655 2755 (AU) +61 7 3023 5133 |
|
From: Achim G. <ac...@gr...> - 2006-02-21 16:23:48
|
On Tuesday 21 February 2006 06:09, David Leonard wrote: > +#include <gssapi_krb5.h> BTW another question: What symbols do you need from gssapi_krb5.h? GSSAPI.xs defines all Kerberos5 related symbols inline. What symbols are missing in not including gssapi_krb5.h? Achim |
|
From: Achim G. <ac...@gr...> - 2006-02-21 15:06:18
|
On Tuesday 21 February 2006 06:09, David Leonard wrote:
> ("3.0.1"). Should it say "Heimdal" somewhere in there?
Hmm, the easiest way would be to print a unique name.
On the Name Makefile.PL can decide what to to and what
DEFINES to be set.
> Indeed, is there
> a standard way to tell programs that the interface is a Heimdal variant
> and not MIT?
I have no idea, my workaround was to use krb5-config.
I the krb5-config behaves in a prediactable way I can use that.
> Also, could perlgssapi's Makefile.PL dynamially detect the
> presence/requirement of <gssapi_krb5.h>?
What symbols do you need from your gssapi_krb5.h?
In the original Heimdal I need only the gssapi.h.
> Not knowing which header to
> include is a deficiency in the standards (RFC1964 has no corresponding C
> binding std).
Mabe your krb5-config can prinout a unique identifier
I can use to set the correct include behaviour?
Thank you,
Achim
|
|
From: David L. <Dav...@qu...> - 2006-02-21 05:09:51
|
Hi.
Here is some build feedback with GSSAPI-0.18.
We have a Heimdal-derived GSSAPI implementation called VAS.
Anyway, when I tried to build GSSAPI-0.18 against it, I found I could
succeed with this patch:
--- GSSAPI-0.18.orig/GSSAPI.xs 2006-02-21 14:42:37.000000000 +1000
+++ GSSAPI-0.18/GSSAPI.xs 2006-02-21 14:42:54.000000000 +1000
@@ -9,8 +9,10 @@
#define __GSS_KRB5_NT_PRINCIPAL_NAME &mygss_nt_krb5_principal
#define __gss_mech_krb5_v2 &mygss_mech_krb5_v2
+#define HEIMDAL
#if defined(HEIMDAL)
#include <gssapi.h>
+#include <gssapi_krb5.h>
#endif
#if !defined(HEIMDAL)
This is needed because 'krb5-config --version' does not contain
"eimdal", and gssapi_krb5.h was split from gssapi.h to better match the
RFCs.
So, I have some questions. How can this situation be improved? Our
'krb5-config --version' only spits out the product version number
("3.0.1"). Should it say "Heimdal" somewhere in there? Indeed, is there
a standard way to tell programs that the interface is a Heimdal variant
and not MIT?
Also, could perlgssapi's Makefile.PL dynamially detect the
presence/requirement of <gssapi_krb5.h>? Not knowing which header to
include is a deficiency in the standards (RFC1964 has no corresponding C
binding std).
Otherwise, GSSAPI-0.18 built fine. Follows is the build output, with a
lot of warnings.
d
davidl@willy-wagtail:GSSAPI-0.18$ perl Makefile.PL && make
Welcome to GSSAPI.pm setup!
run "perl Makefile.PL --help" to see further installation options
----------------------------------------------------------
Searching krb5-config command...
/opt/quest/bin/krb5-config
----------------------------------------------------------
using GSSAPI implementation
3.0.1
----------------------------------------------------------
Adding from your Perlinstallation ($Config{lddlflags}) to LDDLFLAGS
-shared
----------------------------------------------------------
Bypassing to LDDLFLAGS
-shared -Wl,-rpath -Wl,/opt/quest/lib:/opt/quest/lib/support
----------------------------------------------------------
Using LIBS
-L/opt/quest/lib -lvas -L/opt/quest/lib/support -lgcc_s
----------------------------------------------------------
Using INC includeconfiguration
-I/opt/quest/include
----------------------------------------------------------
Checking if your kit is complete...
Looks good
Writing Makefile for GSSAPI
cp GSSAPI.pm blib/lib/GSSAPI.pm
cp GSSAPI/OID/Set.pm blib/lib/GSSAPI/OID/Set.pm
cp GSSAPI/OID.pm blib/lib/GSSAPI/OID.pm
cp GSSAPI/Status.pm blib/lib/GSSAPI/Status.pm
/usr/bin/perl /usr/lib/perl5/5.8.6/ExtUtils/xsubpp -typemap
/usr/lib/perl5/5.8.6/ExtUtils/typemap -typemap typemap GSSAPI.xs >
GSSAPI.xsc && mv GSSAPI.xsc GSSAPI.c
cc -c -I/opt/quest/include -D_REENTRANT -D_GNU_SOURCE
-DTHREADS_HAVE_PIDS -DDEBUGGING -fno-strict-aliasing -pipe
-D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -O2 -march=i586
-mcpu=i686 -fmessage-length=0 -Wall -g -Wall -pipe
-DVERSION=\"0.18\" -DXS_VERSION=\"0.18\" -fPIC
"-I/usr/lib/perl5/5.8.6/i586-linux-thread-multi/CORE" GSSAPI.c
GSSAPI.xs: In function `constant_GSS_S_NO':
GSSAPI.xs:69: warning: label `not_there' defined but not used
GSSAPI.xs: In function `constant_GSS_S_N':
GSSAPI.xs:92: warning: label `not_there' defined but not used
GSSAPI.xs: In function `constant_GSS_S_BAD_N':
GSSAPI.xs:125: warning: label `not_there' defined but not used
GSSAPI.xs: In function `constant_GSS_S_BAD_S':
GSSAPI.xs:154: warning: label `not_there' defined but not used
GSSAPI.xs: In function `constant_GSS_S_B':
GSSAPI.xs:203: warning: label `not_there' defined but not used
GSSAPI.xs: In function `constant_GSS_S_CON':
GSSAPI.xs:236: warning: label `not_there' defined but not used
GSSAPI.xs: In function `constant_GSS_S_CO':
GSSAPI.xs:259: warning: label `not_there' defined but not used
GSSAPI.xs: In function `constant_GSS_S_CALL_I':
GSSAPI.xs:292: warning: label `not_there' defined but not used
GSSAPI.xs: In function `constant_GSS_S_CA':
GSSAPI.xs:321: warning: label `not_there' defined but not used
GSSAPI.xs: In function `constant_GSS_S_C':
GSSAPI.xs:373: warning: label `not_there' defined but not used
GSSAPI.xs: In function `constant_GSS_S_DU':
GSSAPI.xs:406: warning: label `not_there' defined but not used
GSSAPI.xs: In function `constant_GSS_S_DE':
GSSAPI.xs:439: warning: label `not_there' defined but not used
GSSAPI.xs: In function `constant_GSS_S_D':
GSSAPI.xs:456: warning: label `not_there' defined but not used
GSSAPI.xs: In function `constant_GSS_S_UNA':
GSSAPI.xs:485: warning: label `not_there' defined but not used
GSSAPI.xs: In function `constant_GSS_S_U':
GSSAPI.xs:514: warning: label `not_there' defined but not used
GSSAPI.xs: In function `constant_GSS_S_':
GSSAPI.xs:561: warning: label `not_there' defined but not used
GSSAPI.xs: In function `constant_GSS_C_AF_N':
GSSAPI.xs:598: warning: label `not_there' defined but not used
GSSAPI.xs: In function `constant_GSS_C_AF_C':
GSSAPI.xs:627: warning: label `not_there' defined but not used
GSSAPI.xs: In function `constant_GSS_C_AF_D':
GSSAPI.xs:672: warning: label `not_there' defined but not used
GSSAPI.xs: In function `constant_GSS_C_AF_I':
GSSAPI.xs:701: warning: label `not_there' defined but not used
GSSAPI.xs: In function `constant_GSS_C_AF_L':
GSSAPI.xs:730: warning: label `not_there' defined but not used
GSSAPI.xs: In function `constant_GSS_C_AF':
GSSAPI.xs:839: warning: label `not_there' defined but not used
GSSAPI.xs: In function `constant_GSS_C_A':
GSSAPI.xs:870: warning: label `not_there' defined but not used
GSSAPI.xs: In function `constant_GSS_C_RO':
GSSAPI.xs:903: warning: label `not_there' defined but not used
GSSAPI.xs: In function `constant_GSS_C_R':
GSSAPI.xs:926: warning: label `not_there' defined but not used
GSSAPI.xs: In function `constant_GSS_C_SU':
GSSAPI.xs:959: warning: label `not_there' defined but not used
GSSAPI.xs: In function `constant_GSS_C_S':
GSSAPI.xs:982: warning: label `not_there' defined but not used
GSSAPI.xs: In function `constant_GSS_C_CA':
GSSAPI.xs:1015: warning: label `not_there' defined but not used
GSSAPI.xs: In function `constant_GSS_C_C':
GSSAPI.xs:1038: warning: label `not_there' defined but not used
GSSAPI.xs: In function `constant_GSS_C_I':
GSSAPI.xs:1079: warning: label `not_there' defined but not used
GSSAPI.xs: In function `constant_GSS_C_M':
GSSAPI.xs:1108: warning: label `not_there' defined but not used
GSSAPI.xs: In function `constant_GSS_C':
GSSAPI.xs:1197: warning: label `not_there' defined but not used
GSSAPI.xs: In function `constant_G':
GSSAPI.xs:1222: warning: label `not_there' defined but not used
GSSAPI.xs: In function `constant':
GSSAPI.xs:1238: warning: label `not_there' defined but not used
GSSAPI.c: In function `XS_GSSAPI__Status_new':
GSSAPI.c:1444: warning: unused variable `class'
GSSAPI.c: In function `XS_GSSAPI__Name_new':
GSSAPI.c:1694: warning: unused variable `class'
GSSAPI.c: In function `XS_GSSAPI__Name_import':
GSSAPI.c:1744: warning: unused variable `class'
GSSAPI.c: In function `XS_GSSAPI__OID_new':
GSSAPI.c:2047: warning: unused variable `class'
GSSAPI.c: In function `XS_GSSAPI__OID_DESTROY':
xs/OID.xs:14: warning: unused variable `minor'
GSSAPI.c: In function `XS_GSSAPI__OID_from_str':
GSSAPI.c:2109: warning: unused variable `class'
GSSAPI.c: In function `XS_GSSAPI__OID__Set_new':
GSSAPI.c:2502: warning: unused variable `class'
GSSAPI.c: In function `XS_GSSAPI__Binding_new':
GSSAPI.c:3108: warning: unused variable `class'
GSSAPI.c: In function `XS_GSSAPI__Context_new':
GSSAPI.c:3460: warning: unused variable `class'
GSSAPI.c: In function `XS_GSSAPI__Context_import':
GSSAPI.c:4234: warning: unused variable `class'
Running Mkbootstrap for GSSAPI ()
chmod 644 GSSAPI.bs
rm -f blib/arch/auto/GSSAPI/GSSAPI.so
LD_RUN_PATH="/opt/quest/lib:/opt/quest/lib/support" cc -shared
-Wl,-rpath -Wl,/opt/quest/lib:/opt/quest/lib/support GSSAPI.o -o
blib/arch/auto/GSSAPI/GSSAPI.so -L/opt/quest/lib -lvas
-L/opt/quest/lib/support -lgcc_s
chmod 755 blib/arch/auto/GSSAPI/GSSAPI.so
cp GSSAPI.bs blib/arch/auto/GSSAPI/GSSAPI.bs
chmod 644 blib/arch/auto/GSSAPI/GSSAPI.bs
Manifying blib/man3/GSSAPI.3pm
Manifying blib/man3/GSSAPI::OID::Set.3pm
Manifying blib/man3/GSSAPI::OID.3pm
Manifying blib/man3/GSSAPI::Status.3pm
--
David Leonard
Vintela Resource Central software engineer
Quest Software; 303 Adelaide St, Brisbane, Australia; www.quest.com
Phone: (US) +1 801 655 2755
(AU) +61 7 3023 5133
|
|
From: Achim G. <ac...@gr...> - 2006-02-11 03:06:00
|
Reading the Output of Makefile.PL
hundreds and hundreds of time is boring.
Just beatifying of output of Makefile.PL,
but makes testing easier. (I hope ;-))
looks like this now:
Welcome to GSSAPI.pm setup!
run "perl Makefile.PL --help" to see further installation options
----------------------------------------------------------
Searching krb5-config command...
/usr/bin/krb5-config
----------------------------------------------------------
using GSSAPI implementation
Kerberos 5 release 1.3.1
----------------------------------------------------------
Adding from your Perlinstallation ($Config{lddlflags}) to LDDLFLAGS
-shared -L/usr/local/lib
----------------------------------------------------------
Bypassing to LDDLFLAGS
-shared -L/usr/local/lib -Wl,-rpath -Wl,/usr/lib
----------------------------------------------------------
Using LIBS
-L/usr/lib -lgssapi_krb5 -lkrb5 -lk5crypto -lcom_err -lresolv
----------------------------------------------------------
Using INC includeconfiguration
-I/usr/include
----------------------------------------------------------
Writing Makefile for GSSAPI
Thank you,
Achim
|
|
From: Achim G. <ac...@gr...> - 2006-02-05 02:23:20
|
Welcome to the GSSAPI Bindings user List. I hope you will have fun with the module! Achim |
1 message has been excluded from this view by a project administrator.
