[logwatch/dovecot]lignes sieve non analysées

DjKlaus · Février 21, 2016, 1:31pm

Bonjour,

J’ai mis logwatch sur un serveur de messagerie utilisant postfix/dovecot/sieve sur une squeeze. La distribution est assurée par sieve pour profiter des règles de filtrage. Les gentils utilisateurs peuvent tout configurer depuis le webmail.
Par contre logwatch me sort des “unmatched entries” pour chaque mail distribué. Ceci est “un peu” pénible dans la mesure où :

c’est un analyseur de log
le trafic n’est pas anodin et je n’aime pas lire un roman des 20000 lignes tous les matins.
Les lignes sont du genre :

Il s’agit d’un bug référencé bugs.debian.org/cgi-bin/bugreport.cgi?bug=571163
En suivant la discussion du rapport de bug j’ai vu que quelqu’un a fait un patch d’une part et qu’un correctif est mis en place sur la version suivante (qui apporte un lot de régressions et d’autres bugs et qui n’est pas dans squeeze).

Est-ce que quelqu’un a essayé le patch ou a rétroporté une version ultérieure ou s’est fait son patch perso ?
Ce sont les 3 options que j’envisage. En fait non, il y en a une quatrième mais je n’en parlerai pas.

syam · Février 21, 2016, 1:31pm

La partie dovecot de logwatch m’a fait des siennes aussi. Pas exactement la même chose que toi par contre.
Mon patch perso pour la version Squeeze :

[code]— /usr/share/logwatch/scripts/services/dovecot 2011-03-04 07:55:02.000000000 +0000
+++ /usr/share/logwatch/scripts/services/dovecot 2012-05-24 13:28:40.242563657 +0000
@@ -104,6 +104,12 @@
$ThisLine =~ s/^\w{3} .\d \d\d:\d\d:\d\d [^ ]* //;
if ($ThisLine =~ /ssl-build-param: SSL parameters regeneration completed/) {
# We don’t care about these

} elsif ($ThisLine =~ /^dovecot: deliver\(.*\): msgid=.*: saved mail to INBOX/) {

```
  # We don't care about these
```

} elsif ($ThisLine =~ /^dovecot: auth-worker\(default\): mysql: Connected to 127\.0\.0\.1 \(postfix\)/) {

```
  # We don't care about these
```

} elsif ($ThisLine =~ /^dovecot: imap-login: Disconnected \(auth failed, [0-9]+ attempts\): user=<.*>, method=PLAIN, rip=.*, lip=.*, (secured|TLS)/) {

  # We don't care about these
} elsif ( $ThisLine =~ /Killed with signal /) {
    $End++;
} elsif ( $ThisLine =~ /Dovecot (v\d[^ ]* |)starting up$/) {[/code]

Je crois que t’es capable d’écrire une regex en Perl pour ta ligne particulière, comme tu vois les modifs sont simples à faire. Si ce n’est pas le cas dis-le et je le ferai.
Pense juste à sauvegarder l’original pour pouvoir faire un diff ensuite, que tu réappliqueras automatiquement après chaque mise à jour (hook Dpkg::Post-Invoke, patch -N).

DjKlaus · Février 21, 2016, 1:31pm

Merci de ta réponse.
En effet, l’écriture du patch ne me fait pas spécialement peur, j’ai déjà regardé et je n’en ai pas pour longtemps, l’empaquetage est simple en plus. C’est juste que j’aime bien utiliser des solutions “officielles” quand c’est possible, surtout sur serveur et encore plus sur serveur de messagerie. Ca m’évite de gérer un paquet perso et d’assurer un suivi avec les maj.
Bon logwatch n’est pas mis à jour tous les 4 matins donc je devrais tolérer cette infraction à mon règlement.
Je vais essayer d’empaqueter ça ce w-e. Par contre si d’autres maintiennent aussi des patches c’est peut-être l’occasion de mettre tout ça en commun.
Est-ce que vous avez un dépôt debian-fr.org ? J’ai vu qu’il existait un wiki mais rien sur un dépôt.

syam · Février 21, 2016, 1:31pm

Note bien que je ne parlais pas d’empaquetage et tout le tralala, mais bien d’un patch local, réappliqué automatiquement à chaque mise à jour (je me sers de plus en plus des hooks Dpkg::*-Invoke, c’est très pratique pour faire ce genre de choses).

Sur le serveur en question :

[code]# cat /etc/apt/apt.conf.d/99apt-wrapper-hooks
DPkg {
Pre-Invoke { “/opt/sbin/apt-wrapper-hooks pre-invoke”; };
Post-Invoke { “/opt/sbin/apt-wrapper-hooks post-invoke; true”; };
};

cat /opt/sbin/apt-wrapper-hooks

#!/bin/sh
case “$1” in
pre-invoke)
# des trucs…
;;
post-invoke)
# des trucs…
patch -N -r - /usr/share/logwatch/scripts/services/dovecot /root/upgrades/logwatch/dovecot.diff
;;
esac[/code]
En d’autres termes, après chaque mise à jour il essaye de réappliquer le patch. L’option -N force le sens du patch (si il est déjà appliqué il ne va pas te demander si tu veux l’inverser). Résultat des courses : logwatch peut être mis à jour tant qu’il veut, si le fichier /usr/share/logwatch/scripts/services/dovecot change il sera à nouveau patché immédiatement et (le plus important) sans intervention de ma part. Au pire des cas s’il y a un conflit ça s’affichera à l’écran et je pourrai le résoudre manuellement (et mettre mon diff à jour pour la prochaine fois).

D’accord c’est moins propre que de réempaquetter, mais tu conviendras quand même que c’est beaucoup moins lourd à mettre en place et à maintenir.

Je comprends bien, je réagis pareil. Mais quand les solutions “officielles” ne sont pas disponibles (comme c’est le cas ici), je vais tout simplement au plus pratique sans m’embarrasser avec des “détails” comme le réempaquetage.
Enfin bien sûr ce genre de bricolage “rapide et sale” n’est faisable que sur les scripts, si c’est du code à compiler tout de suite cette méthode pose problème.

DjKlaus · Février 21, 2016, 1:31pm

Oui mais je n’utilise pas cette méthode, même sur mes machines perso. Je préfère gérer mes spécifiques dans les paquets source pour des raisons évidentes de facilité de déploiement et diffusion. De plus appliquer un patch sur un script en prod reste dangereux en cas de zouille, on doit traiter les erreurs à chaque application, à chaque maj sur toutes les machines. La gestion par paquet permet d’anticiper tout ça pour le prix d’un maintien de dépôt.

Au fait pas de dépôt debian-fr alors ?

syam · Février 21, 2016, 1:31pm

Ces raisons ne sont pas du tout évidentes pour moi. Mes scripts de déploiement sont rustiques, je te l’accorde, mais ils fonctionnent très bien.

Peu importe la manière dont tu gères tes patchs, et d’ailleurs même si tu n’as aucun patch à appliquer, on est pas censés faire une quelconque modif en prod avant de l’avoir validée en pré-prod (des VM dans mon cas), ça serait du suicide autrement.
D’accord je ne fais pas toujours tout de manière “propre”, mais je ne suis quand même pas assez malade pour court-circuiter les tests avant mise en prod.

Enfin, ma manière de faire tient sûrement au fait que je suis développeur et non pas admin de profession, pour moi un script restera toujours plus compréhensible qu’un tas de paquets avec des infos éparpillées dans tous les sens.
L’essentiel étant que ça marche et que les serveurs restent stables et disponibles.

DjKlaus · Février 21, 2016, 1:31pm

On a tous nos méthodes de toute façon. L’essentiel étant de garder l’esprit critique.
Je collerai mon patch sur ce fil avant de passer en résolu.
Merci pour tes interventions toujours très pertinentes.

Edition :
Ci-joint un patch minimal pour traiter les lignes “dovecot: deliver(address): sieve:”. Elles sont juste comptées.

--- dovecot    2012-10-18 20:41:51.000000000 +0200
+++ dovecot    2012-10-18 21:45:00.000000000 +0200
@@ -139,6 +139,8 @@
          $ConnectionIMAP{$Host}++;
          $Connection{$Host}++;
        }
+   } elsif ($ThisLine =~ /^dovecot: deliver\(.*\): sieve:/) {
+         $Deliver++;
 
    } elsif ($ThisLine =~ /Disconnected \[/) {
       $Disconnected{"no reason"}++;
@@ -304,6 +306,10 @@
    print "\n\nTLS Initialization failed $TLSInitFail Time(s)";
 }
 
+if ($Deliver > 0) {
+   print "\n\nDelivered by sieve service (from patch) :\n  $Deliver messages";
+}
+
 if (keys %OtherList) {
    print "\n\n**Unmatched Entries**\n";
    foreach $line (sort {$a cmp $b} keys %OtherList) {

Pour déploiement je me prépare un paquet perso qui traite le destinataire et le répertoire où est déposé le message. Si quelqu’un est intéressé qu’il le fasse savoir.