[Vserver] EBUSY on rmdir of a previous mount point with namespaces

2004-10-28 Thread Sam Vilain
Found that tricky can't-remove-the-mount-point bug.
clunker:/vservers# mkdir compileit
clunker:/vservers# grep compileit /etc/fstab
/dev/clunker/compileit  /vservers/compileit ext3defaults 1 2
clunker:/vservers# mount compileit/
kclunker:/vservers# journald starting.  Commit interval 5 seconds
EXT3 FS on dm-1, internal journal
EXT3-fs: mounted filesystem with ordered data mode.
vserver bind start
Mounting shadow filesystems for bind
Starting system log daemon: syslogd.
Starting kernel log daemon: klogd.
Starting domain name service: named.
clunker:/vservers# vserver bind exec grep comp /proc/mounts
clunker:/vservers# grep comp /proc/mounts
/dev/clunker/compileit /vservers/compileit ext3 rw 0 0
clunker:/vservers# vserver bind exec cat /proc/mounts
clunker:/vservers# umount compileit
clunker:/vservers# rmdir compileit
rmdir: `compileit': Device or resource busy
clunker:/vservers# vserver bind stop
Sending all processes the TERM signal...done.
Sending all processes the KILL signal...done.
clunker:/vservers# rmdir compileit/
clunker:/vservers#
Look!  It works with tmpfs, too!
clunker:/vservers# mkdir foo
clunker:/vservers# mount -t tmpfs none foo
clunker:/vservers# vserver bind start
Mounting shadow filesystems for bind
Starting system log daemon: syslogd.
Starting kernel log daemon: klogd.
Starting domain name service: named.
clunker:/vservers# umount foo
clunker:/vservers# rmdir foo
rmdir: `foo': Device or resource busy
clunker:/vservers# vserver bind stop
Sending all processes the TERM signal...done.
Sending all processes the KILL signal...done.
clunker:/vservers# rmdir foo
clunker:/vservers#
This really shouldn't happen for mount points which are entirely outside
the chroot of the new namespace, but I think this may be another point
of our `chroot/pivot_root/vnamespace/mount --rbind/chcontext' chicken,
egg, rooster, barn and farmer problem.
For mount points which are *inside* the chroot, is this a bug or a
feature?  Is it possible to have a filesystem mounted on a path in one 
namespace, then remove the underlying directory?

Versions:
   Kernel: 2.6.9-final-vs1.9.3-rc3
   VS-API: 0x00010022
 util-vserver: 0.30.195; Oct 10 2004, 16:55:15
--
Sam Vilain, sam /\T vilain |T net, PGP key ID: 0x05B52F13
(include my PGP key ID in personal replies to avoid spam filtering)
___
Vserver mailing list
[EMAIL PROTECTED]
http://list.linux-vserver.org/mailman/listinfo/vserver


Re: [Vserver] Cannot set defaultroute under vserver

2004-10-28 Thread Sam Vilain
TK Lew wrote:
I have read the LARTC but until now I still cannot ping or get 
vapt-get  working.
You need to use SNAT;
I started the a vserver using eth1 and have a ppp0 connection to the internet.
Vserver IP : 192.168.100.200
This what i did using ip route ::
203.106.129.217 dev ppp0  proto kernel  scope link  src 210.195.72.82
Assuming your world IP address is 210.195.72.82, then you need to run a
command like this after your network is up:
iptables -t nat -A POSTROUTING -o ppp0 -j SNAT --to-source 210.195.72.82
Others have mentioned tools like fwbuilder and shorewall, which boil
down to issuing commands like the above as well as providing nicer
interfaces for doing all other things iptables.
--
Sam Vilain, sam /\T vilain |T net, PGP key ID: 0x05B52F13
(include my PGP key ID in personal replies to avoid spam filtering)
___
Vserver mailing list
[EMAIL PROTECTED]
http://list.linux-vserver.org/mailman/listinfo/vserver


Re: [Vserver] EBUSY on rmdir of a previous mount point with namespaces

2004-10-28 Thread Björn Steinbrink
On Fri, 29 Oct 2004 12:10:04 +1300
Sam Vilain [EMAIL PROTECTED] wrote:

 Found that tricky can't-remove-the-mount-point bug.
 
 clunker:/vservers# mkdir compileit
 clunker:/vservers# grep compileit /etc/fstab
 /dev/clunker/compileit  /vservers/compileit ext3defaults 1 2
 clunker:/vservers# mount compileit/
 kclunker:/vservers# journald starting.  Commit interval 5 seconds
 EXT3 FS on dm-1, internal journal
 EXT3-fs: mounted filesystem with ordered data mode.
 vserver bind start
 Mounting shadow filesystems for bind
 Starting system log daemon: syslogd.
 Starting kernel log daemon: klogd.
 Starting domain name service: named.
 clunker:/vservers# vserver bind exec grep comp /proc/mounts
 clunker:/vservers# grep comp /proc/mounts
 /dev/clunker/compileit /vservers/compileit ext3 rw 0 0
 clunker:/vservers# vserver bind exec cat /proc/mounts
 clunker:/vservers# umount compileit
 clunker:/vservers# rmdir compileit
 rmdir: `compileit': Device or resource busy
 clunker:/vservers# vserver bind stop
 Sending all processes the TERM signal...done.
 Sending all processes the KILL signal...done.
 clunker:/vservers# rmdir compileit/
 clunker:/vservers#
 
 Look!  It works with tmpfs, too!
 
 clunker:/vservers# mkdir foo
 clunker:/vservers# mount -t tmpfs none foo
 clunker:/vservers# vserver bind start
 Mounting shadow filesystems for bind
 Starting system log daemon: syslogd.
 Starting kernel log daemon: klogd.
 Starting domain name service: named.
 clunker:/vservers# umount foo
 clunker:/vservers# rmdir foo
 rmdir: `foo': Device or resource busy
 clunker:/vservers# vserver bind stop
 Sending all processes the TERM signal...done.
 Sending all processes the KILL signal...done.
 clunker:/vservers# rmdir foo
 clunker:/vservers#
 
 This really shouldn't happen for mount points which are entirely
 outside the chroot of the new namespace, but I think this may be
 another point of our `chroot/pivot_root/vnamespace/mount
 --rbind/chcontext' chicken, egg, rooster, barn and farmer problem.

Yes, you mounted something on 'foo' before starting the vserver, so that
mount will also be in the vserver's namespace (but of course you can't
reach it from inside the vserver because of the chroot). Once we're able
to cleanup the namespace, this problem will be gone.

 
 For mount points which are *inside* the chroot, is this a bug or a
 feature?  Is it possible to have a filesystem mounted on a path in one
 namespace, then remove the underlying directory?
 

AFAICT this is not possible. You share the actual filesystems between
the namespaces, so removing 'foo' in namespace A would also remove in
namespace B (just because you remove it from the filesystem, not from
the namespace). Now if in namespace B 'foo' is a mountpoint you would
have a hard time accessing the mounted filesystem. ;-) Therefore you
can't remove that directory.

HTH
Bjoern
___
Vserver mailing list
[EMAIL PROTECTED]
http://list.linux-vserver.org/mailman/listinfo/vserver