更新:我现在就开始工作了. Jim Zajkowski的回答帮助我检测到我的/etc/init.d/couchdb重新启动调用实际上没有重启实例.在我手动杀死CouchDB进程并启动一个新实例后,它获取了所需的BindAddress更改.
我已经安装了CouchDB
aptitude install couchdb
从我的服务器,我可以通过连接
telnet localhost 5984
并执行RESTful命令.当我尝试从我们网络上的另一台机器或从我们网络外部的机器访问服务器时,我得到一个连接被重置错误.我在路由器上设置了端口转发,否则可以通过Apache,Tomcat,SSH等访问服务器.
我是Linux / Ubuntu的新手,所以我不确定是否有阻止连接的默认防火墙,所以我运行:
iptables -A INPUT -p tcp –dport 5984 -j ACCEPT
但它没有帮助.
这是运行iptables -L -n -v的转储
Chain INPUT (policy ACCEPT 2121K packets,1319M bytes) pkts bytes target prot opt in out source destination 70 3864 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:5984 9 1647 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:8080 0 0 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:8080 Chain FORWARD (policy ACCEPT 0 packets,0 bytes) pkts bytes target prot opt in out source destination Chain OUTPUT (policy ACCEPT 1708K packets,1136M bytes) pkts bytes target prot opt in out source destination
我假设显示转换为5984的字节是由于我的localhost连接.
这是运行netstat -an |的转储grep 5984
tcp 0 0 127.0.0.1:5984 0.0.0.0:* LISTEN
我将couch.ini配置为“BindAddress = 0.0.0.0”并重新启动,因此它应该在所有接口上进行侦听.当我运行“sudo /etc/init.d/couchdb stop”然后运行netstat时,我仍然看到上面的条目.看起来CouchDB实际上并没有停止.这可能解释了我的问题,因为这意味着它可能意味着CouchDB从未真正重新启动并且从未选择BindAddress更改.
我手动杀死了CouchDB进程并重新启动它.现在netstat显示:
tcp 0 0 127.0.0.1:5984 0.0.0.0:* LISTEN tcp 0 0 127.0.0.1:5984 127.0.0.1:35366 TIME_WAIT
我仍然无法连接,即使是从局域网上的另一台机器.
解决方法
什么是netstat -an | grep 5984说?它是说127.0.0.1:5984还是*:5984?如果它是127.0.0.1,则需要将couchdb设置为侦听所有接口.