Re: [Freeipa-users] Doubt on FreeIPA LDAP extensibility
On Sun, 2012-03-18 at 13:59 +0100, Marco Pizzoli wrote: Hi Simo, On Sat, Mar 17, 2012 at 7:16 PM, Simo Sorce s...@redhat.com wrote: On Sat, 2012-03-17 at 11:12 +0100, Marco Pizzoli wrote: Hi guys, I extended my set of LDAP objectClasses associated to users by adding my new objectClass to my cn=ipaConfig LDAP entry, the ipaUserObjectClasses attribute. Then, I created a new user with the web ui and I see the new objectClass associated with that user, but as structural instead of auxiliary. I don't know why, could you help me? Same thing happened for my groups. I added 3 objectClasses and now I see all of them as structural. I would understand an answer: all objectClasses eventually result as structural, but so why, for example, the ipaObject is still an auxiliary objectClass? The objectClass type depends on the schema. It is not something that changes after you assign it to an object. Yes, your answer surely does make sense. My question was triggered by the fact that, AFAICS, not all objectClasses are structural as well. In fact I can see that, for my group object, the objectClass ipaobject has been defined as auxiliary, while others structural. For users, I see that *only my objectClass* is defined as structural. All others as auxiliary. In attachment you can see 2 images that immediately represent what I'm trying to explain. If this was the intended behaviour, I would be really interested in knowing what is the rationale behind this. Only curiousity, as usual :-) Objectclasses have no structureal/auxiliary attribute in an object, it's your ldap browser that is returning the labeling by (I guess ) searching the schema. I guess your object is getting it wrong, or the schema you defined in 389ds has these classes marked structural. search the schema with your browser and see how it identify these classes ? I see you also opened a bug, but it makes little sense to me. I will close it as invalid for now, unless there is evidence 389ds returns the wrong type from the schema tree. Simo. -- Simo Sorce * Red Hat, Inc * New York ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Doubt on FreeIPA LDAP extensibility
On Mon, Mar 19, 2012 at 1:15 PM, Simo Sorce s...@redhat.com wrote: On Sun, 2012-03-18 at 13:59 +0100, Marco Pizzoli wrote: Hi Simo, On Sat, Mar 17, 2012 at 7:16 PM, Simo Sorce s...@redhat.com wrote: On Sat, 2012-03-17 at 11:12 +0100, Marco Pizzoli wrote: Hi guys, I extended my set of LDAP objectClasses associated to users by adding my new objectClass to my cn=ipaConfig LDAP entry, the ipaUserObjectClasses attribute. Then, I created a new user with the web ui and I see the new objectClass associated with that user, but as structural instead of auxiliary. I don't know why, could you help me? Same thing happened for my groups. I added 3 objectClasses and now I see all of them as structural. I would understand an answer: all objectClasses eventually result as structural, but so why, for example, the ipaObject is still an auxiliary objectClass? The objectClass type depends on the schema. It is not something that changes after you assign it to an object. Yes, your answer surely does make sense. My question was triggered by the fact that, AFAICS, not all objectClasses are structural as well. In fact I can see that, for my group object, the objectClass ipaobject has been defined as auxiliary, while others structural. For users, I see that *only my objectClass* is defined as structural. All others as auxiliary. In attachment you can see 2 images that immediately represent what I'm trying to explain. If this was the intended behaviour, I would be really interested in knowing what is the rationale behind this. Only curiousity, as usual :-) Objectclasses have no structureal/auxiliary attribute in an object, it's your ldap browser that is returning the labeling by (I guess ) searching the schema. Exact. I admit I have not been so clear in my explanation. I guess your object is getting it wrong, or the schema you defined in 389ds has these classes marked structural. search the schema with your browser and see how it identify these classes ? 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. I see you also opened a bug, but it makes little sense to me. I will close it as invalid for now, unless there is evidence 389ds returns the wrong type from the schema tree. Ok, I agree. Thanks as usual Marco Simo. -- Simo Sorce * Red Hat, Inc * New York attachment: GroupsAttribute_ObjectClass.PNG___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Doubt on FreeIPA LDAP extensibility
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 ? 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. Simo. -- Simo Sorce * Red Hat, Inc * New York ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Doubt on FreeIPA LDAP extensibility
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 -Dcn=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. Simo. -- Simo Sorce * Red Hat, Inc * New York ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Doubt on FreeIPA LDAP extensibility
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 -Dcn=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
Re: [Freeipa-users] Doubt on FreeIPA LDAP extensibility
Hi Simo, On Sat, Mar 17, 2012 at 7:16 PM, Simo Sorce s...@redhat.com wrote: On Sat, 2012-03-17 at 11:12 +0100, Marco Pizzoli wrote: Hi guys, I extended my set of LDAP objectClasses associated to users by adding my new objectClass to my cn=ipaConfig LDAP entry, the ipaUserObjectClasses attribute. Then, I created a new user with the web ui and I see the new objectClass associated with that user, but as structural instead of auxiliary. I don't know why, could you help me? Same thing happened for my groups. I added 3 objectClasses and now I see all of them as structural. I would understand an answer: all objectClasses eventually result as structural, but so why, for example, the ipaObject is still an auxiliary objectClass? The objectClass type depends on the schema. It is not something that changes after you assign it to an object. Yes, your answer surely does make sense. My question was triggered by the fact that, AFAICS, not all objectClasses are structural as well. In fact I can see that, for my group object, the objectClass ipaobject has been defined as auxiliary, while others structural. For users, I see that *only my objectClass* is defined as structural. All others as auxiliary. In attachment you can see 2 images that immediately represent what I'm trying to explain. If this was the intended behaviour, I would be really interested in knowing what is the rationale behind this. Only curiousity, as usual :-) Thanks again for your patience! Marco Simo. -- Simo Sorce * Red Hat, Inc * New York attachment: User_objectClasses.PNGattachment: Group_objectClasses.PNG___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Doubt on FreeIPA LDAP extensibility
On 03/18/2012 08:59 AM, Marco Pizzoli wrote: Hi Simo, On Sat, Mar 17, 2012 at 7:16 PM, Simo Sorce s...@redhat.com mailto:s...@redhat.com wrote: On Sat, 2012-03-17 at 11:12 +0100, Marco Pizzoli wrote: Hi guys, I extended my set of LDAP objectClasses associated to users by adding my new objectClass to my cn=ipaConfig LDAP entry, the ipaUserObjectClasses attribute. Then, I created a new user with the web ui and I see the new objectClass associated with that user, but as structural instead of auxiliary. I don't know why, could you help me? Same thing happened for my groups. I added 3 objectClasses and now I see all of them as structural. I would understand an answer: all objectClasses eventually result as structural, but so why, for example, the ipaObject is still an auxiliary objectClass? The objectClass type depends on the schema. It is not something that changes after you assign it to an object. Yes, your answer surely does make sense. My question was triggered by the fact that, AFAICS, not all objectClasses are structural as well. In fact I can see that, for my group object, the objectClass ipaobject has been defined as auxiliary, while others structural. For users, I see that *only my objectClass* is defined as structural. All others as auxiliary. In attachment you can see 2 images that immediately represent what I'm trying to explain. If this was the intended behaviour, I would be really interested in knowing what is the rationale behind this. Only curiousity, as usual :-) Thanks again for your patience! AFAIU the object classes that are added to users and groups need to be first defined in the schema. I assume you have done so otherwise all sorts of errors would have shown up. Am I correct? I do not recognize the object classes as standard object classes. But might knowledge might be limited. Can you put show how you defined these new object classes in schema? You might have not specified the type and it defaulted to structural. Marco Simo. -- Simo Sorce * Red Hat, Inc * New York ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users -- Thank you, Dmitri Pal Sr. Engineering Manager IPA project, Red Hat Inc. --- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Doubt on FreeIPA LDAP extensibility
Hi Dmitri, On Sun, Mar 18, 2012 at 5:41 PM, Dmitri Pal d...@redhat.com wrote: ** On 03/18/2012 08:59 AM, Marco Pizzoli wrote: Hi Simo, On Sat, Mar 17, 2012 at 7:16 PM, Simo Sorce s...@redhat.com wrote: On Sat, 2012-03-17 at 11:12 +0100, Marco Pizzoli wrote: Hi guys, I extended my set of LDAP objectClasses associated to users by adding my new objectClass to my cn=ipaConfig LDAP entry, the ipaUserObjectClasses attribute. Then, I created a new user with the web ui and I see the new objectClass associated with that user, but as structural instead of auxiliary. I don't know why, could you help me? Same thing happened for my groups. I added 3 objectClasses and now I see all of them as structural. I would understand an answer: all objectClasses eventually result as structural, but so why, for example, the ipaObject is still an auxiliary objectClass? The objectClass type depends on the schema. It is not something that changes after you assign it to an object. Yes, your answer surely does make sense. My question was triggered by the fact that, AFAICS, not all objectClasses are structural as well. In fact I can see that, for my group object, the objectClass ipaobject has been defined as auxiliary, while others structural. For users, I see that *only my objectClass* is defined as structural. All others as auxiliary. In attachment you can see 2 images that immediately represent what I'm trying to explain. If this was the intended behaviour, I would be really interested in knowing what is the rationale behind this. Only curiousity, as usual :-) Thanks again for your patience! AFAIU the object classes that are added to users and groups need to be first defined in the schema. I assume you have done so otherwise all sorts of errors would have shown up. Am I correct? Exact. I followed the instructions on extending the schema on 389-ds, by inserting a file in my /etc/dirsrv/instance/schema dir. Everything went ok, and I can see from phpldapadmin that the DSA correctly present my objectClasses as available to use for extending objects. I do not recognize the object classes as standard object classes. But might knowledge might be limited. Exact, they are mine objects, under a reserved OID number. Can you put show how you defined these new object classes in schema? You might have not specified the type and it defaulted to structural. This was a schema file created for OpenLDAP and which is currently in production. I used the script posted on the 389-ds HowTo for the migration from OpenLDAP schema files to 389-ds format. Here you can find it. A little camouflated, of course. [root@freeipa01 ~]# cat /etc/dirsrv/slapd-UNIX-MYDOMAIN-IT/schema/98myfile.ldif dn: cn=schema attributetypes: ( 1.3.6.1.4.1.36005.0.2.4.4 NAME 'xxxUfficio' DESC 'Ufficio di appartenenza degli utenti XXX' EQUALITY caseIgnoreMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 USAGE userApplications ) objectclasses: ( 1.3.6.1.4.1.36005.0.2.6.2 NAME 'xxxPeopleAttributes' SUP top AUXILIARY DESC 'Definizione di attributi specifici per gli utenti XXX' MAY ( xxxUfficio )) attributetypes: ( 1.3.6.1.4.1.36005.0.2.4.1 NAME 'xxxProgetto' DESC 'Nome del macro-progetto associato a questo gruppo LDAP' EQUALITY caseIgnoreMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 USAGE userApplications ) attributetypes: ( 1.3.6.1.4.1.36005.0.2.4.2 NAME 'xxxAmbiente' DESC 'Nome di ambiente SVIL-TEST-VALID-PROD associato al progetto' EQUALITY caseIgnoreMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 USAGE userApplications ) attributetypes: ( 1.3.6.1.4.1.36005.0.2.4.5 NAME 'xxxTipoGruppo' DESC 'Tipologia di gruppo' EQUALITY caseIgnoreMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 USAGE userApplications ) objectclasses: ( 1.3.6.1.4.1.36005.0.2.6.3 NAME 'xxxGroupsAttributes' SUP top AUXILIARY DESC 'Definizione di attributi specifici per i gruppi XXX' MAY ( xxxProgetto $ xxxAmbiente $ xxxTipoGruppo )) attributetypes: ( 1.3.6.1.4.1.36005.0.2.4.6 NAME 'xxxWebminAmbiente' DESC 'Ufficio di appartenenza degli utenti XXX' EQUALITY caseIgnoreMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 USAGE userApplications ) objectclasses: ( 1.3.6.1.4.1.36005.0.2.6.4 NAME 'xxxWebminAttributes' SUP top AUXILIARY DESC 'Definizione di attributi specifici per gli oggetti Webmin' MAY ( xxxWebminAmbiente )) attributetypes: ( 1.3.6.1.4.1.36005.0.2.4.3 NAME 'xxxDB2GruppiPrivilegi' DESC 'Tipologia di gruppo creato per accesso al DB2' EQUALITY caseIgnoreMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 USAGE userApplications ) objectclasses: ( 1.3.6.1.4.1.36005.0.2.6.5 NAME 'xxxDB2GroupsAttributes' SUP top AUXILIARY DESC 'Definizione di attributi specifici per i gruppi DB2' MAY ( xxxDB2GruppiPrivilegi )) objectclasses: ( 1.3.6.1.4.1.36005.0.2.6.1 NAME 'xxxAttributes' SUP top AUXILIARY DESC 'Definizione di attributi specifici per utilizzo interno' MAY ( xxxProgetto $ xxxAmbiente $ xxxTipoGruppo $ xxxDB2GruppiPrivilegi )) As you can see, they are explicitly declared
Re: [Freeipa-users] Doubt on FreeIPA LDAP extensibility
On Sat, 2012-03-17 at 11:12 +0100, Marco Pizzoli wrote: Hi guys, I extended my set of LDAP objectClasses associated to users by adding my new objectClass to my cn=ipaConfig LDAP entry, the ipaUserObjectClasses attribute. Then, I created a new user with the web ui and I see the new objectClass associated with that user, but as structural instead of auxiliary. I don't know why, could you help me? Same thing happened for my groups. I added 3 objectClasses and now I see all of them as structural. I would understand an answer: all objectClasses eventually result as structural, but so why, for example, the ipaObject is still an auxiliary objectClass? The objectClass type depends on the schema. It is not something that changes after you assign it to an object. Simo. -- Simo Sorce * Red Hat, Inc * New York ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
