couchdb-replication mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jay Clark <jcl...@maf.org>
Subject RE: Replication consistently fails
Date Mon, 10 Mar 2014 19:01:06 GMT
As a quick followup to this, I can remove the username:password from the source URL, and the
POST to _replicator will return an "error":"unauthorized", which is what I expect.

However, the POST returns no response when using username:password in the URL. So, replicator
seems to be hanging when trying to authenticate against my couchdb during replication. Also,
the replication gets created (visible via _active_tasks), but the POST never gets a response
back, and the replication never completes, it always times out.

Any help would be greatly appreciated.

Thanks again,
~Jay

-----Original Message-----
From: Jay Clark 
Sent: Monday, March 10, 2014 12:06 PM
To: replication@couchdb.apache.org
Subject: Replication consistently fails

Hi,
I’m trying to figure out why my app is having difficulty replicating, and hoping someone
here can help.

I have a couchdb 1.4 server setup behind an Apache reverse proxy. We’re only allowing HTTPS
connections to the Apache server, and couchdb user credentials are needed to access any db.
I’m inside a corporate network, but have verified with sysadmins that the appropriate (documented)
ports are open for CouchDB replication to happen. The couchdb server in question is in a DMZ.
Please let me know if that’s enough info.

While my laptop is on my corporate (public) wi-fi network, I’m trying to replicate a db
from my server (in our DMZ) with this post to _replicate, but it consistently times out:

{"source":"https://username:password@estante.maflt.org/dbname","target":"eeb"}

While I’m external to our network, the replication succeeds without problem.

Using a REST client inside my corporate network, I get no response and it eventually times
out. The Erlang log shows this message:

Replicator, request GET to "https://username:*****@estante.maflt.org/dbname/_changes?feed=normal&style=all_docs&since=0&heartbeat=10000"
failed due to error timeout

We’ve scoured logs for errors or issues related to connectivity from our public LAN and
our DMZ, and nothing appears to be blocking our connection. Regular HTTP/HTTPS can go through
just fine. I can access Futon just fine on the server, and the server pull can replicate into
itself just fine.

Could someone point me in the right direction to figure out why replication seems to fail
so consistently like this? Are there other ports we need to be looking at? Other protocols
being used? Is there a flaw in my replication request? Is there some network config I need
to have our sysadmin look at that could be preventing this?

As far as I can tell though, the behavior seems to indicate that the document is not fully
getting posted to the localhost’s _replicate method.

Thank you,
Jay Clark
Mime
View raw message