Hi Frank,
ich hoffe, dass es das ist. Wenn ich vor KA noch zeit habe mir das anzuschauen, kann ich dir vllt. auch folgen, wenn du drüber redest. Was ich sagen will: Ich hoffe, dass es einfacher ist, als das was ich bisher zusammengegurkt habe.
V.a. dass du auch ein RZ im Sinn hast gefällt mir, vielleicht kannst du das der Stadt KA mal vorstellen (inkl. deren Handlanger-Firma).
Mal sehn, wer die Limesurvey-App zuerst gebaut hat: @Michael oder ich. (Du bist nicht im Rennen!)
Vg, tobias
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 
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 
Hat @Michael einen github Account?
VG
Frank
Hi. Wusste bisher nicht, dass es da ein Wettrennen gibt 
… 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 Docker 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.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.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.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 
VG
Frank
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
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
Hallo,
Ja, allerdings finde ich den Port 80 erst mal nicht schlimm.
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
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:
Falls beim Setup die Mailserver-Option gesetzt wurde, werden in einem zweiten Schritt
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
Hallo,
super, danke für die Infos. Ich denk mal nach, wie wir das dann am geschicktesten hinbekommen und schick nen Pull Request 
VG
Frank
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 
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:
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
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?
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