为什么 Capistrano 在执行特定 iptables 命令时会锁定？
我正在尝试使用 Capistrano 远程打开 iptables 防火墙中的端口。这是我的任务：
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
问题是任务中的第一个命令被锁定。我尝试使用各种端口号和目标计算机运行此规则，但始终得到相同的结果。
我确实有许多其他规则，看起来很像这个，但工作得很好。事实上，我有一个类似的任务，其中第一个命令是调用 iptables 来创建端口映射，并且该任务运行得很好。
更重要的是，我可以在 Capistrano 主机上成功运行此命令：
ssh -l deployer core sudo /sbin/iptables -I RH-Firewall-1-INPUT 1 -p tcp --dport 2424 -j ACCEPT
这工作正常。这应该正是 Capistrano 正在尝试做的事情。
为什么这个命令会锁定 Capistrano？
TIA 寻求解决方案或任何线索。
祝大家玩得开心！！！
I'm trying to remotely open a port in a iptables firewall using Capistrano. Here's my task:
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
The problem is that the first command in the task locks up. I've tried running this rule using a variety of port numbers and target machines, always with the same result.
I've got literally many dozens of other rules that look much like this but that work fine. In fact, I've got a similar task where the first command is a call to iptables to create a port mapping and that task works just fine.
What's more, I can successfully run this command on the Capistrano host:
ssh -l deployer core sudo /sbin/iptables -I RH-Firewall-1-INPUT 1 -p tcp --dport 2424 -j ACCEPT
This works fine. This should be exactly what Capistrano is attempting to do.
Why is this command locking up Capistrano?
TIA for a solution or any clue whatsoever.
Have Fun All!!!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
前几天我自己解决了这个问题。问题是我使用名称“port”作为我的任务的参数。 “参数”端口由“运行”命令识别，并导致系统尝试通过该端口而不是普通的 ssh 端口连接到目标计算机。因此锁定。
我将参数名称更改为“dport”，任务开始按我的预期工作。
Figured this one out myself the other day. The problem was that I was using the name 'port' as the parameter to my task. The 'parameter' port is recognized by the 'run' command, and causes the system to try to connect to the target machine via that port rather than the normal ssh port. Hence the lockup.
I changed my parameter name to 'dport', and the task started working as I expected.