freem a écrit 5019 commentaires

TL;DR:

Debian a toujours très bien marché sans systemd, et pour éviter toutes traces de ce machin, le plus simple c'est (c)debootstrap.
Il ne faut pas chercher un système «KISS» quand on utilise des outils (DE, gestionnaire réseau) qui ne le sont pas (KDE, Gnome, NetworkManager, etc).
Devuan n'apporte en pratique que des régressions.

Plus en détails:

Pour info, je n'installe plus Debian par l'installateur depuis… disons quelques mois (peut-être même plus de 24?).

À la place, je fais du (c)debootstrap, ça me permets d'éviter l'installation par défaut de systemd (parce que j'aime pas, pour des raisons diverses et variées, certaines pragmatiques, d'autres plus «politiques»), ce qui est plus propre et respectueux envers «la nature» (surtout envers ma bande passante et mon temps en vrai, ça m'évite un reboot et autres bricolages à la con) que d'installer puis supprimer ce dernier.

J'ai aussi toujours évité autant que possible les trucs foireux genre networkmanager, y préférant à l'origine /etc/network/interfaces et maintenant que mes systèmes tournent avec runit (je note que ce système n'utilise d'ailleurs pas runit-init, va falloir que je corrige ça!), un service par IFACE, bien souvent qui fait tourner un bête busybox udhcpcd. Bon, par encore testé le WiFi, mais ça me fait pas plus peur que ça, suffit de lancer un wpasupplicant avant. Déjà fait sans runit, ça marche nickel.

Le seul cas dans lequel j'ai eu à installer un gestionnaire réseau, c'est pour le WiFi dans les hôtels, parce qu'ironiquement, je ne sais pas configurer le WiFi pour du WEP et leurs espèces de portails. Y'a probablement d'autres cas que je sais pas gérer, mais bon… le problème n'est pas l'outil ici, c'est moi, l'admin.

Par contre, point notable, je n'utilise pas de bureau monolithique. Du coup, à la question:

Il est où le KISS ?

Je répondrais qu'il est inutile de chercher du KISS (en plus je déteste cet acronyme, il est débile, je préfère MISS moi: Make It Simple Smart, parce que quand on fait simple en programmation, c'est pas stupide, et du code stupide ça finit invariablement en usine à gaz, surtout quand on essaie de le garder) quand on utilise Gnome, KDE, ou autre usine à gaz.
Un système simple, c'est un ensemble, on ne peux pas demander d'avoir un environnement logiciel qui fait son boulot, le café, et torche le petit sans qu'on lève un doigt et obtenir un système simple.
De mon point de vue, un système simple, ça force l'administrateur à maîtriser son système sans passer par des outils automatiques.
Typiquement, l'installation d'arch ou de voidlinux, c'est assez «KISS», là ou l'installateur de Debian est un truc automatique clés en main et, some toute, complexe (et qui pose 100 mille questions chiantes quand on veut juste un démarrage de secours, en plus, super pénible!).

Niveau réseau, le plus gros changement que j'ai vu depuis l'arrivée de systemd, c'est le renommage des iface. À vue de nez, sur des install clean, ça marche pas trop mal (en tout cas, j'ai eu aucun souci sur plusieurs centaines d'installations sur des beaglebone black et des mano842, systèmes auxquels je peux ajouter un serveur et quelques tours de diverses marques) par contre sur ma carte mère perso:

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: enp2s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DEFAULT group default qlen 1000
    link/ether 70:85:c2:a6:0e:38 brd ff:ff:ff:ff:ff:ff
3: eno1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000
    link/ether 70:85:c2:a6:0e:36 brd ff:ff:ff:ff:ff:ff
4: wlp3s0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000
    link/ether 3c:6a:a7:b5:a2:c5 brd ff:ff:ff:ff:ff:ff

On repassera pour le nommage cohérent… C'est peut-être dû au hard, peut-être à des traces de config du système, vu qu'il me semble que cette install est partie d'une Debian probablement stretch à Devuan à une autre version de Devuan à Debian stretch puis à Debian buster… faudrait que je tente une réinstall clean pour être sûr (sans parler du fait que c'est la 2nde carte mère sur laquelle cette install tourne et que la Debian précédente ne détectais pas tout le hard).
Je pourrais juste demander au système de pas effectuer le renommage, ça se fait facilement, juste une option a ajouter au boot.
Ou alors que j'acquière une meilleure maîtrise de comment marche udev, mais j'avoue avoir la flemme, ce machin me semble particulièrement compliqué pour un usage qui me semble, somme toute, pas si utile que ça: à part des clés USB mon hardware ne change que très rarement après tout (les gens normaux ajoutent probablement leurs débilophones et appareils photo à la liste, certes, mais bon, ça reste sur l'USB au final).

De mon côté, Devuan, j'ai essayé aussi. Plus d'un an.

De mon point de vue, ça n'apporte rien, et ça casse même certaines fonctionnalités, notamment le fait que les paquets n'ont plus de description!
C'est extrêmement pénible pour moi. Debootstrap et consort qui pètent, ça aussi c'est pénible. J'ai probablement eu d'autres petites merdes à gauche et a droite, mais ça devais pas être bloquant, sinon je serais capable de les lister :)

Et avec l'arrivée de runit-init qui est l'une des dépendances possibles du paquet init dans Buster, c'est encore moins pertinent (oui, c'est stupide de vouloir rester avec rc.d et ses scripts bloatés qui font même pas le minimum syndical malgré plusieurs milliers de lignes de shell exécutées à chaque action).
Bon, certes, quand on lis /etc/runit/2, on sent que c'est aussi bien intégré que l'étais systemd quand il est apparu dans Debian: très mal, on lance en gros juste les trucs que rc.d lance. Mais bon, le pied est dans la porte.

Après, une fois encore, je n'utilise pas de bureau bloaté, du coup j'ai pas la dépendance à logind qui est le principal problème pour les DE de ce que je comprend de mes diverses lectures sur la toile. Je note quand même la présence d'elogind dans le dépôt Debian.

Pour finir ce pavé: peut-être bien que l'arrivée d'elogind et de runit-init sont indirectement liés à la naissance de Devuan, qui sait?
Perso, je pense plutôt que c'est l'oeuvre de gens qui n'apprécient pas systemd mais qui sont restés dans Debian malgré tout, Devuan semblant plutôt partir sur d'abord un retour a sysVinit+rc.d pour ensuite migrer vers openrc, ce qui me semble contre-productif (revenir en arrière pour avancer ensuite? Pourquoi ne pas juste avancer, ça casserais la vision de «gens qui veulent juste garder /etc/init.d et ses scripts foireux»).

Bon, après, si t'as un retour d'expérience sur Devuan ou il y a des améliorations réelles comparé à Debian, je suis intéressé, même si je sais que le sujet est un appeau à trolls et à moinssages.

autant réseau je suis moins sûr.

ip -s link donne, par exemple:

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    RX: bytes  packets  errors  dropped overrun mcast   
    16410506   152826   0       0       0       0       
    TX: bytes  packets  errors  dropped carrier collsns 
    16410506   152826   0       0       0       0       
2: enp3s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP mode DEFAULT group default qlen 1000
    link/ether d8:cb:8a:e9:03:05 brd ff:ff:ff:ff:ff:ff
    RX: bytes  packets  errors  dropped overrun mcast   
    422738017  454508   0       0       0       23208   
    TX: bytes  packets  errors  dropped carrier collsns 
    17412954   242196   0       0       0       0       
3: enp4s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP mode DEFAULT group default qlen 1000
    link/ether 18:d6:c7:01:8d:a4 brd ff:ff:ff:ff:ff:ff
    RX: bytes  packets  errors  dropped overrun mcast   
    0          0        0       0       0       0       
    TX: bytes  packets  errors  dropped carrier collsns 
    136932     732      0       0       0       0       

On peut y mettre d'autres options, dont un formatage en json soit-disant plus facile à parser. Dans mon cas j'avais utilisé ip -s l | sed 's! *! !g' | awk '...' pour parser, ça se fait bien.
Bon, évidemment, ça donne des stats sur l'instant t, pour y voir un intérêt, il faut prendre des mesures régulièrement, timestamp inclus, et comparer un certain nombre d'enregistrements.
Par contre, je sais pas si on peut choper le débit maximal d'une interface réseau…

mais j'en vois pas dans l'autre sens (je parle bien de vexer les caucasiens hétérosexuels).

Gigolo? Ce nom est choisit parce que:

About the name

Let me quote Olivier Fourdan about the name 'Gigolo':

<ofourdan> Q: Why is it called “gigolo”

<ofourdan> A: Because it mounts what it's told to

Du coup, on a ici clairement l'objetisation de l'homme, mais c'est moins à la mode que de critiquer l'autre côté.

Me reste à rappeler que «boob» dans ma langue et dans bien d'autres, ça veux rien dire.

Que le lien soit en anglais, ok. Mais que le le titre le soit aussi, franchement, je trouve que c'est même pas du partage, sur un site francophone.

j'ai voulu utiliser les tildes pour barrer un texte dans le titre mais ça a pas marché…

Je sais, je dois ouvrir une feature request, vous me laissez jusqu'a demain pour le faire?

Heu, t'es en train de me dire que l'on peut debootstrap sur un dossier inexistant?

À vrai dire, c'est un tout petit prototype et je n'ai pas le temps d'améliorer

Je comprend.

packager pour Debian

Si c'est faire un vrai paquet source, je peux pas t'aider, mais faire un paquet binaire, c'est assez simple. Ça implique qu'on ait confiance en toi, certes, mais ça sera de toute façon le cas.
Pour moi, la bureaucratie debian, elle n'a de sens que pour faire des deb intégrés au dépôt central, avec un haut degré de qualité.
Du coup, je pense que, pour juste partager un repo a toi qui sera ajouté dans les sources, pas besoin de te prendre trop la tête, suffit de créer un dossier pour le projet foobar foobar/DEBIAN avec divers fichiers, genre control (obligatoire), sha512sum (de mémoire, et pas obligatoire) et autres du même genre.

Si tu veux plus d'infos pour faire un truc qui soit installable par dpkg, je peux t'aider, voire contribuer.

(pour les utilisateurs) permettre de traduire les messages automatiquement

J'avoue n'avoir aucune idée de comment traduire les messages de scripts… en C, je sais faire, mais en sh? Ceci est un appel à bonne âme: un journal sur comment traduire du script serait plussé par au moins moi :)

(pour les administrateurs) utiliser une solution plus générique pour la configuration de l'initrd (dracut, clevis ou systemd-*). Chacune de ces solutions aboutit à une proposition d'architecture assez différente.

Je suis vexé.
Vraiment.
Parce que, hé, debian 10 intègre runit-init dans les variantes de init (même si c'est pas mon fait, mais j'espère rendre mes scripts assez solides pour les contribuer).
Blague à part, systemd impacte vraiment l'initrd? Pour dracut, il me semblait que c'est juste un système de de build, une sorte d'autotools spécialisé, et clevis, je connais pas.
Mais, parles-moi un peu plus de tout ça, je souhaite aider a avoir un système debian portable et potentiellement maintenable par un nombre réduit de personnes, et je pense que runit correspond a ma façon de penser, malgré ses défauts (il faudrait que j'étudie nosh, en vrai).

J'essaies de monter en compétence petit à petit, et je pense que je n'ai pas encore assez de compréhension du fonctionnement interne de LVM pour l'utiliser.
Je ne sais pas pourquoi, il me faut une compréhension relativement bas niveau d'un système pour l'appréhender, et j'ai pas encore étudié LVM.
Ce que j'en comprend, de très loin, c'est que c'est une sorte de méta-format de disque, une sur-couche à GPT/DOS/whatever, qui, j'imagine, considère le disque entier comme un FS, et chaque partition comme un fichier? Enfin, c'est un raccourcis très gros…

Bref, du peu de compréhension que je suppose avoir, je n'aime pas trop l'idée de LVM, sans trop pouvoir expliquer pourquoi. C'est purement subjectif je pense, et se combine au fait que je vois peu d'intérêts objectifs à un truc qui correspond à l'image décrite plus tôt (qui est fausse, j'en suis persuadé).

Mais, si quelqu'un fait de la vulga sur LVM, je serais très curieux de lire ça, et je poserais surement un tas de questions bêtes!

C'est ce que j'ai fait, non?

J'avoue, les notations étaient en Mo à l'époque, et je serais incapable de dire s'il s'agit de Méga au sens USI, ou au sens informaticien. J'ai préféré supposer le sens informatien et supposer Mio, donc, qui ne laisse pas de flou sur ce que j'ai voulu dire. Je reste un optimiste après tout (même si le temps me rends puissamment cynique).

Mois, soit je moule, sois je seiche.

Désolé, j'ai pas pu résister avec ça:

Je m'en remets donc à vos coquilles

Ce message est totalement impertinent, pour le coup, je vais encore me faire pourrir le karma :D (mais ça me fait rire)

Ce qu'il faudrait faire pour le rPI aussi, non? Sans relais, je ne vois pas comment faire un poff/pon d'une machine sans accès root a celle-ci. Mais peut-être qu'il peut se logger dessus, par exemple via telnet?

D'ailleurs, je suis en train de me dire, il y a déjà une machine sur le switch, donc pourquoi ajouter un système tiers?
Pour les GPIO?
Certaines cartes mères en ont aussi (même si je ne sais pas comment y accéder dans le cas que j'ai en tête: mano842), ou il peut être possible d'en ajouter (je viens de trouver ça, le sujet m'intrigue).

En bonus, ça permettrais un reboot de la machine elle-même si watchdog cesse d'émettre?

Désolé, plus de questions que de réponses réelles du coup :)

Hon, donc, en (très) gros:

dd if=/dev/zero of=/tmp/target count=10240 #par exemple
mkfs.ext4 /tmp/target
mount /tmp/target /mnt
debootstrap --variant=minbase buster /mnt
tar -czf /mnt /tmp/result.tar.gz

ça ferais un truc utilisable par docker? (inutile, certes, mais c'est une base…)

n espece de watchdog avec un rpi par exemple

Pourquoi utiliser un PC complet pour faire watchdog? T'as moyen d'envoyer un signal régulièrement dans, par exemple, un relais temporisé?

En tout cas tu écris des super journaux, tout mon respect

Je fais ce que je peux, mais merci.

C'est chiant ce système de +/- , mais bon on peut pas basher les traits d'humour!

Je pense que la plupart des gens ici ignorent en grande partie le score d'un post (sauf certains scores extrêmes, je dirais, même si je les lis quand même par curiosité perso), donc c'est pas très important.

En tout cas, j'ai toujours vu/lu que testing était à éviter (exception faite comme dit plus haut par les mainteneurs de paquets).

Bof, j'ai utilisé testing longtemps, jamais eu de grosses merdes (sur un PC perso).
En gros, ça permets une meilleure stabilité qu'unstable (les paquets ont déjà passé des tests avant d'arriver dans testing) tout en étant plus récents que stable, surtout quand la stable tire sur sa fin de vie (stable backports fait pas tout)…
Un argument que j'avais vu sur la ML, par contre, c'était que oui, pour une machine que l'on veut sécurisée (genre un serveur), c'est la pire, parce qu'à l'époque stable avait le dépôt security, unstable était fréquemment mise à jour, mais en effet un bug dans testing pouvais ouvrir une faille qui mette du temps à être patchée. Depuis, il me semble qu'il existe un repo security pour testing?

Et si tu utilises testing, rien ne t'empêche, justement, d'intégrer des paquets unstable/experimental, vu que la version de la glibc sera plus probablement la même, moins de galères donc que quand tu mixes une stable ou une plus vieille avec d'autres versions.

Pour l'apt-pinning, petite précision: par défaut, les versions privilégiées serons celles configurées dans /etc/apt/apt.conf.d par une entrée de type: APT::Default-Release "buster";, et que l'apt-pinning (que je ne recommande pas a un débutant qui veut un truc qui juste marche) passe après cette clé…

Pour parser des trucs plus complexes, si tu aimes yacc et/ou des grammaires BNF (avec des jolis pipes), libre à toi. Chacun utilise les outils qu'il veut même quand (note le point d'interrogation) on est con … non ?

Mais, moi, j'aime les jolies pipes, je trouve ça esthétique. Bon, ok, pardon pour le jeux de mot pourri.

Pour le reste, désolé. Je n'ai pas de bonne excuse pour le manque de recul dont je fais preuve en ce moment.

Mais, je sais pourquoi j'ai été moinssé… j'ai sortie une blague masculine, alors que bon, j'aurais pu jouer avec l'index() aussi, ça aurais été plus neutre.

Tant que je me fais rire moi-même, ça me va, mais dans la philosophie du LL, je partage ma bêtise, et je constate que c'est parfois bien, merci à toi pour ce constat :)

Accessoirement, je suis assez fier du fait que je ne recule devant aucune facilité quand il s'agit de déconner ;)

Vu ce que tu codes, je me doutais bien que tu étais un peu chéper…

Vraiment?
Je n'ai perso aucune idée de comment faire, j'ai la flemme de chercher, et je soupçonne les résultats des moteurs de recherche d'être blindés d'articles de blogs qui se contentent de gratter la surface.

Du coup, y'a moyen que tu postes un lien? Je suis intéressé.

Je me permets une traduction (je ne suis pas traducteur):

Tant qu'il est possible de compiler, empaqueter(1), déployer les projets depuis un conteneur docker, il est possible de le faire avec OneDev. OneDev supporte tant les conteneurs Linux que Windows(2) dont je suppose qu'il y a de grandes chances qu'il supporte les projets basés sur PHP ou .NET (3).

1: je suis pas sûr de la traduction sur ce terme
2: Je suppose qu'il parle ici d'un environnement GNU/linux, mais il est très possible que ça soit valide pour d'autre systèmes basés sur le noyau linux.
3: .Net: DotNet.

Hello.

I am not sure what do you mean about "require permission to execute on data files", can you please elaborate?

From what I understand, I think he says gitlab needs execution rights on files in /var, which might be a problem on a computer where /var is mounted with options to forbid execution of files. I may be wrong, though.

Et en français:

De ce que je comprend, je pense qu'il dis que gitlab nécessite les droits d'exécution de certains fichiers dans /var, ce qui peut être un problème quand /var est monté avec des option pour empêcher l'exécution de fichiers. Je peux me tromper, cependant.

Montre nous ta main(), je parie sur un problème incrément et décrement.

Heureusement qu'on parle ici de main(), et non de byte(), quand même… non parce que bon, l'incrément, le décrément, l'incrément, c'est… bon, ok. Désolé.

bah, inotify peut détecter une écriture sur un fichier, et de la, tu peux faire un patch que tu envoies sur la cible… mais bon, il faut qu'il y ait écriture sur le fichier, donc, une sauvegarde.

Autrement, t'es obligé de coder un plug-in pour l'outil, c'est autrement plus délicat.