Hi On Mon, Mar 19, 2012 at 6:44 PM, Simo Sorce <s...@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 <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. > 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 > >
_______________________________________________ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users