On 05/17/2017 05:03 AM, Turbo Fredriksson wrote:
On 16 May 2017, at 20:23, Prentice Bisbal pbisbal@pppl.gov wrote:
I think many system admins would say just copy the schemas from the old server to the new server and forget about it, but I don't think this is a good approach.
That’s what I do. I agree, on a theoretical level, that that might not be the best way to do it, but it sure is the simplest :). I have way to much to do anyway, so if I can take the easy way for once, I’ll take it.
The way I look at it, it's better to address this problem head-on and fix it now (if it in fact needs fixing), than wait until my schemas are so old that when I upgrade my directory clients something breaks because my schemas are old and obsolete that they're no longer compatible with the client applications like SSSD, etc. In that scenario, I see bosses and users screaming at me, asking why the upgrade lead to problems...
Although to be honest, I don't think schemas really change very often.
As far as other applications using LDAP and any attribute in there, they are (should be!) configurable. For example, LibNSS-LDAP and LibPAM-LDAP all let you configure what attributes to use for what..
Very true, but I'd rather fix the schema in one place, rather than fix all my applications, which could have config files with various syntaxes all over /etc.
I’m sure there’s a reason for changing 'krbPrincipal' to ‘krbPrincipalAux’, but personally I don’t care. The former works for me.
I think Ryan Tandy nailed it - one's for Heimdal Kerberos, the other is for MIT kerberos. I need to dig into this further to confirm for myself, though,
- Who/what is the authoritative source for current schema definitions? Are they all defined in RFCs?
Probably not all. MINE isn’t. But I do have a registered IANA, so from the schemas attribute or objectless OID, it should be “reasonably” easy to match the two and find out who wrote it and from there you might be able to get a later version.