Docker KISS + linuxmuster-mrbs

Hai,

Ich glaube schon. Also ainfacher als traefik ist es sicherlich, ob man den Reverse Proxy jetzt auf den Docker Host hat oder mit jwilder/nginx plus letsencrypt-Helper in einem Container kann man sicher diskutieren. Das hat vor allem Auswirkungen, wenn die Reverse-Proxy Konfiguration komplizierter ist, z.B. wenn man Apps wie Mattermost verwendet, die Websockets ist dergleichen verwenden.

Habe verstanden :yum:

Bei der Erstellung des Images könnt ihr ja durchaus mal in den Dockerfiles der OSP und MRBS Images spicken, die sind ja auch beide PHP. Wichtig ist vor allem, dran zu denken, dass man die LDAP Erweiterung für PHP ins Image aufnimmt, die kommt bei den PHP Basisimages nicht mit.

Wenn ihr euch beim docker hub Registriert, kann ich aus linuxmuster eine Organisation machen, dann könnt ihr die Continerimages dort zur verfügung stellen. linuxmuster/limesurvey :slight_smile:

Hat @Michael einen github Account?

VG

Frank

Hi. Wusste bisher nicht, dass es da ein Wettrennen gibt :slight_smile: … aber auf dockerhub gibt es ja bereits limesurvey-container. Hattest du nicht in einem deiner Videos auch gezeigt, dass man einen bestehenden Container nutzen und abwandeln kann?
Schönen Gruß,
Michael

Hallo,

ja, schau dir mal meine Dockerfiles an, ich nehme ja auch nur ein php7.3.3 Image und passe das an. Genau so kannst du natürlich da hinschreiben From limesurvey/latest und das dann anpassen. Evtl. Kommt man auch ohne selbst gemachtes Image hin, so wie beim Mailserver und kann sich auf dir App Komponente beschränken.

Und man muss genau hischauen, was das für Images sinf und ob und von wem die gepflegt werden. Für MRBS gi ts auch ein paar auf dem Hub, aber mein offizielles und kein ordentlich gepflegtes.

Und für die App musst du das ja dann noch mit einem Datenbank Container zusammenbündeln, da reicht MRBS alleine nicht.

VG

Frank

Hi Frank,

Max und ich haben das jetzt mal nicht für limesurvey, sondern für was viel einfacheres durchgespielt: apt-cacher-ng.
Der feine Unterschied ist, dass der apt-cacher-ng nicht auf 80/443 normalerweise läuft, also auch gar keine nginx-config braucht. Hab mich für den einfach Weg entschieden und die default-port 3142 durch den dockerhost durchreiche.
Alleine fehlt uns, dass man die ufw wohl noch in das deploy-skript stecken muss.

Hier also die zwei Repos, die man gerne in linuxmuster-ext-docker übernehmen (forken?) kann:


und das Image hab ich auch hochgeladen, was man natürlich dann für hub.docker.com/linuxmuster/apt-cacher-ng nochmal machen muss.

https://hub.docker.com/r/hgkvplan/apt-cacher-ng

Mit “man” meine ich entweder dich, @ironiemix, oder jemand aus deinem Infra-Team?

VG, Tobias

Hallo,

das mache ich gerne.

Ich habe mir noch ein paar Gedanken zu einem etwas einheitlicheren Gerüst für Dockerhost und Apps gemacht, das folgende Bildchen zeigt das:

Im Wesentlichen sind das zwei ini-Dateien, die im Dockerhost vorhanden sein müssen:

  • server.ini Enthält alle Infos zum linuxmuster.net Server. Besonders auch die Version des Servers - damit kann man die Migration gestalten.
  • docker.ini damit kann man z.B. für den ganzen Dockerhost eine Rolle definieren, ob der z.B. selbst Revers Proxy Dienste machen soll oder ob dieser Docker Host generell “extern” angsteuert wird.
  • Dann würde ich noch Skripte mitliefern, die App-Erstellern bei der Konfiguration nutzen können, so als eine Art API. Beispiel: check_dns service.host.tld könnte überprüfen, ob es einen DNS Eintrag für service.host.tld gibt, der auf den aktuellen Dockerhost zeigt. Im Setup Skript der App könnte man das dann benutzen, um das zu überprüfen, ebenso z.B. für das Zertifikat.

Die Apps sollten zwei Bedingungen erfüllen:

  • App spezifische Konfiguration sollte in app.ini im Verzeichnis der App liegen. Die Datei wird wenn nötig von der setup-Routine der App (s.u.) ausgewertet und kann auch fehlen.
  • Jede App sollte ein Skript setup haben, das in mindestens zwei Varianten funktionieren sollte: setup first zur Erstkonfiguration und setup update zum Update der App. Wenns gut läuft, kann das Skript beides mal dasselbe tun, wenn nötig kann man aber eben zwischen Erstkonfiguration und Update differenzieren. Außerdem sind weitere Funktionen denkbar wie setup migrate, um z.B. die MRBS DB in die Docker App zu migrieren.

Lasst mich mal wissen, was ihr dazu so denkt. CC: @thomas ich würde den mailserver/Hauptdockerhost auch in diese Richtung vereinheitlichen wollen, um die Dokumetation zu vereinfachen - deine Einschätzung ist also wichtig, was die Konfiguration im Zuge des Serversetups angeht - welche Probleme siehst du diesbezüglich?

VG

Frank

Hi,
ich finds gut. sowohl die pseudo-API als auch einheitliche Ablage.

Ich gebe zu Bedenken, dass momentan jeder Beta-tester mindestens einmal über das Setup stolpert, aus verschiedensten Gründen - und dann muss man von vorne anfangen.
Ist nicht weiter schlimm, aber an der Stelle könnte man auch sagen, dass bei der Erstkonfiguration zumindest der Docker-host auch außen vor bleiben könnte. Dann hätten mehr leute sowohl die Beta als auch die Final schneller in einem Grundsystem am Laufen.

Für den Dockerhost muss man eh auf die wahrscheinlich auf die Konsole, ich sehe also weniger Fehlerquellen, wenn man sagt, den Dockerhost inkl. mail und allen erweiterungen, die man haben möchte installiert man nachgelagert in sein System - a.k.a. ohne SELMA.

Evtl. findet ihr das ein schritt zurück. Daher nur m.M.
vG, Tobias

Hallo,

man muss natürlich unterscheiden zwischen “DEM” Dockerhost und allen Dockerhosts.

Letztlich ist es egal, es sollte mittelfristig eben nur so sein, dass “DER” Dockerhost genauso aussieht, wie alle anderen Dockerhosts und der Mailservercontainer sich eben auch an die dargestellten Regeln hält. Dann kann man eben auch auf “DEM” Dockerhost, die anderen Docker Apps istallieren oder den Mailcontainer selbst auf einem anderen Dockerhost.
Wer das Setup-Sktipt dann wann woher aufruft ist letztlich ja egal, das kann durchaus auch beim Erstsetup des Servers geschehen.

Ich finde auch, das das Erstsetup hier gesplittet werden könnte, aber ich finde ja auch die Bemühungen, die (ein einziges Mal durchzuführende) Installation vollständig in der Selma abzubilden komplette Zweitverschwendung, das heißt ich bin da eher nicht der Maßstab :wink:

VG

Frank

:slight_smile:
Also wäre doch ein Zweitnutzung gut: wenn man linuxmuster-setup-ext mehrfach aufrufen könnte, weil es
a.) mal DEN dockerhost (in grün) konfiguriert oder dekommisioniert
b.) mal einen anderen dockerhost bereitstellt
c.) eine ankreuzliste von diensten bereitstellt, die man haben können wollte: Mail, MRBS, OSP, nginx-RP

Dann kann sich die Abteilung SELMA auch um eine GUI bemühen, wenn schick wichtig ist.
VG, Tobias

1 Like

nochmal hi: an der stelle nochmal verlinkt:

falls wir das tls-alpn-01 benutzen wollen, dann braucht man kein port 80, nur noch 443? vermute ich jedenfalls.

VG, Tobias

1 Like

Hallo,

Ja, allerdings finde ich den Port 80 erst mal nicht schlimm.

  • Dehydrated nimmt den nur für den allerersten Request
  • Anschließend wird http sowieso via 301 (Moved Permanently) auf https geleitet.

Interessanter sind die DNS Validierungen, weil du da WildCard Zertifikate bekommen kannst. Allerding erfordern die DNS Provider spezifische Skripte und Schnittstellen, da kann man also wahrscheinlich auch nur eine Auswahl anbieten. Damit hättest du aber mit einem Schlag “alle” Docker Zertifikate :wink:

VG

Frank

oh, noch ein Argument gegen die nginx-le-companion Variante:

Belwue hat mir, vermutlich aus missverständnis, eine (nicht benutzte) domäne auf eine andere IP gelenkt.

ich habe die Domäne aber doch in Benutzung, nämlich als CNAME für ein anderes LE-Zertifikat.
Bis ich herausgefunden habe, wo das Problem lag … ich habe es gar nicht gesehen, erst als das alte ZErt auslief (übrigens während der Tagung).
Es muss also für den nginx-le-companion noch eine art email-monitoring oder ein moni-pi-script her, das die Geschichte überprüft.
Das intern verwendete python-script des ACME-clients steigt übrigens mit einer Fehlermeldung aus, das ist auch nicht fein.

ich musste meine kompletten apps runter und wieder hochfahren. Jetzt hat es immerhin wieder funktioniert.
Vg, Tobias

Interessant, in der Tat.

Ein Haken: wenn irgendwas schief geht beim wildcard, was propagiert wird, hat man gleich alle Dienste außer Gefecht gesetzt…
VG, Tobias

Hi Frank,

das Serversetup macht folgendes:

  • initiiert den ssh-Link zum Dockerhost,
  • kopiert die selbstsignierten Server-Root- und Dockerhost-Zertifikate nach /etclinuxmuster/ssl und
  • führt danach linuxmuster-prepare aus, was den Domainname und das root-Passwort setzt.
  • Reboot.

Falls beim Setup die Mailserver-Option gesetzt wurde, werden in einem zweiten Schritt

  • die setup.ini-Datei und ein Mailserver-Setup-Skript nach /tmp und
  • die Mailserver-Zertifikate nach /etclinuxmuster/ssl kopiert und
  • schließlich das Mailserver-Setupskript ausgeführt.

Das alles kann mit wenig Aufwand angepasst werden, seh ich also unkritisch. Die Serverversion müsste ich halt noch zusätzlich in die setup.ini eintragen.

VG, Thomas

2 Like

Hallo,

super, danke für die Infos. Ich denk mal nach, wie wir das dann am geschicktesten hinbekommen und schick nen Pull Request :wink:

VG

Frank

1 Like

Hi @ironiemix, hi @Michael,

ich muss für die kommende Umfrage sowieso limesurvey neu aufsetzen. D.h. wenn ich keine weiteren Instruktionen kriege, setze ich ähnlich wie linuxmuster-mrbs und linuxmuster-apt-cacher-ng dann limesurvey um, zumindest probiere ich es in den Osterferien.

Vg, Tobias

Gerne. Dann ist der Wettbewerb also beendet :slight_smile:
Interessant wäre noch, wie das bei limesurvey mit den Upgrades läuft. Ich hatte erst heute ein Sicherheitsupdate im Backend. Hab’s bisher nicht installiert…

Schöne Grüße,
Michael

Sagen wir mal so: könnten wir statt Wettbewerb eine kooperation machen?
Das upgrade ist nämlich wirklich der problematischste Part:
der erfordert nämlich, dass man (du/ich/wer sich verantwortlich fühlt) manuell an die Sache ran geht, nämlich:

  • mail von limesurvey-stable bekommen, dass es ein upgrade gibt
  • upgrade lokal - testen obs funktioniert
  • release notes lesen, z.B. ob man auch bei aktiven Umfrage upgraden kann
  • dockerimage build, push

Dann muss der User (sysadmin) auf seinem dockerhost selbständig entscheiden, ob er ein “docker pull” macht und damit das neue limesurvey kriegt.

Das in Kürze. Im Detail liegt aber die Würze.
Wenn der docker-build nämlich mal steht, dann sollte es upgrades geben, die die community testet und bereitstellt. Wir könnten uns diese Arbeit doch teilen?
Die release notes deuten darauf hin, dass es monatlich upgrades gibt mit security fixes …
https://www.limesurvey.org/stable-release/file/2546-limesurvey3171%20190408zip?tmpl=component

VG, Tobias

3 Beiträge wurden in ein neues Thema verschoben: Linuxmuster-survey

Hi @ironiemix,

ich stehe grade auf dem Schlauch. Schreiben hilft vielleicht:
Ich habe einen Lehrerserver (samba-share im Lehrernetz).

Ergibt so ein Service Sinn zu dockerisieren?

  • Netzwerktechnik: der Lehrerserver (manche nehmen ein NAS) ist im eigenen Lehrernetz VLAN-technisch getrennt. Der Dockerhost müsste also auch ein Interface in dem VLAN haben und damit verbinden, das geht vermutlich: https://docs.docker.com/network/macvlan/
  • Netzwerk-sicherheit: Vermutlich macht es wenig Sinn, wenn der Dockerhost gleichzeitig Interfaces/Container in einer DMZ hat, ebenso wenn er gleichzeitig Interfaces/container in GRÜN hat.
  • Storage: eigentlich kein Problem, volumes auf dem dockerhost ablegen. Sicherheitstechnisch ist das Problem wie oben: wenn ein Angreifer den dockerhost aus dem GRÜN/DMZ Netzwerk übernimmt, dann hätte er auch Zugriff auf die Daten…

Fazit: wenn man sicherheitstechnisch keine Bedenken hat, würde man so einen Lehrerserver-Container noch am ehesten auf den internen Dockerhost (z.B. mit mailserver) legen. Wenn man Bedenken hat, dann sollte der Lehrerserver gleich in einer eigenen VM bleiben.

Fazit 2: Ich sehe den Nutzen eines linuxmuster-ext-teacheronly Containers als ziemlich begrenzt, weil auch momentan vermutlich nicht viele so etwas haben und es einiges an zusätzlichem Wissen benötigt (client-einbindung, VLAN-konfiguration, …) ist das nichts für die breite Masse.

VG, Tobias

Hi Tobias. Warum willst du das NAS dockerisieren? Wir haben hier seit vielen Jahren ein virtualisiertes NAS4Free (heißt jetzt “XigmaNAS”) im Lehrernetz laufen. Das hat noch nie Ärger gemacht. Daher: Wo ist der Mehrwert, wenn du das in einen docker-Container packst?
Schöne Grüße,
Michael