Am 15.05.2013 20:19, schrieb Andrew Deason:
On Wed, 15 May 2013 09:40:50 +0200
Christian <[email protected]> wrote:
we plan to upgrade one of our dbservers (scientific linux 5.3) to
debian by rsyncing the installation of our other dbserver, which
already runs debian (both systems x64). WRT openafs, I think I need
to:
Do you mean "dbserver" as in, afs dbserver? That is, a machine running
ptserver, vlserver, etc.
Yes.
I'm not sure I'm completely clear on what you're doing. It sounds like
you're taking all of the openafs-related files from an existing openafs
dbserver, and just copying them all to the machine you're upgrading.
Wouldn't you rather just install openafs on the box, and copy over the
configuration bits that need copying?
I'm cloning the entire Debian installation from our second dbserver
machine, which already runs Debian, to the first one (which runs SL 5.3
right now) with rsync. Everything. Then I change the hostname,
/etc/network/interfaces, a couple of keytabs and ssl keys, and that will
be it. This works fine usually. The two dbservers are virtually
identical as far as their roles and configurations are conerned. The
result is a well-behaved debian system again. I'm trying to figure out
whether there are specific files I need to pay attention to as far as
cloning an afs dbserver installation to replace an existing installation
is concerned. Sorry if I was not clear on that. /vicep? partitions of
the old SL5.3 installation (on separate raid sets) will just be mounted
to the rsynced debian installation.
For a fileserver hosting volumes, the "proper" way to migrate it is to
bring up a new fileserver, and 'vos move' all of the volumes to it.
But that can take a lot of unnecessary time if you're not physically
moving the volume data. If you're reinstalling the OS, but keeping the
/vicep* partitions around (these are separate disks? or SAN or
something?), this is also possible. The conceptual fileserver
"identity" is kept in a file called /usr/afs/local/sysid (RHEL/SL) or
/var/lib/openafs/local/sysid (Debian). If you're destroying the old
fileserver installation, configuration, etc, you want to move that
file from the old (scientific linux) installation to the new (Debian)
installation.
Ah. OK. That answers my question, it seems.
Do NOT copy the 'sysid' file from the other existing Debian dbserver.
Or maybe to be more generally proper, don't copy the contents of
/usr/afs/local (or /var/lib/openafs/local) between server instances at
all. Just move the sysid file from the scientific linux server, and
create anew any required configuration in there. As you say, if you
use NetInfo/NetRestrict, you'll need those in there. And you can put a
BosConfig in there, though the more 'proper' way is to generate it
using commands like 'bos create'. For dbserver database files, you
shouldn't need to copy anything over. They will be synced from the
existing dbserver(s). It can be faster to copy them yourself, but just
not doing that can reduce steps.
OK. Great. Thanks for the info! Best,
Christian
_______________________________________________
OpenAFS-info mailing list
[email protected]
https://lists.openafs.org/mailman/listinfo/openafs-info
