Oui, pour les installations qui ont une lien d’arrêt du réseau en K. Pour celles qui ont un lien d’arrêt en S comme la mienne, il faut remplacer stop par start.
“Avant l’activation des interfaces réseau configurées en auto dans /etc/network/interfaces […] jusqu’à leur désactivation.”
Bon ben admettons que ceux qui mettrons en place ce parefeu à l’aide du tuto “pour les nuls”, le feraont à partir des futurs Squeeze avec ‘stop’ en K 
Les autres, ils demanderont pourquoi ça ne fonctionne pas 
J’ai modifié la phrase.
Bonjour,
Je suis sous Debian Squeeze et je viens de suivre ce tutoriel pour mettre en place un parefeu. Cependant la commande update-rc.d ne semble pas faire son boulot, en ce qui me concerne le parefeu aurait du avoir le numero 12 pour le démarrage et 8 pour l’arrêt mais j’obiens respectivement 18 et 1. De plus, je constate que les scripts ifupdown et networking ne sont présents que dans les runlevels S, 0 et 6.
En lisant les pages de ce sujet, j’ai appris qu’il fallait ajouter des commentaires au début des scripts d’inits, car l’ordre de ceux-ci est désormais gérer par dépendances. Je viens d’en ajouter dans mon script ainsi que dans le script ifupdown afin que le parfeu démarre avant et se stoppe après celui-ci. Cela semble fonctionner et je n’ai aucun warning de la part de update-rc.d.
Voici les commentaires pour le script de parefeu :
### BEGIN INIT INFO
# Provides: parefeu
# Required-Start: ifupdown-clean
# Required-Stop: $local_fs
# Default-Start: S
# Default-Stop: 0 6
# Short-Description: Start/Stop iptables
### END INIT INFOEt les modifications dans le script ifupdown :
### BEGIN INIT INFO
# Provides: ifupdown
# Required-Start: ifupdown-clean parefeu
# Required-Stop: $local_fs parefeu
# Default-Start: S
# Default-Stop: 0 6
# Short-Description: Prepare the system for taking up interfaces.
### END INIT INFOEnfin, concernant la commande update-rc.d, il ne faut apparemment utilisé l’option defaults que dans le cas où le scripts doit être executés aux runlevels 0, 1, 2, 3, 4, 5 et 6. Comme ifupdown est executé au runlevel S, 0 et 6 il faut les spécifiés.
Je ne suis pas certains que les nombres ont vraiment de l’importance puisqu’ils seront calculés suivant les dépendances, mais bon dans mon cas le bon emplacement était le 9 :
update-rc.d parefeu start 09 S . stop 09 0 6 .Avec ceci je n’obtiens aucun warning et mon script est bien positionné.
[quote=“Taurre”]De plus, je constate que les scripts ifupdown et networking ne sont présents que dans les runlevels S, 0 et 6. […]
Enfin, concernant la commande update-rc.d, il ne faut apparemment utilisé l’option defaults que dans le cas où le scripts doit être executés aux runlevels 0, 1, 2, 3, 4, 5 et 6. Comme ifupdown est executé au runlevel S, 0 et 6 il faut les spécifiés.[/quote]
Tout cela a déjà été expliqué dans cette discussion.
Merci pour les exemples d’en-tête de scripts d’init. A leur lecture, je trouve qu’il y a une lacune dans le système retenu par Debian : un script peut spécifier de quoi il dépend (pour démarrer après) mais pas quoi dépend de lui (pour démarrer avant). Cela t’a obligé à modifier d’autres scripts, ce qui n’est pas souhaitable vis à vis de l’indépendance des paquets. A moins qu’une telle possibilité existe déjà en fait ?
À noter qu’il y a des variables, on peut mettre $all dans les require pour démarrer un script en tout dernier j’imagine.
J’ai lu le man de insserv un peu vite, désolé 
Il existe en effet deux en-têtes X-Start-Before et X-Start-After qui permettent de le spécifier, je corrige donc l’en-tête de mon script de parefeu :
### BEGIN INIT INFO
# Provides: parefeu
# Required-Start: ifupdown-clean
# Required-Stop: $local_fs
# Default-Start: S
# Default-Stop: 0 6
# X-Start-Before: ifupdown
# X-Stop-After: ifupdown
# Short-Description: Start/Stop iptables
### END INIT INFOEt l’édition du script ifupdown n’est donc plus nécessaire.
C’est mieux, merci d’avoir cherché !
Question : pourquoi avoir choisi de le positionner par rapport à ifupdown plutôt que networking ?
En fait je ne m’y connais pas trop en réseau, je l’ai mit avant ce script parce que je pensais que c’était lui que se chargeais de lancer la commande ifup et donc de démarrer la connexion.
Non, c’est le script networking qui démarre les interfaces marquées auto. Le script ifupdown ne sert qu’à préparer le terrain pour les commandes ifup et ifdown.
Dans ce cas je m’excuse et je remodifie mes commentaires pour insserv :
### BEGIN INIT INFO
# Provides: parefeu
# Required-Start: ifupdown
# Required-Stop: $local_fs ifupdown
# Default-Start: S
# Default-Stop: 0 6
# X-Start-Before: networking
# X-Stop-After: networking
# Short-Description: Start/Stop iptables
### END INIT INFOMais juste pour savoir, cela pose problème si le parefeu démarre avant ifupdown ?
A priori non. Sa seule action semble concerner le fichier /etc/network/run/ifstate qui contient les informations d’état des interfaces pour ifup et ifdown.
D’accord, merci beaucoup pour toutes ces précisions et corrections 
Pascal, aucune modif ou ajout à prévoir dans le tuto, suite à cette intervention ?
Tu peux ajouter un paragraphe avec l’en-tête de script indiqué par Taurre en précisant que c’est pris en compte à partir de squeeze.
Oui, mais il a l’air d’avoir remarqué une lacune et pourtant, il précise au début qu’il est sous Squeeze ???
Ne pas perdre de vue que ce tuto s’adresse à des débutants et qu’il n’est ptet pas utile de les embrouiller.
D’autant plus qu’il s’est inspiré de “iptables pour les nuls”, sans suivre exactement à la lettre le tuto.
Je n’ai pas encore eu l’occasion de modifier le mien pour tester, il faudra que je le fasse.
D’un autre côté Squeeze est entré en phase de gel, ce qui veut dire que de plus en plus d’utilisateur vont migrer vers celle-ci, il serait bon de déjà prévoir un script fonctionnant avec insserv.
EDIT : Hé je viens de penser à quelque chose, les en-têtes de insserv sont bien des commentaires, donc si on les place dans le script cela ne devrait pas poser de problèmes sous Lenny non ? Comme cela on embrouille pas le débutant et cela fonctionne partout, la commande update-rc.d ne changeant pas.
Je l’ai suivi à la lettre au début, mais lorsque j’ai vu que le script n’était pas lancé au bon moment j’ai commencé à le modifier en ajoutant les commentaires pour insserv. Quant à la commande update-rc.d je l’utilise de la même manière que dans ce tuto, c’est juste que j’avais prit le script ifupdown comme référence et non networking.
[quote=“Taurre”][quote]
Oui, mais il a l’air d’avoir remarqué une lacune et pourtant, il précise au début qu’il est sous Squeeze ???
Ne pas perdre de vue que ce tuto s’adresse à des débutants et qu’il n’est ptet pas utile de les embrouiller.
[/quote]
D’un autre côté Squeeze est entré en phase de gel, ce qui veut dire que de plus en plus d’utilisateur vont migrer vers celle-ci, il serait bon de déjà prévoir un script fonctionnant avec insserv.
EDIT : Hé je viens de penser à quelque chose, les en-têtes de insserv sont bien des commentaires, donc si on les place dans le script cela ne devrait pas poser de problèmes sous Lenny non ? Comme cela on embrouille pas le débutant et cela fonctionne partout, la commande update-rc.d ne changeant pas.
Je l’ai suivi à la lettre au début, mais lorsque j’ai vu que le script n’était pas lancé au bon moment j’ai commencé à le modifier en ajoutant les commentaires pour insserv. Quant à la commande update-rc.d je l’utilise de la même manière que dans ce tuto, c’est juste que j’avais prit la script ifupdown comme référence et non networking.[/quote]
Je ne connais pas insserv mais je vais aller me renseigner.
Peux-tu me confirmer que le tuto, tel qu’il est écrit actuellement, ne pose pas de problème, avec ‘networking’ comme référence au lieu de ‘ifupdown’ ?
EDIT :
j’ai lu et compris de quoi il s’agissait et j’ai retenu ce lien du forum Ubuntu :
[quote]J’utilise Ubuntu depuis quelques jours et à chaque démarrage le message suivant apparait:
EXT3FS: recovery required on read-only filesystem …
Ce système de fichier est la racine (/) ce qui signifie que la racine n’est pas démontée correctement avant le reboot ou le stop.
Après investigation j’ai pu constaté qu’aucun système de fichier n’est démonté.
Le problème est du à l’utilisation de insserv. Commande qui m’a permis de désactiver certains services.
insserv à un bug sérieux semble-t-il. Lorsque l’on reboot on entre dans le runlevel 6, le système exécute les scripts présents dans le répertoire /etc/rc6.d, (en fait des liens vers les scripts de /etc/init.d) lançant d’abord ceux commençant par K puis ceux commençant par S. C’est un héritage de Unix System V. Chaque script se voit affecté un préfixe en K ou S et un numéro compris entre 00 et 99. Le système les lance dans l’ordre numérique puis lexicographique pour ceux ayant le même numéro.
Mais insserv attribue a reboot le préfixe S01 , alors qu’il attribue à umountfs, umountroot et sendsigs (arrêt des processus) le même numéro mais leur nom commence par u et s, ils sont donc lancés après. Donc le script /etc/init.d/reboot (tout comme /etc/init.d/halt dans le runlevel 0) redémarre (stop) sans avoir invité les processus restant à quitter et sans avoir démonté les systèmes de fichier montés.
Me voilà donc obligé de gérer les liens des répertoires /etc/rc6.d (reboot) et /etc/rc0.d (halt) à la main. A chaque utilisation de insserv ils sont perdus.
Si quelqu’un connait une meilleur solution merci de m’en informer.[/quote]
Que ce soit avec ifupdown ou networking comme référence, insserv fait bien son boulot chez moi.
Au fait c’est bizarre, il me semblait qu’Ubuntu n’utilisait pas insserv mais upstart (cf post de MisterFreeze page 11)? 
On est tous plus ou moins débutant en quelque chose. On peut être débutant en iptables et expérimenté en scripts d’init. En ce qui me concerne je ne me considère pas assez expérimenté pour toucher à squeeze tant qu’elle n’est pas passée stable.
Tu n’avais peut-être pas remarqué, mais ces en-têtes sont déjà présents dans les scripts d’init de lenny ainsi, même s’ils ne sont pas encore utilisés car le paquet insserv est disponible mais pas installé en standard.
A dire vrai, je ne me suis jamais intéressé aux scripts d’inits sous Lenny parce que j’utilisais le fichier /etc/rc.local pour executer mon script de parefeu.
C’est en voyant les avertissements de la commande update-rc.d sous Squeeze que j’ai commencé à m’y intéresser. Ce topic m’a d’ailleur beaucoup éclairer sur le sujet