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. 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!
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)? 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) -Chaz > -----Original Message----- >>>> Something that might work out a little better is the work being done >>>> on disconnected operation. That might suffice for some of your use >>>> cases (assuming the timing of that finishing and the features it >>>> will >>>> offer is suitable for your needs). >>>> >>> >>> Is disconnected afs functional? I saw it as a GSoC '08 project but >>> the afsbpw08 presentation said it's only R/O. > > The BPW presentation predates the work that Dragos did as part of > Summer of Code. His project was very successful, and delivered a > working disconnected client implementation which is now in the 1.5.x > tree for testing. > >> I would not inflict it upon any of my power users or regular users. >> R/W >> does work, but rebooting will lose data and it doesn't work on >> windows, >> just Unix. Simon can tell you more. > > There's a couple of bits of major functionality missing, and some bugs > which still need to be ironed out. In the functionality stakes, we > currently don't preserve some important information when the machine > is rebooted, so you lose any changes made whilst disconnected if you > restart the machine without reconnecting. Less seriously, but still an > issue, is that there's no mechanism for telling the cache manager > which files you'd like to have available whilst disconnected. At > present, you need to explicitly access every file and directory you > require before disconnecting. > > We're also still in bug hunting mode. There are some bugs with the > disconnected implementation which are being found and fixed, and there > are some race conditions in the cache manager which are being exposed > by the differences in timing and serialisation when you are > disconnected. > > Cheers, > > Simon. ____________________________________________________________ Receive Notifications of Incoming Messages Easily monitor multiple email accounts & access them with a click. Visit http://www.inbox.com/notifier and check it out! _______________________________________________ OpenAFS-info mailing list [email protected] https://lists.openafs.org/mailman/listinfo/openafs-info
