Moinmoin,
ich hoffe erst mal das der Platz für das Thema recht ist, da ich keinerlei Unterteilung finden konnte.
Falls nicht möge man es bitte dort hin verklappen.
Da ich egroupware nach >>/dev/nul umgeleitet habe, benötige ich auch keine Hilfe zu dem so gelösten Problem! RIP
Man sollte gaaanz vielleicht mal grundsätzlich darüber nachdenken wie was warum Auswirkungen und Folgen … Das ist wie mit der Kritis Umsetzung bei Hochwasser. Labbern & Sabbern macht weder Sach- noch Rechtsfolgen Gegenstandslos. Was bleibt keine Krähe hackt … kölsche Knüngel, … ächz würg KOTZ
Analogon Gockel, Titter, Eiföhn, … alles Dinge die sinnvoll, nützlich, bequem, pröllprahl… sein können wie missbräuchlich bis gefährlich bis zum schnöden Apendix sein können oder schlicht ausgesperrt sind. Ich stelle immer wieder fest das geistige Kleingartenprogrammierer schlicht die Verfügbarkeit, Nutzung, STILLSCHWEIGEND annehmen bzw. voraussetzen … und deren Stati im Vorfeld nicht eruieren, verifizieren oder nur bekannt machen, quit pro quo eine Fehlerroutine vorsehen, wodurch sich so manch zeltsame guru meditation ergeben.
Rahmenbedingungen:
Hardware ist ein kleines itx Brettl mit AMD CPU - was aber keinerlei causa diesbezüglich machen sollte
Ubuntu 20.04 LTS 64-Bit
Netzwerk ist voll funktional intern, aber extern klar geregelt
GRUNDSÄTZLICHES mal vorweg:
Das ganze ist bzw. war reproduzierbar zum 3. mal jetzt der Fall.
Ich kann partout nicht verstehen wenn man schon diesen Dosenkrams macht, man es fern all seiner & anderer Regeln auch noch im Systemherzen = Paketmanager des Hosts implantiert, anstatt wie Usus im Dosenmanager Docker bzw. Docker-compose abhandelt. Das soll es ja explizit vom System trennen oder wozu dient Docker? ???. Belzebübche oder Kasperleklatsche mit Straussenfedern? Tschuldigung Egroupware ist bzw. war ein echt tolles Teil & Danke dafür ABER das ist definitiv ein gravierendes Sicherheitsdefizit bereits nur vom Ansatz her.
Als HADC Manager kann ich nicht verifizieren wie solch ein Installationsansatz bei einem Kritis / größerem Unternehmen durch die QS/QM Prüfung kommen kann. Ergo alles nur Spielkram für verliebte Nerds. Man darf es in dieser Form nicht als Container sondern MUSS es als VM ansehen und behandeln. da es den Host aussserhalb des Containers manipuliert. Da ist Docker nur ein zusätzlicher Ballast mit Fehleroption.
Darüber könnt ihr diskutieren, streiten, …Oma den Bauch rubbeln, aber das sind und bleiben Fakten.
Ich frage mich sogar ob überhaupt eine saubere?? Deinstallation möglich/vorgesehen/verifiziert ist, was in media res doch auch eher selten praktiziert und weitaus seltener verifiziert werden dürfte. Für eine Softwarefreigabe im operativen ist dies jedoch schlicht eine von unzähligen zwingenden Voraussetzungen für den ordnungsgemäßen Betrieb von IT gemäß Haftungsrichtlinien.
Das nun recht irrelevante:
Beim installieren scheitert immer etwas bei nginx, Volumes, symlinks … was in Folge zu einem unbrauchbaren apt/dpkg führt womit man das System nicht mal mehr von dem “Virus” befreien/updaten … kann, da es immer Fehler auswirft und abbricht. Ich habe auch beobachtet das nginx versucht sich auf Port 80 zu legen, was mit einem bereits laufenden Prozess scheppert. Elegant wird man natürlich weder gefragt, noch kann man wie in einem docker-compose mal eben die Definition ändern. Was stört es Egroupware wenn es alleine auf der Welt bzw. System ist. Docker ist, wie bereits angemerkt, ein missbrauchtes ultima irratio auf dem System.
Lösungen sind per
- Manu die Systemordner von egroup* zu befreien, da intelligenterweise installierte batches in Paketsystem nicht bekannt sind.
- Portainer alle Container, Images, Netze … zu löschen.
- oder secundo ultima irratio
Bedingt durch den Ansatzfehler mit apt/dpkg zu installieren sind beides keine sauberen Lösungen. Danach aber läuft dpkg wieder, wenn auch mit Beschwerdemeldungen bezüglich diverser Egroupware* Packerls, was man aber jetzt durch deinstallation selbiger lösen kann.
Ich, ehh, 'abbe ferrtich. Salve Trapper Toni
