[OpenAFS] Re: dbserver, cloning

Christian chanlists@googlemail.com
Wed, 15 May 2013 21:51:41 +0200


Am 15.05.2013 20:19, schrieb Andrew Deason:
> On Wed, 15 May 2013 09:40:50 +0200
> Christian <chanlists@googlemail.com> 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