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@IFM.LIU.SE (DES cbc mode with

RSA-MD5)

6 nfs/pc13267.ad.ifm.liu.se@IFM.LIU.SE (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@IFM.LIU.SE (DES cbc mode with CRC-32) 3 host/pc14113.ad.ifm.liu.se@IFM.LIU.SE (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@triangulum.ifm.liu.se

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@triangulum.ifm.liu.se

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@IFM.LIU.SE

Valid starting Expires Service principal 11/05/10 10:34:46 11/06/10 10:34:46 krbtgt/IFM.LIU.SE@IFM.LIU.SE

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@IFM.LIU.SE

Valid starting Expires Service principal 11/05/10 10:38:52 11/06/10 10:38:52 krbtgt/IFM.LIU.SE@IFM.LIU.SE 11/05/10 10:38:52 11/06/10 10:38:52

nfs/triangulum.ifm.liu.se@IFM.LIU.SE

Kerberos 4 ticket cache: /tmp/tkt2038 klist: You have no tickets cached

(working)

Ideas? I'm all out of 'em.

Hans