Je ne connais pas cette approche. Je suppose que tu ne parles pas de logrotate mais bien de compression à la volée.
Je ne suis pas un spécialiste de syslog, mais oui les fs font ça à la volée.
N'empêche, ça freine le problème et peut-être que dans la pratique ça peut le résoudre dans l'essentiel des cas, mais je ne comprends pas qu'on ne puisse pas fixer une limite à syslog (hormis limite du système de fichier, donc partition séparée).
Tu recule véritablement le problème de plusieurs magnitudes. Ensuite la méthode classique c'est d'utiliser la rotation pour limiter la taille. Tu fais une rotation basée sur la taille ou le temps (tous les 50Mio ou tous les jours si tu veux) et de définir une période de rétention (tu garde les n dernière archives). La combinaison des 2 te permet de garder un historique important (plusieurs semaines) sans problème.
Une technique peut aussi être d'utiliser fail2ban. S'il sert normalement à empêcher des connections ssh lors de tentatives d'attaque, c'est surtout un moteur qui lit en entrée des fichiers de log pour lancer une commande si un événement est trop fréquent dans tes logs. S'en servir pour relancer ton cups, si ce dernier envoie trop de fois le message d'erreur sur un temps donné, n'a rien de compliqué.
Bien sûr ça n'est pas aussi propre que ce que tu voudrait, mais ça me paraît être une solution actionnable aujourd'hui pour toi et ta copine.
Et je suppose que ça rend la recherche dans les logs un peu plus lourde.
Non tu as les outils z* qui sont là pour ça (zgrep, zless, zcat,...). Quand c'est le système de fichier, c'est totalement transparent.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Et tu ne parles que du matériel...
Posté par barmic . En réponse au journal HP, l’informatique de trahison.. Évalué à 10.
Je ne suis pas un spécialiste de syslog, mais oui les fs font ça à la volée.
Tu recule véritablement le problème de plusieurs magnitudes. Ensuite la méthode classique c'est d'utiliser la rotation pour limiter la taille. Tu fais une rotation basée sur la taille ou le temps (tous les 50Mio ou tous les jours si tu veux) et de définir une période de rétention (tu garde les n dernière archives). La combinaison des 2 te permet de garder un historique important (plusieurs semaines) sans problème.
Une technique peut aussi être d'utiliser fail2ban. S'il sert normalement à empêcher des connections ssh lors de tentatives d'attaque, c'est surtout un moteur qui lit en entrée des fichiers de log pour lancer une commande si un événement est trop fréquent dans tes logs. S'en servir pour relancer ton cups, si ce dernier envoie trop de fois le message d'erreur sur un temps donné, n'a rien de compliqué.
Bien sûr ça n'est pas aussi propre que ce que tu voudrait, mais ça me paraît être une solution actionnable aujourd'hui pour toi et ta copine.
Non tu as les outils z* qui sont là pour ça (zgrep, zless, zcat,...). Quand c'est le système de fichier, c'est totalement transparent.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)