Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > fr.comp.os.unix > #7714 > unrolled thread

gérer des fichiers log

Back to article view | Back to fr.comp.os.unix

Contents

  gérer des fichiers log Thomas <fantome.forums.tDeContes@free.fr.invalid> - 2021-07-05 21:41 +0200
    Re: gérer des fichiers log yamo' <yamo@beurdin.invalid> - 2021-07-06 09:44 +0200
      Re: gérer des fichiers log Thomas <fantome.forums.tDeContes@free.fr.invalid> - 2021-07-06 14:15 +0200
      Re: gérer des fichiers log Thomas <fantome.forums.tDeContes@free.fr.invalid> - 2021-07-16 22:50 +0200
    Re: gérer des fichiers log Nicolas George <nicolas$george@salle-s.org> - 2021-07-06 13:04 +0000
      Re: gérer des fichiers log Thomas <fantome.forums.tDeContes@free.fr.invalid> - 2021-07-06 21:03 +0200
        Re: gérer des fichiers log Nicolas George <nicolas$george@salle-s.org> - 2021-07-06 19:52 +0000
          Re: gérer des fichiers log Marc SCHAEFER <schaefer@alphanet.ch> - 2021-07-06 20:11 +0000
            Re: gérer des fichiers log Nicolas George <nicolas$george@salle-s.org> - 2021-07-07 00:42 +0000
              Re: gérer des fichiers log Marc SCHAEFER <schaefer@alphanet.ch> - 2021-07-07 06:03 +0000
                Re: gérer des fichiers log Thomas <fantome.forums.tDeContes@free.fr.invalid> - 2021-07-16 23:03 +0200
                  Re: gérer des fichiers log Nicolas George <nicolas$george@salle-s.org> - 2021-07-16 21:09 +0000
                    Re: gérer des fichiers log Thomas <fantome.forums.tDeContes@free.fr.invalid> - 2021-07-17 00:32 +0200
                      Re: gérer des fichiers log Nicolas George <nicolas$george@salle-s.org> - 2021-07-17 07:45 +0000
                        Re: gérer des fichiers log Thomas <fantome.forums.tDeContes@free.fr.invalid> - 2021-07-17 22:15 +0200
                    Re: gérer des fichiers log Marc SCHAEFER <schaefer@alphanet.ch> - 2021-07-17 10:37 +0000
                  Re: gérer des fichiers log Marc SCHAEFER <schaefer@alphanet.ch> - 2021-07-17 10:36 +0000
                    Re: gérer des fichiers log Thomas <fantome.forums.tDeContes@free.fr.invalid> - 2021-07-17 20:44 +0200
                      Re: gérer des fichiers log Marc SCHAEFER <schaefer@alphanet.ch> - 2021-07-18 07:29 +0000
                        Re: gérer des fichiers log Thomas <fantome.forums.tDeContes@free.fr.invalid> - 2021-07-20 23:05 +0200
                          Re: gérer des fichiers log Marc SCHAEFER <schaefer@alphanet.ch> - 2021-07-21 06:36 +0000
                            Re: gérer des fichiers log Thomas <fantome.forums.tDeContes@free.fr.invalid> - 2021-07-23 01:58 +0200
                              Re: gérer des fichiers log Marc SCHAEFER <schaefer@alphanet.ch> - 2021-07-23 06:41 +0000
                                Re: gérer des fichiers log Thomas <fantome.forums.tDeContes@free.fr.invalid> - 2021-09-19 19:23 +0200
                                  Re: gérer des fichiers log Marc SCHAEFER <schaefer@alphanet.ch> - 2021-09-20 12:29 +0000
                                    Re: gérer des fichiers log Thomas <fantome.forums.tDeContes@free.fr.invalid> - 2021-09-24 17:40 +0200
                                      Re: gérer des fichiers log Marc SCHAEFER <schaefer@alphanet.ch> - 2021-09-24 17:21 +0000
                                        Re: gérer des fichiers log Thomas <fantome.forums.tDeContes@free.fr.invalid> - 2021-09-26 01:15 +0200
                                          Re: gérer des fichiers log Marc SCHAEFER <schaefer@alphanet.ch> - 2021-09-26 14:24 +0000
                                            Re: gérer des fichiers log Thomas <fantome.forums.tDeContes@free.fr.invalid> - 2021-09-28 22:02 +0200
                                      Re: gérer des fichiers log Stéphane CARPENTIER <sc@fiat-linux.fr> - 2021-09-24 19:12 +0000
                                        Re: gérer des fichiers log Thomas <fantome.forums.tDeContes@free.fr.invalid> - 2021-09-26 03:23 +0200
                                          Re: gérer des fichiers log Stéphane CARPENTIER <sc@fiat-linux.fr> - 2021-09-26 16:45 +0000
                                            Re: gérer des fichiers log Thomas <fantome.forums.tDeContes@free.fr.invalid> - 2021-09-27 17:33 +0200
                                              Re: gérer des fichiers log Stéphane CARPENTIER <sc@fiat-linux.fr> - 2021-10-01 16:54 +0000
                                                Re: gérer des fichiers log Thomas <fantome.forums.tDeContes@free.fr.invalid> - 2021-10-22 23:41 +0200
                                                  Re: gérer des fichiers log Thomas <fantome.forums.tDeContes@free.fr.invalid> - 2021-12-19 19:19 +0100
                                                    Re: gérer des fichiers log Thomas <fantome.forums.tDeContes@free.fr.invalid> - 2021-12-28 12:18 +0100
                                                    Re: gérer des fichiers log Stéphane CARPENTIER <sc@fiat-linux.fr> - 2021-12-28 15:56 +0000
                                                      Re: gérer des fichiers log Thomas <fantome.forums.tDeContes@free.fr.invalid> - 2022-01-02 00:54 +0100
                                            tags pour les logs Thomas <fantome.forums.tDeContes@free.fr.invalid> - 2022-09-17 01:33 +0200
          Re: gérer des fichiers log Thomas <fantome.forums.tDeContes@free.fr.invalid> - 2021-07-17 00:06 +0200
            Re: gérer des fichiers log Marc SCHAEFER <schaefer@alphanet.ch> - 2021-07-17 10:40 +0000
              Re: gérer des fichiers log Thomas <fantome.forums.tDeContes@free.fr.invalid> - 2021-07-17 18:43 +0200
                Re: gérer des fichiers log Marc SCHAEFER <schaefer@alphanet.ch> - 2021-07-18 07:30 +0000
                  Re: gérer des fichiers log Thomas <fantome.forums.tDeContes@free.fr.invalid> - 2021-07-20 21:23 +0200
                    Re: gérer des fichiers log Marc SCHAEFER <schaefer@alphanet.ch> - 2021-07-20 19:32 +0000
                      Re: gérer des fichiers log Thomas <fantome.forums.tDeContes@free.fr.invalid> - 2021-07-21 00:39 +0200
                        Re: gérer des fichiers log Marc SCHAEFER <schaefer@alphanet.ch> - 2021-07-21 06:42 +0000
                          Re: gérer des fichiers log Thomas <fantome.forums.tDeContes@free.fr.invalid> - 2021-07-22 20:41 +0200
                            Re: gérer des fichiers log Marc SCHAEFER <schaefer@alphanet.ch> - 2021-07-22 18:58 +0000
                              Re: gérer des fichiers log Stephane Tougard <stephane@unices.org> - 2021-07-22 19:25 +0000
                                Re: gérer des fichiers log Thomas <fantome.forums.tDeContes@free.fr.invalid> - 2021-07-23 03:03 +0200
                                  Re: gérer des fichiers log Stephane Tougard <stephane@unices.org> - 2021-07-23 04:07 +0000
                                    Re: gérer des fichiers log Thomas <fantome.forums.tDeContes@free.fr.invalid> - 2021-09-23 01:41 +0200
                                  Re: gérer des fichiers log Marc SCHAEFER <schaefer@alphanet.ch> - 2021-07-23 06:49 +0000
                                    Re: gérer des fichiers log Thomas <fantome.forums.tDeContes@free.fr.invalid> - 2021-09-19 21:11 +0200
                                      Re: gérer des fichiers log Marc SCHAEFER <schaefer@alphanet.ch> - 2021-09-20 12:43 +0000
                                        Re: gérer des fichiers log Thomas <fantome.forums.tDeContes@free.fr.invalid> - 2021-09-24 19:12 +0200
                                          Re: gérer des fichiers log Marc SCHAEFER <schaefer@alphanet.ch> - 2021-09-24 17:36 +0000
                                            Re: gérer des fichiers log Stéphane CARPENTIER <sc@fiat-linux.fr> - 2021-09-24 19:24 +0000
                                            Re: gérer des fichiers log Thomas <fantome.forums.tDeContes@free.fr.invalid> - 2021-09-25 23:40 +0200
                              Re: gérer des fichiers log Thomas <fantome.forums.tDeContes@free.fr.invalid> - 2021-07-23 02:32 +0200
                                Re: gérer des fichiers log Marc SCHAEFER <schaefer@alphanet.ch> - 2021-07-23 06:59 +0000
                                  Re: gérer des fichiers log Thomas <fantome.forums.tDeContes@free.fr.invalid> - 2021-09-19 19:23 +0200
                                    Re: gérer des fichiers log Marc SCHAEFER <schaefer@alphanet.ch> - 2021-09-20 12:40 +0000
                                      Re: gérer des fichiers log Thomas <fantome.forums.tDeContes@free.fr.invalid> - 2021-09-25 21:04 +0200
                                        Re: gérer des fichiers log Marc SCHAEFER <schaefer@alphanet.ch> - 2021-09-26 14:30 +0000
                                          Re: gérer des fichiers log Thomas <fantome.forums.tDeContes@free.fr.invalid> - 2021-09-27 15:32 +0200
                                            Re: gérer des fichiers log Marc SCHAEFER <schaefer@alphanet.ch> - 2021-09-27 15:44 +0000
                                          Re: gérer des fichiers log Thomas <fantome.forums.tDeContes@free.fr.invalid> - 2022-09-16 23:25 +0200
                                            Re: gérer des fichiers log Marc SCHAEFER <schaefer@alphanet.ch> - 2022-09-17 05:56 +0000
                                              Re: gérer des fichiers log Thomas <fantome.forums.tDeContes@free.fr.invalid> - 2022-09-17 15:46 +0200
                    Re: gérer des fichiers log Nicolas George <nicolas$george@salle-s.org> - 2021-07-20 20:28 +0000
                      Re: gérer des fichiers log Thomas <fantome.forums.tDeContes@free.fr.invalid> - 2021-07-20 23:33 +0200
                        Re: gérer des fichiers log Nicolas George <nicolas$george@salle-s.org> - 2021-07-21 15:31 +0000
                          Re: gérer des fichiers log Thomas <fantome.forums.tDeContes@free.fr.invalid> - 2021-07-22 17:12 +0200
                            Re: gérer des fichiers log Stéphane CARPENTIER <sc@fiat-linux.fr> - 2021-07-24 13:36 +0000
                              Re: gérer des fichiers log Nicolas George <nicolas$george@salle-s.org> - 2021-07-24 14:09 +0000
                                Re: gérer des fichiers log Thomas <fantome.forums.tDeContes@free.fr.invalid> - 2021-09-23 14:44 +0200
                                  Re: gérer des fichiers log Nicolas George <nicolas$george@salle-s.org> - 2021-09-23 12:54 +0000
                                  Re: gérer des fichiers log Thomas <fantome.forums.tDeContes@free.fr.invalid> - 2022-08-09 20:57 +0200
                              Re: gérer des fichiers log Thomas <fantome.forums.tDeContes@free.fr.invalid> - 2021-09-23 14:38 +0200
    Re: gérer des fichiers log Stephane Tougard <stephane@unices.org> - 2021-07-23 04:03 +0000
    Re: g�rer des fichiers log garkbeda43 <nospam_garkbeda43@gmail.com.invalid> - 2022-06-11 02:27 -0500
      Re: gérer des fichiers log Thomas <fantome.forums.tDeContes@free.fr.invalid> - 2022-07-30 16:42 +0200

Page 1 of 5  [1] 2 3 4 5  Next page →

#7714 — gérer des fichiers log

bonjour :-)


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


j'ai regardé ce qui se passe dans /var/log/ :

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


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


2
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 ?

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


3
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 ?

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

[toc] | [next] | [standalone]

#7716

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

[toc] | [prev] | [next] | [standalone]

#7718

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=224&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/

[toc] | [prev] | [next] | [standalone]

#7730

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.


peux tu me préciser stp quelle est l'interface entre mon logiciel et 
syslog ?
est ce que ça donne qqch de portable avec une configuration où syslog 
n'est pas installé ?

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

[toc] | [prev] | [next] | [standalone]

#7719

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.

[toc] | [prev] | [next] | [standalone]

#7720

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/

[toc] | [prev] | [next] | [standalone]

#7721

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.

[toc] | [prev] | [next] | [standalone]

#7722

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?

[toc] | [prev] | [next] | [standalone]

#7723

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.

[toc] | [prev] | [next] | [standalone]

#7724

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.

[toc] | [prev] | [next] | [standalone]

#7731

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/

[toc] | [prev] | [next] | [standalone]

#7732

Thomas , dans le message
<fantome.forums.tDeContes-815480.23034116072021@news.free.fr>, a écrit :
> 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

Ce n'était pas clair *du tout*.

> 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 ?

Tu envoies tes logs sur stdout et tu le laisse se débrouiller.

[toc] | [prev] | [next] | [standalone]

#7734

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

> Thomas , dans le message
> <fantome.forums.tDeContes-815480.23034116072021@news.free.fr>, a écrit :
> > 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
> 
> Ce n'était pas clair *du tout*.

ah ? désolé, je croyais avoir précisé ça suffisamment dans 
<fantome.forums.tDeContes-BC749E.21034606072021@news.free.fr>


> 
> > 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 ?
> 
> Tu envoies tes logs sur stdout et tu le laisse se débrouiller.

merci, tu réponds à qques unes des questions de l'autre msg, du coup :-)


ça amène les questions suivantes :


1
j'ai 2 fichiers de logs : debug et errors

est ce que j'envoie le debug sur stdout et les errors sur stderr ?


2
actuellement, les errors sont tjr loggées dans le fichier,
mais selon les circonstances elles sont soit affichées dans l'interface 
graphique, soit envoyées sur stdout.

est ce que, pour que tu puisses en faire ce que tu veux,
il faudrait que je les envoie inconditionnellement sur stdout, comme le 
fichier,
peu importe que je les affiche en plus dans l'interface graphique ou pas?


3
comme je n'ai pas ton savoir en matière de gestion des logs, j'ai eu le 
réflexe d'ajouter la création des fichiers de logs.

est ce que c'est qqch qui risque de t'embêter, en te mettant dans les 
pattes des fichiers de logs là où t'en veux pas ?

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

[toc] | [prev] | [next] | [standalone]

#7735

Thomas , dans le message
<fantome.forums.tDeContes-BC1C13.00324017072021@news.free.fr>, a écrit :
> ah ? désolé, je croyais avoir précisé ça suffisamment dans 
> <fantome.forums.tDeContes-BC749E.21034606072021@news.free.fr>

Tu as dit que c'était un logiciel autonome, pas que la question portait sur
sa conception plutôt que son utilisation.

> j'ai 2 fichiers de logs : debug et errors
> 
> est ce que j'envoie le debug sur stdout et les errors sur stderr ?

Ça dépend de certains détails. Cf. ci-dessous.

> mais selon les circonstances elles sont soit affichées dans l'interface 
> graphique, soit envoyées sur stdout.

Wait... What?!?

Si tu as une interface graphique qui a aussi des logs, tu as un énorme
problème de conception qu'il faut corriger.

[toc] | [prev] | [next] | [standalone]

#7741

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

> Thomas , dans le message
> <fantome.forums.tDeContes-BC1C13.00324017072021@news.free.fr>, a écrit :
> > ah ? désolé, je croyais avoir précisé ça suffisamment dans 
> > <fantome.forums.tDeContes-BC749E.21034606072021@news.free.fr>
> 
> Tu as dit que c'était un logiciel autonome, pas que la question portait sur
> sa conception plutôt que son utilisation.

ah, désolé, je vais essayer d'en tenir compte pour les prochaines fois

j'essaye de faire attention aux détails le plus possible (en essayant 
aussi d'avoir des limites),
avec l'idée qu'un pb pas forcément très important tout de suite, s'il 
est facile à traiter pour peu qu'on s'en occupe, sera un pb qu'on n'aura 
pas dans les pattes plus tard.

mais je n'échappe pas à un phénomène, qui est la relativité du 
référentiel définissant ce qui est évident pour chacun ... 
(faut t il faire le lien avec "ce qui est évident ne peut pas être 
expliqué" ?)
donc il y a des choses que tu as besoin que je t'indique, et je n'ai pas 
l'idée de ce besoin parce que pour moi c'est évident.


j'en profite pour préciser :

pour moi, "autonome" voulait dire que le logiciel n'est pas livré avec 
son OS autour, cad "portable" en fait (je crois)

donc chacun dois pouvoir telecharger les sources et le compiler (et 
bientôt l'installer),
et le logiciel doit à la fois pouvoir "y retrouver ses petits", et ne 
pas salir le FS hôte en mettant toutes sortes de fichiers n'importe où, 
être agréable à son utilisateur en en faisant assez mais pas trop, etc...

(est ce que pour toi ça voulait dire autre chose ?)


> 
> > j'ai 2 fichiers de logs : debug et errors
> > 
> > est ce que j'envoie le debug sur stdout et les errors sur stderr ?
> 
> Ça dépend de certains détails. Cf. ci-dessous.

ok, on va voir ça.

> 
> > mais selon les circonstances elles sont soit affichées dans l'interface 
> > graphique, soit envoyées sur stdout.
> 
> Wait... What?!?
> 
> Si tu as une interface graphique qui a aussi des logs, tu as un énorme
> problème de conception qu'il faut corriger.

mon intuition me dit que je n'ai pas d'énorme problème de conception, 
mais un énorme problème de communication avec toi ;-)

qu'as tu compris ?
que le "toolkit" que j'utilise pour l'interface graphique génère 
lui-même des logs ?

non, ce que je disais, c'est que les erreurs, au moment de leur 
traitement, peuvent être affichées dans l'interface graphique, plutôt 
qu'envoyées sur stdout.


pour préciser :

- tout ceci est un choix du mainteneur précédent, et je suis là pour 
corriger ce qui n'est pas fait dans les règles de l'art, sur vos 
indications.

- comme dit dans ma réponse à Marc, le logiciel est une application 
graphique, qui peut aussi occasionnellement être utilisée en ligne de 
commande.

- dans le cas général, il est utilisé comme une application graphique,
et les erreurs sont affichées dans l'interface graphique, dans une boite 
de dialogue avec un bouton "ok" à cliquer des qu'on a lu l'erreur.
dans ce cas là, elles sont écrites dans le fichier de log mais pas 
envoyées sur stdout.

- dans le cas où on l'utilise en ligne de commande,
les erreurs sont envoyées sur stdout.
dans ce cas là, elles sont ecrites dans le fichier de log mais pas 
affichées dans l'interface graphique.


je te propose qu'avant de revenir à mes questions, tu me dises s'il 
reste des points pas clairs quant à la description de l'état des choses 
:-)

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

[toc] | [prev] | [next] | [standalone]

#7737

Nicolas George <nicolas$george@salle-s.org> wrote:
> Tu envoies tes logs sur stdout et tu le laisse se débrouiller.

C'est aussi une option (avec les erreurs sur stderr). Ainsi
l'intégrateur n'a qu'à créer un wrapper script.

[toc] | [prev] | [next] | [standalone]

#7736

Thomas <fantome.forums.tDeContes@free.fr.invalid> wrote:
> 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 ?

Je vois deux options:

   - s'il est intégré à ma distribution (Debian), alors tu n'as rien
     de spécial à faire: cela sera le packager/intégrateur qui gérera
     ce genre de choses pour que cela soit cohérent avec les conventions
     de la distribution

   - si c'est un logiciel que je dois installer à la main (package ou
     archive tar.gz), alors, le plus simple est que le fichier README
     ou INSTALL explique l'installation et qu'un fichier
     de configuration existe et soit documenté (p.ex. avec des
     commentaires à l'intérieur) pour choisir le lieu où les logs
     sont stockés

         évidemment qu'un fichier de configuration bien documenté
         aidera le packager/intégrateur à l'intégrer dans la
         distribution

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

Le fichier de configuration pourrait p.ex. contenir:

# par défaut, stocke les logs dans le répertoire courant du
# lancement du logiciel; si vous le lancez comme daemon, il
# est recommandé de mettre ce log dans /var/log/APPLICATION/general.log
# (avec les permissions adéquates)
general_log=general.log

# similaire
error_log=error.log

Ce fichier de configuration, le plus facile, c'est de le donner en
argument au lancement du programme, plutôt que de présupposer des
choses sur l'emplacement des fichiers.  Et c'est ce fichier de
configuration qui configurera l'emplacement des journaux et, si
nécessaire, des bibliothèques, templates, binaires etc de
l'application.

[toc] | [prev] | [next] | [standalone]

#7740

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

> Thomas <fantome.forums.tDeContes@free.fr.invalid> wrote:
> > 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 ?
> 
> Je vois deux options:

je souhaite que mon logiciel soit adapté aux 2.

> 
>    - s'il est intégré à ma distribution (Debian), alors tu n'as rien
>      de spécial à faire: cela sera le packager/intégrateur qui gérera
>      ce genre de choses pour que cela soit cohérent avec les conventions
>      de la distribution

il y a quand même un minimum pour ne pas lui rendre la vie trop difficile

> 
>    - si c'est un logiciel que je dois installer à la main (package ou
>      archive tar.gz), alors, le plus simple est que le fichier README
>      ou INSTALL explique l'installation

ça serais chouette que des gens d'ici veuillent bien relire ces 
fichiers, pour vérifier si tout est compréhensible :-)

mais je prévois de les convertir en Markdown, donc ça sera surement plus 
agréable à relire pour vous si vous attendez que ça soit fait.

>      et qu'un fichier
>      de configuration existe et soit documenté (p.ex. avec des
>      commentaires à l'intérieur) pour choisir le lieu où les logs
>      sont stockés

l'architecture proposée ne me déplaît pas,
le gros pb que j'ai avec cette proposition, c'est que :
- il n'y a pas de base pour ça dans le logiciel (donc j'ai tout à créer),
- l'analyse de texte me débecte (donc si je peux l'éviter ...)

mais si je comprend bien, la proposition de Nicolas te convient ?
rien de plus simple, et en plus c'est (presque) déjà fait !

> 
>          évidemment qu'un fichier de configuration bien documenté
>          aidera le packager/intégrateur à l'intégrer dans la
>          distribution

:-)
faut il documenter la nécessité de gérer stdout et stderr ?

> 
> > (par ex : utiliser ".log" comme extension)
> 
> Le fichier de configuration pourrait p.ex. contenir:
> 
> # par défaut, stocke les logs dans le répertoire courant du
> # lancement du logiciel;

est ce que tu parles du répertoire courant (pwd), ou du répertoire 
contenant le binaire du logiciel qu'on lance ?

ce que je comptais faire, c'est :
- partir du répertoire contenant le binaire
- ajouter un sous-répertoire "log"
- vu la proposition de gérer ça majoritairement avec stdout et stderr, 
en cas d'erreur quelconque à l'écriture des logs, l'ignorer 
silencieusement, tout simplement.

> si vous le lancez comme daemon, il
> # est recommandé de mettre ce log dans /var/log/APPLICATION/general.log
> # (avec les permissions adéquates)

en principe ça ne sera jamais un daemon, puisque c'est une application 
graphique, qui peut aussi occasionnellement être utilisée en ligne de 
commande

(une autre question subsidiaire est : est ce courant, ou est ce 
recommandé de faire 2 binaires séparés pour chacun des usages ?)

> general_log=general.log
> 
> # similaire
> error_log=error.log

est ce que le general c'est le debug activé tout le temps, ou est ce que 
ce sont 2 choses différentes ?

> 
> Ce fichier de configuration, le plus facile, c'est de le donner en
> argument au lancement du programme,

est ce que c'est qqch qui marche aussi avec une application graphique ?

> plutôt que de présupposer des
> choses sur l'emplacement des fichiers.  Et c'est ce fichier de
> configuration qui configurera l'emplacement des journaux et, si
> nécessaire, des bibliothèques, templates, binaires etc de
> l'application.

c'est sur que si on fait ça, ça permet de résoudre cette série de 
questions d'un seul coup !
merci pour l'indication :-)

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

[toc] | [prev] | [next] | [standalone]

#7742

Thomas <fantome.forums.tDeContes@free.fr.invalid> wrote:
> est ce que tu parles du répertoire courant (pwd), ou du répertoire 

oui

> contenant le binaire du logiciel qu'on lance ?

non, c'est risqué / compliqué sous UNIX

[toc] | [prev] | [next] | [standalone]

#7748

In article <sd0l91$b4m$1@shakotay.alphanet.ch>,
 Marc SCHAEFER <schaefer@alphanet.ch> wrote:

> Thomas <fantome.forums.tDeContes@free.fr.invalid> wrote:
> > est ce que tu parles du répertoire courant (pwd), ou du répertoire 
> 
> oui

tu as dit "le répertoire courant du lancement du logiciel",
si je comprend bien, ça veut dire qu'il faut enregistrer l'emplacement 
du répertoire courant au démarrage, au cas où le logiciel décide d'en 
changer ensuite. (ai je bien compris ?)

en tant qu'usager, ça m'embête d'avoir à faire attention au répertoire 
courant au motif que le logiciel va mettre des choses à lui dedans   
(est ce une pratique courante ?),
il me semblait que ça servait surtout comme point de départ pour les 
fichiers lus ou générés (mais) à la demande de l'utilisateur.

en fait, quand un logiciel a des "affaires à lui" à mettre qqpart, la 
pratique ça serais pas plutôt qqch du genre "~/.config/<logiciel>/" ?


en passant, je me suis aperçu fortuitement que mon logiciel change 
effectivement de répertoire courant au cours de son exécution, puisque 
n'ayant pas fait attention à tous ces détails, je me suis retrouvé avec 
des fichiers de log un peu partout :-(

peut il y avoir un intérêt à faire ça ?
(je n'en vois aucun, pour l'instant je ne vois que les inconvénients)


> 
> > contenant le binaire du logiciel qu'on lance ?
> 
> non, c'est risqué / compliqué sous UNIX

compliqué :
je ne trouve pas tant que ça :

GNAT fournit une procédure ada toute faite, qui utilise notamment PATH 
un peu de la même manière que pathsearch dans cet exemple pour `make` :
https://www.gnu.org/software/make/manual/html_node/Call-Function.html


risqué :
peux tu préciser un peu stp ?

je proposais qu'en cas d'erreur quelconque à l'écriture des logs, 
l'erreur d'écriture soit simplement ignorée silencieusement, comptant 
sur le fait que le même contenu sera accessible via stdout et stderr.

est ce que c'est une mauvaise conception ?

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

[toc] | [prev] | [next] | [standalone]

Page 1 of 5  [1] 2 3 4 5  Next page →

Back to top | Article view | fr.comp.os.unix

csiph-web