Installation via github ohne Docker (20.1) zur Installations-Automatisierung Puppet

[LaB]

Hallo,
zunächst einmal vielen Dank für die egroupware, die wir seit Jahren für die tägliche Arbeit und die Terminplanung im Team verwenden.

Nun soll eine ältere Version der egroupware auf den neusten Stand gebracht werden und ich war - soweit ich das bei Open Source Software sein kann - etwas enttäuscht, dass auf Docker gesetzt wird. Ich denke auch bei kostenloser Open Source Software darf man ein wenig Enttäuschung äußern.

Ich komme aus dem Hosting Bereich und weiß daher durchaus etwas mit Containerisierung anzufangen. Allerdings gibt es diverse Szenarios, die eben keine Containerisierung zulassen, bzw. die zu einer vollständigen Anpassung des Betriebskonzepts führen müssten. Soweit will man natürlich zum Upgrade einer Anwendung erstmal nicht gehen, auch wenn das sicherlich langfristig sinnvoll ist.

In unserem Fall wird egroupware in einem klassischen vServer betrieben, damit lässt sich also kein Docker realisieren. Nun stellt sich für uns nicht die Möglichkeit, das System “spontan” in eine KVM Instanz oder auf “Blech” zu ziehen, um dort dann mit Docker rangehen zu können. Daher habe ich die manuelle Installation via github nach https://github.com/EGroupware/egroupware#installing-egroupware-development-version gewagt.

1. Ich habe eine manuelle Installation via git Repo installing-egroupware-development-version gewagt (Debian 10) und wollte verifizieren, ob folgende ergänzenden Schritte so sinnvoll sind, insbesondere da die Installation bis zu einer benutzbaren Anwendung via Puppet automatisiert werden soll. Daher möchte man also nicht noch die setup/ Seite aufrufen und die Installation finalisieren, das wurde ja bis zu 17.x freundlicherweise vom post-install Script gemacht. Dazu haben ich mir nun “rausgefummelt” und nach dem install-cli.php Schritt ausgeführt:

   /usr/share/egroupware/doc/rpm-build/post_install.php
   –config_user “admin”
   –config_passwd “”
   –admin_user “admin”
   –admin_passwd “”
   –lang “en”
   –db_type mysqli
   –db_root “root”
   –db_root_pw “” 2>&1

Kann man sich auf das post_install.php auch in zukünftigen Versionen verlassen oder wird das zunehmen verwaisen? Gibt es ansonsten andere Wege, die es sich lohnt anzuschauen?

Noch eine kleine Empfehlung am Rande: PHP Erweiterung apcu sollte in der Installationsprüfung aufgenommen werden, das Fehlen führte nämlich zur Dauer-Reload Schleife, wie hier schon in einigen Beiträgen besprochen.

2. Gibt es irgendwelche Bestrebungen, in Zukunft auch wieder eine Standalone Version anzubieten oder hat dieser Pfad mit dem egroupware-docker Paket endgültig sein Ende gefunden?

Ich danke schon jetzt und Grüße
LaB

[RalfBecker]

Kann man sich auf das post_install.php auch in zukünftigen Versionen verlassen oder wird das zunehmen verwaisen? Gibt es ansonsten andere Wege, die es sich lohnt anzuschauen?

Das benutzt der Container auch, gibt keine Pläne daran was zu ändern.

Unterstützung für nicht-Docker Installationen ist schon ehr ein Thema, da das immer aufwendiger wird.

Bei Deiner reiner Git Installation fehlt Dir jetzt zum Beispiel der Push Server, den man so einfach nur als Container bekommt, vom Zusammenspiel der Komponenten mal ganz abgesehen.

Gibt es irgendwelche Bestrebungen, in Zukunft auch wieder eine Standalone Version anzubieten oder hat dieser Pfad mit dem egroupware-docker Paket endgültig sein Ende gefunden?

Du meinst ein klassische Paket für alle unterstützten Linux Distributionen?

Nein, sicher nicht mehr.

Ralf

[StefanU]

Hallo Lars.

etwas enttäuscht, dass auf Docker gesetzt wird. Ich denke auch bei kostenloser Open Source Software darf man ein wenig Enttäuschung äußern.

Natürlich darfst du enttäuscht sein und das zu Ausdruck bringen. So lange es sachlich bleibt immer gerne. Eine Community/OSS lebt auch von verschiedenen Meinungen und (sachlicher) Kritik. Da habe ich bei deinem Beitrag natürlich nichts zu meckern

Bezüglich Docker möchte ich grundsätzlich an der Stelle nur sagen:
Eine Weiterentwicklung einer Groupware-Suite wie EGroupware mit Funktionen wie Online Office, Chat, Remote-Desktop, … kann technisch nur mit erträglichen Aufwand und für den Otto-Normal-Installateur auf Basis von Docker erfolgen. Bitte schaue dir dazu die funktionelle Entwicklung der letzten Jahre an.

Docker ist aktuell Standard um Software-Systeme zu distributieren. Siehe auch z. B. Univention Server.
Aber dass wisst ihr ja auch selber…

Es ist nicht realisierbar, alle die Funktionen nativ auf einem System laufen zu lassen. Und das für verschiedenste PHP, Webserver, Datenbanken. Mit Docker liefern wir eine definierte, ständig aktuelle Umgebung auf deren Basis wir die Anwendung entwickeln.
An der Stelle können wir nicht noch mehr leisten als andere. Von Google bis zu OX (und viele andere) arbeiten alle mit definierten Umgebungen und verlassen sich in der Entwicklung darauf. Wie sollen wir da noch einen drauf packen? In der Entwicklung und im Support…
Und bedenke bitte: Wir würden eine klassische Paket-Installation ohne Docker auch bei keinem Kunden oder bei uns im RZ/Hosting/Saas benötigen. Wir leisten jetzt schon viel (mehr als andere) an die Community.

Ich habe seinerzeit zum Release der 19.1 dazu auch einen Artikel verfasst:

🇩🇪 Docker (in EGroupware 19.1)?

Ist im Prinzip noch aktuell. Nur dass mittlerweile noch der DB-Container (bei Neuinstallationen), der Push-Container und der Guacamole-Container dazu gekommen sind.

---

Wir Ralf schon angemerkt hat, würde dir bei einer nicht Docker-Installation z. B. der Push-Server fehlen. Funktioniert auch ohne, ist aber ein wesentlicher Teil unserer Entwicklung in Richtung Benutzerfreundlichkeit (Verhalten wie Fat-Client).

Ich komme aus dem Hosting Bereich und weiß daher durchaus etwas mit Containerisierung anzufangen.

Dies und dein Thema “…zur Installations-Automatisierung Puppet” lässt mich darauf schließen, dass ihr euren Kunden EGroupware anbieten wollt?

---

In unserem Fall wird egroupware in einem klassischen vServer betrieben, damit lässt sich also kein Docker realisieren.

Ich bin mir sicher, dass der ein oder andere das bei seinem vServer-Vermieter seines Vertrauens so betriebt. Mit Docker. Die müssen die nested-Virtualisierung nur erlauben.
Ich habe das hier gerade noch einmal unter Proxmox/LXC mit eingeschaltetem nesting probiert. Läuft klaglos.
Das Thema Sicherheit lasse ich jetzt mal außen vor. Ich kann das nicht abschließend beurteilen.
Ob das für euch ein gangbarer Weg (vielleicht auch nur) für EGroupware ist musst du schauen.

---

Neben der Git-Installation bleibt dir natürlich auch noch die altehrwürdige Archiv-Installation:

Releases · EGroupware/egroupware

Ebenso kannst du die Container nehmen und bei euch selbst zusammen bauen. Ihr habt ja Expertise dahin gehend.

---

Ich bitte dich, künftig für jedes Problem/ jede Frage ein eigenen Thema zu erstellen. Nur so können wir/andere ein Thema zu Ende bringe, auseinanderhalten, abschließen, …

Stefan

[LaB]

Hallo,

danke für die (wie immer) schnellen und ausführlichen Antworten, auch daran sieht man auf jeden Fall immer wieder, das die Community massiv unterstützt wird, ganz großes Danke dafür!

Nein, wir haben nicht groupware Kunden anzubieten. Da aber Container nicht der einzige Weg zur Standardisierung von Entwicklungs-/Test-/Produktivumgebungen sind, realisieren wir das mit Hilfe von Puppet und erzeugen genau so definierte und ständig aktuelle Umgebungen. Am Ende ist es dann auch nur eine Art von (Einzel-)Container, wenn auch in vServer Form.

Beim Bau des Docker Containers wird ja auch nur mit Wasser gekocht… unser Wasser heißt eben Puppet und unser “Container” nennt sich vServer.

In Sachen Sicherheit bin ich bei Docker etwas hinterher. Aber zu der Zeit, als ich einen aktuelleren Stand hatte, war das eher nicht der Grund Docker warum man Docker einsetzen wollte. Aber da möchte ich mich nicht zu weit aus dem Fenster hängen.

Das Nesting schaue ich mir mal an.

Danke und Grüße

Lars

[StefanU]

In Sachen Sicherheit bin ich bei Docker etwas hinterher.

Das Nesting schaue ich mir mal an.

Der Punkt Sicherheit bezog sich auf eingeschaltetes Nesting in z. B. LXC. Da gab es Diskussionen…

In Proxmox sieht das so aus:

Hier findet LXC Verwendung.

Stefan