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 ?