Hi Dmitri, On Sun, Mar 18, 2012 at 5:41 PM, Dmitri Pal <[email protected]> wrote:
> ** > On 03/18/2012 08:59 AM, Marco Pizzoli wrote: > > Hi Simo, > > On Sat, Mar 17, 2012 at 7:16 PM, Simo Sorce <[email protected]> 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 as AUXILIARY. Thanks again Marco
_______________________________________________ Freeipa-users mailing list [email protected] https://www.redhat.com/mailman/listinfo/freeipa-users
