openldap et evoluitionperson.schema

Bonjour,

Je termine de mettre en place egroupware dans le cadre de mon stage. Il me reste cependant un problème à régler. Openldap est utilisé pour l'authentification des utilisateurs et le stockage des carnets d'adresses. Je cherche à avoir des catégories dans les carnets d'adresses afin que les utilisateurs puissent envoyer des mails à un groupe de personnes.

Egroupware fournit le schema dans son paquet. Je l'ai donc récupéré et placé dans /etc/openldap/schema avec les bons droits puis je l'ai ajouté dans slapd.conf. J'ai enfin redémarré le service ldap qui ne m'a renvoyé aucune erreur.

Pour tester, j'ai exporté ma base actuelle



slapcat -n 1 -c > exportbase.ldif

cp exportbase.ldif importbase.ldif

Ensuite, j'édite importbase.ldif et je modifie une entrée de cette manière (ajout de objectClass: evolutionPerson) :

dn: uid=6f945b6f9556393d9151252790d2f7a4,cn=aldevar,ou=personal,ou=contacts,ou

 =Users,dc=domain,dc=fr

uid: 6f945b6f9556393d9151252790d2f7a4

objectClass: inetOrgPerson

objectClass: person

objectClass: evolutionPerson

cn: marc dupond

givenName: marc

sn: dupond

mail: marc.dupond@revnew.domain.fr

displayName: dupond, marc

structuralObjectClass: inetOrgPerson

entryUUID: d91d6e36-5284-102e-8370-b3fd7d4e5e39

creatorsName: cn=Manager,dc=domain,dc=fr

createTimestamp: 20091021115853Z

entryCSN: 20091021115853Z#0001a6#00#000000

modifiersName: cn=Manager,dc=domain,dc=fr

modifyTimestamp: 20091021115853Z

Enfin, je tente de réimporter la base :



$slapadd -n 1 -l /tmp/importbase.ldif

str2entry: invalid value for attributeType objectClass #2 (syntax 1.3.6.1.4.1.1466.115.121.1.38)

slapadd: could not parse entry (line=8463)

La ligne 8463 correspond à la ligne suivant la dernière ligne de l'entrée (une ligne vide donc)

openldap me refuse donc l'ajout de l'objectclass evolutionPerson car il ne le reconnait pas. Le schema est pourtant bien ajouté dans slapd.conf.

Voici slapd.conf :



include         /etc/openldap/schema/core.schema

include         /etc/openldap/schema/cosine.schema

include         /etc/openldap/schema/inetorgperson.schema

inculde         /etc/openldap/schema/evolutionperson.schema

include         /etc/openldap/schema/mozillaabpersonalpha.schema

include         /etc/openldap/schema/rfc2307bis.schema

include         /etc/openldap/schema/samba.schema

include         /etc/openldap/schema/hopital.schema



allow bind_v2



pidfile         /var/run/openldap/slapd.pid

argsfile        /var/run/openldap/slapd.args



moduleload     back_bdb.la

 moduleload     back_ldap.la

 moduleload     back_ldbm.la

 moduleload     back_passwd.la

 moduleload     back_shell.la



access to dn.one="ou=Users,dc=domain,dc=fr" attrs=entry,sn,mail,cn,givenName,telephoneNumber,uid,objectClass

        by anonymous read



access to dn.one="ou=Groups,dc=domain,dc=fr" attrs=cn,memberUid,objectClass

        by anonymous read



access to dn.one="ou=People,dc=domain,dc=fr" attrs=entry,sn,mail,cn,givenName,telephoneNumber

        by anonymous read



include /etc/openldap/acl_addressbooks.conf



access to *

        by * peername.ip=194.146.14.189 read



access to *

        by * none



database        bdb

suffix          "dc=domain,dc=fr"

rootdn          "cn=Manager,dc=domain,dc=fr"

rootpw          passord



directory       /var/lib/ldap



index default pres,eq

index uid

index cn,sn,mail pres,eq

index   objectClass     eq

Je ne vois pas d'ou peut venir le problème. J'ai egalement essayé de modifié le charset de evolutionperson.schema en utf-8 et iso-8859-15 sans résultat.
De plus, si je renomme le fichier evolutionperson.schema et que je redémarre le service ldap (en laissant inculde /etc/openldap/schema/evolutionperson.schema dans slapd.conf) ldap ne me sort aucune erreur et démarre correctement. Je suppose que ceci est normal, puisqu'il n'y a aucune entrée contenant un attribut de evolutionperson.schema dans ma base actuelle, mais je n'en suis pas sûr a 100% étant plutôt débutant dans ldap.

Quelqu'un saurait-il m'orienter vers un début de solution pour réussir à utiliser ce schema?

# directive schema check et augmenter le niveau de debug

Posté par nono14 (site web personnel) le 09 novembre 2009 à 11:57. Évalué à 2.

La directive schema check permet de vérifier que les données soient correctes vis à vis de leur définition dans le schéma défini.

Augmenter le niveau de debug pour le demon slapd peut etre utile
Système - Réseau - Sécurité Open Source
- [^] # Re: directive schema check et augmenter le niveau de debug
  
  Posté par Aldevar (site web personnel) le 09 novembre 2009 à 12:32. Évalué à 1.
  
  Merci pour cette réponse rapide.
  
  Après avoir redémarré openldap avec un niveau de débug -1, je me suis rendu compte que l'erreur était en fait plutot stupide :
  inculde /etc/openldap/schema/evolutionperson.schema
  ou lieu de
  include /etc/openldap/schema/evolutionperson.schema
  
  Quand je pense que je cherche une solution depuis la fin de la semaine dernière…
  
  Ceci dit, maintenant, quand je tente d'importer ma base importbase.ldif, j'obtiens cette erreur (avec evolutionPerson en STRUCTURAL) :
  slapadd -n 1 -l /tmp/importbase.ldif slapadd: dn="uid=6f945b6f9556393d9151252790d2f7a4,cn=aldevar,ou=personal,ou=contacts,ou=Users,dc=ch-guingamp,dc=fr" (line=8463): (69) structural object class modification from 'inetOrgPerson' to 'evolutionPerson' not allowed
  
  (avec evolutionPerson en AUXILIARY) :
  $slapadd -n 1 -l /tmp/importbase.ldif /etc/openldap/schema/evolutionperson.schema: line 200: user-defined ObjectClass has inappropriate SUPerior: "inetOrgPerson" slapadd: bad configuration file!
  
  A l'origine evolutionPerson.schema contient la definition de evolutionPerson en tant que structural mais également avec SUP inetOrgPerson ce qui ne me semble pas logique. Il me semble qu'on ne peut pas avoir 2 objectclass structural en meme temps sur un objet.
  
  Dois-je supprimer l'objectclass inetOrgPerson dans les entrées de mon carnets d'adresse?
  
  En tout cas merci, je me sens maintenant plus proche de ce que je souhaite obtenir.