Le défi d’Alpine Linux vu par un utilisateur BSD

 (rubenerd.com)
1 points par GN⁺ 2024-04-28 | 1 commentaires | Partager sur WhatsApp
  • Un utilisateur qui se sert souvent d’un bureau BSD ainsi que de chroot et de jails teste Alpine Linux, et estime que sa conception centrée sur la sécurité, la simplicité et l’efficacité des ressources parlera aux utilisateurs BSD
  • Grâce à sa petite taille et à ses dépendances limitées, Alpine est largement utilisée non seulement comme image de base pour conteneurs, mais aussi dans les systèmes embarqués, les routeurs, les appareils mobiles, les serveurs et les postes de travail
  • L’installation consiste à exécuter setup-alpine depuis l’environnement live, puis à configurer successivement les réglages de base comme le keymap, le réseau, le fuseau horaire, SSH et NTP
  • Après le premier démarrage, la combinaison OpenRC, musl et busybox apparaît clairement, avec des éléments comme /etc/rc.conf et crond(8) qui rappellent l’expérience rc façon BSD
  • Après avoir vérifié la gestion des paquets avec apk, la configuration des dépôts et la possibilité d’installer ZFS, l’impression est assez bonne pour envisager sérieusement Alpine comme distribution Linux principale candidate pour les tests et les serveurs

Le caractère d’Alpine familier aux utilisateurs BSD

  • Alpine Linux est une distribution Linux indépendante, non commerciale et généraliste destinée aux power users qui privilégient la sécurité, la simplicité et l’efficacité des ressources
  • Les binaires de l’espace utilisateur sont compilés en PIE (Position Independent Executables) avec protection contre le stack smashing, avec l’objectif de réduire l’exploitation de certains zero-days et vulnérabilités
  • Alpine est un projet plus ancien qu’on ne pourrait le penser, Natanael Copa ayant discuté des origines du projet dès 2005
  • Comme les systèmes de la famille BSD, elle est utilisée dans les systèmes embarqués, les routeurs et les appareils mobiles, mais aussi sur des serveurs et postes de travail classiques
  • Sa petite taille et ses dépendances limitées en font une image de base largement utilisée pour les conteneurs Linux, et il existe aussi des outils comme alpine-chroot-install pour l’exécuter facilement dans chroot(8)
    • C’est un point particulièrement intéressant pour les utilisateurs qui se servent beaucoup de chroot(8) sur NetBSD et des jails FreeBSD pour les tests et les déploiements

Expérience d’installation

  • Alpine fournit plusieurs builds, notamment pour ARM, PPC64, x86 et x86_64
  • L’image ISO Xen a été démarrée dans une VM, mais c’était un choix dû à une mauvaise lecture de Dom0 comme DomU
    • Dom0 désigne l’hyperviseur Xen, pas un invité
    • Malgré cela, le démarrage et l’installation se sont déroulés comme avec une ISO standard
  • L’installation se fait depuis l’environnement live en se connectant avec root et un mot de passe vide, puis en exécutant setup-alpine
  • Pendant l’installation, les éléments de base comme le keymap, le réseau, le fuseau horaire et l’authentification root sont configurés l’un après l’autre
  • Il est possible d’injecter des clés SSH au début du processus
    • C’est utile lorsqu’on déploie ensuite des lots de VM ou de serveurs avec des outils d’orchestration
    • C’est également pratique dans les environnements d’hébergement qui ne fournissent pas de console OOB
  • On peut choisir le serveur SSH et le client NTP, ce qui a permis de sélectionner OpenSSH et openntpd
  • Le processus d’installation détecte correctement qu’il s’exécute sous Xen
  • La configuration LVM est également possible, mais cette fois la configuration standard, qu’Alpine appelle partition sys, a été choisie
    • Cette configuration utilise ext4

Configuration visible après le premier démarrage

  • Après le premier démarrage, dmesg(1) permet de vérifier que le système utilise OpenRC
  • OpenRC est un système init portable, compact, rapide, efficace, transparent et sûr
  • Pour les utilisateurs habitués à écrire des scripts rc façon BSD, OpenRC est très familier
    • Des éléments comme /etc/rc.conf et crond(8) rejoignent l’expérience utilisateur BSD
  • L’existence de distributions Linux utilisant OpenRC, comme Devuan, Gentoo et Alpine, redonne un côté amusant à Linux
  • Alpine inclut musl avec OpenRC et utilise busybox
    • musl et busybox sont plus limités que GCC et les GNU coreutils, mais contribuent à la petite taille du système de base et à la réduction de la surface d’attaque
  • llvm est également disponible
  • Le MirBSD Korn shell est aussi proposé sous forme de paquet, et fait partie des shells interactifs préférés

Gestion des paquets et dépôts

  • Le gestionnaire de paquets par défaut d’Alpine est apk
  • Comme c’est courant sous Linux, apk ne distingue pas le système de base des paquets et les met à jour ensemble
  • Il n’a pas encore été vérifié s’il peut être exécuté depuis une copie non privilégiée comme sous BSD
  • pkgsrc est également disponible, ce qui laisse une alternative
  • La configuration des dépôts se trouve dans /etc/apk/repositories
    • Décommenter la deuxième URL fournie par l’installateur permet d’activer le dépôt community
    • Alpine dispose aussi d’un dépôt testing, et il est possible d’ajouter ses propres dépôts
  • L’utilisation est simple, même si les habitudes font parfois saisir par erreur apt install au lieu de apk add
  • L’interface web officielle des paquets se trouve sur pkgs.alpinelinux.org
  • Les dépôts Alpine peuvent aussi être consultés sur pkgs.org

ZFS et évaluation comme candidate pour les serveurs

  • Après avoir installé quelques paquets, il a été possible de retrouver la configuration d’« outils indispensables » utilisée sur un ordinateur portable uniquement en console
  • L’un des paquets les plus surprenants était ZFS
    • L’installation et le chargement du module noyau ont pu se faire en deux commandes
# apk add zfs zfs-lts


# modprobe zfs
  • Configurer le système de fichiers root sur ZFS pourrait être plus complexe
  • Le comportement de la configuration ZFS après une mise à niveau n’a pas encore été vérifié
  • Rien qu’avec l’expérience acquise jusqu’ici, l’impression est assez bonne pour envisager sérieusement de basculer vers Alpine comme distribution Linux principale pour les tests et les serveurs
  • Parmi les points forts cités figurent le fait de ne voir qu’un petit nombre de processus reconnaissables dans htop(1) et lsof(1), l’usage d’OpenRC, une gestion des paquets qui semble simple et une configuration facile
  • S’il existe un « Occam’s Linux » moderne et fonctionnel, Alpine en serait proche
  • Si davantage de fonctionnalités que busybox sont nécessaires, il serait possible d’essayer uutils, mais le besoin semble limité sur un serveur

À lire aussi

1 commentaires

 
GN⁺ 2024-04-28
Avis sur Hacker News

  • Du point de vue de la sécurité, la plupart des binaires Linux sont aujourd’hui compilés en PIE
    Si l’on lance checksec sur un binaire quelconque d’Ubuntu, cette propriété apparaît, et on peut installer checksec avec pip install pwntools
    À l’inverse, GLIBC possède, à ma connaissance, l’implémentation de tas la plus renforcée, avec davantage de mesures d’atténuation contre le double free et d’autres attaques sur le tas
    De ce point de vue, on pourrait donc dire qu’Alpine est moins sûre parce qu’elle utilise musl, mais le fait d’être un système petit et facile à comprendre est un vrai avantage en matière de sécurité

    • Je ne vois pas très bien en quoi « un système petit et facile à comprendre » serait un argument en faveur de glibc. J’aurais plutôt tendance à penser l’inverse
    • Sur les nœuds Alpine, je lance toujours checksec sur tout, et tous les processus ressortent comme ceci. La sortie complète est longue, donc je l’omets, mais je n’ai jamais vu ces flags absents de quelque chose compilé par Alpine
      COMMAND PID RELRO STACK CANARY NX/PaX PIE
      init 1 Full RELRO Canary found NX enabled PIE enabled
      [snip...]
      crond 422838 Full RELRO Canary found NX enabled PIE enabled
    • La libc d’OpenBSD mérite aussi d’être regardée
    • Du point de vue de la sécurité Linux, si quelqu’un peut exécuter ne serait-ce qu’un peu de code sur le système, c’est déjà terminé. Linux est plein de failles, et s’il n’est pas aussi envahi par les malwares que Windows, c’est parce que peu de gens utilisent Linux sur desktop, donc les auteurs de malwares ne le ciblent pas vraiment
      Honnêtement, je pense que Windows moderne comme macOS ont tous deux une meilleure architecture de sécurité

  • Je viens aussi du monde BSD et, par hasard, j’ai lancé Alpine pour la première fois cette semaine dans une VM sur bhyve
    Le point clé, c’est BusyBox. Si les utilitaires de /bin et /sbin n’ont pas besoin d’être chacun des binaires indépendants, l’espace utilisateur devient très petit et le démarrage rapide. Avec Tmux et zsh installés, c’était suffisant pour la plupart des usages Unix
    Pour arriver à l’environnement final, j’ai quand même dû installer pas mal de choses avec apk, mais globalement, c’était la meilleure expérience Linux que j’aie eue depuis longtemps. J’aimerais que ZFS soit inclus par défaut, et que la connexion virtio adaptée à l’exécution basée sur ZFS de bhyve soit plus explicite

    • J’utilise et déploie FreeBSD depuis plus de 20 ans, et franchement, me connecter à une machine GNU/Linux me rebute. Il y a tellement de variantes et d’incohérences que le système donne l’impression d’être en bazar. Me connecter à un serveur Windows me semble presque plus « logique »
      Cela dit, je suis content d’apprendre qu’il existe peut-être une distribution Linux sensée, et si j’ai besoin d’une machine Linux, je l’essaierai. Mais cela arrive assez rarement
    • Je me demande jusqu’à quel point vous voudriez que ZFS soit « intégré par défaut ». Alpine fait partie des rares distributions qui fournissent des modules noyau ZFS binaires, donc une seule commande apk suffit presque à l’installer
      Le wiki Alpine contient aussi une documentation plutôt correcte pour installer le système de fichiers racine sur ZFS : https://wiki.alpinelinux.org/wiki/Root_on_ZFS_with_native_en...
    • ZFS fonctionne très bien sur Alpine. Alpine + ZFS est ma configuration serveur par défaut depuis plusieurs années

  • Si vous êtes utilisateur de BSD, Void Linux pourrait aussi vous plaire. C’est une distribution créée par xtraeme, développeur NetBSD ; elle existe en versions glibc et musl, et utilise runit comme système d’initialisation
    On peut aussi compiler les paquets depuis les sources avec xbps-src
    https://voidlinux.org/

    • Après avoir utilisé Arch, j’ai fini par m’installer sur Void en cherchant une alternative sans SystemD qui ait une sensation proche d’Arch. Si j’ai choisi Void plutôt qu’Alpine, c’est grâce au support de glibc, qui me permettait d’utiliser les pilotes NVidia. Oui, je connais les « huées contre NVidia »
    • J’aime beaucoup Void. Mon système principal reste Arch à cause du grand choix de paquets et des commodités de systemd, mais j’ai installé Void chez des proches et sur trois de mes machines, et c’était excellent
      Il faut toutefois noter que je n’ai utilisé que des installations xfce avec des modifications minimales. Les configurations multi-utilisateurs complexes peuvent être un peu plus pénibles, car runit embarque moins de fonctionnalités par défaut que systemd
    • Il y a quelques années, il y avait des problèmes avec Rust sur voidlinux+musl. Heureusement, Void peut être facilement réinstallée avec glibc
    • Chimera pourrait aussi convenir. L’espace utilisateur des outils de base vient en grande partie de FreeBSD, donc cela devrait sembler assez familier aux utilisateurs de BSD
    • Il y a aussi CRUX. C’est en quelque sorte la distribution dont Archlinux est issue

  • Je m’attendais à ce que quelqu’un mentionne que les pages man, dont les BSD sont si fiers, ne sont pas incluses par défaut dans Alpine. C’est l’une des raisons pour lesquelles je n’utilisais pas Alpine sur mon ordinateur portable de voyage, et j’utilise maintenant OpenBSD
    Ai-je raté une option de configuration qui ferait que la documentation soit toujours installée quand on récupère un paquet sur Alpine ? Ou faut-il forcément installer manuellement les paquets -doc à chaque fois ?

    • Si vous voulez toujours la documentation, installez le méta-paquet docs. Il tirera ensuite les paquets *-doc correspondant aux éléments que vous installez
    • Avec OpenBSD sur un portable, qu’en est-il de la prise en charge matérielle ?

  • Honnêtement, je ne comprends absolument pas pourquoi les gens trouvent des choses comme OpenRC séduisantes. N’importe quelle approche fondée sur la supervision me paraît meilleure que de laisser traîner un PID, de l’enregistrer dans un fichier PID, puis d’espérer que trois semaines plus tard cette valeur pointe encore vers le démon lancé.
    En plus, dans certains cas, la gestion du service se fait en lançant pgrep sur un nom de processus donné. Je suis assez d’accord avec l’idée qu’il ne faut pas tout redémarrer automatiquement par défaut, mais c’est à peu près le seul avantage que ce camp puisse vraiment faire valoir.
    Et au final, ces systèmes dépendent fortement de syslog, qui est vraiment une technologie des années 80. Des outils comme multilog ou svlogd pourraient être améliorés pour offrir plus facilement une vue centrale de l’ordre des événements entre plusieurs outils, mais regrouper les logs dans des catégories floues et permettre à n’importe qui d’écrire des logs n’importe où sous n’importe quel nom me paraît étrange.

    • À noter qu’Alpine essaie depuis plusieurs années de remplacer OpenRC, sans avoir trouvé d’alternative adéquate. Il existe aussi une tentative d’en faire une distribution indépendante du système d’initialisation.
      https://mastodon.social/@ariadne@treehouse.systems/112044942...
      https://mastodon.social/@ariadne@treehouse.systems/112214386...
    • Cela dit, la principale alternative est systemd, et il a été conçu d’une manière peu sûre, laissant la porte ouverte à de nouvelles CVE intéressantes.
      Il y a trop de choses dans PID1, et il est écrit dans un langage qui n’est pas sûr du point de vue mémoire. Je ne vois pas de raison technique empêchant de le découper en un PID1 minimal et quelques programmes setuid.
      La seule chose qui me vienne à l’esprit est que cela permet de faire tourner systemd dans un conteneur Docker, mais Red Hat/IBM préfère probablement que l’on utilise ses propres outils de conteneurisation, comme systemd-nspawn, et ne doit donc pas y tenir particulièrement. Dans sa structure actuelle, je ne pense pas que ce soit jamais défendable du point de vue de la sécurité.

  • Alpine a un avantage amusant. Quand les utilisateurs de Nix se vantent de la gestion déclarative des paquets, on peut éditer directement /etc/apk/world puis exécuter apk fix pour leur montrer comment faire sans Nix.

    • En général, je préfère l’approche de Gentoo. Les paquets installés manuellement peuvent être dans /var/lib/portage/world, les ensembles sélectionnés dans /var/lib/portage/world_sets, et les définitions d’ensembles dans /etc/portage/sets/.
      Cela permet de répartir les paquets par catégories, de n’en installer certains que sur les systèmes qui en ont besoin, et d’ajouter librement des commentaires dans les fichiers. L’équivalent de apk fix est emerge -uDU @world && emerge -c, même si c’est un peu plus lourd.
      Alpine permet aussi de créer quelque chose qui ressemble à des ensembles avec apk add -t setname pkg1 pkg2 pkg3, ce qui crée un paquet factice dépendant des paquets choisis. De mon côté, je crée souvent des scripts shell dans /etc/apk/sets/ pour imiter l’esprit Gentoo, mais ce n’est pas toujours identique.
    • Le temps que Nix évalue le flake de mon système, je pourrais réinstaller Alpine depuis zéro.
    • C’est classe, mais Nix/OS fait beaucoup plus que l’installation déclarative de paquets.

  • Je me souviens qu’il y avait autrefois des articles sur les performances quand on faisait tourner Alpine dans Docker, et qu’ils recommandaient d’utiliser Debian/Ubuntu.
    Articles sur la lenteur d’Alpine :
    https://pythonspeed.com/articles/alpine-docker-python/
    https://superuser.com/questions/1219609/why-is-the-alpine-do...
    Article favorable à Alpine :
    https://nickjanetakis.com/blog/benchmarking-debian-vs-alpine...
    Je me demande si tout cela est encore valable aujourd’hui.

    • Une bonne partie des reproches précis a au moins été corrigée. Comme le reconnaît aussi la fin du premier lien, il existe désormais des wheels Python compatibles avec Alpine, et les problèmes DNS ont été corrigés il y a déjà un bon moment.
      Cela dit, il serait intéressant de lancer des benchmarks et de voir les chiffres réels côté performances.

  • musl ne prend toujours pas en charge pthread_attr_setaffinity_np, non ? Dans ce cas, certains logiciels ne peuvent pas tourner, le plus gros exemple étant PyTorch.

    • Si une charge de travail sensible aux performances dépend de glibc pour cette raison, on peut sans doute « simplement » faire tourner cette application dans un conteneur.
      Dans beaucoup de situations, la simplicité ou la sécurité sont des préoccupations plus importantes que les performances.

  • Le juste milieu que j’ai trouvé entre BSD et Linux, c’est Slackware. C’est fièrement Unix dans l’esprit, peu compliqué, et il y a aussi un riche arbre de ports maison via Slackbuilds.

    • Slackware a essayé de concurrencer les distributions desktop, mais s’est perdue en chemin sans vraiment s’y consacrer.
      À l’époque, je l’aimais parce que c’était une distribution minimale qui ne se mettait pas en travers de votre chemin, et je la voyais comme visant des utilisateurs un peu plus techniques.
      Mais quand on creusait un problème, la communauté pouvait se montrer hostile si l’on n’avait pas fait une installation complète. La raison invoquée était que l’installation complète était la méthode recommandée, et si on ne le faisait pas, on se retrouvait avec des problèmes de dépendances idiots, du genre mplayer qui ne marche pas parce qu’il manque samba.
      Je considère qu’Alpine est une amélioration par rapport à Slackware sur tous les plans.
    • Je respecte les gens qui utilisent Slackware, mais l’absence de gestion des dépendances a l’air pénible.

  • Alpine Linux n’était donc pas vraiment GNU/Linux. Je ne le savais pas.
    Ce serait alors BusyBox/Linux ?

    • Il suffit de l’appeler Alpine Linux. À ma connaissance, BusyBox n’a rien à voir avec les accès occasionnels d’autopromotion qui échappent à RMS, donc ça va.