[RESOLU] LDAP : Conflit entre plusieurs objectClass

[darkukai]

Bonjour
J'ai un serveur LDAP qui tourne sur une ubuntu 6.06
Tout marche bien je gère çà avec phpldapadmin ( une merveille )

Mais j'ai un problème lors de l'ajout d'un utilisateur à ma base

je met ici un extrait de mon fichier ldif :

dn: uid=mat,ou=People,dc=immaculee,dc=net
cn: mat
givenName: mat
sn: ferber
uid: matferber
gecos: Mat Ferber,,,
mail: mat.ferber@immaculee.net
mailAlternateAddress: mat@immaculee.net
mailAlternateAddress: mf@immaculee.net
uidNumber: 1020
homeDirectory: /home/1020
mailMessageStore: /home/1020/Maildir
gidNumber: 1001
shadowMax: 99999
shadowWarning: 7
shadowLastChange: 12416
loginShell: /bin/bash
ou: People
o: IMMAGESTION
accountStatus: active
mailQuota: 2480000S
physicalDeliveryOfficeName: 74 Place GrandClément
employeeNumber: 0001
telephoneNumber: 06 08 48 50 04
title: Not a Real Person
homePostalAddress: 1 Unix Way or the Hwy.
homePhone: 410-555-1212
userPassword: {SSHA}CD7oNQm9Zb14wZgKM9Wht8d3qp9EJITX
objectClass: top
objectClass: posixAccount
objectClass: shadowAccount
objectClass: account
objectClass: qmailuser
objectClass: couriermailaccount
objectClass: Person
objectClass: OrganizationalPerson
objectClass: inetOrgPerson

et quand je tape :

ldapadd -w monpass -D "cn=admin,dc=immaculee,dc=net" -f users.ldif -x
adding new entry "uid=mat,ou=People,dc=immaculee,dc=net"

j'obtiens un joli :

ldap_add: Object class violation (65)
additional info: invalid structural object class chain (account/person)

Si j'enlève la class Person de mon fichier ldif çà bloque ensuite sur OrganizationalPerson
Et quand je l'enlève çà bloque sur inetOrgPerson.

Bon j'ai cru comprendre dans mes recherches que l'objectClass account ne pouvait être donné en même temps que ces Objets person org.. et inet... car une personne peut avoir un account mais pas l'inverse (désolé j'ai pas tout compris c'était dans une langue obscure qu'on appele l'anglais )

Enfin bon je me dis pas grave je vire la class account, mais voila il semble que j'ai besoin de l'attribut UID pour faire fonctionner mon ldap avec postfix donc je suis bloqué

Voila je sais c'est un peu confus je sais mais c'est ma situation donc si une bonne âme passe par là et a une idée, une piste, une solution, un best of mcchicken potatoes coca, ou une suggestion ma fois merci d'avance


PS : Oui je suis un gros n00b d'LDAP mais je précise que google est une vieille connaissance et que j'ai pas mal potasser le truc à mon niveaux de n00b

[vanvan]

Bonjour.

Après ça fait un moment que j'ai pas replongé dans le ldap mais de mémoire, il te faut obligatoirement l'UID histoire qu'il sache repérer l'objet.
Et puis, en lisant ton message d'erreur, il semblerait que tu ais un probleme de formatage de ton fichier ldif. Tu as dû donner une valeur à l'un des champs qui ne correspond pas à ce qu'il attend.
Un conseil prend ton ldif et met tes modifs sur le compte les unes apres les autres pour voir quels objets plantent tous le reste.

[darkukai]

Merci du conseil je m'y attèle de suite
et désolé d'avoir fait remonter des souvenirs peut être douloureux

[darkukai]

Bon j'ai modifié mon fichier en essayant de laisser le strict nécessaire :

dn: uid=mat,ou=People,dc=immaculee,dc=net
userPassword: {SSHA}CD7oNQm9Zb14wZgKM9Wht8d3qp9EJITX
objectClass: top
objectClass: posixAccount
objectClass: shadowAccount
objectClass: qmailuser
objectClass: account
objectClass: couriermailaccount
objectClass: Person
objectClass: OrganizationalPerson
objectClass: inetOrgPerson

Mais l'erreur reste la même
par contre si je laisse tout les attributs et que j'enlève juste l'objectClasse: account, alors tout passe nickel
Donc çà voudrait dire que mon user n'a pas d'attribut concerné par la class 'account' et que je pourrais m'en passé ??
Quels incidences sur l'utilisation de courier-imap + postfix cela peut t'il avoir ??
Je crois que je vais continuer comme çà en éspérant que çà coincera pas plus tard

En tout cas si quelqu'un a une explication ( en français donc ) sur ce conflit entre les classe account et person,inetorgperson, organizationalperson, elle serait la bienvenue

Merci pour tout

[vanvan]

Et bien je pourrais surement t'en dire plus dans les mois qui viennent car je vais installer un réplicat ldap qui discutera avec un samba et un postfix.

[arapaho]

Ce serait pas mal de se documenter et de comprendre correctement les types de classe d'objets, leurs interactions, ainsi que de correctement visualiser leurs attributs propres et leurs obligations. Pratiquer le LDAP autrement, c'est un peu comme vouloir aller se faire une petite partie de hockey sur glace contre des Suédois avec pour seul équipement une feuille de vigne bien positionnée ....

AMHA, les deux raisons qui t'amenent à ces erreurs sont:

1 - Tu ne travailles pas avec un mindmap des classes et de leurs attributs afin de ne pas cumuler les attributs inutilement et de ne pas faire de mélanges vaseux entre les différentes classes structurelles et auxiliaires,

2 - La méthode de rédaction de ton LDIF ne t'aide pas du tout dans la visualisation des erreurs.

En effet, tu pourrais par exemple commencer par indiquer les classes tout de suite après la déclaration de ton entrée. Ca te permettrait ensuite d'être sûr de l'intégralité des attributs que tu peux accorder à cette entrée. Aussi, cela te permettrait de factoriser les classes utilisées: certaines ont des type d'attributs en commun. Pas la peine de les cumuler.

Je ne te détaillerai pas l'intégralité des erreurs qui se trouvent dans ton entrée: ce ne serait pas t'aider que de te macher le travail. Par contre, pour te donner une piste de travail, un exemple sur ton problème account/posixAccount:

la classe account [structurelle] fournit plusieurs attributs dont un nommé 'uid'.
la classe posixAccount [auxiliaire] fournit également un uid.
les classes inetOrgPerson et organizationalPerson sont structurelles

[darkukai]

faire une petite partie de hockey sur glace contre des Suédois avec pour seul équipement une feuille de vigne bien positionnée

Facile, j'lai fait hier
Je ne réfute pas mes profondes lacunes sur la question, sachant que je lis un how to postfix-ldap je me demandais simplement pourquoi sur le how to çà marche alors que chez moi çà marche po

Bon bein a moi les méandres de google sur le sujet... snif

EDIT - j'avais pas vu çà en haut du how to

Prérequis :

- Des connaissances LDAP

[darkukai]

Bon alors je continue ici a poster mes aventures LDAPIENNE concernant toujours le même problème

J'ai lu ceci :

This particular error refers to the rule about STRUCTURAL objectclasses, which states that an object is of one STRUCTURAL class, the structural class of the object. The object is said to belong to this class, zero or more auxiliaries classes, and their superclasses. While all of these classes are commonly listed in the objectClass attribute of the entry, one of these classes is the structural object class of the entry. Thus, it is OK for an objectClass attribute to contain inetOrgPerson, organizationalPerson, and person because they inherit one from another to form a single superclass chain. That is, inetOrgPerson SUPs organizationPerson SUPs person. On the other hand, it is invalid for both inetOrgPerson and account to be listed in objectClass as inetOrgPerson and account are not part of the same superclass chain (unless some other class is also listed with is a subclass of both).

To resolve this problem, one must determine which class will better serve structural object class for the entry, adding this class to the objectClass attribute (if not already present), and remove any other structural class from the entry's objectClass attribute which is not a superclass of the structural object class.

Which object class is better depends on the particulars of the situation. One generally should consult the documentation for the applications one is using for help in making the determination

Donc j'en comprend que mes classes structurel person et account ne peuvent être utilisé en même temps
car elles ne font pas parti de la même chaine de super class et que daprès ce que j'ai compris lorsqu'on décrit un objet on doit rester cohérent et rester dans la même superclass
A savoir ici :
- top
- inetorgPerson
- person
- organizationalPerson

La solution au problème que j'ai vu sur un autre site serait de créer une nouvelle classe commune à person et account pour insérer account dans la superclass structurel commune.

In that case you must add a structural object class which is a subclass
of both inetOrgPerson and account. E.g.

objectclass ( <oid> NAME 'personalAccount'
SUP ( inetOrgPerson $ account ) STRUCTURAL )

ou alors de trouver une classe autre que 'account' qui aurait l'attribut dont j'ai besoin et qui ferait parti de la chaine structurel person-inetorgperson-top ...





Voila donc je test et j'edit pour voir si çà marche

[darkukai]

Bon bein j'ai changé de tactiques finalement n'arrivant pas a élucider le pourquoi du comment de cette affaire, pas tant de savoir les causes réelles qui nécessitent des connaissances que je n'ai pas ou très peu, mais plus savoir pourquoi dans le how to que je suis çà marche sans problème et pas chez moi

J'ai finalement décider de m'appuyer sur un autre -schema qui semble fonctionner et qui contient tout les attribut dont j'avais besoin.

Un mystère qui restera en suspens.