====== Plenum vom 06.04.2023 ====== * Beginn: 20:05 * Ende: 21:21 * Teilnehmer: * lbehm * qbi * ananke * moep * Tobi * bernd ===== Themen ===== ==== Vereins-Infrastruktur ==== > **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 === Wunsch === * 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 === Diskussion === > **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: - E-Mailserver, alt - Gitserver, Matrix, andere Hardware - Nextcloud, deutlich mehr Festplatte - Tor-Server * den gibts nicht, zur Zeit, später aber wieder - 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. === Beschluss === ⇒ Admintreffen in Vereinsräumen veranstalten. * Termin: Reserviert für 15. oder 16.04. * Anwesenheit: lbehm, qbi (Wahrscheinlichkeit 70%), ananke ==== Bridge zwischen Jabber und Matrix ==== > **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 ==== Sonstiges ==== > **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 - bessere Lautsprecher damit die Remote-Seite besser gehört wird; derzeit Verständnisprobleme bei kleinen Laptop-Speakern im Raum - Mikrofon im Raum/Tischmikrofon: bei kleinem Raum sinnvoll * Ziel: die Veranstaltung angenehmer gestalten ==== Rückblick seit letztem Plenum ==== * 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? === Coding-Corner für Programmierer einführen? === * 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. == Beschluss == ⇒ Chaostreffteilnehmer um frühzeitige Themen-Vorschläge bitten und diese frühzeitig bewerben