FAQ
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 at pc13267 ~]# klist -k -e
Keytab name: FILE:/etc/krb5.keytab
KVNO Principal
---- -----------------------------------------------------------------
20 host/pc13267.ad.ifm.liu.se at IFM.LIU.SE (DES cbc mode with RSA-MD5)
6 nfs/pc13267.ad.ifm.liu.se at IFM.LIU.SE (DES cbc mode with CRC-32)
[root at pc14113 ~]# klist -k -e
Keytab name: FILE:/etc/krb5.keytab
KVNO Principal
---- -----------------------------------------------------------------
3 nfs/pc14113.ad.ifm.liu.se at IFM.LIU.SE (DES cbc mode with CRC-32)
3 host/pc14113.ad.ifm.liu.se at 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 at 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 at 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 at pc13267 /]$ klist
Ticket cache: FILE:/tmp/krb5cc_2038_ch9xY3
Default principal: testson2 at IFM.LIU.SE

Valid starting Expires Service principal
11/05/10 10:34:46 11/06/10 10:34:46 krbtgt/IFM.LIU.SE at 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 at IFM.LIU.SE

Valid starting Expires Service principal
11/05/10 10:38:52 11/06/10 10:38:52 krbtgt/IFM.LIU.SE at IFM.LIU.SE
11/05/10 10:38:52 11/06/10 10:38:52
nfs/triangulum.ifm.liu.se at IFM.LIU.SE

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

Ideas? I'm all out of 'em.

Hans

Search Discussions

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupcentos @
categoriescentos
postedNov 16, '10 at 8:31a
activeNov 16, '10 at 8:31a
posts1
users1
websitecentos.org
irc#centos

1 user in discussion

Hans Persson: 1 post

People

Translate

site design / logo © 2021 Grokbase