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)
Willkommen im EGroupware-Community-Forum.
Bitte beachte: Bedienungsanleitung Forum, EGw-FAQ und richtig posten.
Folge uns: 
Welcome to the EGroupware community forum.
Please note: User manual Forum, EGw-FAQ and post correctly.
Follow us:
(section Ubuntu 20.04)
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
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
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)
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#
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
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.
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.
@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.
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
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!
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
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.
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)
For example, if you use certbot, it will be set up automatically:
I had also written this in the old instructions for an Apache reverse proxy:
And a bit more about how to configure the SSL even more securely.
Stefan
Sold! I’m going for that solution. I didn’t think about automating the renewal process with cron jobs. As said, I’m really new at linux so I don’t have all the. guru reflexes (yet).
That being said, I’d like to thank you very much for your support, Stefan, and I have to say that I’m really impressed with egroupware. Even from a graphical perspective it really stands ahead of all other groupware solutions, both free or proprietary (in my opinion, though).
Cheers
Denis