Joseph Fry via FreeIPA-users wrote:
Unfortunately, the objectclass is the most important part. The
client will only recognize the 'computer' object class as something it can import;
as it requires the groups and groupOfNames object classes on the groups per the block
below or import fails:
dn: cn=adcomputergroups, cn=Schema Compatibility, cn=plugins, cn=config
default:objectClass: top
default:objectClass: extensibleObject
default:cn: adcomputergroups
default:schema-compat-container-group: cn=compat, $SUFFIX
default:schema-compat-container-rdn: cn=adcomputergroups
default:schema-compat-search-base: cn=hostgroups, cn=accounts, $SUFFIX
default:schema-compat-search-filter: (&(member=*)(objectClass=ipahostgroup))
default:schema-compat-entry-rdn: cn=%{cn}
default:schema-compat-entry-check-access: yes
default:schema-compat-entry-attribute: objectclass=group
default:schema-compat-entry-attribute: objectclass=groupOfNames
default:schema-compat-entry-attribute: cn=%{cn}
default:schema-compat-entry-attribute:
distinguishedName=cn=%{cn},cn=adcomputergroups,cn=compat,$SUFFIX
default:schema-compat-entry-attribute: name=%{cn}
default:schema-compat-entry-attribute:
member=cn=%deref_r("member","fqdn"),cn=adcomputers,cn=compat,$SUFFIX
I don't know of a way around it other than defining a computer objectclass.
It may not even need to be much of anything, just its existence. So you
could, for example, declare a computer objectclass with the right OID
and that's it (it technically wouldn't need the right OID but it has to
have something and picking something could get you in trouble later).
I realize this goes against your goal of doing as little as possible but
this would never be used by IPA itself. It would be part of the schema
but it would be so bare bones as to be unusable which I think would
cause someone trying to use it some pause and maybe that would
discourage them.
You can add schema using an update file as well.
rob