Digression Installation parefeu (iptables & ip6tables) "pour les nuls"

Support Debian
#241

[quote=“PascalHambourg”]Les runlevels 2 à 5 permettent de définir différents services à démarrer pour chacun. Par exemple comme je l’ai décrit précédemment, un mode graphique et un mode texte. Pour faire cela avec Debian, il faudrait transformer le lien de démarrage (S) de gdm (si c’est gdm qui démarre X) en un lien d’arrêt (K) dans le runlevel 3 ; ainsi quand on démarre en runlevel 3 on est en mode texte et quand on démarre en runlevel 2 on est en mode graphique.

A la limite, on pourrait imaginer une machine qui démarre des services totalement différents selon le runlevel.

Quant à l’avantage d’utilise l’un plutôt que l’autre, s’ils sont identiques il n’y en a pas. J’ai dit plus haut que les runlevels 2 à 5 étaient identiques, mais vérification faite dans /etc/inittab ce n’est pas tout-à-fait vrai : par défaut ils démarrent les mêmes services mais les runlevels 2 et 3 démarrent 6 consoles virtuelles tty1 à tty6 alors que les autres runlevels ne démarrent que la console virtuelle tty1. Ne me demande pas pourquoi.[/quote]

Voilà en bleu ce qui me semblait le plus logique.
Merci pour toute la leçon.

#242

Ben je croyais avoir terminé mais non !

[quote=“PascalHambourg”]@ricardo :
…
Le réseau est arrêté par /etc/rc[06].d/[color=#0000FF]S[/color]35networking (voir particularité des runlevels 0 et 6 ci-dessus). Par conséquent pour arrêter le pare-feu plus tard, il faut “paradoxalement” créer dans ces deux runlevels un lien S (start) et non K (stop), avec un numéro plus grand que 35. Par exemple :

[/quote]

S ou K ?
star ou stop ?

#243

S et start. J’avais expliqué pourquoi :
“Les scripts K sont exécutés avec le paramètre stop et les scripts S avec le paramètre start, sauf dans les runlevels 0 (arrêt) et 6 (redémarrage) ou tous sont exécutés avec le paramètre stop.”

Hmm, ce n’est peut-être pas archi-clair. Je précise.
Il faut bien distinguer :

  • d’une part, les options start et stop d’update-rc.d qui vont créer des liens S ou K respectivement ;

  • d’autre part, le paramètre start ou stop qui va être passé par init aux scripts lors de l’entrée dans un runlevel. Dans les runlevels 0 et 6 c’est toujours stop même pour les scripts S contrairement aux autres runlevels où les scripts S sont exécutés avec start.

Alors pourquoi S plutôt que K si c’est stop de toute façon ? Pour l’ordre, les scripts K étant exécutés avant les scripts S.

#244

[quote=“PascalHambourg”]S et start. J’avais expliqué pourquoi :
“Les scripts K sont exécutés avec le paramètre stop et les scripts S avec le paramètre start, sauf dans les runlevels 0 (arrêt) et 6 (redémarrage) ou tous sont exécutés avec le paramètre stop.”[/quote]
Bon, je suis certainement bouché mais

les scripts S avec le paramètre start>>>
et en l’(occurrence, il s’agit d’arrêt

est [size=150]arrêté[/size] par /etc/rc[06].d/S35networking

Chez moi, dans 0 et 6, il n’y a que des K et aucun S

#245

Je me doutais que ce n’était pas très clair, alors j’ai édité mon message précédent.

#246

Ah ? Chez moi il y a des S. Ça vient peut-être de l’historique, toutes mes machines ont été installées avec des versions antérieures à lenny puis mises à niveau.

Tu peux copier le résultat d’un ls stp ?

Dans ce cas il faut adapter. Si le lien vers le script networking est de la forme KNNnetworking, alors il suffit de créer un lien K avec un nombre supérieur à NN.

#247

En effet, je n’avais pas lu d’EDIT.
Là, OK, c’est clair mais faut reconnaître que ce n’est pas facile à deviner.
Je crois maintenant, que j’arrive à la fin de ma compréhension.
“Une petit dernière pour la route”, comme on dit dans le Sud-Ouest :
Tu avais émis une réserve pour le niveau de Networking à partir de Squeeze.
Sur ma Debian fonctionnelle, je tourne sous Sid et Networking se trouve en
rcS.d = S15
et
rc0.d & rc6.d = Ko7
Est-ce que ces N° sont susceptibles d’être modifiés, et donc de remettre en cause le bon fonctionnement du parefeu ?

Conviendrait-il, dans le cas du tuto (que j’ai voulu le plus explicite possible, de façon à être assimilé par un débutant), de demander la vérification de ces niveaux, avant d’écrire la ligne en question ?

#248

Ah, donc il y a du changement dans les numéros. De toute façon, je n’ai pas tout suivi mais si j’ai bien compris l’ordonnancement des scripts d’init est complétement revu à partir de squeeze et n’est plus basé sur les numéros d’ordre mais sur des relations de dépendance, donc les numéros devraient perdre de leur intérêt.

Je pense qu’il est opportun de signaler cette réserve dans ton article et de demander de vérifier. De là à dire que le pare-feu ne fonctionnerait pas correctement, c’est beaucoup dire. S’il est démarré après le réseau, la machine ne sera pas protégée dans l’intervalle, c’est tout. En revanche s’il n’est pas arrêté avant le script halt ou reboot, le script d’arrêt risque de ne pas être exécuté et dans ce cas les règles iptables actives ne seront pas sauvegardées.

#249

[quote=“PascalHambourg”]Ah, donc il y a du changement dans les numéros. De toute façon, je n’ai pas tout suivi mais si j’ai bien compris l’ordonnancement des scripts d’init est complétement revu à partir de squeeze et n’est plus basé sur les numéros d’ordre mais sur des relations de dépendance, donc les numéros devraient perdre de leur intérêt.

Je pense qu’il est opportun de signaler cette réserve dans ton article et de demander de vérifier. De là à dire que le pare-feu ne fonctionnerait pas correctement, c’est beaucoup dire. S’il est démarré après le réseau, la machine ne sera pas protégée dans l’intervalle, c’est tout. En revanche s’il n’est pas arrêté avant le script halt ou reboot, le script d’arrêt risque de ne pas être exécuté et dans ce cas les règles iptables actives ne seront pas sauvegardées.[/quote]

Ça t’intéresse d’avoir copie de tous ces runlevel ?

Ta dernière phrase (en bleu) me met la puce à l’oreille sur une mésaventure que j’avais subie, avec mon iptables-save qui ne renvoyait rien, à une certaine époque. Tout est revenu dans l’ordre depuis.

#250

Bah, pourquoi pas, merci.

#251

Je vais t’envoyer ça sur ton e-mail valide ici.
En attendant, tu ne m’as répondu sur le fait que ces niveau vont rester fixés à leur N° actuel ou il risquent de changer à chaque installation, voire MAJ ?

#252

Je ne sais pas comment ça se passe. Visiblement ça peut changer. De là à dire si ça peut changer lors d’une mise à niveau ou seulement lors d’une nouvelle installation, je n’en sais rien. A vrai dire je ne m’étais jamais penché sur la question.

#253

Donc, il faut bien que je mette en garde pour vérifier à la mise en œuvre et moi-même, je vais suivre après chaque MAJ.
Je t’ai envoyé copie mais je ne suis pas sûr de la réception de ton côté ???

#254

J’en ai même reçu deux ! Merci.

#255

En fait Debian va commencer à faire comme toutes les distributions actuelles, les scripts d’init seront lancés en parallèle. Bien sur comme on peut pas tout lancer en parallèle, il a des dépendances. Il y a une foule de technique pour faire ça maintenant :
[ul]
[li]upstart développé par Canonical qui marche par évènements (utilisé aussi par fedora)[/li]
[li]init-ng qui utilise des dépendances et utilise simple fichier de configuration[/li]
[li]insserv qui utilise des dépendances et un ensemble de script[/li][/ul]

Debian a choisi insserv. Il a l’avantage d’être compatible avec init. En fait pour être précis c’est une surcouche d’init. Chaque script défini ses dépendances, puis la commande update-rc.d va résoudre les dépendances et créer les liens qui vont bien pour init (donc avec toujours le même système de [KS]NNscript).

#256

Ca me semble être la meilleure des solutions, car cela permet une rétrocompatibilité tout en évoluant, sans forcément être obligé d’utiliser cette évolution. J’adore Debian :049

#257

Merci pour l’explication, MisterFreez. Je comprends mieux pourquoi les numéros des scripts dans les différents runlevels que m’a fait passer Ricardo sont aussi rapprochés (S01truc S02machin S03bidule…). Si j’ai bien suivi, ces numéros sont recalculés à chaque ajout ou suppression d’un script pour satisfaire les dépendances. Du coup, plus possible d’installer un script “à la sauvage”.

#258

C’est aussi mon avis mais je ne sais donc plus comment rédiger cette ligne, car même si le gus vérifie avant d’écrire son script, pour y mettre les données qui vont bien, si ces données sont modifiées au premier ajout, elles s’avèrent fausses.
Il faudrait donc un script qui, avant d’être lancé, va chercher le bon N° dans le bon runlevel, non ?

#259

C’est possible mais pas d’une fiabilité à toute épreuve

#260

Pascal, peux-tu vérifier si ce qui suit est cohérent avec nos échanges précédents …
[Pause café] …même si tu n’est pas Prof :mrgreen: ( Pour moi, est Prof, celui qui a une excellente connaissance d’un domaine et qui sait la transmettre pédagogiquement).[/Pause café]

[code]update-rc.d mon_parefeu start XX S . stop YY 0 6 .
(Respectez bien les espacements et les points)

(Remplacez XX par le nombre immédiatement inférieur à celui qui indique la priorité de ‘networking’ dans /etc/rcS.d.
($ ls /etc/rcS.d | grep Snetworking
(renvoie chez moi “S15networking”. Il conviendra donc de remplacer XX par 14
(Remplacez YY par le nombre immédiatement supérieur à celui qui indique la priorité de ‘networking’ dans /etc/rc0.d
($ ls /etc/rc0.d | grep Knetworking
(renvoie chez moi “K07networking”. Il conviendra donc de remplacer YY par 08[/code]

EDIT :
Une petite vérif de l’ensemble du tuto, pour voir si j’ai bien transcrit les autres modifications, serait aussi la bienvenue.
http://forum.debian-fr.org/viewtopic.php?f=8&t=1901&p=12172#p12172

EDIT 2 :
Complète aussi cette phrase d’explication ou modifie-la selon ton avis :
(Ainsi, le parefeu sera actif avant la connexion de xxxxxxxxxxxxxxx et le restera jusqu’à sa déconnexion)