[OpenAFS] Re: Moving Magic Trio to another domain

[Andrew Deason]

On Sun, 22 Sep 2013 11:09:38 +0300 (EEST)
"Jukka Tuominen" <jukka.tuominen@finndesign.fi> wrote:

> I'm facing a major challenge. I'm trying to move a populated
> OpenAFS/Kerberos/OpenLDAP installation under another domain name. The
> IP address remains the same. Hopefully there is a way save the users,
> their passwords, accounts etc. The user accounts are on afs. The
> system can go offline, if necessary.

Do you mean you're using OpenLDAP as a kerberos backend, or just that
you're storing passwd/group information in ldap?

For Kerberos, if you're using about MIT or Heimdal, this may be
difficult, since usually the keys for user principals are all salted
with the realm name. In the past I believe doing this was considered
impossible to do with existing code, but maybe things have improved.
This is more appropriate for the relevant Kerberos list, but someone may
respond here further anyway.

AD I assume has an easier time with this, since it stores passwords and
not keys.

> Any suggestions how to best do this?

OpenAFS servers and such usually don't care much about the name of the
cell. You can generally just treat this as adding a new realm for the
cell (and later removing the old realm/cell, if you want to). This means
you generate a new kerberos principal for afs/newcell@NEWREALM, add it
to the KeyFile/rxkad.keytab, and add the new realm to openafs's
krb.conf. If you ever use the '-cell' option in any scripts or anything,
of course that would need to change. You may want to just take down all
of the servers, update ThisCell and CellServDB, and restart, but doing
that I don't think is strictly necessary.

For clients, just point them at the same servers with the new cell name.
So, update their client CellServDBs or your AFSDB/SRV records, etc. You
can point two different cell names at the same servers; clients don't
ever send the cell name when talking to afs servers; it's just used for
deciding which dbservers to contact and for acquiring/storing
credentials.

-- 
Andrew Deason
adeason@sinenomine.net