[Freeipa-users] Doubt on FreeIPA LDAP extensibility

[Marco Pizzoli]

Hi

On Mon, Mar 19, 2012 at 6:44 PM, Simo Sorce <simo at redhat.com> wrote:

> On Mon, 2012-03-19 at 12:36 -0400, Simo Sorce wrote:
> > On Mon, 2012-03-19 at 14:46 +0100, Marco Pizzoli wrote:
> > >
> > >
> > > On Mon, Mar 19, 2012 at 2:32 PM, Simo Sorce <simo at redhat.com> wrote:
> > >         On Mon, 2012-03-19 at 13:51 +0100, Marco Pizzoli wrote:
> > >         >
> > >         > In attachment. You can find only one, but all of them are
> > >         equivalent
> > >         > from this point.
> > >         > They are indeed seen as structural, even if my added schema
> > >         file
> > >         > declare them as auxiliary.
> > >
> > >
> > >         Can you attach the (sanitized) schema file you added to
> > >         389ds ?
> > >
> > > Already done on this thread. See my previous mail to Dmitri.
> > >
> > >
> > >         Also can you run a ldapsearch command and search in the
> > >         'cn=schema'
> > >         base ? This will give you back what 389ds sends to a client.
> > >
> > >
> > >         This command searches for everything but uses an attribute
> > >         filter to
> > >         show only the objectclasses:
> > >         ldapsearch -x -h server -b 'cn=schema' 'objectClasses'
> > >
> > >         No need to attach everything return, just edit the result and
> > >         attach
> > >         only the results for your calsses.
> > >
> > > Ok, here it is:
> > > [root at freeipa01 ~]# ldapsearch -h 127.0.0.1 -x -D"cn=Directory
> > > Manager" -s base  -W -b "cn=schema" "objectClasses"|perl -0pe
> > > 's/\n //g'
> > >
> > > objectClasses: ( 1.3.6.1.4.1.36005.0.2.6.2 NAME 'xxxPeopleAttributes'
> > > DESC 'Definizione di attributi specifici per gli utenti XXX'
> > > STRUCTURAL MAY xxxUfficio )
> > > objectClasses: ( 1.3.6.1.4.1.36005.0.2.6.3 NAME 'xxxGroupsAttributes'
> > > DESC 'Definizione di attributi specifici per i gruppi XXX' STRUCTURAL
> > > MAY ( xxxProgetto $ xxxAmbiente $ xxxTipoGruppo ) )
> > > objectClasses: ( 1.3.6.1.4.1.36005.0.2.6.4 NAME 'xxxWebminAttributes'
> > > DESC 'Definizione di attributi specifici per gli oggetti Webmin'
> > > STRUCTURAL MAY xxxWebminAmbiente )
> > > objectClasses: ( 1.3.6.1.4.1.36005.0.2.6.5 NAME
> > > 'xxxDB2GroupsAttributes' DESC 'Definizione di attributi specifici per
> > > i gruppi DB2' STRUCTURAL MAY xxxDB2GruppiPrivilegi )
> > > objectClasses: ( 1.3.6.1.4.1.36005.0.2.6.1 NAME 'xxxAttributes' DESC
> > > 'Definizione di attributi specifici per utilizzo interno' STRUCTURAL
> > > MAY ( xxxProgetto $ xxxAmbiente $ xxxTipoGruppo $
> > > xxxDB2GruppiPrivilegi ) )
> > >
> > >
> > > By seeing this output, I just checked again and I confirm that in my
> > > file /etc/dirsrv/slapd-UNIX-MYDOMAIN-IT/schema/98myfile.ldif they are
> > > still AUXILIARY.
> >
> > This is odd, indeed, I will resurrect the bug you opened with a better
> > description,
> > thanks.
>
> Marco,
> I discussed this briefly with Nathan and it seem that it may be a parser
> error. 389DS parser is quite strict and wants the various definitions in
> the precise order they are defined in the RFCs. I guess that means that
> if you reorder where you define the type (AUXILIARY/STRUCTURAL) in the
> string you'll get the right behavior. As Is I think AUXILIARY is simply
> ignored because it is int eh wrong position and the default STRUCTURAL
> is used.
> If you can change your schema file to define AUS/STR in the right order
> (see other IPA ldif file for hints) and can confirm it is ano ordering
> problem we can open a documentation bug to explain this behavior until
> the underlying parser is improved to better handle random ordered
> definitions.
>

Yes, I modified the position of the "SUP top AUXILIARY" part and now it's
ok!!

My use case was in converting a working OpenLDAP schema file with the
script published on the 389-ds wiki[1]. I would ask/suggest/like/appreciate
it being improved for dealing with this thing too...
I'm not a programmer, in that case I would offer to do it... :-/

[1] http://directory.fedoraproject.org/download/ol-macro-expand.pl


>
> Simo.
>
> --
> Simo Sorce * Red Hat, Inc * New York
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20120319/838d4086/attachment.htm>