freem a écrit 5019 commentaires

Un des avantages de dnsmasq c'est qu'il peut se contenter de faire la partie "PXE" de DHCP : sur un réseau existant (avec un DHCP déjà en place responsable de la configuration du réseau), il envoie les options PxE dès qu'un client demande une configuration IP (le client reçoit donc la configuration IP depuis le serveur DHCP principal + la configuration PxE depuis dnsmasq).

isc-dhcp-server peut étagalement le faire, mais il faut pour ça que le DHCPd principal soit configuré pour ça (next-server). Par contre, je ne sais pas s'il est possible d'identifier une requête DHCP/BOOTP pour PXE d'une requête DHCP classique?
Ceci dit, dans ma boîte, le DHCPd principal, c'est un routeur pour particulier… J'ai beau avoir retravaillé un peu le bordel ambiant, ce n'est pas simple de migrer d'un environnement sale à un propre sans interrompre le service (je suis pas le seul à bosser et le réseau est un élément important) surtout que mes connaissances sont juste celles d'un dev un peu système, pas celles d'un admin réseau.

Après, tu n'as peut-être pas envie de "polluer" ton réseau lan avec des options PXE pour des postes clients qui seraient configurés par défaut pour démarrer sur le réseau alors qu'ils ne devraient pas.

Je suis surtout méfiant envers mes capacités… je sais par expérience qu'il en faut peu pour faire basculer un truc qui marche sans qu'on sache pourquoi à un truc qui ne marche plus du tout. Je pense que je vais finir par vraiment couper le réseau en 2 réseaux physiques, et migrer progressivement les postes sur un sous réseau mieux maîtrisé…
Ceci dit, avec un DHCPd proprement configuré, j'ai cru comprendre que les requêtes PXE peuvent être transmises automatiquement à un DHCP secondaire spécialisé. On peut affecter (et c'est ce que j'ai fait, même alors qu'il est isolé) des classes d'adresses MAC (dont une partie est un identifiant de constructeur, et il y a même une partie réservée aux machines virtuelles apparemment!) à une zone dynamique (pardon pour le manque de vocabulaire technique), zones qui peuvent avoir des options différentes, notamment celle d'indiquer un fichier à télécharger.
D'un autre côté, je suppose que tant que les machines de bureau ne sont pas configurées pour démarrer en PXE, ça ne poserais même pas de problème en pratique. Jusqu'au jour ou… bien sûr.
Ce qui implique donc qu'il faille que les machines connectables (cartes réseau et PC) passent dans les mains d'un admin pour vérifier qu'il n'y a pas de problème.

C'est assez curieux comme choix de nom

Ça va, ils auraient pu faire pire, ils auraient pu l'appeller BSOD, bricolage en revanche eu été faire de la pub au logiciel qu'ils ne veulent justement pas utiliser… Je trouve ça amusant de reprocher un nom qui certes fait référence à un ancien standard (mais, standard, au moins) et de plébisciter derrière un logiciel qui lui évoque la bidouille pour gérer les parties clé d'un système.
Pour ce qui est du nom, je ne sais pas quand tu as regardé, ça a peut-être changé, mais là, sur la page d'accueil c'est écrit:

Now Devuan ASCII offers an upgrade from Devuan Jessie as well as a transition from Debian 9 (Stretch) that avoids unnecessary entanglements and ensures Init Freedom.

Devuan aliases its releases using minor planet names as codenames. Devuan file names follow this release naming scheme.

En gros, il suffit de lire 3 lignes de plus pour savoir d'où le nom vient.
Et puis, je le trouve amusant moi: il colle à leur taxonomie tout en faisant référence a l'informatique. Accessoirement, contrairement à bien des encodages, ASCII est compatible UTF-8.

Je pense qu'il y a plus a reprocher à Devuan que leur choix de noms et de ne pas utiliser systemd, mais pour ça, il faut l'essayer.

Je n'ai pas dis que c'était le mal et qu'il fallait en partir, j'ai même dit que c'est préférable à rc.d.

Je pense qu'il adresse bien une grande classe de problèmes, mais comme toutes les solutions il n'est pas parfait, alors il faut arrêter de le mettre sur un piédestal.

Quand j'ai lu "rien ne nous fera revenir en arrière" dans le contexte, j'ai compris "systemd forever", c'est du fanatisme, surtout quand celui qui me fait comprendre ça liste une série de problèmes qu'il a eus, factuellement.

Par contre, je trouve l'idée d'utiliser des outils pour allouer sur la pile une super mauvaise idée en général, et en particulier pour un logiciel qui tourne en tant que root, accessible via le réseau.

Ok, le seul vrai problème que j'ai eu c'est quand Coreos a décidé sur une release mineur de changer la config du format de stockage des logs, qui était incompatible avec ma version courante de journalbeat. De là à incriminer systemd…

Ça, c'est clairement pas imputable à systemd, je manque de mauvaise foi sur ce coup :)
On pourrait à la rigueur leur repprocher un versionning qui ne parle pas (juste un nombre entier qui s'incrémente, si je ne m'abuse), mais bon, avant de mettre à jour un élément clé, on lit les release note pour moi, donc c'est clairement pas systemd le problème ici.

Juste par curiosité: comment installer un paquet qui n'a pour seule dépendance une suggestion (pas même un recommend qui eusse été installé automatiquement…) sur le serveur TFTP à employer pourrait-il déployer la totalité de la pile nécessaire à une installation réseau?

Réponse: impossible. Du coup, ça n'adresse potentiellement que la partie installation générique d'un système composé uniquement de paquets Debian.
En bref, ça addresse la partie triviale du problème, en la rendant potentiellement plus complexe, et en impliquant qu'il faille apprendre à utiliser un outil qui ne peut servir que dans le cas d'une installation, d'un système dérivé de Debian.
C'est sûrement très bien pour les gens qui installent des postes utilisateurs de cette façon… mes systèmes n'ont pas vocation à avoir un clavier branché (sauf situation d'urgence).

Mes scripts (237 lignes de moins de 80 caractères, espacées et commentées) sont compréhensibles, débogables et correctibles sans apprentissage par n'importe qui capable de lire du bourne shell, prévus pour générer une installation de fallback (au cas ou une MàJ future pète le système, pas encore implémenté, mais ça devrait prendre moins de 10 lignes, ainsi que le temps pour vérifier que tout marche comme prévu), configurent la liaison GPRS et autres paramètres (des applications métiers notament), et choisissent runit plutôt que systemd (ce qui est peut-être un défaut, admettons), privilégient syslinux à grub2 (plus prévisible, réutilise l'outil utilisé pour le PXE de toute façon, et pas besoin d'une partition d'1M réservée pour un bootloader, sachant que syslinux n'est pas une option de D-I à ma connaissance).
Les adapter à un hypothétique autre système nécessiterait de changer à peu près 4 passages qui sont spécifiques à Debian et ses filles (en plus des listes de paquets à installer bien entendu):

• la ligne qui (de)bootstrap;
• les 8 lignes qui préconfigurent la console et le clavier (via debconf-set-selections, ça a un intérêt limité, j'aurai pu faire plus simple en faisant autrement, et avec le D-I j'aurai du les laisser de toute façon);
• la ligne qui fait dans le chroot apt-get update (pour générer la liste des paquets à installer);
• la ligne qui dans le chroot installe les paquets «utiles», que je pourrais fusionner avec deboostrap, mais j'ai séparé ça pour justement rendre le rôle de chaque script clair (il sont numérotés par ordre d'exécution, avec un nom qui indique l'étape;

Heu… tu viens de réinventer le debian installer https://www.debian.org/devel/debian-installer/.

Un collègue avait essayé plusieurs jours de faire fonctionner D-I pour ça, sans succès (pour la partie x86, faite il y a 8 mois). J'ai aussi énormément de souvenirs de lectures sur la mailing list de debian, au sujet de la comlexité de la chose.

Dans mon cas, générer une installation à partir d'un script ne m'a posé aucun problème technique: le seul truc qui m'ai posé des problèmes, c'est comprendre comment U-boot fonctionne (pour l'ARM). Trouver le point d'entrée de U-boot n'est pas simple, et l'information (présente dans la doc, pour le coup. Celle-ci y est.) ne saute pas au yeux.
Pour l'x86, si ma mémoire ne me trompe pas, j'avais réussi aisément à booter une machine virtualbox via PXE (pxelinux a une doc correcte), par contre, le fait est que la majorité des informations trouvables ne concernent que des machines avec un seul port ethernet m'a fait tomber sur le fait qu'il faut spécifier au kernel lequelle utiliser quand il y en a plusieurs. Non, la doc à ce sujet ne saute pas aux yeux (surtout quand on ne connaît pas le sujet, et que l'on n'imagine pas que ça puisse être le problème). Je mets de côté le fait d'avoir des comportements différents entre machines virtuelles, machines physiques, BIOS et UEFIs (etttt je n'ai pas touché IPv6 :)).
Et des informations qui ne sautent pas aux yeux à tête reposée sautent encore moins aux yeux quand il faut aller vite.

Moi je fais ça avec dnsmasq, tout en un, beaucoup moins prise de tête : cf. https://openwrt.org/inbox/howto/netboot par exemple.

Je regarderais.
Pour être honnête, le choix s'est fait plus ou moins par défaut: isc-dhcp est l'outil pour lequel j'ai trouvé la doc en premier, tout simplement. Il fait le boulot, la doc est exhaustive, le nom indique ce qu'il fait et il ne fait à priori qu'une seule chose (moins de risque qu'un truc que je maîtrise pas me pète au nez), je suis parti avec. Mais en effet, ce n'est peut-être pas le plus simple.

Beaucoup de NIH ici

Ne maîtrisant pas le sujet, je ne connais pas les outils habituellement utilisés. Enfin, je connaissais les termes «PXE», «DHCP», «diskless», «preseed» depuis quelques années, mais sans plus.
Dans ce genre de cas, il arrive que trouver les outils les plus simples avec une doc claire (fr ou en, peu importe) et pas obsolète soit plus long que partir sur une solution plus bas niveau mais que l'on sait comment faire (ayant déjà joué avec debootstrap et dpkg bien avant, pour installer ou réparer (à partir d')un système de secours sur une partition d'un disque booté, sans périphérique externe pour simplifier… et puis, sérieux, la tétrachiées de questions posées par le D-I pour avoir un shell de secours, c'est ridicule. Quant on veul un shell pour réparer, est-ce vraiment vital de spécifier le pays ou l'on est?).

Donc, je dirais que oui, il y a NIH pour l'installation, parce que j'ai fait un script qui en moins de 200 lignes de shell facile à déboguer installe un système propre sur une partition cible sans forcer les gens à lire un pavé de doc pour un installateur qui ne semble pas franchement conçu pour être automatisé (je suis sûr qu'en fouillant un peu, je pourrais même trouver une citation à ce sujet, sur le preseed…).
Accessoirement, intégrer les soft qu'on fait selon la rache est plus simple avec un script qu'avec un installateur qui attendra forcément des paquets, donc un reprepro et un serveur http/ftp déployé quelque part, et de préférence sécurisé (je parle ici d'un serveur créé et déployé par des étudiants non encadrés, dans l'urgence, ainsi que d'un système «embarqué» implémenté et déployé de la même manière, le tout pendant 3 ans. Le serveur est lancé manuellement, via screen, pour info.), ce qui implique l'usage de signatures électroniques (oui, j'ai regardé, c'est un truc que j'ai bien l'intention de faire, mais j'ai d'autres choses à faire avant).

Pour le boot réseau, c'est juste de la démerde, faite avec les connaissances du bord, et, oui, en l'occurrence elles étaient limitées, tout comme le temps que j'ai à disposition pour avoir un truc qui marche. C'est pour le boulot, pas un projet de stage ou de fin d'études, ni même un trip perso. Et il y a encore 20 000 trucs à automatiser.

D'un autre côté, le fait que j'aie certainement fait de mauvais choix, et le dire ici, ça permets à ceux qui connaissent les bons choix de les indiquer, ce qui m'aidera pour la prochaine fois, et peut-être d'autres. Informations qui arriveront donc parce que j'ai parlé de mon "NIH".

Je me demande d'ailleurs comment j'aurai pu faire pour avoir rapidement un truc qui marche et qui installe les applications maison (qui ne sont pas empaquetées proprement, parce que l'année 2018 à été sous le signe de l'urgence, dans une boîte qui a 0 infra, dont les seuls informaticiens avant moi étaient stagiaires ou alternants, partis depuis).
Sachant que l'installation elle-même fut la partie la plus simple.

Je te raconte même pas le jour où j'ai testé le netboot UEFI en IPv6 : je devrais écrire un journal, tiens.

Excellente idée, ça serait informatif, et ça changerait des journaux sur la politique ou pour savoir quelles blagues sont acceptables sur des projets internationaux.

tu le dis que tu ne maîtrises pas le sujet, ça en devient de la mauvaise foi!

On m'aurait menti, quand on m'a dis que la mauvaise foi consiste à ne pas admettre ses erreurs et faiblesses?

excellentes formations

Je me demande: le temps de chercher, puis de prendre une formation, et enfin d'accomplir la tâche, ça m'aurait pris combien de temps? Ah, j'ai oublié le temps de convaincre le patron…

Quant à la doc, on va faire court, j'ai pris celle qui semble être celle du site officiel. Si on prend par exemple la section sur bootp on à ceci:

=> help bootp
bootp - boot image via network using BOOTP/TFTP protocol

Usage:
bootp [loadAddress] [[hostIPaddr:]bootfilename]
=>

Superbe doc en effet.
Même sans le site officiel, taper help permets de trouver cette commande, puis help bootp d'accéder au même texte.
Problème: spécifier l'IP hôte ou le nom de fichier dans le cas que j'ai eu n'avait strictement aucun effet. J'ai aussi été lire le source, et non, je n'ai pas pris assez de temps pour tirer toute la pelote, j'ai préféré zapper et mettre en forme un dump de l'environnement, réduire le boot au strict minimum qui marche, regarder le code fournit puis l'adapter.
Ce code utilise une commande qui n'est nulle part dans la doc.

Je ne sais pas ce que valent les autres, et c'est possible que U-boot soit le meilleure. De toute façon, je n'ai pas le choix de l'utiliser, je ne suis pas assez idiot pour essayer de remplacer un élément critique d'un matériel que je ne maîtrise pas, et cela implique de ne pas non plus le remplacer par une version compilée moi-même: ce serait la meilleure façon de briquer les systèmes.

Pour le reste, tu peux me qualifier de troll si tu veux. Je me suis contenté de dire ce que j'ai fait, parce qu'il fallait que le boulot soit fait d'une manière ou d'une autre, et que c'est celle qui m'a permis d'avoir des résultats, la ou la méthode "lire la doc" ne me menait nulle part.

Bon la config réseau était visiblement beaucoup plus simple.

Je ne pense pas… elle n'est pas super complexe de mon côté (il y a juste le problème que le but soit de déployer sans connaître l'adresse MAC d'une part, et d'autre part que certaines aient plusieurs interfaces réseau), par contre, les machines sont installées pour être déployées ailleurs, parfois en connexion directe, donc j'ai vraiment besoin d'installer sur un disque. Et si possible, sans intervention manuelle autre que préciser quelques identifiants que je ne peux pas récupérer directement depuis le hardware.

Je fais juste un retour de mon (manque) d'expérience, il y a sûrement des solutions qui m'auraient fait gagner un temps important (je regarderais d'ailleurs).

Pour ce qui est de preseed, il y a 2 problèmes:

• déjà, je me souviens du nombre de questions posées à ce sujet sur la m.l. debian, quand j'y étais abonné, et des réponses: ça à l'air super compliqué, pour pas grand chose;
• c'est conçu pour fonctionner avec le CD d'installation. Il faut donc plus d'interventions manuelles que la solution que j'ai utilisée. Sans parler du fait que l'installateur Debian outre un tas de bloat inutile se base sur debconf pour preseed, et de ce que j'ai vu, c'est vraiment pénible pour pas grand chose.

rien ne nous fera revenir en arrière.

Pas même un watchdog qui fasse son job efficacement? Parce que de ce que tu dis, systemd est une vraie merde. Je cite:

j'ai eu des services recalcitrants, systemd ne m'a jamais aidé et m'a même posé problème

Pourtant systemd prétend pouvoir tout gérer.

GDM - dont le service ne porte pas le nom et ne se désactivant pas via systemctl

GDM… c'est le gestionnaire de session de gnome, non? L'un des DE qui dépendent le plus de systemd je crois?

qui timeout sans fin

Tu n'avais, j'imagine, pas accès aux TTY classiques? Il est ou le chargement à la demande? Voire en parallèle?

zero entrée dans les logs ou stdout, ni audit. C'est en repassant dans tous les fichiers de config que j'ai trouvé le problème.

Tu sembles dire que les fichiers de conf de systemd sont compliqués à comprendre, pourrais-tu détailler?

Mais journald, la gestion de dépendances tout ça ne m'a aucunement aidé. :/

C'est tout de même dommage, journald à pour seul et unique rôle de journaliser les évènements. L'échec du démarrage d'un binaire est la première chose que je loggue quand j'écrit un logiciel… un truc du style

if( -1 == foobar( ... ) )
{
//si fonction systeme
  fprintf( stderr, __FILE__ "[%d]:\t%s\n", __LINE__, strerror( errno ) );
//sinon expliciter le pre-requis qui a foire
  return false;
}

Si les types qui s'amusent à faire des allocations dynamiques en boucle sur la stack (c'est pas vraiment la 1ère faille de sécurité avec journald…) sont pas foutus d'utiliser ce genre de trucs, ça fait quand même peur, non? Je veux dire, je suis loin d'être un dev exceptionnel après tout…

Désolé pour le troll, mais je trouve ta position très amusante. Oui, systemd a de bonne idées. Surtout une: la configuration déclarative. Le reste est trop bordélique, essaie trop de faire le café, et c'est bien le reste qui fait que compte rester le plus loins possible de ce machin.

avec un intérêt relatif, vu que dans tmux ça ne marchait plus il me semble

En même temps, tmux ne gère que du texte je pense… je ne suis pas sûr, mais je pense que tmux/screen se qualifient plus d'émulateurs de terminal (embarquant un gestionnaire de fenêtre) qu'autre chose. Cela dit, ça me fait me demander s'il existe des gestionnaire de fenêtre pour le mode framebuffer? Techniquement, ça me semble pas impossible, je suppose qu'il "suffirait" d'allouer des buffer et de faire pointer les applications fb sur ces buffer plutôt que le véritable fb… par contre je pense que ça serait une belle usine à gaz :/

Cependant, ça tourne bien ici sur ARMv5 à 400 MHz et 128 Mo de RAM.

Pour être honnête, j'ai fais tourner Debian sur un vieux coucou i586 cadencé 700MHz avec moins de 100Mo de RAM sans rien recompiler, et je parle bien de stretch (l'actuelle stable).
Par contre, ce ne sont clairement pas les logiciels installés par défaut… et un des gouffres présent, c'est Xorg, dont on ne peut se débarrasser pour privilégier des applications en framebuffer, vu que sous Debian, je n'ai pas souvenir d'avoir pu faire tourner netsurf ou une application basée sur la SDL sans X: c'est cassé. Ou plutôt, il faut compiler la SDL pour inclure le support des framebuffer (j'ai du le faire au taf, j'en ai profité pour désactiver tout le bloat qu'il y a dans cette lib d'ailleurs, notamment le support foireux de DBus).

rc.d se contente de lancer les daemons dans un ordre précis, défini par le nom du fichier.
Ce qui veut dire (si je ne me trompe pas):

• pas de gestion des dépendances (par example, sur ma Debian, ssh ne vérifie pas que le réseau est accessible);
• démarrage des daemon en série, ce qui freine le démarrage du système (debian à bien un paquet starpar, mais il a beau être installé, si jamais je n'ai pas de DHCP le boot mets 3 plombes juste à cause de ça…);
• si un daemon tombe, il n'est pas relancé automatiquement;
• c'est une question de goût, mais, sérieux, 108 lignes de bourne shell pour gérer mpd (c'est un example, et je n'inclue pas les fichiers inclus)?
• double fork: les process doivent s'échapper sinon le démarrage est bloqué…

La plupart des distros ont opté pour systemd, personnellement je préfère runit (malgré que gérer les inter-dépendances soit pénible, il faut que je teste nosh pour ça).

Pour info, avec rc.d, le script Debian pour lancer isc-dhcp-server (non, ce n'est pas le pire, juste 1 au hasard):

#!/bin/sh

### BEGIN INIT INFO
# Provides:          isc-dhcp-server
# Required-Start:    $remote_fs $network $syslog
# Required-Stop:     $remote_fs $network $syslog
# Should-Start:      $local_fs slapd $named
# Should-Stop:       $local_fs slapd
# Default-Start:     2 3 4 5
# Default-Stop:      0 1 6
# Short-Description: DHCP server
# Description:       Dynamic Host Configuration Protocol Server
### END INIT INFO

PATH=/sbin:/bin:/usr/sbin:/usr/bin

test -f /usr/sbin/dhcpd || exit 0

DHCPD_DEFAULT="${DHCPD_DEFAULT:-/etc/default/isc-dhcp-server}"

# It is not safe to start if we don't have a default configuration...
if [ ! -f "$DHCPD_DEFAULT" ]; then
    echo "$DHCPD_DEFAULT does not exist! - Aborting..."
    if [ "$DHCPD_DEFAULT" = "/etc/default/isc-dhcp-server" ]; then
        echo "Run 'dpkg-reconfigure isc-dhcp-server' to fix the problem."
    fi
    exit 0
fi

. /lib/lsb/init-functions

# Read init script configuration
[ -f "$DHCPD_DEFAULT" ] && . "$DHCPD_DEFAULT"

NAME4=dhcpd
NAME6=dhcpd6

DESC4="ISC DHCPv4 server"
DESC6="ISC DHCPv6 server"

# use already specified config file or fallback to defaults
DHCPDv4_CONF=${DHCPDv4_CONF:-/etc/dhcp/dhcpd.conf}
DHCPDv6_CONF=${DHCPDv6_CONF:-/etc/dhcp/dhcpd6.conf}

# try to read pid file name from config file or fallback to defaults
if [ -z "$DHCPDv4_PID" ]; then
    DHCPDv4_PID=$(sed -n -e 's/^[ \t]*pid-file-name[ \t]*"\(.*\)"[ \t]*;.*$/\1/p' < "$DHCPDv4_CONF" 2>/dev/null | head -n 1)
fi
if [ -z "$DHCPDv6_PID" ]; then
    DHCPDv6_PID=$(sed -n -e 's/^[ \t]*dhcpv6-pid-file-name[ \t]*"\(.*\)"[ \t]*;.*$/\1/p' < "$DHCPDv6_CONF" 2>/dev/null | head -n 1)
fi
DHCPDv4_PID="${DHCPDv4_PID:-/var/run/dhcpd.pid}"
DHCPDv6_PID="${DHCPDv6_PID:-/var/run/dhcpd6.pid}"

test_config()
{
    VERSION="$1"
    CONF="$2"

    if ! /usr/sbin/dhcpd -t $VERSION -q -cf "$CONF" > /dev/null 2>&1; then
        echo "dhcpd self-test failed. Please fix $CONF."
        echo "The error was: "
        /usr/sbin/dhcpd -t $VERSION -cf "$CONF"
        exit 1
    fi
}

check_status()
{
        OPTION="$1"
        PIDFILE="$2"
        NAME="$3"

        if [ ! -r "$PIDFILE" ]; then
                test "$OPTION" != -v || echo "$NAME is not running."
        return 3
        fi

        if read pid < "$PIDFILE" && ps -p "$pid" > /dev/null 2>&1; then
        test "$OPTION" != -v || echo "$NAME is running."
        return 0
        else
        test "$OPTION" != -v || echo "$NAME is not running but $PIDFILE exists."
        return 1
        fi
}

start_daemon()
{
    VERSION="$1"
    CONF="$2"
    NAME="$3"
    PIDFILE="$4"
    DESC="$5"

    shift 5
    INTERFACES="$*"

    test_config "$VERSION" "$CONF"
    log_daemon_msg "Starting $DESC" "$NAME"

    if [ -e "$PIDFILE" ]; then
        log_failure_msg "dhcpd service already running (pid file $PIDFILE currenty exists)"
        exit 1
    fi

    touch /var/lib/dhcp/$NAME.leases

    start-stop-daemon --start --quiet --pidfile $PIDFILE \
        --exec /usr/sbin/dhcpd -- $VERSION -q -cf $CONF $INTERFACES
    sleep 2

    if check_status -q $PIDFILE $NAME; then
        log_end_msg 0
    else
        log_failure_msg "check syslog for diagnostics."
        log_end_msg 1
        exit 1
    fi
}

stop_daemon()
{
    if check_status -q $DHCPDv4_PID $NAME4; then
        log_daemon_msg "Stopping $DESC4" "$NAME4"
        start-stop-daemon --stop --quiet --pidfile $DHCPDv4_PID
        log_end_msg $?
        rm -f "$DHCPDv4_PID"
    fi

    if check_status -q $DHCPDv6_PID $NAME6; then
        log_daemon_msg "Stopping $DESC6" "$NAME6"
        start-stop-daemon --stop --quiet --pidfile $DHCPDv6_PID
        log_end_msg $?
        rm -f "$DHCPDv6_PID"
    fi
}

case "$1" in
    start)
        if test -n "$INTERFACES" -a -z "$INTERFACESv4"; then
                        echo "DHCPv4 interfaces are no longer set by the INTERFACES variable in" >&2
                        echo "/etc/default/isc-dhcp-server.  Please use INTERFACESv4 instead." >&2
                        echo "Migrating automatically for now, but this will go away in the future." >&2
                        INTERFACESv4="$INTERFACES"
        fi
        if test -n "$INTERFACESv4"; then
            echo "Launching IPv4 server only."
            start_daemon "-4" "$DHCPDv4_CONF" "$NAME4" \
                "$DHCPDv4_PID" "$DESC4" "$INTERFACESv4"
        fi
        if test -n "$INTERFACESv6"; then
            echo "Launching IPv6 server only."
            start_daemon "-6" "$DHCPDv6_CONF" "$NAME6" \
                "$DHCPDv6_PID" "$DESC6" "$INTERFACESv6"
        fi
        if test -z "$INTERFACESv4" -a -z "$INTERFACESv6"; then
            echo "Launching both IPv4 and IPv6 servers (please configure INTERFACES in /etc/default/isc-dhcp-server if you only want one or the other)."
            start_daemon "-4" "$DHCPDv4_CONF" "$NAME4" \
                "$DHCPDv4_PID" "$DESC4" ""
            start_daemon "-6" "$DHCPDv6_CONF" "$NAME6" \
                "$DHCPDv6_PID" "$DESC6" ""
        fi
        ;;
    stop)
        stop_daemon
        ;;
    restart | force-reload)
        $0 stop
        sleep 2
        $0 start
        if [ "$?" != "0" ]; then
            exit 1
        fi
        ;;
    status)
        if test -n "$INTERFACES" -a -z "$INTERFACESv4"; then
                        INTERFACESv4="$INTERFACES"
        fi
        if test -n "$INTERFACESv4"; then
            echo -n "Status of $DESC4: "
            check_status -v $DHCPDv4_PID $NAME4 || exit $?
        fi
        if test -n "$INTERFACESv6"; then
            echo -n "Status of $DESC6: "
            check_status -v $DHCPDv6_PID $NAME6 || exit $?
        fi
        ;;
    *)
        echo "Usage: $0 {start|stop|restart|force-reload|status}"
        exit 1
esac

exit 0

Le fichier run de voidlinux pour dhcpd:

#!/bin/sh
[ -r conf ] && . ./conf
mkdir -p /var/lib/dhcp/
touch /var/lib/dhcp/dhcpd.leases
exec dhcpd -f ${OPTS:=-4 -q -pf /run/dhcpd4.pid}

Merci de la correction.

Tu pourrais au moins argumenter un peu… par exemple en citant l'usage de ls dans un script shell utilisé par dpkg (/usr/share/initramfs-tools/hooks/fsck, ligne 14), ou mentionner le fait que rc.d, c'était le bordel, y'avait des dépendances dans tous les coins du disque, et qu'avec systemd, ben… la dernière fois que j'ai regardé, c'était pareil.

Maintenant, le fait est que Debian a énormément de contributeurs, ce qui augmente les chances d'avoir des «incompétents» qui contribuent, d'autant que je doute que la majorité soit payée pour faire ces contributions.
On peut aussi parler du fait que Debian est une distribution avec un nombre de logiciels franchement impressionnant, et qu'il est possible de faire sans trop d'effort le yoyo entre les versions majeures de Debian sans ré-installer from scratch, ce qui me fait plutôt penser qu'il doit y avoir une palanquée de gens compétents.

Perso, je dirais juste que Debian, à force de vouloir être universelle, n'est bonne que sur les machines avec de grosses ressources. Et il faut reconnaître qu'il y a pas besoin de sortir de Saint-Cyr pour l'administrer.

il était possible jusqu'à relativement récemment de virer systemd d'une debian

On peut toujours sur la stable actuelle.

Quid de devuan, slackware, ainsi que des xBSD ?

Y'a voidlinux aussi, qui est pas mal et qui, contrairement à devuan, ne se base pas sur rc.d (parce que le problème de base, c'est pas sysV, c'est rc.d qui fait semblant de gérer alors qu'il sert quasi à rien).

est-ce que ce renommage d'interface réseau vous a vraiment facilité la vie?

Ça dépend des cas. Le cas ou je trouve ça plus simple c'est quand un système dispose de plus d'un connecteur Ethernet: pas besoin de tester au hasard sur quel connecteur il faut brancher le câble (dans mon cas, les interfaces ne sont pas sur le même réseau physique).
Dans le cas ou il n'y a qu'une seule interface, forcément, le fait que le nom change d'un type de machine à un autre, c'est une gêne: vu qu'il n'y a qu'une seule interface, on s'en fout que le nommage soit déterminé par le branchement (bus, port, etc) et la convention (câble = eth, on part de 0) simplifie la vie.

ps:Si vous connaissez une distribution basé sur Debian et n'utilisant pas grub comme bootloader (pas de distribution live) je suis preneur !

Facile: Debian.

Bon, c'est facile à dire, mais pas évident à faire pour un débutant…
En gros, Debian offre le choix à l'installation entre plusieurs chargeurs de démarrage: grub, lilo, et rien. De ce que j'en sais, l'option d'installation lilo est complètement cassée.
En général, ce que je fais (dans le cas d'une installation neuve, et en supposant que je n'ai pas de linux déjà installé à portée de main, sinon je remplace l'installateur lent de debian par debootstrap, plus rapide, mais nécessite une meilleure connaissance du système ainsi qu'un système déjà sous linux), c'est que j'installe sans chargeur de démarrage, je redémarre l'installation mais en mode dépannage, je me chroote dans mon nouveau système, et de là j'installe et configure syslinux.

Ceci dit, même si moi non plus je n'aime pas grub2, il faut reconnaître qu'il a le mérite d'être bien intégré à Debian, ce qui permet d'éviter toute configuration de la part de l'utilisateur final. Syslinux à l'inconvénient de devoir être installé sur la même partition que celle sur laquelle se situe le noyau, ce qui rend les MàJ noyau pénible. Lilo n'avait pas cet inconvénient, mais je ne suis pas sûr qu'il supporte l'UEFI.
Autre solution: l'UEFI est capable, en théorie, de charger directement un système d'exploitation, sans passer par un bootloader. Pour ce qui est de comment faire, par contre, c'est au-delà de mes connaissances.

Pour finir, si ton PC refuse de booter sur clé ou CD, ce n'est pas lié à grub2: les CDs, notamment celui de Debian, utilisent isolinux, une «branche» de syslinux. Pour moi, le problème ne se situe donc pas au niveau de grub.

Ce serait triste que quelqu'un qui considère NodeJS comme une bonne technologie qualifie go de «seul point d'échec» quand on voit la quantité de foirages autour de node (qui viens bien entendu avec npm, médaille d'or de l'usine à gaz, qui n'est d'ai…
Je ne comprend personnellement pas pourquoi utiliser ce machin:

• c'est pénible à débugger;
• quand il faut accéder à une lib système il faut se taper une API mal documentée et instable;
• maîtriser les dépendances est une gageure;

Perso, je dois me taper un bout de NodeJS (+ electron, pour ne pas aider) au taf… enfin, je me contente d'intégrer le code au système, c'est un collègue qui doit supporter l'implémentation (pour raisons «historique» de moins d'un an)… et c'est un cauchemard. À un tel point qu'au final l'application risque fort d'être réécrite dans un autre langage cette année. Un langage avec des outils qui permettent d'analyser statiquement le code, d'exécuter pas à pas le code, et qui est capable d'utiliser les lib systèmes, c'est à dire: n'importe lequel sauf ecmascript (en pratique, ça sera sûrement C++ pour le coup, mais go ne m'aurait pas dérangé plus que ça).

De mon côté, j'ai aussi commencé à me faire une collection de liens sur les problèmes de sécurité autour de NodeJS (et son environnement, et sa communauté), pour me détendre quand je dois interagir avec ce truc. S'il y a bien une technologique que je déteste c'est bien NodeJS: je préférerais retravailler sous windows et son gestionnaire de fenêtres merdique plutôt qu'être concerné par une autre projet qui l'utilise. Je suis pas loin d'éprouver de la haine pour ce machin.

Ansible, c'est de la gestion de configuration, comme Puppet, Chef, Salt, ou CFEngine.

S'il connaît déjà perl, il sera peut-être aussi intéressé par rex, outil que j'ai choisi au taf pour 2 raisons:

• pas d'agent (comme puppet, me semble);
• dépend de perl, donc 0 dépendance sur Debian, perl étant obligatoire de toute façon, contrairement à python;

Au début je voulais utiliser cfengine (les systèmes que je veux automatiser sont des systèmes «embarqués» (dans le sens pas des masses d'espace disque, pas d'accès physique et une connexion GPRS/[1-4]G), j'essaie de réduire les dépendances, mais il est plus complexe à utiliser, tout en offrant plus de fonctionnalités. J'ai honnêtement du mal à comprendre quel binaire doit réellement fonctionner en permanence, et j'ai aussi l'impression que ça fait double-emploi avec runit (qui au vu de mon usage a un certain nombre de problèmes, il faudrait que je teste nosh, il a l'air plus efficace pour gérer les dépendances).
À bien y réfléchir, j'ai l'impression que les gestionnaires de configuration avec ou sans agent sont complémentaires: avec agent, ça permets d'avoir un système qui s'auto-répare, mais ça semble pénible d'effectuer des tâches «one-shot», contrairement aux systèmes sans agents.

Marrant, personne n'a abordé le projet XFCE, pourtant il est pas mal dans le genre: gigolo s'appelle ainsi parce que:

A: Because it mounts what it's told to

(il monte ce qu'on lui de monter)
Vu qu'il est important de faire attention aux sensibilités, je propose d'implémenter un logiciel à nommer «courtisane».

Dans mes souvenir un pauvre hello world en C++ se retrouve tout de suite avec des tonnes d'includes en cascade, dont beaucoup ne sont des bibliothèques standards fournies par le compilo (donc ne devant jamais changer en théorie…).

Pour info, il y a nettement moins de cascade d'inclusions quand on évite les lib fournies par gcc.
Pour C++:

% find /usr/include/c++/6 -type f | wc -l
722
% find /usr/include/c++/v1 -type f | wc -l   
119

Nombre de fichiers divisé par 7. Et lire le code est tout aussi intéressant, celui de clang est nettement plus lisible, notamment parce qu'il fait moins d'appels.

Pour le C (bon, ça, c'est bancal, tous les include ne sont pas dans le même dossier je pense):

% find /usr/include/x86_64-linux-gnu -type f | wc -l
310
% find /usr/include/x86_64-linux-musl -type f | wc -l 
211

À peu près 30% de fichiers en moins pour musl.

Par contre, la compilation d'un

#include <iostream>
int main(){
  std::cout << "hello world";
}

génère un binaire de 2M avec clang++ -static -stdlib=libstdc++ -pthread contre 2.4M avec clang++ -static -stdlib=libc++ -pthread (pour une raison qui m'échappe, lier avec pthread est obligatoire avec libc++…).

Pour info, l'inclusion d'un std::string pour affichage à coup de printf fait passer le binaire libstdc++ à 1.9M et celui de libc++ à 1.3M (très honnêtement, je déteste les stream du C++, je trouve ça illisible, mais je ne m'attendais pas à ça pour autant).

Pour ce qui est C, le code

#include <stdio.h>
int main(){
  printf( "hello world" );
}

génère avec gcc -static hello.c un binaire de 792K contre 29K pour musl-gcc -static hello.c.

Du coup, si vraiment les performances de compilation sont importantes, peut-être qu'avant de vouloir sortir des outils qui font le café, utiliser des libs performantes peut aider? Bon, pour être honnête, musl n'implémente pas encore, à ma connaissance, la gestion des "locales", et se limite aux standards, cette lib n'essaie pas de fournir de fonctionnalités non standard, contrairement à GCC.
J'ai utilisé pour ces «tests» les paquets fournis par debian stable.
Je n'ai pas mesuré le temps de compilation, pour un hello world ce serait difficile à mesurer de toute façon, mais je serai surpris que les libs de gcc soient les plus rapides.

Bon, faire un strip permets de grappiller quelques octets en C. Pour le C++, le résultat est nettement plus impressionnant et place le binaire de libc++ en 1ère position (1615768 octets pour libc++ contre 1619880 octets pour libstdc++, soit à peu près 1.6M pour les deux).

En même temps, les PdM de Gecko, elles sont partagées entre 2 logiciels: Firefox et Thunderbird. Firefox à au moins un fork, mais malheureusement pas empaqueté par les distros que j'utilise (ce qui pourrait être lié au fait de vouloir protéger la marque des différences d'options de compilation).
Le fait est que Mozilla à pendant un moment parlé de lâcher thunderbird, et je trouve que Firefox se dirige de plus en plus vers les «utilisateurs normaux», dès lors que l'on veut faire un truc à sa façon, il faut installer une tonne de plugins… pourtant, je ne suis pas sûr que ce soient les «utilisateurs normaux» qui lui aient permis de décoller il y a quelques années?

Je me demande aussi pourquoi les développeurs ont tendance à utiliser blink et pas gecko? Peut-être est-ce, tout simplement, plus facile?
Parce qu'à part des forks de firefox et de thunderbird, je ne connais aucun logiciel qui embarque gecko (en tout cas, factuellement, debian à des paquets libwebkit, et pas de libgecko (ni de libblink, d'ailleurs)), alors que webkit (je ne sais pas pour blink) a pas mal de projets qui ne sont pas des forks d'un logiciel qui l'embarque d'origine (on peut donc dire qu'il s'agit de choix volontaires).

Pour finir, je suis le seul à avoir l'impression qu'ils utilisent le fait que blink soit le plus populaire pour essayer de gagner des utilisateurs «gratuitement»?

« bug » / « bugs » ne sont pas traduits en « bogue » / « bogues », alors que c'est la recommandation de la page de Wiki traductions classiques de Linuxfr.org ;

Il faut reconnaître que cette traduction phonique est moche: d'un côté, celui du «bug» il y a une raison historique et répulsive (la plupart des gens n'aiment pas les cafards), de l'autre, le côté traduit, il n'y à… rien? Juste une ressemblance phonique pour dire que oui, y'a un mot français bien de chez nous?
C'est de la branlette intellectuelle, ça. Et, oui, j'aurai préféré les termes de «cafard» ou «vermine», puisque j'ai lu a plus d'un endroit le terme «déverminage» d'un logiciel qui m'a semblé bien plus approprié que celui de «bogue», qui dans mon esprit est l'enveloppe de la châtaigne ou du marron… si un arbre pousse dans un ordinateur, on devrait plutôt parler de green IT, non?

Pour le reste de ta tirade, je suis d'accord. Le texte qui doit être préservé hors traduction devrait être signalé par un balisage, et je te remercie d'avoir contribué à améliorer les choses, même si certains points n'ont pas été adoptés.
Notes cependant que je ne suis pas d'accord avec toi sur au moins l'un d'eux :)

jusqu'à oublier le rituel « Merci, corrigé ».

Pour ta note négative, tu sais, je pense que ton historique doit vachement jouer. On dirait que tes comportements passés (que je n'ai pas connus, mais… j'ai l'impression que tu es dans les fortunes de debian? T'es une star, si ça se trouve) on développé des réflexes pavloviens chez certains.
Malgré ça, moi j'apprécie le fait que tu continues de donner ton point de vue malgré l'opprobe (firefox me mets le doute sur l'orthographe…), et sans attaquer en plus.

Ce n'est pas le 1er bugtracker intégré au DVCS sur lequel je tombe, parce que, j'en cherche un depuis longtemps (sans trop me forcer quand même), qui me convienne (mais je suis un grand chieur, donc…).
Je m'aperçois que la plupart se concentrent sur le fait d'isoler la gestion des bugs sur une branche différente, et je me demande pourquoi.

Après tout, un bug peut n'être lié qu'à une branche précise, et tant qu'il n'est pas résolu, il devrait parfois pouvoir bloquer la fusion.
Donc, pourquoi ne pas juste créer une arborescence, avec quelques éventuels scripts (inclus via peu importe quel moyen), pour ça?

C'est justement un des trucs qui font que je trouve fossil pas si intéressant que ça, en plus du fait de nécessiter un outillage binaire spécial rien que pour ça.

De plus impossible de voir le résultat à l'écran (par exemple je ne verrai pas mon "ls -l").

Heu, donc, qu'est-ce qui empêche d'utiliser une redirection vers un fichier? Ou, au pire, d'utiliser le -t de ssh?

(pour diverses raisons)

On dirait que t'es à l'école, la…

À moins que ta boîte ne te laisse même pas installer un outil en mode utilisateur, mais ça reviens à t'empêcher d'écrire sur ton disque. Si c'est le cas, sérieux, changes de boîte. Sauf si tu es masochiste.

Je n'ai pas non plus d'accès direct aux différents serveurs, le serveur maître est un Bastion.

Rex (comme Ansible, probablement) sont utilisable sans installation sur les serveurs proxy ou les cibles, c'est justement leur force: ils sont «agentless», sans agent.
Il suffit de les installer sur le poste de l'opérateur… et de savoir configurer correctement SSH.

Moi j'ai accès aux miens, mais mon but est à terme d'empêcher tous les développeurs irresponsables (genre, ceux dont le pass user est " ", idem pour le root, non, je ne plaisante pas, sachant qu'il est possible d'accéder au LAN par wifi et que la machine en question n'est jamais éteinte…) de ma boîte d'y avoir accès, tout en pouvant intervenir dessus malgré tout (faudrait aussi que je bride un peu plus le sudo…).

Toutefois, je dois rester dans les clous et me contenter de faire du "scripting"

Accessoirement, le perl, c'est du script. Vraiment. Perl à été créé pour justement remplacer sh+sed+grep+awk+whatever, avec le gain de performances que l'on peut attendre d'un moins grand nombre de fork/exec. Pour faire simple, je dirais que sh, c'est le mode interactif du script système (beaucoup de texte), quand la perf on s'en balance. Le perl, c'est quand on fait du script système, mais qu'on fait souvent la tâche, et qu'aller vite est utile. La syntaxe est aussi plus lisible qu'un mélange des outils sus-cités.

Python est aussi un langage de script, mais il est généraliste.
Pour finir, Rex fournit en pratique un DSL de type déclaratif, basé sur perl.