502 Bad Gateway after reboot

Denis_O 2021-07-17 09:35:24 UTC #7

I followed the exact installation step described here (“For a new 21.1 installation”):

…here (Step by step installation - for Community Edition)…

…here for adding the Ubuntu 20.04-specific repo:
https://software.opensuse.org/download.html?project=server%3AeGroupWare&package=egroupware-epl

…and here:

a few things about the server and its environment
the egw server has IPv4 172.16.15.15/24, GW=.1
AD Domain Ctrl (Univention): 172.16.10.10
Mail server: 172.16.15.11

The egw VM has the following config:
4vCPU
6GB RAM
40GB HD (during the install, I used the default setings “use the entire disk”)

admin@egw:/etc/egroupware-docker$ df -h
Filesystem                         Size  Used Avail Use% Mounted on
udev                               1.9G     0  1.9G   0% /dev
tmpfs                              394M  1.4M  393M   1% /run
/dev/mapper/ubuntu--vg-ubuntu--lv   20G   11G  8.3G  56% /
tmpfs                              2.0G     0  2.0G   0% /dev/shm
tmpfs                              5.0M     0  5.0M   0% /run/lock
tmpfs                              2.0G     0  2.0G   0% /sys/fs/cgroup
/dev/sda2                          976M  107M  803M  12% /boot
/dev/loop0                          56M   56M     0 100% /snap/core18/1944
/dev/loop1                          56M   56M     0 100% /snap/core18/2074
/dev/loop2                          70M   70M     0 100% /snap/lxd/19188
/dev/loop3                          68M   68M     0 100% /snap/lxd/20326
/dev/loop4                          32M   32M     0 100% /snap/snapd/10707
/dev/loop5                          33M   33M     0 100% /snap/snapd/12398
tmpfs                              394M     0  394M   0% /run/user/1000
admin@egw:/etc/egroupware-docker$

Cheers

Denis

Denis_O 2021-07-17 09:38:26 UTC #8

@NK1: yeah that was my first thought too, so I tested with even 8GB RAM but that didn’t make any difference. During the initial VM setup, I had 4GB Ram, now I have added 2 GB for a total of 6GB, but it barely uses 4GB according to the Vcenter Dashboard.

StefanU 2021-07-17 10:45:01 UTC #9

That is more than enough. Very generous…

That should also fit:

And the installation of Ubuntu?
Have you installed anything else besides the basic system with ssh (database, docker, …)?

Stefan

Denis_O 2021-07-18 01:03:47 UTC #10

for the Ubuntu install, I installed the basic server OS and enabled SSH during the install process.
After the OS installation, I followed these instructions:

(section Ubuntu 20.04)

Denis_O 2021-07-18 12:27:31 UTC #11

Quoting:

Just adding my 2 cts here for what it’s worth… I think this is a very, very bad idea to use internal docker networks within the 172.16.0.0/12 range by default, as most enterprise networks will use some addresses or subnets in that range. IMHO it would be much better to use a subnet somewhere in the higher 192.168.0.0/16 range, e.g. 192.168.245.0/24, as these networks are are barely used both in enterprise networks or well designed geek’s home networks. Only basic home users will only use the default 192.168.0.0/24 or 192.168.1.0/24, which are the most common ranges preconfigured in consumer-grade toy-routers. And those people will certainly not have a egw instance running at home! Therefore, in 99,9% of the user cases, docker networks in the higher 192.168.0.0/16 range will never interfere with existing networks.

Cheers

Denis

StefanU 2021-07-18 12:56:34 UTC #12

I understand you. But:
It is not our idea to use this network area. This is Docker standard.

We always use standards whenever possible. That’s why we also described how to change the Docker network.

I have only come across two networks so far where this network range is used. And I have seen many…

But that doesn’t seem to be the problem with you either.
Everyone else can change the network and adapt it to their requirements.

Now I don’t know what to do about your problem either. It could still be that the database is not accessible(?)…

Could you install a new VM with Debian 10 server with EGroupware in parallel and test it (reboot)?
Takes me 8 minutes with Debian 10 template
I had documented this once here:

Stefan

Denis_O 2021-07-18 13:09:28 UTC #13

Thanks for the clarification! It makes perfect sense to leave the default docker network it as it is then.

I am downloading the Debian 10 Image as we speak and will do the installation according to the procedure you provided right after (note that Debian 11 will be released in 2 weeks)

Denis_O 2021-07-18 17:41:52 UTC #14

hum. with the Debian 10VM I get a 404 not found following the 1st reboot. The SSL part did not work at all (I got tons of errors), but http did work after egw install up until I rebooted the system.

docker is running fine:
root@egw02:/home/admax# docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
046b54954e89 quay.io/egroupware/collabora-key:stable “/bin/sh -c 'bash st…” 33 minutes ago Up 7 minutes 127.0.0.1:9980->9980/tcp collabora-key
c2d522bc68f9 nginx:stable-alpine “/docker-entrypoint.…” About an hour ago Up 7 minutes 127.0.0.1:8080->80/tcp egroupware-nginx
147d04de0f08 phpswoole/swoole:4.6-php7.4-alpine “docker-php-entrypoi…” About an hour ago Up 7 minutes egroupware-push
4f5c10ebbad2 containrrr/watchtower:latest “/watchtower --sched…” About an hour ago Up 7 minutes 8080/tcp egroupware-watchtower
c598b8024da5 egroupware/egroupware:21.1 “/entrypoint.sh php-…” About an hour ago Up 7 minutes 9000/tcp egroupware
804c92f7aa89 mariadb:10.4 “docker-entrypoint.s…” About an hour ago Up 7 minutes 3306/tcp egroupware-db
root@egw02:/home/admax#

StefanU 2021-07-18 19:08:17 UTC #15

The cause must lie somewhere in your environment. This is definitely not a general problem.

Have you checked that too?:

Do you have applications running on the UCS that are installed as Docker containers? The UCS also uses the standard Docker network (I think).
On the UCS it is also sometimes necessary to change the Docker network.

Are you virtualising (the EGroupware-VM) on your UCS?

Something like this is difficult to solve within the context of community support.
We also offer support for community users:

In your case, this is certainly more effective, quicker and costs less nerves.

Stefan

Denis_O 2021-07-18 19:53:39 UTC #16

thanks a lot for the links. I will go through them tonight. I suspect the issue to be between the screen and the chair!

I will keep the support as a last option, because this is a purely private deployment, and for private use only. In that sense, 240 EUR/hr is quite some money for a private household. But again, as a last option, I will have to go that road, but I first want to rule out everything else.

Denis_O 2021-07-19 15:15:50 UTC #17

update: On the Debian reinstall, I don’t have the issue as long as I don’t configure ssl. With simple http, I can reboot the server and the webGUI is still accessible. I will dig in that direction.

Denis_O 2021-07-19 15:23:37 UTC #18

@Stefan: in your well documented egw install on Debian 10, you specify in the SSL/letsencrype section that the procedure described is not compatible with egw 20.1. I guess that this is also true for 21.1? In that case, that might be the problem on my Debian test install.

StefanU 2021-07-19 16:36:19 UTC #19

Yes.

I created the description when we still had an Apache reverse proxy installed by default. In the meantime, we use nginx in a standard installation. So also in the 21.1.

But you can orientate yourself on documentations from the net (for Lets encrypt-SSL with nginx).

Stefan

StefanU 2021-07-19 16:36:57 UTC #20

How do you install/configure SSL?

Stefan

Denis_O 2021-07-19 19:07:40 UTC #21

I would like to be able to use both http and https. In the LAN itself I perfer using http as it is easier to troubleshoot (packet captures) if needed. but for accessing the server from the Internet of course ssl is mandatory.

I will do my research and see how to configure ssl for nginx… I hope to be able to report good news soon!

StefanU 2021-07-19 20:28:01 UTC #22

Ohhh

Lets Encrypt can set up automatic forwarding to https for you, or you can leave it alone.

I strongly recommend that you ALWAYS use SSL. This security is also necessary in the internal network.

I also don’t know what you want to read in the traffic. To debug problems with a web application you use the web browser developer tools.

Apart from that:
In a web application that lives on links and linking, how is anything supposed to work with a mixture of https and http addresses?

You also get problems with Collabora Online, Rocket.Chat, Guacamole or whatever you want to integrate in the future.

Please ALWAYS use https. You are doing yourself (and us) a big favour!

Stefan

Denis_O 2021-07-20 11:17:33 UTC #23

well, the encrypted/unencrypted traffic in LAN debate is an old one, revived with the increase of ransomware attacks in recent times… Fact is that SSL encryption inevitably creates blind spots within the Network, which can easily lead to malware to travel through your network unnoticed (cf. Broadcom/Symantec, A10, Gartner 2019 studies among others). The technically best answer to the problem is to perform SSL decryption at strategic points which in turn can cause legal troubles with GDPR. Professionally, I had to struggle a lot with such designs in the last couple of years.

In this particular case with egw however, I indeed makes sense to have ssl everywhere, I agree, and I’m gonna go down this path especially if it may interfere with some modules as you pointed out. Maybe I’ll ask for a wirespeed SSL decryptor for Xmas to make things perfect.

I’ll check how to use letsencrypt with nginx later this afternoon.

Denis_O 2021-07-21 14:48:21 UTC #24

Okay, I got it working. I used this procedure to setup encryption:

I decided to go for a self-signed certificate as all certificates issues for free (Letsencrypt and others) need to be renewed every 3 months, and honestly I don’t have the patience to do that 4x/year. I will buy a certificate on a yearly basis (or more) as it doesn’t cost that much.

I also found a way aound my unencrypted vs ssl dilemma: I have set it up encrypted, and if I need to tshoot a session between a user and the server, I can just remove the auto redirect in the egroupware.conf file during tshoot if needed, and reenabling it afterwards (just needs to restart nginx for that)

StefanU 2021-07-21 15:14:09 UTC #25

Works automatically. If you want…

grafik

Stefan

StefanU 2021-07-21 15:14:38 UTC #26

Stefan