What output do you get for: curl --verbose http://localhost:5984/
curl --verbose https://localhost:5984/Let's get that working first before we try and sort out whatever the heck is going on with .app domains.
-Joan On 2019-08-13 12:38 a.m., Rene Veerman wrote:
and the log : root@albatross:/opt/couchdb/etc# rm /var/log/couchdb/couchdb.log root@albatross:/opt/couchdb/etc# service couchdb restart root@albatross:/opt/couchdb/etc# cat /var/log/couchdb/couchdb.log [info] 2019-08-13T04:30:19.782183Z [email protected] <0.9.0> -------- Application couch_log started on node '[email protected]' [info] 2019-08-13T04:30:19.784813Z [email protected] <0.9.0> -------- Application folsom started on node '[email protected]' [info] 2019-08-13T04:30:19.809271Z [email protected] <0.9.0> -------- Application couch_stats started on node '[email protected]' [info] 2019-08-13T04:30:19.809378Z [email protected] <0.9.0> -------- Application khash started on node '[email protected]' [info] 2019-08-13T04:30:19.813194Z [email protected] <0.9.0> -------- Application couch_event started on node '[email protected]' [info] 2019-08-13T04:30:19.813291Z [email protected] <0.9.0> -------- Application hyper started on node '[email protected]' [info] 2019-08-13T04:30:19.816832Z [email protected] <0.9.0> -------- Application ibrowse started on node '[email protected]' [info] 2019-08-13T04:30:19.819801Z [email protected] <0.9.0> -------- Application ioq started on node '[email protected]' [info] 2019-08-13T04:30:19.819931Z [email protected] <0.9.0> -------- Application mochiweb started on node '[email protected]' [info] 2019-08-13T04:30:19.824769Z [email protected] <0.212.0> -------- Apache CouchDB 2.3.1 is starting. [info] 2019-08-13T04:30:19.824829Z [email protected] <0.213.0> -------- Starting couch_sup [notice] 2019-08-13T04:30:19.830479Z [email protected] <0.96.0> -------- config: [features] pluggable-storage-engines set to true for reason nil [info] 2019-08-13T04:30:19.889337Z [email protected] <0.212.0> -------- Apache CouchDB has started. Time to relax. [info] 2019-08-13T04:30:19.889419Z [email protected] <0.212.0> -------- Apache CouchDB has started on http://127.0.0.1:5986/ [info] 2019-08-13T04:30:19.889518Z [email protected] <0.9.0> -------- Application couch started on node '[email protected]' [info] 2019-08-13T04:30:19.889624Z [email protected] <0.9.0> -------- Application ets_lru started on node '[email protected]' [notice] 2019-08-13T04:30:19.909310Z [email protected] <0.276.0> -------- rexi_server : started servers [notice] 2019-08-13T04:30:19.911977Z [email protected] <0.280.0> -------- rexi_buffer : started servers [info] 2019-08-13T04:30:19.912108Z [email protected] <0.9.0> -------- Application rexi started on node '[email protected]' [info] 2019-08-13T04:30:19.933416Z [email protected] <0.9.0> -------- Application mem3 started on node '[email protected]' [info] 2019-08-13T04:30:19.933443Z [email protected] <0.9.0> -------- Application fabric started on node '[email protected]' [info] 2019-08-13T04:30:19.943825Z [email protected] <0.9.0> -------- Application chttpd started on node '[email protected]' [info] 2019-08-13T04:30:19.950696Z [email protected] <0.9.0> -------- Application couch_index started on node '[email protected]' [info] 2019-08-13T04:30:19.950722Z [email protected] <0.9.0> -------- Application couch_mrview started on node '[email protected]' [info] 2019-08-13T04:30:19.950809Z [email protected] <0.9.0> -------- Application couch_plugins started on node '[email protected]' [notice] 2019-08-13T04:30:19.980249Z [email protected] <0.96.0> -------- config: [features] scheduler set to true for reason nil [info] 2019-08-13T04:30:19.990117Z [email protected] <0.9.0> -------- Application couch_replicator started on node '[email protected]' [info] 2019-08-13T04:30:19.994567Z [email protected] <0.9.0> -------- Application couch_peruser started on node '[email protected]' [info] 2019-08-13T04:30:20.001778Z [email protected] <0.9.0> -------- Application ddoc_cache started on node '[email protected]' [info] 2019-08-13T04:30:20.010320Z [email protected] <0.9.0> -------- Application global_changes started on node '[email protected]' [info] 2019-08-13T04:30:20.010341Z [email protected] <0.9.0> -------- Application jiffy started on node '[email protected]' [info] 2019-08-13T04:30:20.013833Z [email protected] <0.9.0> -------- Application mango started on node '[email protected]' [info] 2019-08-13T04:30:20.017261Z [email protected] <0.9.0> -------- Application setup started on node '[email protected]' [info] 2019-08-13T04:30:20.017321Z [email protected] <0.9.0> -------- Application snappy started on node '[email protected]' root@albatross:/opt/couchdb/etc# On Tue, Aug 13, 2019 at 6:38 AM Rene Veerman <[email protected]> wrote:included below here is the log of restarting couchdb, it looks completely normal to me. i've included it so others won't have to guess what's in it. and yeah, when i bought the .app domain, they didn't mention enforced https. but hey, lets just update the docs and make this simple, shall we? coz it seems according to the article posted by Jonathan just now, that this is an encroaching "problem". and probably a non-problem for someone skilled at crypto setups on ubuntu. ehm, i'm hesitant to try out the lets encrypt service ( https://letsencrypt.org/getting-started/ ), because i fear Google would enforce somehow, with another cryptic browser error, that i use the same certificate as for regular https traffic to apache on the same machine. and since my primary use for couchdb is AJAX access from the browser with a javascript plugin, this could be a real stubborn problem if i try letsencrypt. i may try it out later, ok... i wanna get some coding work done too today. On Tue, Aug 13, 2019 at 6:25 AM Jonathan Aquilina <[email protected]> wrote:Also have you tried to use a lets encrypt free SSL certificate? -----Original Message----- From: Rene Veerman <[email protected]> Sent: Tuesday, 13 August 2019 06:13 To: [email protected] Subject: Re: running couchdb on a .app domain (https enforced) ok, i followed your instructions to the letter, Joan. and with a self-signed key, i'm now stuck at ERR_CONNECTION_REFUSED when connecting to the domain name. and i'm getting the same error when trying to connect to localhost:5984, and even to 127.0.0.1, same error. could it be that Google (who run the .app TLD) enforces a real certificate? like the one i used on regular apache on the same machine? problem is, i can't find any step by step guide to get me to that key_file, cert_file, cacert_file setup... :( and anyone who's not an expert at this sorta thing is probably going to run into the same problems. a couchdb installer that fails to ask for the simple files provided by domain registrars (where you buy the certificate for a .app domain) that are also fed to the regular apache daemon to make regular https to the webserver work. normally you'd google yourself through that, like i did with apache itself, but here the online documentation is also quite lacking. i don't want to look a gift horse in the mouth of course, i'm a programmer myself, and i hate documentation work like the next guy, but in this case, couchdb programmers, we could use at least a simple setup article (mentioned in the documentation, website, and installer for couch), and then later or even straight away, that input request in the couchdb installer. it sucks to have to remember the ins and outs of a OS sub system just to get it to work, and then go through the same difficult process of finding the right settings, when you need to re-install a machine a few months or years later. anyways, thanks for the help so far, people. but i'm still stuck, and would love some more good simple pointers. On Mon, Aug 12, 2019 at 7:48 PM Joan Touzet <[email protected]> wrote:CouchDB with SSL has 2 ports for general access: 5984, and 6984. 5984 is the insecure http version of the port. You can't turn it off easily in CouchDB 2.3.1, but you can change what port it appears at. I recommend firewalling access to this port immediately. If you enable SSL, that'll be on port 6984 by default. You may have changed it to port 7984. That's the one you want the world to see. It shares the same address binding as the insecure 5984 port, so you must bind both to 0.0.0.0 to see this externally. Do *not* change the settings for the administrative port (5986). Leave this bound only to 127.0.0.1. Since you're having so much trouble, I'll write up the settings you need. The following has: * Standard (http) port bound to 0.0.0.0:1234 (*firewall this*!!) * SSL (https) port bound to 0.0.0.0:5984 (this is the one you want) * Administrative port bound only to 127.0.0.1:5986 * **BE SURE TO RESTORE THE ORIGINAL DEFAULT.INI FILE WE SHIP FIRST.** After changing this file, kill all running CouchDB processes, then restart CouchDB. ``` [chttpd] port = 1234 bind_address = 0.0.0.0 [httpd] port = 5986 bind_address = 127.0.0.1 [ssl] port = 5984 key_file = YOUR PATH HERE cert_file = YOUR CERT HERE cacert_file = YOUR CACERT HERE ``` On 2019-08-12 8:18, Adam Kocoloski wrote:This means something else is already listening on one of the ports thatCouchDB is trying to use.AdamOn Aug 12, 2019, at 3:24 AM, Rene Veerman <[email protected]>wrote:eaddrinuse
