Thanks for the info, I greatly appreciate it.
I'm guessing my choices are:
1) use that configure option, and have my command-line tools not work with the tickets that the GUI apps use (which means I'll have 2 different kinit's and kdestroy's, as well, right? because the stock ones that come with Panther do work with those same tickets)
That's correct, you'd basically have double-signon instead of single-signon. ;-)
2) figure out what all of the things I to do in order to link with KfM instead of static linking; which includes making copies of certain BSD networking functions, and figuring out what configure options go with the KfM libs (are those the default ones?)
Also correct. You don't actually need to do anything special to configure because KfM provides compatibility libraries in /usr/lib and headers in /usr/include. The problem basically boils down to the MIT Kerberos Team having defined a public API, the KfM Kerberos framework enforcing that API with an export list, and the appl/bsd tools using functions not in the public API.
I'd rather they all use one set of tickets, but I don't know how much time I have to throw at this process.
You might actually have a third option of using Heimdal 0.7 (which hasn't been released yet). I believe Heimdal 0.7 will have support to use the in-memory credentials cache on KfM. So if you can build Heimdal 0.7, its BSD tools will share tickets with KfM. Basically it looks like you add "default_cc_name = API:" to the libdefaults in /etc/krb5.conf and applications linked against Heimdal will see the KfM in-memory credentials cache.
This support is discussed in this email thread: <http://www.stacken.kth.se/lists/heimdal-discuss/2004-08/msg00073.html>
Note that KfM on Panther supports having the config file either in /Library/Preferences/edu.mit.Kerberos or in /etc/krb5.conf. It looks like at least as of the time of the aforementioned discussion, Heimdal only looks at /etc/krb5.conf. You might have to move your config into /etc/krb5.conf to get it to work.
Anyway, it might be worth a shot to grab a current snapshot of Heimdal and see if it just works.
On Jan 21, 2005, at 14:52, Alexandra Ellwood wrote:
To build stock krb5 on Mac OS X, try building with "LDFLAGS=-Wl,-search_paths_first" as an option to configure. See <http://mailman.mit.edu/pipermail/krbdev/2003/001714.html> for more information.
Note that if you build the appl/bsd utilities statically linked against your own stock krb5 libraries, you won't be able to share tickets with Kerberos for Macintosh (the Kerberos in Mac OS X) because KfM uses an in-memory ccache to store tickets which the stock krb5 currently doesn't support.
However, you should be able to work around the undefined symbols in the appl/bsd programs and link with KfM. krb5_net_read/write and many of the other symbols are just simple BSD networking functions which you can copy into the sources of utilities you want to build. I'm not sure about krb5_random_confounder(), though. You'd have to look at it.
John Rudd wrote:> go to the appl/bsd dir and do a make, I get:
When I try to build on Mac OS X (10.3.7), everything is fine until lib/rpc/unit-test:
making all in lib/rpc/unit-test... gcc -L../../../lib -g -O2 -Wall -Wmissing-prototypes -Wcast-qual -Wcast-align -Wconversion -Wshadow -Wno-comment -pedantic -o client client.o rpc_test_clnt.o \ -lgssrpc -lgssapi_krb5 -lkrb5 -lk5crypto -lcom_err ld: Undefined symbols: _krb5_gss_dbg_client_expcreds _gss_mech_krb5 _gss_mech_krb5_old
But all I really want is rlogin, klogind, rsh, rcp, and krshd. So, if I> _krb5_random_confounder
gcc -L../../lib -g -O2 -Wall -Wmissing-prototypes -Wcast-qual -Wcast-align -Wconversion -Wshadow -Wno-comment -pedantic -o rsh krsh.o kcmd.o forward.o -lkrb4 -ldes425 -lkrb5 -lk5crypto -lcom_err ld: Undefined symbols: _krb5_net_read_krb5_write_message _krb_net_read
Anyone know what's going on and how to fix/avoid it? I did a configure with "--with-krb4" as its only argument. It's a pretty vanilla Mac OS X install, with the apple developer tools (which are what I'm building with). If you need more information, just ask.
No one has thoughts, comments, suggestions, commiserations? ________________________________________________ Kerberos mailing list [email protected] https://mailman.mit.edu/mailman/listinfo/kerberos
Hope this helps,
-- --lxs
Alexandra Ellwood <[EMAIL PROTECTED]> MIT Kerberos Development Team <http://mit.edu/lxs/www/>
-- --lxs
Alexandra Ellwood <[EMAIL PROTECTED]> MIT Kerberos Development Team <http://mit.edu/lxs/www/> ________________________________________________ Kerberos mailing list [email protected] https://mailman.mit.edu/mailman/listinfo/kerberos
