Je rencontre un problème dans le paramétrage du firewall:
J'ai différentes configuration réseau à paramétrer.
J'ai donc fait un script shell qui met tout cela en place. Jusque là,
pas trop de soucis.
Ça ce complique lorsque j'attaque les réglages du firewall. En effet,
les règles sont, presque, toujours les mêmes.
Seules changent les adresses IP source et/ou destination (DNS par exemple).
J'envisageais donc de faire un script (au hasard, iptable_run) qui
définisse les variable (IP_DNS et autres par exemples), script que
j'aurais placé dans /etc/network/if-pre-up.d/ et qui lui-même aurait
appelé le script générique (disons iptable_generic) du firewall situé
ailleurs.
Problème, si j'arrive bien à appeler l'un à partir de l'autre, je
n'arrive pas à "propager" les variables définies dans le premier. Je
n'ai évidemment pas tellement envie d'exporter ces variables. Y
aurait-il une possibilité d'inclure le contenu de l'un dans l'autre ?
J'ai évidemment tenté la solution "en dur dans chaque script". Le
problème alors est de propager une modification des règles dans
plusieurs fichiers avec les risques d'erreurs inhérents (en même temps,
c'est un peu pour cela que je cherche une solution plus "propre").
Merci de vos réponses.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Sylvain Sauvage
Wed, 06 Oct 2004 18:22:21 +0200, Jean Baptiste FAVRE a écrit :
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Bonjour à tous,
Bonjour,
[...] J'ai évidemment tenté la solution "en dur dans chaque script". Le problème alors est de propager une modification des règles dans plusieurs fichiers avec les risques d'erreurs inhérents (en même temp s, c'est un peu pour cela que je cherche une solution plus "propre").
Tu mets tes variables dans un fichier unique (p.ex. mesvariables) et dans les scripts tu fais un « source mesvariables » au début.
-- Sylvain Sauvage
Wed, 06 Oct 2004 18:22:21 +0200, Jean Baptiste FAVRE a écrit :
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Bonjour à tous,
Bonjour,
[...]
J'ai évidemment tenté la solution "en dur dans chaque script". Le
problème alors est de propager une modification des règles dans
plusieurs fichiers avec les risques d'erreurs inhérents (en même temp s,
c'est un peu pour cela que je cherche une solution plus "propre").
Tu mets tes variables dans un fichier unique (p.ex. mesvariables) et dans
les scripts tu fais un « source mesvariables » au début.
Wed, 06 Oct 2004 18:22:21 +0200, Jean Baptiste FAVRE a écrit :
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Bonjour à tous,
Bonjour,
[...] J'ai évidemment tenté la solution "en dur dans chaque script". Le problème alors est de propager une modification des règles dans plusieurs fichiers avec les risques d'erreurs inhérents (en même temp s, c'est un peu pour cela que je cherche une solution plus "propre").
Tu mets tes variables dans un fichier unique (p.ex. mesvariables) et dans les scripts tu fais un « source mesvariables » au début.
-- Sylvain Sauvage
Jean Baptiste FAVRE
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Forcément, ça marche mieux qu' "include" ;-) Je vais regarder cela demain (c'est pour le boulot). Par hasard, juste en passant, on pourrait pas inverser (c-a-d définir les variables et faire un "source" ou équivalent du script iptables ?). Merci pour tout. FAVRE Jean Baptiste
Sylvain Sauvage a écrit : | Wed, 06 Oct 2004 18:22:21 +0200, Jean Baptiste FAVRE a écrit : | |>-----BEGIN PGP SIGNED MESSAGE----- |>Hash: SHA1 |> |>Bonjour à tous, | | | Bonjour, | | |>[...] |>J'ai évidemment tenté la solution "en dur dans chaque script". Le |>problème alors est de propager une modification des règles dans |>plusieurs fichiers avec les risques d'erreurs inhérents (en même temps, |>c'est un peu pour cela que je cherche une solution plus "propre"). | | | Tu mets tes variables dans un fichier unique (p.ex. mesvariables) et dans | les scripts tu fais un « source mesvariables » au début. |
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
-- Pensez à lire la FAQ de la liste avant de poser une question : http://wiki.debian.net/?DebianFrench
Pensez à rajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"
To UNSUBSCRIBE, email to with a subject of "unsubscribe". Trouble? Contact
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Forcément, ça marche mieux qu' "include" ;-)
Je vais regarder cela demain (c'est pour le boulot).
Par hasard, juste en passant, on pourrait pas inverser (c-a-d définir
les variables et faire un "source" ou équivalent du script iptables ?).
Merci pour tout.
FAVRE Jean Baptiste
Sylvain Sauvage a écrit :
| Wed, 06 Oct 2004 18:22:21 +0200, Jean Baptiste FAVRE a écrit :
|
|>-----BEGIN PGP SIGNED MESSAGE-----
|>Hash: SHA1
|>
|>Bonjour à tous,
|
|
| Bonjour,
|
|
|>[...]
|>J'ai évidemment tenté la solution "en dur dans chaque script". Le
|>problème alors est de propager une modification des règles dans
|>plusieurs fichiers avec les risques d'erreurs inhérents (en même temps,
|>c'est un peu pour cela que je cherche une solution plus "propre").
|
|
| Tu mets tes variables dans un fichier unique (p.ex. mesvariables) et dans
| les scripts tu fais un « source mesvariables » au début.
|
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
Forcément, ça marche mieux qu' "include" ;-) Je vais regarder cela demain (c'est pour le boulot). Par hasard, juste en passant, on pourrait pas inverser (c-a-d définir les variables et faire un "source" ou équivalent du script iptables ?). Merci pour tout. FAVRE Jean Baptiste
Sylvain Sauvage a écrit : | Wed, 06 Oct 2004 18:22:21 +0200, Jean Baptiste FAVRE a écrit : | |>-----BEGIN PGP SIGNED MESSAGE----- |>Hash: SHA1 |> |>Bonjour à tous, | | | Bonjour, | | |>[...] |>J'ai évidemment tenté la solution "en dur dans chaque script". Le |>problème alors est de propager une modification des règles dans |>plusieurs fichiers avec les risques d'erreurs inhérents (en même temps, |>c'est un peu pour cela que je cherche une solution plus "propre"). | | | Tu mets tes variables dans un fichier unique (p.ex. mesvariables) et dans | les scripts tu fais un « source mesvariables » au début. |
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
-- Pensez à lire la FAQ de la liste avant de poser une question : http://wiki.debian.net/?DebianFrench
Pensez à rajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"
To UNSUBSCRIBE, email to with a subject of "unsubscribe". Trouble? Contact
Sylvain Sauvage
Wed, 06 Oct 2004 20:31:04 +0200, Jean Baptiste FAVRE a écrit :
[...] Forcément, ça marche mieux qu' "include" ;-) Je vais regarder cela demain (c'est pour le boulot). Par hasard, juste en passant, on pourrait pas inverser (c-a-d définir les variables et faire un "source" ou équivalent du script iptables ?).
Ben si, ça marche aussi. « source » (ou « . » dans certains shell s, notamment bash) correspond à un « include ». On notera donc que, gé nie lociellement parlant, ce qui est « includé » est ce qui est réutili sable (en général fonctions et autres définitions). On peut donc, en gros, voir trois parties dans un logiciel : - les paramètres (configuration) ; - les définitions réutilisables (fonctions, structures, etc.) ; - le corps (non réutilisable).
Dans ton cas, tu peux faire : {{ toto="coucou" source <le script générique qui utilise $toto> }} ce qui fait que tu dois modifier le script pour changer les paramètres,
ou : {{ source <fonctions qui utilisent $1, $2...> ma_fonction "toto" "tutu" }} idem mais point de vue inversé et plus langage de programmation (les fonctions sont plus génériques : elles ne sont pas liées à des vari ables globales),
ou, plus modulaire : {{ source <fonctions qui utilisent $1, $2...> source <paramètres> ma_fonction $toto $tutu }} ce qui fait que les fonctions et le script principal ne sont pas modifiés, seul le fichier de paramètres est à modifier (plus propre à mon avis : on peut placer les paramètres dans /etc et les scripts dans des répertoires en read-only (genre /usr/local/sbin)).
Bon courage, -- Sylvain Sauvage
Wed, 06 Oct 2004 20:31:04 +0200, Jean Baptiste FAVRE a écrit :
[...]
Forcément, ça marche mieux qu' "include" ;-)
Je vais regarder cela demain (c'est pour le boulot).
Par hasard, juste en passant, on pourrait pas inverser (c-a-d définir
les variables et faire un "source" ou équivalent du script iptables ?).
Ben si, ça marche aussi. « source » (ou « . » dans certains shell s,
notamment bash) correspond à un « include ». On notera donc que, gé nie
lociellement parlant, ce qui est « includé » est ce qui est réutili sable
(en général fonctions et autres définitions).
On peut donc, en gros, voir trois parties dans un logiciel :
- les paramètres (configuration) ;
- les définitions réutilisables (fonctions, structures, etc.) ;
- le corps (non réutilisable).
Dans ton cas, tu peux faire :
{{
toto="coucou"
source <le script générique qui utilise $toto>
}}
ce qui fait que tu dois modifier le script pour changer les paramètres,
ou :
{{
source <fonctions qui utilisent $1, $2...>
ma_fonction "toto" "tutu"
}}
idem mais point de vue inversé et plus langage de programmation (les
fonctions sont plus génériques : elles ne sont pas liées à des vari ables
globales),
ou, plus modulaire :
{{
source <fonctions qui utilisent $1, $2...>
source <paramètres>
ma_fonction $toto $tutu
}}
ce qui fait que les fonctions et le script principal ne sont pas modifiés,
seul le fichier de paramètres est à modifier (plus propre à mon avis :
on peut placer les paramètres dans /etc et les scripts dans des
répertoires en read-only (genre /usr/local/sbin)).
Wed, 06 Oct 2004 20:31:04 +0200, Jean Baptiste FAVRE a écrit :
[...] Forcément, ça marche mieux qu' "include" ;-) Je vais regarder cela demain (c'est pour le boulot). Par hasard, juste en passant, on pourrait pas inverser (c-a-d définir les variables et faire un "source" ou équivalent du script iptables ?).
Ben si, ça marche aussi. « source » (ou « . » dans certains shell s, notamment bash) correspond à un « include ». On notera donc que, gé nie lociellement parlant, ce qui est « includé » est ce qui est réutili sable (en général fonctions et autres définitions). On peut donc, en gros, voir trois parties dans un logiciel : - les paramètres (configuration) ; - les définitions réutilisables (fonctions, structures, etc.) ; - le corps (non réutilisable).
Dans ton cas, tu peux faire : {{ toto="coucou" source <le script générique qui utilise $toto> }} ce qui fait que tu dois modifier le script pour changer les paramètres,
ou : {{ source <fonctions qui utilisent $1, $2...> ma_fonction "toto" "tutu" }} idem mais point de vue inversé et plus langage de programmation (les fonctions sont plus génériques : elles ne sont pas liées à des vari ables globales),
ou, plus modulaire : {{ source <fonctions qui utilisent $1, $2...> source <paramètres> ma_fonction $toto $tutu }} ce qui fait que les fonctions et le script principal ne sont pas modifiés, seul le fichier de paramètres est à modifier (plus propre à mon avis : on peut placer les paramètres dans /etc et les scripts dans des répertoires en read-only (genre /usr/local/sbin)).
