Dlaczego nie mogę uzyskać dostępu do mojej instancji CouchDB zewnętrznie na serwerze Ubuntu 9.04?

Aktualizacja: Mam to działa teraz. Odpowiedź Jima Zajkowskiego pomogła mi wykryć, że moje wywołania restartu /etc/init.d/couchdb tak naprawdę nie restartowały instancji. Po tym, jak ręcznie zabiłem procesy CouchDB i rozpocząłem nową instancję, wykryłem wymaganą zmianę adresu BindAddress.

Zainstalowałem CouchDB przez

aptitude install couchdb

Z mojego serwera mogę się połączyć przez

telnet localhost 5984

i wykonaj polecenia RESTful. Gdy próbuję uzyskać dostęp do serwera z innego komputera w naszej sieci lub z urządzenia zewnętrznego w naszej sieci, pojawia się komunikat Błąd połączenia został zresetowany . Skonfigurowałem przekierowanie portów na routerze, a serwer jest w inny sposób dostępny za pośrednictwem Apache, Tomcat, SSH itp.

Jestem nowy w systemie Linux / Ubuntu, więc nie byłem pewien, czy domyślna zapora blokuje połączenie, więc uruchomiłem:

iptables -A WEJŚCIE -p tcp --port 5984 -j AKCEPTUJ

ale to nie pomogło.

Oto zrzut po uruchomieniu 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

Zakładam, że bajty wyświetlane jako przekazane dla 5984 są spowodowane moim połączeniem localhost.

Oto zrzut po uruchomieniu netstat -an | grep 5984

tcp        0      0 127.0.0.1:5984          0.0.0.0:*               LISTEN

Skonfigurowałem couch.ini, aby mieć „BindAddress = 0.0.0.0” i zrestartowałem, więc powinno nasłuchiwać na wszystkich interfejsach. Kiedy uruchamiam „sudo /etc/init.d/couchdb stop”, a następnie uruchamiam netstat, jednak nadal widzę powyższy wpis. Wygląda na to, że CouchDB wcale się nie zatrzymuje. Może to wyjaśniać mój problem, ponieważ może to oznaczać, że CouchDB nigdy nie uruchomił się ponownie i nigdy nie odebrał zmiany adresu BindAddress.

Ręcznie zabiłem proces CouchDB i uruchomiłem go ponownie. Teraz netstat pokazuje:

 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

Nadal nie mogę się połączyć, nawet z innego komputera w sieci LAN.

Co netstat -an | grep 5984mówi Czy to mówi 127.0.0.1:5984czy *:5984? Jeśli tak 127.0.0.1, to należy ustawić couchdb, aby nasłuchiwał na wszystkich interfejsach.

Musisz zmienić adres powiązania w /etc/couchdb/default.ini. Następnie uruchom ponownie usługę i spróbuj ponownie.

Zauważyłem, że aby to zadziałało, z jakiegoś powodu musisz ręcznie zabić działający proces erlang. ps ax | grep beampowinien ujawnić proces erlang, powinieneś dostać coś wzdłuż linii 0:00 /usr/lib/erlang/ertsgdzieś na wyjściu. Jeśli zabijesz ten proces, a następnie uruchom /etc/init.d/couchdb restartnowy plik konfiguracyjny zostanie załadowany.

Na komputerze PC / Mac uruchom następujące polecenie:

ssh -L 5984:localhost:5984 YOUR-SERVER-IP-HERE

następnie otwórz w przeglądarce localhost: 5984 / _utils ... Działa dla mnie

Dokumenty konfiguracji :

Jeśli zmienisz to z panelu konfiguracji Futon, nie musisz nic więcej robić (restartowanie bazy danych itp.):

Przed zmianą domyślnego adresu bind_address:

peter@earth:~/$ netstat -an | grep 5984
tcp        0      0 127.0.0.1:5984          0.0.0.0:*               LISTEN

Po zmianie na 0.0.0.0:

peter@earth:~/$ netstat -an | grep 5984
tcp        0      0 0.0.0.1:5984          0.0.0.0:*               LISTEN

Uwaga nie guru: komputery, które nie mają dostępu do twojego (normalnie, nic poza siecią lokalną) nadal nie będą miały dostępu do twojego komputera (CouchDB lub cokolwiek innego).

Zetknąłem się z tym, a moim problemem było to, że najwyraźniej w mojej instalacji Ubuntu zainstalowano couchdb. Edytowałem pliki konfiguracyjne w / etc / couchdb, ale ten, który był uruchomiony, w rzeczywistości ściągał config z / usr / local / etc / couchdb.

Wskazówka była taka, że ​​konfiguracje w / etc / couchdb wspomniały couch 0.10, ale właśnie zainstalowałem 1.0.1.

iptables -L -n -vpokaże ci twoje obecne reguły zapory ogniowej. Sprawdź, czy istnieje taki, który upuszcza te pakiety, zanim dotrze do Twojej reguły.