On LDAP objectClasses

Petter suggests to make the dhcpHost LDAP objectClass an auxiliary one, to make it possible to combine it with the dNSDomain objectClass in one and the same object.

Unfortunately, you can't do that. Well—not if you want Debian-edu to remain compatible with everything else under the sun. You see, one of the features of LDAP is that each and every objectClass is well-defined, and that you cannot change it. As such, once a tool knows about an objectClass, it can make assumptions about objects in that class, for any such object, in any LDAP-server anywhere. Change an objectClass, and some tools will break.

The proper fix is, first, to verify that you are using the proper objectClasses. To me, an objectClass called dhcpHost and one called dNSDomain don't sound like they were meant to be used together; I would suspect that there is another DNS-related objectClass that is meant for hosts rather than domains. If that isn't the case, then one can create a new objectclass—say, auxiliaryDhcpHost or some such—that is the same as dhcpHost in all but name, OID, and the fact that you make it an auxiliary rather than a structural objectClass. Because luckily, what's true for an objectClass is also true for an attributeType: if it is assigned to an LDAP object, tools may assume that their meaning is what they think it is...