Bonjour,

Sur une machine Debian AMD64, je rencontre un problème plutôt bizarre
avec un script iptables. Le script n'arrive pas à s'exécuter jusqu'au
bout et reste bloqué.

Je ne crois pas que ce soit un problème de syntaxe puisque je n'ai aucun
message d'erreur et que le dit script fonctionne sans problème sur une
autre machine ( Athlon XP ). Pire, je n'ai aucun soucis lorsque
j'exécute mes commandes iptables les unes après les autres à la main mais
vous vous doutez bien que c'est loin d'être pratique.

Si quelqu'un dans l'assemblée, à défaut d'avoir la solution, peut
m'indiquer dans quel sens chercher, je suis preneur :-)

Merci,

Oumar

--
One OS to rule them all,
One OS to find them.
One OS to call them all,
And in salvation bind them.
In the bright land of Linux,
Where the hackers play.
(J. Scott Thayer, with apologies to J.R.R.T.)

Le samedi 30 juin 2007 13:05, Oumar Niane a écrit:
> Bonjour,
>
> Sur une machine Debian AMD64, je rencontre un problème plutôt bizarre
> avec un script iptables. Le script n'arrive pas à s'exécuter jusqu'au
> bout et reste bloqué.
>
> Je ne crois pas que ce soit un problème de syntaxe puisque je n'ai aucun
> message d'erreur et que le dit script fonctionne sans problème sur une
> autre machine ( Athlon XP ). Pire, je n'ai aucun soucis lorsque
> j'exécute mes commandes iptables les unes après les autres à la main mais
> vous vous doutez bien que c'est loin d'être pratique.
>
> Si quelqu'un dans l'assemblée, à défaut d'avoir la solution, peut
> m'indiquer dans quel sens chercher, je suis preneur :-)

J'imagine que les logs ont déjà été regardés ...
Entre chaque lignes (je suppose que c'est un batch qui lance les commandes)
faire un
sleep 1s ; echo "Etape X à venir ...."

histoire de voir à quelle ligne cela bloque (voir si c'est la ligne précédante
qui entre en conflit temporelle avec la ligne courante)

Le samedi 30 juin 2007 13:05, Oumar Niane a écrit:
> Bonjour,
>
> Sur une machine Debian AMD64, je rencontre un problème plutôt bizarre
> avec un script iptables. Le script n'arrive pas à s'exécuter jusqu'au
> bout et reste bloqué.
>
> Je ne crois pas que ce soit un problème de syntaxe puisque je n'ai aucun
> message d'erreur et que le dit script fonctionne sans problème sur une
> autre machine ( Athlon XP ). Pire, je n'ai aucun soucis lorsque
> j'exécute mes commandes iptables les unes après les autres à la main mais
> vous vous doutez bien que c'est loin d'être pratique.
>
> Si quelqu'un dans l'assemblée, à défaut d'avoir la solution, peut
> m'indiquer dans quel sens chercher, je suis preneur :-)

J'imagine que les logs ont déjà été regardés ...
Entre chaque lignes (je suppose que c'est un batch qui lance les commandes)
faire un
sleep 1s ; echo "Etape X à venir ...."

histoire de voir à quelle ligne cela bloque (voir si c'est la ligne précédante
qui entre en conflit temporelle avec la ligne courante)

On Sat, Jun 30, 2007 at 01:16:41PM +0200, Bulot Grégory wrote :
>
> J'imagine que les logs ont déjà été regardés ...

Oui et il sont drôlement silencieux sur le sujet :-( . Juste ces trois
lignes:

ip_tables: (C) 2000-2006 Netfilter Core Team
Netfilter messages via NETLINK v0.30.
ip_conntrack version 2.4 (3071 buckets, 24568 max) - 304 bytes per conntrack

> Entre chaque lignes (je suppose que c'est un batch qui lance les commandes)
> faire un
> sleep 1s ; echo "Etape X à venir ...."
>
> histoire de voir à quelle ligne cela bloque

J'avais déjà fait un truc de ce style ( sans le sleep 1s ) et si tu
consultes le script que j'avais joint à mon mail précédent, il bloque
après la ligne 77 ( iptables -N in_accept ) . Je ne crois pas
que ce soit une instruction particulière qui pose problème puisque si je
commente cette ligne, il bloque sur la suivante et ainsi de suite.

Merci pour ta réponse,

Oumar

--
One OS to rule them all,
One OS to find them.
One OS to call them all,
And in salvation bind them.
In the bright land of Linux,
Where the hackers play.
(J. Scott Thayer, with apologies to J.R.R.T.)


--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.net/?DebianFrench
Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et
"Reply-To:"

To UNSUBSCRIBE, email to debian-user-french-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

On Sat, Jun 30, 2007 at 01:16:41PM +0200, Bulot Grégory wrote :
>
> J'imagine que les logs ont déjà été regardés ...

Oui et il sont drôlement silencieux sur le sujet :-( . Juste ces trois
lignes:

ip_tables: (C) 2000-2006 Netfilter Core Team
Netfilter messages via NETLINK v0.30.
ip_conntrack version 2.4 (3071 buckets, 24568 max) - 304 bytes per conntrack

> Entre chaque lignes (je suppose que c'est un batch qui lance les commandes)
> faire un
> sleep 1s ; echo "Etape X à venir ...."
>
> histoire de voir à quelle ligne cela bloque

J'avais déjà fait un truc de ce style ( sans le sleep 1s ) et si tu
consultes le script que j'avais joint à mon mail précédent, il bloque
après la ligne 77 ( iptables -N in_accept ) . Je ne crois pas
que ce soit une instruction particulière qui pose problème puisque si je
commente cette ligne, il bloque sur la suivante et ainsi de suite.

Merci pour ta réponse,

Oumar

--
One OS to rule them all,
One OS to find them.
One OS to call them all,
And in salvation bind them.
In the bright land of Linux,
Where the hackers play.
(J. Scott Thayer, with apologies to J.R.R.T.)


--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.net/?DebianFrench
Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et
"Reply-To:"

To UNSUBSCRIBE, email to debian-user-french-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

On Sat, Jun 30, 2007 at 02:22:03PM +0200, Oumar Niane wrote:
> On Sat, Jun 30, 2007 at 01:16:41PM +0200, Bulot Grégory wrote :
> >
> > Entre chaque lignes (je suppose que c'est un batch qui lance les commandes)
> > faire un
> > sleep 1s ; echo "Etape X Ã venir ...."
> >
> > histoire de voir à quelle ligne cela bloque
>
> J'avais déjà fait un truc de ce style ( sans le sleep 1s ) et si tu
> consultes le script que j'avais joint à mon mail précédent, il bloque
> après la ligne 77 ( iptables -N in_accept ) . Je ne crois pas
> que ce soit une instruction particulière qui pose problème puisque si je
> commente cette ligne, il bloque sur la suivante et ainsi de suite.
>

En regardant le script à Pascal :p! je ne vois pas ce qui pourrait
engendrer un tel problème. Tu peux aussi mettre en évidence ce que
iptables à charger avec la commande _iptables -L -v_.

--
Franck Joncourt
http://www.debian.org - http://smhteam.info/wiki/
GPG server : pgpkeys.mit.edu
Fingerprint : C10E D1D0 EF70 0A2A CACF 9A3C C490 534E 75C0 89FE

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFGhlenxJBTTnXAif4RAiv3AJ9SGH41D7GBbSX+uzp/7W08kVNYWQCgxOj/
wjWw0ypRq6Ykr7xLG3hyYtI=
=iK65
-----END PGP SIGNATURE-----

On Sat, Jun 30, 2007 at 02:22:03PM +0200, Oumar Niane wrote:
> On Sat, Jun 30, 2007 at 01:16:41PM +0200, Bulot Grégory wrote :
> >
> > Entre chaque lignes (je suppose que c'est un batch qui lance les commandes)
> > faire un
> > sleep 1s ; echo "Etape X Ã venir ...."
> >
> > histoire de voir à quelle ligne cela bloque
>
> J'avais déjà fait un truc de ce style ( sans le sleep 1s ) et si tu
> consultes le script que j'avais joint à mon mail précédent, il bloque
> après la ligne 77 ( iptables -N in_accept ) . Je ne crois pas
> que ce soit une instruction particulière qui pose problème puisque si je
> commente cette ligne, il bloque sur la suivante et ainsi de suite.
>

En regardant le script à Pascal :p! je ne vois pas ce qui pourrait
engendrer un tel problème. Tu peux aussi mettre en évidence ce que
iptables à charger avec la commande _iptables -L -v_.

--
Franck Joncourt
http://www.debian.org - http://smhteam.info/wiki/
GPG server : pgpkeys.mit.edu
Fingerprint : C10E D1D0 EF70 0A2A CACF 9A3C C490 534E 75C0 89FE

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFGhlenxJBTTnXAif4RAiv3AJ9SGH41D7GBbSX+uzp/7W08kVNYWQCgxOj/
wjWw0ypRq6Ykr7xLG3hyYtI=
=iK65
-----END PGP SIGNATURE-----

Oumar Niane wrote:
> On Sat, Jun 30, 2007 at 01:16:41PM +0200, Bulot Grégory wrote :
>
>> J'imagine que les logs ont déjà été regardés ...
>>
>
> Oui et il sont drôlement silencieux sur le sujet :-( . Juste ces trois
> lignes:
>
> ip_tables: (C) 2000-2006 Netfilter Core Team
> Netfilter messages via NETLINK v0.30.
> ip_conntrack version 2.4 (3071 buckets, 24568 max) - 304 bytes per conntrack
>
>
>> Entre chaque lignes (je suppose que c'est un batch qui lance les commandes)
>> faire un
>> sleep 1s ; echo "Etape X à venir ...."
>>
>> histoire de voir à quelle ligne cela bloque
>>
>
> J'avais déjà fait un truc de ce style ( sans le sleep 1s ) et si tu
> consultes le script que j'avais joint à mon mail précédent, il bloque
> après la ligne 77 ( iptables -N in_accept ) . Je ne crois pas
> que ce soit une instruction particulière qui pose problème puisque si je
> commente cette ligne, il bloque sur la suivante et ainsi de suite.
>

si je ne me trompe, juste après, le script execute:

/etc/network/firewall/fw_accept

il faut donc regarder dedans ce qui peut prendre du temps. regarde si ta
machine attend quelque chose du réseau (dns, dhcp, ... etc). c'est le
genre de trucs qui peuvent ralentir (et si en plus, les paquest
correspondants sont drop'és quelque part dans leur chemin, alors, ça
dure encore plus longtemps, puisqu'il faut attendre un timeout).



--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.net/?DebianFrench
Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et
"Reply-To:"

To UNSUBSCRIBE, email to debian-user-french-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Oumar Niane wrote:
> On Sat, Jun 30, 2007 at 01:16:41PM +0200, Bulot Grégory wrote :
>
>> J'imagine que les logs ont déjà été regardés ...
>>
>
> Oui et il sont drôlement silencieux sur le sujet :-( . Juste ces trois
> lignes:
>
> ip_tables: (C) 2000-2006 Netfilter Core Team
> Netfilter messages via NETLINK v0.30.
> ip_conntrack version 2.4 (3071 buckets, 24568 max) - 304 bytes per conntrack
>
>
>> Entre chaque lignes (je suppose que c'est un batch qui lance les commandes)
>> faire un
>> sleep 1s ; echo "Etape X à venir ...."
>>
>> histoire de voir à quelle ligne cela bloque
>>
>
> J'avais déjà fait un truc de ce style ( sans le sleep 1s ) et si tu
> consultes le script que j'avais joint à mon mail précédent, il bloque
> après la ligne 77 ( iptables -N in_accept ) . Je ne crois pas
> que ce soit une instruction particulière qui pose problème puisque si je
> commente cette ligne, il bloque sur la suivante et ainsi de suite.
>

si je ne me trompe, juste après, le script execute:

/etc/network/firewall/fw_accept

il faut donc regarder dedans ce qui peut prendre du temps. regarde si ta
machine attend quelque chose du réseau (dns, dhcp, ... etc). c'est le
genre de trucs qui peuvent ralentir (et si en plus, les paquest
correspondants sont drop'és quelque part dans leur chemin, alors, ça
dure encore plus longtemps, puisqu'il faut attendre un timeout).



--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.net/?DebianFrench
Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et
"Reply-To:"

To UNSUBSCRIBE, email to debian-user-french-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

On Sat, Jun 30, 2007 at 03:25:53PM +0200, mouss wrote:
> Oumar Niane wrote:
>
> si je ne me trompe, juste après, le script execute:
>
> /etc/network/firewall/fw_accept
>
> il faut donc regarder dedans ce qui peut prendre du temps. regarde si ta
> machine attend quelque chose du réseau (dns, dhcp, ... etc). c'est le
> genre de trucs qui peuvent ralentir (et si en plus, les paquest
> correspondants sont drop'és quelque part dans leur chemin, alors, ça
> dure encore plus longtemps, puisqu'il faut attendre un timeout).
>

Il n'y a rien de méchant la dedans non plus :

http://www.plouf.fr.eu.org/bazar/net...veur/fw_accept

Cela permet de recharger les règles associées au serveur sans relancer
tout le script firewall.

C'est vrai qu'il a peut-être ajouté quelque chose en plus dedans qui
fait que cela plante.

--
Franck Joncourt
http://www.debian.org - http://smhteam.info/wiki/
GPG server : pgpkeys.mit.edu
Fingerprint : C10E D1D0 EF70 0A2A CACF 9A3C C490 534E 75C0 89FE

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFGhmG2xJBTTnXAif4RAj9uAJ9/KI04j+MLqy9+SF1M5QaR7gpQkQCgxynd
07WGVCfRCRhzX9Feg7tivmk=
=VETe
-----END PGP SIGNATURE-----

On Sat, Jun 30, 2007 at 03:25:53PM +0200, mouss wrote:
> Oumar Niane wrote:
>
> si je ne me trompe, juste après, le script execute:
>
> /etc/network/firewall/fw_accept
>
> il faut donc regarder dedans ce qui peut prendre du temps. regarde si ta
> machine attend quelque chose du réseau (dns, dhcp, ... etc). c'est le
> genre de trucs qui peuvent ralentir (et si en plus, les paquest
> correspondants sont drop'és quelque part dans leur chemin, alors, ça
> dure encore plus longtemps, puisqu'il faut attendre un timeout).
>

Il n'y a rien de méchant la dedans non plus :

http://www.plouf.fr.eu.org/bazar/net...veur/fw_accept

Cela permet de recharger les règles associées au serveur sans relancer
tout le script firewall.

C'est vrai qu'il a peut-être ajouté quelque chose en plus dedans qui
fait que cela plante.

--
Franck Joncourt
http://www.debian.org - http://smhteam.info/wiki/
GPG server : pgpkeys.mit.edu
Fingerprint : C10E D1D0 EF70 0A2A CACF 9A3C C490 534E 75C0 89FE

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFGhmG2xJBTTnXAif4RAj9uAJ9/KI04j+MLqy9+SF1M5QaR7gpQkQCgxynd
07WGVCfRCRhzX9Feg7tivmk=
=VETe
-----END PGP SIGNATURE-----

On Sat, Jun 30, 2007 at 04:36:40PM +0200, Oumar Niane wrote:
> On Sat, Jun 30, 2007 at 03:59:18PM +0200, Franck Joncourt wrote :
> > On Sat, Jun 30, 2007 at 03:25:53PM +0200, mouss wrote:
> > > Oumar Niane wrote:
> > >
> > > si je ne me trompe, juste après, le script execute:
> > >
> > > /etc/network/firewall/fw_accept
> > >
> > > il faut donc regarder dedans ce qui peut prendre du temps. regarde sita
> > > machine attend quelque chose du réseau (dns, dhcp, ... etc). c'est le
> > > genre de trucs qui peuvent ralentir (et si en plus, les paquest
> > > correspondants sont drop'és quelque part dans leur chemin, alors, ça
> > > dure encore plus longtemps, puisqu'il faut attendre un timeout).
> > >
> >
> > Il n'y a rien de méchant la dedans non plus :
> >
> > http://www.plouf.fr.eu.org/bazar/net...veur/fw_accept
> >
> > Cela permet de recharger les règles associées au serveur sansrelancer
> > tout le script firewall.
> >
> > C'est vrai qu'il a peut-être ajouté quelque chose en plus dedans qui
> > fait que cela plante.
>
> Non, j'autorise juste le ssh. Encore une fois, le script fonctionne très
> bien sur une autre machine x86 sous etch également avec le mêmelot de
> paquets et les mêmes fichiers de conf puisque je suis en train de faire
> une migration de cette machine vers l'AMD64.
>
> Existe-t-il un mode DEBUG ou un truc du genre avec iptables ?
>


Non, pas à ma connaissance.
A part, mettre des commentaires dans le code pour mettre en évidence le
problème, fouillez du côté de la sortie de la commande iptables -L -v
pour connaire les différentes règles chargées, je sèche.

Si tu ne charges pas le fichier fw_accept, est-ce que cela fonctionne ?
Si oui, le chargé après pose t-il le même problème (pasdans le même
script) ?

iptables n'a rien avoir avec ton architecture. Il se charge très bien
chez moi. 2.6.21 amd64. Aurais tu recompilé ton noyau et oublié certaines
options ? Il devrait te mettre au moins un message.

Peut tu poster ton fichier fw_accept au cas où ?

--
Franck Joncourt
http://www.debian.org - http://smhteam.info/wiki/
GPG server : pgpkeys.mit.edu
Fingerprint : C10E D1D0 EF70 0A2A CACF 9A3C C490 534E 75C0 89FE

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFGhncLxJBTTnXAif4RAvSmAJ9QI400a1SOLPBQ4WsIR1 qqxq0tdQCfer0b
86zh4MmcNRvBQnXgCS4TA5U=
=wrvG
-----END PGP SIGNATURE-----

On Sat, Jun 30, 2007 at 04:36:40PM +0200, Oumar Niane wrote:
> On Sat, Jun 30, 2007 at 03:59:18PM +0200, Franck Joncourt wrote :
> > On Sat, Jun 30, 2007 at 03:25:53PM +0200, mouss wrote:
> > > Oumar Niane wrote:
> > >
> > > si je ne me trompe, juste après, le script execute:
> > >
> > > /etc/network/firewall/fw_accept
> > >
> > > il faut donc regarder dedans ce qui peut prendre du temps. regarde sita
> > > machine attend quelque chose du réseau (dns, dhcp, ... etc). c'est le
> > > genre de trucs qui peuvent ralentir (et si en plus, les paquest
> > > correspondants sont drop'és quelque part dans leur chemin, alors, ça
> > > dure encore plus longtemps, puisqu'il faut attendre un timeout).
> > >
> >
> > Il n'y a rien de méchant la dedans non plus :
> >
> > http://www.plouf.fr.eu.org/bazar/net...veur/fw_accept
> >
> > Cela permet de recharger les règles associées au serveur sansrelancer
> > tout le script firewall.
> >
> > C'est vrai qu'il a peut-être ajouté quelque chose en plus dedans qui
> > fait que cela plante.
>
> Non, j'autorise juste le ssh. Encore une fois, le script fonctionne très
> bien sur une autre machine x86 sous etch également avec le mêmelot de
> paquets et les mêmes fichiers de conf puisque je suis en train de faire
> une migration de cette machine vers l'AMD64.
>
> Existe-t-il un mode DEBUG ou un truc du genre avec iptables ?
>


Non, pas à ma connaissance.
A part, mettre des commentaires dans le code pour mettre en évidence le
problème, fouillez du côté de la sortie de la commande iptables -L -v
pour connaire les différentes règles chargées, je sèche.

Si tu ne charges pas le fichier fw_accept, est-ce que cela fonctionne ?
Si oui, le chargé après pose t-il le même problème (pasdans le même
script) ?

iptables n'a rien avoir avec ton architecture. Il se charge très bien
chez moi. 2.6.21 amd64. Aurais tu recompilé ton noyau et oublié certaines
options ? Il devrait te mettre au moins un message.

Peut tu poster ton fichier fw_accept au cas où ?

--
Franck Joncourt
http://www.debian.org - http://smhteam.info/wiki/
GPG server : pgpkeys.mit.edu
Fingerprint : C10E D1D0 EF70 0A2A CACF 9A3C C490 534E 75C0 89FE

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFGhncLxJBTTnXAif4RAvSmAJ9QI400a1SOLPBQ4WsIR1 qqxq0tdQCfer0b
86zh4MmcNRvBQnXgCS4TA5U=
=wrvG
-----END PGP SIGNATURE-----

Le samedi 30 juin 2007 14:22, Oumar Niane a écrit:
> J'avais déjà fait un truc de ce style ( sans le sleep 1s ) et si tu
> consultes le script que j'avais joint à mon mail précédent, il bloque
> après la ligne 77 ( iptables -N in_accept ) . Je ne crois pas ...


Milles excuses, j'avais pas fait attention à la pièce jointe

Le samedi 30 juin 2007 14:22, Oumar Niane a écrit:
> J'avais déjà fait un truc de ce style ( sans le sleep 1s ) et si tu
> consultes le script que j'avais joint à mon mail précédent, il bloque
> après la ligne 77 ( iptables -N in_accept ) . Je ne crois pas ...


Milles excuses, j'avais pas fait attention à la pièce jointe

Salut,

Oumar Niane a écrit :
>
> Sur une machine Debian AMD64, je rencontre un problème plutôt bizarre
> avec un script iptables. Le script n'arrive pas à s'exécuter jusqu'au
> bout et reste bloqué.
>
> Je ne crois pas que ce soit un problème de syntaxe puisque je n'ai aucun
> message d'erreur et que le dit script fonctionne sans problème sur une
> autre machine ( Athlon XP ). Pire, je n'ai aucun soucis lorsque
> j'exécute mes commandes iptables les unes après les autres à la main mais
> vous vous doutez bien que c'est loin d'être pratique.
>
> Si quelqu'un dans l'assemblée, à défaut d'avoir la solution, peut
> m'indiquer dans quel sens chercher, je suis preneur :-)

Vu qu'il paraît que je suis l'auteur initial de ce script, je me sens un
peu obligé de répondre, bien que n'ayant pas de solution à proposer. Et
je n'ai aucun moyen de tester, ne disposant pas d'une machine AMD64.

Pour la petite histoire, je ne suis pas sûr d'avoir jamais testé ce
script. Je l'avais écrit pour le serveur hébergé d'un ami qui n'en a
finalement pas voulu, prétextant qu'il n'avait pas vraiment besoin d'un
firewall (pas totalement faux puisque déjà seuls les services voulus
étaient ouverts à l'extérieur) et qu'il avait peur de verrouiller la
machine en cas de fausse manip.

Au chapitre des raisons possibles du blocage, je n'ai guère d'idées.
Il y a déjà eu des bugs d'ABI en 64 bits entre iptables et le noyau,
mais le fait que les commandes passent à la main infirme cette hypothèse.

Il a aussi été constaté que parfois la création de règles iptables
pouvait être anormalement longue, mais il me semble que cela concerne
plutôt iptables-restore. As-tu essayé d'attendre un peu pour voir ce qui
se passe ? Ou de surveiller les appels système de la commande qui bloque
avec strace ?

L'interpréteur de commande est-il le même en console et dans le script ?
En général /bin/sh est un lien symbolique qui pointe sur bash, peut-être
est-ce différent sur ta Debian amd64. Au fait, c'est bien une Debian
amd64 et non juste une Debian i386 installée sur une machine AMD64 ?


--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.net/?DebianFrench
Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et
"Reply-To:"

To UNSUBSCRIBE, email to debian-user-french-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Salut,

Oumar Niane a écrit :
>
> Sur une machine Debian AMD64, je rencontre un problème plutôt bizarre
> avec un script iptables. Le script n'arrive pas à s'exécuter jusqu'au
> bout et reste bloqué.
>
> Je ne crois pas que ce soit un problème de syntaxe puisque je n'ai aucun
> message d'erreur et que le dit script fonctionne sans problème sur une
> autre machine ( Athlon XP ). Pire, je n'ai aucun soucis lorsque
> j'exécute mes commandes iptables les unes après les autres à la main mais
> vous vous doutez bien que c'est loin d'être pratique.
>
> Si quelqu'un dans l'assemblée, à défaut d'avoir la solution, peut
> m'indiquer dans quel sens chercher, je suis preneur :-)

Vu qu'il paraît que je suis l'auteur initial de ce script, je me sens un
peu obligé de répondre, bien que n'ayant pas de solution à proposer. Et
je n'ai aucun moyen de tester, ne disposant pas d'une machine AMD64.

Pour la petite histoire, je ne suis pas sûr d'avoir jamais testé ce
script. Je l'avais écrit pour le serveur hébergé d'un ami qui n'en a
finalement pas voulu, prétextant qu'il n'avait pas vraiment besoin d'un
firewall (pas totalement faux puisque déjà seuls les services voulus
étaient ouverts à l'extérieur) et qu'il avait peur de verrouiller la
machine en cas de fausse manip.

Au chapitre des raisons possibles du blocage, je n'ai guère d'idées.
Il y a déjà eu des bugs d'ABI en 64 bits entre iptables et le noyau,
mais le fait que les commandes passent à la main infirme cette hypothèse.

Il a aussi été constaté que parfois la création de règles iptables
pouvait être anormalement longue, mais il me semble que cela concerne
plutôt iptables-restore. As-tu essayé d'attendre un peu pour voir ce qui
se passe ? Ou de surveiller les appels système de la commande qui bloque
avec strace ?

L'interpréteur de commande est-il le même en console et dans le script ?
En général /bin/sh est un lien symbolique qui pointe sur bash, peut-être
est-ce différent sur ta Debian amd64. Au fait, c'est bien une Debian
amd64 et non juste une Debian i386 installée sur une machine AMD64 ?


--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.net/?DebianFrench
Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et
"Reply-To:"

To UNSUBSCRIBE, email to debian-user-french-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Salut,

J'ai réussi à résoudre le problème en autorisant le trafic sur
l'interface de loopback toute suite après l'initialisation de,
tables et des paramètres noyau. Je n'ai pas pour autant compris
ce qui clochait :-(.

On Sun, Jul 01, 2007 at 04:19:08PM +0200, Pascal Hambourg wrote :
> Vu qu'il paraît que je suis l'auteur initial de ce script,

Rendons à César ce qui est à César :-) . En tout cas, merci pour ce
script car il m'a rendu bien des services.

> As-tu essayé d'attendre un peu pour voir ce qui se passe ?

Rien au bout de 5min

> Ou de surveiller les appels système de la commande qui bloque
> avec strace ?

Les 18 dernières lignes:

read(255, "iptables -A related_icmp -p icmp"..., 5868) = 1279
stat("/sbin/iptables", {st_mode=S_IFREG|0755, st_size=53176, ...}) = 0
stat(".", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
stat("/usr/local/sbin/iptables", 0x7fff803bea30) = -1 ENOENT (No such
file or directory)
stat("/usr/local/bin/iptables", 0x7fff803bea30) = -1 ENOENT (No such
file or directory)
stat("/usr/sbin/iptables", 0x7fff803bea30) = -1 ENOENT (No such file or
directory)
stat("/usr/bin/iptables", 0x7fff803bea30) = -1 ENOENT (No such file or
directory)
stat("/sbin/iptables", {st_mode=S_IFREG|0755, st_size=53176, ...}) = 0
stat("/sbin/iptables", {st_mode=S_IFREG|0755, st_size=53176, ...}) = 0
rt_sigprocmask(SIG_BLOCK, [INT CHLD], [], 8) = 0
lseek(255, -1210, SEEK_CUR) = 4658
clone(child_stack=0,
flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGC HLD,
child_tidptr=0x2b3e2ac9c760) = 7526
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) = 0
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) = 0
rt_sigaction(SIGINT, {0x436000, [], SA_RESTORER, 0x2b3e2aa8e110},
{SIG_DFL}, 8) = 0
wait4(-1, [{WIFSIGNALED(s) && WTERMSIG(s) == SIGINT}], 0, NULL) = 7526

> L'interpréteur de commande est-il le même en console et dans le script ?
> En général /bin/sh est un lien symbolique qui pointe sur bash, peut-être
> est-ce différent sur ta Debian amd64.

Non c'est pareil

> Au fait, c'est bien une Debian amd64 et non juste une Debian i386 installée
> sur une machine AMD64 ?

C'est bien une debian amd64

Si quelqu'un, avec ces infos supplémentaires, arrive à trouver une
explication, je suis preneur.

Merci pour toutes vos réponses,

Oumar

--
One OS to rule them all,
One OS to find them.
One OS to call them all,
And in salvation bind them.
In the bright land of Linux,
Where the hackers play.
(J. Scott Thayer, with apologies to J.R.R.T.)


--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.net/?DebianFrench
Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et
"Reply-To:"

To UNSUBSCRIBE, email to debian-user-french-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Salut,

J'ai réussi à résoudre le problème en autorisant le trafic sur
l'interface de loopback toute suite après l'initialisation de,
tables et des paramètres noyau. Je n'ai pas pour autant compris
ce qui clochait :-(.

On Sun, Jul 01, 2007 at 04:19:08PM +0200, Pascal Hambourg wrote :
> Vu qu'il paraît que je suis l'auteur initial de ce script,

Rendons à César ce qui est à César :-) . En tout cas, merci pour ce
script car il m'a rendu bien des services.

> As-tu essayé d'attendre un peu pour voir ce qui se passe ?

Rien au bout de 5min

> Ou de surveiller les appels système de la commande qui bloque
> avec strace ?

Les 18 dernières lignes:

read(255, "iptables -A related_icmp -p icmp"..., 5868) = 1279
stat("/sbin/iptables", {st_mode=S_IFREG|0755, st_size=53176, ...}) = 0
stat(".", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
stat("/usr/local/sbin/iptables", 0x7fff803bea30) = -1 ENOENT (No such
file or directory)
stat("/usr/local/bin/iptables", 0x7fff803bea30) = -1 ENOENT (No such
file or directory)
stat("/usr/sbin/iptables", 0x7fff803bea30) = -1 ENOENT (No such file or
directory)
stat("/usr/bin/iptables", 0x7fff803bea30) = -1 ENOENT (No such file or
directory)
stat("/sbin/iptables", {st_mode=S_IFREG|0755, st_size=53176, ...}) = 0
stat("/sbin/iptables", {st_mode=S_IFREG|0755, st_size=53176, ...}) = 0
rt_sigprocmask(SIG_BLOCK, [INT CHLD], [], 8) = 0
lseek(255, -1210, SEEK_CUR) = 4658
clone(child_stack=0,
flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGC HLD,
child_tidptr=0x2b3e2ac9c760) = 7526
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) = 0
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) = 0
rt_sigaction(SIGINT, {0x436000, [], SA_RESTORER, 0x2b3e2aa8e110},
{SIG_DFL}, 8) = 0
wait4(-1, [{WIFSIGNALED(s) && WTERMSIG(s) == SIGINT}], 0, NULL) = 7526

> L'interpréteur de commande est-il le même en console et dans le script ?
> En général /bin/sh est un lien symbolique qui pointe sur bash, peut-être
> est-ce différent sur ta Debian amd64.

Non c'est pareil

> Au fait, c'est bien une Debian amd64 et non juste une Debian i386 installée
> sur une machine AMD64 ?

C'est bien une debian amd64

Si quelqu'un, avec ces infos supplémentaires, arrive à trouver une
explication, je suis preneur.

Merci pour toutes vos réponses,

Oumar

--
One OS to rule them all,
One OS to find them.
One OS to call them all,
And in salvation bind them.
In the bright land of Linux,
Where the hackers play.
(J. Scott Thayer, with apologies to J.R.R.T.)


--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.net/?DebianFrench
Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et
"Reply-To:"

To UNSUBSCRIBE, email to debian-user-french-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org