gérer des fichiers log

Salut,

Thomas a tapoté le 05/07/2021 21:41:

j'ai des logs Í  gérer, et j'aimerais mieux ne pas les effacer quand j'ai
besoin de place pour un nouveau fichier.

Tu peux déjÍ  envoyer les logs vers un serveur syslog qui les centralise
et donc sur les serveurs o͹ tu as besoin de place tu écris des règles
logrotate plus strictes.

<https://homputersecurity.com/2018/03/01/comment-mettre-en-place-un-serveur-syslog/>

--
Stéphane

In article <sc11ll$tqp8$1@pasdenom.info>, yamo' <yamo@beurdin.invalid>
wrote:

Salut,

Thomas a tapoté le 05/07/2021 21:41:

> j'ai des logs Í  gérer, et j'aimerais mieux ne pas les effacer quand j'ai
> besoin de place pour un nouveau fichier.


Tu peux déjÍ  envoyer les logs vers un serveur syslog qui les centralise
et donc sur les serveurs o͹ tu as besoin de place tu écris des règles
logrotate plus strictes.

<https://homputersecurity.com/2018/03/01/comment-mettre-en-place-un-serveur-sy
slog/>

non, désolé, c'est trop avancé pour moi, entre autres parce que je crois
n'avoir actuellement aucun usager pour l'instant
(et pour cause, malgré son état officiel, le logiciel est buggé)


j'en suis lÍ  :
http://svn.savannah.gnu.org/viewvc/rapid/branches/gtkada-2.24/src/tki/mcc
_tki/mcc-msg.ads?revision"4&view=markup ( https://urlpetite.fr/5j2 )

et quand on a besoin de place, les *-previous.log sont supprimés.

c'est pour ça que le principe de la numérotation m'intéresse bcp

mais tant qu'Í  améliorer les choses, autant suivre la norme s'il y en a
une
(par ex ".log" comme extension, d'ailleurs ça n'est pas tjr respecté au
niveau du système !)
(par ex, doit on mettre un "." pour séparer le chiffre, ou est ce qu'un
"-" ne dérangera personne ?)

--
RAPID maintainer
http://savannah.nongnu.org/projects/rapid/

Thomas , dans le message
<fantome.forums.tDeContes-AD48E3.21414905072021@news.free.fr>, a écrit :

est ce que c'est qqch de plus ou moins normalisé, ou est ce qu'on fait
vraiment ce qu'on veut ?

Les distributions font un peu toutes la même chose, mais c'est assez naze,
et au final tu fais comme tu veux.

1
j'aime bcp l'idée d'avoir un n° que je peux incrementer jusqu'Í 
l'infini, pas de limite supérieure :-)

Oui, c'est très bien. Mais tant qu'Í  faire, puisque les entiers naturels ne
sont pas une ressource rare, autant en choisir des parlants en plus. Donc
les logs d'hier iraient bien dans un fichier numéroté 20210706.

Attention, si ta numérotation est sur un nombre variable de chiffres, alors
10 va se retrouver entre 1 et 2 dans les listes.

le gros pb, c'est que ça ajoute le n° après l'extension plutÍ´t qu'avant.
du coup, mon éditeur de texte croit avoir affaire Í  des pages de man
plutÍ´t qu'Í  des logs !

quel genre de pb ça peut poser si je décide de faire différemment ?

Les logiciels que tu pourras installer pour analyser tes logs risquent
d'être configurés pour la disposition par défaut, donc il faudra les
configurer aussi de la même manière. Rien de plus grave.

et pendant que j'y suis, pourquoi ne pas corriger ça au niveau du
système ?

Comment ne pas le faire ?

Sur la machine o͹ on a des logs importants, on a choisi syslog-ng (les
logiciels qui ont «Â NG » dans leur nom sont souvent bons, pour des raisons
évidentes), on a configuré pour que les logs arrivent dans
/var/log/byday/$YYYYMMDD/, avec une crontab pour générer un lien .current ->
20210706 et des liens pour que les fichiers du jour apparaissent Í  leur
place habituelle. Ça marche très bien.

Si tu as moins de logs, tu peux faire par mois plutÍ´t que par jour. Ou
utiliser %G%V pour faire par semaine, mais les numéros de semaines sont
moins parlants.

apparemment, quand on a besoin de place, on décale tous les fichiers
d'un cran.

si Í  la place je met juste le dernier n° (le 1er dispo) au fichier qui
n'en a pas encore, sans toucher aux autres, qu'est ce que vous en dites ?

Cf. mes conseils plus haut. Ce que tu décris, c'est ce que fait logrotate,
le mécanisme historique, avec tous les défauts d'un mécanisme historique.

In article <60e454f4$0$6191$426a74cc@news.free.fr>,
Nicolas George <nicolas$george@salle-s.org> wrote:

Thomas , dans le message
<fantome.forums.tDeContes-AD48E3.21414905072021@news.free.fr>, a écrit :

j'ai des logs Í  gérer, et j'aimerais mieux ne pas les effacer quand
j'ai besoin de place pour un nouveau fichier.

je crois bon de préciser que je ne parle pas d'administration système,
mais d'un logiciel autonome

est ce que je ne devrais pas tenter de faire gérer les logs par le
logiciel, mais seulement de les placer au bon endroit, et le système
s'en charge automatiquement avec un outil du genre logrotate qui serais
activé par défaut sur les distributions courantes ?

> est ce que c'est qqch de plus ou moins normalisé, ou est ce qu'on fait
> vraiment ce qu'on veut ?

Les distributions font un peu toutes la même chose, mais c'est assez naze,
et au final tu fais comme tu veux.

je me demande pourquoi ceux qui ont "le pouvoir" sur ces distributions
ne font pas le nécessaire ...

> 1
> j'aime bcp l'idée d'avoir un n° que je peux incrementer jusqu'Í 
> l'infini, pas de limite supérieure :-)

Oui, c'est très bien. Mais tant qu'Í  faire, puisque les entiers naturels ne
sont pas une ressource rare, autant en choisir des parlants en plus. Donc
les logs d'hier iraient bien dans un fichier numéroté 20210706.

actuellement, pour éviter d'avoir des fichiers de logs dont la taille va
jusqu'Í  l'infini, la politique que j'applique est de les initialiser Í 
chaque démarrage du logiciel.
du coup, ce que tu proposes ne va pas marcher ...

sauf que, je viens de penser, on peut combiner les 2 ... 2021-07-06.1

(pour la lisibilité, profitons en pour utiliser le format de date
standard)

Attention, si ta numérotation est sur un nombre variable de chiffres, alors
10 va se retrouver entre 1 et 2 dans les listes.

ça dépend du gestionnaire de fichiers qu'on utilise :
certains reconnaissent les suites de chiffres comme des nombres, et font
le tri en conséquence (par ex Finder sur mac)

> le gros pb, c'est que ça ajoute le n° après l'extension plutÍ´t qu'avant.
> du coup, mon éditeur de texte croit avoir affaire Í  des pages de man
> plutÍ´t qu'Í  des logs !
>
> quel genre de pb ça peut poser si je décide de faire différemment ?

Les logiciels que tu pourras installer pour analyser tes logs risquent
d'être configurés pour la disposition par défaut, donc il faudra les
configurer aussi de la même manière. Rien de plus grave.

ok

> et pendant que j'y suis, pourquoi ne pas corriger ça au niveau du
> système ?

Comment ne pas le faire ?

Sur la machine o͹ on a des logs importants, on a choisi syslog-ng (les
logiciels qui ont «Â NG » dans leur nom sont souvent bons, pour des raisons
évidentes),

"bons" c'est relatif (et ça vaut jusqu'Í  ce que «Â NG » signifie
"aNcienne Génération ;-) ),
mais veux tu simplement dire que les logiciels qui ont «Â NG » sont
logiquement "meilleurs" que ceux de la génération précédente ?

on a configuré pour que les logs arrivent dans
/var/log/byday/$YYYYMMDD/, avec une crontab pour générer un lien .current ->
20210706 et des liens pour que les fichiers du jour apparaissent Í  leur
place habituelle. Ça marche très bien.

si je te comprend bien, les logiciels déposent leurs logs Í  l'endroit
habituel,
et tu les fait pointer vers byday/$YYYYMMDD/ par un montage Í  base de
liens symboliques,
de cette façon les logiciels n'ont besoin d'aucune configuration
particulière individuellement ?

> apparemment, quand on a besoin de place, on décale tous les fichiers
> d'un cran.
>
> si Í  la place je met juste le dernier n° (le 1er dispo) au fichier qui
> n'en a pas encore, sans toucher aux autres, qu'est ce que vous en dites ?

Cf. mes conseils plus haut. Ce que tu décris, c'est ce que fait logrotate,
le mécanisme historique, avec tous les défauts d'un mécanisme historique.

vu le paragraphe précédent, je suppose que tu croyais que je parlais
d'administration système.
donc j'attend de voir si tu maintiens ta réponse ou si tu la changes,
avec le contexte précisé.

je crois comprendre que "ce que fait logrotate" c'est "on décale tous
les fichiers d'un cran", et que tu ne l'approuves pas.

mais pour le reste, je ne sais pas ce que mon logiciel est censé faire,
pour être "bien inséré dans son système"

--
RAPID maintainer
http://savannah.nongnu.org/projects/rapid/

Thomas , dans le message
<fantome.forums.tDeContes-BC749E.21034606072021@news.free.fr>, a écrit :

je crois bon de préciser que je ne parle pas d'administration système,
mais d'un logiciel autonome

Dans ce cas, il faudrait regarder ce les pratiques autour de ce logiciel.

est ce que je ne devrais pas tenter de faire gérer les logs par le
logiciel, mais seulement de les placer au bon endroit, et le système
s'en charge automatiquement avec un outil du genre logrotate qui serais
activé par défaut sur les distributions courantes ?

Tu peux, c'est vraiment toi qui vois.

Si c'est du Linux récent mainstream, tu auras systemd et journald, qui rend
ça beaucoup plus facile.

je me demande pourquoi ceux qui ont "le pouvoir" sur ces distributions
ne font pas le nécessaire ...

Parce que si tu demandes Í  quatre personnes tu auras cinq opinions
différentes sur ce qu'est le nécessaire. C'est facile Í  configurer.

sauf que, je viens de penser, on peut combiner les 2 ... 2021-07-06.1

Bof. Utilise un timestamp plus précis. Si ton logiciel met une seconde Í 
s'initialiser, un le timestamp de lancement peut servir Í  rendre le nom
unique.

ça dépend du gestionnaire de fichiers qu'on utilise :
certains reconnaissent les suites de chiffres comme des nombres, et font
le tri en conséquence (par ex Finder sur mac)

Beurk. Les logiciels qui essaient d'être plus intelligents que moi, cet
article résume parfaitement ce que j'en pense :

https://piece-of-a-larger-me.github.io/la_vallee_derangeante_de_l_intelligence_artificielle.html

"bons" c'est relatif (et ça vaut jusqu'Í  ce que «Â NG » signifie
"aNcienne Génération ;-) ),
mais veux tu simplement dire que les logiciels qui ont «Â NG » sont
logiquement "meilleurs" que ceux de la génération précédente ?

Regarde comment je m'appelle ;-Íž

si je te comprend bien, les logiciels déposent leurs logs Í  l'endroit
habituel,
et tu les fait pointer vers byday/$YYYYMMDD/ par un montage Í  base de
liens symboliques,
de cette façon les logiciels n'ont besoin d'aucune configuration
particulière individuellement ?

Les logiciels envoient leurs logs Í  syslog, qui est en réalité syslog-ng,
qui les envoie directement dans les répertoires datés. Les liens symboliques
ne sont lÍ  que pour que les gens qui ont l'habitude des configurations par
défaut les trouvent.

je crois comprendre que "ce que fait logrotate" c'est "on décale tous
les fichiers d'un cran", et que tu ne l'approuves pas.

C'est assez moche comme fonctionnement, on ne voit pas du tout dans le nom
du fichier de log Í  quelle période il correspond, etc.

Nicolas George <nicolas$george@salle-s.org> wrote:

C'est assez moche comme fonctionnement, on ne voit pas du tout dans le nom
du fichier de log Í  quelle période il correspond, etc.

On le voit dans l'horodatage du fichier. Est-ce nécessaire de doubler
cette information?

Marc SCHAEFER , dans le message <sc2dde$bdj$1@shakotay.alphanet.ch>, a
écrit :

On le voit dans l'horodatage du fichier. Est-ce nécessaire de doubler
cette information?

Rien n'est nécessaire.

Nicolas George <nicolas$george@salle-s.org> wrote:

On le voit dans l'horodatage du fichier. Est-ce nécessaire de doubler
cette information?

Rien n'est nécessaire.

Pour revenir Í  la question, lorsque j'ai installé suricata Í  la main
(pour avoir la dernière version du GIT) dans ma Debian, j'ai configuré
ceci:

# /etc/logrotate.d/suricata
/usr/local/SURICATA/var/log/suricata/*.log
/usr/local/SURICATA/var/log/suricata/eve.json
{
rotate 7
daily
missingok
notifempty
delaycompress
compress
postrotate
systemctl restart suricata
endscript
}

(oui, ici, la convention locale est que les applications localement
installées le sont dans /usr/local/NOM-APPLICATION, qui est un lien
symbolique Í  /usr/local/SURICATA-version, avec si nécessaire des
wrappers scripts dans /usr/local/bin, pas besoin ici).

Bien sÍ»r, comme c'est du systemd préconfiguré par Debian, il faut aussi
élargir un peu la sécurité:

#/lib/systemd/system/logrotate.service
# ajouter
ReadWritePaths=/usr/local/SURICATA/var/log/suricata

Aussi, actuellement, l'outil maison qui parse les logs de suricata et
crée de rares alertes fait ainsi:

logger -- "$alert"

Ainsi, c'est intégré au logcheck centralisé standard maison.

Après, on n'est pas du tout obligé de faire ainsi.

In article <sc3g39$igb$2@shakotay.alphanet.ch>,
Marc SCHAEFER <schaefer@alphanet.ch> wrote:

Pour revenir Í  la question, lorsque j'ai installé suricata Í  la main
dans ma Debian, j'ai configuré

si je comprend bien, tu te places du point de vue d'un administrateur,
et tu me répond en considérant que je le suis aussi ?

le pb, c'est que je ne pose pas la question du point de vue d'un
administrateur, mais du point de vue du développeur d'un logiciel
spécifique, qui essaye d'être le plus portable possible


comment le logiciel devrais faire avec les logs, pour te permettre Í  toi
administrateur d'avoir la vie la plus agréable possible si tu
l'installes un jour sur ta machine ?

(par ex : utiliser ".log" comme extension)

--
RAPID maintainer
http://savannah.nongnu.org/projects/rapid/

In article <60e4b477$0$21592$426a74cc@news.free.fr>,
Nicolas George <nicolas$george@salle-s.org> wrote:

Thomas , dans le message
<fantome.forums.tDeContes-BC749E.21034606072021@news.free.fr>, a écrit :
> je crois bon de préciser que je ne parle pas d'administration système,
> mais d'un logiciel autonome

Dans ce cas, il faudrait regarder ce les pratiques autour de ce logiciel.

quand je l'ai repris, il ne générais aucun fichier de log, il les
affichait seulement Í  l'écran.

> est ce que je ne devrais pas tenter de faire gérer les logs par le
> logiciel, mais seulement de les placer au bon endroit, et le système
> s'en charge automatiquement avec un outil du genre logrotate qui serais
> activé par défaut sur les distributions courantes ?

Tu peux, c'est vraiment toi qui vois.

Si c'est du Linux récent mainstream, tu auras systemd et journald, qui rend
ça beaucoup plus facile.

j'ai 1 contrainte dure :
pour être portable, ne pas dépendre de la présence d'un outil pour le
bon fonctionnement.

ensuite, je souhaite optimiser :
- le confort de l'usager, s'il ne dispose d'aucun autre outil pour gérer
ses logs,
- le travail que ça me fera : je voudrais quand même éviter de
réinventer la roue si d'autres font la même chose bcp mieux que moi.

> sauf que, je viens de penser, on peut combiner les 2 ... 2021-07-06.1

Bof. Utilise un timestamp plus précis. Si ton logiciel met une seconde Í 
s'initialiser, un le timestamp de lancement peut servir Í  rendre le nom
unique.

pas de pb pour l'unicité, mais justement, comme il n'y en aura pas bcp,
je trouve que ça fera bcp de chiffres ...


question sur les extensions, pour le cas o͹ je généraliserais cette
procédure pour "pousser Í  coté" un fichier existant :

comme on a des fois des extensions imbriquées, par ex .tar.gz :
est ce qu'il vaut mieux insérer les chiffres avant le 1er point du nom
du fichier, plutÍ´t qu'avant le dernier ?
ou est ce qu'il y a des cas que je ne connais pas, o͹ ça pourrait poser
des pbs ?

> ça dépend du gestionnaire de fichiers qu'on utilise :
> certains reconnaissent les suites de chiffres comme des nombres, et font
> le tri en conséquence (par ex Finder sur mac)

Beurk. Les logiciels qui essaient d'être plus intelligents que moi, cet
article résume parfaitement ce que j'en pense :

https://piece-of-a-larger-me.github.io/la_vallee_derangeante_de_l_intelligence
_artificielle.html

très intéressant :-)
et celui en lien Í  la fin, aussi !

mais en l'occurrence, les gestionnaires de fichiers qui reconnaissent
les suites de chiffres comme des nombres sont parfaitement prévisibles.

c'est seulement en tant que développeur que, ce qui est imprévisible,
c'est "quel sera le gestionnaire de fichiers de l'usager".

> "bons" c'est relatif (et ça vaut jusqu'Í  ce que «Â NG » signifie
> "aNcienne Génération ;-) ),
> mais veux tu simplement dire que les logiciels qui ont «Â NG » sont
> logiquement "meilleurs" que ceux de la génération précédente ?

Regarde comment je m'appelle ;-Íž

:-D

--
RAPID maintainer
http://savannah.nongnu.org/projects/rapid/