Installation Debian Bookworm

svenp1 2023-05-31 08:56:49 UTC #1

Hallo, ich habe mir eGroupware Docker auf einer VM installiert.

Wenn ich mich an die Anleitung

halte. Bekomme ich nach dem eintragen des Repo den Fehler:

W: http://download.opensuse.org/repositories/server:/eGroupWare/xUbuntu_22.04/InRelease: Schlüssel ist im veralteten Schlüsselbund trusted.gpg gespeichert (/etc/apt/trusted.gpg), siehe den Abschnitt MISSBILLIGUNG in apt-key(8) für Details.

Das verschieben des trusted.php nach /etc/apt/trusted.php.d hat geholfen.

Nur zu Info wenn Ralf das anpassen möchte.

Bei der installation bekomme ich dann folgenden Fehler:

egroupware-docker (23.1.20230314-1) wird eingerichtet ...
Synchronizing state of docker.service with SysV service script with /lib/systemd/systemd-sysv-install.
Executing: /lib/systemd/systemd-sysv-install enable docker
No stopped containers
ls: Zugriff auf '/var/lib/docker/volumes/egroupware*docker_sources/_data/swoolepush' nicht möglich: Datei oder Verzeichnis nicht gefunden
Creating network "egroupware-docker_default" with the default driver

Die Frage ist bekomme ich wegen der swooole Meldung Probleme oder kann ich diese Ignorieren?

Debian 12 Pakete - Update der Anleitung?

StefanU 2023-05-31 10:22:08 UTC #2

Warum verwendest du kein Debian stable?
Und bindest das korrekte Repo für Debian ein?

Stefan

svenp1 2023-05-31 10:27:48 UTC #3

Weil bookworm jetzt freezed ist und eh kommt.
Warum soll ich mir doppelte Arbeit machen.
Der genannten Fehler haben auch nichts mit Bookworm zu tun sondern kommen genauso bei dem Mint Laptop.

itwo 2023-05-31 11:24:00 UTC #4

Das steht so tatsächlich im Code (Zeile 134), da geht es um eine Anpassung wenn ich das richtig verstehe:

itwo 2023-06-01 08:54:44 UTC #5

@RalfBecker ist das ein Bug, leider verstehe ich den Hintergrund dieser Anpassung nicht.

Wird es bald Debian 12 (Release 10.06.) Pakete geben?

RalfBecker 2023-06-03 06:23:38 UTC #6

Sobald Debian 12 auf dem OpenBuildService verfügbar ist, kann ich dort Pakete dafür bauen. In der Regal warten die auf das offizielle Release.

Zu den zwei Fehlern:

Ich habe nur ein Paket für alle Debian/Ubuntu Releases, deswegen ist der alte und der neue Weg den Schlüssel abzulegen enthalten. Die aktuellen Distributionen warnen nun, das sie den alten ignorieren, was aber nix macht, da der Schlüssel ja auch an der Stelle liegt, wo sie ihn erwarten.

Weiß nicht ob es sich lohnt da eine Detection einzubauen …

Das ist tatsächlich ein Fehler

Kannst Du mal auf dem System docker volume ls ausführen und das Ergebnis hier posten.

Der Fehler sorgt dafür, dass der Push nicht funktioniert.

Ralf

svenp1 2023-06-03 08:44:26 UTC #7

Guten Morgen Ralf,

anbei das Ergebnis:

local     egroupware-docker_data
local     egroupware-docker_db
local     egroupware-docker_extra
local     egroupware-docker_push-config
local     egroupware-docker_sessions
local     egroupware-docker_sources
local     egroupware-docker_sources-push
local     egroupware-docker_videos
local     egroupware-rocketchat_mongo

RalfBecker 2023-06-03 13:16:25 UTC #8

Kannst Du Deine docker-compose.override.yml posten (prüfe bitte das keine Passworte drin sind, oder maskiere sie z.B. mit Sternen).

Gibt Dir der Push Test in Admin eine rote oder grüne Nachricht untern rechts?

Ralf

svenp1 2023-06-03 13:33:52 UTC #9

Ist alles grün

grafik

Meine Override ist sehr langweilig. Ich habe nur das Session Timeout verlängert.
Der Rest passt meiner Meinung recht gut.

version: '3'

#volumes:
  # EGroupware data stored in /var/lib/egroupware on the host
  #data:
  #  driver_opts:
  #    type: none
  #    o: bind
  #    device: /var/lib/egroupware

services:
  egroupware:
    # egroupware images to use:
    # - egroupware/egroupware: is the community edition of egroupware
    # - download.egroupware.org/egroupware/epl: is the EPL / subscription version of EGroupware GmbH
    # egroupware tags to use:
    # - latest: recommended is to use tag latest for automatic updates incl. new stable major releases
    # - 23.1: use a branch to keep on latest maintenance release for that branch, but not update automatic to next release
    # - 23.1.20230125: use a maintenance release, to disable automatic updates via watchtower and run them manually
    image: egroupware/egroupware:23.1
    #volumes:
    # if you want to use the host database:
    # 1. follow instructions below to disable db service
    # 2. set EGW_DB_HOST=localhost AND
    # 3. uncomment the next line and modify the host path, it depends on your distro:
    #    - RHEL/CentOS   /var/lib/mysql/mysql.sock:/var/run/mysqld/mysqld.sock
    #    - openSUSE/SLE  /var/run/mysql/mysql.sock:/var/run/mysqld/mysqld.sock
    #    - Debian/Ubuntu /var/run/mysqld:/var/run/mysqld
    #- /var/run/mysqld:/var/run/mysqld
    # private CA so egroupware can validate your certificate to talk to Collabora or Rocket.Chat
    # multiple certificates (eg. a chain) have to be single files in a directory, with one named private-ca.crt!
    #- /etc/egroupware-docker/private-ca.crt:/usr/local/share/ca-certificates/private-ca.crt:ro
    environment:
    # setting a default language for a new installation
    #- LANG=de
    # MariaDB/MySQL host to use: for host database (socket bind-mounted into container) use "localhost"
    #- EGW_DB_HOST=localhost
    # for internal db service you should to specify a root password here AND in db service
    # a database "egroupware" with a random password is created for you on installation (password is stored in header.inc.php in data directory)
    #- EGW_DB_ROOT=root
    #- EGW_DB_ROOT_PW=secret
    # alternativly you can specify an already existing database with full right by the given user!
    #- EGW_DB_NAME=egroupware
    #- EGW_DB_USER=egroupware
    #- EGW_DB_PASS=
    # other php.ini values to set in the container and their current defaults
    #- EGW_SESSION_TIMEOUT=14000
    - EGW_SESSION_TIMEOUT=36000
    #- EGW_APC_SHM_SIZE=128M
    #- EGW_MEMORY_LIMIT=128M
    #- EGW_MAX_EXECUTION_TIME=90
    # set the ip-address of your docker host AND your official DNS name so EGroupware
    # can access Rocket.Chat or Collabora without the need to go over your firewall
    #extra_hosts:
    #- "my.host.name:ip-address"


  # to use the database on the host, uncomment all the following settings to disable the internal db service
  #db:
  #  image: busybox
  #  entrypoint: /bin/true
  #  restart: "no"

  # push server using phpswoole
  #push:

  # nginx server of egroupware using /etc/egroupware-docker/egroupware-nginx.conf
  # You want to install your certificate on the webserver/Nginx running on the host proxying to this one
  #nginx:

  # automatic updates of all containers daily at 4am
  # see https://containrrr.github.io/watchtower for more information
  #watchtower:
    #environment:
    #- WATCHTOWER_CLEANUP=true # delete old image after update to not fill up the disk
    # for email notifications add your email and mail-server here
    #- WATCHTOWER_NOTIFICATIONS=email
    #- WATCHTOWER_NOTIFICATIONS_LEVEL=info # possible values: panic, fatal, error, warn, info or debug
    #- WATCHTOWER_NOTIFICATION_EMAIL_FROM=watchtower@my-domain.com
    #- WATCHTOWER_NOTIFICATION_EMAIL_TO=me@my-domain.com
    #- WATCHTOWER_NOTIFICATION_EMAIL_SERVER=mail.my-domain.com # if you give your MX here, you need no user/password
    #- WATCHTOWER_NOTIFICATION_EMAIL_SERVER_PORT=25
    #- WATCHTOWER_NOTIFICATION_EMAIL_SERVER_USER=watchtower@my-domain.com
    #- WATCHTOWER_NOTIFICATION_EMAIL_SERVER_PASSWORD=secret
    #command: --schedule "0 0 4 * * *"root@debian:/etc/egroupware-docker#

RalfBecker 2023-06-03 13:38:00 UTC #10

Ich fragte nach der Nachricht (kleines Kästchen) die unten rechts angezeigt wird. Ist die rot oder grün?

Wenn die grün ist tut alles und die Fehlermeldung kam nur, weil das swoolepush Verzeichnis noch nicht kopiert war.

Nach Deinem docker volume ls brauchst Du keinen Overwrite und hast auch keinen mit Debian 12.

Ralf

svenp1 2023-06-03 13:58:06 UTC #11

Oh sorry das ich auch wichtig.
Ich dachte weil oben alles grün ist… ok unten rechts ist es Rot.

RalfBecker 2023-06-03 20:01:29 UTC #12

Dh. der Push tut nicht!

Hast Du noch irgendwelche anderen Proxies oder Firewall mit Websecurity o.ä. im Einsatz?

Ralf

svenp1 2023-06-03 20:22:45 UTC #13

Ah das ist blöd.
Ich habe eine Fritzbox dort leite ich also route auf einen Mikrotik Router weiter und von dort Leite ich Port 80 und 443 zum Reverse Proxy weiter.
NAT macht nur die Fritzbox.

Ich kann morgen mal versuchen die Zertifikate auf der VM einzutragen und das Forwarding direkt nach Debian zu machen um den Reverse Proxy auszuschließen.
Bisher funktionierte alles aber mit Push etc. hatte ich schon auf der QNAP Probleme.

svenp1 2023-06-04 06:42:48 UTC #14

Moin Ralf,

um alles auszuschließen lasse ich nun mein DNS Server die egw Adresse mit der Privaten IP Adresse auflösen.
Das LE Zertifikat vom Reverse Proxy habe ich dann auf den Debian Server übertragen und dort in die nginx.conf integriert und 443 aktiviert.

Push zeigt mir nun Grün an.
Somit ist in mein Konstrukt Reverse Proxy an Debian etwas nicht ok.
Dann ist der Debian Server richtig konfiguriert und ich kann woanders weitersuchen.

svenp1 2023-06-04 10:31:58 UTC #15

Ok damit

image: “collabora/code:22.05.13.1.1”

funktioniert es.

Also ein Bug in Collabora.
Nun die Frage wo meldet man diesen Fehler?
Bei Github im Forum von Collabora?
Kommt der Fehler nur im Zusammenspiel mit Egw zum tragen?

StefanU 2023-06-04 19:25:54 UTC #16

Im Forum kann diskutiert werden.
Für Bugs:

Das kann dir wohl niemand bei deiner Konstruktion wirklich sagen.

Ich habe gerade auf meiner Standard-Installation COOL gegen CODE 22.05.14.3 (latest aktuell) getauscht. Kein Problem, funktioniert.

Wir melden bei Collabora Fehler in COOL, welche uns von unseren Kunden gemeldet werden. Dafür haben wir Zugriff auch das Collabora-interne Ticketsystem. Inhaltlich wie auch Probleme mit der Installation, Schnittstelle, Kundenwünsche, …
Das bedingt in der Regel aber Standardinstallationen, so dass man Probleme auch reproduzieren kann.
Es kann dann auch schon mal vorkommen, dass wir bei On-Premises-Kunden auf das System schauen und ein Problem lösen. Geht manchmal eben nicht ohne direkt drauf zu schauen.

Wir als Collabora-Partner bauen auch unsere eigenen Docker-Images und stellen diese nach grundlegenden Tests bereit (für automatische Updates/Hosting).
Wir bauen keine CODE-Images oder testen diese.

CODE-Anwender => https://collaboraonline.github.io/

CODE ist eine Entwickler-Version. Somit ist es auch immer möglich, dass damit Dinge mal nicht so funktionieren wie sie sollten. Schau mal in den Bug-Tracker:

Dann kannst du erahnen, was dich mit CODE erwartet.

Dich als EGroupware-CE-Anwender hindert niemand daran Lizenten für Collabora (bei uns) zu kaufen. Auch die Entwickler bei Collabora wollen ihre Familien ernähren (können)
Ich habe für meine Familie Lizenzen gekauft.

Stefan

svenp1 2023-06-04 19:40:37 UTC #17

@StefanU
Hat sich erledigt.
Der Docker Container brauchte einen Neustart.
Jetzt läuft es.

itwo 2023-06-21 12:32:04 UTC #18

Ich weiß OT aber es gibt inzwischen Debian 12 Pakete:
https://download.opensuse.org/repositories/server:/eGroupWare/Debian_12/

itwo 2023-06-28 17:08:20 UTC #19

Bei mir war das mit dem Debian 12 nicht der Fall, ich musste die /etc/apt/trusted.gpg nach /etc/apt/trusted.gpg.d/[…]eGroupWare.gpg kopieren.

Oder wie war das “[…] da der Schlüssel ja auch an der Stelle liegt, wo sie ihn erwarten.” gemeint?