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
