mais toutes ces informations sont enregistrées d’une façon
cohérente dans tous les fichiers de logs et sont parsables sans
surprise).
Sans surprise, autre que "j'ai changé la langue du systeme et le timestamp a changé". Et sans surprise autre que "j'ai des entrées multilignes dans les logs et ça peut foutre la zone dans mes scripts" ? Ou sans surprise autre que "c'est relou de faire des calculs sur les dates comme trouver tout depuis 1h30" quand tu regardes pour des infos à partir de 1h15 du mat ?
Je sais pas si j'ai vraiment la poisse ou si j'ai juste gardé mon ame d'enfant, mais ça, j'appelle ça des surprises. Des trucs auquel tu penses pas sur le coup, mais dés qu'il faut s'y mettre "surprise".
Les programmes qui se chargent eux-mêmes de leurs propres logs
(souvent avec leur propre format) au lieu de passer par le
démon de journalisation du système poseront toujours problème,
Comme tu le dit, l'interface de syslog, c'est d'ouvrir /dev/log, d'écrire dedans., c'est "tu files une ligne + la priorité" ( man 3 syslog ).
L'interface de journald, c'est soit tu utilises la même chose que syslog ( sd_journal_print ), soit tu utilises sd_journal_send ou tu passes des couples clés/valeurs.
Donc à partir de la, si mod_security veut du clé valeur, soit ils vont faire comme maintenant, cad écrire du structuré que personne ne va lire facilement ( en l'occurence, ça passe via les logs standards d'apache, c'est pas lui qui va écrire ), et qui va arriver avec le reste dans un fichier texte avec un bon mix.
Soit utiliser journald, ou la même chose va arriver, mais ou le filtrage du mix est builtin, pour peu que mod_security fasse ce qu'il faut.
Tu dis que personne ne se sert de l'envoi de messages structurés alors qu'on pouvait depuis longtemps. Mais c'est exactement ce que mod_security fait, et c'est la plaie, parce que justement, il fait ce que les autres ne font pas, cad envoyer du structuré et qu'il faut quelque chose pour s'en occuper.
Et c'est parce que c'est la plaie de faire ça avec la machinerie de syslog que personne le fait. Et ça n'a pas pris pour des questions de poule et d'oeuf.
Personne ou presque ne s'en sert parce qu'aucun format/lib/systéme n'a pris. Et donc aucune interface de recherche n'a été adopté par les gens en standard au delà de grep. Comme tout les trucs qui proposent ça sont lourd ( splunk/elk/graylog ), seul les gros groupes déploient ça, donc pas de standard, donc rien ne prends. Et Journald, qui fait ça de façon plus simple pour l'admin, a changé ce cycle de 2 façons.
Primo, en rajoutant l'information de structure sans demander au programme. Tu as l'unité, le pid, etc, etc. Et de façon uniforme sur tout les daemons juste en se mettant au bon endroit. Quelqu'un qui aurait voulu mettre l'info dispo aurait juste eu à coder le support dans rsyslog et à mettre une configuration par defaut. Mais à la place, l'approche des gens, c'était "on va mettre ça sur chaque daemon", ce qui visiblement n'a pas pris.
Les utilisateurs ont un souci, ils vont voir l'upstream. l'upstream va juste penser à influencer son soft, pas l'ecosystéme autour, et on arrive à la situation plus haut.
Secondo, une fois que l'information était la, il suffisait juste de rajouter une interface pour l'utiliser ( journalctl, en l'occurrence ). Et une fois que tu commences à utiliser l'info, tu continues.
Bien sur, ça aurait pu être fait avant et sans journald, qui n'a rien de magique à ce niveau ( aprés tout, Windows NT le fait depuis un bout de temps ). Mais comme maintenant, c'est en place, ça commence à être adopté.
[^] # Re: Pour toi?
Posté par Misc (site web personnel) . En réponse au journal Vivent les journaux binaires !. Évalué à 8.
Sans surprise, autre que "j'ai changé la langue du systeme et le timestamp a changé". Et sans surprise autre que "j'ai des entrées multilignes dans les logs et ça peut foutre la zone dans mes scripts" ? Ou sans surprise autre que "c'est relou de faire des calculs sur les dates comme trouver tout depuis 1h30" quand tu regardes pour des infos à partir de 1h15 du mat ?
Je sais pas si j'ai vraiment la poisse ou si j'ai juste gardé mon ame d'enfant, mais ça, j'appelle ça des surprises. Des trucs auquel tu penses pas sur le coup, mais dés qu'il faut s'y mettre "surprise".
Comme tu le dit, l'interface de syslog, c'est d'ouvrir /dev/log, d'écrire dedans., c'est "tu files une ligne + la priorité" ( man 3 syslog ).
L'interface de journald, c'est soit tu utilises la même chose que syslog ( sd_journal_print ), soit tu utilises sd_journal_send ou tu passes des couples clés/valeurs.
Donc à partir de la, si mod_security veut du clé valeur, soit ils vont faire comme maintenant, cad écrire du structuré que personne ne va lire facilement ( en l'occurence, ça passe via les logs standards d'apache, c'est pas lui qui va écrire ), et qui va arriver avec le reste dans un fichier texte avec un bon mix.
Soit utiliser journald, ou la même chose va arriver, mais ou le filtrage du mix est builtin, pour peu que mod_security fasse ce qu'il faut.
Tu dis que personne ne se sert de l'envoi de messages structurés alors qu'on pouvait depuis longtemps. Mais c'est exactement ce que mod_security fait, et c'est la plaie, parce que justement, il fait ce que les autres ne font pas, cad envoyer du structuré et qu'il faut quelque chose pour s'en occuper.
Et c'est parce que c'est la plaie de faire ça avec la machinerie de syslog que personne le fait. Et ça n'a pas pris pour des questions de poule et d'oeuf.
Personne ou presque ne s'en sert parce qu'aucun format/lib/systéme n'a pris. Et donc aucune interface de recherche n'a été adopté par les gens en standard au delà de grep. Comme tout les trucs qui proposent ça sont lourd ( splunk/elk/graylog ), seul les gros groupes déploient ça, donc pas de standard, donc rien ne prends. Et Journald, qui fait ça de façon plus simple pour l'admin, a changé ce cycle de 2 façons.
Primo, en rajoutant l'information de structure sans demander au programme. Tu as l'unité, le pid, etc, etc. Et de façon uniforme sur tout les daemons juste en se mettant au bon endroit. Quelqu'un qui aurait voulu mettre l'info dispo aurait juste eu à coder le support dans rsyslog et à mettre une configuration par defaut. Mais à la place, l'approche des gens, c'était "on va mettre ça sur chaque daemon", ce qui visiblement n'a pas pris.
Les utilisateurs ont un souci, ils vont voir l'upstream. l'upstream va juste penser à influencer son soft, pas l'ecosystéme autour, et on arrive à la situation plus haut.
Secondo, une fois que l'information était la, il suffisait juste de rajouter une interface pour l'utiliser ( journalctl, en l'occurrence ). Et une fois que tu commences à utiliser l'info, tu continues.
Bien sur, ça aurait pu être fait avant et sans journald, qui n'a rien de magique à ce niveau ( aprés tout, Windows NT le fait depuis un bout de temps ). Mais comme maintenant, c'est en place, ça commence à être adopté.
Exemple, apache propose ça :
https://httpd.apache.org/docs/trunk/mod/mod_journald.html
Pareil pour cupsd ( https://fedoraproject.org/wiki/Changes/CupsJournalLogging )
Y a pas besoin que les gens s'y mettent, suffit juste d'avoir une configuration par défaut dans une distribution, et que ça soit intégré.