Ah que caca boudin rpcbind (chkconfig -level 2345 rpcbind
off); aujourd'hui, j'ai fait une mise à jour et rpcbind est en
route...
Ad que re-caca boudin dovecot, dovecot est
relancé bien que je l'ai éteint de manière permanente, mai s en
plus ma demande d'extinction permanente est écrasée par la mise Ã
jour et si je demande: chkconfig --list je peux voir:
dovecot 0:off 1:off 2:on 3:on 4:on 5:on 6:off
Donc dovecot sera démarré à chaque boot malgré mon in terdiction...
Ah que caca boudin rpcbind (chkconfig -level 2345 rpcbind
off); aujourd'hui, j'ai fait une mise à jour et rpcbind est en
route...
Ad que re-caca boudin dovecot, dovecot est
relancé bien que je l'ai éteint de manière permanente, mai s en
plus ma demande d'extinction permanente est écrasée par la mise Ã
jour et si je demande: chkconfig --list je peux voir:
dovecot 0:off 1:off 2:on 3:on 4:on 5:on 6:off
Donc dovecot sera démarré à chaque boot malgré mon in terdiction...
Ah que caca boudin rpcbind (chkconfig -level 2345 rpcbind
off); aujourd'hui, j'ai fait une mise à jour et rpcbind est en
route...
Ad que re-caca boudin dovecot, dovecot est
relancé bien que je l'ai éteint de manière permanente, mai s en
plus ma demande d'extinction permanente est écrasée par la mise Ã
jour et si je demande: chkconfig --list je peux voir:
dovecot 0:off 1:off 2:on 3:on 4:on 5:on 6:off
Donc dovecot sera démarré à chaque boot malgré mon in terdiction...
On Sat, 04 Jan 2014 23:53:14 +0100
François Patte wrote:Ah que caca boudin rpcbind (chkconfig -level 2345 rpcbind
off); aujourd'hui, j'ai fait une mise à jour et rpcbind est en
route...
C'est normal, rpcbind étant un daemon, il a un script de déma rrage
dans /etc/init.d; la Mà J effectue d'abord un arrêt du daemon,
met à jour, puis redémarre ledit daemon.Ad que re-caca boudin dovecot, dovecot est
relancé bien que je l'ai éteint de manière permanente, mais en
plus ma demande d'extinction permanente est écrasée par la m ise Ã
jour et si je demande: chkconfig --list je peux voir:
dovecot 0:off 1:off 2:on 3:on 4:on 5:on 6:off
Donc dovecot sera démarré à chaque boot malgré mon interdiction...
Tout dépend de la policy et du maintainer; dans le cas de dovecot,
il est relativement normal que tout soit restauré à la normal e
étant donné qu'il sert les e-mails (dont ceux expédié s par les
daemons).
Même si tu utilises autre chose pour ce faire (disons par ex.
qpopper), les scripts de dovecot ne peuvent pas en tenir compte,
sinon ça virerait Trapidement à l'usine à gaz).
Donc, soit tu utilises autre chose et dovecot n'a plus de raison
d'être installé, soit tu utilises dovecot et il doit rester a ctivé.
On Sat, 04 Jan 2014 23:53:14 +0100
François Patte <francois.patte@mi.parisdescartes.fr> wrote:
Ah que caca boudin rpcbind (chkconfig -level 2345 rpcbind
off); aujourd'hui, j'ai fait une mise à jour et rpcbind est en
route...
C'est normal, rpcbind étant un daemon, il a un script de déma rrage
dans /etc/init.d; la Mà J effectue d'abord un arrêt du daemon,
met à jour, puis redémarre ledit daemon.
Ad que re-caca boudin dovecot, dovecot est
relancé bien que je l'ai éteint de manière permanente, mais en
plus ma demande d'extinction permanente est écrasée par la m ise Ã
jour et si je demande: chkconfig --list je peux voir:
dovecot 0:off 1:off 2:on 3:on 4:on 5:on 6:off
Donc dovecot sera démarré à chaque boot malgré mon interdiction...
Tout dépend de la policy et du maintainer; dans le cas de dovecot,
il est relativement normal que tout soit restauré à la normal e
étant donné qu'il sert les e-mails (dont ceux expédié s par les
daemons).
Même si tu utilises autre chose pour ce faire (disons par ex.
qpopper), les scripts de dovecot ne peuvent pas en tenir compte,
sinon ça virerait Trapidement à l'usine à gaz).
Donc, soit tu utilises autre chose et dovecot n'a plus de raison
d'être installé, soit tu utilises dovecot et il doit rester a ctivé.
On Sat, 04 Jan 2014 23:53:14 +0100
François Patte wrote:Ah que caca boudin rpcbind (chkconfig -level 2345 rpcbind
off); aujourd'hui, j'ai fait une mise à jour et rpcbind est en
route...
C'est normal, rpcbind étant un daemon, il a un script de déma rrage
dans /etc/init.d; la Mà J effectue d'abord un arrêt du daemon,
met à jour, puis redémarre ledit daemon.Ad que re-caca boudin dovecot, dovecot est
relancé bien que je l'ai éteint de manière permanente, mais en
plus ma demande d'extinction permanente est écrasée par la m ise Ã
jour et si je demande: chkconfig --list je peux voir:
dovecot 0:off 1:off 2:on 3:on 4:on 5:on 6:off
Donc dovecot sera démarré à chaque boot malgré mon interdiction...
Tout dépend de la policy et du maintainer; dans le cas de dovecot,
il est relativement normal que tout soit restauré à la normal e
étant donné qu'il sert les e-mails (dont ceux expédié s par les
daemons).
Même si tu utilises autre chose pour ce faire (disons par ex.
qpopper), les scripts de dovecot ne peuvent pas en tenir compte,
sinon ça virerait Trapidement à l'usine à gaz).
Donc, soit tu utilises autre chose et dovecot n'a plus de raison
d'être installé, soit tu utilises dovecot et il doit rester a ctivé.
Le 05/01/2014 00:08, Bzzz a écrit :On Sat, 04 Jan 2014 23:53:14 +0100
François Patte wrote:Ah que caca boudin
Le 05/01/2014 00:08, Bzzz a écrit :
On Sat, 04 Jan 2014 23:53:14 +0100
François Patte <francois.patte@mi.parisdescartes.fr> wrote:
Ah que caca boudin
Le 05/01/2014 00:08, Bzzz a écrit :On Sat, 04 Jan 2014 23:53:14 +0100
François Patte wrote:Ah que caca boudin
Le 05/01/2014 00:08, Bzzz a écrit :On Sat, 04 Jan 2014 23:53:14 +0100
François Patte wrote:Ah que caca boudin rpcbind (chkconfig -level 2345 rpcbind
off); aujourd'hui, j'ai fait une mise à jour et rpcbind est en
route...
C'est normal, rpcbind étant un daemon, il a un script de démarrage
dans /etc/init.d; la MàJ effectue d'abord un arrêt du daemon,
met à jour, puis redémarre ledit daemon.Ad que re-caca boudin dovecot, dovecot est
relancé bien que je l'ai éteint de manière permanente, mais en
plus ma demande d'extinction permanente est écrasée par la mise à
jour et si je demande: chkconfig --list je peux voir:
dovecot 0:off 1:off 2:on 3:on 4:on 5:on 6:off
Donc dovecot sera démarré à chaque boot malgré mon interdiction...
Tout dépend de la policy et du maintainer; dans le cas de dovecot,
il est relativement normal que tout soit restauré à la normale
étant donné qu'il sert les e-mails (dont ceux expédiés par les
daemons).
Même si tu utilises autre chose pour ce faire (disons par ex.
qpopper), les scripts de dovecot ne peuvent pas en tenir compte,
sinon ça virerait Trapidement à l'usine à gaz).
Donc, soit tu utilises autre chose et dovecot n'a plus de raison
d'être installé, soit tu utilises dovecot et il doit rester activé.
Absolument pas d'accord: je devrais être maître chez moi! Si j'éteins un
service sans le désinstaller c'est que j'ai une raison et *en aucun cas*
la mise à jour ne devrait avoir le droit de modifier l'état des services
de ma machine! Que le programme de mise à jour ait besoin d'arrêter un
service, c'est concevable, qu'il ait besion de la redémarrer (pourquoi?
test?) ça peut aussi se concevoir, mais il *doit* remettre la machine
dans l'état dans lequel il l'a trouvée!
On se retrouve ici comme dans W$: on fait des choses dans le dos des
utilisateurs! Je viens de fedora.... on m'avait (les cocardiers
m'avaient) dit que debian y a pas mieux.... Jamais eu ce pb sous fedora!
Le 05/01/2014 00:08, Bzzz a écrit :
On Sat, 04 Jan 2014 23:53:14 +0100
François Patte <francois.patte@mi.parisdescartes.fr> wrote:
Ah que caca boudin rpcbind (chkconfig -level 2345 rpcbind
off); aujourd'hui, j'ai fait une mise à jour et rpcbind est en
route...
C'est normal, rpcbind étant un daemon, il a un script de démarrage
dans /etc/init.d; la MàJ effectue d'abord un arrêt du daemon,
met à jour, puis redémarre ledit daemon.
Ad que re-caca boudin dovecot, dovecot est
relancé bien que je l'ai éteint de manière permanente, mais en
plus ma demande d'extinction permanente est écrasée par la mise à
jour et si je demande: chkconfig --list je peux voir:
dovecot 0:off 1:off 2:on 3:on 4:on 5:on 6:off
Donc dovecot sera démarré à chaque boot malgré mon interdiction...
Tout dépend de la policy et du maintainer; dans le cas de dovecot,
il est relativement normal que tout soit restauré à la normale
étant donné qu'il sert les e-mails (dont ceux expédiés par les
daemons).
Même si tu utilises autre chose pour ce faire (disons par ex.
qpopper), les scripts de dovecot ne peuvent pas en tenir compte,
sinon ça virerait Trapidement à l'usine à gaz).
Donc, soit tu utilises autre chose et dovecot n'a plus de raison
d'être installé, soit tu utilises dovecot et il doit rester activé.
Absolument pas d'accord: je devrais être maître chez moi! Si j'éteins un
service sans le désinstaller c'est que j'ai une raison et *en aucun cas*
la mise à jour ne devrait avoir le droit de modifier l'état des services
de ma machine! Que le programme de mise à jour ait besoin d'arrêter un
service, c'est concevable, qu'il ait besion de la redémarrer (pourquoi?
test?) ça peut aussi se concevoir, mais il *doit* remettre la machine
dans l'état dans lequel il l'a trouvée!
On se retrouve ici comme dans W$: on fait des choses dans le dos des
utilisateurs! Je viens de fedora.... on m'avait (les cocardiers
m'avaient) dit que debian y a pas mieux.... Jamais eu ce pb sous fedora!
Le 05/01/2014 00:08, Bzzz a écrit :On Sat, 04 Jan 2014 23:53:14 +0100
François Patte wrote:Ah que caca boudin rpcbind (chkconfig -level 2345 rpcbind
off); aujourd'hui, j'ai fait une mise à jour et rpcbind est en
route...
C'est normal, rpcbind étant un daemon, il a un script de démarrage
dans /etc/init.d; la MàJ effectue d'abord un arrêt du daemon,
met à jour, puis redémarre ledit daemon.Ad que re-caca boudin dovecot, dovecot est
relancé bien que je l'ai éteint de manière permanente, mais en
plus ma demande d'extinction permanente est écrasée par la mise à
jour et si je demande: chkconfig --list je peux voir:
dovecot 0:off 1:off 2:on 3:on 4:on 5:on 6:off
Donc dovecot sera démarré à chaque boot malgré mon interdiction...
Tout dépend de la policy et du maintainer; dans le cas de dovecot,
il est relativement normal que tout soit restauré à la normale
étant donné qu'il sert les e-mails (dont ceux expédiés par les
daemons).
Même si tu utilises autre chose pour ce faire (disons par ex.
qpopper), les scripts de dovecot ne peuvent pas en tenir compte,
sinon ça virerait Trapidement à l'usine à gaz).
Donc, soit tu utilises autre chose et dovecot n'a plus de raison
d'être installé, soit tu utilises dovecot et il doit rester activé.
Absolument pas d'accord: je devrais être maître chez moi! Si j'éteins un
service sans le désinstaller c'est que j'ai une raison et *en aucun cas*
la mise à jour ne devrait avoir le droit de modifier l'état des services
de ma machine! Que le programme de mise à jour ait besoin d'arrêter un
service, c'est concevable, qu'il ait besion de la redémarrer (pourquoi?
test?) ça peut aussi se concevoir, mais il *doit* remettre la machine
dans l'état dans lequel il l'a trouvée!
On se retrouve ici comme dans W$: on fait des choses dans le dos des
utilisateurs! Je viens de fedora.... on m'avait (les cocardiers
m'avaient) dit que debian y a pas mieux.... Jamais eu ce pb sous fedora!
Le 5 janv. 2014 à 10:17, François Patte
a écrit :Le 05/01/2014 00:08, Bzzz a écrit :On Sat, 04 Jan 2014 23:53:14 +0100 François Patte
wrote:Ah que caca boudin rpcbind (chkconfig -level 2345 rpcbind off);
aujourd'hui, j'ai fait une mise à jour et rpcbind est en
route...
C'est normal, rpcbind étant un daemon, il a un script de
démarrage dans /etc/init.d; la MàJ effectue d'abord un arrêt du
daemon, met à jour, puis redémarre ledit daemon.Ad que re-caca boudin dovecot, dovecot est relancé bien que je
l'ai éteint de manière permanente, mais en plus ma demande
d'extinction permanente est écrasée par la mise à jour et si j e
demande: chkconfig --list je peux voir:
dovecot 0:off 1:off 2:on 3:on 4:on 5:on 6:off
Donc dovecot sera démarré à chaque boot malgré mon
interdiction...
Tout dépend de la policy et du maintainer; dans le cas de
dovecot, il est relativement normal que tout soit restauré à la
normale étant donné qu'il sert les e-mails (dont ceux expédié s
par les daemons). Même si tu utilises autre chose pour ce faire
(disons par ex. qpopper), les scripts de dovecot ne peuvent pas
en tenir compte, sinon ça virerait Trapidement à l'usine à gaz) .
Donc, soit tu utilises autre chose et dovecot n'a plus de raison
d'être installé, soit tu utilises dovecot et il doit rester
activé.
Absolument pas d'accord: je devrais être maître chez moi! Si
j'éteins un service sans le désinstaller c'est que j'ai une raison
et *en aucun cas* la mise à jour ne devrait avoir le droit de
modifier l'état des services de ma machine! Que le programme de
mise à jour ait besoin d'arrêter un service, c'est concevable,
qu'il ait besion de la redémarrer (pourquoi? test?) ça peut aussi
se concevoir, mais il *doit* remettre la machine dans l'état dans
lequel il l'a trouvée!
Il y en a qui commencent l'année très fort, dans la délicatesse, la
mesure et tout, et tout... Les aguapes ont laissé trop de traces ?
Le principe de l'installation d'un paquet sur Debian est d'offrir le
service installé actif et dans une configuration sûre s'il n'y a pa s
de configuration existante précédente. Toute configuration est
définie dans /etc qui est donc sous la seule responsabilité de
l'utilisateur. Le reste, activation ou non, ... dépend du
développeur. On part du principe, en partant d'un simple point de vue
de sécurité et pour éviter l'embonpoint, que la demande
d'installation d'un paquet pré-suppose son utilisation active. À qu oi
peu bien servir d'installer un service si ce n'est pas pour s'en
servir ? N'est-il pas très dangereux d'activer un service sur serveur
ouvert si on ne s'en sert pas ? D'autre part, que donnerait une
démarche qui constituerait à installer un paquet sans l'activer à
part alourdir la gestion du système et encombrer inutilement le
système avec tout un tas de services inactifs et inutiles ?
Là, tu cherches à conserver une configuration active dans
/etc/postfix
mais à invalider sont exécution dans les init.d... Il y
a un certain illogisme dans la démarche. Si, vraiment, tu souhaites
conserver dovecot en même temps qu'un service similaire sans
l'utiliser, tout en le gardant... arranges-toi pour qu'il ne
n'interfère pas sur les mêmes services dans sa configuration dans
/etc/dovecot (p.e. désactiver le listen dans
/etc/dovecot/docvecot.conf).
On se retrouve ici comme dans W$: on fait des choses dans le dos
des utilisateurs! Je viens de fedora.... on m'avait (les
cocardiers m'avaient) dit que debian y a pas mieux.... Jamais eu ce
pb sous fedora!
No comment, il serait bon d'éviter ce genre d'assertion qui ne font
absolument pas avancer le débat.
Le 5 janv. 2014 à 10:17, François Patte
<francois.patte@mi.parisdescartes.fr> a écrit :
Le 05/01/2014 00:08, Bzzz a écrit :
On Sat, 04 Jan 2014 23:53:14 +0100 François Patte
<francois.patte@mi.parisdescartes.fr> wrote:
Ah que caca boudin rpcbind (chkconfig -level 2345 rpcbind off);
aujourd'hui, j'ai fait une mise à jour et rpcbind est en
route...
C'est normal, rpcbind étant un daemon, il a un script de
démarrage dans /etc/init.d; la MàJ effectue d'abord un arrêt du
daemon, met à jour, puis redémarre ledit daemon.
Ad que re-caca boudin dovecot, dovecot est relancé bien que je
l'ai éteint de manière permanente, mais en plus ma demande
d'extinction permanente est écrasée par la mise à jour et si j e
demande: chkconfig --list je peux voir:
dovecot 0:off 1:off 2:on 3:on 4:on 5:on 6:off
Donc dovecot sera démarré à chaque boot malgré mon
interdiction...
Tout dépend de la policy et du maintainer; dans le cas de
dovecot, il est relativement normal que tout soit restauré à la
normale étant donné qu'il sert les e-mails (dont ceux expédié s
par les daemons). Même si tu utilises autre chose pour ce faire
(disons par ex. qpopper), les scripts de dovecot ne peuvent pas
en tenir compte, sinon ça virerait Trapidement à l'usine à gaz) .
Donc, soit tu utilises autre chose et dovecot n'a plus de raison
d'être installé, soit tu utilises dovecot et il doit rester
activé.
Absolument pas d'accord: je devrais être maître chez moi! Si
j'éteins un service sans le désinstaller c'est que j'ai une raison
et *en aucun cas* la mise à jour ne devrait avoir le droit de
modifier l'état des services de ma machine! Que le programme de
mise à jour ait besoin d'arrêter un service, c'est concevable,
qu'il ait besion de la redémarrer (pourquoi? test?) ça peut aussi
se concevoir, mais il *doit* remettre la machine dans l'état dans
lequel il l'a trouvée!
Il y en a qui commencent l'année très fort, dans la délicatesse, la
mesure et tout, et tout... Les aguapes ont laissé trop de traces ?
Le principe de l'installation d'un paquet sur Debian est d'offrir le
service installé actif et dans une configuration sûre s'il n'y a pa s
de configuration existante précédente. Toute configuration est
définie dans /etc qui est donc sous la seule responsabilité de
l'utilisateur. Le reste, activation ou non, ... dépend du
développeur. On part du principe, en partant d'un simple point de vue
de sécurité et pour éviter l'embonpoint, que la demande
d'installation d'un paquet pré-suppose son utilisation active. À qu oi
peu bien servir d'installer un service si ce n'est pas pour s'en
servir ? N'est-il pas très dangereux d'activer un service sur serveur
ouvert si on ne s'en sert pas ? D'autre part, que donnerait une
démarche qui constituerait à installer un paquet sans l'activer à
part alourdir la gestion du système et encombrer inutilement le
système avec tout un tas de services inactifs et inutiles ?
Là, tu cherches à conserver une configuration active dans
/etc/postfix
mais à invalider sont exécution dans les init.d... Il y
a un certain illogisme dans la démarche. Si, vraiment, tu souhaites
conserver dovecot en même temps qu'un service similaire sans
l'utiliser, tout en le gardant... arranges-toi pour qu'il ne
n'interfère pas sur les mêmes services dans sa configuration dans
/etc/dovecot (p.e. désactiver le listen dans
/etc/dovecot/docvecot.conf).
On se retrouve ici comme dans W$: on fait des choses dans le dos
des utilisateurs! Je viens de fedora.... on m'avait (les
cocardiers m'avaient) dit que debian y a pas mieux.... Jamais eu ce
pb sous fedora!
No comment, il serait bon d'éviter ce genre d'assertion qui ne font
absolument pas avancer le débat.
Le 5 janv. 2014 à 10:17, François Patte
a écrit :Le 05/01/2014 00:08, Bzzz a écrit :On Sat, 04 Jan 2014 23:53:14 +0100 François Patte
wrote:Ah que caca boudin rpcbind (chkconfig -level 2345 rpcbind off);
aujourd'hui, j'ai fait une mise à jour et rpcbind est en
route...
C'est normal, rpcbind étant un daemon, il a un script de
démarrage dans /etc/init.d; la MàJ effectue d'abord un arrêt du
daemon, met à jour, puis redémarre ledit daemon.Ad que re-caca boudin dovecot, dovecot est relancé bien que je
l'ai éteint de manière permanente, mais en plus ma demande
d'extinction permanente est écrasée par la mise à jour et si j e
demande: chkconfig --list je peux voir:
dovecot 0:off 1:off 2:on 3:on 4:on 5:on 6:off
Donc dovecot sera démarré à chaque boot malgré mon
interdiction...
Tout dépend de la policy et du maintainer; dans le cas de
dovecot, il est relativement normal que tout soit restauré à la
normale étant donné qu'il sert les e-mails (dont ceux expédié s
par les daemons). Même si tu utilises autre chose pour ce faire
(disons par ex. qpopper), les scripts de dovecot ne peuvent pas
en tenir compte, sinon ça virerait Trapidement à l'usine à gaz) .
Donc, soit tu utilises autre chose et dovecot n'a plus de raison
d'être installé, soit tu utilises dovecot et il doit rester
activé.
Absolument pas d'accord: je devrais être maître chez moi! Si
j'éteins un service sans le désinstaller c'est que j'ai une raison
et *en aucun cas* la mise à jour ne devrait avoir le droit de
modifier l'état des services de ma machine! Que le programme de
mise à jour ait besoin d'arrêter un service, c'est concevable,
qu'il ait besion de la redémarrer (pourquoi? test?) ça peut aussi
se concevoir, mais il *doit* remettre la machine dans l'état dans
lequel il l'a trouvée!
Il y en a qui commencent l'année très fort, dans la délicatesse, la
mesure et tout, et tout... Les aguapes ont laissé trop de traces ?
Le principe de l'installation d'un paquet sur Debian est d'offrir le
service installé actif et dans une configuration sûre s'il n'y a pa s
de configuration existante précédente. Toute configuration est
définie dans /etc qui est donc sous la seule responsabilité de
l'utilisateur. Le reste, activation ou non, ... dépend du
développeur. On part du principe, en partant d'un simple point de vue
de sécurité et pour éviter l'embonpoint, que la demande
d'installation d'un paquet pré-suppose son utilisation active. À qu oi
peu bien servir d'installer un service si ce n'est pas pour s'en
servir ? N'est-il pas très dangereux d'activer un service sur serveur
ouvert si on ne s'en sert pas ? D'autre part, que donnerait une
démarche qui constituerait à installer un paquet sans l'activer à
part alourdir la gestion du système et encombrer inutilement le
système avec tout un tas de services inactifs et inutiles ?
Là, tu cherches à conserver une configuration active dans
/etc/postfix
mais à invalider sont exécution dans les init.d... Il y
a un certain illogisme dans la démarche. Si, vraiment, tu souhaites
conserver dovecot en même temps qu'un service similaire sans
l'utiliser, tout en le gardant... arranges-toi pour qu'il ne
n'interfère pas sur les mêmes services dans sa configuration dans
/etc/dovecot (p.e. désactiver le listen dans
/etc/dovecot/docvecot.conf).
On se retrouve ici comme dans W$: on fait des choses dans le dos
des utilisateurs! Je viens de fedora.... on m'avait (les
cocardiers m'avaient) dit que debian y a pas mieux.... Jamais eu ce
pb sous fedora!
No comment, il serait bon d'éviter ce genre d'assertion qui ne font
absolument pas avancer le débat.
Dois-je encore justifier le fait que dovecot est installé mais que je ne
souhaite pas qu'il soit actif pour l'instant?
Dois-je encore justifier le fait que dovecot est installé mais que je ne
souhaite pas qu'il soit actif pour l'instant?
Dois-je encore justifier le fait que dovecot est installé mais que je ne
souhaite pas qu'il soit actif pour l'instant?
Tu pourrais le supprimer, via `aptitude (apt-get) remove`, ce qui
ne supprimerait pas la config ?
Ou faire un truc crade que je fais parfois, comme renommer le lien
de démarrage SXXservice en sXXservice ?
Tu pourrais le supprimer, via `aptitude (apt-get) remove`, ce qui
ne supprimerait pas la config ?
Ou faire un truc crade que je fais parfois, comme renommer le lien
de démarrage SXXservice en sXXservice ?
Tu pourrais le supprimer, via `aptitude (apt-get) remove`, ce qui
ne supprimerait pas la config ?
Ou faire un truc crade que je fais parfois, comme renommer le lien
de démarrage SXXservice en sXXservice ?
On Sun, 5 Jan 2014 12:51:03 +0100
Jean-Michel OLTRA wrote:Tu pourrais le supprimer, via `aptitude (apt-get) remove`, ce qui
ne supprimerait pas la config ?
Ou faire un truc crade que je fais parfois, comme renommer le lien
de démarrage SXXservice en sXXservice ?
Y'a plus rapide et tout aussi crad: chmod -x /etc/init.d/dovecot
(ou cd /etc/init.d; mv dovecot OFF_dovecot).
Et puis de toute façon, ça n'a pas trop d'importance puisque l'OP
ne sait pas vraiment ce qu'il fait puisqu'il annonce que
/etc/dovecot est inexistant…
On Sun, 5 Jan 2014 12:51:03 +0100
Jean-Michel OLTRA <jm.oltra.antispam@espinasse.net> wrote:
Tu pourrais le supprimer, via `aptitude (apt-get) remove`, ce qui
ne supprimerait pas la config ?
Ou faire un truc crade que je fais parfois, comme renommer le lien
de démarrage SXXservice en sXXservice ?
Y'a plus rapide et tout aussi crad: chmod -x /etc/init.d/dovecot
(ou cd /etc/init.d; mv dovecot OFF_dovecot).
Et puis de toute façon, ça n'a pas trop d'importance puisque l'OP
ne sait pas vraiment ce qu'il fait puisqu'il annonce que
/etc/dovecot est inexistant…
On Sun, 5 Jan 2014 12:51:03 +0100
Jean-Michel OLTRA wrote:Tu pourrais le supprimer, via `aptitude (apt-get) remove`, ce qui
ne supprimerait pas la config ?
Ou faire un truc crade que je fais parfois, comme renommer le lien
de démarrage SXXservice en sXXservice ?
Y'a plus rapide et tout aussi crad: chmod -x /etc/init.d/dovecot
(ou cd /etc/init.d; mv dovecot OFF_dovecot).
Et puis de toute façon, ça n'a pas trop d'importance puisque l'OP
ne sait pas vraiment ce qu'il fait puisqu'il annonce que
/etc/dovecot est inexistant…
Eh bien toi, tu va nous appendre ici ce que fait vraiment l'OP,
car il ne nous l'a pas tout à fait expliqué,
mais puisque toi, tu
as la science infuse, on attends avec impatience tous les détails!
Eh bien toi, tu va nous appendre ici ce que fait vraiment l'OP,
car il ne nous l'a pas tout à fait expliqué,
mais puisque toi, tu
as la science infuse, on attends avec impatience tous les détails!
Eh bien toi, tu va nous appendre ici ce que fait vraiment l'OP,
car il ne nous l'a pas tout à fait expliqué,
mais puisque toi, tu
as la science infuse, on attends avec impatience tous les détails!
Le 05/01/2014 13:50, Bzzz a écrit :On Sun, 5 Jan 2014 12:51:03 +0100
Jean-Michel OLTRA wrote:Tu pourrais le supprimer, via `aptitude (apt-get) remove`, ce qui
ne supprimerait pas la config ?
Ou faire un truc crade que je fais parfois, comme renommer le lien
de démarrage SXXservice en sXXservice ?
Y'a plus rapide et tout aussi crad: chmod -x /etc/init.d/dovecot
(ou cd /etc/init.d; mv dovecot OFF_dovecot).
Et puis de toute façon, ça n'a pas trop d'importance puisque l'OP
ne sait pas vraiment ce qu'il fait puisqu'il annonce que
/etc/dovecot est inexistantâ¦
Eh bien toi, tu va nous appendre ici ce que fait vraiment l'OP, car il
ne nous l'a pas tout à fait expliqué, mais puisque toi, tu as la science
infuse, on attends avec impatience tous les détails!
Le 05/01/2014 13:50, Bzzz a écrit :
On Sun, 5 Jan 2014 12:51:03 +0100
Jean-Michel OLTRA <jm.oltra.antispam@espinasse.net> wrote:
Tu pourrais le supprimer, via `aptitude (apt-get) remove`, ce qui
ne supprimerait pas la config ?
Ou faire un truc crade que je fais parfois, comme renommer le lien
de démarrage SXXservice en sXXservice ?
Y'a plus rapide et tout aussi crad: chmod -x /etc/init.d/dovecot
(ou cd /etc/init.d; mv dovecot OFF_dovecot).
Et puis de toute façon, ça n'a pas trop d'importance puisque l'OP
ne sait pas vraiment ce qu'il fait puisqu'il annonce que
/etc/dovecot est inexistantâ¦
Eh bien toi, tu va nous appendre ici ce que fait vraiment l'OP, car il
ne nous l'a pas tout à fait expliqué, mais puisque toi, tu as la science
infuse, on attends avec impatience tous les détails!
Le 05/01/2014 13:50, Bzzz a écrit :On Sun, 5 Jan 2014 12:51:03 +0100
Jean-Michel OLTRA wrote:Tu pourrais le supprimer, via `aptitude (apt-get) remove`, ce qui
ne supprimerait pas la config ?
Ou faire un truc crade que je fais parfois, comme renommer le lien
de démarrage SXXservice en sXXservice ?
Y'a plus rapide et tout aussi crad: chmod -x /etc/init.d/dovecot
(ou cd /etc/init.d; mv dovecot OFF_dovecot).
Et puis de toute façon, ça n'a pas trop d'importance puisque l'OP
ne sait pas vraiment ce qu'il fait puisqu'il annonce que
/etc/dovecot est inexistantâ¦
Eh bien toi, tu va nous appendre ici ce que fait vraiment l'OP, car il
ne nous l'a pas tout à fait expliqué, mais puisque toi, tu as la science
infuse, on attends avec impatience tous les détails!
