[gdm-list] Consistent failed/successful gdm login

["Jukka Tuominen" <jukka tuominen finndesign fi>]

Hi all,

I have a very strangely behaving client/server installation, where an
identical client installation (virtual machine snapshot) on one host
machine delivers successful gdm login every time, and on another (much
slower) host machine it fails every time. A little background:

I had a well-behaving Kerberos/OpenAFS/OpenLDAP installation, with
integrated gdm login. However, I had to change the domain name for all the
servers, user and host principals, LDAP database content, AFS databases
etc. and try to keep them all in sync. A bit more complex task than you
may wish for, really. Anyhow, I decided to remove LDAP from the equation
since it was only used for the very basic metadata. libnss-afs package is
now used to provide e.g. homedir paths on AFS. None of the user data gets
written on the client side, which has basically a live-cd-type-of memory
arrangements.

As mentioned, I can't get the gdm-login working on all clients. If I login
as a local unix user, I can log into AFS accounts without problems. Also
'id user' and 'getent passwd user' commands return correct metadata for
AFS users. I set gdm on debug mode, and in both cases the login process
goes quite far, until the failing instance returns an error:
gdm-simple-slave[798]: WARNING: Failed to add user authorization: could
not find user "userx" on system
eventhough the authorization phase was once passed already.

It could be a time-out of some kind possibly, but then again, the
rejection happens within a few seconds only. It can be a misconfiguration
somewhere, but one, identical client instance succeeds every time. Weird!

On a visual level, it looks as if the login is going to succeed, but
returns back to the login screen in the end. I found quite a many similar
cases while searching the solution, but none was dealing with similar
installation.

Any idea what may be causing this and how to fix it? I have syslogs for
both the successful and failed login, but they are quite big.

br, jukka