Worteks - Expertise Open Source

Comment choisir votre composant Open Source - 1/3

2026-03-12T00:00:00+01:00

Cet article a pour objectif de lister les différents points à ne pas négliger quand on commence un projet intégrant des composants Open Source.

On va tout d’abord présenter l’impact économique de l’Open Source et de son emploi. On s’attachera ensuite à définir les critères de choix des composants, puis les contraintes associées. On terminera par quelques exemples du monde réel pour mettre en exergue les points d’achoppement et la difficulté de s’appuyer sur ces composants.

Toutes les parties de cet article sont accessibles ci-dessous :

Commençons par définir les besoins et les contraintes au niveau technique et économique, mais aussi juridique et organisationnel.

Rapide balayage historique

Le mouvement Open Source n’est pas récent. Il fut un temps où la notion de “propriété intellectuelle” n’existait tout simplement pas. Il faut attendre le 18ème siècle pour que soit instauré le droit d’auteur. Le partage était néanmoins limité par la difficulté de se procurer des supports à moindre coût. Les copistes du Moyen-Age étaient un parfait exemple de système de partage de connaissances, certes limité à un domaine assez restreint…

Dans le domaine de l’informatique, le partage de code et de spécifications se pratique très vite. Les RFC (“Request for Comments”) sont publiées à partir de 1969. Toutefois, le partage de code a existé depuis au moins1955, quand les membres du groupe SHARE mettaient à disposition de tous les modifications logicielles du code tournant sur des serveurs IBM.

Le mouvement “Open Source” se développe fortement dans les années 1980 et 1990. On parlait alors de “free software”. Mais pour supprimer l’ambiguïté du mot “free”, le terme Open Source a été validé qu’en 1998.

À cette même période, voient le jour des projets comme GNU et Linux et des fondations comme The ASF, qui deviennent rapidement des acteurs incontournables de l’Open Source. Considérés comme un “cancer” par certains gros éditeurs, ils vont effectivement métastaser l’écosystème, au point qu’il est difficile aujourd’hui d’imaginer un développement informatique ne comportant pas de composants Open Source. Et cela sans tuer les sociétés qui les utilisent ;-)

L’OSS en 2026

On peut donc considérer qu’en 2026, l’Open Source (OSS) est partout. Dans l’étude “The Value of Open Source Software”^[1], on peut lire :

…recent studies have come to similar conclusions showing that open source software (OSS) – software whose source code is publicly available for inspection, use, and modification and is often created in a decentralized manner and distributed for free – appears in 96% of codebases (Synopsys 2023), and that some commercial software consists of up to 99.9% freely available OSS (Musseau et al., 2022)

La quasi totalité du logiciel produit s’appuie donc sur des composants Open Source. Il est illusoire d’imaginer un retour en arrière.

Quelle est la valeur de l’OSS et comment la mesurer ?

Se pose la question de la valorisation de l’Open Source et de son coût. Tout d’abord, on peut évaluer son coût de “remplacement”, à savoir combien coûterait le développement des composants Open Source si chaque acteur économique les utilisant devait les réécrire, ou les acheter. Sur quelle base cette valorisation est-elle effectuée ? Un produit commercial a une valeur théorique qui correspond à un prix de vente multiplié par une quantité vendue. Dans le cas de l’Open Source, le prix de vente peut être considéré comme nul (même s’il est toujours possible de vendre un logiciel Open Source, si on trouve un acheteur…). On calcule alors la valeur de remplacement à partir :

du coût du logiciel s’il devait être réécrit,
du nombre d’entreprises l’utilisant,
Ou de l’achat d’un logiciel propriétaire équivalent, avec le coût du support récurant.

L’étude “The Value of Open Source Software” citée plus haut donne cette évaluation :

Le coût de remplacement s’élèverait à 8,8T$, soit environ le PIB du Japon et de l’Inde combinés.
Le coût d’écriture unitaire représenterait 4,15G$.
Les acteurs économiques dépenseraient 3,5 fois plus en logiciels si l’Open Source n’existait pas.

Un petit exemple

Apache Directory Studio est un logiciel assez largement utilisé dans le monde LDAP.

Il comporte environ 260 000 lignes de code (sans compter les sauts de ligne ou les commentaires, ce qui en double le nombre), soit 10 millions de dollars (selon le modèle COCOMO - Constructive Cost Model -). Le remplacement de ce logiciel Open Source représenterait un effort total de 2,7 ans pour une équipe de 26 développeurs.

En réalité, Apache Directory Studio a été développé à 98% par 3 personnes. Le projet a démarré il y a 20 ans même si l’essentiel du travail s’est concentré sur 7 années.

Il est donc clair que les contraintes du monde professionnel ne s’appliquent pas à l’Open Source, en général. Néanmoins cela donne une idée de ce que peut représenter le coût du développement d’un logiciel Open Source.

Les choix techniques

Bien choisir un composant est essentiel, puisqu’on ne va pas le réécrire. Il est primordial de déterminer les critères de sélection. Ils se répartissent en deux catégories :

Les critères mesurables
- L’adéquation au besoin
- La compétence interne sur le composant choisi
- Les performances attendues du composant
- L’intégration avec les autres composants
- Les limitations du composant
- La facilité à administrer et à monitorer le composant
Les critères non mesurables
- La maintenance du projet d’où est issu le composant
- La possibilité d’y apporter des corrections
- La qualité de la documentation
- Le support des failles de sécurité

Cette liste n’est pas exhaustive, mais représente tout de même un ensemble de points pertinents permettant de comparer les composants disponibles et de faire un choix.

Les critères mesurables

De toute évidence, le composant doit répondre à votre besoin technique et fonctionnel. C’est la première étape. Pour valider cette adéquation, il convient de conduire des tests et de réaliser des études de cas ainsi qu’une évaluation fonctionnelle.

Cela suppose que les personnes en charge de cette étude aient la compétence requise pour la mener à bien ou aient recours à des compétences extérieures, ce qui engendre un coût supplémentaire.

La notion de performance est importante, elle sera un des facteurs de dimensionnement de la plateforme sur laquelle tournera le logiciel. Il faut tenir compte des effets de saturation, où les performances peuvent diminuer de façon non linéaire.

L’intégration est à mettre en regard des technologies déjà utilisées et maîtrisées (langage, OS, etc). De même les APIs doivent être étudiées avec soin pour s’assurer qu’elles sont adaptées au besoin.

Un composant Open Source a des limitations, de même qu’un composant privatif. S’il est possible de demander des corrections et des évolutions à une société commerciale, c’est beaucoup plus compliqué pour un projet Open Source, dont le développement est généralement assuré par des volontaires.

Enfin une fois le composant intégré, il faudra le maintenir : montées de versions, analyse des problèmes, corrections des anomalies, sans compter la formation des utilisateurs.

Tout ces critères mesurables vont représenter un coût à internaliser, qu’il ne faut pas négliger lors du choix.

Les critères non mesurables

Ils regroupent les facteurs qu’il n’est pas possible d’évaluer techniquement.

Quand on choisit un composant Open Source, on choisit une communauté : celle qui développe et maintient le produit. Cette communauté n’a aucune obligation autre que celles qu’elle s’impose. Il faut en être conscient, accepter ce risque et l’intégrer dans son plan produit. Un composant Open Source développé au sein d’une fondation comme The ASF ou Eclipse Foundation offre tout de même une garantie plus poussée de pérennité et de qualité sur le long terme, du fait des contraintes imposées aux projets. Par exemple, en ce qui concerne The ASF, on peut citer ces règles :

Un projet ne peut rejoindre la fondation que s’il a atteint un niveau de maturité suffisant.
Il doit passer par une phase d’incubation sous la supervision d’au moins trois membres de la fondation.
Il ne peut sortir de l’incubation tant qu’une release n’a été fournie.
Un projet doit disposer d’au moins trois participants actifs de trois sociétés différentes, ce qui interdit la main-mise d’une seule entreprise sur ce projet.
Des revues trimestrielles sont à fournir au Board par le responsable de chaque projet.
Enfin un projet inactif sera reversé dans l’Attic.

Il est également possible de corriger par soi-même une anomalie critique ou bloquante, ou de développer une fonctionnalité manquante, puisqu’il s’agit d’Open Source. Reste à savoir dans quelle mesure ces corrections ou ajouts vont être intégrés dans les futures versions. Le risque étant d’avoir à maintenir un “fork”.

Un autre aspect qui est souvent reproché aux composants Open Source est la qualité de la documentation. Les projets Open Source n’ont pas nécessairement les moyens de disposer de rédacteurs techniques en charge de la documentation, et c’est généralement du “best effort”. Il n’est pas rare d’avoir des composants dont la seule documentation est le code source, et l’API exposée. Internet reste souvent un moyen d’obtenir l’information manquante, en s’appuyant sur la communauté des utilisateurs.

Enfin il faut tenir compte de la capacité d’une communauté Open Source à prendre en compte les failles de sécurité critiques. L’information est généralement fournie trop tard, lorsqu’elle est déjà publique. En effet, il y a rarement une politique d’alerte privée permettant d’informer les utilisateurs principaux avant la divulgation de la faille corrigée, ce qui est plutôt logique étant donné qu’un projet Open Source ne connaît pas ses utilisateurs (sauf cas d’espèce). Si un processus documenté de gestion des CVE (Common Vulnerabilities and Exposures) existe déjà, c’est un plus. The ASF dispose d’un tel processus^[2], par exemple.

Au final, il est compliqué d’associer un coût à ces critères, mais il est nécessaire à tout le moins de les intégrer en terme de gestion du risque.

Les choix organisationnels

Les éléments qui doivent être pris en compte lors du choix d’un composant Open Source sont également directement liés à des choix organisationnels :

Disponibilité des ressources internes,
Disponibilité de support,
Vitalité du projet,
État de la communauté,
Type de communauté.

Le composant sélectionné doit être pris en main par les équipes internes. Il leur faut l’intégrer, en comprendre le fonctionnement, le tester, valider les performances par rapport aux besoins, gérer les alarmes, le monitorer… En un mot, se l’approprier.

Il est possible d’employer des consultants externes connaissant le composant, encore faut-il les trouver ! Plus le composant est connu, plus il est facile de trouver une ressource externe.

On peut également se poser la question du support : les composants les plus connus sont généralement supportés par de nombreuses entreprises. Reste à qualifier leur niveau de compétence…

Un aspect à ne pas négliger est l’état de la communauté autour du projet. Y-a-t-il une liste de diffusion sur laquelle envoyer les questions que l’on se pose ? Est-elle active ? Les releases sont-elles fréquentes ? Les anomalies remontées sont-elles prises en charge rapidement et efficacement ? Plus généralement, combien y-a-t-il de participants actifs ? Github permet par exemple de vérifier l’activité sur une période de temps afin de se rendre compte si le projet est toujours activement maintenu et développé, pour autant qu’il soit hébergé sur cette plateforme.

Quand aux contributeurs, il faut également se poser la question de leur implication et du cadre de leurs contributions. S’ils sont salariés par des entreprises qui financent leurs travaux, la question de savoir s’ils continueront en cas de changement de cadre professionnel se pose. L’âge des contributeurs est également un facteur à prendre en considération : personne n’est éternel (et chacun va prendre sa retraite à un moment donné…) !

Enfin le type de communauté donne une idée de la direction que peut prendre un projet. Il existe plusieurs modes de fonctionnement, du ‘‘one man show’’ en passant par le BDFL (Benevolent Dictator For Life) jusqu’à un système totalement décentralisé sans direction formelle, où les décisions se prennent collégialement. En pratique, on se trouve souvent confronté à de très petites communautés, ou bien à des communautés adossées à des entreprises commerciales.

Les choix économiques

À ne pas négliger ! Sauf à disposer d’une équipe “couteau suisse” capable de prendre en charge la totalité des composants choisis, il sera sans doute nécessaire d’avoir recours à des experts sur quelques composants essentiels. Et ce n’est pas gratuit !

L’alternative est de souscrire à un contrat de support, ce qui se pratique fréquemment. On entre alors dans un modèle proche de celui d’un éditeur logiciel dont on a acheté un produit, le prix du produit en moins. En réalité, c’est ainsi que se financent de nombreux éditeurs Open Source.

Si votre composant est amené à être exécuté dans le cloud, ou si vous recourez à un service PaaS, il y aura des coûts induits, qui peuvent être conséquents. De nombreux éditeurs logiciels Open Source ont modifié leur modèle de licence pour interdire l’utilisation de leurs produits par des fournisseurs PaaS pour des raisons évidentes. L’impact est alors majeur pour les utilisateurs. Par exemple, une base de données comme MongoDB ne peut pas être utilisée dans sa version Open Source en mode “as a service”. Les coûts peuvent vite se monter à plusieurs dizaines de milliers d’euros par mois pour des volumétries importantes, si on a recours à des solutions basées sur ce produit.

Globalement, les services de type PaaS ne sont pas gratuits et nécessitent une évaluation de l’impact financier lié à ce choix.

Les choix juridiques

Un dernier aspect à prendre en compte, qui n’est pas le moins important, est le type de licence du composant. Toutes les licences Open Source ne se valent pas, certaines sont permissives, d’autres non. Il est primordial d’en comprendre les tenants et aboutissants avant d’opter pour une solution. Il y a trois grandes catégories de licences :

“copyleft”, ou “contaminantes” : GPL et dérivées. Ce type de licence impose que les versions dérivées sont soumises aux règles de la licence d’origine.
“Permissives” : AL, MIT, BSD… Ce type de licence autorise l’utilisation des composants sans imposer de règles autre que celle de tracer la paternité du code (en l’occurrence, rendre accessible le texte de la licence dans le produit final).
“Asymétriques” : Il s’agit de licences autorisant l’utilisation du composant dans un certain cadre, tout en limitant son usage en dehors de ce cadre. C’est, par exemple, une autorisation d’utiliser le composant pour le propre usage d’une entreprise, mais une interdiction d’en permettre l’usage pour les clients de cette même entreprise.

Il existe plusieurs dizaines d’autres licences. Il est nécessaire d’en faire le recensement et d’en étudier les contraintes juridiques avant d’intégrer les composants associés. A ce titre, il peut être judicieux de recourir aux conseils d’un juriste.

Enfin, il faut tenir compte des dépendances transitives ! Un composant Open Source n’arrive jamais seul, il est la plupart du temps lui même consommateur d’autres composants Open Source. Il convient de faire l’étude de chacune de ces dépendances pour faire son choix en connaissance de cause.

Le document produit par The Linux Foundation^[3] donne une idée assez précise de ce qu’il convient de prendre en compte lors d’une étude de “compliance” d’un composant.

Lire la suite : Open Source et développement - Partie 2 : Versions, licences, évolutions et maintenance, la vie du composant Open Source après son intégration

Bibliographie

[1] The Value of Open Source Software
[2] ASF Project Security for Committers
[3] Open Source Compliance

Questions ouvertes : bugs, IA, souveraineté et autres - 3/3

2026-03-12T00:00:00+01:00

Cet article a pour objectif de lister les différents points à ne pas négliger quand on commence un projet intégrant des composants Open Source.

Toutes les parties de cet article sont accessibles ci-dessous :

Une fois ce panorama (partiel) présenté, certaines questions restent en suspens. Ce dernier chapitre va essayer de les lister, sans prétendre à l’exhaustivité.

Quid de la longévité ?

Ayant recherché un composant récemment pour un besoin client, voici le dernier message posté sur la page du projet^[13] :

“This repository is now archived. Thank you all for your excellent contributions. May it continue to live in all your wonderful forks.” OPENLDAP Exporter

C’est juste un exemple, et fort heureusement il a été forké 65 fois, mais cela ouvre d’autres questions :

Quel fork utiliser ?
Quelle garanties a-t-on que le fork que l’on choisira survivra ?
Le problème ne va-t-il pas se reproduire ?

Encore une fois, dans le monde Open Source, l’utilisateur est le responsable de ses choix. Ceux-ci doivent être pesés.

La gestion des CVEs

Les CVE sont des failles de sécurité identifiées. Elles couvrent l’ensemble des logiciels depuis 1999. Ce système d’alerte est géré par The MITRE Corporation. Aujourd’hui, il s’agit de la référence conservant toutes les failles connues et elle est alimentée en continue. Le 15 avril 2025, le contrat qui liait cette organisation et le gouvernement américain a été rompu par ce dernier à la veille de la date d’expiration contractuelle^[14]. Vu l’urgence, une extension de 11 mois a été mise en place, mais rien n’est prévu sur ce qui se passera en avril 2026… On peut légitimement se poser la question de savoir pourquoi l’industrie ne finance pas ce service essentiel.

En Europe, un service équivalent (EUVD, European Union Vulnerability Database^[15]) a été mis en place et délégué à l’ENISA^[16].

Que faire en cas de bug ?

Donc vous avez trouvé un bug dans un des composants que vous utilisez. Quelle est la démarche à suivre ? Il n’y a pas de procédure toute faite.

La première démarche est de vérifier que ce bug n’a pas été corrigé dans une version plus récente. Si ce n’est pas le cas, peut-être qu’un ticket d’anomalie a déjà été rempli ? Sinon, le plus simple est de créer un nouveau ticket. Mais encore faut-il que le projet propose un mécanisme qui le permette. Si le projet est sous GitHub, par exemple, vous pouvez certainement remplir un rapport d’anomalie (mais attention, tous les projets sous GitHub ne le permettent pas). Si le projet dispose d’un système de gestion des anomalies (JIRA, Redmine, Mantis, Bugzilla, etc), c’est sans doute votre point d’entrée. Une autre solution pourrait être de poster un message sur la liste de diffusion du projet, à condition qu’il y en ait une… Comme on le voit, il n’y a pas de mécanisme standardisé pour signaler une anomalie, chaque projet les gère à son gré et il faut en tenir compte.

En espérant qu’une correction sera proposée ! Et si ce n’est pas le cas, mais qu’on est à même d’apporter cette correction, la question suivante est de savoir comment la gérer : faut-il forker le projet en attendant une éventuelle release ?

Dans tous les cas, les utilisateurs sont fortement encouragés à remonter les anomalies et idéalement à proposer des patchs sous toutes formes possibles.

Et l’IA ?

Un nouveau venu est en train de bouleverser la façon dont on développait : l’IA. Depuis un ou deux ans, les progrès des solutions basées sur des LLM permettent de générer du code qui n’est pas totalement inutilisable. On prétend même que ces IA vont remplacer les développeurs, qui ne seront plus que des prompteurs avec une productivité 10 fois supérieure…

On peut rêver. En attendant, cela pose quand même un certain nombre de questions :

Quel est la qualité du code proposé par ces IAs ?
Quid de la licence ?
Qu’en est-il des tests associés ?
Les rapports d’anomalies générés par des IAs sont-ils pertinent ?
Quel sera le coût de ces solutions à long terme ?

Aujourd’hui, de nombreux mainteneurs de projets Open Source se plaignent d’être inondés de propositions de correction de piètre qualité générées par des IA. Le temps passé à relire les propositions, à les tester et à les corriger n’est pas forcément en rapport avec le gain obtenu. Sans compter les faux positifs à éliminer.

De plus, on peut se poser la question du coût d’usage de ces outils. S’ils sont aujourd’hui quasi gratuits, ils risquent de devenir payants quand les sociétés qui ont investit des dizaines de milliards de dollars dans ces solutions demanderont un retour sur investissement.

Certains sites se protègent (difficilement) contre ces robots en tentant de leur interdire l’accès aux sources. En effet, ces requêtes incessantes consomment de la bande passante et du temps CPU, ce qui se traduit en frais d’hébergement en forte augmentation. Le second problème est qu’on risque d’aboutir à une “moyennisation” des solutions proposées, puisque l’alimentation de ces outils se fait par la récupération des sources sur internet. A partir du moment où les IA se mettent à produire du code qui sera intégré dans les bases, elles vont se nourrir de ce qu’elles ont elles-même produit. Il ne faut pas oublier qu’il s’agit d’outil de génération probabilistique.

Sans vouloir dépeindre un tableau apocalyptique, il est important de questionner la portée de ces outils et d’en faire un usage raisonné.

Qui finance ?

La grande question… Puisqu’il s’agit d’Open Source, le modèle économique est compliqué à identifier. Aujourd’hui on peut considérer que les contributions sont financées de différentes façons :

Par de grosses sociétés comme Google, IBM, Microsoft, qui ont une politique Open Source assez poussée.
Par des fondations qui assurent non pas le financement des développements, mais au moins l’infrastructure nécessaire à sa mise à disposition. C’est le cas des fondations Apache ou Eclipse, etc.
Par des organisations gouvernementales qui couvrent tout ou partie des développements (NGI, NLNET…).
De nombreuses PMI/PME qui soit utilisent des composants et les maintiennent, soit développent ces composants en les mettant à disposition, soit ont une politique de contribution.
Par des initiatives publiques ou privées (Bug Bounties, GitHub sponsoring…).
Mais également par beaucoup de personnes travaillant sur leur temps personnel.

Parlons de souveraineté

L’Open Source n’a pas de frontière mais… savez-vous que les USA peuvent interdire l’accès à GitHub à certains pays, comme l’Iran ? Cela a été le cas jusqu’en 2021.

Il peut être utile de se poser la question de la disponibilité de certains composants en terme de souveraineté. Pendant de nombreuses années, toute partie de code qui relevait de la cryptographie relevait de mesures d’autorisation d’exportation de la part du gouvernement américain. Rien n’interdit de penser que des règles plus strictes pourraient être imposées.

L’Open Source offre plus de souplesse que le code privatif, mais il convient de rester prudent. Les demandes récurrentes de la mise en place de backdoors par les administrations sont autant d’éléments inquiétants, par exemple.

Sans aller jusqu’à la paranoïa, il semblerait utile que les administrations s’approprient l’Open Source, non seulement en tant qu’utilisatrices, mais également en tant qu’actrices au sein de projets d’importance vitale. Voilà un autre débat, qui ne sera pas ouvert ici et ce long post de blog se clôturera sur ce point en suspens !

Bibliographie

[13] OpenLDAP exporter
[14] CVE program averts swift end after CISA executes 11-month contract extension
[15] European Union Vulnerability Database
[16] ENISA

La vie du composant Open Source après son intégration - 2/3

2026-03-12T00:00:00+01:00

Cet article a pour objectif de lister les différents points à ne pas négliger quand on commence un projet intégrant des composants Open Source.

Toutes les parties de cet article sont accessibles ci-dessous :

Après avoir défini les critères de choix des composants, nous allons étudier les éléments techniques permettant d’effectuer un choix éclairé.

Les versions

Généralement, un composant Open Source est utilisé dans sa dernière version, mais ce n’est pas toujours le cas. Il est parfois nécessaire d’opter pour une version antérieure.

Du fait du nombre limité de contributeurs, il est rare que plusieurs versions d’un composant soient maintenues. Il faut s’en assurer quand on fait son choix et comprendre que l’impact d’une montée de version peut être important.

La plupart des projets utilisent la notation “Semantic Versioning”, avec des versions utilisant la notation X.Y.Z :

X représente les versions majeures, qui ne sont pas compatibles entre elles. L’introduction de modifications dans l’API est souvent la raison de ce changement de version.
Y représente les versions mineures, qui restent compatibles. L’introduction de nouvelles fonctions ne cause pas de modification de l’API, la nouvelle version reste utilisable sans changement du code qui s’appuie sur le composant.
Z représente les correctifs apportés au composant, sans changement de l’API.

Ce type de notation n’est pas universel. Une autre logique relativement récente consiste à livrer de nouvelles versions incrémentales fréquemment. Les utilisateurs doivent alors prendre en charge les ruptures techniques à chaque changement de version. On pourrait par exemple citer les navigateurs Chrome ou Firefox qui ont un cycle de release particulièrement court (environ une par semaine). Dans tous les cas, une veille technologique est indispensable. Des outils de suivi existent, tel Dependabot qui permet de savoir au jour le jour quel composant a changé de version.

Un autre aspect important concerne l’environnement dans lequel s’exécute le projet. Il est parfois nécessaire de maintenir un projet utilisant de vieilles versions d’un langage (par exemple Java 8) ou d’une version d’OS. En pratique, il suffit souvent de vérifier le bon fonctionnement dans les différentes versions d’un environnement. L’impact est clair : cela interdit souvent l’utilisation des dernières fonctionnalités. Néanmoins il faut être conscient que l’abandon d’une version impacte une quantité non négligeable d’utilisateurs.

Le problème est que la fréquence des releases tend à s’accroître, augmentant ainsi la charge de travail. Il n’est pas à exclure que cela devienne une difficulté de plus en plus importante, dans la mesure où un projet s’appuie sur des librairies, utilisées dans un framework logiciel qui s’appuie à son tour sur un container applicatif, lui-même exécuté dans une plateforme logicielle, dans une machine virtuelle ! Par exemple, Log4J utilisé dans une application Spring, tournant sur Tomcat, dans Docker, sur VMWare…

Pour illustrer ce propos, cette image représente les versions de l’API Apache LDAP téléchargées au mois de décembre 2025 : plus de 39 versions différentes, certaines datant de 12 ans (!!!) sont toujours utilisées…

Les évolutions

On devra donc prendre en compte les évolutions de l’environnement d’exécution qui sont liées à plusieurs facteurs :

Les versions de l’OS,
Les versions de containers,
Les évolutions du ou des langages utilisés,
Les évolutions des librairies utilisées.

À cela s’ajoute les potentiels conflits de versions : il n’est pas rare que plusieurs composants intègrent eux-mêmes des librairies dont les versions sont incompatibles. C’est ce qu’on appelle classiquement le “dependency hell”.

En Java, cela peut se résoudre par l’utilisation d’une plateforme de service comme OSGi, qui permet d’isoler les composants entre eux. Il existe d’autres solutions, par exemple en JS où un composant va charger tout le code dont il dépend pour former un bloc de code autonome, au prix d’une croissance du code…

Dans tous les cas, il convient d’avoir en tête que cette gestion incombe au projet et que cela peut rapidement devenir complexe.

Les dépendances transitives

Pour aller plus loin, il est important de tenir compte des dépendances transitives, c’est à dire des dépendances utilisées par les composants choisis. C’est évidement récursif et il n’est pas rare d’avoir plusieurs niveaux de profondeur (ici, 9) :

[INFO] org.apache.directory.server:apacheds-installers:pom:2.0.0.AM28-SNAPSHOT
[INFO] +- org.apache.directory.server:apacheds-service:jar:2.0.0.AM28-SNAPSHOT:compile
…
[INFO] |  +- org.apache.directory.server:apacheds-service-builder:jar:2.0.0.AM28-SNAPSHOT:compile
…
[INFO] |  |  +- org.apache.directory.server:apacheds-http-integration:jar:2.0.0.AM28-SNAPSHOT:compile
[INFO] |  |  |  +- org.apache.directory.server:apacheds-http-directory-bridge:jar:2.0.0.AM28-SNAPSHOT:compile
[INFO] |  |  |  \- org.eclipse.jetty:jetty-webapp:jar:9.4.56.v20240826:compile
[INFO] |  |  |     +- org.eclipse.jetty:jetty-xml:jar:9.4.56.v20240826:compile
[INFO] |  |  |     |  \- org.eclipse.jetty:jetty-util:jar:9.4.56.v20240826:compile
[INFO] |  |  |     \- org.eclipse.jetty:jetty-servlet:jar:9.4.56.v20240826:compile
[INFO] |  |  |        +- org.eclipse.jetty:jetty-security:jar:9.4.56.v20240826:compile
[INFO] |  |  |        |  \- org.eclipse.jetty:jetty-server:jar:9.4.56.v20240826:compile
[INFO] |  |  |        |     +- javax.servlet:javax.servlet-api:jar:3.1.0:compile
[INFO] |  |  |        |     +- org.eclipse.jetty:jetty-http:jar:9.4.56.v20240826:compile
[INFO] |  |  |        |     \- org.eclipse.jetty:jetty-io:jar:9.4.56.v20240826:compile
…

Il faudra vérifier toutes les dépendances transitives, leur licence, leur version, leur signature. Ne pas négliger non plus qu’un repository peut également avoir été attaqué ou certaines dépendances avoir été modifiées…^[4]

Les SBOMs, une solution ?

Le SBOM (Software Bill Of Material, ou Nomenclature Logicielle) est la liste officielle des dépendances. Il permet de contrôler les licences, de lister les dépendances transitives, de donner la version de chaque composant, de vérifier les signatures et éventuellement d’identifier les CVE associées aux versions utilisées. Il peut (et devrait !) être généré automatiquement. Il existe des outils qui génèrent le SBOM en différents formats, par exemple :

Pour CycloneDX^[5], qui fonctionne pour C/C++, Node.js, Python, Go, Ruby, Java, .NET, PHP, Javascript.
Pour SPDX^[6], qui fonctionne pour Java, Python et Go.

Ils génèrent une liste des dépendances, leur version, leur licence…

L’importance de cette nomenclature n’est pas à négliger. Un “Executive order”^[7] a stipulé qu’un logiciel ne peut être utilisé par une entité publique aux USA si un SBOM n’est pas fourni. Par ailleurs, en Europe, le Cyber Resilient Act (CRA) en a fait un prérequis et le SBOM doit être livré en même temps que la documentation.

Il s’agit donc d’un élément de confiance à fournir, qui ne règle certainement pas tout, mais permet de s’assurer que l’utilisateur dispose de la liste des composants embarqués, ce qui simplifie le travail des utilisateurs.

Les licences

Dans le cadre du développement d’un produit, il faut définir la licence d’utilisation. Il n’est pas toujours possible de choisir celle que l’on souhaite adopter pour son produit. Dans certains cas, l’utilisation de composants Open Source impose le choix de la licence à utiliser.

Comme indiqué plus haut, la catégorie de licence à laquelle appartiennent les composants utilisés peut imposer le choix. C’est le cas de la licence GPL, qui est dite “contaminante”. Si vous choisissez une licence permissive, vous devrez en faire mention dans votre code et cette mention devra être accessible aux utilisateurs. Prenez votre iPhone, par exemple, allez sur Réglage -> Général -> Mentions légales et certifications -> Mentions légales, vous y trouverez la liste de toutes les licences de chaque composant utilisé. Et il y en a beaucoup ;-)

Quels sont les risques à ne pas respecter les licences, ou à en choisir une qui ne soit pas adaptée ? En réalité, tout dépend de la provenance du composant utilisé. Si celui-ci est maintenu par une société disposant d’un service juridique solide, cela peut s’avérer coûteux. En pratique, les deux risques principaux sont surtout l’obligation de publier l’intégralité de ses sources, si on a choisi un composant GPL par exemple, et l’obligation de basculer sur un autre composant dans un délai assez court. Dans tous les cas, ce n’est ni agréable, ni simple. Autant faire le bon choix dès le départ.

Le support

Partant du principe que le choix du composant a été effectué en tenant compte des différents points exposés précédemment, la suite logique est de se préoccuper de la vie de ce composant. Qui dit logiciel dit bugs, évolutions, améliorations… et l’obligation d’en tenir compte. On cherche ici à comprendre quels sont les besoins en support, qui en est responsable et les modalités de maintenance du composant choisi.

Quoi ?

La première étape est d’identifier les besoins. Cela passe par la qualification du composant sur les points suivants :

Sa criticité dans la solution construite.
La façon dont on a détourné les anomalies ou les manques fonctionnels lors de l’intégration.
Le niveau de performance obtenu et attendu dans un futur proche ou moins proche.
La présence ou non de système de supervision, de gestion d’alertes, de logs.

Il faut aussi tenir compte de la façon dont on l’utilise, selon qu’il est intégré au produit, ou hébergé (solution PaaS ou SaaS). Chacun de ses points doit être géré en amont et tout au long de la vie du produit.

Qui ?

Une fois que l’on sait ce qu’on attend d’un composant et ce qu’implique son usage, se pose la question de la responsabilité de son intégration et de sa maintenance en condition opérationnelle.

Il est possible de devenir un membre actif de la communauté, bénéficiant ainsi d’un levier important sur l’évolution du composant. C’est une des raisons pour lesquelles les éditeurs de logiciels recrutent des membres de communautés actives. Le cas de Red Hat est assez significatif, mais ce ne sont pas les seuls. Le bémol étant que la communauté est généralement diverse et que des agendas différents peuvent entrer en conflit.

On peut aussi s’appuyer sur la communauté pour obtenir un support. Rien n’est garanti, mais cela fonctionne étonnamment bien. L’être humain est doué d’empathie et, à condition de demander poliment, on obtient généralement les réponses à ses questions. Reste à voir dans quel délai…

Enfin, on peut aussi avoir recours à des experts externes (consultants, sociétés spécialisées dans le logiciel libre). La principale difficulté est la disponibilité de ces experts, leur coût et leurs compétences réelles. On peut également passer un contrat de service, charge au contractant de faire sienne cette recherche de compétences disponibles.

Comment ?

Une fois identifiée la ou les ressources pouvant répondre au besoin de support à court, moyen ou long terme, reste à définir un cadre de travail.

Dans le cas où le projet internalise ces ressources, il faudra prévoir des formations et/ou des embauches. Et sur une durée longue. L’acquisition de compétences internes est une solution solide.

L’alternative immédiate est le recours à des ressources externes. Il faut s’assurer de la compétence des intervenants, de la surface couverte par le prestataire et du coût induit. Cette solution a l’avantage de ne pas nécessiter une présence permanente : on peut y faire appel ponctuellement en fonction des besoins.

Il est également possible de ne pas internaliser le composant, mais de le ‘louer’, c’est la solution PaaS. L’avantage c’est qu’on s’adresse à une entité dont c’est le cœur d’activité, elle a donc un bon niveau de connaissance et de maîtrise du composant. C’est une solution absolument classique dès qu’on parle d’hébergement de sites web ou de bases de données. L’inconvénient est son coût, à quoi s’ajoute le risque de Vendor Lock-in : changer d’hébergeur n’est jamais simple. On l’a constaté lors du récent changement tarifaire chez VMware, la migration vers des solutions moins coûteuses (Proxmox par exemple) ne s’est pas faite sans peine…

Enfin la dernière possibilité est d’estimer que le composant est fiable, qu’une fois qu’il est intégré il n’y a pas lieu de s’en préoccuper et que, dans le pire des cas, on trouvera toujours une solution. Cela peut sembler inconséquent, mais c’est une pratique assez courante quand il s’agit de composants non critiques ou relativement simples. Les outils de test (Junit ou autre), de log (Log4J), les petites briques simples (il y en a des milliers dans le monde JS) sont fréquemment gérés de cette façon. Les risques sont de deux ordres :

L’abandon du composant, qui n’évolue plus, faute de développeur,
La faille de sécurité (CVE) qu’il faut corriger en urgence.

Sur ce second point, on a tous en mémoire les mésaventures de Log4J. Vous pouvez regarder la présentation qui a été faite en 2022 à ce sujet^[8] et l’histoire de la correction du bug par celui qui était en charge du projet Log4j2^[9].

Forker ou pas ?

Il y a de multiples raisons pour vouloir forker un composant. Il y a également de multiples raisons de ne pas le faire ;-)

Quand est-il intelligent de forker un composant ? Voici quelques raisons pertinentes :

Quand la gouvernance du projet est inadaptée : exemple avec BDFL qui devient un Dictateur tout court, communauté fermée, projet focalisé sur un agenda commercial, projet en état de mort cérébrale, etc.
Quand le projet change de “propriétaire” et que le nouveau ne respecte plus l’esprit initial du projet, ou risque de ne plus le respecter. Ça a été le cas de Hudson (remplacé par Jenkins après son rachat par Oracle), MySQL (remplacé par MariaDB après son rachat par SUN), OpenOffice (devenu Libre Office après son abandon par Oracle). Les exemples sont nombreux.
Quand le projet n’est simplement plus maintenu. L’exemple le plus notable est le serveur Web NCSA qui a donné naissance à Apache httpd.

Mais il y a également autant de cas où forker est simplement une perte de temps ou une dilution de l’effort commun.

L’exemple de OpenSSL

L’histoire de OpenSSL est intéressante. Le projet a commencé comme un fork d’un autre projet (SSLEay, projet démarré en 1995, mais pour lequel les efforts de développement avaient cessés en 1998).

Jusqu’en 2014, OpenSSL a suivi une vie assez paisible, jusqu’à la survenue de la faille de sécurité HeartBleed, qui a été une des plus importantes de par son ubiquité. Cela a donné lieu à la création de forks pour diverses mauvaises raisons :

Fork LibreSSL par des équipes de OpenBDS, suite à un audit du code. Plutôt que de décider de contribuer, ils ont préféré forker. En une semaine, 90 000 lignes de code ont été supprimées du projet initial… Le succès de ce fork reste à démontrer.
Fork BoringSSL par Google. Pas de release, pas de communauté. Mais au moins Google a la main dessus pour son propre usage.
Fork AWS-LC par Amazon. Au moins, il y a des releases…
Fork QuicTLS, par Akaimai et Microsoft : l’objectif est d’intégrer la couche transport QUIC au dessus de OpenSSL 3.3. Une volonté d’intégrer la fondation Apache a été exprimée.

Au final, l’épisode malheureux a permis la création d’une fondation dédiée (OpenSSL Foundation), l’embauche de 14 salariés et la mise en place d’un budget de développement significatif.

LTS ou pas ?

Autre problème : la maintenance des composants à longue durée de vie ? Le serveur Apache httpd n’existe que dans 2 versions majeures, la 1.X et la 2.X. Aujourd’hui, seule la version 2.4 est supportée. D’autres projets proposent des versions appelées LTS (Long Time Support) avec un engagement de maintenance sur une durée garantie. Cela signifie que les bugs découverts sur les dernières versions seront éventuellement back-portés vers les anciennes versions si nécessaire et qu’une correction des anomalies est assurée.

On doit se poser la question d’opter pour de telles versions LTS, plutôt que pour des versions intermédiaires à rotation rapide. Le cas de Java est assez typique :

des LTS toutes les 4 versions,
un support (gratuit) de la version sur 5 ans,
des versions intermédiaires qui ne sont supportées que jusqu’à la sortie de la nouvelle version.

En ce sens, opter pour une LTS semble raisonnable, on utilisera les versions intermédiaires comme un moyen d’anticiper les migrations ultérieures à moindre coût.

C’est également le cas d’Ubuntu qui a une politique de release de LTS et de versions intermédiaires.

Retrouver de l’information

Il faut aussi mentionner qu’il ne suffit pas d’utiliser un composant Open Source, il faut également disposer de sources d’informations fiables. Et ce n’est pas simple.

Les versions évoluent vite et il faut constamment se tenir au courant des modifications apportées. En espérant que les projets fournissent un Change Log adapté et des outils de migration, ce qui n’est pas toujours le cas…
Les sociétés qui supportent des projets Open Source se font racheter et il devient difficile de trouver les informations originelles.
Internet est vivant et il arrive que les liens sur les documentations ou sources que l’on conservait précieusement soient cassés (parfois parce que le nom de domaine n’est plus renouvelé). Il n’y a plus qu’à espérer qu’InternetArchives a conservé une copie (généralement partielle) des pages.
Le contenu peut également disparaître. Toutes les entités gérant des projets Open Source ne proposent pas de récupérer les versions historiques.

Tout cela sans compter les IA qui aujourd’hui rendent difficilement accessibles la documentation ou les échanges sur les anciennes versions, puisque entraînées sur les dernières versions, couplé au fait que les moteurs de recherche ont aujourd’hui tendance à pousser en avant la production de ces IA.

Open Source is One Person

Pour finir, il faut quand même pointer le fait qu’un composant Open Source n’est généralement pas développé ni maintenu par une structure pléthorique. Ceci est parfaitement résumé par le dessin suivant :

Le projet ecosyste.ms^[10] recense un grand nombre de projets Open Source et ses conclusions sont sans appel : sur 11,6 millions de projets analysés, 7 millions sont gérés par une seule personne :

Et si on analyse les projets avec plus de 1 million de téléchargements par mois, près de la moitié n’ont qu’un seul mainteneur :

Le résumé est donné sur la page “Open Source is one person”^[11].

Exemple : Apache Log4j2

Prenons un premier exemple, le projet Apache Log4j2. Sur les deux dernières années :

Il y a eu 1 313 commits,
Dont 354 par des outils (Dependabot, ASF CI release Manager), soit 27% des commits,
Le développeur le plus actif a effectué 484 modifications, soit 50% du total
Le second développeur a effectué 291 modifications, soit 30% du total
Le troisième développeur a effectué 65 modifications, soit 7% du total.
Les trois premiers développeurs sont donc responsables de près de 88% des modifications
Les 34 développeurs ayant participés au projet ont collectivement produit 119 modifications, 3,5 chacun en moyenne…

Exemple : Apache Tomcat

Apache Tomcat est certainement un des composants Open Source de la fondation Apache le plus utilisé. On pourrait se dire qu’il est maintenu par une grosse équipe :

Il y a environ 100 contributeurs sur les 20 dernières années,
Cela représente environ 25 000 commits,
Le premier développeur, Mark Thomas, représente plus de 75% de ces modifications,
Le second développeur, Rémy Maucherat, a contribué à hauteur de 10% des modifications,
Le troisième développeur, Filip Hanik, a contribué à 4% des modifications,
Ces trois développeurs sont donc responsables de 91% des contributions de ces 20 dernières années !

Exemple : LibXML2

LibXML2 est une (petite) librairie en C utilisée pour parser des documents XML. Elle est largement utilisée par des milliers de packages sous Linux. À la fin de l’année 2025, son unique mainteneur, Nick Wellnhofer, a décidé de se retirer du projet. Son dernier commit est le suivant :

On peut légitimement s’inquiéter de cette situation^[12].

Open Source et développement - Partie 3 : Questions ouvertes : bugs, IA, souveraineté et autres

Bibliographie

[4] Hundred of NPM packages compromised
[5] CycloneDX
[6] SPDX
[7] Executive Order 14028
[8] Log4shell, c’est la faute à la fondation Apache ?
[9] L’histoire inédite de Log4j et Log4Shell
[10] Open source intelligence for your project
[11] Open Source is one person
[12] Libxml2 Becomes Officially Unmaintained After Maintainer Steps Down

OVN IPsec avec Kayobe et FreeIPA

2026-01-26T00:00:00+01:00

OpenStack 2025.1 : Le Guide Ultime pour OVN IPsec avec Kayobe et FreeIPA

La sécurité “Zero Trust” n’est plus une option pour les clouds privés modernes. Si vous déployez OpenStack après 2025.1, vous utilisez sûrement OVN (Open Virtual Network) pour le SDN (Software Defined Network). Mais par défaut, le trafic entre vos hyperviseurs circule en clair.

Dans ce guide, nous allons implémenter le chiffrement IPsec pour les tunnels Geneve (Generic Network Virtualization Encapsulation). Nous allons construire une chaîne automatisée robuste :

FreeIPA fournit et renouvelle les certificats automatiquement.
Certmonger surveille ces certificats sur l’OS de l’hôte.
Kayobe orchestre la configuration en injectant les clés dans les conteneurs Kolla.

L’Architecture : Le défi du Conteneur

C’est là que réside la complexité. Dans un déploiement Kolla/Kayobe :

La PKI (Certificats) doit être gérée par l’OS hôte (pour que Certmonger fonctionne).
Le service OVS tourne dans un conteneur isolé (openvswitch_vswitchd).
Le chiffrement IPsec est effectué par le Kernel Linux de l’hôte.

Nous devons donc générer les clés sur l’hôte, les monter dans le conteneur, et piloter la configuration depuis l’extérieur.

1. Prérequis Réseau : la MTU

C’est non-négociable. L’encapsulation (Geneve) + le chiffrement (ESP) ajoutent environ 100 à 130 octets d’overhead. Pour que vos VMs aient une vie normale (MTU 1500), le réseau physique (“Underlay”) doit être en Jumbo Frames.

Dans kayobe/inventory/group_vars/all/network :

network_interfaces:
  - device: eth1
    mtu: 9000
    description: "Tunnel Interface"

Dans kayobe/kolla/globals.yml :

network_mtu: 9000
kolla_enable_neutron_mtu: "yes"
neutron_tenant_network_mtu: 1500

2. Préparation Kolla : Monter les Volumes

Puisque OVS est enfermé dans un conteneur, il ne voit pas vos certificats par défaut. Il faut “monter” le dossier des clés.

Créez le fichier kayobe/kolla/config/openvswitch.yml :

# On monte le dossier des clés de l'hôte vers le conteneur en lecture seule
openvswitch_vswitchd_extra_volumes:
  - "/etc/openvswitch/keys:/etc/openvswitch/keys:ro"

3. Le Hook Ansible : Automatisation PKI & Firewall

Ce playbook va transformer chaque nœud en client FreeIPA, ouvrir le pare-feu et préparer les certificats.

Fichier : etc/kayobe/ansible/hooks/setup-host-pki.yml

---
- name: Configure Host PKI and Firewall for OVN IPsec
  hosts: overcloud
  become: true
  vars:
    ovs_keys_dir: /etc/openvswitch/keys
    ipa_domain: "internal.corp.net"
    # Astuce: utilisez kayobe-vault pour ce mot de passe
    ipa_join_password: ""

  tasks:
    # --- Étape A : Firewall (Crucial !) ---
    - name: Allow IPsec protocols (IKE, NAT-T, ESP)
      firewalld:
        service: ipsec
        permanent: yes
        state: enabled
        immediate: yes
      when: ansible_os_family == 'RedHat'

    # --- Étape B : Installation FreeIPA ---
    - name: Install IPA client and tools
      package:
        name:
          - ipa-client
          - firewalld
        state: present

    - name: Register node to FreeIPA
      command: >
        ipa-client-install --unattended
        --domain=
        --realm=
        --principal=admin
        --password=
        --mkhomedir
      args:
        creates: /etc/ipa/default.conf

    # --- Étape C : Certificats via Certmonger ---
    - name: Ensure keys directory exists
      file:
        path: ""
        state: directory
        owner: root # Sur l'hôte, root gère ça. Dans le conteneur, ce sera monté.
        mode: '0755'

    - name: Request Certificates using Certmonger
      # Cette commande génère les clés et configure le renouvellement auto
      # Le -C redémarre le conteneur si le certif change
      command: >
        ipa-getcert request
        -f /system.pem
        -k /system-privkey.pem
        -N CN=
        -D 
        -K host/@
        -C "docker restart openvswitch_vswitchd"
      args:
        creates: "/system.pem"

    - name: Copy IPA CA cert to OVS keys dir
      copy:
        src: /etc/ipa/ca.crt
        dest: "/ca-cert.pem"
        remote_src: yes

4. Le Hook de Configuration OVS (Post-Deploy)

Une fois que Kolla a déployé les conteneurs, nous devons dire à OVS d’utiliser ces clés. Ce hook intervient après le démarrage des services.

Fichier : etc/kayobe/ansible/hooks/configure-ovs-container.yml

---
- name: Configure OVS Container for IPsec
  hosts: overcloud
  become: true
  tasks:
    - name: Wait for Open vSwitch container
      command: docker inspect -f '' openvswitch_vswitchd
      register: ovs_status
      until: ovs_status.stdout == "true"
      retries: 20
      delay: 5
      ignore_errors: true

    - name: Set OVS SSL config inside container
      # On utilise docker exec car ovs-vsctl n'est pas sur l'hôte
      command: >
        docker exec openvswitch_vswitchd ovs-vsctl set Open_vSwitch .
        other_config:certificate=/etc/openvswitch/keys/system.pem
        other_config:private_key=/etc/openvswitch/keys/system-privkey.pem
        other_config:ca_cert=/etc/openvswitch/keys/ca-cert.pem
      when: ovs_status.stdout == "true"

(Note : Si vous utilisez podman, remplacez docker par podman)

5. Intégration dans Kayobe

Modifiez etc/kayobe/hooks.yml pour insérer ces étapes au bon moment du cycle de vie.

# 1. Préparer l'hôte et les certs AVANT que Kolla ne touche à tout
pre_overcloud_host_configure:
  - ansible/hooks/setup-host-pki.yml

# 2. Configurer OVS une fois que les conteneurs sont lancés
post_overcloud_service_deploy:
  - ansible/hooks/configure-ovs-container.yml

6. L’Interrupteur Général

Tout est prêt, les certificats sont là, OVS les connaît. Il ne reste plus qu’à activer le chiffrement globalement dans la base OVN Northbound.

Fichier : etc/kayobe/ansible/hooks/enable-ovn-global.yml (à lancer manuellement ou en post-deploy final)

- name: Enable IPsec Globally in OVN NB
  hosts: controllers[0]
  become: true
  tasks:
    - name: Enable IPsec
      command: docker exec ovn_nb_db ovn-nbctl set NB_Global . ipsec=true
      ignore_errors: yes # Ignore si déjà activé

Le Test de Vérité

Une fois le déploiement terminé :

Connectez-vous sur un Compute Node.

Interrogez le démon OVS (dans le conteneur) :

docker exec openvswitch_vswitchd ovs-appctl -t ovs-monitor-ipsec tunnels/show

Vérifiez le kernel de l’hôte :
```
ip xfrm state
```

Si vous voyez des clés rfc4106(gcm(aes)), félicitations. Votre cloud OpenStack est chiffré, “Zero Trust”, et vos certificats se renouvelleront tout seuls sans casser la prod.

Autonomie stratégique numérique - 2/2

2026-01-23T00:00:00+01:00

Vos résolutions 2026 pour l’autonomie stratégique numérique : comment Worteks peut vous accompagner

L’analyse de l’état actuel des systèmes d’exploitation Open Source en entreprise révèle une maturité technique indéniable et des avantages structurels majeurs. La transparence, la sécurité renforcée, la flexibilité, la maîtrise des coûts et la souveraineté numérique plaident en faveur d’une adoption réfléchie. Dans un précédent article, nous vous expliquions que 2026 est l’année idéale pour franchir le pas en lien avec :

La situation géopolitique mondiale
Le contexte réglementaire qui favorise l’Open Source.
La maturité de l’écosystème technique.
Les retours d’expérience qui sont nombreux et positifs.

De son côté, Worteks dispose de toute l’expertise pour vous accompagner dans votre projet. L’approche la plus intelligente consiste à évaluer stratégiquement vos besoins, à vous faire accompagner par nos experts et à privilégier une intégration progressive de l’Open Source, en tirant parti de ses atouts pour construire des infrastructures résilientes, sécurisées et maîtrisées.

En ce début 2026, la question n’est donc plus “Pourquoi migrer vers Linux et l’Open Source ?” mais bien “Quelles parties de mon infrastructure puis-je faire basculer en premier et comment Worteks peut-il m’accompagner dans cette transformation ?” Audit de votre infrastructure et feuille de route personnalisée, contactez Worteks dès aujourd’hui et libérez le potentiel de vos infrastructures.

L’Écosystème complet : tout ce dont vous avez besoin

L’écosystème Open Source d’entreprise est désormais mature, complet et prêt pour tous vos besoins, comme nous l’avons expliqué dans notre article « Vos résolutions 2026 pour l’autonomie stratégique numérique : vers des infrastructures toujours plus ouvertes ! ». Petit rappel des possibilités :

Infrastructure de virtualisation : Proxmox VE , oVirt, XCP-ng pour la virtualisation traditionnelle. OpenStack pour le cloud privé. KuberVirt pour l’hybridation VM/conteneurs.
Conteneurisation et orchestration : Docker, Podman pour les conteneurs. Kubernetes, OpenShift pour l’orchestration à grande échelle.
Stockage : Ceph (stockage distribué objet/bloc/fichier), GlusterFS (stockage distribué), ZFS (système de fichiers avancé avec snapshots et déduplication).
Réseau et sécurité : pfSense/OPNsense (pare-feu/routeur), Snort/Suricata (IDS/IPS), OpenVPN/WireGuard (VPN), Wazuh (CVE/logs).
Monitoring et observabilité : Prometheus/Grafana (métriques et dashboards), ELK Stack ou Graylog (centralisation de logs), Zabbix/Nagios (monitoring infrastructure).
Authentification et SSO : OpenLDAP (annuaire), FreeIPA (gestion d’identité intégrée), LemonLDAP::NG (Web Access Manager et SSO), Keycloak (Identity Provider moderne).
Collaboration : BlueMind ou Carbonio (messagerie), Nextcloud (partage et collaboration), Mattermost, Jitsi Meet (communication), GitLab (DevOps).

Worteks maîtrise l’ensemble de cet écosystème et sait composer la solution optimale pour votre contexte quels que soient la taille de votre organisation, votre secteur d’activité, vos contraintes réglementaires, votre budget et vos compétences en interne.

Votre feuille de route 2026

Faire de 2026 l’année de votre indépendance technologique nécessite une approche méthodique et progressive. Voici une proposition de stratégie éprouvée chez nos clients que Worteks recommande.

Approche Progressive

Infrastructure backend

Commencez par l’invisible : migration des serveurs d’infrastructure (DNS, DHCP, proxy), serveurs de fichiers Samba, serveurs web, bases de données.

Avantages : zéro impact utilisateur, gains économiques immédiats.

Worteks vous accompagne avec : audit de l’existant, architecture cible, migration supervisée, formation des équipes techniques, transfert de compétences.

Services Utilisateurs

Déploiement de messagerie Open Source (BlueMind, Carbonio), migration vers Nextcloud pour le partage, mise en place d’authentification centralisée avec OpenLDAP/FreeIPA et gestion des accès web avec LemonLDAP::NG pour le SSO.

Worteks vous accompagne avec : architecture SSO complète, intégration de toutes vos applications, formation des équipes support, documentation personnalisée.

Postes de Travail

Lancement avec des groupes volontaires, profils techniques et utilisateurs bureautique. Distributions comme Ubuntu LTS ou Linux Mint, avec LibreOffice et OnlyOffice. Formation intensive et support rapproché.

Worteks vous accompagne avec : configuration optimale des postes, image système personnalisée, scripts de déploiement, formation utilisateurs, hotline dédiée.

Généralisation

Extension progressive par services, approche hybride assumée avec maintien de postes propriétaires pour applications vraiment critiques, utilisation de VDI (Kyber/Guacamole) pour accès transparent aux applications depuis les postes Linux. Worteks vous accompagne avec : infrastructure VDI complète, optimisation des performances, monitoring et supervision, support continu.

Gestion du changement avec l’humain au cœur

L’aspect humain est crucial pour une migration réussie :

Communication transparente : expliquer les raisons stratégiques (souveraineté, sécurité, économies), valoriser les bénéfices utilisateurs (performances, stabilité, ergonomie moderne).
Formations et ateliers multi-niveaux :
- Administrateurs système : formation approfondie sur Linux, scripting, sécurité.
- Support technique : formation intermédiaire, résolution de problèmes courants.
- Utilisateurs finaux : sessions pratiques courtes, focus sur les outils quotidiens.
- Identification de champions internes : utilisateurs enthousiastes servant de relais.
Support renforcé : période de double support post-migration, documentation accessible (wiki interne, guides visuels, tutoriels vidéo), recueil actif des retours utilisateurs et améliorations continues.

L’expertise pédagogique de Worteks se traduit par des formations adaptées à chaque public, du débutant à l’expert, avec supports de cours complets, labs pratiques et certification des compétences acquises.

Worteks, votre partenaire pour 2026

Worteks accompagne depuis des années les entreprises dans leur transition vers l’Open Source. Notre approche se distingue par :

Une expertise technique reconnue
- Contribution active aux projets Open Source majeurs (OpenLDAP, LemonLDAP::NG, Samba) ;
- Certification et reconnaissance par les éditeurs et communautés ;
- Veille technologique permanente et maîtrise des dernières innovations ;
- Retours d’expérience concrets de centaines de projets réussis.
Une méthodologie éprouvée
- Audit initial complet : infrastructure, applications, compétences, contraintes ;
- Architecture sur mesure : adaptée à vos besoins réels, pas de solution générique ;
- Migration progressive : sans rupture de service, avec rollback possible ;
- Formation intensive : transfert de compétences réel vers vos équipes ;
- Support continu : accompagnement long terme, hotline, maintenance.

Au-delà de la migration initiale, Worteks reste votre partenaire stratégique pour :

Support technique réactif
Évolutions et optimisations continues
Formations complémentaires
Audits de sécurité réguliers
Veille sur les nouvelles technologies

Notre ancrage français et européen nous positionne idéalement pour accompagner les entreprises dans leurs enjeux de souveraineté numérique. Nous privilégions les solutions développées en Europe (BlueMind, LemonLDAP::NG, Nextcloud) quand elles existent, garantissant conformité réglementaire et indépendance.

Autonomie stratégique numérique - 1/2

2026-01-22T00:00:00+01:00

Vos résolutions 2026 pour l’autonomie stratégique numérique : vers des infrastructures toujours plus ouvertes !

Le paysage technologique des entreprises connaît une transformation profonde. Il s’éloigne des systèmes propriétaires et envisage de manière pérenne un tournant vers des solutions ouvertes et maîtrisées. Ce mouvement, autrefois perçu comme une niche réservée aux pionniers, est désormais une réalité pour des organisations de tous types. Il est impulsé par une conjonction de facteurs stratégiques, économiques, réglementaires, sécuritaires et technologiques qui font de l’adoption de l’Open Source non plus seulement une alternative, mais avant tout une démarche qui offre des avantages structurels souvent supérieurs aux écosystèmes propriétaires traditionnels.

Et si 2026 était l’année où votre entreprise prenait enfin le contrôle de son infrastructure technologique ?

Souveraineté numérique et contexte géopolitique

Le gouvernement Trump 2 affiche une politique agressive visant à déréguler au plus vite le numérique, au niveau européen notamment. En témoignent les sanctions prises récemment à l’encontre des juges de la CPI ou l’interdiction de visa pour Thierry Breton, ancien commissaire européen au marché intérieur. Les géants étasuniens du numérique (Google, Amazon, Facebook, Apple, Microsoft…) obéissent aux autorités américaines et appliquent ces demandes de sanctions.

Ces sanctions sont la conséquence directe de la politique de la Commission Européenne qui vise à réduire la dépendance vis-à-vis des “gatekeepers” technologiques et à promouvoir la transparence. L’Union Européenne s’est dotée, pour cela, de directives et règlements comme le RGPD (Règlement Général sur la Protection des Données), le Digital Services Act (DSA), le Digital Markets Act (DMA), le Cyber Resilience Act (CRA), la directive NIS2, le Data Act et l’IA Act.

Ces réglementations incitent fortement à privilégier l’Open Source, dont le code est auditable par nature. En effet, certains systèmes propriétaires intègrent souvent des mécanismes de télémétrie qui envoient des données vers des serveurs centralisés hors de l’Union Européenne, soulevant des défis juridiques complexes. L’intégration de l’Open Source s’inscrit donc dans un cadre réglementaire et stratégique en constante évolution, où la recherche d’une meilleure sécurité et d’une souveraineté numérique accrue conduit les organisations à réévaluer leurs choix technologiques. Ce virage s’appuie sur la richesse et la diversité des solutions Open Source disponibles, chacune offrant des atouts indéniables. L’Open Source offre ainsi aux organisations la maîtrise totale de leurs infrastructures et de leurs données ce qui garantit qu’aucune information sensible ne peut être transférée sans consentement explicite.

De nombreux pays européens ont inscrit l’Open Source comme priorité stratégique :

France : doctrine “Cloud au centre”, programme “Tech.gouv”, soutien à des projets comme Software Heritage ;
Allemagne : stratégie “Digitale Souveränität”, projet Sovereign Workplace développant un environnement de travail souverain basé sur Linux ;
Commission Européenne : stratégie Open Source officielle depuis 2020, obligation d’évaluer les solutions Open Source en priorité, financement via EU-FOSSA et NGI ;
Pays-Bas, Suède, Italie, Espagne : politiques “Open Source first” pour l’administration.

Ce consensus politique signale un changement de paradigme durable et une reconnaissance de l’Open Source comme voie privilégiée pour la souveraineté numérique européenne. 2026 sera l’année où ces initiatives prendront leur pleine ampleur, avec des appels d’offres publics favorisant massivement l’Open Source et des exigences accrues de transparence.

Le panorama des solutions Open Source

Les systèmes d’exploitation

Les distributions Linux

Elles se sont imposées comme le moteur principal de la transformation numérique. Avec des variantes éprouvées comme Red Hat Enterprise Linux (RHEL), Ubuntu Server LTS, Debian ou encore Rocky Linux et AlmaLinux, Linux offre une flexibilité et une adaptabilité sans précédent. Chaque distribution propose un équilibre entre stabilité, innovation et support professionnel. Sa vaste communauté et son écosystème logiciel pléthorique en font une plateforme de choix pour les applications métier, le cloud computing, le big data et l’intelligence artificielle. Le noyau Linux bénéficie de contributions exceptionnelles de milliers de développeurs issus en partie de nombreuses entreprises, garantissant ainsi une diversité de perspectives et une qualité de révision sans équivalent dans le monde propriétaire.

OpenBSD

OpenBSD est mondialement reconnu pour son approche intransigeante de la sécurité. Sa philosophie de “sécurité par défaut”, combinée à un processus d’audit de code continu et à des innovations pionnières en matière de protection, en font un choix privilégié pour les infrastructures critiques : pare-feu, routeurs, serveurs VPN. Contrairement aux systèmes propriétaires dont le fonctionnement interne reste opaque, l’ouverture totale du code source d’OpenBSD permet une vérification constante et une confiance inégalée, réduisant drastiquement la surface d’attaque.

Autres Systèmes BSD

Au-delà d’OpenBSD, FreeBSD et NetBSD proposent des alternatives robustes pour des besoins spécifiques. FreeBSD est particulièrement réputé pour ses performances réseau exceptionnelles (utilisé par Netflix, WhatsApp, Sony PlayStation), sa gestion avancée du stockage avec ZFS et sa stabilité légendaire. NetBSD se distingue par son incroyable portabilité, fonctionnant sur une multitude d’architectures matérielles, un atout dans les environnements industriels hétérogènes ou les systèmes embarqués.

Les architecture système et sécurité

Les systèmes Unix et leurs dérivés se distinguent par un modèle de permissions granulaire et robuste, offrant un contrôle précis sur l’accès aux ressources. Des mécanismes avancés comme SELinux et AppArmor sur Linux ajoutent des couches supplémentaires de contrôles d’accès obligatoires, permettant une isolation renforcée des applications et limitant considérablement l’impact d’une compromission.

Cette architecture de sécurité multi-couches contraste avec les systèmes propriétaires qui peuvent souffrir de complexités diverses et de services système s’exécutant avec les privilèges les plus élevés par défaut.

Le modèle Open Source démontre une réactivité supérieure dans la gestion des vulnérabilités. La transparence du code permet à une vaste communauté internationale de chercheurs d’identifier rapidement les failles. Les correctifs sont souvent disponibles avant même que les vulnérabilités ne soient largement exploitées. Les distributions Linux de qualité entreprise affichent des temps de résolution des vulnérabilités critiques considérablement plus courts que les systèmes propriétaires. De plus, des fonctionnalités comme le livepatch permettent d’appliquer des mises à jour critiques du noyau sans redémarrage, un avantage majeur pour la continuité des activités.

L’expertise de Worteks en matière de durcissement des systèmes (hardening) et d’audits de sécurité permet d’accompagner les organisations dans la mise en œuvre de configurations sécurisées dès le déploiement, réduisant drastiquement les risques.

L’Open Source, catalyseur de l’écosystème DevOps

Le cœur de l’écosystème DevOps moderne bat au rythme exclusif de Linux et des systèmes Open Source. La quasi-totalité des outils de CI/CD et d’automatisation trouve leur support optimal sur ces plateformes. Qu’il s’agisse d’Ansible, Puppet, Docker, Kubernetes, Git, Prometheus, Grafana ou de la stack ELK, l’environnement Linux offre une maturité technique et une intégration native qui simplifient considérablement le déploiement et la gestion des infrastructures complexes.

L’Infrastructure as Code (IaC), paradigme fondamental qui consiste à gérer l’infrastructure via du code versionné, s’épanouit naturellement dans l’écosystème Open Source. Des outils comme Terraform, Pulumi ou CloudFormation facilitent la définition déclarative des infrastructures, permettant des déploiements automatisés, cohérents et rapides à grande échelle.

Worteks accompagne ses clients dans l’adoption de ces pratiques DevOps, avec des formations personnalisées (centre de formation Qualiopi) et un accompagnement sur mesure pour transformer les équipes IT traditionnelles en équipes agiles et efficaces.

Alternatives Open Source pour les services essentiels

Il est possible d’adresser chaque pan de l’infrastructure via des solutions Open Source :

Annuaire et authentification

OpenLDAP s’impose comme la solution d’annuaire Open Source de référence, offrant une gestion centralisée des identités robuste et éprouvée depuis des décennies. Compatible avec les protocoles standards, OpenLDAP permet de structurer l’organisation des utilisateurs, groupes et ressources de manière hiérarchique et efficace. Pour les besoins plus avancés, FreeIPA et Keycloak fournissent des solutions d’authentification centralisées et de SSO modernes.

Worteks possède une expertise reconnue dans l’architecture et le déploiement d’annuaires OpenLDAP haute disponibilité, avec réplication multi-provider, optimisation des performances et intégration avec les écosystèmes existants. Nous accompagnons régulièrement des migrations depuis Active Directory vers des solutions 100% Open Source.

Gestion des accès web (SSO)

LemonLDAP::NG (LLNG) mérite une attention particulière comme solution française de Single Sign-On. Cette plateforme mature et complète permet de sécuriser l’accès aux applications web avec une authentification centralisée, incluant le support de multiples facteurs d’authentification (MFA), SAML, OpenID Connect, CAS et OAuth2. LLNG offre une alternative souveraine et performante aux solutions commerciales, avec une flexibilité remarquable pour gérer des politiques d’accès complexes et des règles de sécurité granulaires. En tant que contributeur actif au projet LemonLDAP::NG, Worteks dispose d’une expertise unique pour déployer des architectures SSO complexes, couvrant des centaines d’applications hétérogènes avec des règles d’accès sophistiquées. Nos équipes maîtrisent parfaitement l’intégration avec les applications modernes (API REST, microservices) comme legacy.

Partage de fichiers et services réseau

Samba offre une compatibilité totale avec les protocoles propriétaires (SMB/CIFS) tout en apportant des fonctionnalités avancées, incluant l’intégration avec OpenLDAP, le chiffrement natif et des performances réseau optimisées.

Messagerie et collaboration

BlueMind (solution française souveraine), Carbonio et SOGo proposent des alternatives complètes avec compatibilité Exchange, calendriers partagés et synchronisation mobile native.

Partage documentaire

Nextcloud s’est imposé comme la plateforme collaborative européenne de référence, offrant partage de fichiers, calendrier, contacts et édition collaborative via Collabora Online ou OnlyOffice.

Cas d’usage réels et adoption sectorielle

Au niveau de la défense et de la sécurité nationale, de nombreux pays européens ont développé des distributions Linux durcies, comme Clip OS en France (ANSSI) ou NeutrINO en Allemagne. Ces systèmes soulignent la confiance placée dans la sécurité intrinsèque de l’Open Source, là où le caractère fermé des solutions propriétaires soulève des doutes légitimes. Dans l’industrie, l’Open Source est le pilier des architectures modernes. Les usines Smart Factory s’appuient sur des systèmes Linux de bout en bout. Des ERP majeurs comme SAP HANA ont fait le choix stratégique de ne fonctionner que sur Linux, en raison des exigences de performance et mise à l’échelle.

Worteks intervient auprès d’entreprises de tous secteurs :

secteur privé, industries
administration publique
santé
finance
éducation Cette diversité nous permet d’apporter des retours d’expérience concrets et des solutions éprouvées, adaptées à chaque contexte métier.

Stratégies pour les applications propriétaires

Pour certaines applications propriétaires qui ne fonctionnent que sur des systèmes spécifiques, plusieurs solutions existent.

Virtualisation d’entreprise

L’écosystème Open Source offre des plateformes de virtualisation matures et performantes qui ont bénéficié d’un coup de projecteur depuis le rachat de VMWare par Broadcom.

Proxmox VE : solution complète intégrant KVM pour la virtualisation et LXC pour les conteneurs, avec interface web intuitive, haute disponibilité native et gestion centralisée. Particulièrement adaptée aux PME et infrastructures distribuées.
oVirt : plateforme de gestion de virtualisation KVM d’entreprise, sponsorisée par Red Hat, offrant des fonctionnalités avancées de centre de données (live migration, haute disponibilité, gestion centralisée de milliers de machines virtuelles).
XCP-ng : fork communautaire libre de Xen, éliminant les limitations artificielles, avec Xen Orchestra comme interface de gestion moderne. Solution robuste pour les environnements exigeants nécessitant une isolation stricte.
OpenStack : plateforme cloud complète pour infrastructures à grande échelle, permettant de créer des clouds privés ou publics avec gestion automatisée de milliers de machines virtuelles et de ressources réseau/stockage.
KubeVirt : extension de Kubernetes permettant d’exécuter des machines virtuelles aux côtés des conteneurs, idéale pour les organisations adoptant une approche cloud-native tout en conservant des workloads legacy.

Worteks a déployé et gère des infrastructures de virtualisation pour des centaines de clients, du petit cluster Proxmox à des clouds privés OpenStack de plusieurs milliers de cœurs. Notre expertise couvre toute la chaîne :

architecture,
déploiement,
migration,
formation et support.

Infrastructures de bureau virtuel (VDI)

Des solutions comme Apache Guacamole (Open Source, accès via navigateur) ou Kyber permettent de centraliser les applications sur des serveurs dédiés et d’y accéder à distance depuis des clients légers. Kyber, en particulier, offre une solution VDI Open Source performante qui facilite l’accès aux applications Windows depuis des postes Linux, réduisant drastiquement le nombre de licences nécessaires tout en maintenant l’expérience utilisateur.

L’approche VDI avec Kyber ou Guacamole représente souvent la solution idéale pour les entreprises souhaitant migrer progressivement : les utilisateurs bénéficient d’un poste Linux performant et sécurisé pour leur travail quotidien, tout en conservant un accès transparent aux quelques applications propriétaires critiques via VDI.

Conclusion

Ce panorama des logiciels Open Source montre qu’ils balayent le spectre d’utilisation des solutions propriétaires tout en constituant des alternatives plus performante, sécurisée et souveraine que ces dernières. Dans notre article suivant « Vos résolutions 2026 pour l’autonomie stratégique numérique : comment Worteks peut vous accompagner », nous vous expliquons comment Worteks peut vous accompagner dans votre migration vers des solutions 100% Open Source.

Proxmox VE

2025-12-29T00:00:00+01:00

Proxmox VE : Une alternative crédible à VMware, mais pas universelle

L’annonce du changement de politique tarifaire de VMware par Broadcom a créé un véritable séisme dans l’écosystème de la virtualisation d’entreprise. Face à des augmentations parfois dramatiques des coûts de licensing, nombreuses sont les organisations qui explorent des alternatives. Proxmox VE s’impose naturellement dans cette réflexion, porté par une communauté active et une approche Open Source séduisante. Cependant, cette migration mérite une analyse technique approfondie pour éviter les écueils d’une transition mal préparée.

Le contexte post-Broadcom : comprendre l’exode VMware

Depuis le rachat de VMware, les nouvelles grilles tarifaires ont bouleversé l’équation économique de nombreuses infrastructures. Les licences par socket disparaissent au profit d’un modèle par cœur CPU, accompagné de bundles imposés qui incluent des fonctionnalités parfois non utilisées. Cette évolution pousse légitimement les DSI à réévaluer leurs choix technologiques. Nous avons déjà réalisé une série d’articles à ce sujet, n’hésitez pas à aller les consulter.

Proxmox VE apparaît alors comme un candidat naturel : hyperviseur basé sur KVM/QEMU, distribution Debian, interface web unifiée et modèle économique transparent. Mais attention aux raccourcis : remplacer VMware par Proxmox ne se résume pas à une simple substitution technique.

Architecture VMware vs Proxmox : correspondances et divergences

Le modèle VMware traditionnel

L’architecture VMware classique s’articule autour de vCenter Server pour la gestion centralisée, d’ESXi comme hyperviseur, et s’appuie sur un stockage partagé (SAN/NAS) avec des fonctionnalités avancées comme vMotion, DRS, et HA. Cette architecture convient particulièrement aux environnements nécessitant une haute disponibilité avec des SLA stricts. Ce modèle est le cas typique des déploiements VMware et correspond à une grande partie des infrastructures à migrer.

L’approche Proxmox

Proxmox VE propose une architecture plus distribuée où chaque nœud intègre à la fois l’hyperviseur (KVM) et les capacités de gestion via une API REST. Le clustering s’appuie sur Corosync, et le stockage peut être géré de manière native via Ceph, ZFS, ou des backends externes.

Correspondance directe : infrastructures de 3 à 16 nœuds avec besoins de virtualisation classique, environnements de développement/test, infrastructures départementales.
Limites architecturales : grandes fermes de virtualisation (>100 hôtes), environnements multi-tenants complexes, intégrations poussées avec des écosystèmes propriétaires.

Migration technique : méthodologie et limite

Prérequis et planification

La migration nécessite une analyse préalable rigoureuse :

Audit de l’existant VMware
Inventaire des VMs et leurs dépendances
Analyse des performances (CPU, RAM, stockage, réseau)
Cartographie des fonctionnalités utilisées (vMotion, DRS, snapshots)
Évaluation des intégrations (backup, monitoring, orchestration)

Processus de migration

La phase de migration est assez simple, reposant essentiellement sur de la conversion de machines virtuelles. Les technologies se ressemblant fortement, il est facile de proposer un modèle type :

Phase 1 : Reconstruction des services
- Reconfiguration du réseau (VLAN, bridges)
- Mise en place du clustering Proxmox
- Configuration du stockage (Ceph, ZFS, ou stockage externe)
Phase 2 : Conversion des VMs , Proxmox propose plusieurs méthodes :
- Conversion directe via qm importovf pour les exports OVF
- Migration à chaud possible avec des outils comme virt-v2v
- Import des disques VMDK vers formats qcow2 ou raw

Il est possible de créer un cluster minimal et de basculer les hyperviseurs d’une solution à une autre pour éviter de devoir dupliquer le nombre de serveurs physiques. Attention : un point de vigilence important concerne la partie stockage local, où un certain nombre de déploiements ESX sont sur des cartes SD ou flash simples.

Points de vigilance techniques

Il y a plusieurs points de vigilance pour identifier la faisabilité d’une migration VMware vers Proxmox :

Stockage : L’absence d’équivalent direct à VMFS nécessite de repenser l’architecture de stockage. Ceph étant intégré, cela offre une solution élégante. Pour les profils les plus expérimentés, il est conseillé de séparer le stockage et la virtualisation en gérant le cluster Ceph autrement.
Réseau : Proxmox gère nativement les VLAN et bridges, mais des configurations réseau complexes (NSX) nécessitent une refonte.
Haute disponibilité : Le système HA de Proxmox, bien que fonctionnel, reste plus basique que DRS/vSphere HA pour des environnements critiques.

L’équation économique : au-delà de la gratuité apparente

Coûts directs Proxmox

Si Proxmox VE Community est gratuit, les environnements de production nécessitent généralement un support commercial :

Les tarifs Proxmox évoluent régulièrement. Il convient de vérifier les prix actuels sur le site officiel pour une évaluation précise.
Proxmox Backup Server nécessite également une souscription pour les environnements de production.

Coûts indirects souvent oubliés

Il est important de noter que certains coûts restent souvent peu estimés ou négligés, ils sont à prendre en compte dans le ROI avec l’économie faite sur les souscriptions VMware :

Formation et montée en compétences sur :
- KVM
- LXC
- Ceph
- clustering Linux
Mise en place d’outils périphériques : L’écosystème VMware (vRealize, NSX) n’a pas d’équivalent direct, nécessitant des solutions tierces.
Souscription à des contrats de support et d’expertise : Il est recommandé de passer par un intégrateur en plus du support Proxmox pour le déploiement.

Cas d’usage adaptés et limites de Proxmox

Le paysage des solutions de virtualisation Open Source est varié et complexe, comme nous l’avons décrit dans notre série d’articles sur le sujet.

Proxmox excelle pour :

PME avec infrastructures simples à moyennes (5-50 VMs)
Environnements de développement/test
Organisations avec expertise Linux forte
Besoins de conteneurisation (LXC natif)
Budgets contraints avec tolérance aux risques

D’autres alternatives sont préférables pour :

Grandes infrastructures (>100 hôtes) : OpenStack ou oVirt
Environnements critiques 24/7 : XCP-ng, KubeVirt, OpenStack ou oVirt
Intégrations complexes : KubeVirt ou OpenStack
Organisations sans expertise Linux : oVirt ou XCP-ng
Besoins cloud hybride : OpenStack

Recommandations pour une migration réussie

Approche pilote

Il est préférable de prendre en main l’outil avant de réaliser la conversion de toute votre infrastructure. Commencer par un sous-ensemble non critique permet de valider l’approche :

Migration d’un cluster de développement
Formation des équipes sur 6 mois
Validation des processus de sauvegarde/restauration
Extension progressive aux environnements de production

Critères de décision

La décision doit être motivée par un besoin et non par une mode ou un effet de foule. Voici certains éléments à prendre en compte :

Complexité : Plus l’infrastructure VMware est sophistiquée, plus la migration sera complexe
Compétences : L’expertise Linux/KVM interne conditionne largement le succès
Budget : Au-delà des licences, intégrer formation, outils et période de transition
Évolutivité : Anticiper les besoins futurs (croissance, cloud hybride)

Conclusion : pragmatisme avant tout

Proxmox VE représente une alternative sérieuse et économiquement attractive pour de nombreux cas d’usage. Son architecture moderne, basée sur des standards ouverts, offre une flexibilité appréciable. Cependant, cette migration ne doit pas être motivée uniquement par les considérations économiques immédiates. Le succès d’une transition repose sur une analyse technique rigoureuse, une planification méthodique et une évaluation réaliste des compétences disponibles. Pour les organisations disposant de l’expertise technique appropriée et d’infrastructures correspondant au modèle Proxmox, cette migration peut effectivement représenter une opportunité de modernisation et d’optimisation des coûts.

L’écosystème Open Source offre aujourd’hui plusieurs alternatives crédibles : oVirt, KubeVirt pour les environnements hybrides, XCP-ng pour une approche Xen, ou OpenStack pour les infrastructures orientées IaC ou IaaS. Chaque solution répond à des besoins spécifiques et mérite une évaluation dans le contexte de migration post-VMware. L’engouement autour de Proxmox est légitime, mais doit être tempéré par une approche technique pragmatique : il ne s’agit pas simplement de remplacer VMware, mais de construire l’infrastructure de virtualisation la plus adaptée aux besoins réels et à l’évolution future de l’organisation.

Retour sur l’OSXP 2025 : Mini W’aaS, le Cloud Provider de poche

2025-12-15T00:00:00+01:00

Retour sur l’OSXP 2025 : Mini W’aaS, le Cloud Provider de poche à la Cité des Sciences

Lors de l’édition 2025 de l’Open Source Experience (OSXP) à la Cité des Sciences et de l’Industrie, on a voulu relever un défi un peu fou avec le projet Mini W’aaS : la démonstration en live et en miniature de notre offre d’hébergement W’aaS.

Le défi : déployer, seul et en seulement 2 jours de préparation, une infrastructure Cloud Provider complète (IaaS), sécurisée et monitorée, sur du matériel de bureau obsolète.

L’objectif n’était pas de montrer la puissance brute, mais de démontrer l’expertise et l’efficience : prouver qu’avec une architecture logicielle maîtrisée, on peut faire tourner OpenStack, Kubernetes et Ceph sur des machines que d’autres auraient mis à la benne.

Le Hardware : des machines d’occasion et des contraintes extrêmes

Le matériel

Pour cette démo, le Data Center tenait sur une table et dans trois racks. Il était composé de 21 machines récupérées, des ThinkCentre Tiny :

14x ThinkCentre M700
13x ThinkCentre M710Q (dont je n’ai utilisé qu’une partie)
8x ThinkCentre M715Q
15x ThinkCentre M73 (les vétérans de 2014 !)
1 Switch 24 Ports pour faire quelques vlans et Jumbo frame

La contrainte absolue : 4 Go de RAM par machine

C’est là que résidait tout le sel de la démo. Dans le monde du Cloud, 4 Go, c’est ce qu’on alloue à une petite VM. Ici, c’est la RAM totale du host physique pour faire tourner l’OS, Kubernetes (K3s), l’agent OpenStack (Nova), l’agent Ceph et les VMs clientes.

Le stockage “audacieux” sur USB

Pour le stockage distribué (Ceph), pas de disques NVMe. J’ai utilisé 3 hosts dédiés avec 6 OSDs montés sur… des clés USB. Faire tourner un cluster Ceph fonctionnel sur de la mémoire flash USB grand public démontre la robustesse incroyable de Rook, capable de gérer la santé du stockage même sur des supports lents (la subtilité : faire croire que les clés usb n’en sont pas).

[root@k1 ~]# kubectl exec -n rook-ceph deploy/rook-ceph-tools -- ceph status
  cluster:
    id:     31de7d7b-e50a-4fc9-aaef-1159c0a0c047
    health: HEALTH_OK
 
  services:
    mon: 3 daemons, quorum a,b,c (age 2d)
    mgr: a(active, since 2d)
    osd: 6 osds: 6 up (since 2d), 6 in (since 2d)
 
  data:
    pools:   7 pools, 193 pgs
    objects: 115 objects, 293 MiB
    usage:   4.2 GiB used, 342 GiB / 347 GiB avail
    pgs:     193 active+clean
 
  io:
    client:   20 KiB/s wr, 0 op/s rd, 1 op/s wr

Une stack logicielle parfaitement adaptée

Liste des logiciels utilisés

Si on fait un petit résumé des principaux produits déployés :

Technologie	Lien	Commentaires
OpnSense	opnsense.org	Pare-feu Open Source
Rocky Linux 9	rockylinux.org	OS Base
SELinux	docs.rockylinux.org	Module de sécurité noyau
K3S	K3s.io	Distribution Kubernetes légère
Calico	tigera.io/project-calico	CNI (Interface Réseau K8s)
WireGuard	wireguard.com	VPN moderne et rapide
OpenStack-Helm	docs.openstack.org / Git	Orchestre les conteneurs OpenStack (Nova, Neutron, Keystone, Cinder) sur Kubernetes
Rook-Ceph	rook.io	Opérateur Kubernetes pour Ceph
MetalLB	metallb.universe.tf	Load Balancer pour K8s
FRR	frrouting.org	Suite de routage (BGP/OSPF)
FreeIPA	freeipa.org	Gestion d’identité centralisée (LDAP/Kerberos)
Keycloak	keycloak.org	Gestionnaire d’identité et d’accès (IAM)
Grafana	grafana.com	Visualisation
Prometheus	prometheus.io	Base de données Time-Series / Collecte les métriques
Exporter FRR	github.com/tynany/frr_exporter	Permet de monitorer l’état des sessions BGP
Exporter Node	github.com/prometheus/node_exporter	Métriques système de base (CPU, RAM, Disque, Réseau) de chaque serveur physique
Exporter OpenStack	github.com/openstack-exporter	Interroge les API OpenStack pour remonter l’état applicatif
Exporter Goldpinger	github.com/bloomberg/goldpinger	Outil visuel génial pour voir la connectivité réseau entre les nœuds K8s
Exporter Kubernetes	github.com/kubernetes/kube-state-metrics	Remonte l’état des objets K8s
Ansible	ansible.com	Automatisation. Utilisé pour le Day 0
Helm	helm.sh	Gestionnaire de paquets K8s

Il est possible qu’il en manque mais cela représente déjà une idée du projet.

Avec cette répartition sur le matériel

Pour la démo, nous sommes parti d’une infrastructure de Data Center Leaf Spine à la sauce petit hardware :

3 Firewalls OpnSense avec le routage FRR
3 Leafs avec du FRR et les services Freeaipa
6 noeuds K3S hébergeant les control Plane : Openstack / Ceph / K3S
6 noeuds Kubernetes pour les computes Openstack
3 noeuds Ceph pour les 6 OSDs

K3s & WireGuard : l’art du déploiement optimisé

Pour faire tenir tout ce monde dans 4 Go de RAM, chaque mégaoctet comptait. L’utilisation d’un Kubernetes standard (k8s) était impossible car trop gourmand.

L’Orchestrateur : K3s

Mon choix s’est porté sur K3s, la distribution Kubernetes légère certifiée. Là où un K8s classique consomme facilement 1 Go de RAM à vide, K3s se contente de moins de 512 Mo, laissant des ressources vitales pour les charges de travail OpenStack.

L’installation s’est faite en une ligne de commande, illustrant la puissance de l’automatisation moderne.

Le Secret : WireGuard dans Calico

Le véritable tour de force réside dans la couche réseau (CNI). Je voulais un réseau chiffré (Zero Trust), mais sur des CPU vieux de 10 ans, le chiffrement IPsec classique aurait mis les machines à genoux.

La solution ? Utiliser le backend WireGuard de Calico pour pouvoir utiliser MetalLB. WireGuard fonctionnant directement dans le kernel Linux, l’overhead est minime et les performances excellentes.

K3s configure automatiquement des tunnels WireGuard transparents entre tous les nœuds. Le résultat est immédiat : tout le trafic inter-pod est encapsulé et chiffré, sans aucune configuration complexe de certificats ou de VPN tiers.

Sécurité : Niveau Entreprise (Zero Trust)

Même si le matériel est roots et que le setup a été monté en deux jours, la sécurité n’a pas été sacrifiée. Au contraire, elle respecte les standards les plus stricts.

Identité Unifiée et SSO

Pas de comptes locaux dispersés. L’infrastructure repose sur une gestion d’identité centralisée :

FreeIPA : pour la gestion des serveurs Linux, l’authentification SSH centralisée et les règles SUDO. Chaque nœud rejoint le domaine au boot. Hébergé sur les trois noeuds FRR, une machine virtuelle hébergeant les services FreeIPA permet d’avoir une redondance.
Keycloak : pour la couche fédération d’identité. L’accès au dashboard OpenStack (Horizon), à Grafana et aux APIs est protégé par SSO (Single Sign-On) hébergé directement sur le K3s. Une seule identité permet de tout piloter.

SDN Chiffré (Le résultat du setup K3s)

Grâce à la configuration WireGuard décrite plus haut, le réseau Overlay (les tunnels VXLAN qui transportent les paquets des VMs) ne circule pas en clair. Même si on branche un sniffer sur le switch de la démo, on ne voit qu’un flux chiffré indéchiffrable entre les hyperviseurs. Le réseau physique est considéré comme non-sûr par défaut.

L’Observabilité : piloter au millimètre

Faire tourner une stack Cloud complète sur 4 Go de RAM ne laisse aucune marge d’erreur. Une fuite mémoire de 200 Mo et le nœud crash (OOM Killer). L’observabilité n’était pas un luxe, mais une nécessité vitale.

J’ai déployé une stack Prometheus / Grafana surveillant 4 niveaux critiques :

La surveillance des ressources

Via node_exporter, je surveillais l’usage RAM à la seconde près. Des alertes étaient configurées pour prévenir si la RAM disponible descendait sous les 200 Mo, permettant d’intervenir avant que le kernel ne tue les processus OpenStack.

La performance du stockage USB

Avec le module Ceph Exporter, je surveillais spécifiquement la latence de commit (écriture) sur les 6 clés USB. Le constat : on pouvait voir graphiquement les pics d’IOPS lors du déploiement d’une VM. Malgré la lenteur du support, Rook a parfaitement lissé la charge, assurant la stabilité du service.

La santé du Control Plane

Un exportateur dédié interrogeait les APIs OpenStack pour vérifier l’état des agents Nova, Neutron et Cinder. Cela permettait de savoir instantanément si un service était Down sans avoir à se connecter en SSH.

La connectivité BGP

Grâce au monitoring de FRR, je pouvais visualiser l’état des sessions BGP entre les hyperviseurs et les routeurs de bordure, garantissant que les IPs des VMs étaient bien annoncées sur le réseau.

Conclusion

Ce projet Mini W’aaS présenté à l’OSXP démontre qu’OpenStack n’est pas une usine à gaz réservée aux équipes de 50 personnes avec un budget illimité. Seul, en 2 jours, et sur du matériel de récupération, il est possible de monter un Cloud Privé résilient, avec du chiffrement WireGuard natif, du SSO et un monitoring complet. C’est une belle preuve de ce que permet la sobriété quand elle est couplée à une expertise technique sur des outils comme K3s.

Retour de helm

[root@k1 ~]# helm list -n openstack
NAME            NAMESPACE       REVISION        UPDATED                                 STATUS          CHART                           APP VERSION
cinder          openstack       7               2025-12-04 15:51:19.950985143 +0100 CET deployed        cinder-2025.2                   v1.0.0     
glance          openstack       1               2025-12-03 13:12:30.524797775 +0100 CET deployed        glance-2025.2                   v1.0.0     
horizon         openstack       2               2025-12-04 16:04:21.569158846 +0100 CET deployed        horizon-2025.2                  v1.0.0     
ingress         openstack       2               2025-12-03 11:33:30.030254791 +0100 CET deployed        ingress-0.2.19                  v1.8.2     
keystone        openstack       3               2025-12-03 12:02:03.239122838 +0100 CET deployed        keystone-2025.2                 v1.0.0     
libvirt         openstack       5               2025-12-03 17:30:27.140643483 +0100 CET deployed        libvirt-2025.2                  v1.0.0     
mariadb         openstack       1               2025-12-02 13:20:41.893833456 +0100 CET deployed        mariadb-2025.2                  v10.6.7    
memcached       openstack       1               2025-12-02 13:39:38.422099454 +0100 CET deployed        memcached-2025.2                v1.5.5     
neutron         openstack       1               2025-12-03 13:42:06.874793696 +0100 CET deployed        neutron-2025.2                  v1.0.0     
nova            openstack       23              2025-12-04 16:11:55.042845769 +0100 CET deployed        nova-2025.2                     v1.0.0     
openvswitch     openstack       2               2025-12-03 17:31:10.676735009 +0100 CET deployed        openvswitch-2025.2              v1.0.0     
placement       openstack       1               2025-12-03 13:28:08.736924742 +0100 CET deployed        placement-2025.2                v1.0.0     
rabbitmq        openstack       1               2025-12-03 11:51:58.42025061 +0100 CET  deployed        rabbitmq-2025                   v3.12.0

Rendez-vous à la prochaine édition :)

Retrouvez notre retour complet de l’événement et nos conférences dans nos actualités : L’Open Source Experience, c’est fini ! Retour sur l’édition 2025.

Évolution du plugin de suppression de vidéos anciennes pour PeerTube : un traitement côté back-end

2025-11-07T00:00:00+01:00

Le développement initial du plugin “Cleanup Unviewed Videos” pour PeerTube (disponible sur le Github de Worteks) avait été évoqué dans un article précédent. Dans la continuité, cet article traite de l’évolution de son architecture en vue de transférer une partie du traitement côté serveur.

Cette évolution permet une recherche plus efficace des vidéos éligibles à la suppression du fait d’un accès direct à la base de données.

Accès à l’API interne

La fonction en charge d’enregistrer le plugin dans PeerTube doit être enrichie de nouveaux attributs permettant l’accès à l’API interne de PeerTube :

async function register({
	getRouter,
	peertubeHelpers,
	registerSetting,  // Cet attribut était déjà importé
	settingsManager
}) {
	const database = peertubeHelpers.database;
	const logger = peertubeHelpers.logger;
	const router = getRouter();
	const videos = peertubeHelpers.videos;

  // ...
});

Les attributs qui sont exposés aux plugins sont listés sur la page de documentation.

Interactions avec le routeur

Pour que le plugin puisse être piloté depuis l’interface de PeerTube, il faut qu’il déclare des terminaisons d’API HTTP. Nous allons déclarer deux routes :

récupération des vidéos éligibles à la suppression
suppression d’une vidéo

Le routeur utilisé par PeerTube est celui du framework Express. La déclaration des deux routes se fait de la sorte :

router.get("/", async (req, res) => {
	// ...
	res.status(200).json(data);
});

router.delete("/:id", async (req, res) => {
	// ...
	res.status(204).json();
});

Les routes sont alors accessibles via les requêtes HTTP suivantes :

GET /plugins/<plugin-name>/router
DELETE /plugins/<plugin-name>/router/:id

Accès aux paramètres du plugin

La recherche des vidéos éligibles à une suppression est basée sur des critères d’âge exprimés en années, mois et jours. Ces critères sont passés en paramètres GET de la requête. Il est possible d’anticiper des requêtes incomplètes dont certains paramètres seraient manquants. On peut alors augmenter la robustesse du code en chargeant la valeur par défaut pour chacun des arguments manquants. (Note : on aurait pu décider de leur donner la valeur de “0” par défaut, mais ça aurait été trop simpliste).

router.get("/", async (req, res) => {
	const [years, months, days] = await Promise.all(
		["years", "months", "days"].map(async (field) => {
			const req_value = parseInt(req.query[field], 10);
			return !isNaN(req_value)
				? req_value
				: parseInt(
						`${await settingsManager.getSetting(`default-${field}-old`)}`,
						10,
					);
		}),
	);

	// ...
});

Dans sa version initiale, le plugin expose un paramètre permettant de désactiver la suppression (à des fins de test). La prise en compte de ce paramètre doit maintenant se faire dans le code de traitement de la route DELETE /plugins/<plugin-name>/router/:id.

const enable_deletion = await settingsManager.getSetting("enable-deletion");
if (enable_deletion) {
	// Actually delete video
} else {
	// Write a log message
}

Accès à la base de données

PeerTube interagit avec la base de données via Sequelize. Les plugins peuvent accéder à cette bibliothèque via peertubeHelpers.database.

Cette méthode d’accès permet d’exécuter des requêtes au format SQL sur la base de données. Cependant, des limitations ou des particularités imposent les précautions suivantes.

Il n’est pas possible d’accéder aux commodités de haut niveau de l’ORM :

Par ailleurs, Sequelize nomme les tables en traduction camelCase de la classe TypeScript associée. Ceci a comme conséquence que les tables ne seront pas reconnues directement par le shell PostgreSQL et devront être entourées de doubles-quotes :

SELECT * FROM videoView;    -- ERROR:  relation "videoview" does not exist
SELECT * FROM "videoView";  -- OK

Enfin, les plugins n’ont pas accès à suffisamment de fonctionnalités de protection anti-injection (bind-parameters, date-ranges, etc.).

Les besoins du plugin nécessitent l’intervention d’opérateurs de calculs de date afin de traduire l’âge spécifié en date. La requête que le plugin va exécuter ne pourra pas être sécurisée par l’ORM et nous devons nous assurer nous-mêmes qu’elle ne permettra pas d’injection. Une conversion en entier base 10 a été insérée dans sa mise en forme. Le résultat de cette conversion sera soit une succession de chiffres, soit NaN. Ni l’un ni l’autre ne seront vecteurs d’injection.

const [results, _] = await database.query(
	`SELECT "videoId" as id, name, url, "createdAt"
				FROM (
					SELECT "videoId", video.name, video.url, video."createdAt", MAX("endDate") AS last_viewed
						FROM "videoView"
						LEFT JOIN video ON "videoId" = video.id
						GROUP BY "videoId", video.name, video.url, video."createdAt"
				)
				WHERE last_viewed < CURRENT_DATE
					- interval \'${parseInt(years, 10)} years\'
					- interval \'${parseInt(months, 10)} months\'
					- interval \'${parseInt(days, 10)} days\'
			`,
);

Suppression d’une vidéo

Parmi les fonctions d’aide exposées aux plugins par PeerTube, la fonction removeVideo permet la suppression d’une vidéo et de tous les éléments qui y sont associés :

await peertubeHelpers.videos.removeVideo(req.params.id);

Conclusion

L’ajout de fonctionnalités back-end à ce plugin représente un important gain d’efficacité. De plus, il permet d’en rendre l’architecture plus classique.

Les fonctionnalités offertes aux plugins par PeerTube permettent de traiter des cas simples sans trop de difficulté. Cependant, la documentation étant assez rudimentaire, il est nécessaire d’avoir un bagage TypeScript/Javascript suffisant pour comprendre la façon dont les interfaces de l’API interne à PeerTube doivent être utilisées.

Une évolution prochaine de ce plugin (ou une approche initiale pour un prochain plugin) pourrait être de le développer en TypeScript, ce qui apporterait un gain en ergonomie dans le processus de développement (au détriment de la simplicité de déploiement actuelle).

Conduite d’un test de charge de réplication avec OpenLDAP

2025-09-22T00:00:00+02:00

On a une base OpenLDAP avec 30 millions d’entrées, donc assez volumineuse. De temps en temps, pour des raisons techniques (mise à jour d’un service, par exemple), on doit basculer un état booléen sur toutes les entrées de façon à ce que ce service ne soit pas visible le temps de la mise à jour, puis revenir à l’état antérieur. Du fonctionnel, donc.

Les principes et objectifs

L’objectif de ce test est de déterminer la meilleure méthode pour conduire cette mise à jour, dans un contexte où des contraintes fortes de production sont présentes.

Pour cela nous allons tester plusieurs configurations tant matérielles que logicielles et mesurer les résultats obtenus, de façon à définir la configuration optimale.

L’architecture de réplication cible

On dispose de 4 serveurs identiques (32 Go de mémoire), avec OpenLDAP dans la version 2.6.10, en réplication complète (chaque serveur pouvant recevoir des modifications et les transmettre aux autres). La raison pour laquelle cette architecture a été choisie est de répartir la charge tout en s’assurant de la continuité de service si un ou plusieurs serveurs tombaient. La charge est importante, avec entre 100 000 à 300 000 modifications par jour (considérant que cette charge se répartit sur 10h, on tourne donc autour de 10 modifications par seconde).

Par ailleurs, ces serveurs reçoivent une charge de 30 000 recherches par seconde, ce qui est très important.

Le schéma suivant indique les relations de réplication :

En terme de transferts, une modification appliquée sur un des serveurs est transmise plusieurs fois. Par exemple, la modification M appliquée sur le serveur S1 est transmise à S2, S3 et S4. Mais il faut aussi considérer que S2 transmet cette modification à S3 et S4, et de même pour chaque serveur. Au total, une modification est communiquée dans le pire des cas jusqu’à 9 fois avec 4 serveurs.

Note : La propagation s’arrête grâce à deux règles :

On ne propage pas une entrée vers le serveur de provenance (par exemple, si S2 reçoit une entrée de S1, il ne la lui renvoie pas).
On ne propage pas une entrée que l’on a déjà reçue (et pour cela on compare l’entryCSN local avec l’entryCSN de l’entrée reçue, s’ils sont égaux, la propagation de l’entrée cesse).

Avec d’aussi gros volumes de modifications potentielles, il est nécessaire d’utiliser delta-syncrepl, qui ne transfert que les attributs modifiés (et quelques autres attributs techniques), au lieu d’utiliser l’algorithme classique (syncrepl) qui transmet les entrées modifiées dans leur totalité.

Cela implique la mise en place d’une base de stockage des modifications partielles (accesslog), qui est utilisée en cas de reprise suite à une déconnexion d’un des serveurs. Cela signifie que chaque modification est appliquée localement, puis enregistrée dans accesslog, et envoyée aux serveurs en réplication.

On a donc une double écriture sur disque.

La contrainte supplémentaire est qu’il faut prévoir la purge de la base accesslog qui ne fait que grossir : idéalement, sur une base journalière, mais de préférence plus fréquemment pour éviter les gros traitements de purge (on parle de purger jusqu’à 300 000 modifications par jour, et 30 millions lors de l’opération qui nous intéresse).

La configuration testée

Pour les tests de charge, on va se contenter de configurer deux serveurs en MMR. Cela nous suffit pour mettre en évidence les problèmes potentiels et mesurer les performances dans différentes configurations.

De même, pour des raisons de temps de traitement, on teste les serveurs avec une base de données de 10 millions d’entrées, une extrapolation à 30 millions d’entrées sera effectuée.

La plateforme OpenStack a été configurée en conséquence, comme décrit dans l’article Construction d’une plateforme de test avec OpenStack.

Configuration OpenLDAP

Principes généraux

On configure donc deux serveurs disposant d’une base pour les données (worteks), et d’une base pour stocker les opérations à répliquer (accessLog).

Le mode de réplication utilisé est delta-syncrepl, qui optimise les données transmises en ne propageant que les valeurs d’attributs modifiées.

La base de configuration est également répliquée afin que les modifications apportées à chaud puissent se propager automatiquement aux autres serveurs.

La configuration en détail

La configuration se présente sous la forme d’une arborescence :

cn=config/
 |
 +-- cn=config.ldif
 |
 +-- cn=module{0}.ldif
 |
 +-- cn={0}schema/
 |
 +-- cn=schema.ldif
 |
 +-- olcDatabase={-1}frontend.ldif
 |
 +-- olcDatabase={0}config/
 |    |
 |    +-- olcOverlay={0}syncprov.ldif
 |
 +-- olcDatabase={0}config.ldif
 |
 +-- olcDatabase={1}monitor.ldif
 |
 +-- olcDatabase={2}mdb/
 |    |
 |    +-- olcOverlay={0}syncprov.ldif
 |
 +-- olcDatabase={2}mdb.ldif
 |
 +-- olcDatabase={3}mdb/
 |    |
 |    +-- olcOverlay={0}syncprov.ldif
 |    |
 |    +-- olcOverlay={1}accesslog.ldif
 |
 +-- olcDatabase={3}mdb.ldif

Les paragraphes suivants décrivent l’intégralité de la configuration.

cn=config

Voici le contenu de la configuration :

dn: cn=config
objectClass: olcGlobal
cn: config
# Les connections anonymes sont interdites
olcDisallows: bind_anon
# Localisation du fichier de log
olcLogFile: /var/log/openldap/slapd.log
# Sync + stats
olcLogLevel: 16640
olcRequires: authc
# Premier serveur
olcServerID: 11 ldap://openldap1:10389
# Second serveur
olcServerID: 12 ldap://openldap2:10389

cn=module{0}.ldif

Trois modules sont chargés :

MDB
AccessLog
SyncProv

dn: cn=module{0}
objectClass: olcModuleList
cn: module{0}
# Chemin de stockage des modules
olcModulePath: /usr/local/openldap/libexec/openldap/
# Base mdb
olcModuleLoad: {0}back_mdb
# Provider de réplication
olcModuleLoad: {1}syncprov
# Base access log
olcModuleLoad: {2}accesslog

olcDatabase={-1}frontend.ldif

Cet élément de configuration ne contient aucune information globale dans notre plateforme de test.

dn: olcDatabase={-1}frontend
objectClass: olcDatabaseConfig
olcDatabase: {-1}frontend

olcDatabase={0}config.ldif

C’est dans cette entrée que l’on trouve les deux règles de réplication pour la configuration. La raison pour laquelle deux règles sont définies est que cela permet de copier cette configuration intégralement sur l’autre serveur : seules les règles qui ne correspondent pas au serveur local seront actives.

Note : Il faut faire attention à ce que les URLs utilisées comme valeur de l’attribut olcSyncrepl pour le paramètre provider correspondent exactement au paramètre -h passé en ligne de commande à slapd, sinon le serveur va chercher à répliquer vers lui-même. Par exemple, pour la ligne de commande de lancement de OpenLdap suivante :

$ slapd -h ldap://openldap1:10389 ...

il faut utiliser la configuration suivante pour olcSyncrepl :

olcSyncrepl: {0}rid=001 provider=ldap://openldap1:10389 ...

Si on utilise l’addresse IP de openldap1 dans cette ligne, la réplication du serveur vers lui-même sera activée…

Il est à noter que le mot de passe est en clair pour cet exemple, mais devrait techniquement être chiffré. Cela dit le mot de passe est également fourni en clair dans les directives de réplication, ce qui est nécessaire pour pouvoir s’authentifier sur le serveur distant. Une meilleure solution consiste à mettre en œuvre une authentification via certificats, pour éviter ce problème, mais cela sort du cadre de cette étude.

dn: olcDatabase={0}config
objectClass: olcDatabaseConfig
olcDatabase: {0}config
# Donne accès au user root
olcAccess: {0}to * by dn="gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=a
 uth" manage by dn="cn=admin,cn=config" manage by * none
olcRootDN: cn=admin,cn=config
# Mot de passe encodé en base 64 (ici : 'secret')
olcRootPW:: c2VjcmV0
# première directive de réplication de la configuration
olcSyncrepl: {0}rid=001 provider=ldap://openldap1:10389 binddn="cn=admin,cn=co
 nfig" bindmethod=simple credentials="secret" searchbase="cn=config" type=refr
 eshAndPersist retry="5 5 300 +" timeout=1
# seconde directive de réplication de la configuration
olcSyncrepl: {1}rid=002 provider=ldap://openldap2:10389 binddn="cn=admin,cn=co
 nfig" bindmethod=simple credentials="secret" searchbase="cn=config" type=refr
 eshAndPersist retry="5 5 300 +" timeout=1
# Autorise les updates sur ce serveur
olcMultiProvider: TRUE

olcDatabase={0}config/olcOverlay={0}syncprov.ldif

Cette entrée se contente de déclarer le module syncprov pour la base config.

dn: olcOverlay={0}syncprov
objectClass: olcSyncProvConfig
olcOverlay: {0}syncprov

olcDatabase={1}monitor.ldif

On définit les identifiants d’accès à la base monitor.

dn: olcDatabase={1}monitor
objectClass: olcDatabaseConfig
olcDatabase: {1}monitor
olcRootDN: cn=monitor
olcRootPW:: c2VjcmV0

olcDatabase={2}mdb.ldif

On définit ici la configuration de la base accesslog.

Un utilisateur spécifique doit être créé pour accéder à cette base. Son DN est uid=repl,ou=security,o=service,o=worteks.

Cette base est assez importante pour conserver une grande quantité de modifications, mais il faut la purger régulièrement. On verra quelle taille sera occupée après avoir appliqué 10 millions de modifications.

dn: olcDatabase={2}mdb
objectClass: olcDatabaseConfig
objectClass: olcMdbConfig
olcDatabase: {2}mdb
# Répertoire de stockage
olcDbDirectory: /usr/local/openldap/data/accesslog
# Le point d'entrée de la base
olcSuffix: cn=accesslog
# Accès autorisé au user uid=repl
olcAccess: {0}to * by dn.base="uid=repl,ou=security,o=service,o=worteks" read by * break
# Cet utilisateur n'a pas de restriction
olcLimits: {0}dn="uid=repl,ou=security,o=service,o=worteks" size=unlimited time=unl
 imited
# La base est read only (seul le serveur y écrira)
olcReadOnly: TRUE
# Le root user
olcRootDN: cn=accesslog
# et son mot de passe ('secret')
olcRootPW:: c2VjcmV0
# Stocke le ContextCSN dans une subentry cn=ldapsync
olcSyncUseSubentry: TRUE
# La base est monitorée
olcMonitoring: TRUE
# Écrit les données toutes les minutes en base
olcDbCheckpoint: 0 1
# Les données ne sont pas immédiatement écrites sur disque
olcDbNoSync: TRUE
# Les index déclarés
olcDbIndex: default eq
olcDbIndex: entryCSN,objectClass,reqEnd,reqResult,reqStart,reqDN,reqSession
# Taille maximale de la base, ici 40Go
olcDbMaxSize: 40000000000
# Nombre d'entrées maximales traitées par un search
olcDbRtxnSize: 10000

olcDatabase={2}mdb/olcOverlay={0}syncprov.ldif

Cette entrée déclare le module syncprov pour la base accesslog.

La particularité est que l’on positionne le flag olcSpNoPresent à TRUE car on ne souhaite pas que la phase ‘present’ de l’algorithme de réplication soit activée. Cette phase permet de déterminer les entrées qui ont été supprimées sur le serveur distant, pour pouvoir les supprimer localement. Cela n’a pas de sens pour une base de log.

Le flag olcSpReloadHint doit être positionné à TRUE pour la base accesslog. Cela force une mise à jour au redémarrage de la réplication.

dn: olcOverlay={0}syncprov
objectClass: olcSyncProvConfig
olcOverlay: {0}syncprov
# La phase 'present' de la réplication est désactivée.
olcSpNoPresent: TRUE
olcSpReloadHint: TRUE

olcDatabase={3}mdb.ldif

Cette entrée définit la configuration de la base de données proprement dite.

On y décrit les ACLs (règles d’accès), les limites, l’utilisateur d’administration (dont le mot de passe est en clair ici, mais devra être haché en production), les directives de réplication.

Concernant ces dernières, on en a autant qu’il y a de serveurs présents dans l’architecture MMR, sachant que celle correspondant au serveur lui-même sera ignorée. Ici, on a deux directives, une seule sera activée.

Leur configuration indique :

L’identifiant de réplication (RID) utilisé par le client pour identifier la réplication. Dans notre cas on a 2 serveurs, le local et le distant, donc il y a deux lignes olcSyncrepl avec deux RID différents. Il est à noter qu’on réplique également la configuration, donc il faut faire attention à ce que les RID soient différents de ceux utilisés pour la configuration.
L’URL du serveur à contacter
L’utilisateur de réplication : uid=repl,ou=security,o=service,o=worteks
La base accesslog à utiliser : cn=accesslog
Le filtre sur cette base, à savoir les objets en update (objectClass=auditWriteObject) et qui ont été validés (reqResult=0). A noter que, comme la base a été configurée pour ne stocker que les modifications réussies, ce dernier filtre n’est pas nécessaire.
Le type de réplication (refreshAndPersist) : on se connecte, on rafraîchit la base puis on reste à l’écoute de toute mise à jour indéfiniment
Les directives retry en cas de déconnexion, ici toutes les 5 secondes sans interruption
Le temps d’attente maximum pour valider la connexion à un serveur distant, ici 1 seconde
Le format des données reçues, ici avec le paramètre syncdata=accesslog, on ne recevra que les différences entre l’entrée initiale et l’entrée modifiée.

La base est MultiProvider, ce qui signifie que le serveur pourra recevoir des modifications.

Elle est configurée pour ne pas écrire les données immédiatement sur le disque, pour des raisons de performances (olcDbNoSync à TRUE). Les données sont alors écrites sur disque quand plus de 1Mo de données ont été reçues, ou qu’une minute s’est écoulée. Le risque de perte en cas de crash est faible.

dn: olcDatabase={3}mdb
objectClass: olcDatabaseConfig
objectClass: olcMdbConfig
olcDatabase: {3}mdb
# Le répertoire de stockage des données
olcDbDirectory: /usr/local/openldap/data/worteks/
# Le DN de la racine
olcSuffix: o=service,o=worteks
# Autorise l'utilisateur root à se connecter
# ainsi que l'utilisateur de réplication en read only
# Les utilisateurs anonymes sont rejetés
olcAccess: {0}to * by dn="gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=a
 uth" read by dn="uid=repl,ou=security,o=service,o=worteks" read by anonymous a
 uth by * none break
# L'attribut userPassword n'est jamais accessible
olcAccess: {1}to attrs=userPassword by * none
# La branche ou=security n'est pas accessible
olcAccess: {2}to dn.subtree="ou=security,o=service,o=worteks" by * none
olcAccess: {3}to * by * none
# Les entrées ajoutées seront contrôlées avec les ACLs
olcAddContentAcl: TRUE
# L'utilisateur de réplication n'a pas de limite
olcLimits: {0}dn="uid=repl,ou=security,o=service,o=worteks" size=unlimited tim
 e=unlimited
# L'utilisateur root n'a pas de limite
olcLimits: {1}dn="gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth" siz
 e=unlimited time=unlimited
# DN de l'administrateur de la base
olcRootDN: cn=admin,o=service,o=worteks
# Password en clair ('secret')
olcRootPW:: c2VjcmV0
# Première directive de réplication
olcSyncrepl: {0}rid=012 provider=ldap://openldap1:10389 binddn="uid=repl,ou=se
 curity,o=service,o=worteks" bindmethod=simple credentials="secret" searchbase
 ="o=service,o=worteks" logbase="cn=accesslog" logfilter="(&(objectClass=audit
 WriteObject)(reqResult=0))" type=refreshAndPersist retry="5 +" timeout=1 sync
 data=accesslog
# Seconde directive de réplication
olcSyncrepl: {1}rid=011 provider=ldap://openldap2:10389 binddn="uid=repl,ou=se
 curity,o=service,o=worteks" bindmethod=simple credentials="secret" searchbase
 ="o=service,o=worteks" logbase="cn=accesslog" logfilter="(&(objectClass=audit
 WriteObject)(reqResult=0))" type=refreshAndPersist retry="5 +" timeout=1 sync
 data=accesslog
# Serveur en MMR
olcMultiProvider: TRUE
# Les données sont écrites chaque minute
olcDbCheckpoint: 0 1
# Pas d'écriture sur disque immédiate
olcDbNoSync: TRUE
# Les index à déclarer
olcDbIndex: entryUUID eq
olcDbIndex: objectClass eq
olcDbIndex: entryCSN eq
olcDbIndex: uid eq
olcDbIndex: mailboxServiceIMAP eq
olcDbIndex: mailboxServicePOP eq
olcDbIndex: mailPrimaryAddress eq
olcDbIndex: mailAlternativeAddress eq
olcDbIndex: mailboxHiddenAlias eq
# Taille maximale de la base, 80Gb
olcDbMaxSize: 85899345920

olcDatabase={3}mdb/olcOverlay={0}syncprov.ldif

La configuration de l’overlay syncprov pour la base de données spécifie une taille de log en mémoire de 10 000 opérations pour éviter de lire dans la base accesslog si une déconnexion courte a lieu. On n’écrit l’attribut contextCSN qu’une fois toutes les 100 opérations ou toutes les 10 minutes, ce qui évite des écritures trop fréquentes. Avec 300 000 modifications par jour (réparties sur 10h), cela représente 500 mises à jour par minute, donc 5 mises à jour des données par minute pendant la journée, et une modification toutes les 10 minutes hors période d’activité. C’est un compromis acceptable, mais il est possible d’augmenter le nombre de modifications à appliquer avant mise à jour du contextCSN à 500 pour qu’il ne soit effectué qu’une fois par minute.

dn: olcOverlay={0}syncprov
objectClass: olcSyncProvConfig
olcOverlay: {0}syncprov
# Le _contextCSN_ n'est écrit sur disque que toutes les 100 opérations ou 10 minutes
olcSpCheckpoint: 100 10
# Taille de la session conservée en mémoire, ici 10 000 opérations
olcSpSessionlog: 10000

olcDatabase={3}mdb/olcOverlay={1}accesslog.ldif

La configuration de l’overlay accesslog utilisé pour la réplication de la base de données :

dn: olcOverlay={1}accesslog
objectClass: olcAccessLogConfig
olcOverlay: {1}accesslog
# Pointe vers la base accesslog à utiliser
olcAccessLogDB: cn=accesslog
# Ne garde que les opérations d'écriture (add, delete, modify, moddn)
olcAccessLogOps: writes
# Garde les entrées un maximum de 7 jours, et effectue la purge tous les jours
olcAccessLogPurge: 07+00:00 01+00:00
# Ne garde que les opérations ayant réussi
olcAccessLogSuccess: TRUE

La préparation des données

Les tests effectués montrent qu’on peut appliquer jusqu’à 2000 modifications par seconde avec un serveur disposant de 8 Go de mémoire. Il faut donc 1h30 pour les appliquer toutes dans le cas des 10 millions de modifications (10 000 000 modifications / 2000 par seconde / 3600 secondes par heure -> 1h 23mins)

Bien évidemment, cela dépend de l’infrastructure physique. La base utilisée est MDB, qui n’accepte pas d’écriture concurrente, donc une écriture en base ne pourra se faire que quand la précédente aura été effectuée. Le facteur important concernant les performances est la taille mémoire disponible : l’objectif est que la totalité de la base MDB soit montée en mémoire. On analysera le comportement de la base quand ce n’est pas le cas.

Chaque entrée contient de nombreux attributs et, ceux-ci pouvant être indexés, il convient d’étudier la base chargée avec un nombre significatif d’entrées pour estimer sa taille.

En utilisant la commande _mdb_stat -a _, on obtient le listing suivant, dans lequel nous prenons les _'branch pages'_ et _'leaf pages'_, qui contiennent le **B-tree**, que l'on multiplie par la taille d'une page, soit 4096 octets, pour avoir la taille réellement occupée par les données :

$ mdb_stat -a /usr/local/openldap/data/worteks
Status of Main DB
  Tree depth: 1
  Branch pages: 0
  Leaf pages: 1
  Overflow pages: 0
  Entries: 14

  Total: 4Ko

Status of ad2i
  Tree depth: 1
  Branch pages: 0
  Leaf pages: 1
  Overflow pages: 0
  Entries: 35

  Total: 4Ko

Status of dn2i
  Tree depth: 4
  Branch pages: 594
  Leaf pages: 133335
  Overflow pages: 0
  Entries: 20000013

  Total: 4096 * (594 + 133 335) = 536 Mo

Status of entryCSN
  Tree depth: 3
  Branch pages: 55
  Leaf pages: 13596
  Overflow pages: 0
  Entries: 10000006

 Total: 4096 * (55 + 13 596) = 54 Mo

Status of entryUUID
  Tree depth: 4
  Branch pages: 451
  Leaf pages: 77171
  Overflow pages: 0
  Entries: 10000006

  Total = 4096 * (451 + 77 171) = 310 Mo

Status of id2e
  Tree depth: 4
  Branch pages: 29118
  Leaf pages: 4935050
  Overflow pages: 0
  Entries: 10000006

  Total = 4096 * (29 118 + 4 935 050) = 19,9 Go

Status of id2v
  Tree depth: 0
  Branch pages: 0
  Leaf pages: 0
  Overflow pages: 0
  Entries: 0

  Total: 0

Status of ixck
  Tree depth: 0
  Branch pages: 0
  Leaf pages: 0
  Overflow pages: 0
  Entries: 0

  Total: 0

Status of mailAlternativeAddress
  Tree depth: 4
  Branch pages: 453
  Leaf pages: 77987
  Overflow pages: 0
  Entries: 10000000

  Total = 4096 * (453 + 77 987) = 314 Mo

Status of mailPrimaryAddress
  Tree depth: 4
  Branch pages: 441
  Leaf pages: 77862
  Overflow pages: 0
  Entries: 10000000

  Total = 4096 * (441 + 77 862) = 313 Mo

Status of objectClass
  Tree depth: 1
  Branch pages: 0
  Leaf pages: 1
  Overflow pages: 0
  Entries: 36

  Total = 4 Ko

Status of MailboxHiddenAlias
  Tree depth: 4
  Branch pages: 448
  Leaf pages: 77683
  Overflow pages: 0
  Entries: 10000000

  Total = 4096 * (448 + 77 683) = 313 Mo

Status of MailboxServiceIMAP
  Tree depth: 1
  Branch pages: 0
  Leaf pages: 1
  Overflow pages: 0
  Entries: 3

  Total = 4 Ko

Status of MailboxServicePOP
  Tree depth: 1
  Branch pages: 0
  Leaf pages: 1
  Overflow pages: 0
  Entries: 3

  Total = 4 Ko

Status of uid
  Tree depth: 4
  Branch pages: 465
  Leaf pages: 77931
  Overflow pages: 0
  Entries: 10000001

  Total = 4096 * (465 + 77 931) = 313 Mo

Cette base occupe donc 19,9 Go pour les données (table id2e), 1,6 Go pour les index et 0,5 Go pour les DNs, soit un total d’environ 22 Go.

On peut croiser cette information avec les données récupérées avec la commande _mdb_stat -e _ :

$ mdb_stat -e /usr/local/openldap/data/worteks
Environment Info
  Map address: (nil)
  Map size: 137438953472
  Page size: 4096
  Max pages: 33554432
  Number of pages used: 5650219
  Last transaction ID: 9691279
  Max readers: 126
  Number of readers used: 7
Status of Main DB
  Tree depth: 1
  Branch pages: 0
  Leaf pages: 1
  Overflow pages: 0
  Entries: 14

On constate qu’il y a 5 650 219 pages utilisées, avec une taille de 4 Ko par page, soit un total de 22,6 Go.

Le chiffre diffère légèrement, car il y a des pages libres qui seront réutilisées dans le retour de la seconde commande. On retiendra la taille de 23 Go par sécurité.

A ce chiffre, il faut ajouter la place occupée par la base access_log après injection de 10 millions de modifications :

Environment Info
  Map address: (nil)
  Map size: 137438953472
  Page size: 4096
  Max pages: 33554432
  Number of pages used: 1511239
  Last transaction ID: 4811538
  Max readers: 126
  Number of readers used: 5
Status of Main DB
  Tree depth: 1
  Branch pages: 0
  Leaf pages: 1
  Overflow pages: 0
  Entries: 12

Pour 1 511 239 pages de 4 Ko, cela correspond à 6 Go supplémentaires.

On considère donc qu’avec 23 Go + 6 Go, soit 29 Go, une taille mémoire de 32 Go permet de conserver la totalité de la base en mémoire, ce qui évitera des I/O lors de la mise à jour des B-tree. En effet, si on dispose d’une taille mémoire inférieure, il y aura nécessairement des lectures de pages sur disque pour remonter la structure et les feuilles en mémoire. En pratique, moins on dispose de mémoire, plus il y a d’entrées sorties et donc de ralentissements.

Voici par exemple ce que prend l’injection de 10 millions d’entrées selon la taille mémoire affectée au serveur (le fichier contenant les entrées fait 9,4 Gb) :

+----------------+-------------------+----------+
| Taille mémoire | Temps d'injection | Entrée/s |
+----------------+-------------------+----------+
| 2Gb            | 11h 37m           | 239/s    |
+----------------+-------------------+----------+
| 3Gb            | 1h 39m 55s        | 1668/s   |
+----------------+-------------------+----------+
| 3.5Gb          | 36m 59s           | 4625/s   |
+----------------+-------------------+----------+
| 4Gb            | 8m 50s            | 18 867/s |
+----------------+-------------------+----------+
| 8Gb            | 8m 20s            | 20 000/s |
+----------------+-------------------+----------+
| 16Gb           | 7m 08s            | 23 364/s |
+----------------+-------------------+----------+
| 32Gb           | 7m 41s            | 24 390/s |
+----------------+-------------------+----------+

Jusqu’à un certain point, le manque de mémoire est pénalisant lors de l’injection de données dans la base, puis rajouter de la mémoire n’améliore que marginalement les temps d’exécution. L’inflexion est assez brutale.

Si on considère l’index de l’attribut entryUUID, dont les données sont les suivantes :

Status of entryUUID
  Tree depth: 4
  Branch pages: 451
  Leaf pages: 77171
  Overflow pages: 0
  Entries: 10000006

on constate que le nombre de pages intermédiaires ne représente que 0,6% des pages utilisées pour cet index. Le ratio est le même pour la table id2e qui contient les entrées. Plus on dispose de mémoire, plus on augmente la probabilité que les pages intermédiaires soient présentes en mémoire. Cela limite les I/O disque, augmentant les performances de plusieurs ordres de magnitude. C’est ce qu’on constate dès 3 Gb de mémoire.

Par contre, il s’agit d’un scénario d’écriture où les données sont écrites séquentiellement, qui n’est pas représentatif d’un fonctionnement normal d’une base LDAP. Dans un scénario de lecture où les données lues se répartiront aléatoirement sur l’ensemble des pages, ce niveau de mémoire va entraîner de nombreuses lectures de pages terminales. Il convient, dans la mesure du possible, de monter la totalité des pages en mémoire et donc d’augmenter celle-ci pour correspondre à la taille totale de la base de données. Pour une base de 30 millions d’entrées, on peut considérer que 32 Gb de mémoire sont suffisants pour l’injection, mais insuffisants pour monter la totalité de la base en mémoire. En extrapolant les chiffres obtenus pour 10 millions d’entrées, on peut estimer qu’il faut 96 Gb de mémoire (32 Gb x 3 pour un triplement du nombre d’entrées) pour s’assurer que toute la base sera en mémoire à terme et ainsi obtenir la meilleure performance possible en lecture et en écriture.

La copie des données

Dans notre cas, on va utiliser des serveurs disposant de 16 Go de mémoire, dont les bases de données et accesslog ont été supprimées au préalable.

Le nettoyage des bases se fait de la façon suivante :

$ cd /usr/local/openldap/data
$ rm accesslog/*
$ rm worteks/*

Cette suppression doit s’effectuer sur les deux serveurs.

On va ensuite charger deux jeux de données :

La base, qui construit l’arborescence. Il s’agit d’une dizaine d’entrées. La commande suivante effectue ce travail :

$ slapadd -b "o=service,o=worteks" -F /usr/local/openldap/etc/openldap/slapd.d -l /home/debian/base.ldif -S 11

Les données, soit 10 millions d’entrées avec une structure telle que :

dn: uid=<UID>,cn=mailboxes,ou=fr,o=service,o=worteks
objectClass: inetOrgPerson
objectClass: mailbox
objectClass: simpleSecurityObject
objectClass: uidObject
cn: cn<UID>
sn: sn<UID>
uid: <UID>
userPassword:: MDAwMDAwMDAwMA==
displayName: displayName<UID>
givenName: givenName<UID>
mailAlternativeAddress: alias<UID>@worteks.fr
mailPrimaryAddress: <UID>@worteks.fr
mailboxAccountStatus: active
mailboxDomainId: 1
mailboxGroupName: RETAIL
mailboxHiddenAlias: hiddenAlias<UID>@worteks.fr
mailboxQuota: 10737418240
mailboxServiceAntivirusAll: FALSE
mailboxServiceIMAP: FALSE
mailboxServicePOP: FALSE
mailboxServiceSMTPIn: TRUE
mailboxServiceSMTPOut: TRUE
mailboxServiceWebmail: TRUE
mailboxSite: 1
mailboxStorage: 0
mailboxUserOidVal: MELOFR-200-MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMA==
mailboxUserServiceOidVal: 0030003000300030003000300030003000300030

Une entrée comporte 24 attributs et les attributs suivants sont indexés :

entryUUID
objectClass
entryCSN
uid
mailboxServiceIMAP
mailboxServicePOP
mailPrimaryAddress
mailAlternativeAddress
mailboxHiddenAlias

ATTENTION!!! Si les injections de données se font avec le user root, la base de données n’aura pas les bons droits et ne pourra pas être chargée au démarrage de slapd. Il conviendra de faire un chown ldap:ldap /usr/local/openldap/data/worteks/* avant le lancement de slapd.

L’injection se fait via la commande :

$ slapadd -q -w -s -b "o=service,o=worteks" -F /usr/local/openldap/etc/openldap/slapd.d -l /tmp/entries.ldif -S 11

Les options utilisées pour ce premier import sont les suivantes :

-q : Quick mode. On suppose que les données sont correctes.
-w : Une fois toutes les entrées injectées, le contextCSN va être mis à jour avec l’entryCSN le plus récent (donc celui de la dernière valeur injectée)
-s : Pas de vérification du schéma
-S : L’identifiant du serveur, ServerID, ici 11

Une fois l’injection initiale effectuée sur un des serveurs, il faut exporter les données et les recharger sur les autres serveurs.

On commence par exporter les données du premier serveur par la commande suivante :

 $ slapcat -b "o=service,o=worteks" -F /usr/local/openldap/etc/openldap/slapd.d -l /tmp/all.ldif

On déplace le résultat sur le second serveur, puis on injecte les données par la commande suivante :

 $ slapadd -b "o=service,o=worteks" -F /usr/local/openldap/etc/openldap/slapd.d -l /tmp/all.ldif -q -s

Ici, on utilise également les options -q (pas de vérification) et -s (pas de contrôle du schéma), mais pas l’option -w. L’option -S permet de donner le serverID.

L’opération prend environ 7 minutes sur ce serveur, comme précédemment.

A ce stade, les deux serveurs contiennent les mêmes informations, toutes avec la même date. Les bases sont donc équivalentes.

On le vérifie après relance des deux serveurs OpenLDAP :

# slapd-cli start
slapd-cli: [INFO] Using /usr/local/openldap/etc/openldap/slapd-cli.conf for configuration
slapd-cli: [INFO] Launching OpenLDAP configuration test...
slapd-cli: [OK] OpenLDAP configuration test successful
slapd-cli: [INFO] Launching OpenLDAP...
slapd-cli: [OK] File descriptor limit set to 1024
slapd-cli: [ALERT] No PID file for OpenLDAP

Même opération sur le second serveur.

Comme on est en delta-syncrepl, il faut déclencher la réplication, ce qui se fait en effectuant une modification sur le premier serveur, ce qui synchronise les deux bases. La raison pour laquelle cette étape est nécessaire est que le mécanisme de réplication s’appuie sur le contenu de la base accesslog, qui est vide. Cela permet de diffuser les contextCSN sur chaque serveur.

Normalement, on doit retrouver le contextCSN des deux serveurs sur chaque serveur.

Sur OpenLDAP1 :

20250625130822.612684Z#000000#000#000000
20250625135436.855194Z#000000#00c#000000 -> Serveur ID 12 ('0x0b' en troisième position)
20250625135502.701625Z#000000#00b#000000 -> Serveur ID 11 ('0x0c' en troisième position)

Sur OpenLDAP2 :

20250625130822.612684Z#000000#000#000000
20250625135502.701625Z#000000#00b#000000 -> Serveur ID 11 ('0x0b' en troisième position)
20250625135922.024564Z#000000#00c#000000 -> Serveur ID 12 ('0x0c' en troisième position)

On est prêt pour l’étape suivante.

Injection des modifications

On va donc appliquer une modification sur 10 millions d’entrées. Cette modification va être générée par un script prenant comme template ce fichier :

DN: uid=<UID>,cn=mailboxes,ou=fr,o=service,o=worteks
changetype: modify
replace: mailboxServiceAntivirusAll
mailboxServiceAntivirusAll: TRUE

qui va être appliquée via un ldapModify à toutes les entrées, le résultat étant stocké dans le fichier mod.ldif. On boucle pour remplacer l’UID par la valeur de chaque entrée.

La commande est la suivante :

ldapmodify -x -H ldap://openldap1:10389 -D "cn=admin,o=service,o=worteks" -w secret -f mod.ldif

Sur les serveurs de test, cela applique environ 2200 modifications par seconde. Il faut donc environ 1h30 pour que toutes les modifications soient appliquées et répliquées. Sur une base de 30 millions d’entrées, cela va prendre près de 5h.

Il est à noter qu’en modifiant le paramètre olcDbNoSync de TRUE à FALSE, l’injection se fait au rythme de 250 modifications par seconde, soit environ 9 fois plus lentement!

La raison étant que les données sont écrites lors de chaque modification, ralentissant fortement le traitement. La contrepartie en production, c’est qu’il y a un risque de perte de données, si le serveur est arrêté brutalement.

Ce risque est compensé par le fait qu’il faudrait l’arrêt de l’ensemble des serveurs simultanément pour que les données ne soient pas enregistrées, la réplication étant déclenchée dès l’enregistrement local des données sur un serveur.

Est-il possible d’améliorer ce temps d’injection ? En pratique, il est possible de basculer sur une commande passée serveur arrêté, slapmodify.

La seconde solution consiste à arrêter les bases, appliquer les modifications avec un slapmodify, exporter la base avec un slapcat, copier l’export sur les différents serveurs, les recharger avec un slapadd après avoir purgé les bases, redémarrer les serveurs et faire une modification sur un des serveurs pour relancer la réplication.

Ces opérations prennent un peu moins d’une heure (slapmodify : 10 minutes, slapcat : 10 minutes, slapadd sur les serveurs : 10 minutes, plus le temps de copie et les manipulations), mais peuvent être scriptées. Il s’agit néanmoins d’une opération qui se mène à froid, ce qui interrompt le service pendant sa durée. Il est néanmoins possible de limiter la durée de coupure à 10 minutes, le temps nécessaire pour appliquer localement les modifications. La manipulation est plus complexe, il faut relancer le serveur après application des modifications, puis faire un ldapsearch à chaud, et injecter le résultat dans la seconde base qui, elle, a été maintenue arrêtée. Une fois ces manipulations terminées, on peut relancer le second serveur, qui se met à jour avec le premier.

Une alternative serait de garder les serveurs clients en lecture seule, réplication désactivée, le temps que la mise à jour des données et l’export soient effectués sur le premier serveur, suivi d’un redémarrage du serveur à jour, avec arrêt des serveurs clients, mise à jour de ceux-ci et redémarrage. Dans ce scénario, on n’aura qu’un service dégradé le temps de la mise à jour, mais accessible en lecture.

Conclusion

OpenLDAP est une base performante, mais qui nécessite une attention particulière aux paramètres de configuration dès qu’on y stocke des données volumineuses. Une base de 30 millions d’entrées n’est pas un cas d’usage fréquent et il convient d’anticiper les opérations de maintenance.

La taille de la mémoire allouée est le paramètre le plus crucial quand il s’agit d’obtenir les meilleures performances. Économiser sur la configuration physique est une garantie de surcoût à brève échéance. Dans le cas d’écritures nombreuses, il est également critique de disposer d’un support physique rapide (SSD ou NVMe) et de se poser la question de l’arbitrage entre risque de perte et rapidité (on a vu qu’un facteur 9 en performance est à payer si on souhaite s’assurer d’écritures atomiques).

Les autres éléments de configuration (index, structure de la base, ACLs, attributs multi-valués avec de nombreuses valeurs, etc) peuvent également impacter les performances, mais dans une moindre mesure. Ils pourront faire l’objet d’autres études.