ok :) On Tue, Aug 13, 2019 at 7:33 AM Joan Touzet <woh...@apache.org> wrote:
> The other link I sent is way better :D > > On 2019-08-13 1:32 a.m., Rene Veerman wrote: > > never mind, found it.. :) > > > https://mail-archives.apache.org/mod_mbox/couchdb-user/201908.mbox/browser > > > > On Tue, Aug 13, 2019 at 7:24 AM Rene Veerman <seductivea...@gmail.com> > > wrote: > > > >> ok Joan, thanks for your help. > >> > >> one final question : is this email list we're using here archived on the > >> web anywhere? if so, where? > >> > >> On Tue, Aug 13, 2019 at 7:19 AM Joan Touzet <woh...@apache.org> wrote: > >> > >>> It doesn't look like CouchDB is listening on port 5984 at all if it's > >>> refusing any connections there. > >>> > >>> Sorry, I'm out of ideas. I recommend you hop on the CouchDB Slack > >>> (instructions at https://couchdb.apache.org/) and get some real-time > >>> help. > >>> > >>> On 2019-08-13 12:41 a.m., Rene Veerman wrote: > >>>> total disobedience ;) > >>>> > >>>> root@albatross:/opt/couchdb/etc# curl --verbose > http://localhost:5984/ > >>>> * Trying 127.0.0.1... > >>>> * TCP_NODELAY set > >>>> * connect to 127.0.0.1 port 5984 failed: Connection refused > >>>> * Failed to connect to localhost port 5984: Connection refused > >>>> * Closing connection 0 > >>>> curl: (7) Failed to connect to localhost port 5984: Connection refused > >>>> root@albatross:/opt/couchdb/etc# curl --verbose > https://localhost:5984/ > >>>> * Trying 127.0.0.1... > >>>> * TCP_NODELAY set > >>>> * connect to 127.0.0.1 port 5984 failed: Connection refused > >>>> * Failed to connect to localhost port 5984: Connection refused > >>>> * Closing connection 0 > >>>> curl: (7) Failed to connect to localhost port 5984: Connection refused > >>>> root@albatross:/opt/couchdb/etc# > >>>> > >>>> On Tue, Aug 13, 2019 at 6:40 AM Joan Touzet <woh...@apache.org> > wrote: > >>>> > >>>>> 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 couchdb@127.0.0.1 <0.9.0> > -------- > >>>>>> Application couch_log started on node 'couchdb@127.0.0.1' > >>>>>> [info] 2019-08-13T04:30:19.784813Z couchdb@127.0.0.1 <0.9.0> > -------- > >>>>>> Application folsom started on node 'couchdb@127.0.0.1' > >>>>>> [info] 2019-08-13T04:30:19.809271Z couchdb@127.0.0.1 <0.9.0> > -------- > >>>>>> Application couch_stats started on node 'couchdb@127.0.0.1' > >>>>>> [info] 2019-08-13T04:30:19.809378Z couchdb@127.0.0.1 <0.9.0> > -------- > >>>>>> Application khash started on node 'couchdb@127.0.0.1' > >>>>>> [info] 2019-08-13T04:30:19.813194Z couchdb@127.0.0.1 <0.9.0> > -------- > >>>>>> Application couch_event started on node 'couchdb@127.0.0.1' > >>>>>> [info] 2019-08-13T04:30:19.813291Z couchdb@127.0.0.1 <0.9.0> > -------- > >>>>>> Application hyper started on node 'couchdb@127.0.0.1' > >>>>>> [info] 2019-08-13T04:30:19.816832Z couchdb@127.0.0.1 <0.9.0> > -------- > >>>>>> Application ibrowse started on node 'couchdb@127.0.0.1' > >>>>>> [info] 2019-08-13T04:30:19.819801Z couchdb@127.0.0.1 <0.9.0> > -------- > >>>>>> Application ioq started on node 'couchdb@127.0.0.1' > >>>>>> [info] 2019-08-13T04:30:19.819931Z couchdb@127.0.0.1 <0.9.0> > -------- > >>>>>> Application mochiweb started on node 'couchdb@127.0.0.1' > >>>>>> [info] 2019-08-13T04:30:19.824769Z couchdb@127.0.0.1 <0.212.0> > >>> -------- > >>>>>> Apache CouchDB 2.3.1 is starting. > >>>>>> > >>>>>> [info] 2019-08-13T04:30:19.824829Z couchdb@127.0.0.1 <0.213.0> > >>> -------- > >>>>>> Starting couch_sup > >>>>>> [notice] 2019-08-13T04:30:19.830479Z couchdb@127.0.0.1 <0.96.0> > >>> -------- > >>>>>> config: [features] pluggable-storage-engines set to true for reason > >>> nil > >>>>>> [info] 2019-08-13T04:30:19.889337Z couchdb@127.0.0.1 <0.212.0> > >>> -------- > >>>>>> Apache CouchDB has started. Time to relax. > >>>>>> > >>>>>> [info] 2019-08-13T04:30:19.889419Z couchdb@127.0.0.1 <0.212.0> > >>> -------- > >>>>>> Apache CouchDB has started on http://127.0.0.1:5986/ > >>>>>> [info] 2019-08-13T04:30:19.889518Z couchdb@127.0.0.1 <0.9.0> > -------- > >>>>>> Application couch started on node 'couchdb@127.0.0.1' > >>>>>> [info] 2019-08-13T04:30:19.889624Z couchdb@127.0.0.1 <0.9.0> > -------- > >>>>>> Application ets_lru started on node 'couchdb@127.0.0.1' > >>>>>> [notice] 2019-08-13T04:30:19.909310Z couchdb@127.0.0.1 <0.276.0> > >>>>> -------- > >>>>>> rexi_server : started servers > >>>>>> [notice] 2019-08-13T04:30:19.911977Z couchdb@127.0.0.1 <0.280.0> > >>>>> -------- > >>>>>> rexi_buffer : started servers > >>>>>> [info] 2019-08-13T04:30:19.912108Z couchdb@127.0.0.1 <0.9.0> > -------- > >>>>>> Application rexi started on node 'couchdb@127.0.0.1' > >>>>>> [info] 2019-08-13T04:30:19.933416Z couchdb@127.0.0.1 <0.9.0> > -------- > >>>>>> Application mem3 started on node 'couchdb@127.0.0.1' > >>>>>> [info] 2019-08-13T04:30:19.933443Z couchdb@127.0.0.1 <0.9.0> > -------- > >>>>>> Application fabric started on node 'couchdb@127.0.0.1' > >>>>>> [info] 2019-08-13T04:30:19.943825Z couchdb@127.0.0.1 <0.9.0> > -------- > >>>>>> Application chttpd started on node 'couchdb@127.0.0.1' > >>>>>> [info] 2019-08-13T04:30:19.950696Z couchdb@127.0.0.1 <0.9.0> > -------- > >>>>>> Application couch_index started on node 'couchdb@127.0.0.1' > >>>>>> [info] 2019-08-13T04:30:19.950722Z couchdb@127.0.0.1 <0.9.0> > -------- > >>>>>> Application couch_mrview started on node 'couchdb@127.0.0.1' > >>>>>> [info] 2019-08-13T04:30:19.950809Z couchdb@127.0.0.1 <0.9.0> > -------- > >>>>>> Application couch_plugins started on node 'couchdb@127.0.0.1' > >>>>>> [notice] 2019-08-13T04:30:19.980249Z couchdb@127.0.0.1 <0.96.0> > >>> -------- > >>>>>> config: [features] scheduler set to true for reason nil > >>>>>> [info] 2019-08-13T04:30:19.990117Z couchdb@127.0.0.1 <0.9.0> > -------- > >>>>>> Application couch_replicator started on node 'couchdb@127.0.0.1' > >>>>>> [info] 2019-08-13T04:30:19.994567Z couchdb@127.0.0.1 <0.9.0> > -------- > >>>>>> Application couch_peruser started on node 'couchdb@127.0.0.1' > >>>>>> [info] 2019-08-13T04:30:20.001778Z couchdb@127.0.0.1 <0.9.0> > -------- > >>>>>> Application ddoc_cache started on node 'couchdb@127.0.0.1' > >>>>>> [info] 2019-08-13T04:30:20.010320Z couchdb@127.0.0.1 <0.9.0> > -------- > >>>>>> Application global_changes started on node 'couchdb@127.0.0.1' > >>>>>> [info] 2019-08-13T04:30:20.010341Z couchdb@127.0.0.1 <0.9.0> > -------- > >>>>>> Application jiffy started on node 'couchdb@127.0.0.1' > >>>>>> [info] 2019-08-13T04:30:20.013833Z couchdb@127.0.0.1 <0.9.0> > -------- > >>>>>> Application mango started on node 'couchdb@127.0.0.1' > >>>>>> [info] 2019-08-13T04:30:20.017261Z couchdb@127.0.0.1 <0.9.0> > -------- > >>>>>> Application setup started on node 'couchdb@127.0.0.1' > >>>>>> [info] 2019-08-13T04:30:20.017321Z couchdb@127.0.0.1 <0.9.0> > -------- > >>>>>> Application snappy started on node 'couchdb@127.0.0.1' > >>>>>> root@albatross:/opt/couchdb/etc# > >>>>>> > >>>>>> > >>>>>> > >>>>>> On Tue, Aug 13, 2019 at 6:38 AM Rene Veerman < > seductivea...@gmail.com > >>>> > >>>>>> 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 < > >>>>> jaquil...@eagleeyet.net> > >>>>>>> wrote: > >>>>>>> > >>>>>>>> Also have you tried to use a lets encrypt free SSL certificate? > >>>>>>>> > >>>>>>>> > >>>>>>>> -----Original Message----- > >>>>>>>> From: Rene Veerman <seductivea...@gmail.com> > >>>>>>>> Sent: Tuesday, 13 August 2019 06:13 > >>>>>>>> To: user@couchdb.apache.org > >>>>>>>> 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 <woh...@apache.org> > >>> 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 > >>>>>>>>>> that > >>>>>>>>> CouchDB is trying to use. > >>>>>>>>>> > >>>>>>>>>> Adam > >>>>>>>>>> > >>>>>>>>>>> On Aug 12, 2019, at 3:24 AM, Rene Veerman < > >>> seductivea...@gmail.com> > >>>>>>>>> wrote: > >>>>>>>>>>> > >>>>>>>>>>> eaddrinuse > >>>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>> > >>>>>>> > >>>>>> > >>>>> > >>>> > >>> > >> > > >
