Unable to Run After Updating to 0.4 #56
Comments
|
ugh, hm, how did that happen? i'll take a look tomorrow. |
|
Actually I didn't really catch the first few errors until I found out my domain ssl registration check in letsencrypt has been blocked due too too many request (probably nginx trying multiple times after unsuccessfull restart). So I switched to customssl from cloudflare and change the .env settings (just to clarify i had to set the domain to "local" is it right? and ssl to "customssl"). Then the above errors occured even though I already remove the images and container beforehand and start update : I fix the first 2 line warning above by removing "text/html" in odk.conf.template (turns out gzip already enable text/html by default so didn't need to be mentioned) but I still I haven't find out where the settings in "/etc/nginx/sites-enabled/default". |
|
thanks for the update—mostly i am still confused why we didn't see this when we did our own upgrade and fresh install testing. |
|
Looks like a similar issue has been reported at https://forum.opendatakit.org/t/odk-central-v0-4-setup-duplicate-default-server-error/17942. |
|
still looking into this. for whatever reason none of our own installations are showing this behavior, but we have 2 or possibly 3 reports of what you're seeing. would you mind running the diagnostics i suggest here and seeing what you get? |
|
sure, is there any command i have to run? btw, I've tried deleting all previous docker with docker prune system (-a and --volumes) and restart the installation process from start using root user. Here's the log in systemctl status docker-compose@central before the nginx exited with process 1 and here's the log when I run using letsencrypt in looks like on both occasion the nginx failed to start, on the letsencrypt case it failed certbot authentication because invalid response from the webserver. here's the debian server version i use : while I'm at it, is it compatible to use newer debian version (stretch - 9)? while the odk-central is in docker environment I just want to make sure it stays compatible. |
Closed
|
okay, i think i've found the issue (#57); would you mind pulling the latest |
|
trying from fresh install in debian 9 as root, this time the error is different I set the edit : using customssl, now server finally up again, only the warning still persist |
|
the failure there would have happened earlier in the log, when letsencrypt
tried to run. if you’re still interested in a resolution here, would you
mind finding that and pasting it?
…On Tue, Feb 19, 2019 at 05:08 Ark ***@***.***> wrote:
Reopened #56 <#56>.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#56 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AAHMAppCqwdwTQxKkvGZiFvVIIm2OLY5ks5vO_dagaJpZM4a_e1g>
.
|
|
sure, do you want the error log from last docker-compose run when using letsencrypt or is there something else I need to paste here? edit : i need to replace my mouse from kept closing and opening this report |
|
for this warning : may I suggest removing the "text/html" in : as for this logs : might it be related to why letsencrypt failed? edit : I also have this warning when I use |
|
as for the former, i agree; we will do that for the next release. but it probably doesn't hurt anything for it to be present for the time being. as for the optimal variables_hash warning being related to letsencrypt, mayybe. but if letsencrypt failed, you should see that failure earlier in the log somewhere. as an example, here is the successful run on my server: when it was failing, instead of the as for the |
|
Few question before I'll try to recreate the previous error when using letsecnrypt :
|
|
it is not necessary to delete those files. it should not be necessary to delete containers and volumes; just running build should do it. |
|
Sorry for late reply, here's the error log when running using letsencrypt : there's no change in my domain name and previously it just works with letsencrypt, the error somewhat related to failed challange (response) from the nginx server? |
|
so, the problem here is that the domain name needs to be set in the |
sorry forgot to tell that and is indeed set with my domain name and email in the |
|
oh, okay, i see. hmm, what happens if you run
|
here's the log from letsencrypt.log, (I don't know if any other sensitive information, I hope I don't forgot to replace them 😄) |
|
hmmmm. the only thing i can see before the failure occurs (when letsencrypt tries to connect to your server) that seems weird is that your server has both IPv6 and IPv4 addresses, and however that is set up certbot was only able to attach to the IPv6 but not the IPv4 address. later on, it claims to be trying IPv6, but my experience with IPv6 in general is that sometimes these sorts of splits can cause problems. either way, the root problem is that your machine is capable of connecting to letsencrypt and setting up the authorization, but that when letsencrypt tries to connect back to you over a direct IP connection, it is unable to do so. there is a small snippet of HTML it outputs from the failure; i'm not sure where that HTML comes from but it resembles neither the ODK Central HTML nor the nginx error page, so i'm not really sure what letsencrypt is hitting instead of the certbot verifier. |
|
Interesting, didn't though about it before because not long ago letsencrypt in odk central works. It might be my vps provider or cloudflare is the culprit, I'll have a look at that. Meanwhile I'm quite satisfied that customssl using cloudflare works for this time. |
|
okay, great. i'm glad it's working, and thanks for taking a look! |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
After updating odk central to 0.4 and following the readme, I managed to run odk-central using docker-compose up -d, but somehow odk-central cannot be accessed in browsers with "This site can’t be reached" error. Is there any step in updating that I missed?
edit : i try to start docker-compose and here's the snippet of the log I suspect the culprit :
The text was updated successfully, but these errors were encountered: