> On Mon, 23 Sep 2013 09:08:35 +0300 (EEST) > "Jukka Tuominen" <jukka.tuomi...@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....@old.example.com, and you need to > create a new one called afs/new.example....@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 > adea...@sinenomine.net > > _______________________________________________ > OpenAFS-info mailing list > OpenAFS-info@openafs.org > https://lists.openafs.org/mailman/listinfo/openafs-info > _______________________________________________ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info