[33473] in Kerberos
Re: Migrating to new hardware - best practises?
daemon@ATHENA.MIT.EDU (Richard E. Silverman)
Mon Jun 13 15:34:17 2011
From: res@qoxp.net (Richard E. Silverman)
Message-ID: <m24o3w27d6.fsf@darwin.oankali.net>
MIME-Version: 1.0
X-Complaints-To: abuse@thundernews.com
Date: Sat, 11 Jun 2011 02:46:13 -0400
To: kerberos@mit.edu
Content-Type: text/plain; charset="utf-8"
Errors-To: kerberos-bounces@mit.edu
Content-Transfer-Encoding: 8bit
Bjørn Tore Sund <bjorn.sund@adm.uib.no> writes:
> Hi,>> We have been running our KDCs on a dual Sun Solaris 10 setup for five> years, currently at MIT Kerberos 1.6. The hardware is out of support, Sun> Solaris is going away by local policy and so we need to migrate to a dual> RHEL 6 setup with whatever version of MIT Kerberos is current from rpms on> that platform - currently 1.8.2.>> After googling for a while I thought I'd ask here - is there a best> practices document we can use to plan the procedure?
One suggestion: if you're using file-based storage for the principaldatabase, do a dump and reload rather than try to copy the binary filesover; they will likely not be compatible. On the old host:
# dump the database to the file kerberos.db#$ sudo kdb5_util -r REALM dump kerberos.db
... and on the new host:
# initialize a new database#$ sudo kdb5_util -r REALM create -s
# and load your principal data into it#$ sudo kdb5_util -r REALM load kerberos.db
Also, a warning: there is a bug in 1.8 which sometimes preventsauthentication from Unix clients to Windows-based services when theservice ticket employs an RC4 session key. The bug was not present in1.6.3, and disappeared with 1.9.1. I downgraded from 1.8 to 1.6.3 tobuy myself time until I had a chance to debug it, but 1.9.1 came outfirst, so I never did track it down.
-- Richard Silverman res@qoxp.net________________________________________________Kerberos mailing list Kerberos@mit.eduhttps://mailman.mit.edu/mailman/listinfo/kerberos
