Salut.
En voulant connaître l'heure à laquelle j'ai lancé une commande sudo sur ma machine, je me suis aperçu qu'il me manquait un syslog. Bon, c'est juste une machine de bricolage, donc pas grave, je fais mon p'tit fichier /etc/sv/syslogd/run qui invoque exec chpst -b syslogd busybox -t -n -O -, je fais mon habituel symlink de /etc/runit/log.run vers /etc/sv/syslogd/log/run, je symlink le tout dans le dossier service qui va bien, et pour vérifier que tout roule, je me cale un p'tit tail -f /var/log/syslogd/current.
Je balance une commande sudo -i pour voir si l'info se retrouve bien, c'est le cas. Nickel.
Puis, comme je bricole pépère en discutant sur IRC, je lance mon navigateur web pour vérifier un truc, navigateur basé sur chrome.
À ma surprise, un truc s'ajoute dans le syslog:
2020-07-31_05:29:12.42271 Jul 31 07:29:12 styx user.err chrome[3227]: [3227:3227:0731/072912.422613:ERROR:browser_dm_token_storage_linux.cc(100)] Error: /etc/machine-id contains 0 characters (32 were expected).
Huh? Mais qu'est-ce que? Pourquoi un navigateur web vient-il logguer la-dedans? Et surtout, qu'est-ce que c'est que ce fichier /etc/machine-id au juste?
Lisons la doc…
DESCRIPTION
The /etc/machine-id file contains the unique machine ID of the local
system that is set during installation or boot. The machine ID is a
single newline-terminated, hexadecimal, 32-character, lowercase ID.
When decoded from hexadecimal, this corresponds to a 16-byte/128-bit
value. This ID may not be all zeros.
The machine ID is usually generated from a random source during
system installation or first boot and stays constant for all
subsequent boots. Optionally, for stateless systems, it is generated
during runtime during early boot if necessary.
The machine ID may be set, for example when network booting, with the
systemd.machine_id= kernel command line parameter or by passing the
option --machine-id= to systemd. An ID specified in this manner has
higher priority and will be used instead of the ID stored in
/etc/machine-id.
The machine ID does not change based on local or network
configuration or when hardware is replaced. Due to this and its
greater length, it is a more useful replacement for the gethostid(3)
call that POSIX specifies.
This machine ID adheres to the same format and logic as the D-Bus
machine ID.
This ID uniquely identifies the host. It should be considered
"confidential", and must not be exposed in untrusted environments, in
particular on the network. If a stable unique identifier that is tied
to the machine is needed for some application, the machine ID or any
part of it must not be used directly. Instead the machine ID should
be hashed with a cryptographic, keyed hash function, using a fixed,
application-specific key. That way the ID will be properly unique,
and derived in a constant way from the machine ID but there will be
no way to retrieve the original machine ID from the
application-specific one. The sd_id128_get_machine_app_specific(3)
API provides an implementation of such an algorithm.
Bon…
Reprenons.
Il s'agit donc d'un identifiant unique, qui est nécessaire pour que le système puisse… ben rien en fait, puisque ça fait quelques années que mon système marche très bien sans.
Alors peut-être que systemd peut en avoir besoin, mais je me demande bien ce qu'il peut en faire, vraiment.
Toujours est-il que cet identifiant unique, qui est censé être, je cite "confidential" est manifestement aussi en 0644, donc lisible par tout et n'importe quoi, ce qui inclue le navigateur…
Je continue un peu la lecture de la manpage et lis ceci:
HISTORY
The simple configuration file format of /etc/machine-id originates in
the /var/lib/dbus/machine-id file introduced by D-Bus. In fact, this
latter file might be a symlink to /etc/machine-id.
Je vérifie sur mon système, je sais que dbus est lancé automatiquement par certaines applications, bien malgré moi vu qu'il ne me sert à rien d'autre qu'a satisfaire une dépendance de dconf-service (et tous les logiciels qui ont ce truc en dépendance marchent très bien quand je tue dbus pour info).
En effet, il y a bien un p'tit cookie ici (pas pour longtemps certes).
Un peu plus de recherche sur ce à quoi peuvent bien servir ces machins et je tombe sur ceci:
What should be made clearer in the future
* what is the machine id actually used for?
Je vois bien le genre d'usage qu'on peut faire d'un tel identifiant, après tout, je renseigne bien le hostname de mon système (citation du lien précédent: Being opaque and non-human-meaningful is important for some of the places where it's useful, because if a string is human-meaningful (like a hostname), then people will sometimes want to change it mouai…) mais je trouve les explications que j'ai trouvées "un peu" légères, et le seul usage qui semble en être fait sur mon système vient… d'un des logiciels qui est sur ma TODO-list de remplacement depuis des lustres: un navigateur web (proprio en plus, vivaldi. En même temps, c'est ma faute d'utiliser un freeware).
Par acquit de conscience, j'ai testé vite fait avec firefox et le chromium (installé pour l'occasion) des dépôts debian officiels, et cet identifiant n'est pas utilisé, ou s'il l'est, ce n'est pas loggué dans syslogd.
J'imagine qu'il faudrait que je creuse un peu plus, que j'installe un truc qui log les accès à ces deux fichiers pour que je sache quels logiciels, dans la pratique, les utilise réellement, et surtout pourquoi, mais je me suis dit qu'il serait plus facile dans un 1er temps d'aller troller ici au sujet de systemd (et dbus, mais ça attire moins).
# Oui sur Firefox
Posté par gUI (Mastodon) . Évalué à 6.
Du coup je teste sur le Firefox 78.0.2 de mon Archlinux :
Donc Firefox y accède également.
Et au passage :
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
[^] # Re: Oui sur Firefox
Posté par sebas . Évalué à 2.
Pas chez moi (version 68.11.0esr). Ça ne serait pas un greffon qui y accéderait ?
Par contre, vivaldi, opera et falkon y accèdent, soit dans /etc, soit dans /var/lib/dbus
Basilisk n'y accède pas, mais comme il est basé sur FF, ça semble logique.
Pour Vivaldi, ou ce sont des gros menteurs, ou ils sont sur la voie de corriger ça (à vérifier dans leur prochaine version) : extrait de We don’t track you. Nothing, zero, zilch :
[^] # Re: Oui sur Firefox
Posté par freem . Évalué à 3.
Je suis en train de regarder avec
strace firefox 2>&1 | grep machine-idet en effet, je n'ai pas non plus l'impression qu'il soit accédé. Version 68.10.0esr (la màj vers la 68.11.0esr est dans le tuyau).La question, c'est aussi: est-ce utilisé en soit par vivaldi, ou juste par chrome?
Je veux dire, ça n'excuse pas, hein, mais peut-être que c'est "pas intentionnel".
En fait, je me demande s'il existe un outil qui monitore les accès des processus au système?
Je me souviens que, quand j'utilisais windows XP, il y avais un «firewall» (pas vraiment un firewall pour moi, bien plus puissant. Je ne sais plus si libre ou freeware) qui traçais les accès des applications aux fichier, à la base de registre, au réseau, etc, et qui les bloquais, jusqu'à ce que l'utilisateur dise "ok, ce soft a le droit de faire ça (cette fois|définitivement)" via une GUI qui étais tournée vers l'efficacité, et non le bullshit et le blingbling comme la plupart des AV…
Pas impossible que mon système de l'époque, sous windows et sans anti-virus, était plus sécurisé que mes machines actuelles…
Sous linux, ça doit être techniquement possible avec SELinux et auditd, je regarde justement ces sujets depuis que j'ai posté le journal, mais je ne trouve rien de simple (comme on peut s'y attendre).
[^] # Re: Oui sur Firefox
Posté par ff9097 . Évalué à 0.
Flatpak permet cela, tu peux facilement restreindre l'accès qu'à $HOME par exemple
[^] # Re: Oui sur Firefox
Posté par freem . Évalué à -2.
sudo -R chmod a-rw /. Flatpack réinventé?[^] # Re: Oui sur Firefox
Posté par claudex . Évalué à 4.
Tu ne peux plus lancer aucune commande, tu ne peux plus résoudre de nom, tu ne peux plus charger le profile, lire la conf par défaut ssh…
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Oui sur Firefox
Posté par freem . Évalué à 1.
Ben oui mais l'accès a $HOME est limité :)
Plus "sérieusement", c'était aussi pertinent que de parler de flatpack pour monitorer l'activité réelle d'une application…
Parce que bon, oui, je sais, flatpack peut, en effet, limiter les accès d'une applications a certains fichiers seulement.
Tu ne fais que réduire la liste de ce a quoi ça peut toucher, tu ne sais pas pour autant à quoi ça touche réellement. Donc tu ne peux détecter de comportement étrange.
[^] # Re: Oui sur Firefox
Posté par Jean Roc Morreale . Évalué à 7.
zonealarm, il était très intéressant de voir quel programme essayait d'accéder à quelle ressource
[^] # Re: Oui sur Firefox
Posté par freem . Évalué à 3.
J'ai peut-être «retrouvé» la chose: ProcessGuard mais il semble qu'il en fait un peu moins que dans mes souvenirs, et puis, je ne doute pas qu'il avait ses limites…
Ou était-ce celui-la? Je ne sais plus…
Mais oui c'était intéressant, parce que du coup tu peux corriger le problème à la source, soit en remontant un bug, soit en virant le coupable, voire tout simplement en le bridant.
Me demande s'il y a un trucsimilaire sous linux?
[^] # Re: Oui sur Firefox
Posté par Fopossum . Évalué à 3.
auditd ? Tout « simplement » ?
cd /pub && more beer
# Vendredi c'est permis
Posté par Romuald Brunet (site web personnel) . Évalué à 4.
Plus facile en effet, mais tu as le droit on est vendredi
Je pensais trouver quelques choses d'utiles sur GitHub mais … ça fait beaucoup de bruit en fait :
https://github.com/search?q=%22%2Fetc%2Fmachine-id%22&type=Commits
# Ça sert à quoi machine-id?!
Posté par xrogaan . Évalué à -1.
Ben, c'est pour les DRM hein. Sinon, tout le monde s'en fout. Par exemple, possédant une copie de SublimeText, ce logiciel va utiliser machine-id pour encoder la licence et puis stocker tout ça sur le disque. Il est bien entendus possible de passer outre tout ce brouhaha d'ânerie et d'utilisé le fichier de licence directement (qui n'est qu'une simple clef).
Mais bon, voilà, tout ce qui est proprio et DRM ont besoin d'un identifiant.
[^] # Re: Ça sert à quoi machine-id?!
Posté par gUI (Mastodon) . Évalué à 6. Dernière modification le 31 juillet 2020 à 10:00.
J'en doute très fort vu la simplicité pour le modifier. En tous cas je n'y ferais aucunement confiance si je devais mettre en place un DRM.
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
[^] # Re: Ça sert à quoi machine-id?!
Posté par freem . Évalué à 2.
Et puis surtout, dans le cas d'un DRM, ça serait probablement plus efficace et discret de s'appuyer sur un truc généré via les numéros de série de la machine.
C'est très simple à faire, pas besoin d'être root, j'utilisais ça au taf pour générer des hostname uniques (justement :) mais je construisais le hostname sur diverses infos pour que ça soit utilisable par ceux qui devaient se co a distance pour diverses raisons (donc: moi, entres autres), le but étant de pouvoir ssh par rebond après tout) pour les systèmes a déployer:
udevadm info --query=all /dev/sdaet le tour est joué.Enfin, non, parce qu'il être sûr qu'on est bien installé sur /dev/sda, mais c'est loin d'être insurmontable:
findmnt,lsblketawkpermettent largement de bricoler un truc.Et pas besoin d'un fichier bricolable, potentiellement absent: on se base direct sur la reconnaissance du matos par le kernel.
[^] # Re: Ça sert à quoi machine-id?!
Posté par BAud (site web personnel) . Évalué à 2.
et dans une VM ?
[^] # Re: Ça sert à quoi machine-id?!
Posté par freem . Évalué à 2.
Bonne question. Je n'ai jamais eu le besoin encore.
[^] # Re: Ça sert à quoi machine-id?!
Posté par xrogaan . Évalué à 1.
J'ai jamais avancé l'idée qu'un DRM était malin.
[^] # Re: Ça sert à quoi machine-id?!
Posté par saltimbanque (site web personnel) . Évalué à 0.
Si c'était pas malin les gens l'auraient craqué depuis longtemps et ne s'en plaindraient pas. Que ce soit pas cooool est un autre sujet.
[^] # Re: Ça sert à quoi machine-id?!
Posté par claudex . Évalué à 7.
Il y a plusieurs utilités. Avoir une IP "stable" en DHCP, avoir un multiboot sans soucis avec UEFI (le kernel est dans un dossier qui utilise le machine-id), l'utiliser pour générer le hostname (comme le dit freem) (quand tu as 2500 VM, c'est pratique).
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Ça sert à quoi machine-id?!
Posté par freem . Évalué à 4.
Adresse MAC?
Tu peux développer? Je suis intéressé par le sujet.
[^] # Re: Ça sert à quoi machine-id?!
Posté par claudex . Évalué à 9.
Avec un portable, tu changes d'adaptateur USB et tu change de mac. Tu change de docking et du change de mac. Si la carte réseau de ton serveur change ou si change de machine (en gardant le disque), l'adresse MAC change. Alors, ça marche dans la plupart des cas. Mais je trouve plus logique d'utiliser un identifiant lié au système pour identifier le système. Tout ce qui est lié au matériel peu changer.
Je ne vois pas ce que tu veux de plus comme info. Au lieu de stocker à la racine, c'est stocker dans un dossier qui a pour nom le machine-id. Du coup, si tu as deux kernel avec le même nom pour deux install distinctes, il n'y a pas de collision. https://wiki.debian.org/MachineId
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Ça sert à quoi machine-id?!
Posté par esdeem . Évalué à 5. Dernière modification le 31 juillet 2020 à 19:32.
Pas nécessairement, tu peux faire du softmac, et c'est même très pratique pour t'identifier sur un réseau de la même façon, avec différentes machines (une à la fois sinon ton réseau va déconner), ou une seule machine mais différentes cartes réseaux.
C'est exactement ce que j'ai fais quand j'ai changé de portable sur le réseau de mon école d'ingénieur. C'était passablement plus simple que de refaire un demande pour avoir accès au réseau, lequel était filtré par adresse MAC. Et dès le départ, j'avais créé un adresse MAC ad-hoc pour ce réseau.
Par ailleurs, je continue à faire ce genre de chose sur certains réseaux, ou au contraire je randomise les adresses MAC de mes cartes réseau pour plus d’anonymité.
0. Assume good faith 1. Be kind to other people 2. Express yourself 4. Apply rule 0
[^] # Re: Ça sert à quoi machine-id?!
Posté par claudex . Évalué à 3.
ça reste plus simple d'avoir un DUID fixe pour du DHCP. C'est prévu pour ça et évite le risque de collision.
Et du coup, tu randomise ton DUID sur ces réseaux aussi ?
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Ça sert à quoi machine-id?!
Posté par freem . Évalué à 2.
C'est pas plus simple d'avoir juste 2 sous-dossier différents? Quand tu fais du multiboot, tu es quand même capable de faire ça je pense?
Et je vois pas ce que ça a a voir avec l'UEFI, sauf le fait que les kernels ont tendance a se retrouver sur la partitions de boot, et… je me demande si c'est une fatalité, en soit, surtout avec des softs comme grub2 (qui n'est pas celui que j'utilise, certes, m'enfin la n'est pas la question).
[^] # Re: Ça sert à quoi machine-id?!
Posté par claudex . Évalué à 3.
C'est justement ce qui est fait. Le but est de nommer ces sous-dossier pour éviter une collision.
Tu peux te passer de grub avec un UEFI.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Ça sert à quoi machine-id?!
Posté par freem . Évalué à 0. Dernière modification le 01 août 2020 à 01:51.
Exact. Tout comme on peut le faire avec un BIOS en vrai.
Zut on est plus trolldi, je dois donc préciser, le BIOS boote un secteur précis, etne savais pas gérer un format de fichier.
UEFI lui semble savoir gérer un format de ficher (FAT?) et booteras une partitions avec un UUID spécifique. Ou partiras sur un interpréteur de commandes.
Ça reste flou… mais bon, dans l'état, grub n'a toujours été qu'in intermédiaire, il n'a jamais été techiquement nécessaire, je me trompe?
[^] # Re: Ça sert à quoi machine-id?!
Posté par claudex . Évalué à 5.
Je ne suis pas sûr de ce que tu veux dire. Avec un UEFI, tu peux enregistrer des kernels à démarrer directement par l'UEFI, kernels qui sont stocker dans une partition en FAT32 (la spécification impose qu'un UEFI puisse lire du FAT32, donc c'est ce qui est utilisé la plupart du temps, mais je crois que rien n'empêche dans la spec que l'UEFI puisse lire un autre type de partition et donc que tu puisse booté depuis de l'ext4 si ton UEFI le permet).
Avec un BIOS, le bootloader est nécessaire parce qu'il ne charge que les 512 octets d'un secteur. Si ton kernel tient là-dedans, tu n'as pas besoin bootloader, sinon il t'en faut un. C'est pour ça que grub est en deux partie (stage 1 et stage 2). La première est minimaliste et permet juste de charger la deuxième qui est plus complète et va elle-même avoir les instructions pour charger un kernel et l'initrd.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Ça sert à quoi machine-id?!
Posté par freem . Évalué à 3.
Si je me trompe pas:
Dans le cas d'un partitionnement type MS-DOS, le 1er secteur (donc 512 octets) du disque ne contiens pas à proprement parler le boot loader, mais un code qui permets de trouver la partition à booter, qui elle contiendra un chargeur de démarrage, la ou LILO, Syslinux vont aller se coller. Grub2, en effet, va modifier ce 1er secteur, ce qui m'a suffisamment cassé les pieds par le passé.
Mais la 1ère partie de grub ne tiens pas sur 512 octets, ce qui semble être la raison qui fait qu'utiliser grub sur un système GPT en legacy boot implique l'usage d'une partition dédiée, parce que Grub2 se base sur un overflow.
Les autres que j'ai pu utiliser (LILO, syslinux, et probablement le démarrage sous dos, w9x, wXP) ne faisaient pas ça.
Je n'arrive pas a retrouver les documents que j'avais sur le sujet, tant pis (j'aurai bien aimé revérifier mes propos et avoir des références plus précises, mais ça fait plus de 15 ans que je les ai pas vus).
[^] # Re: Ça sert à quoi machine-id?!
Posté par claudex . Évalué à 4.
L'article Wikipédia explique bien le fonctionnement je trouve.
https://en.wikipedia.org/wiki/GNU_GRUB#Version_2_(GRUB_2)
Ce n'est pas qu'il se base sur un overflow mais le stage 1 pointe vers des secteurs vident dans une partition mbr.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Ça sert à quoi machine-id?!
Posté par freem . Évalué à 2.
Merci, je lirais ça un peu plus tard.
Et, tu as raison, j'aurai du plutôt parler de dépassement de tampon, puisque ce n'est pas un comportement qui serais causé par la RàZ d'un overflow, mais bien par une écriture au-delà de qu'il a le droit d'écrire.
Vu que c'est, dans ce cas, intentionnel, il s'agit d'un hack. Pas malintentionné, certes, mais bon.
[^] # Re: Ça sert à quoi machine-id?!
Posté par Guillaume T . Évalué à 3.
En Ipv6 on ne peut plus se baser sur l'adresse MAC. Si on souhaite attribuer une IPv6 perso à une machine en la reconnaissant sur le réseau (via les RA et dhcpv6 donc), machine-id est utilisé, au moins par nerworkmanager et systemd-network.
Pour l'anecdote, je déteste les installs systèmes. Donc je copie un autre système systématiquement et je modifie ce qui doit l'être. Je me suis retrouvé avec plusieurs machines possédant le même machine-id. Ça ne m'a jamais posé de problèmes jusqu'à ce fameux cas.
[^] # Re: Ça sert à quoi machine-id?!
Posté par Anonyme . Évalué à 2.
Le mode « stable-privacy » est activé par défaut, mais tu peux toujours le changer, voir addr-gen-mode (désolé, j’ai pas trouvé de documentation orientée utilisateur).
[^] # Re: Ça sert à quoi machine-id?!
Posté par Anonyme . Évalué à 2. Dernière modification le 03 août 2020 à 14:45.
Selon ce que tu fais, tu devrais peut-être regardé du côté de cloud-init.
Par exemple, mes templates de VM sont construit avec packer, au démarrage cloud-init se charge de la configuration de base (réseau, ssh, installation des paquets nécessaires, etc.) et enfin Puppet passe s’occuper de tout le reste.
# Utilisé dans Chrome, pas Chromium ?
Posté par Tarnyko (site web personnel) . Évalué à 3. Dernière modification le 31 juillet 2020 à 14:03.
Hello, après avoir lu le code de Chromium,
J'ai trouvé où c'est implémenté, mais pas appelé. Du coup je me demande si seul Chrome (le browser commercial) ne ferait pas appel à cette info, et d'une manière qu'on ignore ; pourrais-tu exécuter :
ls ~/.config/chromium/Policy/Enrollment/
ls ~/.config/chrome/Policy/Enrollment
ls ~/.config/google-chrome/Policy/Enrollment/
(un indice quand même : sous Windows uniquement, si l'équivalent de cette valeur existe, la machine est considérée comme "gérée par l'entreprise" et Chrome ne fait pas ses mises à jour par lui-même)
[^] # Re: Utilisé dans Chrome, pas Chromium ?
Posté par freem . Évalué à 3.
Les seuls dossiers que j'ai par ici avec le mot policy dans le nom sont:
Ça ne semble pas correspondre a ce que tu veux?
[^] # Re: Utilisé dans Chrome, pas Chromium ?
Posté par Tarnyko (site web personnel) . Évalué à 1.
Effectivement, tout comme moi.
J'ai installé Chrome du coup, et ai même activé la synchro cloud (pour la science !), mais sans résultat.
Par contre j'ai trouvé ceci sur le net ; n'ayant pas de compte "entreprise", je ne peux pas tester…
# machine-id
Posté par solsTiCe (site web personnel) . Évalué à 5.
le machine-id est utilisé par journald. Tu le retrouves dans
/var/log/journaloù les journaux système sont loguer … si tu utilises systemd-journaldJe pense que d'autres utilitaires/services systemd peuvent l'utiliser: machinectl ?
Tu peux changer le machine-id avec
systemd-machine-id-setupmais ce n'est pas recommandé et cela se fait à l'installation du système. Je n'ai aucune idée de ce que cela peut casser si tu le changes. Ça doit dépendre des softs qui l'utilises et de ce qu'ils en font.# .
Posté par Sufflope (site web personnel) . Évalué à 10.
Oui un cas classique de "quelle heure est-il" rien de compliqué.
[^] # Re: .
Posté par freem . Évalué à 4.
Je sais que c'est fait exprès, mais tu as quand même enlevé un morceau important: je ne parlais pas de l'heure actuelle, sinon "date" m'aurai suffit :)
[^] # Re: .
Posté par Sufflope (site web personnel) . Évalué à 4.
Hahaha oui mon […] bien que techniquement correct (j'ai supprimé une portion contiguë de ton texte) est un peu… hasardeux :-)
Ceci dit si tu veux que je prenne plus de risques, ça peut se faire. Attends. Hum hum.
Sérieusement, pour avoir un log global horodaté, perso je préfère faire
dnf install journald. Ah non mais attends j'ai rien à faire : c'est installé de base sur ma distrib. Mais bon si t'aimes souffrir années 90-style…Et pour être sûr d'avoir du moinssage cette fois : je suis sérieux en fait :-D
[^] # Re: .
Posté par freem . Évalué à 1. Dernière modification le 07 août 2020 à 08:51.
Tu confonds "se faire chier 90-style" et "ne pas avoir a implémenter parce que d'autres ont fait le boulot pour moi". Ce sont deux choses différentes.
Techniquement, runit est un héritier des daemontools donc c'est "me faire chier 2000-style".
Et techniquement, je pourrais aussi juste utiliser voidlinux, donc je peux aussi parler de 2020-style, et utiliser runit sans m'embêter a faire mes scripts.
Sauf que moi je veux le support de runit dans ma Debian. Et je ne suis pas le seul à le vouloir.
Sinon, au sujet de "se faire souffrir": voici ce que j'ai lu récemment. Vois-tu, il semble que parmi ceux qui ont vraiment besoin de bosser avec le gestionnaire de service, certains trouvent que, oui systemd a de jolies fonctionnalités (
One or two features seem to do what we have hacked differently so far.), mais c'est fragile (It looks like several features are incompatible changes and will break things in more or less surprising ways.) et complexe (all development schedules blow up with its complexity).Malheureusement, cette personne ne parle pas d'autres systèmes qu'elle aurait expérimenté (aurait été intéressant pour comparer).
Pour ma part, j'en ai expérimenté un autre, qui a ses défauts, qui sont différents de ceux de systemd.
Il y en a un 3ème que j'aimerai essayer, qui semble avoir la simplicité que j'apprécie chez runit, sans son inconvénient majeur: l'absence de gestion des dépendances. Un jour je prendrais le temps de tester nosh, s'il tiens ses promesses, alors c'est peut-être bien la meilleure option.
Honnêtement, ça serait pas mal, mais vu que la plupart de ceux qui cherchent une alternative simple et stable à systemd ont tendance a partir vers runit, je préfère suivre ce mouvement dans un 1er temps. Les logiques étant compatible (nosh est aussi un héritier de daemontools) si le jour ou je teste il s'avère que ça marche mieux, migrer sera un jeu d'enfant. Et je pourrais me baser sur un truc qui marche.
Tu sais que c'est peu probable, tu défends le système le plus utilisé après tout :)
[^] # Re: .
Posté par GnunuX (site web personnel) . Évalué à 0.
Ah ben si un gus à dit qu'il lui semble quelque chose c'est que c'est forcement fragile.
[^] # Re: .
Posté par freem . Évalué à 2.
Vu l'argumentation que tu mets en place, c'est clair.
# Grammalecte a dit
Posté par tisaac (Mastodon) . Évalué à 1.
qu’il me manquais → qu’il me manquait
je fait mon habituel → je fais mon habituel
sur ce a quoi peuvent → sur ce à quoi peuvent
par acquis de conscience → par acquit de conscience
je me suis dis → je me suis dit
Surtout, ne pas tout prendre au sérieux !
[^] # Re: Grammalecte a dit
Posté par Benoît Sibaud (site web personnel) . Évalué à 3.
Corrigé, merci.
# pour les UUID ?
Posté par Kioob (site web personnel) . Évalué à 1.
Je m'en sers pour initialiser un générateur d'UUIDv2 : l'idée est que ce machine-id est sensé être différent sur toutes les instances d'un même cluster ; ce qui est sensé éviter les conflits en cas de traitement/insertions parallèles.
Par contre je n'arrive pas à retrouver pourquoi j'ai basé ça sur le /etc/machine-id. C'était peut-être un moyen "pratique" de remplacer les MAC, par un autre «stable unique identifier that is tied to the machine», comme dit la manpage.
alf.life
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.