Hello,
I'm about to setup a Linux based fileserver for home directories and a
couple of Linux clients with kerberos and NFS4 (no NFS3 for security
reasons).
The whole stuff is currently based on debian stable (with a backported
current NFS userland 1.2.5) and a recent vanilla kernel (3.5.2).
So far I have the NFS4 Server up and running as well as a couple of clients
with NFS4+autofs mounted home directories.
All this stuff mostly works now, but unfortunately I ran into some strange
bahaviour now.
When I ssh from one machine to another the system hangs (a delay of up to 60
seconds) while running xauth.
Replacing xauth by a wrapper script I have been able to trace this behaviour
to a hang of an unlink("/home/<user>/.Xauthority") system call.
So the question is what cases hangs in NFS4 based Linux systems in general
an in this particular case?
Any hint on how to debug this?
Sven
--
"C Is Quirky, Flawed, And An Enormous Success."
(Dennis M. Ritchie)
/me is giggls@ircnet, http://sven.gegg.us/ on the Web
> Sven Geggus wrote:
>
> Jim Rees <[email protected]> wrote:
>
> > No, the question is why did X put that file in your home directory. That's
> > not where it belongs. I've got this in my .xinitrc:
> >
> > setenv XAUTHORITY /tmp/Xauthority`id -u`
>
> I agree, that ~/.Xauthority is probably not the best place for this file,
> but it is the default (at least in Debian).
>
> If it is expected behaviour that this will not work correctly with shared
> Homedirectories, I wonder why this did not cause me any trouble with NFS3
> for many years.
NFS3 doesn't have delegations and this file placement should not be an
issue in NFSv4 either if it is working correctly!
Regards, Malahal.
Malahal Naineni wrote:
NFS3 doesn't have delegations and this file placement should not be an
issue in NFSv4 either if it is working correctly!
Xauthority doesn't belong in $HOME, it belongs on the local disk. That has
nothing to do with NFS v3/v4. It has to do with limiting distribution and
exposure of sensitive information.
Sven Geggus wrote:
Jim Rees <[email protected]> wrote:
> No, the question is why did X put that file in your home directory. That's
> not where it belongs. I've got this in my .xinitrc:
>
> setenv XAUTHORITY /tmp/Xauthority`id -u`
I agree, that ~/.Xauthority is probably not the best place for this file,
but it is the default (at least in Debian).
If it is expected behaviour that this will not work correctly with shared
Homedirectories, I wonder why this did not cause me any trouble with NFS3
for many years.
Are you sure it didn't cause you any trouble? You were giving root access
to anyone who could snoop the Xauthority file off the wire. That's the main
reason you don't want it in your home dir. As to why that's still the
default, laziness I guess.
Anyway I did not yet figure out how to globally change the XAUTHORITY
Variable in kdm and ssh :(
I don't use kdm. For ssh:
% cat ~/.ssh/environment
XAUTHORITY=/tmp/Xauthority1234
You might also have to fix /etc/ssh/sshd_config.
Sven Geggus wrote:
Hello,
I'm about to setup a Linux based fileserver for home directories and a
couple of Linux clients with kerberos and NFS4 (no NFS3 for security
reasons).
The whole stuff is currently based on debian stable (with a backported
current NFS userland 1.2.5) and a recent vanilla kernel (3.5.2).
So far I have the NFS4 Server up and running as well as a couple of clients
with NFS4+autofs mounted home directories.
All this stuff mostly works now, but unfortunately I ran into some strange
bahaviour now.
When I ssh from one machine to another the system hangs (a delay of up to 60
seconds) while running xauth.
Replacing xauth by a wrapper script I have been able to trace this behaviour
to a hang of an unlink("/home/<user>/.Xauthority") system call.
So the question is what cases hangs in NFS4 based Linux systems in general
an in this particular case?
No, the question is why did X put that file in your home directory. That's
not where it belongs. I've got this in my .xinitrc:
setenv XAUTHORITY /tmp/Xauthority`id -u`
On Tue, Aug 21, 2012 at 02:42:30PM -0400, Jim Rees wrote:
> Malahal Naineni wrote:
>
> NFS3 doesn't have delegations and this file placement should not be an
> issue in NFSv4 either if it is working correctly!
>
> Xauthority doesn't belong in $HOME, it belongs on the local disk. That has
> nothing to do with NFS v3/v4. It has to do with limiting distribution and
> exposure of sensitive information.
Yah. Unlinking a file shouldn't take a minute, though, so we do have a
bug, however it was found. Let me know if the patch I referred to fixes
it.
--b.
Jim Rees <[email protected]> wrote:
> No, the question is why did X put that file in your home directory. That's
> not where it belongs. I've got this in my .xinitrc:
>
> setenv XAUTHORITY /tmp/Xauthority`id -u`
I agree, that ~/.Xauthority is probably not the best place for this file,
but it is the default (at least in Debian).
If it is expected behaviour that this will not work correctly with shared
Homedirectories, I wonder why this did not cause me any trouble with NFS3
for many years.
Anyway I did not yet figure out how to globally change the XAUTHORITY
Variable in kdm and ssh :(
Sven
--
Microsoft ist offenbar die einzige Firma, die in der Lage ist, ein mit
Office nicht kompatibles Bürosoftwarepaket einzuführen.
(Florian Weimer in de.alt.sysadmin.recovery)
/me is giggls@ircnet, http://sven.gegg.us/ on the Web