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.
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.
Gerne. Dann ist der Wettbewerb also beendet
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…
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
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.
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
Hallo zusammen.
Ich pushe diesen Thread nochmal nach oben … eigentlich bin mal wieder bei moodle angelangt und frage mich nicht zum ersten Mal, ob wir das künftig dockerisieren oder „richtig installieren“.
In diesem Zusammenhang bin ich dann (auch nicht zum ersten Mal) wieder über die Frage gestolpert, welchen reverse proxy ich davor schalten sollte (da ja mehrere Container/VMs Port 80/443 anbieten werden).
Und so schließt sich der Kreis: Ist diese Anleitung die „offiziellen Lösung“? Einen dockerhost habe ich bereits aber bisher leider keinen Reverse Proxy. Gibt es einen „offiziellen Weg“?
Daher auch nochmal die Frage an die Geschwindigkeit: @Tobias schrieb irgendwo, dass man deutliche Einbußen bemerkt, wenn man alles über einen docker-nginx schickt. Könnt ihr das bestätigen?
eine weitere Option: du kannst auch HAProxy als Reverse Proxy in der OPNSense installieren. Einen offziellen Weg gibt es soweit ich weiß bisher (noch) nicht.
Ja Ist ja oft der Fall, wenn man ein mächtiges Werkzeug hat. Ist aber nicht unmöglich, wenn man sich damit auseinandersetzt und was ein Reverse Proxy eigentlich so alles macht bzw. machen kann.
Aber wenn das so ist, würde ich OPNSense ja auch die Let’s Encrypt Zertifikate direkt erneuern lassen?!? Klingt irgendwie einfacher, als wenn man das auf irgendeinem client in irgendeinem Subnetz macht, oder?!?
Wo würdest du denn den DHCP Server (zB für das WLAN) laufen lassen? Ist das nun schlau oder kontraproduktiv möglichst viele solcher Services auf der FW laufen lassen zu wollen
hatte dasselbe Problem mit dem OSP. Dehydrated funktioniert gerade nicht mehr weil letsencrypt die API geändert hat. Ich bin auf certbot umgestiegen, was sofort geklappt hat…man muss daran denken, die Pfade zu den Zertifikaten in der ngnix config zu ändern.
Ist ja oft der Fall, wenn man ein mächtiges Werkzeug hat. Ist aber nicht unmöglich, wenn man sich damit auseinandersetzt und was ein Reverse Proxy eigentlich so alles macht bzw. machen kann.
.
