Slapd est le nom de l'implémentation d'un serveur LDAP au sein du projet libre de référence OpenLDAP.

Sur un slapd en version 2.4.44 installé sur un Debian Stretch (9), la fonctionnalité d'indexation, qui, comme sur un système de gestion de bases de données permet d'accélérer les recherches dans la base, a un comportement surprenant. Je vais énoncer ce que je trouve bizarre, je n'ai pas de réponse.

J'ai effectué mes essais sur deux serveurs fraîchement installés et dotés de la même configuration slapd (cela se vérifie avec un ldapsearch -Y external -H ldapi:/// -b cn=config + diff) et dans lesquels j'importe la même base de données (obtenue avec un slapcat) avec un slapadd.

La doc' OpenLDAP énonce que si l'on ajoute / supprime des index dans la configuration, l'indexation se fait en tâche de fond : « If this setting is changed while slapd is running, an internal task will be run to generate the changed index data. All server operations can continue as normal while the indexer does its work. If slapd is stopped before the index task completes, indexing will have to be manually completed using the slapindex tool. ». Je nuance :

• L'indexation ne débute pas forcément de manière automatique après la définition d'un nouvel index. On s'en rend compte car slapd occupe 0 % du CPU en permanence et la taille de la base de données (/var/lib/ldap/data.mdb) reste inchangée ;
  
  
• L'indexation peut conduire le serveur à ne plus répondre aux requêtes LDAP, trop occupé qu'il est à indexer les données. Dans mon cas, slapd a lancé 16 threads sur une machine dotée de 4 cœurs CPU, ce qui entraîne une charge de 17 et une absence de réponse à des ldapsearch, même en attendant plus de 20 secondes (la plupart des applications auront abandonnées avant…).

De même, je constate une grande variation dans la consommation de RAM par la fonctionnalité d'exploitation… Entre 29 % de la RAM de la machine consommée par slapd et 65 %, il y a quand même un écart non négligeable.

Si la taille de la base de données dépasse la taille maximale prédéfinie (1 Go), alors l'indexation s'arrête nette (car plus rien ne peut être écrit dans la base de données). Si l'on change la taille de la base de données en direct avec un ldapmodify, l'indexation ne reprend pas son cours (conso CPU nulle, taille de la base de données inchangée). Si l'on la force avec la commande sudo -u openldap slapindex, la taille de la base de données reste inchangée.

La taille de la base de données peut varier du tout au tout entre deux suppressions de la base de données puis re-création avec un slapadd :

• 338 Mo puis 301 Mo sur un producer avec peu d'index définis dans la conf' ;
  
  
• Plus de 8 Go sur un consumer, 1004 Mo sur un autre, les deux ayant un nombre d'index plus conséquent que le producer qui les alimentent ;
  
  
• On peut aussi passer de 1,9 Go à 314 Mo sur un consumer ;
  
  
• L'écart peut aussi se creuser : 4,6 Go contre 1004 Mo sur deux consumers avant l'ajout d'index supplémentaires, 8 Go contre 1004 Mo (taille inchangée, donc) après l'ajout d'index supplémentaires et un slapindex…
  
  
• À chaque fois, j'utilise un serveur vierge, la même configuration slapd et la même méthodologie pour installer slapd et importer les données… Lors de ma dernière tentative, l'écart entre mes deux consumers était d'environ 50 Mo, j'ai trouvé ça acceptable, je n'ai pas cherché plus loin, mais ma configuration actuelle est identique à celle avec laquelle slapd me générait 8 Go d'index sur un consumer et 1004 Mo sur un autre…

Soit une architecture LDAP reposant sur la version 2.4.44 de slapd (l'implémentation d'un serveur LDAP du projet de référence OpenLDAP). Nous avons un serveur pour l'écriture, et un autre pour la lecture.

Nous activons la réplication entre les deux. Source : le serveur d'écriture. Destination : le serveur de lecture. Point terminologie : désormais un master se nomme un producer et un slave se nomme un consumer. On passe donc d'une terminologie esclavagiste à une terminologie consumériste.

Pour superviser cette réplication, nous souhaitons utiliser le script check_syncrepl_extended qui compare les attributs « contextCSN » (une sorte de numéro de version d'une base de données LDAP) et les « entryCSN » (une sorte de numéro de version d'un objet au sein d'une BDD LDAP).

Nous importons une copie de la base de données depuis un serveur Debian 3.1 + OpenLDAP 2.2. Cette copie a été réalisée avec la commande slapcat -l copie_base_ldap.ldif. L'importation est réalisée en exécutant la commande slapadd -l copie_base_ldap.ldif sur notre producer.

On vérifie ensuite que la réplication a bien copié nos objets LDAP sur le consumer à l'aide du script présenté ci-dessus. Il nous informe que tous nos objets sont en erreur…

Si l'on active le mode debug avec le paramètre -d, on constate qu'un message d'erreur est affiché pour chacun de nos objets LDAP :

2019-01-07 17:01:55,947 - DEBUG : Found on ldap://producer.exemple:389 : uid=lala,ou=people,dc=monorganisation,dc=fr / 20181009070723Z#000029#00#000000
2019-01-07 17:02:00,547 - DEBUG : Found on ldap://consumer.exemple:389 : uid=lala,ou=people,dc=monorganisation,dc=fr / 20181009070723.000000Z#000029#000#000000
2019-01-07 17:02:05,441 - DEBUG : Check obj uid=lala,ou=people,dc=monorganisation,dc=fr
2019-01-07 17:02:05,441 - DEBUG : Obj uid=lala,ou=people,dc=monorganisation,dc=fr not synchronized : 20181009070723Z#000029#00#000000 <-> 20181009070723.000000Z#000029#000#000000

On constate que l'estampille temporelle stockée dans l'attribut « entryCSN » de chaque objet est codée différemment : sur le producer, on a une date+heure en seconde alors que l'on a une date+heure en microseconde sur le consumer. De même, le troisième champ de l'attribut a un nombre de zéro différent. On constate que le slapadd a repris tel quel le format présent dans la copie alors que la réplication a changé ce format.

Solution : j'ai désactivé la réplication du côté du consumer, j'ai supprimé la base de donnée (rm /var/lib/ldap/*), j'ai effectué un slapadd sur les deux serveurs puis j'ai réactivé la réplication.

J'ai testé la réplication : la modification, avec un ldapvi ou un ldapmodify, de tout objet sur le producer entraîne un changement de son entryCSN. Le tout est répliqué sur le consumer. Les deux entryCSN concordent donc nous pouvons utiliser un script de supervision qui s'appuie dessus.

Je retiens donc une différence de comportement entre un slapadd et une réplication.

Un documentaire diffusé en octobre 2018 sur Arte qui traite de la police prédictive.

Il permet de faire le point sur les techniques et méthodes qui existent à ce sujet (et ça fait froid dans le dos, notamment les petites dérives / interprétations personnelles des flics).

En revanche, aucun argument allant à l'encontre de ces technos est nouveau : qui défini les critères de dangerosité (pourquoi la criminalité en col blanc n'est-elle pas analysée ?) ? Pourquoi ces critères ne sont-ils pas publics ? Cela ne favorise-t-il pas un contrôle au faciès (le documentaire nous montre une intervention de police qui fait partie de cette catégorie) / préjugé (« Tu vis dans tel quartier ? C'est le quartier des receleurs, donc t'es suspect. C'est aussi le seul quartier où je peux vivre compte-tenu du montant des loyers…) ? Une probabilité, c'est juste une approximation d'un fait réel par des modèles mathématiques perfectibles, comme la météorologie. Si la désobéissance n'est plus permise, alors il n'y a plus d'espace politique, car il n'y a plus possibilité de faire évoluer la société vers de nouvelles pratiques. Si un crime n'a pas lieu car l'humain a été positivement influencé, faut-il le punir (c'est toute la trame narrative du film Minority Report) ?

Sur le contrôle au faciès, un doute me prend : si un flic décide de t'arrêter parce que t'es un « black à capuche » (exemple souvent cité dans le docu), quelle différence cela fait-il que le traitement qui a conduit à cette décision provienne d'un humain ou d'un logiciel programmé par un humain ?

Je note que, dès son commencement, ce film a un ton négatif : ce flicage permanent fait partie de nous, nous ne l'avons pas vu venir, tout est perdu d'avance, toute résistance est futile…

Mes notes :

• Les logiciels Prepod (USA), Beware (Canada) et Matrix (Londres) fonctionnent tous à peu-près de la même façon. Preprod : être arrêté en même temps qu'une autre personne (victime ou agresseur), analyse des fréquentations d'une personne (graphe social), calcul de la probabilité d'un délit (comme un cambriolage) par secteurs géographiques basé sur les événements délinquants précédents, etc. Beware : casier judiciaire, données financières auprès des organismes bancaires, numéro de téléphone, graphe social, etc. des habitants d'un appartement avant une intervention policière, etc. Matrix : analyse du graphe social, attribution de points de citoyenneté, établissement de listes de personnes à risque de basculer dans la délinquance et envoi de mises en garde "on pense que tu peux passer à l'acte, ne le fait pas" voire déplacement d'un agent de police, etc. ;
  
  
• Un délinquant, comme un cambrioleur, serait tout aussi routinier qu'une personne innocente, ce qui explique que des cambriolages se produisent au même endroit quelques jours après un premier signalement… L'argument "renforcer les patrouilles de police dans les secteurs géographiques jugés sensibles est inutile, car il y a un déport de la délinquance vers des secteurs jugés non sensibles" serait ainsi contre-carré ;
  
  
• Un système de calcul de la probabilité de la répétition d’un type de délit / crime dans un secteur géographique donné repose sur les signalements : si des infractions ne sont pas signalées, alors le calcul est faussé. Par conséquent : ceux qui signalent sont plus protégés que les autres… Donc des gens qui ont une tendance au signalement facile voire abusif sont plus protégés que les autres… C’est un biais : la police doit-elle vraiment se concentrer sur ceux qui signalent ou sur offrir un même niveau de service à toute la population ? Cela contribuera aussi à une évaluation différente de l’efficacité de la police prédictive : les gens qui signalent beaucoup auront une illusion de la sécurité et seront donc favorables au maintien de ce dispositif alors que les autres citoyens constateront une inefficacité du dispositif. Cette bipolarisation des avis entraînera des débats politiques sur l’intérêt de ces technos compliqués.
  
  
• Aux USA, des prises de vues aériennes (réalisées depuis un hélico) très haute définition cumulées d'une ville permettent de revoir une scène de crime à grande échelle, comme une flic qui se fait suivre depuis son domicile pour être assassiné durant son trajet ;
  
  
• Les éditeurs de logiciels de police prédictive, c'est un peu comme les géants du numérique : ils développent des outils de surveillance pour gagner du fric, au nom de la croissance, etc. Oui, ça forme une vaste toile, le capitalisme de surveillance.