Ce qui compte, selon moi, c'est d'avoir des paquets avec une validation propre.

Prenons, `bpytop`, depuis des lustres si tu l'installes sur un env Ubuntu ou Debian, il ne marche pas, parce qu'à tous les coups ils oublient des dép (genre psutils)

Les versions sont souvent à la rue, `podman` est ingérbale, des paquets font doublons, etc...

Depuis 22 ans, j'ai testé, retesté, etc... c'est, à mon sens, fou d'utiliser Debian/Ubuntu sur un serveur de prod.

@breizh @dada

@metal3d @dada J’ai jamais constaté ça, et ça marche nickel ici.

Perso j’ai à peine une dizaine d’année d’expérience, alors je te redis si j’ai eu des problèmes de ce type dans 12 ans ahah.

héhé, non mais qu'on soit clairs: je ne critique pas l'utilisation en soit, parce que oui: ça marche.

Mais ce que je dis, c'est que je ne comprends pas pourquoi tout le monde fonce tête baissée dessus alors qu'on est pas mal de "vieux roublards" à savoir que c'est pas du tout l'idéal.

PS: je ne mets pas de Fedora Server à mes clients, on passe par Rocky ou RH - pour l'heure ils sont tous d'accord avec moi sur le fait que Debian est "risqué" à leurs yeux

@breizh @dada

@metal3d @dada Les vieux roublards je m’en méfie, je suis trop souvent tombé sur des types avec des idées arrêtées au mieux bancales au pire erronée (un exemple frappant étant la swap ahah).

Je préfère me fier à mon jugement.

Après, je suis pas fan de Debian non plus, pas pour rien que je préfère Arch en perso.

Je constate simplement que bon, pour nos clients, j’irais pas leur coller du Arch. Du coup la question c’est Debian ou RPM, et j’étais plus compétent sur Debian, et la boîte où je suis tombé utilisais Debian depuis longtemps, et du coup… bah Debian, quoi. Et Proxmox pour les hyperviseurs.

Et ça réponds bien aux besoins à la fois les nôtres et ceux des clients, donc pas de raison de chercher à changer. Ce que je dis souvent, c’est qu’un gros changement est lié à un gros avantage, pas juste un léger.

Ou dis autrement, tant qu’on a pas de problèmes sérieux avec Debian, l’effort de faire un changement de distro ne vaudra pas le coup par rapport à juste améliorer ce qu’on maîtrise déjà pas mal.

@metal3d @dada Maintenant si je devais partir de rien, et après avoir eu une formation sur du RPM-based, j’y réfléchirais ptêt à deux fois. Mais aujourd’hui j’ai pas de raison de quitter Debian en pro, et pas de temps ni d’intérêt à aller sur du RPM en perso.

Bah le fait est que ce sont les arguments qui comptent et que l'expérience en apporte.

Prend seulement les deux faits que j'ai expliqué, par exemple l'activation d'app nginx dans sites-available, et le nommage de comptes système et imagine qu'on est forcé de faire des tests à l'install pour être compatible deb vs le reste du monde. Rien que ça c'est induit par Debian et dérivés.

@breizh @dada

@breizh @dada après oui bien entendu que l'habitude et les compétences dans telle ou telle distro comptent pour le choix. Et on est bien d'accord que je n'installe pas une distribution pour un client seulement à partir de les préférences.

Je dis juste, dans mon premier message, que je ne comprends pas l'engouement pour deb/buntu surtout pour leur manque de rigueur et de respect des conventions.

@metal3d @dada C’est quoi le problème avec sites-available au fait ? J’ai pas compris ce point.

Et puis je connais pas deux distros compatibles entre elles, c’est pas Debian vs. le reste du monde mais Debian vs. Arch vs. Fedora vs. Gentoo vs. Void, etc.

La nomenclature normalisée c'est un "conf.d" dans lequel tu poses tes fichiers de conf. Toutes les distros utilisent ça, sauf les deb like.

Du coup, par exemple, quand le mainteneur du conteneur NGInx a fait sa tambouille, il a laissé cette conf pour les "Alpine"

Résultat: les conteneurs ont tous pété à la tronche des utilisateurs

@breizh @dada

@metal3d @dada J’ai envie de dire, on s’en fous, t’es même pas obligé de faire comme la distro le propose par défaut, /etc c’est l’admin qui décide de comment il gère.

Et séparer les mods des conf des vhosts je trouve que c’est une plutôt bonne pratique au contraire, et si c’était pas par défaut sous Debian j’aurais sûrement fait un truc similaire.

Quand à ton mainteneur, s’il utilise Alpine pour ses docker sans connaître Alpine, et sans vérifier la conf qu’il déploie, c’est un branque, c’est pas de la faut à Debian…

Tu bottes en touche. Le souci est réel. Les mainteneurs sont les gens de Docker, ils automatisent un pauquet de chose.

Or, des règles spécifique de Debian mettent à mal la symbiose des conf. C'est bien de la faute de Debian là.

@breizh @dada

@metal3d @dada Oui je botte en touche, et donc ?

Et nope, y’a aucune règle qui dit que toutes les distros doivent avoir la même conf 🤷.

Ni même tous les serveurs. Franchement, c’est un non problème à mes yeux, sérieusement.

Surtout que « les mainteneurs sont les gens de docker » oui mais les mainteneurs sont censés maintenir pour une distro, par pour un truc universel.

Les mainteneurs docker Debian devraient pas être les même que les mainteneur docker Alpine, sauf à maîtriser les deux bien sûr (ce qui n’est visiblement pas le cas).

Après j’aime pas Docker en premier lieu, ça aide sans doute pas. Mais chaque distro fait son boulot, et c’est la responsabilité des mainteneurs de chaque distro, et ça ne regarde que la distro et les admins.

alors si, y'a la FHS: https://fr.wikipedia.org/wiki/Filesystem_Hierarchy_Standard

C'est un exemple parmi plein de standard.

Quant à ta remarque sur les mainteneurs Docker, tu imagines que tu demande un nombre exponentiel de mainteneurs ?

@breizh @dada

@metal3d @dada Oui, j’en ai bien conscience. Ou juste des mainteneurs plus compétents (c’est courant que les mainteneurs s’occupent de plusieurs distros à la fois).

Mais c’est eux qui se sont mis dans cette position.

Il est absolment normal que le mainteneur d'une solution se charge des distros.

Tu ne peux pas demander à un spécialiste Debian de packager 300 applications sur Docker.

Tu peux par contre demander à un spécialiste Nginx de packager pour 4 ou 5 distrso "demandées"

@breizh @dada

@metal3d @dada Yep, mais il faut qu’il soit compétent là-dessus. Là il a fait n’importe quoi. S’il sait pas une distro, qu’il ne s’en occupe pas. Ou qu’il apprenne, je sais pas. En tout cas la faute est de son côté là.

Alors justement c'est pas la question.

Si tu normalises, tu dois pouvoir compiler et installer sur Arch, et le même script, ou presque, doit passer sur les autres distro. La seule différence va venir des install de package de dependances.

Or, comme je te le dis, si tu pars du principe que "sites-enabled" est un truc standard, alors tout pète sur les autres distros.

Debian donne des mauvaises habitudes, vraiment

@breizh @dada

@metal3d @dada Bah non. C’est le boulot de chaque distro de faire son propre script. Tu dois pas produire un truc universel. C’est le boulot de chaque distro de faire ce job pour ses spécificités.

C’est pour ça que ça peut être des personnes tout à fait différentes qui s’en occupent.

Je suis désolé mais je pense que tu as un biais d'utilisation.

Je prend un exemple: je code une app, je propose un truc qui ne marche que sur Fedora (pour faire chier le monde) - tu attends quoi ? que Debian fournisse un paquet modifié, ou que je fasse mon job et que je propose un mode d'install qui fonctionne partout ?

@breizh @dada

@metal3d Que Debian fasse son paquet modifié. C’est pas ton job d’être compatible avec toutes les distros (et heureusement vu le nombre).

Par contre tu dois avoir une procédure d’installation propre pour que celle-ci puisse être adaptée par les mainteneurs.

Mais du coup dans l’exemple de Apache, par défaut c’est conf.d, et derrière Debian fait sa modif, je vois pas le problème. C’est pas ton problème cette modif, c’est le leur. Ta doc elle dit conf.d, ta conf par défaut aussi, t’es même pas censé être au courant que ça a été modifié (on te demande pas de l’être en tout cas).

@metal3d Et perso je dis que si tu considères que site-enabled est standard, tu fais une faute qui t’es imputable. 🤷

Sauf que c'est le mode standard de Debian...

Et que quand un dev me donne un makefile qui utilises "site-enabled", je suis cramé pour l'install sur une RH.

Et si je modifie le script, pour utiliser conf.d, alors ça ne va pas marcher sur Debian. Debian est le seul à faire ça.

@breizh

Ce que beaucoup n'arrive pas à comprendre c'est que ce souci n'est induit que par une seule distrib: Debian. C'est la seule qui casse autant les standards.

Arch, Rocky, RH, Gentoo, alpine, etc... ne posent pas ces problèmes

@breizh

@metal3d J’ai du mal à voir pourquoi un makefile est censé toucher à la conf apache, mais oui, c’est à toi en tant qu’admin de le modifier pour correspondre à ton installation. Et si t’as plusieurs machines avec des configurations hétérogènes, c’est à toi d’adapter le script pour les différents cas. Je vois pas le problème.

@metal3d @breizh @dada Si on pouvais faire des recettes universelles ça se saurait, même dans le monde rpm chaque distro à ses spécificités, même si typiquement coté serveur c'est le plus RHEL-compatible possible mais c'est pas un truc auquel tu peux vraiment compter dessus sans avoir des problèmes de temps à autres.

La création de package est un autre problème

@lanodan @dada @breizh

@metal3d @dada @breizh Un Dockerfile c'est tout autant une recette, pareil pour genre Ansible.

Si tu veux des exemples:
https://github.com/nginxinc/docker-nginx/issues/171

Si tu cherches "docker nginx issue site-available" tu vas voir le bordel que ça crée.

C'est une idée absurde, surtout qu'on leur dit depuis des années (à Debian) que faire un simple lien symbolique entre "sites-available" et "conf.d" pourrait déjà corriger un paquet de problèmes. Mais ils s'en tamponnent (position dominante)

@breizh @dada

@metal3d @dada Bah euh, faire un lien entre les deux casse complètement la mécanique en fait, ce qui est dans available est pas de la conf active, ce qui est actif est dans enabled… si t’actives tout ce qu’il y a dans available tu fous la merde.

je voulais dire "enabled", pardon

@breizh @dada

Et je ne te parle pas des délires avec le compte "apache" qui devient "www-data", et qu'ils ont appelé "httpd" => apache...

Apache n'est pas un serveur, ils n'arrivent pas à l'admettrre. Apache propose httpd et tomcat.

Foutre un utilisateur commun entre nginx, tomcat et httpd c'est délirant...

Bref, ils font un peu n'imp. On s'en sort hein, mais ils nous complique la tâche 🙂

@breizh @dada

@metal3d @dada Après comme je l’ai dit j’aime pas trop Debian et le fait qu’ils customisent toutes les confs fait un peu partie du lot. J’aime bien la politique de Arch d’être le plus upstream possible par exemple.

Mais bon, ce sont les mainteneurs de la distro qui décident, soit ça te convient et tu fais avec, soit ça te convient pas et tu vas voir ailleurs, l’avantage c’est qu’il y a du choix 🤷.

Par contre je reste sur mes positions sur le fait que les choix qu’ils font n’ont aucune influence sur les autres distro, s’il y en a c’est de la faute à ceux qui mélangent tout, pas à Debian. À un moment faut savoir faire son job correctement.

Je ne te dis pas que Debian influe sur les autres distros. Je te dis qu'ils influent sur le travail des packageurs (que ce soit Docker ou pas)

Casser des standards, des normes, ne pas respecter la paroles des éditeurs de solutions (apache est un exemple parmis des centaines), c'est un "problème"

@breizh @dada

@metal3d @dada Pas pour moi. Pour moi ça fait partie du travail de la distribution.

Tu peux pas appliquer tout ce que l’upstream impose parce qu’il y a pas qu’un seul upstream. L’adapter au reste de la distro fait partie du job.

Après ici, c’est pas forcément pertinent ce qu’ils font, mais ils sont libres de le faire.

Non, justement.

Quand tu package Nginx sur un conteneur, tu ne prends surtout pas les paquets de la distribution (qui implique des deps, des prefs, etc...)

Tu compiles et installes.

Or, si ta base d'automatisation part de Debian, tu as des soucis de compat sur 99% des autres distros. Or, Debian est utilisé de-facto (de moins en moins) - donc ça pose problème

@breizh @dada

@metal3d Bah c’est le principe d’une distribution. Si tu veux pas être lié à la distribution, met pas une distribution dans ton container, en fait.

Ou alors on se comprends pas (la conf est en dehors du container ?).

On se lit à une distribution pour des raisons pratiques:

- avoir une image de base et pas 20, pour limiter le poids de ta base images
- avoir des versions de lib communes ou imposées par un client (genre, la libssl)
- avoir du support sur des paquets en dépendance

La distro compte

@breizh

@metal3d Je vois. Mais du coup tout l’argumentaire ici c’est « comment bypasser le travail de la distribution tout en restant compatible avec » et du coup ma réponse c’est « ne faites pas ça ».

@metal3d J’aime bien ces articles sur la question du job des distros, et de pourquoi idéalement les packagers ne devraient pas être liés à l’upstream (ou au moins être capable de séparer les casquettes s’ils le sont).

https://drewdevault.com/2021/09/27/Let-distros-do-their-job.html

https://drewdevault.com/2019/12/09/Developers-shouldnt-distribute.html

CentOS / RH / Fedora ou encore Rocky (qui remplace CentOS) ont un bien meilleur pipeline de validation de package (je ne sais pas si tu as déjà utilisé rpmbuild mais c'est tellement strict que tu ne peux pas oublier de le moindre truc)

On a SELinux, ça respecte les noms (pas de "apache" pour parler de "httpd", et la connerie pure d'avoir un "site-availables" qui fout le merdier, j'en ai fait les frais avec le mainteneur Docker Nginx)

J'adore Arch au passage

@breizh @dada

Donc, pour reprendre tes termes, non... Debian ne fait pas "parfaitement le travail" 😜

@breizh @dada

Par contre je vais préciser un truc: je suis souvent forcé d'utiliser Ubuntu ou Debian sur des images de conteneurs... parce que les devs ont réussi à nous pondre des trucs qui ne marchent que sur cette distro. Et le pire c'est que quand on prend le temps de faire la migration sur Rocky ou Arch par exemple, et bah on nettoie et ça marche mieux (et partout).

Moralité, je pense qu'il faut que Deb/Buntu fasse un effort de "conformité Linux"

@breizh @dada

@metal3d @dada Bah Ubuntu pour le coup c’est d’la marde.

Après, ça c’est un reproche à faire aux devs plus qu’au mainteneurs, et j’en ai des tas à faire là-dessus…

@breizh @dada @metal3d Je vous remercie pour cette discussion très enrichissante.