No response from "Log in" button

General Discussions
21

It’s a VM running on Azure. It’s running as an x86_64 with Ubuntu 18.04 and Docker 19.03.6.

22

right. could we rule out the possible issues on the local side?
could you run the browser locally from that machine and use e.g. ssh -X host firefox from your desktop or something similar to display the browser from the server and see what happens?

peter

23

status update: I am trying to run exactly the same setup and replicate, since I have gone to the end of this one way dead end street.

peter

24

I did try the local test and it still seemed to behave the same way. Slow connection and processor didn’t help with trying to do a remote GUI.

It sounds like you’ve done everything you can. I appreciate the extra effort and time you’ve put into this. I’ll keep plugging away at it and will post back here if I find something definitive.

Ken

25

thanks! I will let you know if I find something.

sorry for the inconvenience
peter

26

hello,

ok, I was able to reproduce the issue with fresh 2.5.x installation, new LE certificates and fresh host. I will let you know tomorrow about the progress of the investigation.

best regards,
peter

27

could you please check the logs from api-gateway container, and check if you see there something like connect() failed (111: Connection refused) while connecting to upstream, client: xxxx, server: xxxx, request: "POST /api/management/v1/useradm/auth/login HTTP/1.1", upstream: "http://192.168.80.11:8080/api/management/v1/useradm/auth/login"

and more importantly could you please check the status of mongodb, does it restart? I am getting:

# docker ps | grep mongo
442d3a899c14        mongo:4.4                                            "docker-entrypoint.s…"   33 minutes ago      Restarting (14) 20 seconds ago                                  menderproduction_mender-mongo_1

with

{"t":{"$date":"2020-11-23T22:59:45.074+00:00"},"s":"W",  "c":"STORAGE",  "id":22347,   "ctx":"initandlisten","msg":"Failed to start up WiredTiger under any compatibility version. This may be due to an unsupported upgrade or downgrade."}
{"t":{"$date":"2020-11-23T22:59:45.075+00:00"},"s":"F",  "c":"STORAGE",  "id":28595,   "ctx":"initandlisten","msg":"Terminating.","attr":{"reason":"95: Operation not supported"}}
{"t":{"$date":"2020-11-23T22:59:45.075+00:00"},"s":"F",  "c":"-",        "id":23091,   "ctx":"initandlisten","msg":"Fatal assertion","attr":{"msgid":28595,"file":"src/mongo/db/storage/wiredtiger/wiredtiger_kv_engine.cpp","line":1123}}
{"t":{"$date":"2020-11-23T22:59:45.075+00:00"},"s":"F",  "c":"-",        "id":23092,   "ctx":"initandlisten","msg":"\n\n***aborting after fassert() failure\n\n"}

The above is due to problems with mongo:4.4. @kdavidson if it is a new installation (e.g.: you have nothing to loose atm) you can try running mongo 4.0 which for me solved the issue:

diff --git a/docker-compose.yml b/docker-compose.yml
index b1d7754..ce0835c 100644
--- a/docker-compose.yml
+++ b/docker-compose.yml
@@ -143,7 +143,7 @@ services:
             - mender-mongo

     mender-mongo:
-        image: mongo:4.4
+        image: mongo:4.0
         extends:
             file: common.yml
             service: mender-base

Thats all I can offer now.
Is it possible that you have had some previous docker volumes with mongodb?
The only way I can explain what has happened is: there was an existing mender-db volume:

# docker volume ls | grep -F mender-db
local               mender-db

which contained mongo db v3.6 data dir. the new db version (4.4) used in 2.5.0 cannot be immediately run over 3.6 datadir. if you are sure you do not have any data stored in that volume you can remove it:

docker volume rm mender-db

and recreated it:

# docker volume create --name=mender-db
mender-db

and then restart, creating the initial user again.
If you have some data in the mender-db volume, you have to go through the regular mongodb upgrade from 3.6 to 4.4.

peter

28

Well, it’s working. I thought that the keys generated by Let’s Encrypt had to go in both the certs subfolders and the keys subfolders. However, when I left the private.key files as they were generated by the Mender keygen in the keys subfolders and put the Let’s Encrypt certs and keys in the certs subfolders, it started working.

I don’t have the time or desire to do more testing to ensure that this was absolutely the cause, but it’s working now.

Thanks again for all your help.

Ken