From: Jan-Marc Pilawa (j.pilawa_at_tu-bs.de)
Date: Sun 09 Mar 2003 - 22:25:26 GMT
Zitat von Sam Vilain <sam_at_vilain.net>:
> Immutable Link Inversion [...]
> I assume, Jan-Marc, that you are thinking of using it more as a mechanism
> for sharing data partitions between different vservers - for instance, to
> share home directories across vservers like one would have done with
> NFS+automounter+NIS (my `upbringing' to Unix network transparency).
>
Hello Herbert, hello Sam. Yes, this is exactly what I want or better: tried with
some kind off success last night. The real good thing is, that users can for
example edit their websites on an AFS-enabled windows-machine with these
"clicky" kind of Programms while the webserver is using these files instantly.
No FTP, SCP and other Things the user hadnīt heard of. Since all home dir's are
in AFS our users are familiar with it.
[...]
>
> Did you try to get it running? Did you have any problems?
>
> One thing that is almost guaranteed to work, if you don't mind all
> AFS-enabled vservers on a system getting the same view of the AFS volume,
> would be to bind-mount the AFS mount point /afs into each of the vserver's
> space; ie
>
> mount --bind /afs /vservers/vs1/afs
>
> or you could restrict their view to a particular cell within the AFS tree;
> from the root server:
>
> mount --bind /afs/vs1_home /vservers/vs1/home
>
This is the way I set it up. Since AFS is managed via kernel-module, I saw no
quick solution for "AFS per vserver". I think AFS will not start in a vserver.
-But I have not really tried it: If the vserver-host is running an AFS-Client it
will surely complain about failed bind to some UDP-Ports. So I chose the "easy
way" with --bind and threw away the Idea to restrict access to parts of the
AFS-Tree from certain vservers by assigning an AFS-ID to vservers IPs, arrange
them to groups and setting ACLs. By mapping /afs/CellName via --bind to the
vservers all filesystem access to AFS will be managed by the vserver-host, not
the vservers.
So, after some playing around with it and some curious losses of tokens I have
some Ideas to experiment with it:
i) more playing with the tokens, might be there are things not running smoothly.
ii) obtain token for filesystem access right before starting a vserver, so the
token should/might survive in the vserver
ii) Clients running in a vserver, but not on the vserver-host
> As for actually putting an AFS server or client into a vserver, that would
> require testing to see whether the server can handle being `chbind'ed, the
> client can function without privileged kernel access and/or the kernel
> module doesn't make the assumption that one kernel space = one AFS tree.
>
> If you've been using AFS for a while, I'd be very interested in hearing
> your results - a distributed caching filesystem would certainly fill a gap
> in my plans to take over the world with vservers :-)
I will report on my experinences with AFS. As mentioned, sharing an AFS-Tree of
the vserver-host is working with the limitation, that all IO will be made from
the vserver-host and that might be important. Since I dont like to obtain tokens
for every vserver or application running in a vserver, AFS-Client per vserver
would be - yes: a step in the right way to take over the world with vservers ;-)
Best regards
Jan