We had a similar problem. I believe there was an error message in our system log files that pointed to the solution. I logged in remotely and deleted a problem file. I'm not 100% sure what the file was, but I think it was something like .ICEauthority or a variation on it. Some how the file got corrupted and when root tried to login, it was quickly kicked out. I hope this helps some. Good luck.
On 5/23/07, Brent L. Bates blbates@vigyan.com wrote:
We had a similar problem. I believe there was an error message in oursystem log files that pointed to the solution. I logged in remotely and deleted a problem file. I'm not 100% sure what the file was, but I think it was something like .ICEauthority or a variation on it. Some how the file got corrupted and when root tried to login, it was quickly kicked out. I hope this helps some. Good luck.
Well, I tried .dmrc, .ICEauthority and .Xauthority and none of them appear to be responsible. (I renamed each one to .old, tried a login, failed, and renamed them back.)
As far as I can tell, this affects ALL non root users on the system. I can log in remotely, or as root (remotely or directly via gdm), but not via gdm as a non-root user.
Also, I cannot manipulate passwords at all. When I try to set a user password using the users and groups applet, it hangs. When I try to set a user password from the root login via passwd <user>, I always get an authentication failure.
Does that clarify the problem to anyone else?
Mark Hull-Richter wrote:
Also, I cannot manipulate passwords at all. When I try to set a user password using the users and groups applet, it hangs. When I try to set a user password from the root login via passwd <user>, I always get an authentication failure.
Does that clarify the problem to anyone else?
Hmm, not sure about the password part of this... but is SELinux enabled? If so, you might have to run restorecon on the new /home directory.
Also, you said you "think" permissions were preserved, but it's better to be absolutely sure: when you "ls -la" any user's home directory, they own every file/directory in their home (including "hidden" ones like .gnome, etc)?
Lastly, in Users & Groups applet, the home directories are correct for each user?
johnn
On 5/23/07, Johnny Tan jtan@limewire.com wrote:
Hmm, not sure about the password part of this... but is SELinux enabled? If so, you might have to run restorecon on the new /home directory.
No SELinux (it is disabled).
Also, you said you "think" permissions were preserved, but it's better to be absolutely sure: when you "ls -la" any user's home directory, they own every file/directory in their home (including "hidden" ones like .gnome, etc)?
Everything is correct here - the user ids are all set up right.
Lastly, in Users & Groups applet, the home directories are correct for each user?
Yes, that, too.
I'm rebuilding the installation (again).
On Wed, 23 May 2007 10:36:50 -0700 "Mark Hull-Richter" mhullrich@gmail.com took out a #2 pencil and scribbled:
On 5/23/07, Brent L. Bates blbates@vigyan.com wrote:
We had a similar problem. I believe there was an errormessage in our system log files that pointed to the solution. I logged in remotely and deleted a problem file. I'm not 100% sure what the file was, but I think it was something like .ICEauthority or a variation on it. Some how the file got corrupted and when root tried to login, it was quickly kicked out. I hope this helps some. Good luck.
Well, I tried .dmrc, .ICEauthority and .Xauthority and none of them appear to be responsible. (I renamed each one to .old, tried a login, failed, and renamed them back.)
As far as I can tell, this affects ALL non root users on the system. I can log in remotely, or as root (remotely or directly via gdm), but not via gdm as a non-root user.
Also, I cannot manipulate passwords at all. When I try to set a user password using the users and groups applet, it hangs. When I try to set a user password from the root login via passwd <user>, I always get an authentication failure.
Does that clarify the problem to anyone else?
You aren't running SELinux are you? Did you restore those contexts or at least make sure the contexts are correct? Did permissions not get preserved in the move? If the permissions (which I know was probably obvious to you) are incorrect the user won't be able to log in, but I'm not sure about that log in incorrect error with changing passwords. It could possibly be SELinux related.
HTH
On 5/23/07, Mark Hull-Richter mhullrich@gmail.com wrote:
Also, I cannot manipulate passwords at all. When I try to set a user password using the users and groups applet, it hangs. When I try to set a user password from the root login via passwd <user>, I always get an authentication failure.
Does that clarify the problem to anyone else?
This very much smells like a permissions error. Did you muck with /etc/ at all when you were moving things around?
You might want to try something like 'rpm -V setup' or even 'rpm -Va > whatsbroke.txt'
The output of these commands will tell you if anything has been changed for the setup package (which has the password files) or all rpms respectively. If,as root, you cannot manipulate a user's password with 'passwd userfoo' then it's probably a permissions error on /etc/passwd or /etc/shadow
On 5/23/07, Jim Perrin jperrin@gmail.com wrote:
This very much smells like a permissions error. Did you muck with /etc/ at all when you were moving things around?
You might want to try something like 'rpm -V setup' or even 'rpm -Va > whatsbroke.txt'
The output of these commands will tell you if anything has been changed for the setup package (which has the password files) or all rpms respectively. If,as root, you cannot manipulate a user's password with 'passwd userfoo' then it's probably a permissions error on /etc/passwd or /etc/shadow
I looked at them (as root) and even removed a password from the shadow file for one user to see if that made a difference. What you say sounds probable, and I'll keep this for reference should the issue come up again (or just to see what it should look like on a normal system).
Unfortunately, I don't have any more time to fix this - I need the system up and working a.s.a.p., so I'm reinstalling it, with care....
Thanks.
New scenario, same problem.
Installed 4.4. Logged in through gdm on console as root. Created 3 non-root users. Ran yum update (578 packages - worked fine). Rebooted.
Checked permissions on all three users' directories - everything looks fine.
Logged out. Tried to log in as each non-root user - same <10 second error / login failure.
Figured, hmm, maybe I should just delete and recreate the users. Fired up the gdm users & groups applet. Deleted last user. Fine. Deleted next user. Fine. Deleted main/first non-root user. Still circling (five minutes now). Something is definitely awry here.
Aborted the applet. Checked /home - all three directories are now gone. Checked /etc/passwd and /etc/shadow - all three users gone. Recreated second user. Paths and passwd/shadow look fine. Logged out. Attempted login with that user - failed again.
Took Jim's advice and ran rpm -Va | grep -v '.......T' and got a whole long list of discrepancies, but nothing that looks too suspicious except /etc/sysconfig/system-config-users has ..5....T.
WTF?
On 5/23/07, Mark Hull-Richter mhullrich@gmail.com wrote:
New scenario, same problem.
Installed 4.4. Logged in through gdm on console as root. Created 3 non-root users. Ran yum update (578 packages - worked fine). Rebooted.
Shouldn't matter, but you should really *never* log into the GUI as root for a server. I smack my junior admins around verbally when I see this sort of thing (I should probably really stop watching reruns of House and Scrubs...) If you installed enough to get the gui, you should have also gotten firstboot, which would have prompted you to create a user. Does this user work? Did you log in with this user before you logged in with root? (If not, can you try that?)
Checked permissions on all three users' directories - everything looks fine.
What options are you setting for these users(shell, home directory, enabled/disabled status etc)?
Logged out. Tried to log in as each non-root user - same <10 second error / login failure.
This error should tell you that it dropped an error file. Have you looked at the contents of this file?
Figured, hmm, maybe I should just delete and recreate the users. Fired up the gdm users & groups applet. Deleted last user. Fine. Deleted next user. Fine. Deleted main/first non-root user. Still circling (five minutes now). Something is definitely awry here.
The gui tools can sometimes hide useful errors. Can you try adding/removing users from the cli with useradd/userdel?
Aborted the applet. Checked /home - all three directories are now gone. Checked /etc/passwd and /etc/shadow - all three users gone. Recreated second user. Paths and passwd/shadow look fine. Logged out. Attempted login with that user - failed again.
How are you looking at /etc/passwd and /etc/shadow? If you're opening them with an editor, you could be inadvertently changing the permissions.
Took Jim's advice and ran rpm -Va | grep -v '.......T' and got a whole long list of discrepancies, but nothing that looks too suspicious except /etc/sysconfig/system-config-users has ..5....T.
This tells you that the md5sum has changed, and that the modify time has changed. Unless you were changing some values there, this shouldn't be the case. I don't use the gui user applet you're refering to, but I can't imagine that it would modify this file. At least not for any sane reason.
WTF?
I'd say try again with CLI tools to rule out any gui foolishness, and try logging in with the user you create at firstboot rather than logging in with root.
On 5/23/07, Jim Perrin jperrin@gmail.com wrote:
Shouldn't matter, but you should really *never* log into the GUI as root for a server. I smack my junior admins around verbally when I see this sort of thing (I should probably really stop watching reruns of House and Scrubs...)
Technically it's not a server, but I almost never log in as root anyway, just as a matter of habit. This time there was no alternative.
If you installed enough to get the gui, you should have also gotten firstboot, which would have prompted you to create a user. Does this user work? Did you log in with this user before you logged in with root? (If not, can you try that?)
No and yes, in that order.
What options are you setting for these users(shell, home directory, enabled/disabled status etc)?
Pretty much just the defaults, except that I put all the users in the "users" group (instead of having a unique one for each). /bin/bash, /home/<username>, enabled...
This error should tell you that it dropped an error file. Have you looked at the contents of this file?
I thought so too, and I looked for one, but the only error the files in /var/log/gdm are showing are:
(WW) ATI(0): Failed to set up write-combining range (0xfc000000, 0x8000000) AUDIT: Wen May 23 18:59:25 2007: 5901 X: client 5 rejected from local host
Does that mean something (in English)?
The gui tools can sometimes hide useful errors. Can you try adding/removing users from the cli with useradd/userdel?
These work, but the users still can't log in.
How are you looking at /etc/passwd and /etc/shadow? If you're opening them with an editor, you could be inadvertently changing the permissions.
-rw-r--r-- 1 root root 1575 May 23 19:08 /etc/passwd -r--------- 1 root root 995 May 23 19:09 /etc/shadow
This tells you that the md5sum has changed, and that the modify time has changed. Unless you were changing some values there, this shouldn't be the case. I don't use the gui user applet you're refering to, but I can't imagine that it would modify this file. At least not for any sane reason.
My thoughts also.
I'd say try again with CLI tools to rule out any gui foolishness, and try logging in with the user you create at firstboot rather than logging in with root.
Tried that one, too. No go. I'm not sure now if I logged in as root first or as mhr, though I can't fathom why that would make this kind of difference. If needed, tomorrow I can re-install one more time and do the first login as the non-root user and see what happens. I'm wondering if the update to 4.5 has anything to do with this, since that was one of the first things I did, and all this happened after that. Seems strange that I haven't heard of this before, though, if that were the case.
Thanks!
-
Brent L. Bates -
ethericalzenï¼ gmail.com -
Jim Perrin -
Johnny Tan -
Mark Hull-Richter