From: Stephen Harris (lists_at_spuddy.org)
Date: Sat 13 Aug 2005 - 02:03:39 BST
On Fri, Aug 12, 2005 at 01:55:30AM +0200, Herbert Poetzl wrote:
> On Thu, Aug 11, 2005 at 09:56:20AM -0400, Stephen Harris wrote:
> > [root]/home/sweh
> > backup.pts/2% mount -r backup:/RedHat/updates/core1 /vservers/webssh/RedHat
> no idea 'what' filesystem you did mount here, but to me
> it looks like a network filesystem (i.e. nfs)
Yes, it is. In fact it's an NFS mount from myself to myself; I can't use
bind mounts because I want the vservers to only have read-only access to
the filesystem, and bind mounts don't (or didn't, last time I tried) allow
changes in permissions between the original location and the bound location.
> > backup.pts/2% vserver webssh enter
> > SIOCSIFBRDADDR: Cannot assign requested address
> > SIOCSIFFLAGS: Cannot assign requested address
> this is a good sign of a broken config (network wise)
Network wise, it actually works. I had thought this had come from the guest
OS trying to do stuff, but I'm a vserver newbie. Hmm.
Ah... maybe it's because I'm using a 10.* address but have a 255.255.255.0
netmask; I left IPROOTMASK and IPROOTBCAST unset, so _maybe_ it's attempting
to calculate based on a 255.0.0.0 mask, and failing to set them. Hmm, no,
that's not it. I just tried.
Could this be ipv6, perhaps? I'm not using ipv6.
I had noticed that inside the vserver, an "ifconfig -a" shows _all_
the hosts IP addresses, and not just the one in the vserver.
But otherwise it all works.
> > ipv4root is now 10.0.0.2
This is the correct address.
> > New security context is 49173
> and just as sidenote, you should avoid dynamic context
> ids, unless you are looking for trouble :)
OK; I'm new vserver newbie and just took the defaults which said
# Select an unused context (this is optional)
# The default is to allocate a free context on the fly
# In general you don't need to force a context
but I'll take your advice and have assigned fixed contexts now (10001
> > bash: ulimit: core file size: cannot modify limit: Invalid argument
> this looks evem more like a debian^Wconfig issue, where
> you specified a limit (maybe -H or -S) without raising
> the proper other limit (specify -HS to solve that)
No, it appears to be from my .profile inside the guest. For historical
reasons I had "ulimit -Sc unlimited" for my own account, and this seems
to be read when entering the guest.
> this is a different IP than the one before, NFS isn't
> handled that well on 2.4, but of course, the guest
> will send requests with 10.0.0.3 now, which, in turn
> might lead to the Permission denied (if your server
> does not allow 10.0.0.3 to access the share)
The server allows the whole 10.0.0.* network (my home network).
Will the guest make a request? The guest hasn't actually made the mount;
the host has made the mount and has made it available to the guest.
So will the request come from the guest's IP address, or will it fall
through to the host, and the host make the request.
Ah, OK... some network snooping... the request comes from the guest
IP address. That's... broken! The mount came from the host IP address
but the nfs requests came from the guest IP adrress. Hmm.. I'm surprised
it ever worked!
OK, what's the best way of providing a filesystem to the guest with
read-only privs? Clearly NFS is a kludge.
Huh.. that's odd... I just shut down _all_ vservers and restarted them and now
the mount works in both vserver instances.... that seems like something
confused, but I can probably live with it; my mounts have so far worked.
But it does look like I need better solution; how to make a filesystem
available to a vserver with differnt permissions than the host has?
> hmm, and IDE hotswapping did work with 2.4 but does
> not with 2.6? interesting ...
Yeah, it's very annoying. Alan Cox has a lot to say about it!
rgds Stephen _______________________________________________ Vserver mailing list Vserver_at_list.linux-vserver.org http://list.linux-vserver.org/mailman/listinfo/vserver