Squeeze : Démarrage de postfix, fetchmail et spampd
2 réponses
Alain Rpnpif
Bonjour,
Squeeze comporte le nouveau syst=C3=A8me de d=C3=A9marrage en parall=C3=A8le
des /etc/init.d/*.
Les d=C3=A9pendances de d=C3=A9marrage des services postfix, fetchmail et
spampd est =C3=A9trange et illogique pour moi.
Fetchmail devrait imp=C3=A9rativement =C3=AAtre d=C3=A9marr=C3=A9 apr=C3=A8=
s Postfix
($mail-transport-agent). Spampd devrait =C3=AAtre d=C3=A9marr=C3=A9 avant P=
ostfix car
il est en lien =C3=A9troit avec celui-ci.
Ce qui fait qu'on devrait avoir un d=C3=A9marrage dans cet ordre pour
=C3=A9viter de perdre des courriels :
1 spampd
2 postfix
3 fetchmail
D'apr=C3=A8s moi, ces d=C3=A9pendances sont bogu=C3=A9es pour les raisons s=
uivantes :
1 D'abord spamassassin doit =C3=AAtre d=C3=A9sactiv=C3=A9
dans /etc/default/spamassassin car il ne doit pas =C3=AAtre lanc=C3=A9 =C3=
=A9tant en
conflit avec spampd mais il doit =C3=AAtre install=C3=A9 car indispensable =
=C3=A0
spampd.
Donc postfix ne devrait pas avoir de d=C3=A9pendance =C3=A0 spamassassin ma=
is =C3=A0
quelque chose comme une variable appel=C3=A9e par exemple $antispam qui
prendrait la valeur spamassassin si ce dernier est effectivement
utilis=C3=A9 ou spampd si c'est celui-ci ou autre ; pour moi ce serait
spampd.
2 L'ordre de d=C3=A9marrage est 1 fetchmail, 2 postfix, 3 spampd, c'est =C3=
=A0
dire =C3=A0 l'envers.
Fetchmail rapatrie les courriels mais ne peut pas les d=C3=A9livrer
(postfix n'est pas encore lanc=C3=A9). Il y a donc risque de perte de
donn=C3=A9es.
3 Un transporteur de courriel est indispensable pour fetchmail donc on
devrait avoir : # Required-Start: $mail-transport-agent au lieu de
Should-Start.
4 # Required-Start: $mail-transport-agent
ne donne pas la priorit=C3=A9 =C3=A0 Postfix devant fetchmail comme il est =
cens=C3=A9
le faire. Je ne comprends pas pourquoi cela ne marche pas ce qui fait
que fetchmail d=C3=A9marre en premier (bogue de update-rc.d ?)
En r=C3=A9sum=C3=A9 voici les modifications que je pr=C3=A9conise :
Pour Spamassassin
# Provides: spampassassin antispam
(avec risque de faux conflit avec spampd). =C3=80 revoir. Il y a
contradiction ou conflit entre l'activation
dans /etc/default/spamassassin et le d=C3=A9marrage du
service /etc/init.d/spamassassin.
Ces probl=C3=A8mes n'existant qu'au d=C3=A9marrage ont pu =C3=A9chapp=C3=A9=
car la plupart
des serveurs ne sont que rarement d=C3=A9marr=C3=A9s, ce n'est pas le cas d=
u mien.
Ma question :
Qu'en pensez-vous ? Me trompe-je ?=20
=C3=80 quels paquets affecter les bogues (parce que je suppose que plusieurs
paquets sont en cause) ?
=C3=80 vous lire.
--=20
Alain Rpnpif
--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists
Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers debian-user-french-REQUEST@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmaster@lists.debian.org
Archive: http://lists.debian.org/20101030151755.0406628f@arrcuis.home
--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists
Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers debian-user-french-REQUEST@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmaster@lists.debian.org
Archive: http://lists.debian.org/20101030165651.4aea3f3c@arrcuis.home
-- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists
Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe" vers En cas de soucis, contactez EN ANGLAIS Archive: http://lists.debian.org/
mouss
Le 30/10/2010 15:17, Alain Rpnpif a écrit :
Bonjour,
Squeeze comporte le nouveau système de démarrage en parallèle des /etc/init.d/*.
Les dépendances de démarrage des services postfix, fetchmail et spampd est étrange et illogique pour moi.
Fetchmail devrait impérativement être démarré après Postfix ($mail-transport-agent). Spampd devrait être démarré avant Postfix car il est en lien étroit avec celui-ci.
Ce qui fait qu'on devrait avoir un démarrage dans cet ordre pour éviter de perdre des courriels : 1 spampd 2 postfix 3 fetchmail
D'après moi, ces dépendances sont boguées pour les raisons suivantes :
1 D'abord spamassassin doit être désactivé dans /etc/default/spamassassin car il ne doit pas être lancé étant en conflit avec spampd mais il doit être installé car indispensable à spampd. Donc postfix ne devrait pas avoir de dépendance à spamassassin mais à quelque chose comme une variable appelée par exemple $antispam qui prendrait la valeur spamassassin si ce dernier est effectivement utilisé ou spampd si c'est celui-ci ou autre ; pour moi ce serait spampd.
2 L'ordre de démarrage est 1 fetchmail, 2 postfix, 3 spampd, c'est à dire à l'envers. Fetchmail rapatrie les courriels mais ne peut pas les délivrer (postfix n'est pas encore lancé). Il y a donc risque de perte de données.
3 Un transporteur de courriel est indispensable pour fetchmail donc on devrait avoir : # Required-Start: $mail-transport-agent au lieu de Should-Start.
4 # Required-Start: $mail-transport-agent ne donne pas la priorité à Postfix devant fetchmail comme il est censé le faire. Je ne comprends pas pourquoi cela ne marche pas ce qui fait que fetchmail démarre en premier (bogue de update-rc.d ?)
En résumé voici les modifications que je préconise :
Pour Spamassassin # Provides: spampassassin antispam (avec risque de faux conflit avec spampd). À revoir. Il y a contradiction ou conflit entre l'activation dans /etc/default/spamassassin et le démarrage du service /etc/init.d/spamassassin.
Ces problèmes n'existant qu'au démarrage ont pu échappé car la plupart des serveurs ne sont que rarement démarrés, ce n'est pas le cas du mien.
Ma question : Qu'en pensez-vous ? Me trompe-je ? À quels paquets affecter les bogues (parce que je suppose que plusieurs paquets sont en cause) ?
moi, je voterai pour la suppression de ces dépendances. quand on fait tourner postfix, clamsmtp, clamav, amavisd-new, dovecot, mailman/sympa, 4 milters, 3 policy-services, ... etc, la liste des dépendances risque de faire mal à la tête ;-p
de façon plus générale, je suis pour le découplage et pour "distribuer l'intelligence" autant que possible, surtout pour les services "asynchrones". si les services peuvent être lancés sans qu'on s'embête à les ordonner, ça fera une tache en moins, et on pourra les lancer en parallèle.
Dans le cas présent, l'ordre ne devrait pas poser de problème. sinon, ce problème serait rencontré sans redémarrage. par exemple: - spampd n'a plus de ressources - postfix n'a plus de ressources
en principe, - si postfiux n'est pas dispo (pas forcément arrêté), fetchmail fera une tentative plus tard. fetchmail ne demande pas la suppression du message (du serveur pop/imap) sauf quand postfix a "pris la responsabilité" de livrer ce message. - si spampd n'est pas dispo (pas forcémenet arrêté), postfix fera une tentative plus tard. en attendant, il garde le message dans sa file d'attente (mail queue).
-- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists
Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe" vers En cas de soucis, contactez EN ANGLAIS Archive: http://lists.debian.org/
Le 30/10/2010 15:17, Alain Rpnpif a écrit :
Bonjour,
Squeeze comporte le nouveau système de démarrage en parallèle
des /etc/init.d/*.
Les dépendances de démarrage des services postfix, fetchmail et
spampd est étrange et illogique pour moi.
Fetchmail devrait impérativement être démarré après Postfix
($mail-transport-agent). Spampd devrait être démarré avant Postfix car
il est en lien étroit avec celui-ci.
Ce qui fait qu'on devrait avoir un démarrage dans cet ordre pour
éviter de perdre des courriels :
1 spampd
2 postfix
3 fetchmail
D'après moi, ces dépendances sont boguées pour les raisons suivantes :
1 D'abord spamassassin doit être désactivé
dans /etc/default/spamassassin car il ne doit pas être lancé étant en
conflit avec spampd mais il doit être installé car indispensable à
spampd.
Donc postfix ne devrait pas avoir de dépendance à spamassassin mais à
quelque chose comme une variable appelée par exemple $antispam qui
prendrait la valeur spamassassin si ce dernier est effectivement
utilisé ou spampd si c'est celui-ci ou autre ; pour moi ce serait
spampd.
2 L'ordre de démarrage est 1 fetchmail, 2 postfix, 3 spampd, c'est à
dire à l'envers.
Fetchmail rapatrie les courriels mais ne peut pas les délivrer
(postfix n'est pas encore lancé). Il y a donc risque de perte de
données.
3 Un transporteur de courriel est indispensable pour fetchmail donc on
devrait avoir : # Required-Start: $mail-transport-agent au lieu de
Should-Start.
4 # Required-Start: $mail-transport-agent
ne donne pas la priorité à Postfix devant fetchmail comme il est censé
le faire. Je ne comprends pas pourquoi cela ne marche pas ce qui fait
que fetchmail démarre en premier (bogue de update-rc.d ?)
En résumé voici les modifications que je préconise :
Pour Spamassassin
# Provides: spampassassin antispam
(avec risque de faux conflit avec spampd). À revoir. Il y a
contradiction ou conflit entre l'activation
dans /etc/default/spamassassin et le démarrage du
service /etc/init.d/spamassassin.
Ces problèmes n'existant qu'au démarrage ont pu échappé car la plupart
des serveurs ne sont que rarement démarrés, ce n'est pas le cas du mien.
Ma question :
Qu'en pensez-vous ? Me trompe-je ?
À quels paquets affecter les bogues (parce que je suppose que plusieurs
paquets sont en cause) ?
moi, je voterai pour la suppression de ces dépendances. quand on fait
tourner postfix, clamsmtp, clamav, amavisd-new, dovecot, mailman/sympa,
4 milters, 3 policy-services, ... etc, la liste des dépendances risque
de faire mal à la tête ;-p
de façon plus générale, je suis pour le découplage et pour "distribuer
l'intelligence" autant que possible, surtout pour les services
"asynchrones". si les services peuvent être lancés sans qu'on s'embête à
les ordonner, ça fera une tache en moins, et on pourra les lancer en
parallèle.
Dans le cas présent, l'ordre ne devrait pas poser de problème. sinon, ce
problème serait rencontré sans redémarrage. par exemple:
- spampd n'a plus de ressources
- postfix n'a plus de ressources
en principe,
- si postfiux n'est pas dispo (pas forcément arrêté), fetchmail fera une
tentative plus tard. fetchmail ne demande pas la suppression du message
(du serveur pop/imap) sauf quand postfix a "pris la responsabilité" de
livrer ce message.
- si spampd n'est pas dispo (pas forcémenet arrêté), postfix fera une
tentative plus tard. en attendant, il garde le message dans sa file
d'attente (mail queue).
--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists
Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers debian-user-french-REQUEST@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmaster@lists.debian.org
Archive: http://lists.debian.org/20101031173417.8EC6713A43CC@liszt.debian.org
Squeeze comporte le nouveau système de démarrage en parallèle des /etc/init.d/*.
Les dépendances de démarrage des services postfix, fetchmail et spampd est étrange et illogique pour moi.
Fetchmail devrait impérativement être démarré après Postfix ($mail-transport-agent). Spampd devrait être démarré avant Postfix car il est en lien étroit avec celui-ci.
Ce qui fait qu'on devrait avoir un démarrage dans cet ordre pour éviter de perdre des courriels : 1 spampd 2 postfix 3 fetchmail
D'après moi, ces dépendances sont boguées pour les raisons suivantes :
1 D'abord spamassassin doit être désactivé dans /etc/default/spamassassin car il ne doit pas être lancé étant en conflit avec spampd mais il doit être installé car indispensable à spampd. Donc postfix ne devrait pas avoir de dépendance à spamassassin mais à quelque chose comme une variable appelée par exemple $antispam qui prendrait la valeur spamassassin si ce dernier est effectivement utilisé ou spampd si c'est celui-ci ou autre ; pour moi ce serait spampd.
2 L'ordre de démarrage est 1 fetchmail, 2 postfix, 3 spampd, c'est à dire à l'envers. Fetchmail rapatrie les courriels mais ne peut pas les délivrer (postfix n'est pas encore lancé). Il y a donc risque de perte de données.
3 Un transporteur de courriel est indispensable pour fetchmail donc on devrait avoir : # Required-Start: $mail-transport-agent au lieu de Should-Start.
4 # Required-Start: $mail-transport-agent ne donne pas la priorité à Postfix devant fetchmail comme il est censé le faire. Je ne comprends pas pourquoi cela ne marche pas ce qui fait que fetchmail démarre en premier (bogue de update-rc.d ?)
En résumé voici les modifications que je préconise :
Pour Spamassassin # Provides: spampassassin antispam (avec risque de faux conflit avec spampd). À revoir. Il y a contradiction ou conflit entre l'activation dans /etc/default/spamassassin et le démarrage du service /etc/init.d/spamassassin.
Ces problèmes n'existant qu'au démarrage ont pu échappé car la plupart des serveurs ne sont que rarement démarrés, ce n'est pas le cas du mien.
Ma question : Qu'en pensez-vous ? Me trompe-je ? À quels paquets affecter les bogues (parce que je suppose que plusieurs paquets sont en cause) ?
moi, je voterai pour la suppression de ces dépendances. quand on fait tourner postfix, clamsmtp, clamav, amavisd-new, dovecot, mailman/sympa, 4 milters, 3 policy-services, ... etc, la liste des dépendances risque de faire mal à la tête ;-p
de façon plus générale, je suis pour le découplage et pour "distribuer l'intelligence" autant que possible, surtout pour les services "asynchrones". si les services peuvent être lancés sans qu'on s'embête à les ordonner, ça fera une tache en moins, et on pourra les lancer en parallèle.
Dans le cas présent, l'ordre ne devrait pas poser de problème. sinon, ce problème serait rencontré sans redémarrage. par exemple: - spampd n'a plus de ressources - postfix n'a plus de ressources
en principe, - si postfiux n'est pas dispo (pas forcément arrêté), fetchmail fera une tentative plus tard. fetchmail ne demande pas la suppression du message (du serveur pop/imap) sauf quand postfix a "pris la responsabilité" de livrer ce message. - si spampd n'est pas dispo (pas forcémenet arrêté), postfix fera une tentative plus tard. en attendant, il garde le message dans sa file d'attente (mail queue).
-- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists
Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe" vers En cas de soucis, contactez EN ANGLAIS Archive: http://lists.debian.org/