Don't do NFS localhost mounts from fstab eg localhost:/origdir /newdir nfs ro 0 0
(Indeed, don't do localhost NFS mounts at all).
Why? Because at shutdown time nfsd is terminated before the unmounting, so the shutdown hangs trying to access NFS server localhost. And at boot time it tries to do NFS mounts before nfsd starts up.
_sigh_
On Mon, May 17, 2010 at 04:04:45PM -0400, Phil Schaffner wrote:
Stephen Harris wrote on 05/17/2010 12:15 PM:
Don't do NFS localhost mounts from fstab
Why would you want to do localhost: NFS mounts anyway?
'cos the current kernel doesn't allow read-only bind mounts and I need to present information in a locked down read-only area.
(need to test if the latest kernel has the patch backported; previous one didn't)
On Mon, 17 May 2010, Stephen Harris wrote:
On Mon, May 17, 2010 at 04:04:45PM -0400, Phil Schaffner wrote:
Stephen Harris wrote on 05/17/2010 12:15 PM:
Don't do NFS localhost mounts from fstab
Why would you want to do localhost: NFS mounts anyway?
'cos the current kernel doesn't allow read-only bind mounts and I need to present information in a locked down read-only area.
+1. On one server, we provide a read-write CVS tree accessible to developers -- but we nfs-mount a read-only view of the same filesystem into the cvsd chroot environment for anonymous users. If cvsd is found to have a vulnerability, the chroot and nfs layers are likely to limit the damage.
On Mon, 17 May 2010, Phil Schaffner wrote:
Stephen Harris wrote on 05/17/2010 12:15 PM:
Don't do NFS localhost mounts from fstab
Why would you want to do localhost: NFS mounts anyway?
Perhaps for a restricted 'regrafting' RO overmount down in a autobuilder's chroot tree, rather than a 'bind' mount ? I can see some rare uses for it as a way to solve ACL problems
-- Russ herrold
On May 17, 2010, at 5:37 PM, R P Herrold herrold@centos.org wrote:
On Mon, 17 May 2010, Phil Schaffner wrote:
Stephen Harris wrote on 05/17/2010 12:15 PM:
Don't do NFS localhost mounts from fstab
Why would you want to do localhost: NFS mounts anyway?
Perhaps for a restricted 'regrafting' RO overmount down in a autobuilder's chroot tree, rather than a 'bind' mount ? I can see some rare uses for it as a way to solve ACL problems
Since these are RO to local system why not mount them "soft,intr"?
Or you could use automount.
-Ross
On Mon, May 17, 2010 at 06:41:40PM -0400, Ross Walker wrote:
On May 17, 2010, at 5:37 PM, R P Herrold herrold@centos.org wrote:
On Mon, 17 May 2010, Phil Schaffner wrote:
Stephen Harris wrote on 05/17/2010 12:15 PM:
Don't do NFS localhost mounts from fstab
Why would you want to do localhost: NFS mounts anyway?
Perhaps for a restricted 'regrafting' RO overmount down in a autobuilder's chroot tree, rather than a 'bind' mount ? I can see some rare uses for it as a way to solve ACL problems
Since these are RO to local system why not mount them "soft,intr"?
Or you could use automount.
I didn't realize you couldn't do bind mounts read-only. Interesting.
What about re-mounting the same block device (presumably as ext3) in ro mode at another mountpoint?
Or if that complained, maybe created an additional block device under /dev with identical major/minor numbers and mounting *that* RO?
Maybe ext3 wouldn't handle that too well...
Ray
On May 17, 2010, at 6:44 PM, Ray Van Dolson rayvd@bludgeon.org wrote:
On Mon, May 17, 2010 at 06:41:40PM -0400, Ross Walker wrote:
On May 17, 2010, at 5:37 PM, R P Herrold herrold@centos.org wrote:
On Mon, 17 May 2010, Phil Schaffner wrote:
Stephen Harris wrote on 05/17/2010 12:15 PM:
Don't do NFS localhost mounts from fstab
Why would you want to do localhost: NFS mounts anyway?
Perhaps for a restricted 'regrafting' RO overmount down in a autobuilder's chroot tree, rather than a 'bind' mount ? I can see some rare uses for it as a way to solve ACL problems
Since these are RO to local system why not mount them "soft,intr"?
Or you could use automount.
I didn't realize you couldn't do bind mounts read-only. Interesting.
What about re-mounting the same block device (presumably as ext3) in ro mode at another mountpoint?
Or if that complained, maybe created an additional block device under /dev with identical major/minor numbers and mounting *that* RO?
Maybe ext3 wouldn't handle that too well...
Do not try that, at best it will give you inconsistent views of the file system, at worse it will scramble your file system.
-Ross
On Mon, May 17, 2010 at 06:49:20PM -0400, Ross Walker wrote:
On May 17, 2010, at 6:44 PM, Ray Van Dolson rayvd@bludgeon.org wrote:
On Mon, May 17, 2010 at 06:41:40PM -0400, Ross Walker wrote:
On May 17, 2010, at 5:37 PM, R P Herrold herrold@centos.org wrote:
On Mon, 17 May 2010, Phil Schaffner wrote:
Stephen Harris wrote on 05/17/2010 12:15 PM:
Don't do NFS localhost mounts from fstab
Why would you want to do localhost: NFS mounts anyway?
Perhaps for a restricted 'regrafting' RO overmount down in a autobuilder's chroot tree, rather than a 'bind' mount ? I can see some rare uses for it as a way to solve ACL problems
Since these are RO to local system why not mount them "soft,intr"?
Or you could use automount.
I didn't realize you couldn't do bind mounts read-only. Interesting.
What about re-mounting the same block device (presumably as ext3) in ro mode at another mountpoint?
Or if that complained, maybe created an additional block device under /dev with identical major/minor numbers and mounting *that* RO?
Maybe ext3 wouldn't handle that too well...
Do not try that, at best it will give you inconsistent views of the file system, at worse it will scramble your file system.
-Ross
I would like to try it, but definitely do not try it on data you can't afford to lose. :)
I was trying to set the default desktop environment using /etc/sysconfig/desktop. Originally, there was no /etc/sysconfig/desktop.
I have discovered that if my home directory does NOT have a .dmrc file (i.e. If the account is brand new), then I get the following logged to the .xession-errors file in my home directory:
/etc/gdm/PreSession/Default: Registering your session with utmp /etc/gdm/PreSession/Default: running: /usr/bin/sessreg -a -u /var/run/utmp -x "/ var/gdm/:0.Xservers" -h "" -l ":0" "mvanhorn" localuser:mvanhorn being added to access control list No profile for user 'mvanhorn' found stty: standard input: Inappropriate ioctl for device
However, if I create a .dmrc file in my home directory, and it contains either
[Desktop] Session=gnome
or
[Desktop] Session=kde
everything works fine.
So, what seems to be happening is that when the system needs to function without a .dmrc file, it creates a new one (in my home directory which contains)
[Desktop] Session=default
but then the above error happens and it goes back to the login screen.
There doesn't seem to be any permission problem involved, and it's not logging any error about not being able to write to ~/.dmrc. However, I can't figure out why it needs to have a preexisting .dmrc file (which seems to go against the idea of the /etc/sysconfig/desktop file).
Any insight or help is greatly appreciated.
Thanks!
--- Mike VanHorn Senior Computer Systems Administrator College of Engineering and Computer Science Wright State University 265 Russ Engineering Center 937-775-5157 michael.vanhorn@wright.edu RSS: http://www.engineering.wright.edu/~mvanhorn/MikeVanHorn%27sNewsFeed.xml http://www.engineering.wright.edu/~mvanhorn/
On 05/17/2010 03:44 PM, Ray Van Dolson wrote:
What about re-mounting the same block device (presumably as ext3) in ro mode at another mountpoint?
Or if that complained, maybe created an additional block device under /dev with identical major/minor numbers and mounting *that* RO?
Maybe ext3 wouldn't handle that too well...
I'm reasonably certain that in the former case "mount" will refuse to mount the device twice, and in the latter case the kernel will report that the filesystem was not unmounted properly and refuse to mount the FS until it has been.
Even if mount and the kernel allowed you to do this, at some point the kernel could potentially read inconsistent data from the device and crash. You'd never want to do this.