lbehm:
Skripte mussten mehrere Tage lang geskriptet werden ⇒ Backup-Scripts einheitlich gestalten
Serverinfrastruktur ist heterogen; einheitliche Systeme sind gewünscht
Skript-Programmiersprachen sind unterschiedlich (Bash, Python, …)
Umstellung/Neuumsetzung wird sehr viel Aufwand benötigen
Plattenverschlüsselung muss umgesetzt werden, ordentlich!
Server-Migration von Anwendungen notwendig um Verfügbarkeit von Anwendungen zu gewährleisten
Netzwerk-Konfiguration über unterschiedliche Network-Manager
ToDos erfordern sehr viel Aufwand bei Abarbeitung
ananke: Anforderungen erfassen
lbehm: Dokumentation der Komponenten sind bereits im Wiki hinterlegt
lbehm: Grund-Installation und -Einrichtung oder das komplette System? Anwendungen in Container? Wie kann sinnvoll mit Ansible gearbeitet werden? Was sind Einsatzszenarien?
Welche Voraussetzungen müssen gegeben sein? Muss das System gesäubert sein (Ursprungszustand)?, nur Apps wie nginx runter und Ansible drauf?
qbi: Ansible läuft einmal durch, erstellt Configs; falls diese schon da sind ⇒ soll nichts machen
lbehm: Klärung: clean /etc muss da sein?
lbehm: Infrastructure as Code mit Debian auf VM? oder ggf. Richtung Container?
15 Jahre gleichartige Arbeit ⇒ soll das so weitergehen? Oder denken wir uns die Welt neu aus?
moep: *spricht sich für Debian aus*; aber manchmal fehlen Pakete
lbehm: Debian hat im Verein beste Voraussetzungen ⇒ viele Vereinsmitglieder werden sich damit auskennen, sinnvoll, Probleme können auch an andere Mitglieder abgegeben werden
Packet-Verfügbarkeits-Problematik in den letzten Jahren angenehmer geworden; notfalls selber Hand anlegen und bauen oder Docker (Matrix, Discourse)
Hat noch offene Fragestellungen, wie z.B. Scripting-Überlegungen: Interoperabilität zwischen durch Ansible erstellten nginx-Configs und apt-Update-Prozessen
Hoffnung: Nicht das Rad neu erfinden ⇒ andere haben die Probleme sicher schon gelöst.
Weitere Zielstellung: blue/green-Deployment-Upgrade-Prozess für Docker-Compose-Container (z.B. Discourse / Ruby-Monstrositäten die 15 min boot-time haben?)
Derzeit gibt es folgende VMs/Server:
Unterscheidung in Hardware und Anwendungsbereich.
Mehr Konfigurationsaufwand aber auch Vorteil.
qbi:
klar machen was gemacht werden soll
⇒ Gemeinschaftsprojekt schaffen?
nginx Installation ⇒ Einschätzung
Man kann bei einer Umstellung Schritt für Schritt vorgehen, anstelle gleich alles neu zu machen. ⇒ Sicherstellung das alles nach Plan abläuft.
Configs kann man aus Templates zusammenbauen.
Was liegt auf dem Server? Nginx-Version? Änderungen?
Ansible ermöglicht Konfiguration nach Wunsch; Wie als würde man sich manuell einloggen.
Beobachtung: Stück für Stück ist alles gewachsen, immer wieder Probleme, gut wenn man sich mal in Ruhe da hinsetzt.
Anwendungsfall lässt sich gut abbilden.
IP-Adresse ändern, durchlaufen lassen
relativ einfach
Reverse Proxys unterschiedlich konfiguriert?
Es empfiehlt sich erst darüber nachzudenken. Es gibt verschiedene Möglichkeiten damit umzugehen ⇒ komplett ausschalten?
Admintag öfters machen!
Wahrscheinlichkeit bei 70% beim Admintag dabei sein
lbehm:
nginx template für virtual sites vorkonfiguriert ⇒ was kann man da vereinheitlichen? alle unterschiedlich?
einheitlicher Aufbau sollte möglich sein
nur auf 1 Server Mailserver notwendig (aktuell auf allen..)
Anwendung für einen Server, mit wenig Aufwand Skripte auf anderen Server hochfahren „copy paste config“
Fragen was Edge-Cases betrifft: einheitlicher Server, dann Debian update, config ⇒ wie kann man das ⇒ möglichst maintenance-arm gestalten?
andere haben ähnliche Probleme, so was muss es bereits geben
nicht alles sofort klären, zunächst Termin vereinbaren: Samstag/Sonntag (Admintag)
Abstimmung nicht nötig, unspezifischen Termin: 15./16. April 2023
alle mit Infrastruktur-Erfahrung sind eingeladen
ananke: Wer kann beim Admintag dabei sein?
qbi: jeder der Interesse an Infrastruktur hat
moep:
geht schon ein bisschen zu weit..
Anfangen: was wird benötigt? was soll getan werden?
statisch? automatisieren (später)?
BASE bauen: „So geht es los..“
„System vereinheitlichen“ stimme ich zu
möglichst nah an Debian halten ⇒ falls neuere Version (z.B. Entwickler) ⇒ muss dann halt sein, Feature
1 Stand testen, der auf jeden Server identisch ist
bernd:
es ist eine gewachsene Struktur
das liegt vor allem daran, dass alles zu verschiedenen Zeiten von unterschiedlichen Leuten gemacht wurde.
dann sollten wir uns wohl vor allem erst mal klar werden, was auf welchem Server laufen soll.
nochmal … bevor wir irgendwas mit Ansible machen, sollten wir uns einen genauen plan machen, was auf welchem Server laufen soll.
⇒ Admintreffen in Vereinsräumen veranstalten.
qbi: Jemand hat in Matrixräumen dazu angefragt. Angeblich würde es inzwischen funktionierende Bridge geben, damit XMPP-Nutzer miteingebunden werden können.
⇒ Serverlandschaft würde diverser werden
Anfrage: ist das machbar? Interesse ist da, das wir das machen
moep: Matterbridge?
bernd: kann ich dann noch Spammer vom XMPP aus Matrix heraus kicken?
lbehm:
War bei Plenum im CCCHH (CCC Hamburg)
„Verwaltung“ hatte Übersicht am Anfang zu Finanzen und Mitgliedszahlen gezeigt (kurze tabellarische Aufstellung, monatlich aktualisiert)
Scheinbar gab es da zu solchen Fragen Interesse
großer Vereins-Raum vor Ort; Plenum lief als Hybridveranstaltungen im Raum highend-Mikrofon ⇒ nur einer redet, sehr gute Audioqualität
Eventuell kann man sich da inspirieren lassen
bernd:
Früher haben wir uns vom Project Euler eine Aufgabe rausgesucht und dann hat jeder versucht, dass zu implementieren.
Hinterher haben wir die Ergebnisse verglichen und uns über die verschiedenen Lösungen ausgetauscht.
Das war durchaus lehrreich.
War eine ganze Weile immer Dienstags.
Ein paar davon dürften sogar noch im Wiki dokumentiert sein.
Ein borg-Vortrag wäre auch nett.
Philipp hat zwar schon mal einen gemacht, aber doppelt hält besser.
lbehm:
Dienstag Chaostreff
Datum beibehalten, aber ein Thema geben
Themenbeispiel: „experimentelle Programmiersprachen“
Tobi:
Startzeit z.B. 18:30 definieren
bernd:
klar warum nicht. habe ich nichts dagegen.
und ich denke, wenn wir das vorher öffentlich machen, kommt sicher auch der eine oder andere Interessent. bis der letzte eingeschlafen ist :)
lbehm:
Themenbeispiel / „Aufhänger“: Lightning-Talk-Youtube-Video schauen, und danach `$x` selber nachbauen
bernd:
ich glaube, da bräuchtest du auch gutes Video.
ananke:
Im Vorfeld Werbung für den Vortrag machen, in Matrix o.ä.
Wann damit anfangen?
bernd:
1. Termin nach Ostern?
lbehm:
Nach Ostern, wenn alle aus Ferien zurück sind, sinnvoll: 18.04.23
ich arbeite derzeit an Borg-Backup-Umsetzungen ⇒ da könnte ich hinterher was zu erzählen wie man das nutzt oder worauf man achten muss
* Diskussion gleitet komplett in Borg-spezifische Implementationen ab
lbehm:
keine richtigen Vorträge, eher Workshop, Themen-Zusammenfassung vorstellen, ohne zu große Vorbereitung
als open end-Veranstaltung ⇒ wer zuerst kommt redet zu erst
Falls sich mehrere Leute anmelden ⇒ ggf. jemand schieben / spontane Abstimmung
Diskussionen auch über „Fremdmaterial“ wie z.B. Blog-Artikel oder Lightning-Talks starten.
Gutes Audio ist das A und O (wäre sagenhaft)
bernd:
Aber solange wir niemand einen Vortrag machen will/kann, können wir doch solange trotzdem Programmierübungen machen.
Erläuterungen zu Algorithmen fände ich zum Beispiel auch gut. Suchalgorithmen z.B.
⇒ Chaostreffteilnehmer um frühzeitige Themen-Vorschläge bitten und diese frühzeitig bewerben