Crux 3.1: une distribution KISS à la saveur BSD

Posté par (page perso) . Édité par palm123, Xavier Teyssier et Christophe Guilloux. Modéré par Christophe Guilloux. Licence CC by-sa
Tags :
31
25
juil.
2014
Distribution

Crux est disponible dans sa version 3.1 depuis le 16 juillet dernier. Cette distribution, qui a été la principale source d'inspiration à la création d'Arch Linux, suit le principe KISS (keep it simple), dispose d'un système d'init à la BSD ainsi que d'un système de [ports]. C'est une distribution légère ciblant l'architecture x86-64 et des utilisateurs Linux avancés.

Crux, dont la première version date de décembre 2002, n'est basée sur aucune autre distribution et possède ses propres outils pour, par exemple, la gestion des paquets et ports.

Plus d'informations se trouvent dans la suite de la dépêche.

Sommaire

Scripts d'initialisation

Les utilisateurs de systèmes *BSD ne devraient pas être trop dépaysés par Crux. En effet, point de systemd ici mais un système d'init à la BSD.

Le système comporte plusieurs runlevels, tels que définis dans /etc/inittab:

  • 0: halt
  • 1: mode utilisateur unique
  • 2: mode multi-utilisateur
  • 3-5: non utilisés
  • 6: reboot

Le script de démarrage système est défini dans /etc/rc alors que celui pour l'extinction se trouve dans /etc/rc.shutdown et l'initialisation des modules passe par /etc/rc.modules. Le script pour le mode utilisateur unique dans /etc/rc.single, pour le mode multi-utilisateur dans /etc/rc.multi.

La configuration de base du système se fait via /etc/rc.conf et les scripts des services, par exemple sshd, se trouve dans /etc/rc.d.

Ports et paquets

Le système de paquets utilise des simples tarballs tar.gz, sans métadonnées. Cependant, l'extension .pkg.tar.gz est utilisée afin de permettre de différencier un paquet d'un simple tarball. Les paquets peuvent également être compressés avec bzip2 ou encore xz et dans ce cas là, l'extension est changée en accord (.pkg.tar.bz2 et .pkg.tar.xz).

Les paquets s'installent et se mettent à jour via pkgadd(8), se désinstallent via pkgrm(8) et peuvent se créer via pkgmk(8) tandis que pkginfo(8) permet l'obtention d'informations sur les paquets.

Ce système de paquets simple ne supporte pas, par exemple, la résolution des dépendances. En revanche, un front-end, prt-get(8), est fourni avec le système et permet notamment la résolution des dépendances.

Crux comprend également un système de ports que l'on peut trouver dans /usr/ports. Un port comprend les fichiers Pkgfile, .md5sum et .footprint. Le Pkgfile est en réalité un script shell spécial qui permet la création d'un paquet, un peu à la manière d'un PKGBUILD chez Arch Linux. Un exemple valant mieux que mille mots:
```

Description: Compression utility using the lzma algorithm, successor of lzma-utils

URL: http://tukaani.org/xz/

Maintainer: CRUX System Team, core-ports at crux dot nu

name=xz
version=5.0.5
release=1
source=(http://tukaani.org/xz/$name-$version.tar.bz2)

build() {
cd $name-$version
./configure --prefix=/usr \
--mandir=/usr/man \
--disable-nls
make
make DESTDIR=$PKG install

ln -s liblzma.so.$version $PKG/usr/lib/liblzma.so.0

rm -r $PKG/usr/share

}
``Le fichier.md5sumsert donc à stocker la somme md5 du (des) tarball(s) nécessaire(s) à la création du paquet tandis que le fichier.footprint` contient la liste des fichiers et dossiers créés par le port. Évidemment, si des patches ou fichiers de configuration sont nécessaires, ils prendront également leur place dans le dossier du port en question.

Il faut noter que les paquets sont réduits au strict minimum. Ainsi, les fichiers de traduction ne sont pas installés, de même que les fichiers de documentation tels des README, fichiers *.info ou *.html, etc. Seules les pages de manuels sont conservées comme documentation.

L'arbre des ports se synchronise via l'utilitaire ports(8). Ainsi, une mise à jour de son système peut être réalisée simplement via un ports -u && prt-get sysup.

Le noyau Linux est une exception. En effet, il n'existe pas de port pour le noyau Linux. Les sources du noyau se trouvent par défaut dans /usr/src. Par exemple, la version 3.1 de Crux fournit les sources du noyau Linux 3.12 dans /usr/src/linux-3.12.24. L'installation du noyau passe donc par un procédé standard:

$ cd /usr/src/linux-3.12.24
$ make menuconfig
$ make all
$ make modules_install
$ cp arch/x86/boot/bzImage /boot/vmlinuz
$ cp System.map /boot

Pour une mise à jour du noyau, il suffit donc de télécharger les sources depuis kernel.org, de copier le fichier de configuration du noyau et de lancer un make oldconfig suivi d'un make all && make modules_install && make install.

Étant donné que le noyau n'est pas géré par pkgadd(8), il est tout à fait possible de télécharger et installer le noyau de son choix sans rendre la base de données des paquets inconsistante. Par ailleurs, cela n'affecte pas non plus les headers kernel qui se trouvent dans /usr/include/linux et /usr/include/asm étant donné que ceux-ci ne sont pas des liens symboliques vers les sources du kernel mais contiennent une copie des headers.

Installation

Concernant l'installation, point de GUI ou de superflu. Le média d'installation est une image ISO hybride pouvant autant être gravée sur un CD-ROM qu'utilisée pour créer une clé USB amorçable. Une fois démarré sur le média d'installation, l'utilisateur se trouve connecté en tant que root et peut donc procéder à l'installation du système.

Le partitionnement se fait généralement via fdisk(8) suivit d'un mkfs(8). Une fois cela fait, il faut monter la (ou les) partition(s) nouvellement créée(s), par exemple dans /mnt et lancer la commande setup. Cette dernière permet d'installer les paquets nécessaires au système, notamment les paquets de core. Une fois cela effectué, il faut créer un chroot pour finir la configuration de son système. Cela peut se faire de manière traditionnelle mais la commande setup-chroot permet d'automatiser le processus. Une fois dans le chroot, l'utilisateur doit donc définir un mot de passe pour le super-utilisateur, éditer /etc/fstab afin de configurer les systèmes de fichiers, éditer /etc/rc.conf pour configurer le système de base tel que la timezone, le layout du clavier ou encore le hostname et les services à lancer au démarrage. La configuration du réseau passe par l'édition des fichiers /etc/rc.d/net, /etc/hosts et /etc/resolv.conf.
Une fois ceci fait, il est nécessaire de configurer et installer son kernel, tels que décrit dans la section précédente. À noter qu'un fichier .config générique est fourni de base pour simplifier le processus.
Le gestionnaire de démarrage de base par défaut est lilo. Pour autant que l'utilisateur le choisisse, il doit passer par l'édition de /etc/lilo.conf afin de rendre son système démarrable.

Changements dans la version 3.1

La toolchain utilise glibc 2.19.0, gcc 4.8.3 et binutils 2.24.

Le kernel par défaut est le kernel à support à long terme 3.12.24. À noter que depuis la disponibilité de Crux 3.1, la version 3.12.25 est disponible et une mise-à-jour du noyau est donc conseillée.

À noter également que udev a disparu au profit de eudev.

Les détails peuvent se trouver dans les notes de mise à jour ainsi que dans le changelog.

  • # Compilation du noyau sous root ?

    Posté par (page perso) . Évalué à 5. Dernière modification le 25/07/14 à 13:49.

    L’installation du noyau passe donc par un procédé standard :

    $ cd /usr/src/linux-3.12.24
    $ make menuconfig
    $ make all
    $ make modules_install
    $ cp arch/x86/boot/bzImage /boot/vmlinuz
    $ cp System.map /boot

    Tout ceci est supposé être fait en tant que root ? Alors ce n’est pas le procédé standard. Il n’y a aucune raison de configurer et compiler le noyau sous l’identité du superutilisateur, et les développeurs du noyau le déconseillent formellement.

    Extrait du README à la racine des sources du noyau :

    To do the actual install, you have to be root, but none of the normal build should require that. Don’t take the name of root in vain.

    Greg Kroah-Hartman en particulier insiste lourdement là-dessus, dans une page de « Linux Kernel in a Nutshell » que je me permets de citer largement (vu que la page en question est dans un PDF et que je ne peux donc pas y faire de lien direct) :

    Do not configure or build your kernel with superuser permissions enabled!
    […]
    Only the two or three commands it takes to install a new kernel should be done as the superuser.
    There have been bugs in the kernel build process in the past, causing some special files in the /dev directory to be deleted if the user had superuser permissions while building the Linux kernel.¹
    […]
    Do not do any kernel development under the /usr/src directory tree at all, but only in a local user directory where nothing bad can happen to the system.

    ¹ This took quite a while to fix, as none of the primary kernel developers build kernels as root, so they did not suffer from the bug. A number of weeks went by before it was finally determined that the act of building the kernel was the problem. A number of kernel developers half-jokingly suggested that the bug remain in, to help prevent anyone from building the kernel as root, but calmer heads prevailed and the bug in the build system was fixed.

    • [^] # Re: Compilation du noyau sous root ?

      Posté par (page perso) . Évalué à -1.

      Tout ceci est supposé être fait en tant que root ?

      Parce que le signe dollar apparait comme prompt ne signifie pas forcément que le compte est root même si c'est une vieille habitude.

      Il n’y a aucune raison de configurer et compiler le noyau sous l’identité du superutilisateur

      Tu as tout à fait raison là-dessus.

      vu que la page en question est dans un PDF et que je ne peux donc pas y faire de lien direct

      Je suis taquin aujourd'hui, j'en fais un.
      Tiens c'est drôle il y a le signe dollar partout. ;)

      • [^] # Re: Compilation du noyau sous root ?

        Posté par . Évalué à 9.

        Le dollar n'est pas censé signifier au contraire, que c'est un compte utilisateur et non un compte root?

      • [^] # Re: Compilation du noyau sous root ?

        Posté par (page perso) . Évalué à 10.

        Parce que le signe dollar apparait comme prompt ne signifie pas forcément que le compte est root même si c'est une vieille habitude.

        D’une part, non justement, le signe $ signifie habituellement que c’est un compte utilisateur normal, c’est # qui dénote typiquement le superutilisateur. Mais ce n’est qu’une habitude.

        D’autre part, le fait de procéder à la compilation directement dans le répertoire /usr/src/linux-3.12.24 suppose que l’utilisateur a le droit d’écrire dans cette arborescence, privilège normalement réservé au superutilisateur. Et comme il n’y a de plus aucun changement d’identité entre les commandes de configuration/compilation et les commandes d’installation, il est logique de conclure que c’est bien toute l’opération que l’on est supposé faire sous l’identité du superutilisateur, peu importe quel est le symbole du prompt.

        Tiens c'est drôle il y a le signe dollar partout. ;)

        Oui, le signe $ qui dénote typiquement un utilisateur non-privilégié.

    • [^] # Re: Compilation du noyau sous root ?

      Posté par (page perso) . Évalué à 3.

      Tout ceci est supposé être fait en tant que root ? Alors ce n’est pas le procédé standard.

      Un utilisateur responsable n'a pas de problème à faire un chown -R george:users linux-3.12.24 ou a télécharger les sources du noyau dans un endroit de son home et à ne passer en mode super utilisateur que pour la phase d'installation. Ce qui est "standard" ici c'est la procédure de configuration et compilation du noyau.

      • [^] # Re: Compilation du noyau sous root ?

        Posté par . Évalué à 3.

        Un utilisateur responsable ferra aussi un chown -R george:users /boot ?

        Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

  • # Quelques questions

    Posté par (page perso) . Évalué à 5.

    Ah très bien, je me posais justement quelques questions sur cette distrib !

    Tout d'abord, a-t-elle une bonne base utilisateurs et possède t-elle les mainteneurs capables de la développer en autarcie, hors de l'écosystème-d ?
    Je sais qu'elle existe depuis longtemps, mais ne va t-elle pas rencontrer de sérieuses difficultés quand udev sera devenu tellement indissociable de systemd que les alternatives comme mdev seront trop compliquées à maintenir ? Ce n'est pas un appel au troll, mais quand je vois les difficultés récentes de Gentoo avec eudev (http://lists.freedesktop.org/archives/systemd-devel/2014-May/019587.html), on peut se poser de sérieuses questions.

    Le système de port: ça me fait penser à Gentoo (et à FreeBSD bien sûr, mais je n'ai utilisé réellement que Gentoo) que j'ai abandonné suite à deux changements dans le même mois de la libjpeg. À peine fini la recompilation de tous les paquets dépendants de la libjpeg, j'avais dû tout reprendre. Existe t-il un moyen documenté (ou mieux, un utilitaire) pour préparer ses paquets depuis une autre plateforme, avec la bonne libc, les bonnes options de compilo et les libs dynamiques correspondant à la plate-forme cible ? En gros, cross-compiler pour la crux sur mon netbook depuis mon serveur octo-core. J'aimerais éviter de me palucher la config de distcc et ccache, et je rêve d'un truc tout prêt. Je sais bien que ce n'est pas vraiment une question spécifique à Crux, mais vu que la distrib est très concernée par les compilations, il doit bien y avoir un truc tout prêt, non ?

    La disponibilité des ports: j'ai vu qu'il n'y avait pas Blender, en allant voir ici: http://crux.nu/portdb/
    Existe t-il d'autres emplacements bien achalandés en ports ? Sinon, peut-on adapter facilement un PKGBUILD de Arch (piqué dans l'AUR) ? À première vue, je dirais bien que oui, mais il peut y avoir des pièges.

    La version 3.1 nécessite un passage par les binaires fournis. Autrement, «un cassage temporaire du système» (sic la doc) est à redouter avec des ports linkés sur des libs pas compatibles. Est-ce comme celà à chaque release de Crux ? Cela ne réduit-il pas quelque peu l'intéret du système de port ?

    En me relisant, mes questions peuvent apparaitre critiques. J'ai essayé de nuancer, car cette distrib m'intéresse réellement, mais les interrogations demeurent :)

    • [^] # Re: Quelques questions

      Posté par . Évalué à -1.

      Au niveau de Gentoo, si l'on compile sur une autre machine, on perd les quelques pourcentages d'optimisation lié à la compilation en local.

      Est ce que je me trompe?

      • [^] # Re: Quelques questions

        Posté par (page perso) . Évalué à 3.

        Est ce que je me trompe?

        Oui, on peut tout à fait compiler pour un autre processeur en mettant autre chose que native à march

        « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

    • [^] # Re: Quelques questions

      Posté par (page perso) . Évalué à 4.

      a-t-elle une bonne base utilisateurs et possède t-elle les mainteneurs capables de la développer en autarcie, hors de l'écosystème-d ?

      Cela, j'en doute. La communauté semble plutôt restreinte bien que pas non plus microscopique. Ceci dit, je pense que ce n'est pas la seule communauté qui a un intérêt hors de l'écosystème-d (je pense à Gentoo, Slackware, les distributions à destination de l'embarqué, etc.).

      Je sais qu'elle existe depuis longtemps, mais ne va t-elle pas rencontrer de sérieuses difficultés quand udev sera devenu tellement indissociable de systemd que les alternatives comme mdev seront trop compliquées à maintenir ?

      C'est une vrai question. L'avenir le dira. Pour l'instant, avec cette version, c'est eudev qui est utilisé.

      vu que la distrib est très concernée par les compilations, il doit bien y avoir un truc tout prêt, non ?

      Je ne crois pas qu'il y ait un truc "tout prêt". Après, il y a toujours moyen.

      La disponibilité des ports

      C'est un peu le point faible selon moi. Les ports sont très peu nombreux. D'un autre côté, il est extrêmement aisé de créer un port (c'est même encore plus simple qu'un PKGBUILD arch linux).
      En dehors des ports officiels (core, opt, xorg et compat-32), il y a les ports semi-officiels de contrib (ports communautaires) ainsi que tous les ports mis à disposition par les utilisateurs.

      peut-on adapter facilement un PKGBUILD de Arch (piqué dans l'AUR) ?

      Tout à fait. En général, passer d'un PKGBUILD à un Pkgfile consiste surtout à enlever le superflu du PKGBUILD. Ensuite, il y a aussi les principes de packaging propres à Crux qui veulent les "junks files" (selon la doc) ne doivent pas être inclus, etc.

      «un cassage temporaire du système» (sic la doc) est à redouter avec des ports linkés sur des libs pas compatibles.

      Il faut en général passer par la case recompilation je pense en cas de certains changements.

      Pardonne-moi de ne pas donner plus de détails mais j'ai écrit cette dépêche sur un coup de tête et n'ai en fait testé Crux que récemment. Je cherchais une distribution sans systemd à la philosophie assez proche des BSD et, étant utilisateur de longue date d'arch linux, cela m'a paru naturel de jeter un œil sur Crux.

      • [^] # Re: Quelques questions

        Posté par . Évalué à 0.

        C'était quoi le problème avec système sous arch ?

        "Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

        • [^] # Re: Quelques questions

          Posté par . Évalué à 1.

          s/système/systemd

          "Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

          • [^] # Re: Quelques questions

            Posté par (page perso) . Évalué à 3.

            Je ne vais pas nourrir le troll :)

            Je cherche simplement une distribution à la philosophie plus proche des BSD.

            • [^] # Re: Quelques questions

              Posté par . Évalué à -2.

              Bah euh c'était une vraie question. :(

              J'avais compris que c'était systemd qui t'avait poussé à changé de distrib', et j'étais curieux de savoir pourquoi.

              "Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

              • [^] # Re: Quelques questions

                Posté par (page perso) . Évalué à 9.

                Bon, alors je vais répondre franchement mais je vais tâcher de faire court ;)

                Je trouve dommage que tout le paysage des distributions Linux se tourne vers systemd. Il reste peu, aujourd'hui, de distributions qui ne l'utilise pas (ou pour lesquels ce n'est pas prévu). On perd de la diversité et du choix. Dans les faits, cela devient pénible pour une distribution de faire sans systemd de nos jours. Et je ne vais pas revenir sur les problèmes que cela pose avec udev, etc.

                Sinon, j'ai techniquement pas mal de reproches envers systemd. D'une part, il en fait beaucoup trop en tant que PID 1 (oui, je suis au courant pas tout n'est dans le PID 1, et heureusement d'ailleurs). Cela a plusieurs conséquences: une étant que, en étant complexe il y a plus de risques de plantages et en tant que PID 1 ça ne pardonne pas puisqu'il n'y a personne pour récupérer l'orphelin; une autre, le fait que certaines mises-à-jour de systemd demandent du coup un redémarrage.
                Les logs binaires, je trouve ça vraiment stupide. Oui, je sais qu'aujourd'hui on peut encore envoyer vers syslog mais… pour combien de temps encore?
                Sinon, il y a aussi tout le bloat: systemd incluant notamment, un serveur http, de quoi servir des codes QR, etc.
                Je pense que systemd fait trop de choses. Niveau sécurité, je pense que systemd est également un problème. On a déjà vu passer quelques CVE concernant systemd mais à mon avis, cette tendance ne va aller qu'à la hausse puisque, vu son importance, il est une cible de choix.

                Ceci dit, je ne pense pas que du mal de systemd. J'ai juste relevé les points que je trouve négatifs, puisque tu le demandais.

                • [^] # Re: Quelques questions

                  Posté par . Évalué à -6. Dernière modification le 28/07/14 à 22:02.

                  Je trouve dommage que tout le paysage des distributions Linux se tourne vers systemd.

                  T'as eu la même réaction quand SysV s'est imposé ?

                  Peut-être que systemd s'impose car il est bien meilleur que SysV. Par exemple, plus besoin de maintenir des scripts : on prend l'unit file upstream et c'est plié.

                  Il reste peu, aujourd'hui, de distributions qui ne l'utilise pas (ou pour lesquels ce n'est pas prévu). On perd de la diversité et du choix.

                  De la diversité pour un système d'init. Comment dire… Tout ce que je demande à un système d'init (en gros), c'est que la machine boot sans problème. Au delà, qu'il soit SysV ou systemd importe peu.

                  Et puis là c'est pas de la diversité : c'est revenir sur SysV. Si au moins c'était un init nouveau, là il y aurait une vraie diversité.

                  Et que penses-tu de Mir alors ? Tu crois que c'est une chance d'avoir autre chose que Wayland pour le futur des serveurs d'affichage ? Deux APIs, deux serveurs d'affichages concurrents, deux fois plus de bugs potentiels : youpi… ;-)

                  Je pense qu'au contraire qu'avoir systemd partout permet :
                  - d'avoir une seule API pour l'init
                  - de même pour l'usage des cgroups par l'user-space
                  - d'éviter d'écrire 1000 fois a peu près le même script d'init pour le service X (1 fois par distribution. Et encore, 1000, c'est loin du compte du nombre de distribs).

                  Dans les faits, cela devient pénible pour une distribution de faire sans systemd de nos jours.

                  Faut croire que c'est pas tellement le cas vu que Crux, Gentoo, Slackware, Ubuntu (jusqu'à la 14.04 au moins, qui a 5 ans de support), la dernière Debian stable (d'ailleurs systemd a été choisi pour d'autres raisons que sa "pénibilité" supposée : après tout les arguments autres que techniques n'avaient pas leur place dans la discussion) et d'autres font bien sans.

                  Et je ne vais pas revenir sur les problèmes que cela pose avec udev, etc.

                  Bah systemd est très dépendant d'udev, et puis bon le seul "problème" c'est de pouvoir compiler udev sans systemd.

                  Les forks c'est bien, sauf quand on s'appelle eudev et qu'on a pas parlé à l'upstream avant de forker udev en "eudev". C'est sûr que si on coopère pas, rien ne changera.

                  systemd, ses outils (dont udev) sont développés ensemble, et sont sur un VCS commun à la BSD. Mais ça ne plaît pas à BSDiste. Et ça ne plaît pas aux linuxiens. Faut croire que le problème, c'est peut-être pas systemd…

                  Pour l'etc, je ne vois pas… (je suis pas devin ;-) )

                  Sinon, j'ai techniquement pas mal de reproches envers systemd.

                  Dommage que ce soit toujours les même arguments répétés 1000 fois et réfutés 1000 fois. :/
                  Honnêtement, pour la plupart de tes griefs, je me suis renseigné 30 secondes pour savoir que c'était faux…

                  D'une part, il en fait beaucoup trop en tant que PID 1 (oui, je suis au courant pas tout n'est dans le PID 1, et heureusement d'ailleurs).

                  "Mon" /sbin/init (systemd) ne fait guère de plus que SysV, il me semble (non seulement d'après la page de man, mais en lançant /sbin/init --help on voit qu'on a pas grand chose de compliqué :

                  max-laptop% /sbin/init --help
                  systemd [OPTIONS…]

                  Starts up and maintains the system or user services.

                  -h --help Show this help
                  --test Determine startup sequence, dump it and exit
                  --dump-configuration-items Dump understood unit configuration items
                  --unit=UNIT Set default unit
                  --system Run a system instance, even if PID != 1
                  --user Run a user instance
                  --dump-core[=0|1] Dump core on crash
                  --crash-shell[=0|1] Run shell on crash
                  --confirm-spawn[=0|1] Ask for confirmation when spawning processes
                  --show-status[=0|1] Show status updates on the console during bootup
                  --log-target=TARGET Set log target (console, journal, syslog, kmsg, journal-or-kmsg, syslog-or-kmsg, null)
                  --log-level=LEVEL Set log level (debug, info, notice, warning, err, crit, alert, emerg)
                  --log-color[=0|1] Highlight important log messages
                  --log-location[=0|1] Include code location in log messages
                  --default-standard-output= Set default standard output for services
                  --default-standard-error= Set default standard error output for services

                  Ou du moins, il n'y a rien de surprenant.

                  D'ailleurs, quand j'interagis (rarement, d'ailleurs) avec systemd, j'utilise en fait /usr/bin/systemctl

                  Cela a plusieurs conséquences: une étant que, en étant complexe il y a plus de risques de plantages et en tant que PID 1 ça ne pardonne pas puisqu'il n'y a personne pour récupérer l'orphelin;

                  Euh, ce n'est pas mon impression. Extrait du man :

                  --crash-shell
                  Run shell on crash.
                  (bon sauf que j'ai pas pu crasher systemd pour tester)

                  Et puis tant qu'on parle de fiabilité : quand je m'étais planté dans mon inittab, SysV empêchait le système de démarrer. C'était tellement mieux, SysV à ce niveau ?
                  J'ai jamais eu cette impression.

                  Quant à la sécurité de SysV : euh, quelle sécurité ? La sécurité d'avoir des scripts shells exécutés par root, sans usage des control groups qui plus est ?

                  Et puis bon, face à la complexité du kernel, de Firefox, ou de Xorg, systemd (le PID 1 pas si compliqué que ça en fait…) c'est rien du tout du tout du tout. Mais le kernel et Xorg ne sont pas des cibles de choix : après tout, ce n'est pas systemd. ;-)

                  une autre, le fait que certaines mises-à-jour de systemd demandent du coup un redémarrage.

                  Euh… lesquelles ?
                  J'ai jamais été obligé de redémarrer. Et pour profiter de la nouvelle version les mises à jours du kernel ou de Xorg nécessitent elles aussi un redémarrage : rien d'anormal là dedans (oui pour Xorg on peut "juste" redémarrer Xorg : mais c'est plus rapide pour moi de redémarrer tout court…).

                  Les logs binaires, je trouve ça vraiment stupide.

                  Bah d'un point de vue sécurité, c'est les logs textuels le plus "stupide" :
                  - N'importe qui ayant accès aux logs peut les modifier et effacer ses traces (ce qui n'est pas le cas avec journald)
                  - on ne peut pas mettre un core dump ou un dump de firmware avec les logs. Oh, on peut mettre ça à côté, mais ce n'est pas dans le journal binaire, le même journal qu'on veut pouvoir être lisible avec journalctl sur un autre système et authentifier facilement.
                  - on a pas un standard de notation des dates/heures, ce qui est particulièrement énèrvant quand on a des tonnes de logs
                  - Perso, je trouve bien plus vite les erreurs avec journald qu'avec des fichiers textes (pas besoin de me souvenir comment fonctionne awk, sed, & co.). Au bout d'un moment, avoir une abstraction qui m'évite cette peine a du sens.

                  Je veux les logs produits par Firefox ? Aucun problème :

                  max-laptop% journalctl /usr/bin/firefox
                  -- Logs begin at sam. 2014-01-11 18:57:59 CET, end at lun. 2014-07-28 21:31:10 C
                  févr. 25 20:06:54 max-laptop firefox[2419]: getaddrinfo*.gaih_getanswer: got typ
                  févr. 25 20:06:54 max-laptop firefox[2419]: getaddrinfo*.gaih_getanswer: got typ
                  -- Reboot --
                  mars 31 06:45:20 max-laptop firefox[2152]: getaddrinfo*.gaih_getanswer: got type
                  mars 31 06:45:20 max-laptop firefox[2152]: getaddrinfo*.gaih_getanswer: got type
                  -- Reboot --
                  avril 07 07:27:44 max-laptop firefox[2193]: getaddrinfo*.gaih_getanswer: got typ
                  avril 07 07:27:44 max-laptop firefox[2193]: getaddrinfo*.gaih_getanswer: got typ
                  lines 1-9/9 (END)

                  Je veux les logs du boot précédent ? OK :

                  max-laptop% journalctl -k -b -1
                  -- Logs begin at sam. 2014-01-11 18:57:59 CET, end at lun. 2014-07-28 21:42:15 C
                  juin 15 07:47:32 max-laptop kernel: Initializing cgroup subsys cpuset
                  juin 15 07:47:32 max-laptop kernel: Initializing cgroup subsys cpu
                  juin 15 07:47:32 max-laptop kernel: Initializing cgroup subsys cpuacct
                  juin 15 07:47:32 max-laptop kernel: Linux version 3.14.6-1-ARCH (nobody@var-lib-
                  juin 15 07:47:32 max-laptop kernel: Command line: BOOT_IMAGE=/boot/vmlinuz-linux
                  juin 15 07:47:32 max-laptop kernel: e820: BIOS-provided physical RAM map:
                  juin 15 07:47:32 max-laptop kernel: BIOS-e820: [mem 0x0000000000000000-0x0000000
                  juin 15 07:47:32 max-laptop kernel: BIOS-e820: [mem 0x000000000009e000-0x0000000
                  juin 15 07:47:32 max-laptop kernel: BIOS-e820: [mem 0x0000000000100000-0x0000000
                  juin 15 07:47:32 max-laptop kernel: BIOS-e820: [mem 0x0000000020000000-0x0000000
                  juin 15 07:47:32 max-laptop kernel: BIOS-e820: [mem 0x0000000020200000-0x0000000
                  juin 15 07:47:32 max-laptop kernel: BIOS-e820: [mem 0x0000000040004000-0x0000000
                  juin 15 07:47:32 max-laptop kernel: BIOS-e820: [mem 0x0000000040005000-0x0000000
                  juin 15 07:47:32 max-laptop kernel: BIOS-e820: [mem 0x00000000c97a5000-0x0000000
                  juin 15 07:47:32 max-laptop kernel: BIOS-e820: [mem 0x00000000c9da6000-0x0000000
                  juin 15 07:47:32 max-laptop kernel: BIOS-e820: [mem 0x00000000c9da9000-0x0000000
                  juin 15 07:47:32 max-laptop kernel: BIOS-e820: [mem 0x00000000c9dbf000-0x0000000
                  juin 15 07:47:32 max-laptop kernel: BIOS-e820: [mem 0x00000000c9dc5000-0x0000000
                  juin 15 07:47:32 max-laptop kernel: BIOS-e820: [mem 0x00000000c9dc7000-0x0000000
                  juin 15 07:47:32 max-laptop kernel: BIOS-e820: [mem 0x00000000c9dd1000-0x0000000
                  juin 15 07:47:32 max-laptop kernel: BIOS-e820: [mem 0x00000000c9f28000-0x0000000
                  juin 15 07:47:32 max-laptop kernel: BIOS-e820: [mem 0x00000000c9f2c000-0x0000000
                  lines 1-23

                  Les exemples du manuel sont pas mal aussi.

                  Aux pros de awk/sed & co. : Bravo, mais il y a des gens qui sont de simples mortels. Désolé de vous décevoir.

                  Oui, je sais qu'aujourd'hui on peut encore envoyer vers syslog mais… pour combien de temps encore?

                  Euh, tu nous fais du FUD maintenant ?

                  Personne ne peut répondre à ce genre de questions, à part les auteurs de systemd ! D'ailleurs, tu leur a posé la question ?

                  Et à part ça, t'es au courant que c'est un logiciel libre, tout de même ?

                  Surtout qu'il te donne plus d'informations dans ton syslog que ne le fait SysV (parce que journald démarre plus tôt que ne peut le faire syslog, et que journald enregistre la sortie standard et la sortie d'erreurs de tout service système) : rien n'est caché à syslog. En rien, on ne te force d'utiliser journald.

                  Sinon, il y a aussi tout le bloat: systemd incluant notamment, un serveur http, de quoi servir des codes QR, etc.

                  C'est optionnel à la compilation, et d'ailleurs sur Archlinux ce n'est même pas compilé.

                  Le support de la génération de codes QR par journald (et non systemd) c'est environ 116 lignes.

                  Y'a pas de quoi fouetter un chat, surtout quand on sait à quoi ça sert.
                  (en gros, c'est une option pour ne pas avoir à copier des clés de vérification que l'utilisateur pourrait trouver trop longues).

                  Quant au serveur http (cela semble être systemd-journald-gatewayd) embarqué :
                  - il est embarqué (ou pas, si on le compile pas) pour éviter une dépendance
                  - sa compilation n'est pas activé par défaut
                  - son code est réduit au minimum
                  - il permet d'envoyer le journal de journald à travers le réseau. Rien de révoltant là non plus (on faisait pareil avec SysV)
                  - même s'il est compilé, il faut l'activer pour l'utiliser ou le désactiver si on en veut pas, comme n'importe quel autre service.

                  Je pense que systemd fait trop de choses.

                  Euh ouais… Tout comme le kernel monolithique linux, Xorg le très mauvais middle-man (c'est les devs Xorg qui le disent eux-mêmes !), ou Firefox si on en croit certains (c'est vrai que je largement mets moins de temps à compiler linux qu'à compiler Firefox), si on va par là…

                  Et c'est vrai que quand j'ai découvert (par exemple) que systemd s'occupait de l'ACPI, je me suis dit qu'il faisait trop de choses. Mais ça a du sens sur un système embarqué (c'est un marché ou systemd semble être utilisé)
                  Ou si on veut pas utiliser de bureau : j'imaginerais bien un système utilisateur léger avec un WM de son choix, et systemd pour l'ACPI (pas xfce4-power-manager ni rien de tout ça !). :)

                  Niveau sécurité, je pense que systemd est également un problème. On a déjà vu passer quelques CVE concernant systemd mais à mon avis, cette tendance ne va aller qu'à la hausse puisque, vu son importance, il est une cible de choix.

                  Ce qui compte, c'est pas la tellement taille du code, c'est sa qualité. Sinon, on utiliserait tous nginx au lieu d'Apache (ben oui moins de code = plus de sécurité. Autant éteindre l'ordi et le débrancher : il y aura zéro code, donc un maximum de sécurité ;-) ).

                  En parlant de qualité, avec des suites de tests et une convention de style de code assez détaillée, c'est bien plus que pas mal de projets…

                  Et j'ai du mal à imaginer qu'il n'y ait jamais eu de CVE avec SysV. Ou Xorg. Ou Linux. Ou Firefox. Ou Apache… Ou nginx.

                  Ceci dit, je ne pense pas que du mal de systemd. J'ai juste relevé les points que je trouve négatifs, puisque tu le demandais.

                  Et je t'en remercie.

                  Pour en rire : voici les six étapes de systemd (linux conf.au 2014). ;-)

                  "Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

                  • [^] # Re: Quelques questions

                    Posté par . Évalué à 6.

                    T'as eu la même réaction quand SysV s'est imposé ?

                    SysV a longtemps été certes dominant mais jamais en situation de monopole. Cf init-ng et mudur par exemple (pour ceux que j’utilisais avant la systemd-mania).

                    De la diversité pour un système d'init. Comment dire… Tout ce que je demande à un système d'init (en gros), c'est que la machine boot sans problème. Au delà, qu'il soit SysV ou systemd importe peu.

                    C’est très très réducteur comme vue. Et tu n’y crois pas d’ailleurs toi-même :

                    • de même pour l'usage des cgroups par l'user-space

                    De fait si tout ce qu’on demandait à un système d’init « c’est que la machine boot sans problèmes » pourquoi s’embêter à remplacer sysvinit ? Aux dernières nouvelles les machines bootaient sans problèmes avec sysvinint hein…

                    d'éviter d'écrire 1000 fois a peu près le même script d'init pour le service X

                    systemd changera rien à l’affaire tant que la moitié des distribs nommeront apache apache2, l’autre moitié httpd, et quelques autres apache ou httpd2

                    Et dans l’hypothèse où les distribs arrivent à se mettre d’accord pour ce genre de choses les scripts sysv sont tout aussi portables

                    • N'importe qui ayant accès aux logs peut les modifier et effacer ses traces (ce qui n'est pas le cas avec journald)
                    • on ne peut pas mettre un core dump ou un dump de firmware avec les logs. Oh, on peut mettre ça à côté, mais ce n'est pas dans le journal binaire, le même journal qu'on veut pouvoir être lisible avec journalctl sur un autre système et authentifier facilement.
                    • on a pas un standard de notation des dates/heures, ce qui est particulièrement énèrvant quand on a des tonnes de log

                    Ça c’est pas des arguments logs textuels vs logs binaires mais format standardisé vs sans format

  • # Mise en page

    Posté par (page perso) . Évalué à 6.

    Lors de la modération, la mise en page a été cassée. Il manque un backtick et un saut de ligne à la fin de l'exemple de Pkgfile.

  • # Kis vs Kiss

    Posté par . Évalué à 2.

    Il s'agit d'une distribution simple pour les geeks qui connaissent déjà bien linux ou ont eu la bonne idée de monter une LFS. Mais je ne vois nulle part une volonté KISS de ne pas rendre les choses plus compliquées que nécessaire, le dernier S de KISS signifie Stupid, pas Superuser.

    Membre de l'april, et vous ? http://www.april.org/adherer

    • [^] # Re: Kis vs Kiss

      Posté par (page perso) . Évalué à 9.

      le dernier S de KISS signifie Stupid, pas Superuser

      Le dernier S signifie bien stupide mais c'est du système qu'il s'agit, pas de l'utilisateur. Par conséquence, un système stupide a besoin d'un utilisateur moins stupide afin de marcher correctement.

  • # Chtite question aux spécialistes de Crux

    Posté par (page perso) . Évalué à 1.

    Est-ce que Crux utilise Linux-PAM ? C'est malheureusement le seul truc qui manque vraiment à Slackware, et qui fait qu'on est obligé de sauter à travers des cerceaux en feu pour configurer une authentification centralisée avec LDAP.

    Dyslexics have more fnu.

    • [^] # Re: Chtite question aux spécialistes de Crux

      Posté par (page perso) . Évalué à 3.

      Pas par défaut en tout cas. En revanche, il y a un port linux-pam ainsi que pam_ldap dans contrib ainsi que openldap dans opt. J'imagine que c'est donc possible de mettre ça en place. Le mieux reste encore de demander sur leur channel irc (#crux sur Freenode).

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.