Well, I’ve begun the migration and probably picked the hardest machine to start with. One of my goals here was to do a clean migration from a Red Hat Enterprise Linux 5 box to a Red Hat Enterprise Linux 6 box for a specific set of services, and to intentionally have SELinux in enforcing mode (I’m determined to no longer be intimidated by SELinux). The machine in question is probably one of the most important in my home network: it handles DHCP, DNS, LDAP, and Kerberos for authentication.
RHEL6 is amazing, but the migration was.. painful. But I take full responsibility for that pain… if I had read the migration guide (or even pertinent parts of it), I could have saved myself two long nights. Oh well, live and learn. The other goal was to not copy any existing configs over, but to re-edit new configs (some of these configs hail from Annvix, some from Mandriva Corporate Server… it was due a cleaning and updating).
DNS was easy enough, and DHCP was a piece of cake. Kerberos was pretty good, but moving from Kerberos 1.6 to 1.8 had one interesting gotchya. I had to work around Kerberized NFS previously due to a 1.8-based client talking to a 1.6-based server and it seems that a similar work-around was required for the server (note this is the KDC, it doesn’t export anything for NFS). I needed to add to /etc/krb5.conf in the [libdefaults] section, the following:
# for NFS allow_weak_crypto = true default_tgs_enctypes = des-cbc-crc default_tkt_enctypes = des-cbc-crc
Once that was done, Kerberos worked just as well as before and, more importantly, I wasn’t seeing any problems in my krb5kdc.log when my Fedora 14 box was trying to get a ticket. For Google’s sake, the log entry looked like this:
Feb 23 17:33:20 kerberos.example.com krb5kdc[1679](info): TGS_REQ
(7 etypes {18 17 16 23 3 1 2}) 192.168.250.52: BAD_ENCRYPTION_TYPE:
authtime 0, [email protected] for nfs/[email protected],
KDC has no support for encryption type
LDAP was a severe PITA for me though. There were a few challenges. For one, it completely ignores /etc/openldap/slapd.conf now. If I would have read the Red Hat Enterprise Linux 6 Migration Planning Guide I would have known this. Sadly I chased my tail for two nights trying to figure out why TLS wasn’t working at all (I could do an ldapsearch against the directory with -Z, but tossing in -ZZ always crapped out). Eventually, I did get it working once I realized what was going on. The big thing here is, if you have an existing slapd.conf you plan to migrate, you need to do:
# rm -rf /etc/openldap/slapd.d; mkdir /etc/openldap/slapd.d # slaptest -f /etc/openldap/slapd.conf -F /etc/openldap/slapd.d # chown -R ldap:ldap /etc/openldap/slapd.d/
You could remove the slapd.conf, but I since I find it nice and easy and comfortable, I’ve kept it (realizing that it’s a template only, of sorts). Also keep in mind that if your LDAP server is, for example, ldap.foo.com, you better darn well make sure the CN in the SSL certificate matches, or SSSD will be very unhappy with you. I didn’t realize this before (although before I don’t believe I had enabled TLS (primarily because SSSD doesn’t enforce TLS when doing NSS lookups, by the looks of things, but only when requesting authentication information (or sending it, as the case may be)). It doesn’t matter much to nss_ldap (where you can tell it to not use SSL/TLS), but it sure matters a lot to SSSD (which I didn’t pay much attention to before because kerberos is handling the auth, not LDAP). That drove me bonkers for a bit (SSSD, or whatever it’s talking to, needs to be a little more helpful the error messages!).
Other gotchyas were that only gpg2 is available now, which played havoc with my AIDE+gpg scripts. That was a simple fix, once I figured it out (the problem is that gpg-agent is pretty much mandatory, and pinentry doesn’t seem to work too well if you don’t have a GUI and are su -‘d to another user). Thankfully, I could work around this quite painlessly in my scripts.
All in all, it was a good brain flex. Frustrating as all get out, but now that it’s working, I’m happy. The next box is the internal intranet with kerberized apache, NFSv4 kerberized exports, nagios server, and internal subversion server. I think I’ll wait for the weekend on that one though. I don’t think it will be as painful as this box, but there will be a lot of SELinux policy tweaking on that one if I want to run it in enforcing mode. I’ve also been mucking with this since Saturday, and feel like doing something a little less taxing for the rest of my evening. =)