CSV2LDIF - Adaptation pour migration des organismes

[gryckelynck]

J'ai commencé à adapter le script CSV2LDIF pour pouvoir alimenter le LDAP (version master, future 18.06) à partir de 2 fichiers:

• users.csv (sur le modèle actuel)
• orgs.csv (liste des organismes)

Je m'appuie également sur https://github.com/georchestra/georchestra/blob/master/ldap/georchestra.ldif comme modèle.

Pour finaliser le script j'aurais besoin de savoir:

• Est-il possible d'avoir dans le LDIF des USERS sans ORG ?

• Est-il possible d'avoir des ORGS sans USER ?

• Est-il nécessaire de conserver le champs "o" de USER ?
  Si oui, avec quelle valeur (nom long ou court de l'organisme) ?

• Les ORGS sont composés de 2 éléments "organization" et "groupOfMembers". Pourquoi? Je ne comprend pas bien la répartition des champs en 2 objets...
  Dans l'un j'ai par exemple dn o=sigle et dans le second j'ai ou=Sigle et o=Nom Complet. Je peux donc utiliser la valeur ou en minuscule pour le dn o=?
  Cela impose-t-il des règles de saisie pour le nom court (majuscules, etc.)?
  Existe-t’il un schéma pour mieux comprendre les liens entre ces objets (cardinalité, champs "communs", etc.)?

• Toujours pour les ORGS, la valeur businessCategory=REGISTERED est une valeur immuable donnée par défaut pour les "groupOfMembers"?

[fvanderbiest]

Est-il possible d'avoir dans le LDIF des USERS sans ORG ?

oui

Est-il possible d'avoir des ORGS sans USER ?

oui

Est-il nécessaire de conserver le champs "o" de USER ?

non, c'est même non recommandé

Les ORGS sont composés de 2 éléments "organization" et "groupOfMembers". Pourquoi?

Parce qu'il n'existe pas dans le LDAP de classe permettant de stocker tous les champs dont nous avions besoin => utilisation de 2 objets pour 1 org.

Je peux donc utiliser la valeur ou en minuscule pour le dn o=?

oui, en supprimant aussi les caractères spéciaux et espaces de préférence

Existe-t’il un schéma pour mieux comprendre les liens entre ces objets (cardinalité, champs "communs", etc.)?

http://www.zytrax.com/books/ldap/ch3/

Toujours pour les ORGS, la valeur businessCategory=REGISTERED est une valeur immuable donnée par défaut pour les "groupOfMembers"?

Nous avons arbitrairement choisi le champ businessCategory pour stocker l'état de l'organisation : valide ou pas encore modérée. REGISTERED signifie dans ce contexte que l'org est "validée".

[fvanderbiest]

Idée pour le codesprint du geocom : mieux documenter ces aspects du LDAP !

[gryckelynck]

Merci pour ces éléments.
Je pense que c'est presque bon. Je vais encore faire quelques tests pour valider que cela fonctionne comme souhaité.
Il serait aussi intéressant de documenter aussi l'API. Il y avait "à l'époque" une doc (format ODS je crois) qui nous avait permis de faire un script d'export du LDAP: https://github.com/cigalsace/ldapreader
Je ne la retrouve plus

[fvanderbiest]

https://github.com/georchestra/georchestra/blob/15.06/ldapadmin/functional-test.odt?raw=true plus très à jour => supprimé ...

[gryckelynck]

Je peux donc utiliser la valeur ou en minuscule pour le dn o=?

oui, en supprimant aussi les caractères spéciaux et espaces de préférence

Peut-on sinon créer un identifiant de type numérique ou autre?
Comment est généré cette valeur par la Console ou l'API?

[fvanderbiest]

Peut-on sinon créer un identifiant de type numérique ou autre?

Il vaudrait mieux éviter je pense, ne serait-ce que pour la lisibilité - https://github.com/georchestra/georchestra/blob/4fba03a21e7485e9bb618baba451bc03a8f28155/migrations/16.12/migrate-orgs.py#L75 fournit une routine de sanitisation...

[gryckelynck]

Il vaudrait mieux éviter je pense, ne serait-ce que pour la lisibilité

Ok, je vais me baser sur les noms cours.

Autre point pour être sûr d'optimiser le passage de notre annuaire en LDAP via CSV2LDIF.py
A partir de l'API, j'obtiens pour résultat:

{
    "uid": "me",
    "cn": "me",
    "sn": "(user)",
    "mail": "test@test.fr",
    "telephoneNumber": null,
    "description": "",
    "givenName": "me",
    "title": null,
    "postalAddress": null,
    "postalCode": null,
    "registeredAddress": null,
    "postOfficeBox": null,
    "physicalDeliveryOfficeName": null,
    "street": null,
    "l": null,
    "facsimileTelephoneNumber": null,
    "mobile": null,
    "roomNumber": null,
    "st": null,
    "homePostalAddress": null,
    "shadowExpire": null,
    "manager": null,
    "preferredLanguage": null,
    "org": "cra"
}

Je n'ai pas retrouvé certains champs dans le LDIF ou la console.
Cela signifie-t-il que l'ensemble de ces champs a une correspondance dans le LDAP/LDIF (laquelle?) ou est-ce des éléments résiduels?

[fvanderbiest]

Ce sont les champs standards de la classe inetOrgPerson, oui. Je pense qu'ils sont pris en compte par l'API ldapadmin (à vérifier)