spamassasin update

Le
Jazzoroastre
Je ne comprends pas bien qqchose :
J'ai fait une recompilation puis installation de la dernière version de
spamassasssin (3.1.8) avec un make install qui s'est bien fini, puis n
reboot : nickel.
Or quand je regarde les traces dans les sources de mes mails, je vois
toujours :

X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on .

Comment être sûr que c'est la version 3.1.8 qui tourne ?
Ou bien, si ce que je présume est que ce n'est pas elle qui tourne, comment
faire pour la faire remplacer l'ancienne.

PS j'utilise Postfix + amavisd-new + clamav + spamassassin.

Merci de votre aide.
Vidéos High-Tech et Jeu Vidéo
Téléchargements
Vos réponses Page 1 / 2
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
Mihamina Rakotomandimby (R12y)
Le #1876796
Jazzoroastre wrote:

X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on ....
Comment être sûr que c'est la version 3.1.8 qui tourne ?


Qui fait appel à spamassassin?
- PostFix?
- Procmail?
- ...

Un des problèmes de la compilation (j'entend par là ne pas utiliser les
packages) c'est justement que les autres éléments du système cherchent
spamassassin (par exemple) à un endroit bien précis, et que toi quand tu
l'a compilé, tu l'as foutu là ou tu veux.
Il y a une certaine cohésion qui est apportée par le fait qu'on reste sous
le gestionnaire de package. Quand le gesiotnnaire de package est bon...
Le système pourrait aussi scanner les répertoires probables ou peut se
trouver SA, mais dans ton cas, il ne l'a pas fait.

patpro ~ Patrick Proniewski
Le #1876795
In article "Mihamina Rakotomandimby (R12y)"
Jazzoroastre wrote:

X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on ....
Comment être sûr que c'est la version 3.1.8 qui tourne ?


Qui fait appel à spamassassin?
- PostFix?
- Procmail?
- ...


dans un montage classic amavisd-new/SA/clamav, c'est amavisd-new qui
utilise la librairie PERL SpamAssassin.

Je soupçonne que la lib utilisée par amavis n'est pas installée au même
endroit que le produit de l'installation de la nouvelle version.

patpro

--
http://www.patpro.net/


Jazzoroastre
Le #1876793
Je soupçonne que la lib utilisée par amavis n'est pas installée au même
endroit que le produit de l'installation de la nouvelle version.

patpro


Ok resolu en desinstallant l'ancien paquet avec apt-get remove puis
resintallant le nouveau spamassassin par make install.
Merci à tous.

Sébastien Kirche
Le #1876790
Le 2 mars 2007 à 18:31, Jazzoroastre a formulé :

Ok resolu en desinstallant l'ancien paquet avec apt-get remove puis
resintallant le nouveau spamassassin par make install.


Sauf que maintenant apt n'est pas au courant que tu as spamassassin et
ça peut être source d'emmerdes.

Tu n'as plus les dépendances nécessaires à certaines applis que tu
pourrais vouloir installer (apt-cache rdepends spamassassin pour savoir
lesquelles et il y en a) et si tu les installes, apt te remettra le
paquet que tu as supprimé et tu te retrouveras avec une régression.
--
Sébastien Kirche

Mihamina (R12y) Rakotomandimby
Le #1876746
Sébastien Kirche wrote:

Sauf que maintenant apt n'est pas au courant


Tu sais, de nos jours, on a meme besoin de mettre sur les boites de
cigarette un avertissement qui dit que le tabac tue. On a beau prévenir de
la sorte, y en a qui achètent... Alors... (Si si , Linux est une drogue!)

miterrandir
Le #1876745
Mihamina Rakotomandimby (R12y) sur fr.comp.os.linux.configuration le
vendredi 02 mars 2007 16:09

Un des problèmes de la compilation (j'entend par là ne pas utiliser les
packages) c'est justement que les autres éléments du système cherchent
spamassassin (par exemple) à un endroit bien précis, et que toi quand tu
l'a compilé, tu l'as foutu là ou tu veux.


Sauf erreur et à moins qu'il n'ait été bidouiller le makefile, on a pas le
choix du chemin d'install lors d'une installation à partir des sources de
spamassassin. Si "l'endroit bien précis" n'est pas respecté, c'est pas du
coté de l'installation par les sources qu'il faut chercher.

Sébastien Kirche
Le #1876742
Le 3 mars 2007 à 12:27, miterrandir a formulé :

Sauf erreur et à moins qu'il n'ait été bidouiller le makefile, on a
pas le choix du chemin d'install lors d'une installation à partir des
sources de spamassassin.


Le script configure ne connaît pas PREFIX & compagnie ?
--
Sébastien Kirche

miterrandir
Le #1876740
Sébastien Kirche sur fr.comp.os.linux.configuration le samedi 03 mars 2007
15:45

Le 3 mars 2007 à 12:27, miterrandir a formulé :

Sauf erreur et à moins qu'il n'ait été bidouiller le makefile, on a
pas le choix du chemin d'install lors d'une installation à partir des
sources de spamassassin.


Le script configure ne connaît pas PREFIX & compagnie ?


Si, passer des arguments de configuration consiste à modifier (le mot est
sans doute mal choisi, d'où le 'bidouiller') le Makefile il me semble ? Ce
que je veux dire c'est que si on fait (comme indiqué dans la doc ?) perl
Makefile.PL, on ne pose pas de question sur les chemins d'accès, comme
c'est parfois le cas (lorsque ça a une utilité ?).


Mihamina (R12y) Rakotomandimby
Le #1876696
miterrandir wrote:

Makefile.PL, on ne pose pas de question sur les chemins d'accès, comme
c'est parfois le cas (lorsque ça a une utilité ?).


La modularité/flexibilité a _toujours_ une utilité.

Sébastien Kirche
Le #1876695
Le 3 mars 2007 à 19:36, miterrandir a formulé :

Le script configure ne connaît pas PREFIX & compagnie ?


Si, passer des arguments de configuration consiste à modifier (le mot
est sans doute mal choisi, d'où le 'bidouiller') le Makefile il me
semble ?


Oui et non.
Oui car le passage de paramètre PREFIX à configure se traduit par une
modification du Makefile standard.
Non car c'est prévu pour justement dans les cas où on ne souhaite pas
(ou ne peut pas) installer le résultat dans les répertoires par défaut.
Soit parce qu'on n'a pas le droit (utilisateur qui compile une appli
dans son $HOME) ou parce qu'on souhaite tester une version en parallèle
de la version en place par exemple.

En tout cas c'est infiniment plus pratique et plus sûr de passer des
arguments à configure que d'aller modifier le Makefile résultant. Et
c'est fait pour.

Ce que je veux dire c'est que si on fait (comme indiqué dans
la doc ?) perl Makefile.PL, on ne pose pas de question sur les chemins
d'accès, comme c'est parfois le cas (lorsque ça a une utilité ?).


Biens sûr que ça a une utilité. Croire qu'on peut définir un cas qui
marche de façon universelle est illusoire.
--
Sébastien Kirche


Publicité
Poster une réponse
Anonyme