Both pc13267 and pc14113 run CentOS 5.5. On pc14113, my test user gets a
home directory when logging in, but not on pc13267. But why?
All logs below are from /var/log/messages. I have removed dates and
stuff from the beginning of lines to make them more readable, and then
grouped lines about the same thing from both machines.
> pc13267 Using keytab file '/etc/krb5.keytab'
> pc13267 INFO: Credentials in CC
> 'MEMORY:/tmp/krb5cc_machine_IFM.LIU.SE' are good until
> 1288959329
> pc14113 getting credentials for client with uid 2038 for server
> triangulum.ifm.liu.se
> pc14113 CC file 'krb5cc_2038_R3Gzcw' being considered
> pc14113 CC file 'krb5cc_2038_R3Gzcw' matches owner check and has
> mtime of 1288949932
For some reason, only the broken machine appears to look
in /etc/krb5.keytab (or at least it's the only one admitting to doing
it).
/etc/krb5.conf looks the same on both machines.
/etc/krb5.keytab has the same rights (root.root, 600) and size on both
machines, and as far as I can tell no differences in content:
> [root@pc13267 ~]# klist -k -e
> Keytab name: FILE:/etc/krb5.keytab
> KVNO Principal
> ---- -----------------------------------------------------------------
> 20 host/pc13267.ad.ifm.liu.se@xxxxxxxxxx (DES cbc mode with
RSA-MD5)
> 6 nfs/pc13267.ad.ifm.liu.se@xxxxxxxxxx (DES cbc mode with CRC-32)
> [root@pc14113 ~]# klist -k -e
> Keytab name: FILE:/etc/krb5.keytab
> KVNO Principal
> ---- -----------------------------------------------------------------
> 3 nfs/pc14113.ad.ifm.liu.se@xxxxxxxxxx (DES cbc mode with CRC-32)
> 3 host/pc14113.ad.ifm.liu.se@xxxxxxxxxx (DES cbc mode with
RSA-MD5)
There are no differences in /etc/pam.d/ between the machines (except
that the working machine apart from the files it should have also has a
system-auth-ac~, but I have a hard time imagining that to be
significant).
> pc13267 using MEMORY:/tmp/krb5cc_machine_IFM.LIU.SE as credentials
> cache for machine creds
> pc13267 using environment variable to select krb5 ccache
> MEMORY:/tmp/krb5cc_machine_IFM.LIU.SE
> pc14113 using FILE:/tmp/krb5cc_2038_R3Gzcw as credentials cache for
> client with uid 2038 for server triangulum.ifm.liu.se
> pc14113 using environment variable to select krb5 ccache
> FILE:/tmp/krb5cc_2038_R3Gzcw
The machine having problems save to memory, the working one to disk, and
they use file names with a different structure. I suspect this to be
relevant somehow, but I have no clue why they behave differently.
> pc13267 creating context using fsuid 0 (save_uid 0)
> pc13267 creating tcp client for server triangulum.ifm.liu.se
> pc13267 creating context with server nfs@xxxxxxxxxxxxxxxxxxxxx
> pc14113 creating context using fsuid 2038 (save_uid 0)
> pc14113 creating tcp client for server triangulum.ifm.liu.se
> pc14113 creating context with server nfs@xxxxxxxxxxxxxxxxxxxxx
The machine that works gets the uid right while the other one for some
reason gets it to 0. Definitely wrong, but why?
> pc13267 rpcsec_gss: gss_init_sec_context: (major) Unspecified GSS
> failure. Minor code may provide more information - (minor)
> Unknown code krb5 60
> pc13267 WARNING: Failed to create krb5 context for user with uid 0
> for server triangulum.ifm.liu.se
> pc13267 WARNING: Failed to create krb5 context for user with uid 0
> with credentials cache MEMORY:/tmp/krb5cc_machine_IFM.LIU.SE for
> server triangulum.ifm.liu.se
> pc13267 WARNING: Failed to create krb5 context for user with uid 0
> with any credentials cache for server triangulum.ifm.liu.se
> pc14113 DEBUG: serialize_krb5_ctx: lucid version!
> pc14113 prepare_krb5_rfc1964_buffer: serializing keys with enctype 4
> and length 8
After this, things break down (which doesn't really surprise me). The
question is, I guess, why the broken machine starts using uid 0 to begin
with.
There is also a difference in what tickets the user gets on the
different machines.
> [testson2@pc13267 /]$ klist
> Ticket cache: FILE:/tmp/krb5cc_2038_ch9xY3
> Default principal: testson2@xxxxxxxxxx
>
> Valid starting Expires Service principal
> 11/05/10 10:34:46 11/06/10 10:34:46 krbtgt/IFM.LIU.SE@xxxxxxxxxx
>
>
> Kerberos 4 ticket cache: /tmp/tkt2038
> klist: You have no tickets cached
(non-working)
> pc14113:/home/testson2> klist
> Ticket cache: FILE:/tmp/krb5cc_2038_R3Gzcw
> Default principal: testson2@xxxxxxxxxx
>
> Valid starting Expires Service principal
> 11/05/10 10:38:52 11/06/10 10:38:52 krbtgt/IFM.LIU.SE@xxxxxxxxxx
> 11/05/10 10:38:52 11/06/10 10:38:52
nfs/triangulum.ifm.liu.se@xxxxxxxxxx
>
>
> Kerberos 4 ticket cache: /tmp/tkt2038
> klist: You have no tickets cached
(working)
Ideas? I'm all out of 'em.
Hans
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
http://lists.centos.org/mailman/listinfo/centos
