> Date: Sun, 18 Apr 2010 12:30:38 +0200
> To: openafs-devel@openafs.org
> From: Mohammed Gamal <m.gamal...@gmail.com>
> 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
_______________________________________________
OpenAFS-devel mailing list
OpenAFS-devel@openafs.org
https://lists.openafs.org/mailman/listinfo/openafs-devel
