[OpenAFS] Integrating previous volumes into new AFS installation

[Marcus Watts]

daniel@mri.ucsd.edu writes:
> From: daniel@mri.ucsd.edu
> To: openafs-info@openafs.org
> Subject: [OpenAFS] Integrating previous volumes into new AFS installation
> Date: Thu, 11 May 2006 19:48:46 -0700 (PDT)
> 
> I recently had a server hacked so I had to do a fresh reinstall of the OS.
> My afs volumes are still intact. I have my old KeyFile and old db files
> from my previous setup but am having problems getting my AFS server back
> up using my old files. Is there a way to do a fresh installation of AFS
> and bring back my old volumes using newly generated keys and db files?
> 
> Right now I have my .vol's mounted on vicep* and have installed the
> openafs-1.2.10, along with the kernel, and server, and am using my old
> KeyFile and db files. When I run /etc/init.d/ i get the following error:
> libafs-2.4.18-14-i386.mp.o
> Failed to load AFS client, not starting AFS services.
> 
> I'm kinda new to all those so if none of this makes sense let me know and
> I'll try to be a little more clear
...

You want to scrap and remake your keyfile, as was just recommended for
"Gabe Listaccount".  If your kdc (krb5kdc or kaserver) was on the same
machine, that's just the start of what you need to consider compromised
- *every* other principal in your kdb is also potentially compromised.

prdb does not contain secrets, nor does vldb, so you can reuse that no
problem.  Note that ptserver does not automatically make all things
visible, so be aware your vandal now knows even your hidden
associations.  It is harmless to rebuild vldb from scratch.  You almost
certainly don't want to rebuild prdb from scratch; if you do, figure
out how you're going to preserve viceids.

The volumes themselves do not contain any secrets or signatures.  You
should be able to continue to use them with no problems.  You may want
to consider doing backups and worrying about DRP; if you had been doing
this already you would have additional options now.

You probably want to run openafs-1.2.13 not 1.2.10.  There should
not be any problems just moving the data to the new version ( note
in theory, this is not totally guaranteed between any two versions
although in practice it nearly always works. )

The kernel extension you apparently built (libafs-2.4.18) isn't compatible
with your kernel.  Some part of your build or install process failed
to do the right thing.  Check timestamps on the kernel module and
on your kernel, and make sure one isn't old.  To build the kernel
extension, in general, you need to get kernel source & .config
for *exactly* the kernel that you plan to run, do at least "make config",
then point the AFS build process at the result.  In slightly more detail:
To just configure virgin kernel source:
	< put what you already used in .config >
	make oldconfig
	#(use this if I'm wrong in thinking you don't need this:)
	# make dep
(If you're using something like RH, beware; get their source
not that from kernel.org.)
To build just the openafs cache manager:
	configure --with-linux-kernel-headers=<your kernel> ...
	make SYS_NAME=i386_linux24 make dest_only_libafs
It is also a valid choice to build the kernel from scratch,
install that, then point openafs at that, build it all from scratch,
and run the result.  If you don't give the openafs configure
a pointer to the right linux kernel headers, it will probably pick the
kernel headers that were used to build libc, which probably does not
match the kernel you are running.  Some distributions have a separate
package you can install which contains the linux kernel headers
specifically for the corresponding bootable kernel that you
might run.

linux kernel version 2.4.18 sounds like really really old.
I don't need or want to know what you're running, but you may want
to investigate your distribution to see if what you've got is really
up to date on security patches or whether you should be running something
quite different.

				-Marcus