My first thoughts in doing this was to:
Stop the master server, all clients will then goto to the slave for
authentication.
Install the krb5 binaries, without configuring the new master.
Tar up the /var/krb5 and /etc/krb5 directories, then untar it onto the
new host.
Change the kdc and krb5 conf files with the new hostname. Start the
new master up
Would that work, or is there another sequence I should follow.
Thanks
Pete.
Ideally it should work. But I would suggest you to take dump of KDC database
and then move on to the new hardware.
- Sachin.
> ________________________________________________
> Kerberos mailing list Kerb...@mit.edu
> https://mailman.mit.edu/mailman/listinfo/kerberos
>
> ________________________________________________
> Kerberos mailing list Kerb...@mit.edu
> https://mailman.mit.edu/mailman/listinfo/kerberos
>
>
I have done this three times and this how I do it.
Build the new server and kerberos software. Harden it.
Grab a tar file of the principal db off of a slave server get the
krb5.conf file and requisite ketabs and put it in place.
Start it up - you should be able to kinit locally to it and do some
kadmin functions. This will not have any effect on your production
Realm (as long as you are not propagating to slaves from it)- make
certain you are kinit ing to the new machine by inspecting logs.
Once you are satisfied with the tests - schedule your down time bring
the main server down and move the princs over. Make sure you local
files (krb5.conf) are pointing to the right host and you should be ok.
I usually don't start kadmin right away so no one can reset their
passwords until I am sure that I am going to leave it up.
Actual down time is usually 30 minutes or less.
/sd
Steve Devine
Email & Storage
Academic Technology Services
Michigan State University
313 Computer Center
East Lansing, MI 48824-1042
1-517-432-7327
Everything that can be counted does not necessarily count;
everything that counts cannot necessarily be counted.
Albert Einstein