Re: quelques énervements
Le 05/01/2014 00:08, Bzzz a écrit : On Sat, 04 Jan 2014 23:53:14 +0100 François Patte francois.pa...@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! -- François Patte UFR de mathématiques et informatique Laboratoire CNRS MAP5, UMR 8145 Université Paris Descartes 45, rue des Saints Pères F-75270 Paris Cedex 06 Tél. +33 (0)1 8394 5849 http://www.math-info.univ-paris5.fr/~patte signature.asc Description: OpenPGP digital signature
Re: quelques énervements[bis]
Le 05/01/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 francois.pa...@mi.parisdescartes.fr wrote: Ah que caca boudin C'est quoi ça? JE N'AI JAMAIS ÉCRIS ÇA! On modifie même les originaux des courriers ici? Ça va chercher dans les combien au tribunal? -- François Patte UFR de mathématiques et informatique Laboratoire CNRS MAP5, UMR 8145 Université Paris Descartes 45, rue des Saints Pères F-75270 Paris Cedex 06 Tél. +33 (0)1 8394 5849 http://www.math-info.univ-paris5.fr/~patte signature.asc Description: OpenPGP digital signature
Re: quelques énervements
Le 5 janv. 2014 à 10:17, François Patte francois.pa...@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.pa...@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! 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 pas 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. À quoi 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. -- Pierre Malard « Les utopies ne sont souvent que des vérités prématurées » Alphonse de Lamartine |\ _,,,---,,_ /,`.-'`'-. ;-;;,_ |,4- ) )-,_. ,\ ( `'-' '---''(_/--' `-'\_) perl -e '$_=q#: 3|\ 5-,3-3,2-: 3/,`.'''`''' 5-. ;-;;,-: |,A- ) )-,_. ,\ ( `'''-''': '''-3'''2(-/--''' `-'''\-): 22PLM::#;y#:#\n#;s#(\D)(\d+)#$1x$2#ge;print' - -- Ce message n’engage que son auteur -- signature.asc Description: Message signed with OpenPGP using GPGMail
Re: quelques énervements
Le 05/01/2014 11:39, Pierre Malard a écrit : Le 5 janv. 2014 à 10:17, François Patte francois.pa...@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.pa...@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! 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 pas 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. À quoi 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 ? Doit-on justifier sa config quand on pose une question? Là, tu cherches à conserver une configuration active dans /etc/postfix /etc/postfix: Aucun fichier ou dossier de ce type 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). Dois-je encore justifier le fait que dovecot est installé mais que je ne souhaite pas qu'il soit actif pour l'instant? 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. Surtout ne pas aller voir ailleurs! -- François Patte UFR de mathématiques et informatique Laboratoire CNRS MAP5, UMR 8145 Université Paris Descartes 45, rue des Saints Pères F-75270 Paris Cedex 06 Tél. +33 (0)1 8394 5849 http://www.math-info.univ-paris5.fr/~patte signature.asc Description: OpenPGP digital signature
Re: quelques énervements
Bonjour, Le dimanche 05 janvier 2014, François Patte a écrit... 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 ? -- jm -- 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-requ...@lists.debian.org En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org Archive: http://lists.debian.org/20140105115103.GB31693@espinasse
Re: quelques énervements
On Sun, 5 Jan 2014 12:51:03 +0100 Jean-Michel OLTRA jm.oltra.antis...@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… -- Il ne faut pas désespérer des imbéciles, avec un peu d'entraînement, on peut réussir à en faire des militaires. -- Pierre Desproges -- 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-requ...@lists.debian.org En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org Archive: http://lists.debian.org/20140105134325.33e1fb98@anubis.defcon1
Re: quelques énervements
Le 05/01/2014 13:50, Bzzz a écrit : On Sun, 5 Jan 2014 12:51:03 +0100 Jean-Michel OLTRA jm.oltra.antis...@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! -- 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-requ...@lists.debian.org En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org Archive: http://lists.debian.org/52c9574c$0$2193$426a7...@news.free.fr
Re: quelques énervements
Le 05/01/2014 13:59, Michel a écrit : Le 05/01/2014 13:50, Bzzz a écrit : On Sun, 5 Jan 2014 12:51:03 +0100 Jean-Michel OLTRA jm.oltra.antis...@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! Et puis tu sais pas lire puisque j'ai écrit: */etc/postfix: Aucun fichier ou dossier de ce type* En réponse à celui qui disait qu'il fallait modifier, ou s'occuper, ou je ne sais quoi... il a dû croire que je parlais de postfix et pas de dovecot et il a répondu pour dire quelque chose parce que c'est encore les vacances et qu'il ne sait pas quoi faire comme toi (B pas Michel...) Je me demande s'il y a quelques personnes sérieuses et qui comprennent ce que l'on demande sur cette liste... pas juste répondre pour répondre, du genre: j'ai pas lu, j'ai pas vu, je ne m'en sers pas mais j'en ai entendu causer et je l'ouvre juste comme ça! -- François Patte UFR de mathématiques et informatique Laboratoire CNRS MAP5, UMR 8145 Université Paris Descartes 45, rue des Saints Pères F-75270 Paris Cedex 06 Tél. +33 (0)1 8394 5849 http://www.math-info.univ-paris5.fr/~patte signature.asc Description: OpenPGP digital signature
Re: quelques énervements
On Sun, 05 Jan 2014 13:59:56 +0100 Michel c...@free.fr wrote: Eh bien toi, tu va nous appendre ici ce que fait vraiment l'OP, car il ne nous l'a pas tout à fait expliqué, Alors… le monsieur te dit, par le truchement de ton œil raccordé à ton oreille par plein d'air, que l'OP ne sait pas ce qu'il fait parce que /etc/dovecot fait partie du pkg dovecot-core, ainsi que le daemon dovecot et son script de démarrage. Ce qui veut dire que si /etc/dovecot est inexistant, c'est que l'OP l'a supprimé sans autre forme de procès. mais puisque toi, tu as la science infuse, on attends avec impatience tous les détails! Je vois, alors afin d'être sûr que tu as bien compris, je re-formule: /etc/dovecot dan pkg dovecot-core, sipu /etc/dovecot ça yenaêtfotàlOP. Évidemment les esprits chagrins objecteront que ça manque de détails, mais ça a le mérite d'être clair. -- Mon père était fonctionnaire et ma mère ne faisait rien non plus. -- Coluche -- 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-requ...@lists.debian.org En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org Archive: http://lists.debian.org/20140105144254.33161a02@anubis.defcon1
Re: quelques énervements
On Sun, 05 Jan 2014 14:41:01 +0100 François Patte francois.pa...@mi.parisdescartes.fr wrote: il a dû croire que je parlais de postfix et pas de dovecot et il a répondu pour dire quelque chose parce que c'est encore les vacances et qu'il ne sait pas quoi faire comme toi (B pas Michel...) Oops, 'ffectivement j'ai lu bcp trop vite; maintenant, ça ne change rien à ma 1ère réponse qui garde sa logique: un système de lecture des e-mails fonctionnel est assez vital pour l'administration, car une majorité de daemons critiques envoient des messages quand ça part en sucette, et bien souvent, c'est la seule façon de prévenir l'admin que qq chose part en sucette (mis à part le monitoring). Donc, il paraît logique que le dev|maintainer ait fait en sorte que le daemon soit automatiquement redémarré, et il y a pômal de chances que tous les daemons concernant le service des e-mails soient dans le même cas. -- La dictature, c'est ferme ta gueule, et la démocratie, c'est cause toujours. -- Woody Allen -- 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-requ...@lists.debian.org En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org Archive: http://lists.debian.org/20140105145220.0fa9d20e@anubis.defcon1
Re: quelques énervements
Le 5 janv. 2014 à 12:43, François Patte francois.pa...@mi.parisdescartes.fr a écrit : Le 05/01/2014 11:39, Pierre Malard a écrit : 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 pas 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. À quoi 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 ? Doit-on justifier sa config quand on pose une question? Vraiment la veine polémique à ce que je vois ;-) il ne s'agit pas d'une demande de justification de sa config mais simplement une explication du pourquoi de la situation, ainsi que de la validité des choix de debian. Là, tu cherches à conserver une configuration active dans /etc/postfix /etc/postfix: Aucun fichier ou dossier de ce type Désolé, mes doigts se sont croisés. Comme Dovecot n'a de sens que dans le cadre de la gestion des mails, j'ai écrit postfix à la place de dovecot. /etc/dovecot est, dans la droite ligne de toute installation *nix le répertoire de configuration de ... dovecot. 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). Dois-je encore justifier le fait que dovecot est installé mais que je ne souhaite pas qu'il soit actif pour l'instant? Encore la polémique ? Je te donnais simplement une voie pour conserver le paquet dovecot tout en s'assurant qu'il n'interfère plus. Ça me semblait pourtant clair, non ? 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. Surtout ne pas aller voir ailleurs! no comments encore, je ne vois pas en quoi s'envoyer de assertions rageuses peut, d'une manière ou d'une autre, faire avancer tour débat, quelqu'il soit. Personne, dans es réponses qui t'ont été faites, n'a porté de jugement sur ton attitude et la façon dont tu gère ton problème, toi si. -- Pierre Malard « Si l'on veut croire en l'humanité, il faut voir et comprendre l'inhumanité » |\ _,,,---,,_ /,`.-'`'-. ;-;;,_ |,4- ) )-,_. ,\ ( `'-' '---''(_/--' `-'\_) perl -e '$_=q#: 3|\ 5-,3-3,2-: 3/,`.'''`''' 5-. ;-;;,-: |,A- ) )-,_. ,\ ( `'''-''': '''-3'''2(-/--''' `-'''\-): 22PLM::#;y#:#\n#;s#(\D)(\d+)#$1x$2#ge;print' - -- Ce message n’engage que son auteur -- signature.asc Description: Message signed with OpenPGP using GPGMail
Re: quelques énervements
Bonjour, Le 04/01/2014 23:53, François Patte a écrit : A chaque upgrade l'état des services est modifié; par exemple: J'ai éteint rpcbind (chkconfig -level 2345 rpcbind off); aujourd'hui, j'ai fait une mise à jour et rpcbind est en route... en faisant chkconfig --list, je peux voir qu'il est toujours configuré pour ne pas démarrer au boot. Bien! Je ne connais pas trop chkconfig désolé. Mais d'une manière générale, ça ne me surprend pas trop le genre de comportements que tu décris ici tant que tu n'écris pas ce que tu veux en dur dans un fichier de conf (dans /etc/ en somme). L'idéal pour avoir ce que tu veux, ce sont les services qui ont le bon goût d'avoir un fichier de conf /etc/default/le-service avec une instruction du genre : START=yes ou encore DAEMON=true etc. ou on peut mettre alors la valeur sur no/false. Là au moins, le fichier de conf « t'appartient » et le paquet a priori ne le modifiera pas lors d'un upgrade etc. À mon sens, c'est le moyen le plus propre de désactiver un service (tout en le laissant installé sur le système). Pour en revenir à rpcbind, il ne semble pas avoir de tel paramètre (pour ce que j'en ai vu vite faite sur une wheezy en tout cas). Par contre dans le fichier /etc/init.d/rpcbind on peut voir ça : if [ -f /etc/default/rpcbind ] then . /etc/default/rpcbind [...] Cela veut donc dire que lors du lancement du service, le fichier /etc/default/rpcbind (qui n'existe pas à la base sur ma Wheezy) est sourcé. Du coup, tu peux parfaitement créer ce fichier s'il n'existe pas et y mettre un truc du genre : echo Sorry, rpcbind is disabled by the /etc/default/rpcbind file... exit 0 Lors d'un start du service, le « exit 0 » permettra de le stopper directement avant qu'il ait eu le temps de faire quoi que ce soit. Ensuite, ne me demande pas pourquoi (pas cherché, pas le temps de creuser mais si quelqu'un a la réponse ici je suis preneur), un restart du service ne semble pas complètement désactiver rpcbind. En tout cas, je constate chez moi qu'avec un : invoke-rc.d rpcbind restart (ou même avec carrément un « invoke-rc.d rpcbind stop ») la commande « netstat -lnp » semble m'indiquer qu'il y a encore des machins en rapport avec rpcbind qui tournent sur la machine. Par contre, après un reboot, plus rien ne tourne concernant rpcbind. Et a priori je vois mal un upgrade etc. te changer tout ça car là on a écrit en dur quelque chose dans un fichier de conf qui « t'appartient » et qu'aucun paquet ne devra te modifier à ton insu. Plus surprenant: à chaque mise à jour de 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... C'est ch Même chose, il faudrait que tu arrives à l'indiquer dans un fichier de conf (idéalement /etc/default/dovecot). Peut-être que ce service possède un paramètre de conf du genre START ou DAEMON etc. Je ne connais ce programme. Tout ceci étant dit, j'approuve totalement les dires de François (Patte) : on peut parfaitement vouloir installer un service et ne pas vouloir qu'il se lance automatiquement au reboot afin de l'activer et de l'utiliser quand on en a envie. Je ne vois pas pourquoi cela devrait être interdit. Il y a même certains services qui proposent cela dans leur conf comme je l'expliquais ci-dessus. Je pense à puppet par exemple dont le service est d'ailleurs stoppé par défaut juste après installation. Enfin sur ce point, François Patte a écrit : Je me demande s'il y a quelques personnes sérieuses et qui comprennent ce que l'on demande sur cette liste... pas juste répondre pour répondre, du genre: j'ai pas lu, j'ai pas vu, je ne m'en sers pas mais j'en ai entendu causer et je l'ouvre juste comme ça! Heureusement, ce n'est pas le cas de tout le monde sur cette liste. Mais c'est vrai que parfois certains ont tendance à faire ce que tu décrit au lieu de chercher à résoudre véritablement le problème de l'OP (ou au lieu de se taire) et c'est parfois un peu agaçant, bien que ça ne soit pas très grave non plus. ;-) Perso, j'aime bien faire des digressions parfois dans les fils de discussions... mais seulement une fois le problème de l'OP résolu (ou alors j'ouvre un autre fil). À+ -- François Lafont -- 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-requ...@lists.debian.org En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org Archive: http://lists.debian.org/labrqb$2db$1...@ger.gmane.org
Re: quelques énervements
On 2014-01-05 11:39:27 +0100, Pierre Malard wrote: 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 pas 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. À quoi 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 ? Certains paquets fournissent un démon + d'autres choses (client, documentation...). Un utilisateur peut être intéressé à seulement à ces autres choses. -- Vincent Lefèvre vinc...@vinc17.net - Web: http://www.vinc17.net/ 100% accessible validated (X)HTML - Blog: http://www.vinc17.net/blog/ Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon) -- 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-requ...@lists.debian.org En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org Archive: http://lists.debian.org/20140105150645.gp4...@xvii.vinc17.org
Re: quelques énervements
Le 05/01/2014 11:39, Pierre Malard a écrit : 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. À quoi 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 ? Hélas les dépendances et recommandations peuvent arriver à cet embonpoint... Par exemple dans jessie, telepathy lance un ddémon ofonod dont je n'ai pas compris à quoi il sers (stack de tépéhonie d'après les descriptions, noi en quoi il est nécessaire pour un client jabber... Sinon le moyen debian de désactiver le lancement d'un démon c'est update-rc.d service disable signature.asc Description: OpenPGP digital signature
Re: quelques énervements
On 2014-01-05 14:52:20 +0100, Bzzz wrote: Oops, 'ffectivement j'ai lu bcp trop vite; maintenant, ça ne change rien à ma 1ère réponse qui garde sa logique: un système de lecture Plutôt un système de réception (MDA et non MUA) des e-mails fonctionnel est assez vital pour l'administration, car une majorité de daemons critiques envoient des messages quand ça part en sucette, et bien souvent, c'est la seule façon de prévenir l'admin que qq chose part en sucette (mis à part le monitoring). Donc, il paraît logique que le dev|maintainer ait fait en sorte que le daemon soit automatiquement redémarré, et il y a pômal de chances que tous les daemons concernant le service des e-mails soient dans le même cas. Mais il faut faire attention à ce qu'initialement le serveur de mail n'écoute pas sur l'extérieur avant que l'utilisateur ait eu la chance de le configurer, sinon c'est la perte de mail... -- Vincent Lefèvre vinc...@vinc17.net - Web: http://www.vinc17.net/ 100% accessible validated (X)HTML - Blog: http://www.vinc17.net/blog/ Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon) -- 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-requ...@lists.debian.org En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org Archive: http://lists.debian.org/20140105151510.gq4...@xvii.vinc17.org
Re: quelques énervements
Le 05/01/2014 16:10, Erwan David a écrit : Sinon le moyen debian de désactiver le lancement d'un démon c'est update-rc.d service disable Ce ne sera pas « upgrade résistant » à tous les coups. Si jamais le script postinst du paquet concerné re-configure les liens symboliques du script init, la modif va disparaître et au prochain reboot le service sera actif. C'est d'ailleurs le cas du paquet rpcbind justement où l'on peut voir dans le script postinst : if [ -x /etc/init.d/rpcbind ]; then update-rc.d rpcbind start 43 S 2 3 4 5 . start 32 0 6 . stop 81 1 . /dev/null invoke-rc.d rpcbind start || exit $? fi À mon humble avis, comme je l'indiquais dans mon précédent message, le moyen le plus pérenne pour avoir ce qu'on veut c'est toujours de l'inscrire en dur dans un fichier de conf (dans /etc/ donc). -- François Lafont -- 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-requ...@lists.debian.org En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org Archive: http://lists.debian.org/labtcd$i02$1...@ger.gmane.org
Re: quelques énervements
On 2014-01-05 15:56:23 +0100, Francois Lafont wrote: L'idéal pour avoir ce que tu veux, ce sont les services qui ont le bon goût d'avoir un fichier de conf /etc/default/le-service avec une instruction du genre : START=yes ou encore DAEMON=true Non, ce n'est officiellement plus supporté par Debian. Les paquets qui permettent ce genre de chose sont considérés comme buggés. La façon recommandée (je crois) est d'utiliser update-rc.d, mais c'est spécifique à l'init System-V. Pour en revenir à rpcbind, il ne semble pas avoir de tel paramètre (pour ce que j'en ai vu vite faite sur une wheezy en tout cas). Cf ci-dessus. Par contre dans le fichier /etc/init.d/rpcbind on peut voir ça : if [ -f /etc/default/rpcbind ] then . /etc/default/rpcbind [...] Cela veut donc dire que lors du lancement du service, le fichier /etc/default/rpcbind (qui n'existe pas à la base sur ma Wheezy) est sourcé. Du coup, tu peux parfaitement créer ce fichier s'il n'existe pas et y mettre un truc du genre : echo Sorry, rpcbind is disabled by the /etc/default/rpcbind file... exit 0 Ce n'est pas la bonne solution, car l'utilisateur ne peut plus lancer le service à la main quand il en a besoin (c'était le même problème avec START=no). -- Vincent Lefèvre vinc...@vinc17.net - Web: http://www.vinc17.net/ 100% accessible validated (X)HTML - Blog: http://www.vinc17.net/blog/ Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon) -- 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-requ...@lists.debian.org En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org Archive: http://lists.debian.org/20140105154633.gs4...@xvii.vinc17.org
Re: quelques énervements
Le 05/01/2014 16:23, Francois Lafont a écrit : Le 05/01/2014 16:10, Erwan David a écrit : Sinon le moyen debian de désactiver le lancement d'un démon c'est update-rc.d service disable Ce ne sera pas « upgrade résistant » à tous les coups. Si jamais le script postinst du paquet concerné re-configure les liens symboliques du script init, la modif va disparaître et au prochain reboot le service sera actif. Non parceque justement update-rc.d sauvegarde qu'il ne faut pas utiliser les niveaux par défaut mais d'autres. C'est d'ailleurs le cas du paquet rpcbind justement où l'on peut voir dans le script postinst : if [ -x /etc/init.d/rpcbind ]; then update-rc.d rpcbind start 43 S 2 3 4 5 . start 32 0 6 . stop 81 1 . /dev/null invoke-rc.d rpcbind start || exit $? fi À vérifier si c'est réellement appelé lors d'un upgrade, sinon vis à vis de la doc c'est un bug. À mon humble avis, comme je l'indiquais dans mon précédent message, le moyen le plus pérenne pour avoir ce qu'on veut c'est toujours de l'inscrire en dur dans un fichier de conf (dans /etc/ donc). Manière totalement non standard qui dépend de la manière dont le démon a été packagé... Quand en plus le démon est arrivé en dépendance on n'a pas forcément conscience de sa présence... -- 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-requ...@lists.debian.org En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org Archive: http://lists.debian.org/52c9810c.9020...@rail.eu.org
Re: quelques énervements
Le 05/01/2014 16:46, Vincent Lefevre a écrit : On 2014-01-05 15:56:23 +0100, Francois Lafont wrote: L'idéal pour avoir ce que tu veux, ce sont les services qui ont le bon goût d'avoir un fichier de conf /etc/default/le-service avec une instruction du genre : START=yes ou encore DAEMON=true Non, ce n'est officiellement plus supporté par Debian. Les paquets qui permettent ce genre de chose sont considérés comme buggés. Ah, c'est possible. Si tu as une source là-dessus, ça m'intéresse. La façon recommandée (je crois) est d'utiliser update-rc.d, mais c'est spécifique à l'init System-V. Sur ce point, je suis vraiment sûr que l'utilisation de update-rc.d ne résiste pas à un upgrade dans de nombreux cas (dans le cas de rpcbind par exemple). Cela veut donc dire que lors du lancement du service, le fichier /etc/default/rpcbind (qui n'existe pas à la base sur ma Wheezy) est sourcé. Du coup, tu peux parfaitement créer ce fichier s'il n'existe pas et y mettre un truc du genre : echo Sorry, rpcbind is disabled by the /etc/default/rpcbind file... exit 0 Ce n'est pas la bonne solution, car l'utilisateur ne peut plus lancer le service à la main quand il en a besoin (c'était le même problème avec START=no). Oui, exact sauf si on réédite le fichier de conf ce qui un peu naze, j'en conviens. Après, pour les services qui possèdent un truc du genre START=no, il y a en général une commande fournie pour lancer « à la main » le service (enfin je dis ça sans vraiment savoir, j'ai juste l'exemple particulier de puppet en tête c'est tout), mais ça ne passe plus par le script init. Je reconnais que c'est top comme solution, en plus si tu me dis que ce n'est pas une pratique approuvée par Debian alors le problème reste entier : Comment désactiver proprement le start d'un service au reboot de manière pérenne (et upgrade résistant) tout en se gardant la possibilité de faire un start à la main quand on en a envie ? (sachant que, pour ma part, j'estime que c'est une demande légitime mais c'est un autre problème). -- François Lafont -- 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-requ...@lists.debian.org En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org Archive: http://lists.debian.org/labvvp$bun$1...@ger.gmane.org
Re: quelques énervements
Le 05/01/2014 17:07, Francois Lafont a écrit : Comment désactiver proprement le start d'un service au reboot de manière pérenne (et upgrade résistant) tout en se gardant la possibilité de faire un start à la main quand on en a envie ? (sachant que, pour ma part, j'estime que c'est une demande légitime mais c'est un autre problème). J'ai ce besoin pour des services que je ne lance pas au boot, mais plus tard quand j'ai monté un disque chiffré, sachant que c'est une machine dans un datacenter à laquelle je n'ai pas d'accès physique (et je ne fais pas confiance à la console distante pour être sûr qu'elle fonctionne lors du reboot). -- 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-requ...@lists.debian.org En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org Archive: http://lists.debian.org/52c98406.9060...@rail.eu.org
Re: quelques énervements
Le 05/01/2014 16:58, Erwan David a écrit : Sinon le moyen debian de désactiver le lancement d'un démon c'est update-rc.d service disable Ce ne sera pas « upgrade résistant » à tous les coups. Si jamais le script postinst du paquet concerné re-configure les liens symboliques du script init, la modif va disparaître et au prochain reboot le service sera actif. Non parceque justement update-rc.d sauvegarde qu'il ne faut pas utiliser les niveaux par défaut mais d'autres. Si le script postinst appelle un update-rc.d à son tour (et c'est le cas de rpcbind), ta modif va être perdue. C'est tout ce que je voulais dire. C'est d'ailleurs le cas du paquet rpcbind justement où l'on peut voir dans le script postinst : if [ -x /etc/init.d/rpcbind ]; then update-rc.d rpcbind start 43 S 2 3 4 5 . start 32 0 6 . stop 81 1 . /dev/null invoke-rc.d rpcbind start || exit $? fi À vérifier si c'est réellement appelé lors d'un upgrade, Je peux me tromper bien sûr mais je suis presque sûr que ça l'est car : - le postinst est systématiquement appelé lors d'un upgrade du paquet (avec des arguments derrières) - dans le cas de rpcbind, le update-rc.d sera toujours appelé du moment que /etc/init.d/rpcbind est exécutable. sinon vis à vis de la doc c'est un bug. Où ça dans la doc cela implique que ce soit un bug ? À mon humble avis, comme je l'indiquais dans mon précédent message, le moyen le plus pérenne pour avoir ce qu'on veut c'est toujours de l'inscrire en dur dans un fichier de conf (dans /etc/ donc). Manière totalement non standard Si tu as des sources, je suis preneur. qui dépend de la manière dont le démon a été packagé... Oui en effet. -- François Lafont -- 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-requ...@lists.debian.org En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org Archive: http://lists.debian.org/lac0ru$m5r$1...@ger.gmane.org
Re: quelques énervements
Le 05/01/2014 17:22, Francois Lafont a écrit : Le 05/01/2014 16:58, Erwan David a écrit : Sinon le moyen debian de désactiver le lancement d'un démon c'est update-rc.d service disable Ce ne sera pas « upgrade résistant » à tous les coups. Si jamais le script postinst du paquet concerné re-configure les liens symboliques du script init, la modif va disparaître et au prochain reboot le service sera actif. Non parceque justement update-rc.d sauvegarde qu'il ne faut pas utiliser les niveaux par défaut mais d'autres. Si le script postinst appelle un update-rc.d à son tour (et c'est le cas de rpcbind), ta modif va être perdue. C'est tout ce que je voulais dire. C'est d'ailleurs le cas du paquet rpcbind justement où l'on peut voir dans le script postinst : if [ -x /etc/init.d/rpcbind ]; then update-rc.d rpcbind start 43 S 2 3 4 5 . start 32 0 6 . stop 81 1 . /dev/null invoke-rc.d rpcbind start || exit $? fi À vérifier si c'est réellement appelé lors d'un upgrade, Je peux me tromper bien sûr mais je suis presque sûr que ça l'est car : - le postinst est systématiquement appelé lors d'un upgrade du paquet (avec des arguments derrières) - dans le cas de rpcbind, le update-rc.d sera toujours appelé du moment que /etc/init.d/rpcbind est exécutable. C'est appelé, mais si on a fait un update-rc.d disable, ça ne fait rien : If any files named /etc/rcrunlevel.d/[SK]??name already exist then update-rc.d does nothing. The program was written this way so that it will never change an existing con‐ figuration, which may have been customized by the system administrator. The program will only install links if none are present, i.e., if it appears that the service has never been installed before. Si on fait disable on a un lien K??name donc il n'est pas changé. sinon vis à vis de la doc c'est un bug. Où ça dans la doc cela implique que ce soit un bug ? celle de update-rc.d qui dit que ça résiste aux mises à jour, mais voir ci dessus pourquoi. À mon humble avis, comme je l'indiquais dans mon précédent message, le moyen le plus pérenne pour avoir ce qu'on veut c'est toujours de l'inscrire en dur dans un fichier de conf (dans /etc/ donc). Manière totalement non standard Si tu as des sources, je suis preneur. Non standard car dépendant du packaging. Ce n'est pas un mécanisme général, qui s'applique à tous les paquets. -- 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-requ...@lists.debian.org En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org Archive: http://lists.debian.org/52c989ef.6010...@rail.eu.org
Re: quelques énervements
On 2014-01-05 17:07:33 +0100, Francois Lafont wrote: Le 05/01/2014 16:46, Vincent Lefevre a écrit : On 2014-01-05 15:56:23 +0100, Francois Lafont wrote: L'idéal pour avoir ce que tu veux, ce sont les services qui ont le bon goût d'avoir un fichier de conf /etc/default/le-service avec une instruction du genre : START=yes ou encore DAEMON=true Non, ce n'est officiellement plus supporté par Debian. Les paquets qui permettent ce genre de chose sont considérés comme buggés. Ah, c'est possible. Si tu as une source là-dessus, ça m'intéresse. Discussion solving the network-manager-in-gnome problem dans debian-devel en juillet 2012. La façon recommandée (je crois) est d'utiliser update-rc.d, mais c'est spécifique à l'init System-V. Sur ce point, je suis vraiment sûr que l'utilisation de update-rc.d ne résiste pas à un upgrade dans de nombreux cas (dans le cas de rpcbind par exemple). Rapporter un bug dans ce cas. -- Vincent Lefèvre vinc...@vinc17.net - Web: http://www.vinc17.net/ 100% accessible validated (X)HTML - Blog: http://www.vinc17.net/blog/ Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon) -- 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-requ...@lists.debian.org En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org Archive: http://lists.debian.org/20140105170107.ga5...@ioooi.vinc17.net
Re: quelques énervements
On 2014-01-05 17:35:59 +0100, Erwan David wrote: Le 05/01/2014 17:22, Francois Lafont a écrit : Je peux me tromper bien sûr mais je suis presque sûr que ça l'est car : - le postinst est systématiquement appelé lors d'un upgrade du paquet (avec des arguments derrières) - dans le cas de rpcbind, le update-rc.d sera toujours appelé du moment que /etc/init.d/rpcbind est exécutable. C'est appelé, mais si on a fait un update-rc.d disable, ça ne fait rien : If any files named /etc/rcrunlevel.d/[SK]??name already exist then update-rc.d does nothing. The program was written this way so that it will never change an existing con‐ figuration, which may have been customized by the system administrator. The program will only install links if none are present, i.e., if it appears that the service has never been installed before. Ce qui explique aussi qu'il ne faut pas supprimer les liens à la main, mais utiliser update-rc.d pour désactiver un service. -- Vincent Lefèvre vinc...@vinc17.net - Web: http://www.vinc17.net/ 100% accessible validated (X)HTML - Blog: http://www.vinc17.net/blog/ Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon) -- 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-requ...@lists.debian.org En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org Archive: http://lists.debian.org/20140105172203.gc5...@ioooi.vinc17.net
Re: quelques énervements
Le 05/01/2014 17:35, Erwan David a écrit : C'est appelé, mais si on a fait un update-rc.d disable, ça ne fait rien : If any files named /etc/rcrunlevel.d/[SK]??name already exist then update-rc.d does nothing. The program was written this way so that it will never change an existing con‐ figuration, which may have been customized by the system administrator. The program will only install links if none are present, i.e., if it appears that the service has never been installed before. Si on fait disable on a un lien K??name donc il n'est pas changé. sinon vis à vis de la doc c'est un bug. Où ça dans la doc cela implique que ce soit un bug ? celle de update-rc.d qui dit que ça résiste aux mises à jour, mais voir ci dessus pourquoi. Oui, oui. Je viens de faire le test et tu as raison sur toute la ligne (ainsi que Vincent). Dans mes souvenirs, je m'étais fait couillonner parce que j'avais fait un remove et non un disable (mais c'est expliqué dans la page man de update-rc.d). Désolé, j'ai donc dis des bêtises, au temps pour moi. ;-) Donc, comme tu le disais précédemment, pour désactiver un service de manière pérenne sans le désinstaller tout en se gardant la possibilité de le démarrer quand on a envie c'est « update-rc.d le-service disable ». Fin de l'histoire. Si tu as des sources, je suis preneur. Non standard car dépendant du packaging. Ce n'est pas un mécanisme général, qui s'applique à tous les paquets. Ok. Grâce à ce fil, j'ai appris des trucs, merci bien. -- François Lafont -- 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-requ...@lists.debian.org En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org Archive: http://lists.debian.org/lac614$bdj$1...@ger.gmane.org
quelques énervements
Bonsoir, A chaque upgrade l'état des services est modifié; par exemple: J'ai éteint rpcbind (chkconfig -level 2345 rpcbind off); aujourd'hui, j'ai fait une mise à jour et rpcbind est en route... en faisant chkconfig --list, je peux voir qu'il est toujours configuré pour ne pas démarrer au boot. Bien! Plus surprenant: à chaque mise à jour de 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... C'est ch Merci de vos lumières. -- François Patte UFR de mathématiques et informatique Laboratoire CNRS MAP5, UMR 8145 Université Paris Descartes 45, rue des Saints Pères F-75270 Paris Cedex 06 Tél. +33 (0)1 8394 5849 http://www.math-info.univ-paris5.fr/~patte signature.asc Description: OpenPGP digital signature
Re: quelques énervements
On Sat, 04 Jan 2014 23:53:14 +0100 François Patte francois.pa...@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é. -- Une visite fait toujours plaisir. Si ce n'est à l'arrivée, c'est au départ. -- Proverbe breton -- 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-requ...@lists.debian.org En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org Archive: http://lists.debian.org/20140105000822.139c74c3@anubis.defcon1
