Posté par lym .
En réponse à la dépêche Systemd v256.
Évalué à 2.
Question d'habitude... Le hasard veut que j'ai réinstallé from scracth ma domotique sur un PI en Debian Bookworm ce WE. J'ai pourtant upgradé qq PC sur l'année passée et j'étais passé au travers (en upgrade, on garde rsyslog et sa config) d'un léger changement sur le sujet!
Et, bien entendu, comme j'ai voulu faire plus clean sur des trucs en python avec des venv sur un python embarqué par l'appli domotique (je ne savais pas que dans ce cadre, c'était la merde comparé à l'interpréteur, voilà qui ne va pas améliorer mon opinion générale sur python: Pratique/riche de modules quand on veut aller vite, mais bannir les choses sérieuses!) utilisant les libpython3 et libpython3-dev du système... Et gros crash sur un truc headless, même pas le temps de se connecter en ssh en étant rapide.
Quelle ne fut pas ma surprise de voir un /var/log vide, en tentant de l'utiliser en post-mortem carte uSD extraite. Comme j'ai tripatouillé des settings de management de mémoire virtuelle pour moins taper la carte SD (temps de commit/regroupements écriture/%cache), au départ j'ai cru que ça se gaufrait avant d'avoir pu écrire mais y'avait même pas les logs de mes ajouts après avoir collé l'image lite!
Bref, systemd est devenu le défaut pour les logs sur bookworm...
Je crois donc qu'il va falloir que je m'y mette mais bon, comme tout le monde, quand j'ai un truc bien câblé dans mon cerveau reptilien je trouve cela pénible. Ils semblent au moins avoir prévu d'utiliser un racine alternative (comme un point de montage, en post-mortem!) à donner à journalctl. En espérant qu'il n'y ait jamais d'incompatibilité de format qui pourraient dans ce cadre faire regretter amèrement des fichiers texte qu'on saura toujours lire sans s'emmerder.
Je dois dire que les fonctionnalités intégrées pour les recherches semblent intéressantes et sans doute plus efficaces/rapides. Mais la combinaison d'utilitaires génériques d'affichage/tri etc n'était pas propre à systemd et donc utilisables sans apprentissage spécifique.
Je ne sais pas trop comment va se comporter un fail2ban et autres outils basés logs textes non plus.
[^] # Re: osctl
Posté par lym . En réponse à la dépêche Systemd v256. Évalué à 2.
Question d'habitude... Le hasard veut que j'ai réinstallé from scracth ma domotique sur un PI en Debian Bookworm ce WE. J'ai pourtant upgradé qq PC sur l'année passée et j'étais passé au travers (en upgrade, on garde rsyslog et sa config) d'un léger changement sur le sujet!
Et, bien entendu, comme j'ai voulu faire plus clean sur des trucs en python avec des venv sur un python embarqué par l'appli domotique (je ne savais pas que dans ce cadre, c'était la merde comparé à l'interpréteur, voilà qui ne va pas améliorer mon opinion générale sur python: Pratique/riche de modules quand on veut aller vite, mais bannir les choses sérieuses!) utilisant les libpython3 et libpython3-dev du système... Et gros crash sur un truc headless, même pas le temps de se connecter en ssh en étant rapide.
Quelle ne fut pas ma surprise de voir un /var/log vide, en tentant de l'utiliser en post-mortem carte uSD extraite. Comme j'ai tripatouillé des settings de management de mémoire virtuelle pour moins taper la carte SD (temps de commit/regroupements écriture/%cache), au départ j'ai cru que ça se gaufrait avant d'avoir pu écrire mais y'avait même pas les logs de mes ajouts après avoir collé l'image lite!
Bref, systemd est devenu le défaut pour les logs sur bookworm...
Je crois donc qu'il va falloir que je m'y mette mais bon, comme tout le monde, quand j'ai un truc bien câblé dans mon cerveau reptilien je trouve cela pénible. Ils semblent au moins avoir prévu d'utiliser un racine alternative (comme un point de montage, en post-mortem!) à donner à journalctl. En espérant qu'il n'y ait jamais d'incompatibilité de format qui pourraient dans ce cadre faire regretter amèrement des fichiers texte qu'on saura toujours lire sans s'emmerder.
Je dois dire que les fonctionnalités intégrées pour les recherches semblent intéressantes et sans doute plus efficaces/rapides. Mais la combinaison d'utilitaires génériques d'affichage/tri etc n'était pas propre à systemd et donc utilisables sans apprentissage spécifique.
Je ne sais pas trop comment va se comporter un fail2ban et autres outils basés logs textes non plus.