2010-07-17 15 views
0

J'essaie d'ouvrir à distance un port dans un pare-feu iptables en utilisant Capistrano. Voici ma tâche:Pourquoi Capistrano se verrouille-t-il lors de l'exécution d'une commande iptables spécifique?

desc "Open up a port in the firewall" 
    task :open_port, :roles => :all do 
    port = variables[:port] || nil 
    if (!port) 
     puts "You must specify the port number" 
     next 
    end 
    run "#{sudo} /sbin/iptables -I RH-Firewall-1-INPUT 1 -p tcp --dport #{port.to_s} -j ACCEPT" 
    run "#{sudo} /sbin/service iptables save" 
    run "#{sudo} /etc/init.d/iptables restart" 
    end 

Le problème est que la première commande de la tâche se bloque. J'ai essayé d'exécuter cette règle en utilisant une variété de numéros de port et de machines cibles, toujours avec le même résultat. J'ai littéralement plusieurs dizaines d'autres règles qui ressemblent beaucoup à ceci mais qui fonctionnent bien. En fait, j'ai une tâche similaire où la première commande est un appel à iptables pour créer un mappage de port et cette tâche marche très bien.

De plus, je peux courir avec succès cette commande sur l'hôte Capistrano:

ssh -l deployer core sudo /sbin/iptables -I RH-Firewall-1-INPUT 1 -p tcp --dport 2424 -j ACCEPT 

Cela fonctionne très bien. Cela devrait être exactement ce que Capistrano essaie de faire.

Pourquoi cette commande verrouille-t-elle Capistrano?

TIA pour une solution ou n'importe quelle idée que ce soit.

Amusez-vous tous !!!

Répondre

0

J'ai imaginé celui-ci l'autre jour. Le problème était que j'utilisais le nom 'port' comme paramètre pour ma tâche. Le port 'parameter' est reconnu par la commande 'run', et le système tente de se connecter à la machine cible via ce port plutôt que le port ssh normal. D'où le lock-up.

J'ai changé mon nom de paramètre en 'dport', et la tâche a commencé à fonctionner comme je l'avais prévu.