Les gens voient sur TF1, sur news.com ou autre un article disant "vulnerabiite dans Windows" (ou dans IE ou …).
Les journaux parlent des vulnérabilités de Windows ?
C’est marrant, moi la seule fois que j’ai entendu parler de Windows au journal télévisé, c’est quand Microsoft s’est invité sur le plateau du 20 h de France 2 pour la sortie de Windows Vista (oui, cinq minutes de pub en grandes pompes sur la télévision publique, dans un créneau normalement réservé à « l’information », où est le problème ?). Et bizarrement ni l’invité ni le présentateur n’ont évoqué la moindre faille…
qui n'est pas fourni avec le kernel standard de Debian
Tu veux dire que le noyau fourni par défaut sous Debian n’est pas configuré avec CONFIG_RT_GROUP_SCHED ? Si c’est le cas, alors la méthode d’Anthony devrait marcher.
Pour rappel, il y a deux façons incompatibles de donner des privilèges temps-réels à un processus sous Linux, selon que CONFIG_RT_GROUP_SCHED soit activé ou non.
Sans CONFIG_RT_GROUP_SCHED, un processus demande une politique d’ordonnancement temps-réel (SCHED_FIFO ou SCHED_RR) et une priorité en appelant sched_setscheduler(2). Le système accède à cette demande si le processus est autorisé, c’est-à-dire si la “resource limit” RLIMIT_RTPRIO associée à ce processus est supérieure à la priorité demandée. En règle générale, la limite RLIMIT_RTPRIO (comme toutes les autres ”resource limits”) pour un utilisateur donné est définie à la connexion de ce dernier, via un module PAM qui applique des règles décrites dans /etc/security/limits.conf.
Si le noyau est compilé avec CONFIG_RT_GROUP_SCHED, un processus obtient une politique d’ordonnancement temps-réel de facto en se plaçant (ou en étant placé) dans un cgroup auquel on a attribué une « fraction de temps réel » (paramètre cpu.rt_runtime_us > 0).
Les deux méthodes sont incompatibles parce que la seconde invalide complètement la première : si CONFIG_RT_GROUP_SCHED est activé, demander et obtenir une politique d’ordonnancement temps réel avec sched_setscheduler(2) ne sert à rien tant que le processus n’est pas placé dans un cgroup avec un cpu.rt_runtime_us non-nul (le piège étant que l’appel à sched_setscheduler(2) n’échoue pas — pour le processus, tout semble se passer comme s’il avait bel et bien obtenu la politique d’ordonnancement qu’il demandait). Inversement, une fois un processus placé dans un cgroup « temps réel », il a de facto une politique d’ordonnancement temps réel même s’il ne l’a pas explicitement demandé.
le problème est que systemd implémente seulement un subset des cgroups qui correspond à l'option automatique du kernel, qu'il prend le contrôle des cgroups, et que contrairement au kernel associé avec libcgroup/cgroup-bin, systemd ne met aucune réelle possibilité de setup à disposition de l'utilisateur.
En fait, à terme systemd doit être le seul à utiliser les cgroups de manière à les cacher complètement au reste du système. Il introduit pour ça les « slices », qui sont la seule chose que le code utilisateur est censé connaître et utiliser pendant que lui (systemd) utilise les cgroups en arrière-plan.
“Direct access to the cgroup tree is on is way out and that must be clear to everybody.” — L. Poettering
Il y a bien une forme de transivité dans les clés, non ?
Pour la validité des clés, oui. Pour la confiance accordée au propriétaire de la clef, non.
Si je fais confiance à Bruce qui fait confiance à Roger, je ne fais pas du tout confiance à Roger ?
Non. Si tu fais pleinement confiance à Bruce et que Bruce dit que la clé de Roger est valide, alors la clé de Roger est automatiquement considérée valide.¹ Cela n’implique pas du tout que tu fasses automatiquement confiance à Roger, et ce quelle que soit la confiance éventuelle que Bruce accorde à Roger.
Une fois qu’une clé a été validée (que ce soit par toi-même ou par quelqu’un de ton réseau en qui tu as confiance), c’est à toi et à toi seul de décider de la confiance que tu accordes à son propriétaire.
¹ Dans la configuration par défaut de GnuPG, mais c’est modifiable.
Alors déjà, pour faire ça SANS AUCUN RISQUE DE BUGS, je n’utiliserais pas Evenja, quand je vois ce que me donne ton Tuto3 :
$ ./configure
$ make
$ cd src
$ ./evenja hello1.xml
Hello World!
This is only an example.
Loto : 35,17,33,34,38,9
Segmentation fault
Alors, sans Evenja, comment faire des choses complexes en combinant des programmes simples sans modifier le code de ceux-ci ?
Euh, comme on fait déjà sous Unix depuis quarante ans ?
Soit Tuto1 un programme qui lit les lignes d’un fichier et les affiche (même pas besoin de l’écrire, il existe déjà, il s’appelle cat), Tuto2 un programme qui affiche six numéros tirés au hasard entre 1 et 42 ; et voici Tuto3, un programme qui lit et affiche les lignes d’un fichier et affiche 6 numéros tirés au hasard :
Je remarque que tu parles de personnes mortes depuis longtemps, pour mieux "vendre" leur histoire
Je ne suis pas sûr (je n’en sais rien en fait) que toutes ces francisations (et germanisations, italianisations, etc.) soient postérieures au décès des personnes concernées.¹
Je pense plutôt que c’était simplement l’usage à l’époque, même si aujourd’hui je t’accorde qu’il tend franchement à disparaître (on francise toujours aujourd’hui Elizabeth II en Élisabeth II, mais on ne parle jamais du Prince Guillaume pour désigner son petit-fils le Prince William).
¹ Bon, pour Cicéron, il n’y a guère de doutes que son nom n’a pas été francisé de son vivant. ;)
Outre les noms de lieux dont j’ai déjà parlé plus bas, on francise même les noms de personnes : William III qui devient Guillaume III, Johan Sebastian Bach qui devient Jean-Sébastien Bach, Friedrich II qui devient Frédéric II (ou même, en remontant beaucoup plus loin, Cicero qui devient Cicéron)…
Et ce n’est pas propre au français d’ailleurs : William devient Wilhelm en allemand, Guglielmo en italien, Guillermo en espagnol…
Pékin, c'est Bejing (nom qui remplace Pékin de plus en plus souvent). Comme, quoi, c'est facile.
Peut-être que Beijing commence à remplacer Pékin, mais je n’ai pas l’impression que London, Frankfurt, Köln, Roma ou Philadelphia remplacent de plus en plus souvent Londres, Francfort, Cologne, Rome ou Philadelphie…
Ce n’est pas qu’une question d’alphabet, on francise beaucoup de noms issus de langues utilisant pourtant l’alphabet latin.
Il me reste plus qu'à trouver un moyen pour re-install logwatch sans installer exim4 ou sendmail (le lien symbolique ne lui suffit pas :D)
Sur Debian ou dérivé, je pense qu’il faut plutôt installer le paquet msmtp-mta plutôt que msmtp. C’est le même programme mais le premier paquet fournit le paquet virtuel mail-transport-agent, dont est dépendant logwatch.
Juste parce que ça me pique les yeux (et que j’ai déjà répondu utilement par ailleurs) : quelque chose peut faire l’affaire ou remplir sa fonction, mais pas remplir l’affaire.
Je comprend bien qu'il me faut "quelques chose" qui fasse le liens entre WEB et MAIL, mais quoi ?
Un client SMTP, comme msmtp par exemple. L’avantage de ce dernier est qu’il accepte les mêmes options que sendmail(8), de telle sorte qu’on peut créer un lien symbolique /usr/sbin/sendmail vers /usr/bin/msmtp, ainsi les programmes se reposant sur sendmail(8) pour l’envoi de messages (comme la fonction mail() de PHP si j’ai bien compris) utiliseront automatiquement msmtp de façon transparente.
(Quel intérêt de remplacer sendmail par un programme qui se fait passer pour sendmail, me diras-tu ? C’est que msmtp est « juste » un client SMTP qui relaie les messages à un vrai MTA — en l’occurence le Postfix installé sur ta machine MAIL —, là où sendmail est lui-même un « vrai » MTA dont tu n’as pas besoin, sur ta machine WEB, de toutes les fonctionnalités.)
Il n'y a pas besoin de laisser tomber syslog, le support de l'API journal peut etre ajoutée dans des #ifdef.
Quand je disais « laisser tomber syslog pour journald », je sous-entendais naturellement « sur les plate-formes où systemd est disponible ». Et ça ne change rien à mon propos : qui va le faire ? Qui va prendre la peine de préparer une entrée de log structurée quand systemd est disponible, et une ligne de texte partout ailleurs, alors qu’il peut tout simplement continuer à utiliser une ligne de texte partout comme actuellement ?
Non, ca peut permettre par exemple de ne grepper que les logs du dernier boot, ou du precedent, ou uniquement ceux depuis une certaine date.
Point accordé. Ça doit être bien pratique dans certains cas. Mais je ne trouve toujours pas ça transcendant (c’est-à-dire que je ne suis pas convaincu que ça justifie une telle refonte du système de log).
Enfin bref, comme je n’ai pas spécialement l’intention d’intervenir davantage dans ce débat, je vais résumer ma position actuelle sur systemd :
– détracteurs de systemd, ne vous tracassez pas trop, vous verrez qu’en définitive, systemd ne changera pas grand’chose ;
– adorateurs de systemd, ne vous emballez pas trop, vous verrez qu’en définitive, systemd ne changera pas grand’chose.
Ca change que le programme peut logguer des données de facon structurée.
Et combien vont le faire ? Sachant que seul systemd-journald offre cette possibilité et qu’il n’est pas seul en jeu. Tu crois que les développeurs de démons vont laisser tomber syslog(3), largement disponible, et se mettre à utiliser l’API propre à systemd-journald ? Moi je n’y crois pas. Oh, certains le feront, certainement, mais je doute fort qu’ils soient nombreux.¹
D’ailleurs, d’après Lennart Poettering, la meilleure façon de logger, pour les démons « new style » (c’est comme ça qu’il appelle les démons conçus dès le départ pour profiter de systemd), c’est d’utiliser… le bon vieux printf(3), systemd se chargeant d’envoyer la sortie standard du démon vers journald.
Et meme si le programme ne le fait pas, journald log de base certaines infos de facon structurée, comme le PID et l'UID du process, l'ID de boot, l'unit systemd, les infos SELinux, etc
Sauf que typiquement ce ne sont pas ces informations que l’on veut aller grepper dans les logs, mais bien les informations propres au programme, celles contenues dans le message qu’il a envoyé.
Pour illustrer mon propos, mettons que je veuille récupérer les adresses des petits malins qui tentent de bruteforcer mon serveur SSH. Actuellement, avec des journaux au format texte gérés par syslog, je ferais quelque chose du genre :
$ grep sshd /var/log/messages | sed -nre 's/^.*\[(.+)\] failed - POSSIBLE BREAK-IN ATTEMPT!/\1/p'
avec une belle regex fragile qui peut ne plus marcher à la prochaine mise à jour de sshd si les développeurs de celui-ci ont jugé bon de changer le format de ce message.
Avec des journaux au format binaire gérés par systemd-journald, je ferais (attention, révolution) :
$ journalctl _SYSTEMD_UNIT=sshd.service | sed -nre 's/^.*\[(.+)\] failed - POSSIBLE BREAK-IN ATTEMPT!/\1/p'
… avec une belle regex fragile qui peut ne plus marcher à la prochaine mise à jour de sshd si les développeurs de celui-ci ont jugé bon de changer le format de ce message. Zut alors, ni systemd-journald ni le fait de stocker les journaux au format binaire n’ont empêché ça.
Le seul bénéfice visible de journald, ici, c’est de faire l’économie de la première regex, celle qui sert à filtrer les messages issus de sshd — c’est-à-dire, la plus simple et surtout celle qui n’est pas vraiment susceptible de changer.
il est relativement simple de ne pas casser la compatibilité, l'ajout d'un nouveau champ ne va pas poser de problèmes.
Je considérerai cet avantage lorsque je verrai les développeurs de sshd opter pour l’API de journald en lieu et place de syslog(3). En attendant, c’est purement théorique.
¹ Quand je vois le nombre de programmes qui enregistrent encore leurs données directement à la racine de $HOME au lieu d’utiliser les répertoires proposés par la « XDG Base Directory Specification »… il ne suffit pas de proposer quelque chose de pratique pour que ce soit utilisé.
En quoi, est-ce plus compréhensible ? On a la moité des champs qui sont du texte (paths, messages, …), un grand nombre de champs qui sont des très petits nombre, quelques timestamps.
D’une part, le volume d’informations pour une entrée est tel que ça ne me paraitrait pas très pratique de tout stocker sur une ligne. Je note au passage qu’au moins deux de ces champs peuvent contenir des espaces (MESSAGE et CMDLINE), ce qui introduit la nécessité de trouver un séparateur dont on soit sûr qu’il ne figurera jamais dans le contenu d’un champ (ou de permettre des échappements).
On pourrait certes stocker une entrée sur plusieurs lignes, mais cela rendrait le journal sensiblement plus difficile à exploiter avec les outils Unix classiques qui sont typiquement conçus pour travailler sur des lignes (comment récupérer deux champs différents d’une même entrée à coups de grep|cut|sed|awk|etc. s’ils sont sur deux lignes différentes ? c’est possible, certes, mais certainement pas pratique).
D’autre part, avec systemd-journald la composition d’une entrée de journal n’est pas constante (par exemple, toutes les entrées n’auront pas de champ _SYSTEMD_UNIT, seules celles provenant d’un processus faisant partie d’une unité systemd). Et ce d’autant plus que systemd-journald veut offrir aux programmes la possibilité de créer leurs propres champs en plus des champs définis par défaut (même si je doute personnellement que cette fonctionnalité sera beaucoup utilisée). Encore une fois, gérer ça me paraît malaisé dans un format texte à la syslog (qui est facile à utiliser notamment parce que tous les champs sont à des positions connues d’avance sur une ligne).
Après, je n’ai pas dit que le format binaire était le meilleur choix (franchement, je n’ai pas d’opinion tranchée sur la question) : je dis juste que compte tenu des ambitions de systemd-journald (qui veut un journal plus riche), ça se défend.
C'est ce que j'ai dit […] non ?
Si. Ce passage s’adressait plus à Zenitram, à qui tu répondais.
On pourrait imaginer l'ajout d'un pid ou autre bricoles
Justement, systemd-journald ajoute pas mal « d’autres bricoles », comme :
– PID, UID et GID du processus émetteur ;
– le chemin du fichier exécutable ;
– la ligne de commande complète avec laquelle il a été lancé ;
– le cgroup dans lequel il se trouve ;
– le unit systemd dont il dépend ;
– un identifiant unique de la machine émettrice ;
– etc.
Cf. systemd.journal-fields(7) pour la liste complète (dans la section « Trusted journal fields »).
Du coup, voici à qui peut ressembler une entrée journald complète (telle que renvoyée par journalctl -o export :
Vu le nombre de champs ajoutés à stocker (ici, seul les champs MESSAGE et PRIORITY viennent du programme émetteur, tout le reste est ajouté soit par syslog, soit par journald), le choix d’un format binaire devient peut-être plus compréhensible… (Et puis, ça aurait pu être pire : si systemd avait été inventé dix ans plus tôt on aurait probablement eu droit à du XML…)
En tout cas, toujours au vu de la quantité d’informations à obtenir et à écrire, débattre du temps mis pour écrire un timestamp selon que l’on stocke en texte ou en binaire me semble assez peu pertinent, ce n’est certainement pas là à mon avis que systemd-journald passe le plus de temps.
Et c'est très fragile. Ta regex devient inutile dès que le format des messages changent.
Peut-être que tu peux écrire des regex très intelligentes. Mais dès que le format des messages va changer, t'auras 50% de chances pour que ta regex ne fonctionne plus.
Et qu’est-ce que systemd-journald va changer à cela au juste ?
Systemd-journald n’impose absolument rien quand au format des messages. Un programme souhaitant enregistrer une entrée dans le journal peut envoyer un message structuré basé sur des champs bien définis, mais le même programme peut aussi utiliser des champs qu’il définit lui-même et surtout il peut parfaitement se contenter de n’envoyer que de banales chaînes de caractères dans lequel il formatte les informations à sa guise. journald n’impose même pas la locale ou l’encodage des chaînes de caractères en question (UTF-8 est recommandé mais la documentation dit clairement que rien n’est fait pour l’imposer).
Perso, je préfère avoir affaire à une API stable ou une base de données qu'à du texte.
Tu auras une API stable pour accéder aux messages, mais pas pour exploiter leur contenu. Si un programme change le format de ses messages (que ceux-ci soit structurés ou non), tu devras toujours t’y adapter. systemd-journald ne résoudra pas automagiquement ce problème qui est totalement hors de sa portée, c’est entièrement dépendant des développeurs des programmes qui écriront dans le journal. Comme avec syslog en fait.
c'est peut-être même un comportement par défaut de systemd mais je ne suis pas sûr
Vérification faite (directement depuis l’archive source de systemd-208), c’est le cas : c’est l’unité « rc-local.service », qui exécute par défaut /etc/rc.local (modifiable par --with-rc-local-script-path-start lors de la configuration de systemd).
Sous Slackware (mais ça doit être adaptable facilement sous une autre distribution), je ferais ça d’abord en ajoutant le code suivant dans /etc/rc.d/rc.local :
Le script /etc/rc.d/rc.local est exécuté à la fin de la séquence de démarrage (sous Slackware, il est vide par défaut — il est précisément conçu pour que l’administrateur puisse y rassembler ses bidouillages) ; ici, il exécute le programme demandé et stocke le résultat (sous une forme sourçable par un shell, c’est-à-dire nom=valeur) dans un fichier quelque part dans /var.
Ensuite, dans /etc/profile, ou dans un fichier quelconque dans /etc/profile.d (ces fichiers étant sourcés lors de tout démarrage de session), on vérifie la présence du fichier /var/state/resultats, on le source, et on exporte la variable dans l’environnement :
if[ -f /var/state/resultats ];then
. /var/state/resultats
export mon_resultat
fi
(La variable n’est pas accessible depuis tout le système — en particulier, tous les processus démarrés dans les scripts d’init en ignoreront toujours l’existence —, mais elle sera accessible à tous les programmes démarrés depuis une session utilisateur.)
La présence de systemd (ou d’un autre système d’init non-classique) ne devrait pas changer grand’chose, dès lors qu’on peut insérer un bout de script shell quelque part à une étape du démarrage. Avec systemd, j’imagine qu’il faudra créer une unit uniquement chargée d’exécuter un script dédié.
Non mais ne te fatigue pas à répondre, tout le message est juste un prétexte pour coller des liens prétendument pertinents vers "batterie chargeurs fr"… (NdM : nom du site modifié, pas la peine d'aider le spammeur)
Je suis presque sûr qu’en faisant le tour des forums consacrés de près ou de loin à l’informatique, on trouvera sur nombre d’entre eux un message similaire issu d’un compte utilisateur dont le nom est dérivé du site (comme linuxfr.org → linxfr).
Personellement je n'utilise pas la même définition de libre pour une distribution que pour un logiciel.
La FSF non plus.
Pour un logiciel, leur définition est la définition « classique » (les quatre libertés, tout ça) sur laquelle à peu près tout le monde est d’accord, éventuellement à quelques nuances de formulation près.
Pour une distribution, leur définition est explicitée dans leurs free system distributions guidelines, avec lesquelles pas grand’monde ne semble d’accord (en particuliers les développeurs de distributions).
En fait, le support de SNI par le client n’est même pas nécessaire, si l’on accepte que les virtual hosts partagent le même certificat et la même clef privée, ce qui est acceptable dans certains cas.¹ Il suffit de lister le nom de tous les virtual hosts dans le champ subjectAltName du certificat.
¹ Ça l’est évidemment beaucoup moins si les différents virtual hosts concernent des sites n’ayant absolument aucun rapport entre eux (comme dans un hébergement mutualisé par exemple).
Mais ici, j'avais pris le double soin d'écrire scenarii sans accent sur le e, et en italique. Par conséquent il s'agit là d'un usage tout à fait correct, ce que l'académie préconise pour l'emploi d'une locution étrangère.
Justification peu convaincante. Ou bien le mot est entré dans le vocabulaire français, auquel cas il s’écrit en français aussi bien au singulier qu’au pluriel, ou bien il ne l’est pas, auquel cas le singulier comme le pluriel doivent s’écrire en italique et sans accent. Si on francise le singulier, il n’y a aucune raison d’exclure le pluriel.
D’autre part, même en italien « scenarii » est incorrect, la bonne forme est « scenari ».
« Scenari » aurait été acceptable si « scénario » n’apparaissait pas dans le même message.
[^] # Re: Bien essaye
Posté par gouttegd . En réponse au journal La GPL est un échec (FreeBSD 10 est sorti). Évalué à 9.
Les journaux parlent des vulnérabilités de Windows ?
C’est marrant, moi la seule fois que j’ai entendu parler de Windows au journal télévisé, c’est quand Microsoft s’est invité sur le plateau du 20 h de France 2 pour la sortie de Windows Vista (oui, cinq minutes de pub en grandes pompes sur la télévision publique, dans un créneau normalement réservé à « l’information », où est le problème ?). Et bizarrement ni l’invité ni le présentateur n’ont évoqué la moindre faille…
[^] # Re: Scheduler Temps reel
Posté par gouttegd . En réponse au message Les cgroups et systemd. Évalué à 2.
Tu veux dire que le noyau fourni par défaut sous Debian n’est pas configuré avec CONFIG_RT_GROUP_SCHED ? Si c’est le cas, alors la méthode d’Anthony devrait marcher.
Pour rappel, il y a deux façons incompatibles de donner des privilèges temps-réels à un processus sous Linux, selon que CONFIG_RT_GROUP_SCHED soit activé ou non.
Sans CONFIG_RT_GROUP_SCHED, un processus demande une politique d’ordonnancement temps-réel (SCHED_FIFO ou SCHED_RR) et une priorité en appelant sched_setscheduler(2). Le système accède à cette demande si le processus est autorisé, c’est-à-dire si la “resource limit” RLIMIT_RTPRIO associée à ce processus est supérieure à la priorité demandée. En règle générale, la limite RLIMIT_RTPRIO (comme toutes les autres ”resource limits”) pour un utilisateur donné est définie à la connexion de ce dernier, via un module PAM qui applique des règles décrites dans
/etc/security/limits.conf.Si le noyau est compilé avec CONFIG_RT_GROUP_SCHED, un processus obtient une politique d’ordonnancement temps-réel de facto en se plaçant (ou en étant placé) dans un cgroup auquel on a attribué une « fraction de temps réel » (paramètre cpu.rt_runtime_us > 0).
Les deux méthodes sont incompatibles parce que la seconde invalide complètement la première : si CONFIG_RT_GROUP_SCHED est activé, demander et obtenir une politique d’ordonnancement temps réel avec sched_setscheduler(2) ne sert à rien tant que le processus n’est pas placé dans un cgroup avec un cpu.rt_runtime_us non-nul (le piège étant que l’appel à sched_setscheduler(2) n’échoue pas — pour le processus, tout semble se passer comme s’il avait bel et bien obtenu la politique d’ordonnancement qu’il demandait). Inversement, une fois un processus placé dans un cgroup « temps réel », il a de facto une politique d’ordonnancement temps réel même s’il ne l’a pas explicitement demandé.
[^] # Re:
Posté par gouttegd . En réponse au message Les cgroups et systemd. Évalué à 2.
En fait, à terme systemd doit être le seul à utiliser les cgroups de manière à les cacher complètement au reste du système. Il introduit pour ça les « slices », qui sont la seule chose que le code utilisateur est censé connaître et utiliser pendant que lui (systemd) utilise les cgroups en arrière-plan.
“Direct access to the cgroup tree is on is way out and that must be clear to everybody.” — L. Poettering
[^] # Re: Limites de GPG
Posté par gouttegd . En réponse à la dépêche La plus grande GPG key signing party approche. Évalué à 2.
Pour la validité des clés, oui. Pour la confiance accordée au propriétaire de la clef, non.
Non. Si tu fais pleinement confiance à Bruce et que Bruce dit que la clé de Roger est valide, alors la clé de Roger est automatiquement considérée valide.¹ Cela n’implique pas du tout que tu fasses automatiquement confiance à Roger, et ce quelle que soit la confiance éventuelle que Bruce accorde à Roger.
Une fois qu’une clé a été validée (que ce soit par toi-même ou par quelqu’un de ton réseau en qui tu as confiance), c’est à toi et à toi seul de décider de la confiance que tu accordes à son propriétaire.
¹ Dans la configuration par défaut de GnuPG, mais c’est modifiable.
[^] # Re: Brace yourselves, bullshit is coming.
Posté par gouttegd . En réponse à la dépêche Concours "Evenja Café", un nouveau paradigme de programmation. Évalué à 3. Dernière modification le 08 janvier 2014 à 15:18.
Alors déjà, pour faire ça SANS AUCUN RISQUE DE BUGS, je n’utiliserais pas Evenja, quand je vois ce que me donne ton Tuto3 :
Alors, sans Evenja, comment faire des choses complexes en combinant des programmes simples sans modifier le code de ceux-ci ?
Euh, comme on fait déjà sous Unix depuis quarante ans ?
Soit Tuto1 un programme qui lit les lignes d’un fichier et les affiche (même pas besoin de l’écrire, il existe déjà, il s’appelle cat), Tuto2 un programme qui affiche six numéros tirés au hasard entre 1 et 42 ; et voici Tuto3, un programme qui lit et affiche les lignes d’un fichier et affiche 6 numéros tirés au hasard :
[^] # Re: de toute façon ce sont des cons chez freedesktop
Posté par gouttegd . En réponse au journal Perte de CTRL. Évalué à 10.
Genre comme avec OpenSSL ?
Sans rire, j’aurais cru que cette mésaventure diminuerait un peu l’ardeur des développeurs Debian à patcher à tout va…
[^] # Re: Android / androïde
Posté par gouttegd . En réponse à la dépêche CyanogenMod 10.2. Évalué à 4.
Je ne suis pas sûr (je n’en sais rien en fait) que toutes ces francisations (et germanisations, italianisations, etc.) soient postérieures au décès des personnes concernées.¹
Je pense plutôt que c’était simplement l’usage à l’époque, même si aujourd’hui je t’accorde qu’il tend franchement à disparaître (on francise toujours aujourd’hui Elizabeth II en Élisabeth II, mais on ne parle jamais du Prince Guillaume pour désigner son petit-fils le Prince William).
¹ Bon, pour Cicéron, il n’y a guère de doutes que son nom n’a pas été francisé de son vivant. ;)
[^] # Re: Android / androïde
Posté par gouttegd . En réponse à la dépêche CyanogenMod 10.2. Évalué à 5.
Euh, oui ?
Outre les noms de lieux dont j’ai déjà parlé plus bas, on francise même les noms de personnes : William III qui devient Guillaume III, Johan Sebastian Bach qui devient Jean-Sébastien Bach, Friedrich II qui devient Frédéric II (ou même, en remontant beaucoup plus loin, Cicero qui devient Cicéron)…
Et ce n’est pas propre au français d’ailleurs : William devient Wilhelm en allemand, Guglielmo en italien, Guillermo en espagnol…
[^] # Re: Android / androïde
Posté par gouttegd . En réponse à la dépêche CyanogenMod 10.2. Évalué à 5.
Peut-être que Beijing commence à remplacer Pékin, mais je n’ai pas l’impression que London, Frankfurt, Köln, Roma ou Philadelphia remplacent de plus en plus souvent Londres, Francfort, Cologne, Rome ou Philadelphie…
Ce n’est pas qu’une question d’alphabet, on francise beaucoup de noms issus de langues utilisant pourtant l’alphabet latin.
[^] # Re: C'est pas pour gâcher l'esprit de Noël, mais...
Posté par gouttegd . En réponse au journal Alan Turing gracié.. Évalué à 4.
Oh, elle est jolie, celle-là !
Tu voulais dire décris, je suppose, parce que je ne vois pas où ton interlocuteur a décrié qui que ce soit.
(Il sort discrètement.)
[^] # Re: installer autre chose sur WEB
Posté par gouttegd . En réponse au message [Résolu] Envoie de mail depuis serveur web. Évalué à 4.
Sur Debian ou dérivé, je pense qu’il faut plutôt installer le paquet msmtp-mta plutôt que msmtp. C’est le même programme mais le premier paquet fournit le paquet virtuel mail-transport-agent, dont est dépendant logwatch.
[^] # Re: installer autre chose sur WEB
Posté par gouttegd . En réponse au message [Résolu] Envoie de mail depuis serveur web. Évalué à 2.
Juste parce que ça me pique les yeux (et que j’ai déjà répondu utilement par ailleurs) : quelque chose peut faire l’affaire ou remplir sa fonction, mais pas remplir l’affaire.
[^] # Re: installer autre chose sur WEB
Posté par gouttegd . En réponse au message [Résolu] Envoie de mail depuis serveur web. Évalué à 4.
Un client SMTP, comme msmtp par exemple. L’avantage de ce dernier est qu’il accepte les mêmes options que sendmail(8), de telle sorte qu’on peut créer un lien symbolique
/usr/sbin/sendmailvers/usr/bin/msmtp, ainsi les programmes se reposant sur sendmail(8) pour l’envoi de messages (comme la fonction mail() de PHP si j’ai bien compris) utiliseront automatiquement msmtp de façon transparente.(Quel intérêt de remplacer sendmail par un programme qui se fait passer pour sendmail, me diras-tu ? C’est que msmtp est « juste » un client SMTP qui relaie les messages à un vrai MTA — en l’occurence le Postfix installé sur ta machine MAIL —, là où sendmail est lui-même un « vrai » MTA dont tu n’as pas besoin, sur ta machine WEB, de toutes les fonctionnalités.)
[^] # Re: GNU/SystemD/Linux
Posté par gouttegd . En réponse au journal Systemd va gagner une console système, un bootsplash et un login-screen. Évalué à 1.
Quand je disais « laisser tomber syslog pour journald », je sous-entendais naturellement « sur les plate-formes où systemd est disponible ». Et ça ne change rien à mon propos : qui va le faire ? Qui va prendre la peine de préparer une entrée de log structurée quand systemd est disponible, et une ligne de texte partout ailleurs, alors qu’il peut tout simplement continuer à utiliser une ligne de texte partout comme actuellement ?
Point accordé. Ça doit être bien pratique dans certains cas. Mais je ne trouve toujours pas ça transcendant (c’est-à-dire que je ne suis pas convaincu que ça justifie une telle refonte du système de log).
Enfin bref, comme je n’ai pas spécialement l’intention d’intervenir davantage dans ce débat, je vais résumer ma position actuelle sur systemd :
– détracteurs de systemd, ne vous tracassez pas trop, vous verrez qu’en définitive, systemd ne changera pas grand’chose ;
– adorateurs de systemd, ne vous emballez pas trop, vous verrez qu’en définitive, systemd ne changera pas grand’chose.
Bon vendredi.
[^] # Re: GNU/SystemD/Linux
Posté par gouttegd . En réponse au journal Systemd va gagner une console système, un bootsplash et un login-screen. Évalué à 4. Dernière modification le 05 décembre 2013 à 23:56.
Et combien vont le faire ? Sachant que seul systemd-journald offre cette possibilité et qu’il n’est pas seul en jeu. Tu crois que les développeurs de démons vont laisser tomber syslog(3), largement disponible, et se mettre à utiliser l’API propre à systemd-journald ? Moi je n’y crois pas. Oh, certains le feront, certainement, mais je doute fort qu’ils soient nombreux.¹
D’ailleurs, d’après Lennart Poettering, la meilleure façon de logger, pour les démons « new style » (c’est comme ça qu’il appelle les démons conçus dès le départ pour profiter de systemd), c’est d’utiliser… le bon vieux printf(3), systemd se chargeant d’envoyer la sortie standard du démon vers journald.
Sauf que typiquement ce ne sont pas ces informations que l’on veut aller grepper dans les logs, mais bien les informations propres au programme, celles contenues dans le message qu’il a envoyé.
Pour illustrer mon propos, mettons que je veuille récupérer les adresses des petits malins qui tentent de bruteforcer mon serveur SSH. Actuellement, avec des journaux au format texte gérés par syslog, je ferais quelque chose du genre :
avec une belle regex fragile qui peut ne plus marcher à la prochaine mise à jour de sshd si les développeurs de celui-ci ont jugé bon de changer le format de ce message.
Avec des journaux au format binaire gérés par systemd-journald, je ferais (attention, révolution) :
… avec une belle regex fragile qui peut ne plus marcher à la prochaine mise à jour de sshd si les développeurs de celui-ci ont jugé bon de changer le format de ce message. Zut alors, ni systemd-journald ni le fait de stocker les journaux au format binaire n’ont empêché ça.
Le seul bénéfice visible de journald, ici, c’est de faire l’économie de la première regex, celle qui sert à filtrer les messages issus de sshd — c’est-à-dire, la plus simple et surtout celle qui n’est pas vraiment susceptible de changer.
Je considérerai cet avantage lorsque je verrai les développeurs de sshd opter pour l’API de journald en lieu et place de syslog(3). En attendant, c’est purement théorique.
¹ Quand je vois le nombre de programmes qui enregistrent encore leurs données directement à la racine de $HOME au lieu d’utiliser les répertoires proposés par la « XDG Base Directory Specification »… il ne suffit pas de proposer quelque chose de pratique pour que ce soit utilisé.
[^] # Re: GNU/SystemD/Linux
Posté par gouttegd . En réponse au journal Systemd va gagner une console système, un bootsplash et un login-screen. Évalué à 5.
D’une part, le volume d’informations pour une entrée est tel que ça ne me paraitrait pas très pratique de tout stocker sur une ligne. Je note au passage qu’au moins deux de ces champs peuvent contenir des espaces (MESSAGE et CMDLINE), ce qui introduit la nécessité de trouver un séparateur dont on soit sûr qu’il ne figurera jamais dans le contenu d’un champ (ou de permettre des échappements).
On pourrait certes stocker une entrée sur plusieurs lignes, mais cela rendrait le journal sensiblement plus difficile à exploiter avec les outils Unix classiques qui sont typiquement conçus pour travailler sur des lignes (comment récupérer deux champs différents d’une même entrée à coups de grep|cut|sed|awk|etc. s’ils sont sur deux lignes différentes ? c’est possible, certes, mais certainement pas pratique).
D’autre part, avec systemd-journald la composition d’une entrée de journal n’est pas constante (par exemple, toutes les entrées n’auront pas de champ _SYSTEMD_UNIT, seules celles provenant d’un processus faisant partie d’une unité systemd). Et ce d’autant plus que systemd-journald veut offrir aux programmes la possibilité de créer leurs propres champs en plus des champs définis par défaut (même si je doute personnellement que cette fonctionnalité sera beaucoup utilisée). Encore une fois, gérer ça me paraît malaisé dans un format texte à la syslog (qui est facile à utiliser notamment parce que tous les champs sont à des positions connues d’avance sur une ligne).
Après, je n’ai pas dit que le format binaire était le meilleur choix (franchement, je n’ai pas d’opinion tranchée sur la question) : je dis juste que compte tenu des ambitions de systemd-journald (qui veut un journal plus riche), ça se défend.
Si. Ce passage s’adressait plus à Zenitram, à qui tu répondais.
[^] # Re: GNU/SystemD/Linux
Posté par gouttegd . En réponse au journal Systemd va gagner une console système, un bootsplash et un login-screen. Évalué à 7.
Justement, systemd-journald ajoute pas mal « d’autres bricoles », comme :
– PID, UID et GID du processus émetteur ;
– le chemin du fichier exécutable ;
– la ligne de commande complète avec laquelle il a été lancé ;
– le cgroup dans lequel il se trouve ;
– le unit systemd dont il dépend ;
– un identifiant unique de la machine émettrice ;
– etc.
Cf. systemd.journal-fields(7) pour la liste complète (dans la section « Trusted journal fields »).
Du coup, voici à qui peut ressembler une entrée journald complète (telle que renvoyée par
journalctl -o export:Vu le nombre de champs ajoutés à stocker (ici, seul les champs MESSAGE et PRIORITY viennent du programme émetteur, tout le reste est ajouté soit par syslog, soit par journald), le choix d’un format binaire devient peut-être plus compréhensible… (Et puis, ça aurait pu être pire : si systemd avait été inventé dix ans plus tôt on aurait probablement eu droit à du XML…)
En tout cas, toujours au vu de la quantité d’informations à obtenir et à écrire, débattre du temps mis pour écrire un timestamp selon que l’on stocke en texte ou en binaire me semble assez peu pertinent, ce n’est certainement pas là à mon avis que systemd-journald passe le plus de temps.
[^] # Re: traduction git
Posté par gouttegd . En réponse au journal traduction git. Évalué à 4.
Oui, à la compilation. Extrait du
configure.acde Git :[^] # Re: GNU/SystemD/Linux
Posté par gouttegd . En réponse au journal Systemd va gagner une console système, un bootsplash et un login-screen. Évalué à 5.
Et qu’est-ce que systemd-journald va changer à cela au juste ?
Systemd-journald n’impose absolument rien quand au format des messages. Un programme souhaitant enregistrer une entrée dans le journal peut envoyer un message structuré basé sur des champs bien définis, mais le même programme peut aussi utiliser des champs qu’il définit lui-même et surtout il peut parfaitement se contenter de n’envoyer que de banales chaînes de caractères dans lequel il formatte les informations à sa guise. journald n’impose même pas la locale ou l’encodage des chaînes de caractères en question (UTF-8 est recommandé mais la documentation dit clairement que rien n’est fait pour l’imposer).
Tu auras une API stable pour accéder aux messages, mais pas pour exploiter leur contenu. Si un programme change le format de ses messages (que ceux-ci soit structurés ou non), tu devras toujours t’y adapter. systemd-journald ne résoudra pas automagiquement ce problème qui est totalement hors de sa portée, c’est entièrement dépendant des développeurs des programmes qui écriront dans le journal. Comme avec syslog en fait.
[^] # Re: Juste une question
Posté par gouttegd . En réponse au journal Systemd va gagner une console système, un bootsplash et un login-screen. Évalué à 3.
Vérification faite (directement depuis l’archive source de systemd-208), c’est le cas : c’est l’unité « rc-local.service », qui exécute par défaut
/etc/rc.local(modifiable par--with-rc-local-script-path-startlors de la configuration de systemd).[^] # Re: Juste une question
Posté par gouttegd . En réponse au journal Systemd va gagner une console système, un bootsplash et un login-screen. Évalué à 3. Dernière modification le 02 décembre 2013 à 15:14.
Sous Slackware (mais ça doit être adaptable facilement sous une autre distribution), je ferais ça d’abord en ajoutant le code suivant dans
/etc/rc.d/rc.local:Le script
/etc/rc.d/rc.localest exécuté à la fin de la séquence de démarrage (sous Slackware, il est vide par défaut — il est précisément conçu pour que l’administrateur puisse y rassembler ses bidouillages) ; ici, il exécute le programme demandé et stocke le résultat (sous une forme sourçable par un shell, c’est-à-direnom=valeur) dans un fichier quelque part dans/var.Ensuite, dans
/etc/profile, ou dans un fichier quelconque dans/etc/profile.d(ces fichiers étant sourcés lors de tout démarrage de session), on vérifie la présence du fichier/var/state/resultats, on le source, et on exporte la variable dans l’environnement :(La variable n’est pas accessible depuis tout le système — en particulier, tous les processus démarrés dans les scripts d’init en ignoreront toujours l’existence —, mais elle sera accessible à tous les programmes démarrés depuis une session utilisateur.)
La présence de systemd (ou d’un autre système d’init non-classique) ne devrait pas changer grand’chose, dès lors qu’on peut insérer un bout de script shell quelque part à une étape du démarrage. Avec systemd, j’imagine qu’il faudra créer une unit uniquement chargée d’exécuter un script dédié.
[^] # Re: C'est chimie et logique...
Posté par gouttegd . En réponse au message Pourquoi les batteries sont si sensibles au froid?. Évalué à 2. Dernière modification le 02 décembre 2013 à 09:50.
Non mais ne te fatigue pas à répondre, tout le message est juste un prétexte pour coller des liens prétendument pertinents vers "batterie chargeurs fr"… (NdM : nom du site modifié, pas la peine d'aider le spammeur)
Je suis presque sûr qu’en faisant le tour des forums consacrés de près ou de loin à l’informatique, on trouvera sur nombre d’entre eux un message similaire issu d’un compte utilisateur dont le nom est dérivé du site (comme linuxfr.org → linxfr).
Nice try.
[^] # Re: OSD = DFSG
Posté par gouttegd . En réponse au sondage Êtes vous plutôt Libre ou Open Source ?. Évalué à 2.
La FSF non plus.
Pour un logiciel, leur définition est la définition « classique » (les quatre libertés, tout ça) sur laquelle à peu près tout le monde est d’accord, éventuellement à quelques nuances de formulation près.
Pour une distribution, leur définition est explicitée dans leurs free system distributions guidelines, avec lesquelles pas grand’monde ne semble d’accord (en particuliers les développeurs de distributions).
[^] # Re: HTTPS
Posté par gouttegd . En réponse à la dépêche Du chiffrement et de la sécurité sur LinuxFr.org (statut au 24/11/2013). Évalué à 2.
Si.
En fait, le support de SNI par le client n’est même pas nécessaire, si l’on accepte que les virtual hosts partagent le même certificat et la même clef privée, ce qui est acceptable dans certains cas.¹ Il suffit de lister le nom de tous les virtual hosts dans le champ subjectAltName du certificat.
¹ Ça l’est évidemment beaucoup moins si les différents virtual hosts concernent des sites n’ayant absolument aucun rapport entre eux (comme dans un hébergement mutualisé par exemple).
[^] # Re: Scénarios
Posté par gouttegd . En réponse au journal Le moment crucial. Évalué à 7.
Justification peu convaincante. Ou bien le mot est entré dans le vocabulaire français, auquel cas il s’écrit en français aussi bien au singulier qu’au pluriel, ou bien il ne l’est pas, auquel cas le singulier comme le pluriel doivent s’écrire en italique et sans accent. Si on francise le singulier, il n’y a aucune raison d’exclure le pluriel.
D’autre part, même en italien « scenarii » est incorrect, la bonne forme est « scenari ».
« Scenari » aurait été acceptable si « scénario » n’apparaissait pas dans le même message.