Update auf 19.1 - nichts geht mehr

[TomH]

In der mySQL Tabelle egw_config habe ich

auth_type = mail
mail_server = localhost:143
mail_server_type = imap

Ich vermute nun, dass aus dem Container heraus “localhost:143” halt nicht erreicht werden kann.

FYI: Password Reset hat funktioniert auf der 17.1, dank [Stefans Antwort hier auf dieses Thema].(Upgrade failed. Egroupware is not working).

Ich probiere in kürze weiter. Wenn ich dann in das Setup-&Konfigurations-Tool reinkomme, so hoffe ich, kann ich dann hier die richtige IP einstellen.

Ich frage mich, was diese IP Adresse ist: 172.18.0.4(?)

Ich erkenne nun den Sinn der IP Adresse, ich sehe dass dieses Docker-Dinges mir weitere virtuelle Netzwerkkarten anlegt, wohl um über diese mit diesem mini virtuellen Container zu kommunizieren.

Ich werde immer weniger Freund von diesem Docker-Konzept und überlege mir nur für eGroupware einen eigenen Server anzulegen, denn was das Docker-Dinges an Konfigänderungen am ganzen OS vornimmt finde ich persönlich nun schon etwas zuviel des guten

[RalfBecker]

WARNING: Error loading config file:/root/.docker/config.json - read /root/.docker/config.json: is a directory

Dazu habe ich schon was geschrieben und mit dem vorgestern aktualisierten Paket passiert das auch nicht mehr. Für einfach folgende Kommandos aus:

rm -rf /root/.docker/config.json
echo "{}" > /root/.docker/config.json
cd /etc/egroupware-docker
docker-compose stop watchtower
docker-compose rm -r watchtower
docker-compose up -d

docker stop b9f6b1445447

Den EGroupware Container alleine stoppen und starten funktioniert in der Regel nicht, weil er eine andere IP bekommt und Nginx das nicht mitkriegt. Besser alles per docker-compose machen.

Ralf

[RalfBecker]

Wenn ich nun in diese files schauen möchte, dann…

[root@mail ~]# cat /usr/share/egroupware/api/src/Auth.php
cat: /usr/share/egroupware/api/src/Auth.php: No such file or directory

Vermutlich sind die auch nur in dem Container. Hmm… wie komme ich da ran?`

Habe ich auch schon ein paarmal was dazu geschrieben: Die Sourcen sind in dem Container unter /usr/share/egroupware-sources und werden vom entrypoint.sh Skript beim Start in ein Volume kopiert das sich Nginx und der EGroupware Container teilen (dort unter /usr/share/egroupware gemounted).
Einfach nur anschauen der Sourcen funktioniert auf Github vermutlich besser, Du kannst aber auch in dem Container eine Shell starten und zur Not einen Editor:

docker exec -it egroupware bash
apt install -y vim
vi /usr/share/egroupware/api/src/Auth.php
exit # the shell in the container
docker-compose restart egroupware

Das Restart am Ende ist bei Änderungen wichtig, da der OPCache im Container die Sourcen nicht mehr permanent auf Änderungen überprüft (bessere Performance). Es ist auch in der Regel nicht notwendig irgendwas im Container zu ändern. Alle Daten und unser Konfigfile header.inc.php liegen - wie bisher - außerhalb unter /var/lib/egroupware.

Ralf

[RalfBecker]

Ich vermute nun, dass aus dem Container heraus “localhost:143” halt nicht erreicht werden kann.

localhost im Container ist der Container selbst nicht der Host. Entweder die IP des Hosts oder der docker0 Bridge verwenden, steht auch in der Dokumentation!

Ich werde immer weniger Freund von diesem Docker-Konzept und überlege mir nur für eGroupware einen eigenen Server anzulegen, denn was das Docker-Dinges an Konfigänderungen am ganzen OS vornimmt finde ich persönlich nun schon etwas zuviel des guten

Einer der Gründe für Docker ist das Du am Host eben keine Änderungen vornehmen musst und unterschiedlichste Anwendungen damit zusammen installieren und rückstandsfrei deinstallieren kannst.

Ralf

[TomH]

Hi Ralf

Danke dir, die Infos helfen ungemein.

So weiss ich,

• wie ich an die Shell des Docker Containers komme
• dass ich wohl auf der richtigen Spur bin (localhost im Container ist localhost des Containers).

Ja, ich verstehe den Standpunkt von dir/euch.

Das mit dem Rückstandslos entfernen: Ist mir nicht wichtig, warum soll ich das wollen? Und wenn ich wollen würde, dann könnte ich nach einer Deinstallation der RPMs immer noch die ‘left over’ files löschen + das eine oder andere zusätzlich gekommene Paket wegnehmen, wenn es mich stören würde.

Notabene: Ganz Rückstandslos kriege ich es auch mit Docker nicht weg, da ja auch Docker wiederum neue Sachen mitbringt, die ich dann (evtl.) nicht Rückstandslos weg kriege. Ich zähle Docker zu eGw dazu; verstehe aber schon, dass es nicht eGw ist, wenn ich für Docker anderweitigen Bedarf hätte. Ich mag einfach eine Virtualisierung mit den NIC Bridges etc auf einem Guest-Server nicht wirklich. Habe heute auch gerade gelesen, dass Dockers Finanzierung nicht gesichert ist; evtl. verschwindet dies bald wieder.

Soweit des politischen; ich widme mich in den kommenden Tagen wieder dem technischen.

Danke nochmals vorab, ich weiss es sehr zu schätzen.

Baldiges Wochenende und Gruss
Tom

[RalfBecker]

Habe heute auch gerade gelesen, dass Dockers Finanzierung nicht gesichert ist; evtl. verschwindet dies bald wieder.

Da geht es um die Firma Docker nicht Docker als Technologie. Im Moment würde ich sagen wenn irgendwo die Zukunft liegt dann bei Docker bzw. Kubernetes!

Ralf

[StefanU]

Hi Tom.

Habe heute auch gerade gelesen, dass Dockers Finanzierung nicht gesichert ist; evtl. verschwindet dies bald wieder.

Docker als Technik ist gesetzt. Die kleine Firma dahinter wird nicht zwingend benötigt. Der Laden ist aber mit einer verhältnismäßig kleinen Geldspritze von -sagen wir mal- 100M wieder flott. Nur das Geschäftsmodell muss für den Investor auch mal Geld abwerfen.

Docker ist heute Basis von allen Rechenzentren. Auch Amazon AWS, Mickisoft und Konsorten.
Verschwinden wird da erst einmal nichts.
Ich betreue auch bei meinem Arbeitgeber Server mit ERP-Systemen. Darauf läuft auch Docker, um weitere Software (meist Drittsoftware) zu integrieren und dann auch aktualisieren zu können.

Docker ist auch erst einmal nur eine Weiterentwicklung/Evolution von Linux-Container-Technologie. Ich hatte das hier

🇩🇪 Docker (in EGroupware 19.1)?

ein wenig ausgeführt.

Docker ist keine Eintagsfliege oder Randerscheinung.

Du kannst dich ja auch mal auf DockerHub und Quay (RedHat) umschauen:
https://hub.docker.com/search?q=egroupware&type=image
https://quay.io/search

Dann erahnst du die Dimensionen.
Wer heute seine Software nicht als Docker-Container anbietet braucht gar nicht mehr anfangen. Ist so.

Gruß
Stefan

[TomH]

Hi Zusammen

Wer heute seine Software nicht als Docker-Container anbietet braucht gar nicht mehr anfangen. Ist so.

Dann wird der Schritt wohl eher der sein, einen fetten Server zu haben, der für das hosten von vielen Docker Containern ausgelegt ist, anstatt einen Mailserver im klassischen Sinne zu haben, der noch einen Docker Container hostet.

Dann würde ich eben eher daran denken, ein Mail- / DB Backend zu betreiben und vorgelagert einen Docker-Applikationsserver, der dieses Mail- & DB Backend nutzt. Aktuell ist es bei mir nur eGw, welches dieses Bedürfnis hat.

Was aber ja nicht heissen muss, dass es so bleibt in Zukunft; plötzlich kommt noch dies und das.

Wie gesagt; ich verstehe euren Standpunkt schon. Ich gebe zu: Bin eher konservativ unterwegs.

Gruss
Tom

[RalfBecker]

Irgendwie tut mein %{centos_version} >= 8 nicht, habe die CentOS 8 Sachen jetzt mal auskommentiert und neuen Bau angworfen.

Sprich sollte in ein paar Minuten nach einem yum clean metadata wieder tun.

Ralf

[TomH]

Hi Ralf

Das docker-ce Paket wird im “EXTRAS” Repo von CentOS 7 nach wie vor nicht gefunden.

Gruss
Tom

[RalfBecker]

docker-ce soll nur für CentOS 8 verwendet werden nicht für CentOS 7 und es war noch nie in CentOS Extras sondern ist von Docker selbst.

Dh. Du solltest unter CentOS 7 (nach einem yum clear metadata) keine Abhänigkeit auf docker-ce mehr haben.

Ralf

[TomH]

Verstehe . Danke für die Erklärung.

Gruss
Tom

[TomH]

Hi Leute

Ich habe erfolgreich upgedatet. Danke für die Hilfe. Grundsätzlich:

• Ich war noch auf CentOS 7.6, das Update auf 7.7 umfasste 500 Updates.
• Ich hatte erstmal von CentOS 7.6 auf CentOS 7.7 upgedatet, ohne eGw.
• Danach hatte ich noch eGw nachgezogen.

Dies lief dann auch auf Anhieb durch.

Nach dem Update zwei Anpassungen:

1. https://myserver/egroupware/setup/config.php
   POP/IMAP Mail Server Hostname oder IP Adresse[:port]: von localhost auf die reale IP meines Servers geändert: In meinem Fall 10.0.1.32

2. https://myserver/egroupware
   Als eGw Administrator angemeldet an das normale WebGUI. Dann via Mail > Konto bearbeiten… die Postein- & Postausgangsserver ebenfalls von localhost auf die reale IP gewechselt (durch Zugewiesen an “Alle Anwender” war dies für alle Benutzer umgeschaltet).
   

   
   
   
   
   
   
   

Freude herrscht

[TomH]

Oh, die Freude war nur von kurzer dauer.
Nach einem Serverneustart dieses Bild:

# systemctl status mariadb
Oct 07 23:16:51 mail.netcult.ch systemd[1]: Starting MariaDB database server...
Oct 07 23:16:51 mail.netcult.ch mariadb-prepare-db-dir[5495]: Database MariaDB is probably initialized in /var/lib/mysql already, nothing is done.
Oct 07 23:16:51 mail.netcult.ch mariadb-prepare-db-dir[5495]: If this is not the case, make sure the /var/lib/mysql is empty before running mariadb-prepare-db-dir.
Oct 07 23:16:51 mail.netcult.ch mysqld_safe[5532]: 191007 23:16:51 mysqld_safe Logging to '/var/log/mariadb/mariadb.log'.
Oct 07 23:16:51 mail.netcult.ch mysqld_safe[5532]: 191007 23:16:51 mysqld_safe Starting mysqld daemon with databases from /var/lib/mysql
Oct 07 23:16:58 mail.netcult.ch systemd[1]: mariadb.service: control process exited, code=exited status=1
Oct 07 23:16:58 mail.netcult.ch systemd[1]: Failed to start MariaDB database server.
Oct 07 23:16:58 mail.netcult.ch systemd[1]: Unit mariadb.service entered failed state.
Oct 07 23:16:58 mail.netcult.ch systemd[1]: mariadb.service failed.

# cat /var/log/mariadb/mariadb.log
191007 23:16:52 InnoDB: Completed initialization of buffer pool
191007 23:16:52 InnoDB: highest supported file format is Barracuda.
191007 23:16:52  InnoDB: Waiting for the background threads to start
191007 23:16:53 Percona XtraDB (http://www.percona.com) 5.5.61-MariaDB-38.13 started; log sequence number 5807494914
191007 23:16:53 [Note] Plugin 'FEEDBACK' is disabled.
191007 23:16:53 [Note] Server socket created on IP: '0.0.0.0'.
191007 23:16:53 [ERROR] Can't start server : Bind on unix socket: Address already in use
191007 23:16:53 [ERROR] Do you already have another mysqld server running on socket: /var/lib/mysql/mysql.sock ?
191007 23:16:53 [ERROR] Aborting

191007 23:16:53  InnoDB: Starting shutdown...
191007 23:16:57  InnoDB: Shutdown completed; log sequence number 5807494914
191007 23:16:57 [Note] /usr/libexec/mysqld: Shutdown complete

191007 23:16:57 mysqld_safe mysqld from pid file /var/run/mariadb/mariadb.pid ended


# cd /etc/egroupware-docker
# docker-compose logs -f
Attaching to egroupware-nginx, egroupware-watchtower, egroupware
egroupware-nginx | 2019/10/07 21:10:34 [emerg] 1#1: host not found in upstream "egroupware:9000" in /etc/nginx/conf.d/default.conf:8
egroupware-nginx | nginx: [emerg] host not found in upstream "egroupware:9000" in /etc/nginx/conf.d/default.conf:8
egroupware-nginx | 2019/10/07 21:10:40 [emerg] 1#1: host not found in upstream "egroupware:9000" in /etc/nginx/conf.d/default.conf:8
egroupware-nginx | nginx: [emerg] host not found in upstream "egroupware:9000" in /etc/nginx/conf.d/default.conf:8
egroupware-nginx | 2019/10/07 21:10:46 [emerg] 1#1: host not found in upstream "egroupware:9000" in /etc/nginx/conf.d/default.conf:8
egroupware-nginx | nginx: [emerg] host not found in upstream "egroupware:9000" in /etc/nginx/conf.d/default.conf:8
egroupware-nginx | 2019/10/07 21:10:52 [emerg] 1#1: host not found in upstream "egroupware:9000" in /etc/nginx/conf.d/default.conf:8
egroupware-nginx | nginx: [emerg] host not found in upstream "egroupware:9000" in /etc/nginx/conf.d/default.conf:8
egroupware-nginx | 2019/10/07 21:10:59 [emerg] 1#1: host not found in upstream "egroupware:9000" in /etc/nginx/conf.d/default.conf:8
egroupware-nginx | nginx: [emerg] host not found in upstream "egroupware:9000" in /etc/nginx/conf.d/default.conf:8
egroupware-nginx | 2019/10/07 21:11:06 [emerg] 1#1: host not found in upstream "egroupware:9000" in /etc/nginx/conf.d/default.conf:8
egroupware-nginx | nginx: [emerg] host not found in upstream "egroupware:9000" in /etc/nginx/conf.d/default.conf:8
egroupware-nginx | 2019/10/07 21:11:15 [emerg] 1#1: host not found in upstream "egroupware:9000" in /etc/nginx/conf.d/default.conf:8
egroupware-nginx | nginx: [emerg] host not found in upstream "egroupware:9000" in /etc/nginx/conf.d/default.conf:8
egroupware-nginx | 2019/10/07 21:11:29 [emerg] 1#1: host not found in upstream "egroupware:9000" in /etc/nginx/conf.d/default.conf:8
egroupware-nginx | nginx: [emerg] host not found in upstream "egroupware:9000" in /etc/nginx/conf.d/default.conf:8
egroupware-nginx | 2019/10/07 21:11:52 [emerg] 1#1: host not found in upstream "egroupware:9000" in /etc/nginx/conf.d/default.conf:8
egroupware-nginx | nginx: [emerg] host not found in upstream "egroupware:9000" in /etc/nginx/conf.d/default.conf:8
egroupware-nginx | 2019/10/07 21:12:24 [emerg] 1#1: host not found in upstream "egroupware:9000" in /etc/nginx/conf.d/default.conf:8
egroupware-nginx | nginx: [emerg] host not found in upstream "egroupware:9000" in /etc/nginx/conf.d/default.conf:8
egroupware-nginx | 2019/10/07 21:13:21 [emerg] 1#1: host not found in upstream "egroupware:9000" in /etc/nginx/conf.d/default.conf:8
egroupware-nginx | nginx: [emerg] host not found in upstream "egroupware:9000" in /etc/nginx/conf.d/default.conf:8
egroupware-nginx | 2019/10/07 21:15:09 [emerg] 1#1: host not found in upstream "egroupware:9000" in /etc/nginx/conf.d/default.conf:8
egroupware-nginx | nginx: [emerg] host not found in upstream "egroupware:9000" in /etc/nginx/conf.d/default.conf:8
egroupware-nginx | 2019/10/07 21:18:39 [emerg] 1#1: host not found in upstream "egroupware:9000" in /etc/nginx/conf.d/default.conf:8
egroupware-nginx | nginx: [emerg] host not found in upstream "egroupware:9000" in /etc/nginx/conf.d/default.conf:8
egroupware    | container_linux.go:235: starting container process caused "container init exited prematurely"
egroupware exited with code 128

Halleluja!

[TomH]

191007 23:16:53 [ERROR] Can't start server : Bind on unix socket: Address already in use`

Nun ist es so, dass auf dem Port 3306 nichts anderes läuft. Revert back auf snapshot. Ich glaube ich werde mit meinem Server/dieser Installation auf der 17.1er Version festsitzen.

[RalfBecker]

191007 23:16:53 [ERROR] Can’t start server : Bind on unix socket: Address already in use
191007 23:16:53 [ERROR] Do you already have another mysqld server running on socket: /var/lib/mysql/mysql.sock ?

Das Problem ist einfach erklärt, bei Dir startet Docker anscheinend vor der MariaDB. Da der Socket der MariaDB in den Container gereicht wird, legt ihn Docker leider als Verzeichnis an, wenn er beim Start des Containers noch nicht existiert

Einfach zu beheben:

rmdir /var/lib/mysql/mysql.sock
systemctl restart mariadb
cd /etc/egroupware-docker
docker-compose stop egroupware
docker-compose rm -f egroupware
docker-compose up -d

Man könnte bei EGroupware einen Init-Container hinlegen, der auf den Start der MariaDB wartet. Das wäre die schönste Lösung, wenn wir ausschließlich MariaDB/MySQL auf dem Host unterstützen würden, in anderen Szenarien sorgt das halt dafür, dass EGroupware nie startet …

Eine anderes Lösung wäre in der docker.service Unit folgendes einzufügen:

Requires=mariadb.service

Dann sorgt systemd dafür, dass MariaDB for Docker gestartet wird.

Bisher bist Du auch der erste der so ein Problem meldet. Tritt das reproduzierbar immer auf?

Ralf

[xenolevis]

Tritt das reproduzierbar immer auf?

Yup, happens to me whenever I reboot.
Server version: 5.7.27 - MySQL Community Server (GPL)

[TomH]

Hi Ralf

Danke, dies hat geholfen.

Eine anderes Lösung wäre in der docker.service Unit folgendes einzufügen:
Requires=mariadb.service

Dies hat nicht funktioniert, frag mich nicht warum - in der Theorie wäre dies schon der passende Ort.
Es hat nur funktioniert, wenn ich es hier eingefügt habe.

After=mariadb.service

Evtl. hilft der Script im Anschluss an die Installation. Dies identifiziert ob mariadb auf dem Host gefunden wird, und falls ja, dann fügt es die Option in /etc/systemd/system/multi-user.target.wants/docker.service ein. Halt sehr rudimentär, kann sicherlich noch verbessert werden.

#!/bin/bash

SVC_CHECK=mariadb
DKR_START=/etc/systemd/system/multi-user.target.wants/docker.service

if [ `systemctl status ${SVC_CHECK} | grep "${SVC_CHECK}.service could not be found" | wc -l` -gt 0 ]
then
  echo "- ${SVC_CHECK} not present"
else
  echo "- ${SVC_CHECK} present"
  if [ -f "${DKR_START}" ]
  then
    if [ `cat ${DKR_START} | grep "${SVC_CHECK}.service" | wc -l` -gt 0 ]
    then
      echo "-- ${DKR_START} exist - dependency already present"
    else
      echo "-- ${DKR_START} exist - apply dependency"
      OUTPUT=`sed "/After=network.target/ s/\$/ ${SVC_CHECK}.service/" ${DKR_START}`
      echo "${OUTPUT}" > ${DKR_START}
    fi
  else
    echo "-- ${DKR_START} does not exist - exit"
  fi
fi

Hinweis: Wenn du mit After= arbeitest, dann startet der Docker Service auch wenn mariadb disabled wäre (und vermutlich auch, wenn mariadb gar nicht installiert wäre).

Update: Wie xenolevis schrieb: War reproduzierbar.

Gruss
Tom

[RalfBecker]

Hi Tom,

werde ich mir zusammen mit CentOS 8 für das nächste Maintenance Release nochmal anschauen.

Mir gefällt nicht in den systemd Units eines anderen Pakets rumzuschreiben, schöner wäre eine Lösung innerhalb unseres docker-compose Files …

Ein anders Problem mit dem Bindmount des Datenbank Sockets ist ein Restart der Datenbank, dann geht die EGroupware auch nicht mehr (ohne einen Restart).

Evtl. würde es helfen, nicht den Socket selbst, sondern das ganze Verzeichnis /var/run/mysqld zu mounten, dann wäre es egal ob MariaDB/MySQL schon gestartet ist oder auch gerestarted wird.

Wenn Du Muse hast kannst Du das gerne mal ausprobieren und hier berichten (ohne After=… in der Docker Unit).

Ralf

[TomH]

Ok.

Noch als Info: Musste noch Relaying für die IP 172.18.0.3 in Sendmail erlauben, damit eGw Mails aus dem Container heraus versenden konnte.