[OpenAFS] Creating a partial sandbox of the production Cell & krb5 realm

[Marcus Watts]

Jason Edgecombe <jason@rampaginggeek.com> writes
> Date:    Sun, 11 Nov 2012 18:11:42 EST
> To:      openafs-info@openafs.org
> From:    Jason Edgecombe <jason@rampaginggeek.com>
> Subject: [OpenAFS] Creating a partial sandbox of the production Cell & krb5 rea
>      ***lm
> 
> Hi everyone,
> 
> We're working on migrating our account creation process and oracle 
> server from Solaris 9 (Oracle 9) to RHEL5 (Oracle 11). To do more 
> testing, I have been asked to create a new AFS cell and krb5 realm that 
> is a sandbox of production, including having the same realm/cell names 
> as production. I plan to mirror just enough volumes to do the testing. 
> The same name is wanted to avoid tweaking the account generation scripts.
> 
> To make the sandbox, I would like to copy the existing krb5 and PTS 
> DB's. Besides the Keyfile and CellservDB, what other Kerberos/AFs keys 
> must be changed to prevent the sandbox from accidentally affecting 
> production via AFS/KRB commands?
> 
> I plan to selectively "vos dump" some production volumes and "vos 
> restore" them on the test cell.
> 
> I would appreciate any other tips that anyone has.
> 
> BTW, I proposed using a differently/named test cell/realm and was shot down.
> 
> Sincerely,
> Jason
> _______________________________________________
> OpenAFS-info mailing list
> OpenAFS-info@openafs.org
> https://lists.openafs.org/mailman/listinfo/openafs-info

Naming things the same is going to require great care to manage
and use.  You're going to have great difficulty using the same
clients & end-user machines to manage your test infrastructure,
and you'll probably wind up having to duplicate all that as well.
You *might* be able to manage using a different cell name on
some of your client machines, and you might be able to do some
even more horrible hacks with your kerberos realm, but it's
going to be complicated and confusing to make this work right.

I've setup and managed various test and sandbox environments
for years - and haven't found naming things differently to be
a problem.  It does mean being a bit more organized about installing
and configuration software, ie, having a repeatable documented process
for this.  In particular, it means you can't get away with just
"tweaking things by hand until they work" when installing or
upgrading stuff.  But if you're doing that, you don't need a test
environment in the first place.  Another advantage of making
cell names and such configurable is you can share your scripts
and software with other sites.

One random trick that ought to eliminate much of your cell/realm
configuration - use the "default" k5 realm & Thiscell wherever possible...

Taking the other tack,
I've never tried this, but think it might be interesting:
set up a virtual environment where *everything* is the same
as your production environment.  ip addresses, cell & realm names,
file structure, everything.  The advantage of this is you can clone
things from your production environment to testing - and to a lesser
extent you could also go backwards.  The disadvantage of this is of
course you're going to have to duplicate everything in a
carefully confined piece of network space.

				-Marcus Watts