On the slave the only log that has a trace of the failed transaction is the
auth.log:
May 19 15:30:11 slave xinetd[1237]: START: krb_prop pid=1454 from=ip.master
May 19 15:30:11 slave xinetd[1454]: FAIL: krb_prop address from=ip.master
Sounds like the server side is dying right away. Check some basics first: Is the pathname in the xinetd config file correct? Can the specified user (probably root) run the executable? Is it the right executable? Does it crash immediately if you try running it from the command line? Are there any core files in the directory that xinetd runs programs in? Does it complain about the command line arguments if you run it with those specified in the xinetd config file? Did you give it the "-S" argument that tells it that it, and not xinetd, should be handling new incoming connections?
Check your syslog configuration to see where daemon.info (and more severe) messages will be logged, since that's what kpropd uses; if you're not logging them, you should change that.
Worst case, you could set up xinetd to run kpropd under strace (for Linux; truss for Solaris; ktrace for NetBSD; etc) and log the syscall activity someplace where you can examine what's going on. (Don't post the output, it'll probably include private key data.)
Ken
________________________________________________ Kerberos mailing list [EMAIL PROTECTED] https://mailman.mit.edu/mailman/listinfo/kerberos
