Posté par ekacnet .
En réponse à la dépêche Samba 4.1.
Évalué à 8.
Symas (l'entreprise qui est derrière la majeure partie du développement de openLDAP) a maintenant deux développeurs qui travaillent à faire en sorte que Samba puisse de nouveau utiliser openLDAP comme stockage pour sa base de donnée SAMDB.
La tâche n'est pas simple pour plusieurs raisons:
Quand Samba utilise OL comme stockage ("storage backend"), la bibliothèque LDB va émettre des commandes LDAP pour lire et écrire dans OL, mais pour l'instant OL ne supporte pas les transactions sur les requêtes LDAP, toutes les requêtes en écriture sont définitives (pas de retour arrière ou "rollback"); c'est un gros problème car les transactions sont fréquemment utilisées en interne par Samba en particulier pour le protocole DRS (celui qui gère la réplication de la base sur tous les contrôleurs de domaines).
Il va falloir introduire la notion de transaction sur lDAP (en fait je crois que c'est déjà en cours chez OL) et l'utiliser.
Le développement de Samba utilise des notions d'intégration continue qui fait que chacun des commits dans le repository passe au travers ~1000 tests unitaires et de bout en bout où plusieurs variantes de Samba sont démarrées et testées (serveur de fichier, AD niveau 2003, AD niveau 2008, 2 contrôleurs, ...) il va donc falloir intégrer OL dans la mécanique pour qu'une série de tests soient fait avec OL comme base de stockage.
De nombreux tests de bout en bout échouent pour l'instant quand on utilise OL comme stockage, il va falloir résoudre ces problèmes.
Une fois ceci fait, OL pourra être utilisé comme base de stockage, mais attention il faudra encore à ce moment oublier l'idée d'envoyer des requêtes directement à OL, OL sera privatisé pour Samba et seul le serveur LDAP de Samba sera accessible.
Je sais que openLDAP va travailler aussi sur un "overlay" afin que OL soit de nouveau joignable sur les port habituels mais je pense que c'est pas mal de boulot donc il va falloir attendre.
Pour finir il faudra aussi oublier l'idée que l'on puisse mettre à jour une installation OL existante pour lui rajouter la personnalité AD, pour l'instant la commande "provision" de Samba part d'une base vierge. Partir d'une base existante va représenter à lui même un défi compliqué à résoudre et qui dans les cas compliqués ne pourra pas l'être car AD insiste pour avoir sa propre organisation de l'annuaire et son propre schéma qui ont des chances d'être incompatibles avec ceux de la base existante.
[^] # Re: Liaison LDAP SAMBA vers Openldap
Posté par ekacnet . En réponse à la dépêche Samba 4.1. Évalué à 8.
Symas (l'entreprise qui est derrière la majeure partie du développement de openLDAP) a maintenant deux développeurs qui travaillent à faire en sorte que Samba puisse de nouveau utiliser openLDAP comme stockage pour sa base de donnée SAMDB.
La tâche n'est pas simple pour plusieurs raisons:
Quand Samba utilise OL comme stockage ("storage backend"), la bibliothèque LDB va émettre des commandes LDAP pour lire et écrire dans OL, mais pour l'instant OL ne supporte pas les transactions sur les requêtes LDAP, toutes les requêtes en écriture sont définitives (pas de retour arrière ou "rollback"); c'est un gros problème car les transactions sont fréquemment utilisées en interne par Samba en particulier pour le protocole DRS (celui qui gère la réplication de la base sur tous les contrôleurs de domaines).
Il va falloir introduire la notion de transaction sur lDAP (en fait je crois que c'est déjà en cours chez OL) et l'utiliser.
Le développement de Samba utilise des notions d'intégration continue qui fait que chacun des commits dans le repository passe au travers ~1000 tests unitaires et de bout en bout où plusieurs variantes de Samba sont démarrées et testées (serveur de fichier, AD niveau 2003, AD niveau 2008, 2 contrôleurs, ...) il va donc falloir intégrer OL dans la mécanique pour qu'une série de tests soient fait avec OL comme base de stockage.
De nombreux tests de bout en bout échouent pour l'instant quand on utilise OL comme stockage, il va falloir résoudre ces problèmes.
Une fois ceci fait, OL pourra être utilisé comme base de stockage, mais attention il faudra encore à ce moment oublier l'idée d'envoyer des requêtes directement à OL, OL sera privatisé pour Samba et seul le serveur LDAP de Samba sera accessible.
Je sais que openLDAP va travailler aussi sur un "overlay" afin que OL soit de nouveau joignable sur les port habituels mais je pense que c'est pas mal de boulot donc il va falloir attendre.
Pour finir il faudra aussi oublier l'idée que l'on puisse mettre à jour une installation OL existante pour lui rajouter la personnalité AD, pour l'instant la commande "provision" de Samba part d'une base vierge. Partir d'une base existante va représenter à lui même un défi compliqué à résoudre et qui dans les cas compliqués ne pourra pas l'être car AD insiste pour avoir sa propre organisation de l'annuaire et son propre schéma qui ont des chances d'être incompatibles avec ceux de la base existante.