On Mon, Jan 19, 2009 at 1:33 PM, Chaz Chandler <[email protected]> wrote: > Thanks for everyone's replies! > > So far, in summary: > 1) There should be a separate cell at each site. This avoids quorum and and > local client server selection difficulties that arise in a VPN environment. > 2) There is no good AFS-based solution for group shares in this scenario.
i don't agree with that, but it depends on your interpretation. > 3) All volumes that need to be read from or written to at LAN speeds at > multiple sites must be replicated via custom scripts. > 4) Disconnected operations would be nice, but are currently not implemented > at a level of completeness suitable for a production environment. Traveling > users will simply have to access AFS through the VPN and deal with the slow > speed! it's actively getting closer right now. you can thank Simon Wilkinson for that. > > Further questions: > a) What is the best way to replicate a volume across cells? > b) How would the presence of multiple cells effect the krb5 infrastructure > (currently: one realm, one cell, cell name = realm name = internal LAN domain > name)? it doesn't have to be. you can have many cells in a realm, for instance, the sipb.mit.edu, athena.mit.edu, etc cells in the ATHENA.MIT.EDU realm. > c) Are any of the Morgan Stanley volume management system utilities available > publicly, or are their methods sufficiently documented publicly? All of what > I've read about them are from previous afsbpw's. (ie, > http://workshop.openafs.org/afsbpw08/talks/wed_1/OpenAFS_and_the_Dawn_of_a_New_Era.pdf) as far as i know none of their tools are distributed at this time. _______________________________________________ OpenAFS-info mailing list [email protected] https://lists.openafs.org/mailman/listinfo/openafs-info
