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 <s...@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@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.

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York

_______________________________________________
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users

Reply via email to