So einen Server zu betreiben verursacht halt laufende Arbeit. Im besten Fall reicht es regelmäßig Updates einzuspielen:
root@master ~ # salt '*' pkg.list_upgrades
gw02.ffrn.de:
----------
tools-itter.ffrn.de:
----------
gw04.ffrn.de:
----------
meet.ffrn.de:
----------
resolver2.ffrn.de:
----------
itter.ffrn.de:
----------
gw03.ffrn.de:
----------
git.ffrn.de:
----------
v6upstream.ffrn.de:
----------
gw09.ffrn.de:
----------
gw06.ffrn.de:
----------
forum.ffrn.de:
----------
tickets.ffrn.de:
----------
tools-elsenz.ffrn.de:
----------
gw05.ffrn.de:
----------
elsenz.ffrn.de:
----------
resolver1.ffrn.de:
----------
map.ffrn.de:
----------
unifi.ffrn.de:
----------
altneckar.ffrn.de:
----------
stats.ffrn.de:
----------
gw08.ffrn.de:
----------
Das wäre zum Beispiel das Kommando mit welchem man sieht auf welchen Servern Updates verfügbar sind (aktuell keine 
). Und mit einem ähnlichen Kommando kann man diese dann auch installieren.
Aber das ist eben nicht immer der Fall. Zum Beispiel im Zuge des Fundes der Malware war es eben nötig die Jitsi Meet VM komplett neu aufzusetzen. Das ist nicht unendlich kompliziert, aber es hat mich am Montag dann eben doch etwa 30 bis 45 Minuten gekostet.
Ich habe nun die Konfiguration von Jitisi Meet in einen Salt State gepackt: https://github.com/Freifunk-Rhein-Neckar/salt/tree/master/jitsi-meet
Damit ist es nun möglich die entsprechenden Sachen mit einem Kommando in Sekunden zu erledigen. Was da nicht drin ist, ist die Installation von Jitsi Meet selbst, da dort während der Installation der Pfad zu den TLS Zertifikaten über eine „GUI“ abgefragt wird und ich nicht auf die schnelle herausfinden konnte wie man das am besten regelt.
Somit sollte es das nächste mal etwas schneller gehen.
Was ich damit sagen will: Es ist möglich einen solchen Jitsi Server zu betreiben, aber es kostet eben doch alles Zeit. Und wenn man dann sieht das bei Freifunk München sowieso ein Jitsi Meet Cluster betrieben wird was technisch wesentlich besser aufgestellt und insgesamt deutlich besser optimiert ist, dann fragt man sich doch etwas warum man sich selber die Arbeit machen soll. Anfangs war es schon so, das ich den Eindruck hatte, das unser Jitsi (aufgrund der geringeren Nutzerzahlen und der dadurch nicht so hohen Komplexität) eventuell sogar etwas besser funktionierte. Aber das ist nun schon einige Zeit her.
Ich habe noch keine genaue Meinung dazu wie lange wir nun den Jitsi Meet Server laufen lassen wollen (und erstmal läuft er nun jetzt ja wieder), aber ich bin mir für mich persönlich einfach über das Zeitaufwand-Nutzen Verhältnis unsicher. Hier mal die 10 Tage bevor ich es abgeschaltet hatte:
Und nun mal als Vergleich die Statistik aus München für den gleichen Zeitraum:
Da würden die paar mehr kaum auffallen.
Ich verstehe das es insgesamt eine blöde Situation ist und erstmal lasse ich meet.ffrn.de ja auch laufen, aber mir stellt sich eben doch sehr stark die Frage wie mein Aufwand in Verhältnis zu dem Nutzen für eine technisch schlechtere Lösung steht.
Wenn jetzt zum Beispiel die Nutzung von meet.ffrn.de ansteigen sollte (eher unwahrscheinlich, aber eben doch möglich), was wollen wir dann machen? Nach oben skalieren ist nicht wirklich möglich da uns Zeit und Serverressourcen fehlen würden. Was ist wenn es einen DDoS Angriff gibt? Wir können nicht wirklich gegensteuern.
Und da Freifunk Müchnen mit meet.ffmuc.net eben eine skalierbare Lösung hat welche ideologisch nahe bei dem liegt was mit meet.ffrn.de erreicht werden sollte fehlt mir eben etwas die Rechtfertigung selber Zeit in dieses Projekt zu investieren.
Wenn es läuft gut, kann es ja auch erstmal auch weiter tun, aber schon alleine ab und zu zu schauen ob es auch wirklich noch läuft braucht eben Zeit, Zeit die ich auch in andere Sachen investieren könnte.
)
Vielen Dank
