Dans son histoire de plus de trente ans, l'équipe Samba a été confrontée à plusieurs reprises au défi d'intégrer des intérêts commerciaux - voire conflictuels - et open source dans un même projet. Quelles sont les méthodes, cependant, qui font que cela fonctionne tout court?
par Volker Lendecke
Cet articlea été publié à l'origine en allemanddans iX 6/2022 "Travail sur un projet open source", p. 60 (article sur heise.de).La traduction française a été créée automatiquement par DeepL.
Le projet open source Samba est considéré comme la suite standard d'outils pour l'interopérabilité entre Windows et Linux/Unix. Il s'agit d'un énorme marché de clients potentiels, à la fois commercialement et personnellement intéressant pour les développeurs. Cependant, cela signifie également qu'il y a de nombreux contributeurs à Samba qui doivent s'entendre entre eux sur la direction à donner au projet.
Une petite anecdote illustre ce qui lie le projet jusqu'à aujourd'hui: en 1991, Andrew Tridgell avait le problème suivant: il voulait échanger des fichiers sur son ordinateur sous MS-DOS simultanément avec un serveur sous DES Pathworks et une station de travail Sun. Les clients NFS de Pathworks et de PC apportaient tous deux leurs propres piles TCP/IP incompatibles. Cela signifiait que seul Pathworks ou PC-NFS était possible. Il a donc écrit un processus serveur qui émule le serveur Ultrix Pathworks sur la machine Sun. Tridgell ne s'est pas rendu compte que le serveur Pathworks descendait du gestionnaire de réseau local OS/2, qui fournirait plus tard le partage de fichiers dans Windows. Mais cela a conduit à ce que Samba, qui ne s'appelait pas ainsi à l'époque, soit compatible avec un très grand nombre de clients dès le départ.
C'est grâce à Andrew Tridgell qu'il a ouvert son "serveur 1.0" à une communauté. Avec l'équipe Samba, il a créé une structure qui permet à d'autres parties intéressées de participer au projet sur un pied d'égalité. Andrew s'est depuis retiré du développement actif, mais l'équipe Samba continue de fonctionner. Mon histoire personnelle avec Samba a commencé lorsque j'ai pu remplacer le serveur NetWare 3 de l'entreprise de mes parents par quelque chose que j'ai compilé moi-même.
Comment l'équipe Samba fonctionne aujourd'hui
Le travail typique sur Samba, outre le développement de nouvelles fonctionnalités, consiste surtout à corriger les bogues. Cela se fait par le biais du canal communautaire Samba bugzilla.samba.org, qui est ouvert à tous, ainsi que des listes de diffusion Samba. Ces canaux sont entièrement basés sur des contributions volontaires, ce qui fonctionne plus ou moins bien. Les bogues très évidents et faciles à corriger sont généralement résolus rapidement. Mais lorsque les choses deviennent plus compliquées, les bugs communautaires ne reçoivent souvent pas l'attention que les utilisateurs souhaitent.
Alors que l'argent entre dans l'équation: en regardant les contributeurs de Samba sur GitLab, il apparaît que les employés de Catalyst, IBM (Red Hat), SerNet et SUSE (par ordre alphabétique) contribuent à la majorité des patchs du projet. Ces entreprises ont toutes un intérêt commercial dans Samba et certaines sont en concurrence les unes avec les autres. Google, employeur de Jeremy Allison, éminent contributeur à Samba, est un cas particulier: un intérêt commercial d'IBM pour Samba peut être justifié beaucoup plus directement par son produit Red Hat Enterprise Linux que les avantages que Google, en tant qu'entreprise, tire de sa participation.
Les quatre entreprises pré cédemment citées offrent cependant un soutien pour les problèmes liés à Samba en échange d'argent. D'autres entreprises peuvent également s'inscrire sur www.samba.org sous le point de menu "Support Samba". Si un client signale un problème avec Samba à l'une des sociétés mentionnées, un développeur se mettra au travail. Comme Samba est très complexe et multiforme, il est impossible pour un seul développeur de tout maîtriser. Cela conduit à une question centrale, que cet article examine de plus près: la communication au sein de l'équipe. En tant que développeur, à qui vous adressez-vous lorsque vous êtes bloqué par un problème, et par quels canaux?
30 ans de complexité croissante
La complexité de Samba provient du fait que, depuis ses débuts en tant que pur serveur SMB, il s'est développé au cours des 30 dernières années en une famille de composants ayant chacun ses propres implémentations de presque tous les protocoles importants dans le monde de l'Active Directory: en commençant par DNS, LDAP et Kerberos, en passant par SMB1/2/3 jusqu'à MS-RPC avec ses dizaines de sous-protocoles, Samba traite les clients avec ses propres serveurs. Chacun de ces serveurs ne peut même pas commencer à rivaliser avec les alternatives en termes de performance ou d'évolutivité.
Par exemple, un serveur OpenLDAP bien réglé tourne en rond autour d'un serveur LDAP Samba en ce qui concerne les besoins en mémoire ou les demandes par seconde. Cependant, la compatibilité avec les clients existants est le facteur le plus important dans ces décisions de type "make or buy".Microsoft AD est très compatible avec les RFC pour les protocoles standard tels que LDAP et Kerberos, mais tire également pleinement parti de l'extensibilité de ces protocoles.
Dans git, les commandes git blame et git whatchanged sont utilisées pour savoir à qui s'adresser en cas de problème dans des cas individuels lors du travail avec du code. Pour chaque ligne du code, git sort ensuite qui l'a modifiée en dernier lieu, et pour chaque fichier, l'historique complet des versions est disponible. Cela permet aux développeurs de voir exactement qui est l'expert sur une partie particulière du code.
De cette vue microscopique, cependant, il n'est souvent pas clair pourquoi un morceau de code fonctionne d'une certaine manière. Ainsi, un morceau de code incompréhensible est-il aussi complexe qu'il l'est pour de bonnes raisons, ou cette complexité est-elle plutôt un accident ? La question "Est-ce de l'art ou des déchets ?" est plus pertinente dans Samba à de très nombreux endroits que les étrangers pourraient le croire.
Qui sait?
Pour discuter de telles questions de conception, les développeurs ont besoin de contacts. Pour les initiés, il est assez facile de trouver la bonne personne: L'équipe Samba est un club assez ancien et bien connecté. Sur les 20 premiers contributeurs de l'année dernière selon openhub.net, 16 sont actifs depuis plus de cinq ans, 11 depuis plus de 10 ans, et trois même depuis plus de 20 ans.
Avant que la pandémie de corona ne rende la chose impossible, une grande partie de l'équipe Samba - ceux qui avaient le temps - se rencontraient en personne deux fois par an. Une fois au printemps à SambaXP à Göttingen, en Allemagne, et une fois à l'automne au SNIA SDC à Santa Clara, en Californie. À ces occasions, les quelques choses que l'équipe Samba doit décider en tant qu'organisation au sein du Software Freedom Conservancy SFC sont discutées, et vous apprenez à mieux vous connaître au "Chips and Salsa" de Pedro en vue d'Intel. Lorsque l'on se connaît personnellement, la communication purement électronique a beaucoup moins de chances d'aboutir à des malentendus. En aucun cas les smileys ne peuvent remplacer un sourire authentique ou un regard effarouché, mais au mieux ils peuvent les compléter.
Le SambaXP de Göttingen est l'un des rendez-vous personnels de l'équipe Samba, ici une photo de 2012.
Ainsi, ceux qui travaillent sur Samba depuis de nombreuses années, et qui ont également suivi le travail de leurs coéquipiers, savent qui est la bonne personne à qui parler pour quel domaine d'expertise. Malgré tout, vous commencez généralement par parler aux collègues de l'entreprise avec lesquels vous avez de toute façon des réunions d'équipe régulières.
Le choix des moyens de communication est flexible: on utilise ce qui est disponible à ce moment-là - e-mail, chat, téléphone ou vidéoconférence. Pour le chat, l'équipe s'appuyait autrefois sur IRC sur freenode ou sur son propre serveur IRC ; aujourd'hui, c'est le projet Matrix qui est utilisé. Pour les appels téléphoniques directs, grâce aux fuseaux horaires adjacents, il est assez pratique que la plupart des développeurs Samba soient situés dans deux points chauds: Australie et Nouvelle-Zélande, et Allemagne.
Changements apportés à Samba
D'un point de vue technique, vous devenez un membre de l'équipe Samba si vous avez un compte sur le serveur qui effectue l'intégration continue (CI) et, après une CI réussie, commet les correctifs dans le référentiel maître.
De nos jours, vous utiliseriez probablement GitLab pour cela. Mais Samba a pratiqué l'IC bien avant que ce terme n'existe: Chez Samba, ce qui est maintenant connu sous le nom de CI était appelé autobuild et build farm. Le système autobuild existe toujours aujourd'hui, et il constitue la base des pipelines d'IC sur GitLab, qui ont remplacé la ferme de build.
Chaque patch dans Samba doit être examiné par deux membres de l'équipe Samba. Cela signifie que si quelqu'un de l'équipe écrit un patch, il doit trouver un autre membre pour contribuer un "Reviewed-by:". En principe, la même règle s'applique aux contributions des non-membres: Ici aussi, deux membres de l'équipe doivent soumettre leur "Reviewed-by:"
Jusqu'à il y a quelques années, un correctif pour Samba passait par un chemin similaire à celui d'un correctif pour le noyau Linux: il était envoyé par courrier à la liste samba-technical. Là, il était commenté publiquement, revu, puis envoyé au système de construction automatique de l'équipe Samba. Cependant, à l'exception des correctifs très simples, il est pratiquement impossible aujourd'hui de faire passer un correctif par les milliers de tests du système de construction automatique du premier coup. Pour l'équipe Samba, cela signifie que pousser un correctif à partir d'externes représente potentiellement beaucoup de travail car, au minimum, vous devez communiquer les erreurs de l'autobuild à celui qui développe le correctif.
Demander aux externes d'effectuer un passage par autobuild n'est pas si facile non plus: le serveur autobuild de l'équipe Samba, avec 32 cœurs et 128 Go de RAM, prend jusqu'à deux heures pour un cycle complet. Bien que ce ne soit pas vraiment une demande énorme pour les serveurs selon les normes d'aujourd'hui, c'est considérablement plus de ressources que ce que vous avez généralement dans un ordinateur portable.
La construction automatique est un autre inconvénient.
Un autre inconvénient de l'approche par liste de diffusion pour le cycle des correctifs est que les correctifs peuvent être oubliés si personne ne s'en soucie activement. Après tout, il n'y a pas de liste centrale de correctifs en attente de commentaires. Il peut être frustrant et rébarbatif pour les nouveaux contributeurs de devoir continuer à pousser leur propre travail.
Nouvelles voies via GitLab
Pour décharger l'équipe Samba de son travail et abaisser les obstacles pour les contributeurs externes, l'équipe a commencé à établir une présence sur GitHub et à y utiliser l'infrastructure CI. Des préoccupations concernant la liberté de l'infrastructure ont ensuite conduit à se concentrer sur GitLab.
Donc, si quelqu'un veut contribuer aux correctifs de Samba de nos jours, la voie à suivre est de passer par un fork sur GitLab. Cependant, comme le pipeline CI de Samba est beaucoup trop grand pour les comptes gratuits, l'équipe offre la possibilité de pousser les contributions vers un dépôt de l'équipe Samba. L'équipe peut accorder la permission à ce dépôt relativement librement parce que le dépôt principal n'est pas sur GitLab, mais sur le serveur CI interne, auquel seuls les membres de l'équipe Samba ont accès.
Une fois le pipeline passé après un push, une demande de fusion est créée, qui est ensuite commentée. En mars 2022, cependant, il n'existe pas encore de mécanisme automatisé permettant à GitLab de pousser directement vers le dépôt maître Samba. Un membre de l'équipe Samba doit encore effectuer cette étape manuellement.
Discussion et résolution des conflits
Bien sûr, même Samba n'a pas traversé ses trois décennies de développement sans conflit. Si l'on devait citer le seul mécanisme de résolution des conflits, c'est que le code fonctionnel l'emporte sur tout. En fait, Samba dispose d'une énorme quantité de code fonctionnel et l'améliorer ou même le remplacer peut représenter un obstacle extrêmement important. Deux conflits dans l'évolution de Samba servent d'exemples: Samba TNG et Samba 3/4.
Samba TNG était une tentative d'adapter l'infrastructure basée sur l'environnement informatique distribué/les appels de procédure à distance (DCE-RPC) dans Samba à la structure interne de Windows. Un membre du domaine Windows parle à son contrôleur de domaine en utilisant la famille de protocoles DCE-RPC. DCE-RPC est un concurrent de l'ONC-RPC (Open Network Computing) initié par Sun, sur lequel NFS et NIS sont basés, et n'a initialement rien à voir avec SMB. Pour mettre en œuvre une base de données utilisateur analogue à NetWare Bindery, Microsoft avait besoin d'un cadre flexible pour transférer facilement des structures complexes sur un réseau. DCE-RPC était un bon choix car il n'était pas lié à TCP/IP comme protocole de transport, mais pouvait travailler de manière flexible avec des protocoles comme IPX et SMB via NetBEUI. Ainsi, pour devenir membre d'un domaine Windows ou même mettre en œuvre un contrôleur de domaine Windows, Samba devait mettre en œuvre DCE-RPC.
L'une des forces motrices derrière le développement de DCE-RPC dans Samba était Luke Kenneth Casson Leighton, qui a même écrit un livre à ce sujet (voir "Sources"). Ses développements ont été déterminants pour permettre à Samba de participer à des domaines Windows en tant que membre et contrôleur de domaine.
Cependant, il n'a pas réussi à convaincre le reste de l'équipe Samba de certaines de ses idées car elles étaient trop en avance sur leur temps. Cela s'est produit à une époque où un fork d'un projet était plus qu'un clic sur une page GitHub. C'est ainsi qu'est né Samba TNG, que Luke et quelques autres contributeurs ont passé quelques années à maintenir. En fin de compte, Samba TNG n'a pas pu rassembler suffisamment de ressources et a été abandonné.
Luke avait les bonnes idées, mais elles étaient très radicales à l'époque, et Samba fonctionnait déjà comme un contrôleur de domaine. Le fait que l'architecture des services RPC était complètement "fausse", c'est-à-dire différente de celle de Windows, était moins important dans l'évaluation que le code fonctionnant raisonnablement. Ce n'est que dans la version 4.16, plus de 20 ans plus tard, que l'équipe Samba a réalisé les idées principales de Samba TNG: fournir des serveurs MS-RPC dans des programmes séparés qui communiquent via des sockets.
Un deuxième serveur SMB
Le deuxième développement majeur qui s'est soldé par une impasse était la tentative d'Andrew Tridgell de réécrire le serveur SMB à partir de zéro. Après des années de développement sur Samba, il avait commencé à développer un nouveau serveur SMB avec une architecture améliorée basée sur son expérience du protocole SMB. Un serveur qui fonctionne de manière asynchrone et, surtout, qui implémente correctement le protocole SMB. Étant donné que SMB1, qui était encore en vigueur à l'époque, n'est pas documenté de manière satisfaisante à ce jour - et ne le sera probablement jamais - il a rédigé des tests à grands frais. Ils vérifiaient tous les aspects possibles du protocole par rapport à des serveurs Windows existants, puis les mettaient en œuvre exactement de la même manière dans son nouveau serveur.
Les développements d'Andrew ont conduit à une deuxième implémentation fonctionnelle d'un serveur SMB, qui est toujours présente dans le code source de Samba aujourd'hui, intégrée dans chaque build de développeur, et utilisée dans les tests. Cependant, cette deuxième implémentation n'a pas réussi à remplacer complètement le code existant, malgré les tentatives d'Andrew de convaincre le reste de l'équipe Samba que l'architecture est sans aucun doute bien meilleure.
Une fois de plus, la raison est que le code existant fonctionnait raisonnablement bien et que trop d'utilisateurs en dépendaient. Donc ici aussi: Le code fonctionnel est primordial.
Au fil des années, l'objectif d'Andrew a évolué, passant initialement d'un serveur SMB correct à une suite de tests complète pour le protocole SMB. Dans ce cadre, il a également décodé et mis en œuvre le protocole SMB2 introduit avec Vista. Quelque temps plus tard, lui et d'autres ont développé leurs propres serveurs DNS et LDAP et les ont combinés avec le Key Distribution Center (KDC) Heimdal pour créer un contrôleur de domaine Active Directory. Ce contrôleur AD fonctionnait comme tel, sauf qu'il était architecturalement étroitement lié à son nouveau serveur SMB. La faction du serveur SMB de l'équipe Samba a estimé qu'il était trop risqué de remplacer le smbd qui fonctionnait. L'équipe a donc fusionné à nouveau les deux branches de développement pour présenter un produit cohésif.
Conclusion
Samba, bien qu'étant un projet très complexe, a un objectif très simple: la compatibilité avec les clients et les serveurs existants. Cela permet de répondre facilement à la question du bon ou du mauvais code: fonctionne-t-il avec les clients Windows ou macOS et Linux ? Dans ce cadre, il y a suffisamment de place pour des développements, qui peuvent aussi parfois déboucher sur une impasse.
Source
- Luke Kenneth Casson Leighton ; DCE/RPC Over SMB: Samba and Windows NT Domain Internals ; Macmillan Technical, 2000
