Hello,
since kernel 2.6.18-164.el5 no user could login any more from nfs client into his home directory on nfs server. The kde error message is: "The following installation problem was detected while trying to start KDE: Writing to $HOME directory (/home/<USER>) failed with the error 'Permission denied' KDE is unable to start."
/home is exported with nfs4 (gss/krb5), the password is delivered by nis. Everything works fine if I reboot the nfs server into the previous kernel 2.6.18-128.7.1.el5. Then it is completely irrelevant which kernel version the client has. So /home export by nfs4 works for client with kernel versions 2.6.18-164.el5 and 2.6.18-128.7.1.el5.
If the nfs server runs under kernel 2.6.18-164.el5, the error messages for the user login process are (names for user, client and domain are replaced):
/var/log/messages Sep 16 15:54:13 <NFS_CLIENT> gdm[3122]: run_session_child: »~/.xsession-errors« konnte nicht geöffnet werden Sep 16 15:55:02 <NFS_CLIENT> ntpd[2674]: synchronized to 192.168.0.1, stratum 14 Sep 16 15:57:14 <NFS_CLIENT> gdm[3122]: run_session_child: »~/.xsession-errors« konnte nicht geöffnet werden
/var/log/secure Sep 16 15:57:14 <NFS_CLIENT> gdm[3122]: pam_unix(gdm:session): session opened for user <USER> by (uid=0) Sep 16 15:57:14 <NFS_CLIENT> sudo: pam_unix(sudo:auth): authentication failure; logname= uid=0 euid=0 tty= ruser= rhost= user=<USER> Sep 16 15:57:14 <NFS_CLIENT> sudo: pam_krb5[7339]: authentication fails for '<USER>' (<USER>@<DOMAIN>): Authentication failure (Decrypt integrity check failed)
Strange files under /home/$USER: ---xrw--wT 1 <USER> <USER> 0 Jan 17 2038 SskWxq ---------- 1 <USER> <USER> 0 Jan 17 2038 .xsession-errors
The following user processes are running on login error: startkde ssh-agent dbus-launch dbus-daemon kdeinit dcopserver klauncher kded kcminit_startup kwrapper ksmserver
regards Olaf
On 09/16/2009 09:42 AM, Olaf Mueller wrote:
Olaf Mueller wrote:
since kernel 2.6.18-164.el5 no user could login any more from nfs client into his home directory
Now reported on CentOS Bug Tracker #0003840.
This is one of the reasons we are hesitant to release JUST the security updates and not all of 5.4 at once.
Try this kernel again after we release the entire tree (and all the other 5.4 updates are applied).
It is possible that the new kernel needs a newer library than the 5.3 for that lookup.
If it does not work after the full 5.4 tree is installed, then we can troubleshoot further.
Olaf - Are you on the QA team ... if not, do you want to be :D (the tree will be available there before it is released).
Johnny Hughes wrote:
Hello.
On 09/16/2009 09:42 AM, Olaf Mueller wrote:
Now reported on CentOS Bug Tracker #0003840.
This is one of the reasons we are hesitant to release JUST the security updates and not all of 5.4 at once. Try this kernel again after we release the entire tree (and all the other 5.4 updates are applied).
Ok, thank you for your explanation. Also I was a bit surprised by this kernel cause it seems to me the same kernel like the kernel under /dzickus/el5/164.el5/. There is also a kernel 2.6.18-165.el5. Would it be a help if I test this kernel?
Olaf - Are you on the QA team ... if not, do you want to be :D (the tree will be available there before it is released).
I am not in the QA team and it would be a great pleasure for me to be on the team, thank you very much.
regards Olaf
Olaf Mueller wrote:
Olaf Mueller wrote:
since kernel 2.6.18-164.el5 no user could login any more from nfs client into his home directory
Now reported on CentOS Bug Tracker #0003840.
Here are some more information and a workaround.
This is a know major flaw as reported on https://bugzilla.redhat.com/show_bug.cgi?id=522163. Since the previous kernel 2.6.18-128.7.1.el5 is not up to date with security fixes and the current kernel 2.6.18-164.el5 isn't usable as a nfs server, I have installed kernel 2.6.18-165.el5.jtltest.87, you will find it in the bug report, as a workaround. This is not optimal cause I think this is a testing kernel for RHEL 5.5 (not 5.4!), but it seems to me the best choice as a kernel under CentOS 5.3 at the moment if you are running an nfs server. And only the nfs server needs this kernel to work, the clients can stay with the current kernel 2.6.18-164.el5.
regards Olaf
Olaf Mueller wrote:
Olaf Mueller wrote:
Olaf Mueller wrote:
since kernel 2.6.18-164.el5 no user could login any more from nfs client into his home directory
Now reported on CentOS Bug Tracker #0003840.
Here are some more information and a workaround.
This is a know major flaw as reported on https://bugzilla.redhat.com/show_bug.cgi?id=522163. Since the previous kernel 2.6.18-128.7.1.el5 is not up to date with security fixes and the current kernel 2.6.18-164.el5 isn't usable as a nfs server, I have installed kernel 2.6.18-165.el5.jtltest.87, you will find it in the bug report, as a workaround. This is not optimal cause I think this is a testing kernel for RHEL 5.5 (not 5.4!), but it seems to me the best choice as a kernel under CentOS 5.3 at the moment if you are running an nfs server. And only the nfs server needs this kernel to work, the clients can stay with the current kernel 2.6.18-164.el5.
regards Olaf
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Am I missing something here? We use and love CentOS for its stability and the fact(?) that the upstream provider does extensive QA(?) Now we have a major regression in the 5.4 kernel and the proposal in the bug fix is wait until 5.5 for the patch? or do it yourself - something I do not look forward to doing. Is someone dropping the ball or am I over-reacting? Rob
Rob Kampen wrote:
Olaf Mueller wrote:
Olaf Mueller wrote:
Olaf Mueller wrote:
I think this is a testing kernel for RHEL 5.5 (not 5.4!), but it seems to me the best choice as a kernel under CentOS 5.3 at the moment if you are running an nfs server. And only the nfs server needs this kernel to work, the clients can stay with the current kernel 2.6.18-164.el5.
Am I missing something here? We use and love CentOS for its stability and the fact(?) that the upstream provider does extensive QA(?) Now we have a major regression in the 5.4 kernel and the proposal in the bug fix is wait until 5.5 for the patch? or do it yourself - something I do not look forward to doing. Is someone dropping the ball or am I over-reacting?
This is a very unlucky situation, yes. But in my opinion, it is not a CentOS problem. We are only suffering under the missing of a nfs working kernel from RedHat. CentOS is based on RHEL that itself has no better kernel at the moment. But I must confess that I am astounded about this all.
regards Olaf
Olaf Mueller wrote:
This is a very unlucky situation, yes. But in my opinion, it is not a CentOS problem. We are only suffering under the missing of a nfs working kernel from RedHat. CentOS is based on RHEL that itself has no better kernel at the moment. But I must confess that I am astounded about this all.
From the looks of the bug it seems specific to NFSv4 or is it
NFS in general?
Can't imagine using NFSv4 myself, so I imagine it probably doesn't impact many users. At least it's easy to roll back to an earlier kernel!
nate
Hi,
On Thu, Sep 17, 2009 at 13:09, nate centos@linuxpowered.net wrote:
At least it's easy to roll back to an earlier kernel!
Yeah, if you can afford to live with unpatched security issues... But then, what is really the point of using an enterprise linux distro?
Filipe
Filipe Brandenburger wrote:
Hi,
On Thu, Sep 17, 2009 at 13:09, nate centos@linuxpowered.net wrote:
At least it's easy to roll back to an earlier kernel!
Yeah, if you can afford to live with unpatched security issues... But then, what is really the point of using an enterprise linux distro?
For me mostly stability. I have roughly 75 older systems that are still running RHEL 4.0 Update 1(used to be over 400, slowly widdling that number down).
In my case at least we can afford to live with unpatched security issues for a time, as the environment around the systems protects them for the most part. Also quite a few windows 2000 boxes still around many of which haven't had updates in eons.
It was just last month that we got rid of what I think was the last RHEL 3.0 Update 3 systems that we had, looks like they probably weren't updated since they got installed in 2004...oh wait now that I look there is 1 more..
For us, an up-to-date CentOS 5.2(last updated shortly before 5.3 was released) is bleeding edge!
nate
On 09/17/2009 03:28 PM, Olaf Mueller wrote:
This is a know major flaw as reported on https://bugzilla.redhat.com/show_bug.cgi?id=522163. Since the previous kernel 2.6.18-128.7.1.el5 is not up to date with security fixes and the current kernel 2.6.18-164.el5 isn't usable as a nfs server,
Olaf,
Thanks for (a) finding it (b) suffering with it and (c) talking about it. Could you make a note to check that when we release 5.4, these details are mentioned in the Release Notes in the known issues section ?
Thanks
-
Filipe Brandenburger -
Johnny Hughes -
Karanbir Singh -
nate -
Olaf Mueller -
Rob Kampen