[OpenAFS] Re: Moving Magic Trio to another domain

[Jukka Tuominen]

> On Mon, 23 Sep 2013 09:08:35 +0300 (EEST)
> "Jukka Tuominen" <jukka.tuominen@finndesign.fi> wrote:
>
>> > 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.
>>
>> So, MIT kerberos is used, but generating new passwords is certainly
>> doable if the homedirs on afs can still be saved.
>
> If you can regenerate all of the keys/passwords, then it sounds like you
> can just create a new realm from scratch. Just destroy the data from the
> old realm and set up a new realm, as if you were setting it up for the
> first time, and create all of the principals that existed in the
> original realm.

I first tried to dpkg-reconfigure krb server packages so I could introduce
the new domain, but it persisted to use the old domain without asking a
thing, so I manually replaced all old domains in the .conf with the new
one. I was then able to create the new realm.

How do I destroy the old realm data?

>
> If you want a migration period where the old and new realm are both
> available, I _think_ you can run multiple realms from the same kdc, but
> it takes some additional configuration.
>
>> > 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.

I was able to add the new cell princ key, but not the server princ key, as
it returned

"cannot specify keysaltlist when not changing key" when given the command

kadmin.local:  ktadd -k /tmp/afs.keytab -norandkey -e des-cbc-crc:normal
afs/[server.name]. But that was my earlier attempt (see a few lines below
what I did), so it may be different when I follow your suggestions more
closely...

>>
>> So, IIUC the homedirs aren't actually moved, they only get new
>> reference points (or something)?
>
> Well yes, they aren't moving; you said the server isn't changing, right?
> There's nowhere to be moving to :)
>
> You just add the new.example.com cell to CellServDB (or AFSDB/SRV DNS,
> or whatever), and then you access someone's home directory via e.g.:
>
> /afs/new.example.com/user/foo
>
> instead of:
>
> /afs/old.example.com/user/foo

I renamed the old /vicepa and was going to create a new one, but I quess I
shouldn't have done that but used the existing one as is? Luckily I can
easily restore an earlier snapshot and try it the other way.

>
> If you do not restart the client, you'll need to add the new cell
> information with 'fs newcell'. If you are not using dynroot, you'll also
> need to add the new.example.com mountpoint to root.afs, like you did for
> the original cell setup.
>
> So, more generally, just treat it as a new cell, which happens to
> contain the data you want in it.
>
>> I duplicated a client and updated all its server pointers, including
>> ldap.  I suppose the new kerberos key needs to be added to the keytab,
>> as well?
>
> To the OpenAFS rxkad.keytab/KeyFile? Yes, you need to generate a new key
> for a new principal with the new cell name in it. The old principal was
> presumably called afs/old.example.com@OLD.EXAMPLE.COM, and you need to
> create a new one called afs/new.example.com@NEW.EXAMPLE.COM, and add it
> to rxkad.keytab or KeyFile, according to the normal instructions. Just
> make sure that the kvnos for the 'old' and 'new' principals are
> different, if you want to use both of them at the same time (for a
> migration period).

Not quite there yet, but will do so. Thanks, again.

br, jukka

>
> --
> Andrew Deason
> adeason@sinenomine.net
>
> _______________________________________________
> OpenAFS-info mailing list
> OpenAFS-info@openafs.org
> https://lists.openafs.org/mailman/listinfo/openafs-info
>