On Sun, Apr 18, 2010 at 9:49 PM, Marcus Watts <[email protected]> wrote: >> Date: Sun, 18 Apr 2010 12:30:38 +0200 >> To: [email protected] >> From: Mohammed Gamal <[email protected]> >> Subject: [OpenAFS-devel] Attempting to build a test environment. Help needed >> >> Hi, >> I am trying to build a test openafs environment for GSoC work. All I >> need is to setup a local cell with some volumes, my main problem is in >> the initial setup. I've cloned the source from the git repo and built >> them and tried to follow through the guidelines in the quick start >> guide, but I am a little bit lost as to what to do. >> >> Is there any standard scenario for setting up some simple test >> environment, or is some public environment available for this purpose? >> >> Regards, >> Mohammed > > I imagine anybody serious about afs development has a canned process > for making a test cell, but I notice nobody posted theirs. > > Bringing up a test cell is easy. Do not let anybody tell you it's hard > or not worth doing. You will learn so much more doing it that you cannot > afford to miss the opportunity. This is the difference between being > a half-assed developer, and a kick-ass developer. > > You need 2 machines: > > machine A > db server, fs server > machine B > test client > > Wimpy desktop dell workstations will work fine for both. > If you go that route, also get a better machine for builds. > > For machine A, a sample version of my notes are here: > /afs/umich.edu/user/m/d/mdw/wp/uniq.2m > > Since I mainly care about identity management, this is a bit weak on > volume setup. Since I haven't setup a cell recently enough, this also > describes use of "pt_util" to initialize prdb. You should use "pts > -localauth" if you can. Very old transarc notes talk about kaserver and > "bos setauth". Avoid any directions like that like the holy plague. > > For volume setup, I have better notes, > /afs/umich.edu/user/m/d/mdw/wp/hdserver.9 > To follow these notes, you need a working cell in which you can > make mount points. If you can't get writable space in somebody > else's cell, life gets a bit more interesting. My other notes > above talk about a "virgin.tgz" containing vos dumps - I'm not sure > where I saved the original, but I can easily make something similar > enough. > > For machine B, the test client, I don't think most people here bother > to keep useful notes. But yes, you need CellServDB, ThisCell, the > client side tools, the cache manager, and a suitable init script. > The cache manager needs to match your running kernel. CellServDB + ThisCell > identify where to mount root.afs from, and the rest follows from there. > > Some people here suggested use of an existing cell. If you do, > use their cell, do "vos listvldb" against it first thing, and once > you have it mounted, wander through their cell and ask them questions > about how it's all organized. Pay attention to where replication stops, > what acls exist where, how volumes are spread across servers, and so forth. > It's complicated, and everybody does this a bit different. If you want to > understand the use of vos, this is exactly the dirt you want. Since your > mentor will knows his cell best - that's why you should pick on him. :-) > > -Marcus Watts >
Thanks for your help. The problem was caused by a faulty installation. I managed now to get the client from the git source to successfully display the volumes on public cells. I'll still definitely try to setup my own cell, and follow Marcus's tips. Thank you all for your help and feedback. Regards, Mohammed _______________________________________________ OpenAFS-devel mailing list [email protected] https://lists.openafs.org/mailman/listinfo/openafs-devel
