pb script iptables

Le
Oumar Niane
--sm4nu43k4a2Rpi4c
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit

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.)

--sm4nu43k4a2Rpi4c
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment; filename=fw_serveur

#!/bin/sh

# /etc/network/firewall/fw_serveur
#
# Auteur original:
# Pascal Hambourg <pascal.mail(at)plouf.fr.eu.org>
# Adapte par:
# Oumar Niane <jpon(at)jpon.org>

#=#
# definitions #
#=#

# nom de l'interface vers le reseau exterieur (a adapter)
IF_WAN="eth1"

#=#
# initialisation des tables & chaines #
#=#

# politiques par defaut des chaines de la table 'filter' : bloquer
iptables -P INPUT DROP
iptables -P FORWARD DROP
iptables -P OUTPUT DROP

# vidage des chaines des 3 tables filter, nat & mangle
iptables -F
iptables -t nat -F
iptables -t mangle -F

# suppression des chaines utilisateur des 3 tables
iptables -X
iptables -t nat -X
iptables -t mangle -X

# politiques par defaut des chaines de la table 'nat' : accepter
iptables -t nat -P PREROUTING ACCEPT
iptables -t nat -P OUTPUT ACCEPT
iptables -t nat -P POSTROUTING ACCEPT

# politiques par defaut des chaines de la table 'mangle' : accepter
iptables -t mangle -P PREROUTING ACCEPT
iptables -t mangle -P INPUT ACCEPT
iptables -t mangle -P FORWARD ACCEPT
iptables -t mangle -P OUTPUT ACCEPT
iptables -t mangle -P POSTROUTING ACCEPT

#=#
# initialisation des parametres du noyau #
#=#

# par defaut le serveur n'est pas un routeur : routage IP desactive
echo "0" > /proc/sys/net/ipv4/ip_forward

# activer le reverse path filtering contre le spoofing IP source
echo "1" > /proc/sys/net/ipv4/conf/all/rp_filter
echo "1" > /proc/sys/net/ipv4/conf/$IF_WAN/rp_filter

# ignorer les ICMP "redirect"
echo "0" > /proc/sys/net/ipv4/conf/$IF_WAN/accept_redirects
echo "0" > /proc/sys/net/ipv4/conf/$IF_WAN/secure_redirects

# ignorer les ICMP "echo request" (ping) sur l'adresse de broadcast
echo "1" > /proc/sys/net/ipv4/icmp_echo_ignore_broadcasts

#==#
# connexions acceptees en entree #
#==#

# On va logguer avant de dropper

iptables -N log_and_drop
iptables -A log_and_drop -j ULOG --ulog-prefix="[IPTABLES DROP] : "
iptables -A log_and_drop -j DROP

# cette chaine contient les types de paquets NEW acceptes en entree
iptables -N in_accept

# les regles sont definies dans le script 'fw_accept'
# relancer ce script apres modification des connexions acceptees
/etc/network/firewall/fw_accept

#==#
# traitement des paquets rejetes #
#==#

# paquets TCP rejetes : emission limitee de TCP RST sauf si RST
iptables -N reject_tcp
iptables -A reject_tcp -p tcp --tcp-flags RST NONE -m limit --limit 10/s -j REJECT --reject-with tcp-reset
iptables -A reject_tcp -j log_and_drop

# paquets UDP rejetes : emission limitee d'ICMP "port unreachable"
iptables -N reject_udp
iptables -A reject_udp -m limit --limit 10/s -j REJECT --reject-with icmp-port-unreachable
iptables -A reject_udp -j log_and_drop

# chaine de traitement de tous les type de paquets IP rejetes
iptables -N reject
iptables -A reject -p tcp -j reject_tcp
iptables -A reject -p udp -j reject_udp
iptables -A reject -p icmp -j log_and_drop
# autres protocoles : emission limitee ICMP "protocol unreachable"
iptables -A reject -m limit --limit 10/s -j REJECT --reject-with icmp-proto-unreachable
iptables -A reject -j log_and_drop

#==#
# traitement des paquets NEW en entree #
#==#

# chaine de traitement des paquets INPUT NEW sur l'interface wan
iptables -N in_wan_new
# accepte les protocoles et ports autorises
iptables -A in_wan_new -j in_accept
# accepte avec limite les ICMP "echo request" (ping)
iptables -A in_wan_new -p icmp --icmp-type echo-request -m limit --limit 5/s -j ACCEPT
iptables -A in_wan_new -j reject

##
# traitement des paquets RELATED en entree #
##

# connexions TCP RELATED : accepte connexions sur ports non privilegies
iptables -N related_tcp
iptables -A related_tcp -p tcp --syn --dport 1024: -j ACCEPT
# accepte les paquets RST
iptables -A related_tcp -p tcp --tcp-flags RST RST -j ACCEPT
iptables -A related_tcp -j reject_tcp

# connexions UDP RELATED : accepte connexions sur ports non privilegies
iptables -N related_udp
iptables -A related_udp -p udp --dport 1024: -j ACCEPT
iptables -A related_udp -j reject_udp

# paquets ICMP RELATED : 4 types acceptes, le reste bloque
iptables -N related_icmp
iptables -A related_icmp -p icmp --icmp-type destination-unreachable -j ACCEPT
iptables -A related_icmp -p icmp --icmp-type time-exceeded -j ACCEPT
iptables -A related_icmp -p icmp --icmp-type source-quench -j ACCEPT
iptables -A related_icmp -p icmp --icmp-type parameter-problem -j ACCEPT
iptables -A related_icmp -j log_and_drop

# chaine de traitement des paquets RELATED
iptables -N related
iptables -A related -p tcp -j related_tcp
iptables -A related -p udp -j related_udp
iptables -A related -p icmp -j related_icmp
# autres protocoles : accepte
iptables -A related -j ACCEPT

#==#
# regles des interfaces #
#==#

# interface de loopback : accepte tout
iptables -A INPUT -i lo -j ACCEPT
iptables -A OUTPUT -o lo -j ACCEPT

# interface WAN

# traitement INPUT WAN : filtrage a etats des paquets entrants
iptables -N in_wan
iptables -A in_wan -m state --state ESTABLISHED -j ACCEPT
iptables -A in_wan -m state --state NEW -j in_wan_new
iptables -A in_wan -m state --state RELATED -j related
# le reste (state INVALID) => bloque
iptables -A in_wan -j log_and_drop
iptables -A INPUT -i $IF_WAN -j in_wan

# traitement OUTPUT WAN : accepte tout
iptables -N out_wan
iptables -A out_wan -j ACCEPT
iptables -A OUTPUT -o $IF_WAN -j out_wan

# fin

--sm4nu43k4a2Rpi4c--


--
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
Vidéos High-Tech et Jeu Vidéo
Téléchargements
Vos réponses
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
Bulot Grégory
Le #9778241
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 mai n 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)
Oumar Niane
Le #9778201
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
with a subject of "unsubscribe". Trouble? Contact
Franck Joncourt
Le #9778191
--45Z9DzgjV8m4Oswq
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

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 comman des)
> 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 s i 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 puis que 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

--45Z9DzgjV8m4Oswq
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
Content-Disposition: inline

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

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

--45Z9DzgjV8m4Oswq--


--
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
with a subject of "unsubscribe". Trouble? Contact
mouss
Le #9778181
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
with a subject of "unsubscribe". Trouble? Contact
Franck Joncourt
Le #9778171
--uZ3hkaAS1mZxFaxD
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

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 l e
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/netfilter/firewall/serveur/fw_accept

Cela permet de recharger les règles associées au serveur sans rel ancer
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

--uZ3hkaAS1mZxFaxD
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
Content-Disposition: inline

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

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

--uZ3hkaAS1mZxFaxD--


--
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
with a subject of "unsubscribe". Trouble? Contact
Franck Joncourt
Le #9778141
--GZVR6ND4mMseVXL/
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

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 si ta
> > machine attend quelque chose du réseau (dns, dhcp, ... etc). c'e st 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/netfilter/firewall/serveur/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 ded ans 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ême lot de
paquets et les mêmes fichiers de conf puisque je suis en train de fa ire
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 iptab les -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 (pas dans 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é c ertaines
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

--GZVR6ND4mMseVXL/
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
Content-Disposition: inline

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

iD8DBQFGhncLxJBTTnXAif4RAvSmAJ9QI400a1SOLPBQ4WsIR1qqxq0tdQCfer0b
86zh4MmcNRvBQnXgCS4TA5U =wrvG
-----END PGP SIGNATURE-----

--GZVR6ND4mMseVXL/--


--
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
with a subject of "unsubscribe". Trouble? Contact
Bulot Grégory
Le #9778051
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 bloq ue
après la ligne 77 ( iptables -N in_accept ) . Je ne crois pas ...




Milles excuses, j'avais pas fait attention à la pièce jointe
Pascal Hambourg
Le #9778021
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
with a subject of "unsubscribe". Trouble? Contact
Oumar Niane
Le #9581961
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_sizeS176, ...}) = 0
stat(".", {st_mode=S_IFDIR|0755, , ...}) = 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_sizeS176, ...}) = 0
stat("/sbin/iptables", {st_mode=S_IFREG|0755, st_sizeS176, ...}) = 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|SIGCHLD,
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
with a subject of "unsubscribe". Trouble? Contact
Publicité
Poster une réponse
Anonyme