• Beginn: 20:05
• Ende: 21:21
• Teilnehmer:
  • lbehm
  • qbi
  • ananke
  • moep
  • Tobi
  • bernd

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ähleisten
Netzwerk-Konfiguration über unterschiedliche Network-Manager
ToDos erfordern sehr viel Aufwand bei Abarbeitung

• Unterstützung und Beratung
• Server standardisieren/vereinheitlichen ⇒ „Infrastructure as Code“ wäre Zielstellung
• Umsetzungen mit Ansible? ⇒ Finden wir Ansprechpartner mit Erfahrung?
• Sinnvolle Vorgehensweisen erarbeiten
• Diskussion anstoßen

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 Vorraussetzungen 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 Vorraussetzungen ⇒ 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:

1. E-Mailserver, alt
2. Gitserver, Matrix, andere Hardware
3. Nextcloud, deutlich mehr Festplatte
4. Tor-Server
   • den gibts nicht, zur Zeit, später aber wieder
5. offsite Backup

Unterscheidung in Hardware und Anwendungsbereich.
Mehr Konfigurationsaufwand aber auch Vorteil.

qbi:
klar machen was gemacht werden soll
⇒ Gemeinschaftsprojekt schaffen?
ngnix 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 virual sites vorkonfiguriert ⇒ was kann man da vereinheitlichen? alle unterschiedlich?
einheitlicher Aufbau sollte möglich sein
nur auf 1 Server Mailserver notwenig (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, sowas muss es bereits geben
nicht alles sofort klären, zunächst Termin vereinbaren: Samstag/Sontag (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 gehts 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, daß alles zu verschiedenen Zeiten von unterschiedlichen Leuten gemacht wurde.
dann solten wir uns wohl vor allem erstmal klarwerden, 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.

• Termin: Reserviert für 15. oder 16.04.
• Anwesenheit: lbehm, qbi (Wahrscheinlichkeit 70%), ananke

qbi: Jemand hat in Matrixräumen dazu angefragt. Angeblich würde es inzwischen funktionierende Bridge geben, damit XMTP-Nutzer miteingebunden werden können.
⇒ Serverlandschaft würde diverser werden
Anfrage: ist das machbar? Interesse ist da, das wir das machen

moeb: Matterbridge?

bernd: kann ich dann noch spammer vom xmpp aus Matrix heraus kicken?

• vor Jahren waren bridges stinkender Haufen Mist
• Abstimmung: Soll eine Person nachforschen ob eine Matrix-Jabber-Bridge inzwischen gut realisierbar ist?
  • Ja: 4
  • Nein: 0
  • Enthaltungen: 1
• Beschluss: qbi forscht nach was es an Bridge-Infra gibt

lbehm:
War bei Plenum im CCCHH (CCC Hamburg)
„Verwaltung“ hatt Ü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

• Audiothema besser umsetzen
  1. bessere Lautsprecher damit die Remote-Seite besser gehört wird; derzeit Verständnisprobleme bei kleinen Laptop-Speakern im Raum
  2. Mikrofon im Raum/Tischmikrofon: bei kleinem Raum sinnvoll
• Ziel: die Veranstaltung angenehmer gestalten

• Chemnitzer-Linux-Tage haben stattgefunden
  • einige aus dem Verein waren vor Ort
  • einige davon haben sich Covid-Infiziert
• E-Mail-Probleme bestanden
  • wurden durch Abschaltung von E-Mail-Empfang auf alten Domains gelöst
  • sinnvolle Fehlermeldung waren angestrebt, aber nicht umsetzbar
• KI-Themenabend
  • ggf. daraus einen Vortrag machen?

• Bisher nicht stattgefunden
• Vortragender war leider nicht greifbar
• Wunschsprachen in repräsentativer Plenums-Jitsi-Umfrage vom 02.03.23: Python, Rust, PHP
• Vorschlag: Chaostreff mit angekündigten Themen
  • Werbung zu Veranstaltung und Themen
  • „Themen“ sollten aus Lightnig-Talks und Diskussions-Runde bestehen
• Idee aufgreifen, Ideen sammeln, Vortrag machen?

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