freem a écrit 5019 commentaires

il n'est plus nécessaire de jongler avec des adresses publiques/privées

Tu veux dire qu'il n'existe plus de plages privées, du coup? La ou Internet IPv4 est un réseau de réseaux, avec des passerelles, avec IPv6 il n'y a plus qu'un seul réseau?

il y a deux protocoles, SLAAC (StateLess Auto Adress Configuration) et DHCPv6.

Vais aller lire ça, merci.

Pas vraiment. Un logiciel lancé par inetd n'a pas de spécificité réseau, puisque inetd raccorde stdin/stdout du process qu'il lance sur une socket qu'il crée lui même, alors que depuis init.d, il faut faire socket/bin/accept et tout ce qui tourne autour…

Il existe des serveurs qui n'ouvrent pas de sockets et ne font que lire stdin? J'imagine que, sur le principe, c'est faisable, et ça pourrait même permettre de faire un serveur avec un simple script shell, mais, en pratique, je serais curieux de voir un exemple.

Je suis curieux de savoir si d'autres ont déjà tenté de récupérer l'énergie de façon plus stable et toute l'année, par exemple via l'eau chaude ou quoi :)

Je suis sûr que oui, mais ça nécessiterait une installation évoluée j'imagine. Peut-être en évacuant la chaleur vers l'équipement de chauffage de l'eau, vu que c'est bien le seul élément auquel je pense qui bénéficierait d'une chaleur permanente… Sauf que justement ces trucs sont plutôt bien isolés en général?
Peut-être la buanderie aussi, pour le coup, pour sécher le linge plus vite, mais bon, en été, on s'en fout un peu je dirait…
Pour tout ce qui est cuisson, la chaleur ne suffirait pas, c'est trop froid.

Combien, 30 ans d'éducation réseau à casser ? Ça va être dur… :)

Nope, je dirais a peu près 17 seulement, ça pourrait être 2 fois plus simple que prévu, si l'administration était mon métier, mais ce n'est pas le cas (ce qui ne m'empêche pas de vouloir savoir comment ça marche).

Pour le reste, si je comprend bien, ton routeur dispose d'une plage d'IPs alors qu'en IPv4, sur les pauvres réseaux domestiques que j'ai eu à gérer, il n'en a qu'une seule. Du fait de l'abondance des IPs, donc, il suffit d'affecter les IPs que l'on souhaite utiliser à une machine spécifique et le tour est joué? Du coup, la différence contrairement à IPv4, c'est qu'il n'a pas besoin d'aller ouvrir le protocole suivant (TCP/UDP/ICMP/Que-sais-je/…) d'où un gain de simplicité dans la pile logicielle?

ni de l'allocation des IPs

A mon grand regret, mais je comprend (que tu ne le fasse pas, je veux dire). De toute façon, je suppose qu'il doit y avoir un équivalent au DHCP qui fonctionne plus ou moins comme ceux que l'on utilise pour IPv4, à l'exception du fait de la quantité d'adresses dispo que l'on ne se prive pas pour assigner plusieurs IPs à une même interface, par exemple une IP publique et une IP locale, qui permette éventuellement de ne lancer les services sensibles que sur l'IP locale?

https://blog.webernetz.net/why-nat-has-nothing-to-do-with-security/)

Autant le discours ne me surprend pas (je n'ai jamais vraiment considéré le NAT comme pour la sécurité… je ne me suis jamais vraiment posé la question non plus, à vrai dire) mais je pense que l'on peut faire la confusion du fait que les box internet font firewall en plus du NAT. Ainsi que DHCP et autres joyeusetés qui devraient à mon humble avis ne pas se situer sur l'équipement qui est directement exposé au réseau public… surtout quand on constate que bien souvent, pour modifier la conf DHCP, il faut rebooter le routeur, super…

En tout cas le lien est sympa, y'a plein de mots-clés à chercher pour qui veut apprendre un peu le réseau \o/

Et tu devras te taper des problématiques de routage à la con au moindre changement topologique. C'est vu et revu.

Du coup, autre point qui m'intéresse: ton IPv6, tu la distribue comment? Codée en dur dans la machine ou distribuée par un DHCP?
Et le jour ou tu veux mettre ton service sur le réseau, tu vas bien passer par une machine (qui fasse à minima firewall, routeur, et peut-être d'autres choses) qui aura 2 IPs, une en local, une en global. Donc, il faudra bien que tu fasse une traduction d'adresse non? Comment ça marcherait tout ça?

Oui, mais si la limitation provenait des TTY, alors SSH au-dessus du TTY serait malgré tout limité par l'affichage lui-même, contrairement à une éventuelle accélération produite par les modes graphiques.

Merci pour les réponses.

Si c'était le cas, le problème se produirait également avec l'usage de SSH sur un TTY, hors ce n'est pas le cas… Accessoirement, stty dans urxvt me donne la même vitesse.

Et puis, 4.6Kio/s, ça me paraît largement assez pour afficher quelques nombres. J'essaierai ce soir de changer le baudrate pour voir, mais je doute que ça change quoique ce soit.

Ça a l'avantage de la simplicité, mais si on veut un truc un peu mieux intégré dans le réseau, il faudra passer par autre chose.

Quand tu dis mieux intégré, tu as des exemples?
Je sais que via un socket on peut récupérer pas mal d'informations, mais la plupart c'est via des sockets de type UNIX, me semble qu'on peut les transférer d'une machine à une autre via des tunnels mais… jamais essayé encore.

ce type de fonctionnement est présenté dans systemd comme une « révolution »

Je le sais, mais je pense que systemd est un projet qui vise à implémenter tout un environnement spécifique au noyau linux pour gérer la totalité du système.
inetd n'est pas le seul daemon qu'ils ont ré-implémenté en appelant ça une révolution: syslogd & consorts, crond, … je ne vois plus systemd comme un ensemble de logiciels mais comme une framework.
Avis personnel: les framework, c'est bien pour le jetable, dès qu'on veut maintenir un truc sur plus de 5 ans, utiliser des lib permets de n'avoir à remplacer qu'un seul composant le jour ou il y a un problème.

Pour moi c'est en priorité pour le simplicité de stdin/stdout, cf. plus haut, c'est tout.

À la lumière d'une autre de tes réponses, cette phrase m'intrigue.
La réponse en question dit:

Si ton service est Unix standard, il utilise syslog. Forcément, si tu parles de l'avantage du logging pour palier son manque dû à des applis Web codées par des dev modernes…

Si ma mémoire est bonne, syslogd nécessite une connexion sur un socket pour récupérer les logs, et non sur l'entrée standard.
Si le but est la simplicité, l'idée de logguer dans stdout plutôt que dans un socket avec le protocole syslog n'est-elle pas bonne? Après tout, un admin peut toujours utiliser des trucs comme svlogd pour ensuite récupérer ces logs?

D'ailleurs, est-ce vraiment une obligation d'utiliser syslog pour un outil UNIX standard? Si je me souviens bien, la philosophie d'UNIX, c'est de toujours balancer du texte sur les entrées et sorties standard, et pour le coup, je trouve que syslogd y déroge, mais bon, ce n'est pas mon domaine, je dois rater un truc (centraliser les logs dans un daemon permets peut-être un filtrage plus efficace, je ne sais pas).

il est même administrable en Web ce qui peut sembler bien, mais moi je trouve que ça fait une interface en trop à surveiller.

Tiens, je n'avais jamais fait attention à son existence, merci, ça pourrait être utile. Et pour commencer, ça va se rendre utile par un touch /etc/apt-cacher-ng/userinfo.html pour désactiver ça… en tout cas, ça à l'air de désactiver le frontal web de conf, je vais creuser un peu plus le sujet quand j'aurais le temps.

j'ai déjà eu des problèmes de cache corrompu pour une raison inconnue (plusieurs fois),

Raison inconnue, ça veut bien dire que tu n'es pas sûr que le problème ne viens pas du système de fichiers ou d'un autre processus?

Je pensais que inetd était un vieux truc

Dans mon cas, je me serais arrêté la, en gros, mais je n'y connais rien.
Si je ne me trompe pas (peu probable, mais les trucs que j'en ai lu jusqu'ici se résument à peu près à dire "superserveur", rien que ça), inetd est un outil pour économiser les ressources: il lance et éteins des daemons selon la demande.
Du coup, autant j'en vois l'intérêt dans un environnement ou il faut pouvoir redémarrer très vite le système (exposé à des milliers d'utilisateurs énervés d'attendre 10s de plus), mais est-ce maintenant vraiment le plus long de nos jours, de charger le daemon depuis le disque dur (voire le cache de l'OS)? Est-ce si coûteux de garder le processus en mémoire (en supposant qu'il soit capable de se nettoyer de lui-même lors de la fermeture d'une connexion, bien sûr) ou en swap?
Même en imaginant un environnement ou il y a un grand besoin de performances, je trouve que l'idée fait double emploi avec le cache de l'OS, au fond?

Du coup, il sert a quoi, inetd?

On voit bien que les terminaux graphiques ont des valeurs sensiblement autour de 2.0secs, mais le tty est vraiment à la ramasse sous linux.
Est ce qu'il y a des raisons à ça ?

J'étais intrigué, donc j'ai fait un test, plus simple, en bash: time for i in $(seq 1 10000); do printf "%d" $i;done.
Le résultat est environ de 1.84s sur un TTY, sur 5 essais.
Sur urxvt, je suis à environ 0.19s, l'écart est d'un ordre de grandeur de x10.
Sur TTY via ssh, les résultats changent pas mal, mais en moyenne et à vue de nez, dans les 0.25s.
Sur urxvt, via ssh, dans les 0.35s.

À vue de nez, le TTY est en moyenne et à la louche 10x plus lents que les autres solutions.
Le temps mis par les sessions ssh fluctue énormément, ce que j'aurai envie d'associer au réseau et autres usages CPU ponctuels (le chiffrement, ça doit se sentir, il aurait fallu tester telnet, screen ou tmux pour enlever des causes d'interférences), mais sont proches, tout en étant légèrement plus lents que le test sous urxvt seul.

À vue de nez, pour moi, la constante ici c'est: /dev/ttyXX vs /dev/pts/XX. Je m'avance, mais je suppose que /dev/ttyXX accède à l'écran de manière brute, sans cache, en mode caractère, tandis que /dev/pts/XX doit ajouter un cache, qui doit augmenter les performances drastiquement (parce qu'envoyer 10 blocs de 5 octets est plus lents qu'envoyer un seul bloc de 50 octets, moins d'appels systèmes, notamment).

Bon, théorie à confirmer, hein, je n'ai pas fait de vrais bench, y'a pleins d'applications qui tournent sur cette machine et qui parasitent, je n'ai pas non plus fait assez d'essais loggués pour extraire des résultats vraiment précis et surtout, je n'ai pas cherché à caler un petit gperftools derrière tout ça :)

Pour le fun, le même truc codé en C:
* tty, sans SSH: ~0.95s
* tty, via SSH: ~0.005s
* urxvt, sans SSH: ~0.004s
* urxvt, via SSH: ~0.005s

Le ratio change radicalement de catégorie ici (x200?) et l'impact de SSH est négligeable (en fait, je pense que la commande time n'est pas assez précise, il faudrait que j'augmente le nombre d'itérations…).
J'ai envie de dire que ça conforte mon idée: dans le cas des terminaux virtuels, il est probable que les données ne soient envoyées à l'écran qu'avec une certaine fréquence, contrairement au TTY qui doit envoyer dès que la donnée est disponible.

Mais c'est amusant de voir l'écart de performances entre PTS et TTY du coup… je pense que je vais me bricoler un petit bout de code pour coller direct mes shells TTY dans des PTS du coup.

PS: désolé de pas pouvoir aider plus sur la question…

Admettons que tu ne t'aperçoive du problème qu'après avoir distribué ton binaire à 1000 machines au travers de, disons, juste 3 pays de la taille de la France.
Tu as alors fait chauffer la totalité de l'infrastructure, et tu dois de toute façon faire tes tests à postériori, sans parler de réémettre. Donc, à mon humble avis, le gain est à la fois au niveau de la réputation (système plus fiable), du temps humain (moins de tests manuels), et de l'énergie (moins de transfert de données).

C'est vrai, et surtout, les softs pour leur système ont une compatibilité ascendante qui peut dépasser les 20 ans, sans recompilation. Ça n'empêche, winfile, c'est une application finale, pas une lib, donc la nécessité d'être carré est «moins importante».
Et ça date de leurs débuts dans le monde des OS graphiques, ils auraient pu avoir du code plus cavalier.

Est-il vraiment souhaitable de faire la même chose qu'Electron.JS (j'ai toujours envie de virer la moitié de ce mot quand je pense à cette «techno»… traumatisme des galères liées à une appli du taf j'imagine)?

Je veux dire, embarquer Chromium, ne pas avoir d'API stable qui permette de s'interfacer avec le système, bouffer une mégachiée de mémoire vive et poncer le disque dur au lancement à chaud, sans parler d'une intégration déplorable au système (ben oui, obligé d'avoir N instances de chromium sur le disque, puisque l'API n'est pas stable…). Ah, et je sais que l'espace disque c'est «pas cher» (même si perso je préfère avoir de la place pour mes VMs, qui elles ont une raison valide d'être lourdes), mais la bande passante à chaque MàJ par contre si: tout le monde n'a pas la fibre hein, mes parents sont encore à moins de 250 Kio/s de download par exemple.

Du coup, ça fait vraiment la même chose? Ça embarque vraiment chromium en mode sale? Est-ce une bonne chose si c'est le cas?

J'ai pris 2 fichiers, comme ça, au hasard, et… j'ai trouvé le code limpide, ça m'a surpris.

Les fonctions documentent leurs pré-requis, les "if() d'une ligne" utilisent des accolades (donc pas de goto fail probable), le code est aéré…
Vraiment surpris!

Parce que "Oh, tu te rends compte, ils allouent sur la stack! Comment osent-ils!!!", moi, ça me fait ni chaud ni froid.

Je faisait référence à ceci. Oui, on passe notre temps à alouer sur la stack, à chaque appel de fonction même.
Par contre, ça se fait très rarement avec des données en provenance directe de l'utilisateur, et la fonction utilisée pour ça ne permets pas de savoir si l'appel à échoué. Les problèmes mémoire sont assez communs comme ça, pourquoi prendre un risque aussi important? La performance de journald est-elle vraiment critique au point de ne pas pouvoir appeller malloc?

a ne remet pas l'intérêt de SystemD en cause. Il répond à des besoins où nous n'avions pas de solution simple avant.

Comme je l'ai dis, je remercie systemd, du fait qu'il m'a forcé à me pencher sur le fonctionnement du PID 1, et j'ai beaucoup appris ainsi.
Et puis, le côté configuration déclarative, franchement, je trouve l'idée super. Ce que je regrette, c'est que le projet ne semble avoir aucune limite dans le NIH, et vue la criticité de tout ça, je tique.

Je dirais que customiser la totalité du démarrage d'une distribution est un bon moyen d'apprendre:

• comprendre ce qui se passe quand le firmware passe la main au bootloader (grub2, habituellement, quelques-uns préfèrent utiliser syslinux, pour diverses raisons);
• comprendre ce que fait le "PID 1", comprendre ce qu'est l'utilisateur "root" (UID 1, de mémoire, on peut très bien imaginer le renommer en "admin", tant que l'UID reste 1), par exemple en refaisant tous les services, ou en essayant d'autres logiciels que systemd (ce qui force à porter les units);
• se faire (en fait, utiliser une combinaison de logiciels isolés, et non un méta-paquet type gnome) son propre environnement de bureau, ce qui part du gestionnaire de connexion jusqu'à l'explorateur de fichier;
• se faire violence (au début au moins) et cesser d'utiliser un explorateur de fichiers ou un menu graphiques;

Sinon, il reste la possibilité d'installer une distribution de 0, sans passer par l'installateur: ça s'appelle du bootstrap, Debian à même des logiciels faits pour: debootstrap et cdebootstrap.
Déployer un serveur PXE pour utiliser des machines sans disque dur est également formateur (et pratique, ça permets de faire des systèmes jetables rapidement, pour les expérimentations).
Utiliser des gestionnaires de configuration, type Rex, cfengine, puppet, salt, …

Mais bon, comme les autres l'ont dit, ça viens surtout au fur et à mesure, quand on cherche à optimiser son PC pour son usage perso, plutôt que garder des trucs génériques.

Titre «raccoleur» (qui ne marchera ici que sur ceux qui s'ennuyent).
Liens sans informations sur leur contenu.
Conclusion qui sort du vide si on lit juste le «journal».

Tu penses juste être moinssé pour l'anglais?

Et donc? Y'en a un qu'ils ont trouvé à propos, ils l'on choisit, et alors?

Je dirais même que, Ascii, pour un satellite, c'est débile, bordel c'est un standard sur 7 bits quoi, comment peut-on nommer un satellite comme ça?

Faudrait p'tet penser à arrêter de se concentrer sur les apparrences un jour… la plupart d'entre nous est probablement adulte, et pourtant on passe plus de temps a critiquer des apparences, noms, libellés,etc qu'a agir…
En plus, ici, on a un public plutôt orienté technique, alors vraiment, si vous voulez enfoncer devuan, faites-le avec un peu d'arguments, de véritables statistiques que vous pouvez détourner proprement…

Devuan c'est tout de même pas terrible.

Je te rejoins, la parenté est trop présente. D'un autre côté, je pense que c'est le but, malgré l'évidente polémique. Cela dit, à la base, c'était debian-fork, je crois. C'est moins pire de nos jours donc.

J'aurais préfèré un truc plus fonctionnel, évocateur.

Hum… cites moi un seul nom de distro qui soit «fonctionnel, évocateur» s'il te plaît? Chapeau rouge? Deborah Ian? Linux du vide? Super-linux (Arch)?

Rah, si seulement on avait un OS complet appelé Linux.

Y'a moyen, si tu parviens a faire intégrer busybox dans le sourcetree de linux…

On peut lister une série de problème sur à peu près tout, y compris des supers logiciels dont on est "fanatique", ça s'appelle garder son sens critique, c'est pas pour ça que ce sont de mauvais logiciels.

Bien entendu.

une simplification de la situation précédente

Qui était quoi, dans ton cas?

Je comprends les sceptiques, SysV (et consort) est satisfaisant pour les administrateurs, qui connaissent bien leur système (contrairement aux développeurs). Et à partir du moment où ça juste marche, pourquoi vouloir changer ..

Je pense que le problème n'est pas juste lié à "if it works, don't fix it".
C'est quoi, d'ailleurs, les consorts de sysV? C'est quoi, selon toi, le rôle de sysV? Et c'est quoi, selon toi, le rôle de systemd? Tu es programmeur, donc tu devrais être capable de définir le rôle d'un logiciel de façon précise, pour pouvoir l'implémenter correctement.
Et c'est justement ce que moi je n'aime pas avec systemd: ce projet a démarré comme simple init+watchdog, et ça faisait sens. En plus, il promettait de remplacer ces immondes scripts de rc.d par des fichier de déclaration? Génial. Seul inconvénient: pas portable. Bon, ça, ok, pourquoi.

Ensuite, je me suis aperçu au fil du temps que non, je n'était pas capable de voir ou ce projet compte s'arrêter, et qu'il compte remlacer tout un ensemble logiciel éprouvé par de nouvelles implémentations inter-dépendantes.
C'est ça qui m'a fait chercher des alternatives, et je dois à systemd le fait de connaîtres des alternatives à rc.d.

Pour en revenir à la question: pourquoi ne pas l'utiliser s'il marche bien? Parce que, il suffit de lire un tant soit peu pour s'apercevoir qu'à plusieurs reprises des composants de systemd qui n'ont pas à tourner en tant que root ont permis l'escalade de privilège, bugs qui sont liés à l'usage de fonctions dont la simple lecture du rôle me fait froid dans le dos (allouer sur la stack?)!

C'est la même chose pour D-Bus aussi

Marrant que tu en parles. Récemment, sur mon poste perso sous debian, j'ai du recompiler SDL pour virer le support de DBus parce que ça pourrissait les performances (afficher un message d'erreur à chaque fois qu'on ne trouve pas DBus, même si on ne s'en sert pas… mais… sérieux?). Je pense que le problème vient en pratique de la SDL, hein, mais, je trouve ça cocasse.

Tu l'as mal compris.

J'ai noté ça.

C'est pas faux. Sauf:

en pratique, les critiqueurs de systemd veulent juste garder leur vieux truc pire sans proposer mieux

Si on remets le contexte, il y a deux catégories de gens qui critiquent systemd:

• ceux qui veulent rester à rc.d (parce que les cascade d'inclusion de dash, bash, et autres c'est tellement lisible, et devoir se fader 150 lignes de code par service c'est logique);
• ceux qui considèrent qu'il y a d'autres solutions moins "tout-en-un", qui font la même chose que ce que j'ai perçu comme le but initial de systemd (à savoir, être un watchdog logiciel, oui, ça remonte, et à l'époque j'aimai systemd) sans avoir à supporter tout le reste, journald inclu, sur lequel j'ai vu passer plusieurs failles exploitables à distance, et les dernières en date sont liées à l'utilisation de code pour allouer dynamiquement sur la stack, qui n'est pas faite pour ça.

tu ne répond en BOOTP/DHCP que aux clients qui sont des firmware PXE

En somme, c'est un DHCP secondaire. Personnellement, j'ai un problème majeur: le routeur que l'on utilise, quand on change la config DHCP, il faut le rebooter. Il n'a pas non plus de telnetd/sshd/whatever. En gros, c'est un routeur pour particuliers, et j'ai aucune maîtrise dessus (enfin, j'ai accès à l'IHM web… mouarf).

Mon idée à long terme, c'est de séparer le LAN en plusieurs VLAN, selon les services, affecter à tout ça un routeur que je puisse configurer à ma guise (ou celle de quelqu'un qui s'y connaît mieux, ça m'arrangerait), qui routerait les requêtes vers l'une de nos deux *box en fonction de divers paramètres. À partir de là, je pourrais être confiant de pas tout casser à la mondre modif DHCP, mais il me reste une longue route à parcourir, et pas mal de connaissances à amasser… la seule chose certaine, c'est qu'ici vu que tout est à faire, je peux choisir de n'utiliser que des soft libres :)