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 (Bzzzz pas Michel...)
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 (Bzzzz pas Michel...)
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 (Bzzzz pas Michel...)
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?
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!
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?
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!
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?
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!
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....
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!"
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....
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!"
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....
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!"
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 ?
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 ?
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 ?
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.
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.
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.
On part du principe, en partant d'un simple point de vue de sécuri té
et pour éviter l'embonpoint, que la demande d'installation d'un pa quet
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 ?
On part du principe, en partant d'un simple point de vue de sécuri té
et pour éviter l'embonpoint, que la demande d'installation d'un pa quet
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 ?
On part du principe, en partant d'un simple point de vue de sécuri té
et pour éviter l'embonpoint, que la demande d'installation d'un pa quet
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 ?
Sinon le moyen debian de désactiver le lancement d'un démon c'est
update-rc.d service disable
Sinon le moyen debian de désactiver le lancement d'un démon c'est
update-rc.d service disable
Sinon le moyen debian de désactiver le lancement d'un démon c'est
update-rc.d service disable
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
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
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
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
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
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
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).
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).
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).
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.
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).
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.
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).
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.
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).