You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@couchdb.apache.org by "Frank (JIRA)" <ji...@apache.org> on 2013/02/07 15:35:12 UTC
[jira] [Updated] (COUCHDB-1672) Replication does not work through
HTTPS
[ https://issues.apache.org/jira/browse/COUCHDB-1672?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Frank updated COUCHDB-1672:
---------------------------
Description:
Hi there,
First thank you all for this amazing DB that CouchDB is. It makes our life easier, fits well with our project and does really a great job. In the following, you will find some details about the issue we encounter while replicating our user databases.
Short description: the replication to an online CouchDB failed when we start the replication from a local CouchDB.
Erlang version: 14A
Operating System: Debian 6 Squeeze wrapped in an OpenVz container.
Host Operating System: Proxmox 2.1
More infos :
* replication works when https is disabled.
* replication fails when https is enabled.
* Https connections works through a browser or an http client such as curl.
* Https connections works through a browser or an http client such as curl if ssl encryption is handled by a Nginx reverse proxy and couchdb is configured to run without https.
* same issues when "verify_certificate" option is set to false
* same issues when the certificate is approved by a certificate authority.
* we tried with two couchdb instances that live on different machines and that talk each other via the web.
* we tried with two couchdb instances that live in different machines that talk each other via a private network.
Logs:
>From the target of the replication:
no logs
>From the source of the replication:
[info] [<0.28429.3>] Retrying HEAD request to https://user:*****@couch2.myadresse.com:6984/MyDB/ in 16.0 seconds due to error {conn_failed,{error,eoptions}}
[info] [<0.1080.0>] 127.0.0.1 - - POST /_replicate 500
[error] [<0.28430.3>] ** Generic server <0.28430.3> terminating
** Last message in was {'EXIT',<0.28429.3>,killed}
** When Server state == {state,"https://user:passwd@couch2.myadresse.com:6984/MyDB/",
20,[],[],
{[],[]}}
** Reason for termination ==
** killed
[error] [<0.28430.3>] {error_report,<0.31.0>,
{<0.28430.3>,crash_report,
[[{initial_call,
{couch_httpc_pool,init,['Argument__1']}},
{pid,<0.28430.3>},
{registered_name,[]},
{error_info,
{exit,killed,
[{gen_server,terminate,6},
{proc_lib,init_p_do_apply,3}]}},
{ancestors,
[<0.28429.3>,couch_rep_sup,
couch_primary_services,couch_server_sup,
<0.32.0>]},
{messages,[]},
{links,[]},
{dictionary,[]},
{trap_exit,true},
{status,running},
{heap_size,377},
{stack_size,24},
{reductions,485}],
[]]}}
was:
Hi there,
First thank you all for this amazing DB that CouchDB is. It makes our life easier, fit well with our project and do really a great job. In the following you will find some details about the issue we encounter while replicating our user databases.
Short description: the replication to an online CouchDB failed when we start the replication from a local CouchDB.
Erlang version: 14A
Operating System: Debian 6 Squeeze wrapped in an OpenVz container.
Host Operating System: Proxmox 2.1
More infos :
* replication works when https is disabled.
* replication fails when https is enabled.
* Https connections works through a browser or an http client such as curl.
* Https connections works through a browser or an http client such as curl if ssl encryption is handled by a Nginx reverse proxy and couchdb is configured to run without https.
* same issues when "verify_certificate" option is set to false
* same issues when the certificate is approved by a certificate authority.
* we tried with two couchdb instances that live on different machines and that talk each other via the web.
* we tried with two couchdb instances that live in different machines that talk each other via a private network.
Logs:
>From the target of the replication:
no logs
>From the source of the replication:
[info] [<0.28429.3>] Retrying HEAD request to https://user:*****@couch2.myadresse.com:6984/MyDB/ in 16.0 seconds due to error {conn_failed,{error,eoptions}}
[info] [<0.1080.0>] 127.0.0.1 - - POST /_replicate 500
[error] [<0.28430.3>] ** Generic server <0.28430.3> terminating
** Last message in was {'EXIT',<0.28429.3>,killed}
** When Server state == {state,"https://user:passwd@couch2.myadresse.com:6984/MyDB/",
20,[],[],
{[],[]}}
** Reason for termination ==
** killed
[error] [<0.28430.3>] {error_report,<0.31.0>,
{<0.28430.3>,crash_report,
[[{initial_call,
{couch_httpc_pool,init,['Argument__1']}},
{pid,<0.28430.3>},
{registered_name,[]},
{error_info,
{exit,killed,
[{gen_server,terminate,6},
{proc_lib,init_p_do_apply,3}]}},
{ancestors,
[<0.28429.3>,couch_rep_sup,
couch_primary_services,couch_server_sup,
<0.32.0>]},
{messages,[]},
{links,[]},
{dictionary,[]},
{trap_exit,true},
{status,running},
{heap_size,377},
{stack_size,24},
{reductions,485}],
[]]}}
> Replication does not work through HTTPS
> ---------------------------------------
>
> Key: COUCHDB-1672
> URL: https://issues.apache.org/jira/browse/COUCHDB-1672
> Project: CouchDB
> Issue Type: Bug
> Components: Replication
> Reporter: Frank
>
> Hi there,
> First thank you all for this amazing DB that CouchDB is. It makes our life easier, fits well with our project and does really a great job. In the following, you will find some details about the issue we encounter while replicating our user databases.
> Short description: the replication to an online CouchDB failed when we start the replication from a local CouchDB.
> Erlang version: 14A
> Operating System: Debian 6 Squeeze wrapped in an OpenVz container.
> Host Operating System: Proxmox 2.1
> More infos :
> * replication works when https is disabled.
> * replication fails when https is enabled.
> * Https connections works through a browser or an http client such as curl.
> * Https connections works through a browser or an http client such as curl if ssl encryption is handled by a Nginx reverse proxy and couchdb is configured to run without https.
> * same issues when "verify_certificate" option is set to false
> * same issues when the certificate is approved by a certificate authority.
> * we tried with two couchdb instances that live on different machines and that talk each other via the web.
> * we tried with two couchdb instances that live in different machines that talk each other via a private network.
> Logs:
> From the target of the replication:
> no logs
> From the source of the replication:
> [info] [<0.28429.3>] Retrying HEAD request to https://user:*****@couch2.myadresse.com:6984/MyDB/ in 16.0 seconds due to error {conn_failed,{error,eoptions}}
> [info] [<0.1080.0>] 127.0.0.1 - - POST /_replicate 500
> [error] [<0.28430.3>] ** Generic server <0.28430.3> terminating
> ** Last message in was {'EXIT',<0.28429.3>,killed}
> ** When Server state == {state,"https://user:passwd@couch2.myadresse.com:6984/MyDB/",
> 20,[],[],
> {[],[]}}
> ** Reason for termination ==
> ** killed
> [error] [<0.28430.3>] {error_report,<0.31.0>,
> {<0.28430.3>,crash_report,
> [[{initial_call,
> {couch_httpc_pool,init,['Argument__1']}},
> {pid,<0.28430.3>},
> {registered_name,[]},
> {error_info,
> {exit,killed,
> [{gen_server,terminate,6},
> {proc_lib,init_p_do_apply,3}]}},
> {ancestors,
> [<0.28429.3>,couch_rep_sup,
> couch_primary_services,couch_server_sup,
> <0.32.0>]},
> {messages,[]},
> {links,[]},
> {dictionary,[]},
> {trap_exit,true},
> {status,running},
> {heap_size,377},
> {stack_size,24},
> {reductions,485}],
> []]}}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira