freem a écrit 5059 commentaires

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.

ls -l c'est juste une commande au hasard pour vérifier la faisabilité.

Bon… j'ai voulu mitiger ma pensée en lisant le sudo su, notamment parce que je reconnais l'avoir commis. Mais le ls dans un script, c'est le pire exemple de hasard… S'il vous plaît les gens, gardez à l'esprit que des enfants peuvent lire ces obscénités et les reproduire, ce qui peut faire subir à des gens bien éduqués la maintenance de ce genre de trucs!
Plutôt que ls, dans un script, utilisez donc find ou (inclusif) stat, il me semble qu'ils sont moins sujets à changement et plus aisés à parser! Sans parler, pour find de la possibilité de changer aisément la profondeur de recherche.

Adl?

Pour ma part, je ne dis pas qu'il faut garder le système d'init sysV

Attention, on confond souvent sysVinit et rc.d. La vraie calamité, dans l'histoire, c'est rc.d, pas sysVinit, même si je trouve quand même que sysVinit en fait trop, notamment les runlevels, qui ne servent en pratique pas à grand chose à mon avis.

Cela dit, vu que sysVinit dispose de fonctionnalités inutiles, je suis également en faveur de le virer.
De mon côté, je cherche des solutions entre-deux.
J'ai adopté runit, mais je tombe au boulot dans certaines de ses limites (quand le fichier run est en exécution, le service est considéré up, alors que si ça se trouve, on essaie juste de vérifier les préconditions… ça se règlerait avec un bête signal à runsv, mais non. De plus, il faut parser la sortie de sv pour savoir si un service devrait tourner… c'est dommage) et je suis tombé récemment sur un outil nommé nosh, qui prétend résoudre certains de ces problèmes.
Accessoirement, nosh prétend être capable de convertir les units de systemd, et implémenter un DSL. Ce sont à la fois les points qui m'intéressent, et qui me font peur: j'ai été énormément déçu par systemd (oui, j'ai cru un jour que ce projet serait capable de faire juste ce qu'on lui demande: gérer les services, mais il continue de grossir et entraîne occasionnellement des failles de sécurité, je ne peux accepter ça d'un PID1) et uselessd à abandonné le suivi justement à cause de ce chaos.
D'un autre côté, pouvoir récupérer les config du PID1 à la mode, proposer un DSL qui évite les forks inutiles (bon, ok, il reste à prouver que les autres imposent l'usage de /bin/sh…) liés au shell scripting, et qui ne lance un service que si les préconditions sont remplies, c'est séduisant…

Je suis désolé, mais je n'ai pas compris l'usage de ce logiciel et, malgré tout, j'ai l'impression qu'il pourrait me permettre de résoudre un de mes problèmes au taf: gérer facilement les comptes utilisateurs.
Bon, je sais que c'est plus ou moins l'utilité de LDAP (je n'ai eu il y a quelques années qu'une formation sur AD, qui semble être une surcouche de LDAP, et je n'ai jamais eu l'occasion de manipuler du vrai LDAP) et justement, c'est là ou je ne comprend pas.

Ce logiciel ajoute quoi à LDAP? Une interface facile à utiliser (facile restant à définir, la ligne de commande ne me fais que rarement peur)? Une possibilité de versionner facilement la config (j'ai cru lire qu'il est maintenant plus facile de faire un diff… pourquoi maintenant, et pas avant?)?

Pourquoi utiliser "sudo su"? Ça me semble moyennement pertinent, non? Juste un sudo devrait faire le taf?

Sinon, compte tenu des contraintes de l'OP, à savoir pas d'installation possible sur les machines distantes, je conseillerais l'usage d'un outil de déploiement sans agent (agentless).
J'ai déjà utilisé un peu Rex, mais pas Ansible qui est plus connu:
* Rex, nécessite perl et un serveur ssh sur la cible;
* ansible, nécessite python et un serveur ssh sur la cible;

J'ai opté pour Rex, parce que mes cibles sont sous Debian (perl obligatoire) et je voulais réduire au maximum le nombre de dépendances. Ansible étant plus connu, il est probablement plus simple de trouver de l'aide.
Pour l'usage que j'ai eu, j'ai trouvé Rex assez facile à utiliser cela dit (même si je n'ai pas eu vraiment le temps de l'apprivoiser complètement).
C'est plutôt pratique: on peut configurer des tâches, des cibles, et des groupes de cibles. À partir de là, il est possible d'invoquer facilement une ou plusieurs tâches spécifiques sur un nombre variables de groupes ou de cibles, y compris en parallèle.

Pour régler le problème des machines accessibles uniquement par une «machine proxy», il est possible d'utiliser les rebonds ou les «proxycommand» ssh, par exemple avec une configuration ssh dans ce goût là:

Host mon_proxy
    User proxy_user
    Hostname proxy.example.com

Host ma_cible_1
    User cible_1_user
    Hostname cible_1
    ProxyCommand ssh -C mon_proxy /bin/nc -U %h

Juste un commentaire sur l'extrait plus haut: mes cibles à moi, elles sont derrière des liens GPRS, du coup pas d'accès direct.
Les cibles établissent donc un tunnel inversé, non pas vers un port de la machine distante, mais vers un fichier de socket UNIX dont le nom dépend de la cible: ça facilite l'allocation de l'identifiant, vu que ce fichier est généré en fonction de l'identifiant de la cible. Et puis, pas besoin de se souvenir si ma_cible_1 utilise le port 2222 ou 2223: il suffit de lister les fichiers.
Ça implique le netcat d'openBSD, mais s'il n'est pas disponible, on peut utiliser des trucs plus standard, c'est juste plus chiant. Pour le coup, j'ai l'avantage d'avoir les accès root sur tous mes systèmes :°

Sérieux, une disquette pour « enregistrer » ? Ceux qui ont moins de 20 ans n’en ont jamais utilisé de leur vie.

Cool.
Donc, on remplace par quoi? Les «d'jeuns» n'ont jamais vu de périphériques de mémoire morte, sauf les clés usb, qui ont la même forme que les dongles pour claviers sans fil, notamment.
Alors, on fait quoi, on mets une icône de périphérique USB pour tout, histoire que, tous, y compris les vieillards de 30 ans soient perdus?

Ça fait quoi, qu'un symbole soit utilisé pour des raisons historiques et que l'on n'en connaisse plus le sens? Moi, perso, le symbole du crâne humain, je n'en connais pas le sens originel, mais je l'associe sans problème à une idée. Même chose pour bien d'autres symboles.
L'intérêt des symboles qui restent les mêmes au court du temps, c'est bien justement de ne plus nécessiter l'adaptation aux modes et évolutions pour une fonctionnalités… remplacer un symbole, pourquoi pas, mais seulement si au moins la majorité de la population ne le connaît pas, et, ici, la disquette, c'est juste les moins de 20 ans (selon toi) qui ne connaissent pas.
Si on se base sur une espérance de vie moyenne de 60 ans, c'est 2/3 tiers de la population qui s'y sont habitués (je fais comme toi, je prend des chiffres sans source, notamment sur l'espérance de vie).

Bref en terme de design il faut toujours se remettre en cause, s’adapter au monde mais pas n’importe comment.

Se remettre en cause, ça n'implique pas de considérer que tout ce qui est, est mauvais et moins bien que ce que l'on imagine. Remettre en cause, c'est bien, casser les codes et les trucs qui s'implantent peu à peu, c'est pas si souvent bien.

Alors autant il a raison sur le point que je n'ai pas écouté, pour diverses raisons:

• j'étais au taf à ce moment la;
• mes machines perso m'ont lâché (physiquement, en série… oui, j'étais la cible de Murphy);
• j'ai déjà vu ce genre de sujets passer, j'ai plus répondu à ces sujets qu'à l'article lui-même, je l'admets;

Par contre, me reprocher de sortir des poncifs quand le point d'accroche lui-même en est un (pour info, je viens de vérifier sur un dico, le terme "poncif" inclue "idée reçue", le titre de l'article lui-même est donc un poncif) me semble mesquin, surtout sans argument.
Perso, j'ai réagit d'une part au texte du journal, sans pouvoir accéder au contenu vidéo (déjà, un contenu vidéo, c'est beaucoup de vide et de faux semblants, comparé à un contenu texte), mais aussi aux commentaires (à ce journal) qui disaient à ce moment que dans le libre tout est moche, sous entendu: c'est mieux dans le fermé. Et, oui, j'ai perdu mon calme. Mais au moins, j'ai essayé d'argumenter.
Toi, en revanche, tu te contentes d'enfoncer quelqu'un sans la moindre tentative de développement.

Si l'usage de partoches réseau en état et de partoches locales en vrac t'es habituel, ma foi, je pense que tu ferais bien mieux d'utiliser un PXE….

Mais c'est bien d'avoir des couches. Le but de ces couches est de mutualiser le travail, ne pas réinventer la roue, avoir des composants plus solides.

J'ai moinssé pour cette phrase précise, alors que je ne comptais pas intervenir dans un thread mort… mais la, non.
Dans le cas de systemd, ça reste discutable, honnêtement. Moi, je n'apprécie pas, avec probablement de mauvaises raisons, éventuellement de bonnes: par exemple, je pense qu'un PID 1 ne devrais que se contenter d'initialiser le système, et lancer un superviseur pour les logiciels qui ont besoin de l'être. J'ai l'impression, du haut de mon manque d'éducation, que systemd utilise le même processus, et donc le même fichier de code source, pour initialiser le système ET superviser les daemons.
Sur ce point, je trouve sysVinit mieux foutu dans le sens ou sysVinit ne supervise (sisi, il supervise un peu, prenez une distro avec lui, et mettez /bin/false à la place de /sbin/getty dans l'inittab…) que des outils peu intelligents: basiquement, il ne supervise que agetty sur une Debian. Il me semble donc plutôt capable de superviser un superviseur plus puissant, qui ne lance les services qu'à la demande et/ou que après que les pré-conditions soient remplies.
Le problème est qu'il n'offre aucun outil qui permette de le faire, et donc, chaque distro s'étant basé sur sysVinit, à bricolé son gestionnaire de daemons, à grand coups de bourne scripts plus ou moins bien ficelés… et le résultat est ingérable pour Debian (mon opinion).
Donc, dans le cas de systemd, je peux accepter cette phrase.

La raison pour laquelle j'ai moinssé, j'ai parce que, au taf, j'ai été confronté à npm. Hors, des… gens… probablement très intelligents… hum… oui, ça doit être ça… fournissent un module pour tester si un nombre est négatif. Ce module, s'appuie sur un module qui teste si un nombre est positif, et en inverse juste le résultat.
Penses-tu vraiment que c'est toujours bien d'avoir des couches? Ne penses-tu pas que le fait d'ajouter, et d'utiliser, une couche doit être réfléchi en fonction du cas d'usage?

L'exemple que j'ai pris est, franchement, extrêmement stupide (mais tristement réel), contrairement à systemd. Mais dans le cas de systemd, je pense que dans certains cas il ne se justifie pas, par exemple est-il utile d'avoir la complexité de systemd qui dépends de dbus et d'une implémentation maison de cron dans un système embarqué, ou la taille des binaires compte?
Dans cet exemple, je crois qu'il n'est pas bon d'avoir des couches, car ça complexifie le débogage (il faut déboguer toutes les couches alors que potentiellement juste attaquer le matos peut être plus simple) et à un coût non négligeable en bande passante réseau (corriger les failles de sécu sans trop impacter le forfait pas cher est parfois un voeu du chef).

Et bizarrement, il n'y a pas grand monde pour se bouger à maintenir les scripts init à l'ancienne, preuve que pas grande monde trouvait SysV si bien que cela à maintenir et à l'usage…

Je connais par l'usage au moins 2 distributions non basées sur systemd. L'une est voidlinux, basée sur runit, l'autre est devuan, et j'ai cru voir un article sur lwn disant que, justement, les tensions se calmeraient pour garder en vie le vieux sysV. Si ça se fait, compte tenu que devuan (que peu ici imaginaient faire le boulot nécessaire pour réussir à publier une version stable) compte passer à openrc (de ce que j'ai compris sur irc, hein), j'imagine qu'il n'est pas impossible qu'un jour, sysV soit lâché, mais d'avoir une alternative à systemd.

Je pense que la réalité est plus complexe que ce que ne veulent faire avaler les gens qui soutiennent absolument systemd. L'inverse est malheureusement vrai aussi.