Verbesserungsvorschlag für das Image

[jhamfler]

Docker erlaubt es soweit ich weiß, dass Installationsskripte / Startskripte und von der Hostmaschine aus nutzbare Verzeichnisse freigegeben werden können. Die genannten Änderungen in der Readme.md könnten dann automatisch getätigt werden, z.B. mit sed. Inspiration gibt es hier.

Ich würde mich über deine Meinung dazu freuen, da ich sehr interessiert an deinem Projekt bin und es gern im "Produktiveinsatz" nutzen würde.

[PinkTurnsBlue]

Ja, das geht. Können wir gerne zusammen machen. Bist du vielleicht auch
auf der Easterhegg ?

/Peter/

Am Donnerstag, den 10.03.2016, 11:44 -0800 schrieb Hamfler:

Docker erlaubt es soweit ich weiß, dass Installationsskripte /
Startskripte und von der Hostmaschine aus nutzbare Verzeichnisse
freigegeben werden können. Die genannten Änderungen in der Readme.md
könnten dann automatisch getätigt werden, z.B. mit sed. Inspiration
gibt es hier.

Ich würde mich über deine Meinung dazu freuen, da ich sehr
interessiert an deinem Projekt bin und es gern im "Produktiveinsatz"
nutzen würde.

—
Reply to this email directly or view it on GitHub.

[jhamfler]

Wunderbar. Nein ich war leider nicht dort, wie du sicherlich bemerkt hast.
Wenn ich kurz Zeit finde, werde ich mal einen Versuch starten.

[PinkTurnsBlue]

Wenn du aus der Gegend um Recklinghausen kommst kannst du uns ja gerne
mal beim Chaostreff besuchen kommen, dann setzen wir uns da zusammen

dran. Alternativ können wir uns auch zusammen telefonieren.

D1ffu$0r

Am Montag, den 11.04.2016, 10:35 -0700 schrieb Hamfler:

Wunderbar. Nein ich war leider nicht dort, wie du sicherlich bemerkt
hast.
Wenn ich kurz Zeit finde, werde ich mal einen Versuch starten.

—
You are receiving this because you commented.
Reply to this email directly or view it on GitHub

[jhamfler]

@skupfer willst du die Änderungen vom WE mergen?

[skupfer]

@jhamfler wie wir festgestellt haben, wird die ganze Sache nicht so einfach...

Auch das hier vorhandene Dockerfile ist nicht vollständig funktionsfähig und die "Fixes" sind keine. So startet "fuglu" keinen Service, sondern wenn dann "service fuglu start". Dies funktioniert jedoch nicht, da der Service nicht registriert werden kann während und nach des/dem build/s. Dasselbe trifft auf fail2ban zu.

EDIT: Dazu kommen noch weitere Baustellen. Ein erster Ansatz ist "CMD /sbin/init" während des builds und anschließend via exec in den Container zu gehen (Andernfalls steht der init-Prozess nicht an erster Stelle bzw. wird gar nicht erst gestartet). Aber auch dann sind weitere Skripte notwendig für das Registrieren und anschließend dass starten der Services. Wenn die Services via dienste_starten.sh gestartet werden, tauchen anschließend weitere Fehler auf, die untersucht und gelöst werden müssen.

[PinkTurnsBlue]

Probiere einfach mal "fuglu" statt "service fuglu start" !

Am Mittwoch, den 15.06.2016, 11:45 -0700 schrieb skupfer:

@jhamfler wie wir festgestellt haben, wird die ganze Sache nicht so
einfach...

Auch das hier vorhandene Dockerfile ist nicht vollständig
funktionsfähig und die "Fixes" sind keine. So startet "fuglu" keinen
Service, sondern wenn dann "service fuglu start". Dies funktioniert
jedoch nicht, da der Service nicht registriert werden kann während und
nach des/dem build/s. Dasselbe trifft auf fail2ban zu.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or mute the thread.

[jhamfler]

Ich glaube das Problem, das vorhanden ist, besteht nicht darin fuglu zu starten, sondern in folgendem:

• minimalinversives Ausführen von Mailcow
• Updatefunktionalität nicht beeinträchtigen durch das Ändern der Skripte

Daraus folgt:

• systemd / init in Docker ausführen können

Wenn man ein Skript nutzt, um die services manuell zu starten, so ist das Skript auch der Prozess mit der PID 1. D.h. das Skript kann andere Prozesse starten, jedoch muss es sich auch um Zombies u.Ä. kümmern. Bei SQL kann es dazu führen, dass der Arbeitsspeicher voll läuft, weil die Zombies nicht getötet werden. Der logische Schluss daraus ist also dem init-Prozess die PID 1 zu geben. Unter Debian 8 ist das systemd. Leider ist es schwierig systemd unter docker zum laufen zu kriegen. Die RedHat-Leute haben dafür zwar ein Paket bereit gestellt, was man nutzen kann um das unter Docker lauffähig zu machen, jedoch ist das unter Debian nicht der Fall, weswegen das so ein großes Problem ist.

Es gibt Ansätze ein FakeSystemd im Container zu nutzen, jedoch erfordert es noch etwas Zeit das genauer zu erkunden. Wir haben uns leider einer Weile nicht mehr damit beschäftigen können, weswegen wir auch noch kein funktionierendes Image haben, um jetzt hinreichend gute Informationen geben zu können.

[PinkTurnsBlue]

Alles richtig, aber wenn ich fuglu per Hand/per Script starte läuft
alles !

Am Mittwoch, den 15.06.2016, 13:15 -0700 schrieb Hamfler:

Ich glaube das Problem, das vorhanden ist, besteht nicht darin fuglu
zu starten, sondern in folgendem:

  * minimalinversives Ausführen von Mailcow
  * Updatefunktionalität nicht beeinträchtigen durch das Ändern
    der Skripte

Daraus folgt:

  * systemd / init in Docker ausführen können

Wenn man ein Skript nutzt, um die services manuell zu starten, so ist
das Skript auch der Prozess mit der PID 1. D.h. das Skript kann andere
Prozesse starten, jedoch muss es sich auch um Zombies u.Ä. kümmern.
Bei SQL kann es dazu führen, dass der Arbeitsspeicher voll läuft, weil
die Zombies nicht getötet werden. Der logische Schluss daraus ist also
dem init-Prozess die PID 1 zu geben. Unter Debian 8 ist das systemd.
Leider ist es schwierig systemd unter docker zum laufen zu kriegen.
Die RedHat-Leute haben dafür zwar ein Paket bereit gestellt, was man
nutzen kann um das unter Docker lauffähig zu machen, jedoch ist das
unter Debian nicht der Fall, weswegen das so ein großes Problem ist.

Es gibt Ansätze ein FakeSystemd im Container zu nutzen, jedoch
erfordert es noch etwas Zeit das genauer zu erkunden. Wir haben uns
leider einer Weile nicht mehr damit beschäftigen können, weswegen wir
auch noch kein funktionierendes Image haben, um jetzt hinreichend gute
Informationen geben zu können.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or mute the thread.

[skupfer]

Mein Kollege hat es ja bereits ausgeführt. So einfach ist das ganze nicht, wie wir bereits rausgefunden haben.

Fuglu bewirkt dennoch nichts. Im htop/top erscheint kein Prozess, das wäre der normale Fall. Ich hab es gestern extra noch mal alles probiert mit deinem Skript, weil bei uns dasselbe vorliegt ;-) Normalerweise würde auch durch "fuglu" ein Prozess gestartet, richtig, was aber den Nachteil bewirkt (zumindest auf einem normalen Server bzw restart des Containers), dass bei einem restart der Prozess nicht wieder hoch kommt.

Davon unabhängig, läuft auch fail2ban nicht, da eben auch* dieser Service nicht registriert werden kann. Die Ausführung dazu hat jhamfler gegeben.

EDIT: Wenn du auf gitlab unterwegs bist, kann ich dich gerne in das Projekt einladen.