since slack is an IRC setup, not a mailinglist, i'll continue to fill in
details of my efforts here..
i have the following files, the cc*.* and gd*.* are provided by my domain
registrar after buying the https certificate for plain apache https there...
the nicer.app--*.* files i also got at the sa
ok :)
On Tue, Aug 13, 2019 at 7:33 AM Joan Touzet 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 A
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
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?
>
>
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
wrote:
ok Joan, thanks for your help.
one final question : is
yup!
https://lists.apache.org/list.html?user@couchdb.apache.org
-Joan
On 2019-08-13 1:24 a.m., Rene Veerman 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
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 wrote:
> It doesn't look like CouchDB is listening on port 5984 at all if it's
> refusing any connections there.
>
> So
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:
tot
Try that out and that should solve the issue of traffic still wanting to go
over http by default with the vhost it will force a redirect from http to https
for you with out having to type in https each time.
-Original Message-
From: Rene Veerman
Sent: Tuesday, 13 August 2019 07:13
To
nope
On Tue, Aug 13, 2019 at 7:12 AM Jonathan Aquilina
wrote:
> Question have you setup a vhost for apache that will redirect the traffic
> from http to https?
>
>
>
> -Original Message-
> From: Rene Veerman
> Sent: Monday, 12 August 2019 08:06
> To: user@couchdb.apache.org
> Subject: R
Question have you setup a vhost for apache that will redirect the traffic from
http to https?
-Original Message-
From: Rene Veerman
Sent: Monday, 12 August 2019 08:06
To: user@couchdb.apache.org
Subject: Re: running couchdb on a .app domain (https enforced)
i added the DNS records ov
i do need to forward the HTTP and HTTPS ports for the regular apache
webserver to be even reachable on the domain.
yes, the machine that runs nicer.app is hosted on an ADSL home network, as
one of the machines on the LAN cables of the modem.
it does not use VM tech anywhere.
and i checked that uf
HTTP and HTTPS you don’t need to forward those ports. If you notice you can
browse the internet etc both on http and https just fine with out forwarding.
I have a few questions
Is this a machine running on the home network correct? Also is this a VM in a
machine that is running on your home net
Listen I have used lets encrypt and im even using it on my shared hosting
panel. What google is enforcing is the use of HTTPS that is what they are after
you will not run into issues, only with out https will you run into error
messages from the chrome browser.
Also note with lets encrypt you w
oh, just for the record : the only ports forwarded at my ADSL modem to the
machine on the LAN that serves nicer.app, are regular HTTP (80), HTTPS (443
if i'm not mistaken) and 5984 for couchdb.
On Tue, Aug 13, 2019 at 6:40 AM Joan Touzet wrote:
> What output do you get for:
>
> curl --verbose
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
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@albatros
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 star
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 i
Also have you tried to use a lets encrypt free SSL certificate?
-Original Message-
From: Rene Veerman
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.
an
Hi Guys,
I did a quick google and it seems like .app domains are already using HTTPS.
https://www.thesslstore.com/blog/google-launches-dot-app/
What I am not sure is how you would integrate the cert into couch db in this
case if the domains are already using certificates. I don’t think the iss
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 ru
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
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 wrote:
>
> eaddrinuse
ok now i'm really stuck, i'm even getting a crash report that makes no
sense to me, and have explored all the avenues that are safe for a noob at
crypto like myself.
i've added to [ssl] in local.ini, the enable = true and password = {the
password i used when following the tutorial (be sure to save
argh
i edited couchdb local.ini and changed all 5984 references (found only 1,
in [chttpd]) to the new port,
i added a [https] section just to be sure,
then removed the log, restarted couchdb, and it still is stuck at
ERR_CONNECTION_TIMED_OUT, and still serving from 5984?!...
but, i see i
ehm, after actually reviewing the log, perfectly good clue here of course :
couchdb@127.0.0.1 <0.212.0> Apache CouchDB has started on
http://0.0.0.0:5986/
i had thought adding the SSL entries into local.ini would get it to start
at the new port 7984, but apparently it didn't.
i'll dig t
reboot didn't fix the current hurdle, but specifying port forwarding on my
ADSL modem for the new port (i use 7984) did.
however, now itś stuck at ERR_CONNECTION_TIMED_OUT.
the latest section from /var/log/couchdb/couch.log doesnt seem to provide
any clues :(
[notice] 2019-08-12T06:04:14.673813Z
27 matches
Mail list logo
