[Date Prev][Date Next] [Chronological] [Thread] [Top]

RE: structural objectclass checking

Thanks Michael for that idea. But that would mean to assign that new group to every entry that has 2 structural objectclasses today, wouldn't it?
So it would require me to change the upstream data e.g. replace posixGroup by aeGroup and remove groupOfURLs (to stick with your example) and the application as there's applications to search for e.g.
&(objectclass=posixGroup)(objectclass=groupOfURLs).
And I would need to fix future entries on the fly (rwm module in replication??)

Guess that won't work out, possibly still easier to work around this in the source code.
Any opinions on that from people to know the source better than I do ?

Best regards
Markus

> -----Original Message-----
> From: Michael Ströder <michael@stroeder.com>
> Sent: Thursday, January 9, 2020 9:56 AM
> To: Storm, Markus <Markus.Storm@t-systems.com>; openldap-
> technical@openldap.org
> Subject: Re: structural objectclass checking
> 
> On 1/8/20 7:07 PM, Quanah Gibson-Mount wrote:
> > --On Wednesday, January 8, 2020 3:25 PM +0000
> > Markus.Storm@t-systems.com
> > wrote:
> >
> >> is there a way to disable OpenLDAP checking entries for existence of
> >> STRUCTURAL objectclasses?
> >
> > No.  This is a hard requirement.  The best option would be to fix the
> > bad data in your upstream system.
> 
> One possibility to fix this:
> Define a new STRUCTURAL object class derived from different other
> STRUCTURAL object classes.
> 
> E.g. in Æ-DIR I'm using this to provide hybrid posixGroup entries serving RFC
> 2307 and RFC 2307bis groups:
> 
> ( 1.3.6.1.4.1.5427.1.389.100.6.1
>   NAME 'aeGroup'
>   DESC 'AE-DIR: Group entry'
>   SUP ( groupOfEntries $ posixGroup $ groupOfURLs $ aeObject )
>   STRUCTURAL
>   MUST description
>   MAY ( aeMemberZone $ aeDept $ aeLocation ) )
> 
> This works because unlike other LDAP directory servers OpenLDAP supports
> multiple class inheritance.
> 
> Ciao, Michael.