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 and 10002). > > 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 [email protected] http://list.linux-vserver.org/mailman/listinfo/vserver
