2. Sitzung Bereich Administration Rechentechnik 2021/2022

0. Formalia

0.0 Anwesende

• Paul ((geschäftsführende) Leitung Bereich Administration Rechentechnik)

0.1 Begrüßung

Die Leitung sieht sich bemüht eine Sitzung abzuhalten. Mindestens die Klarstellung zu bestehenden Mitgliedern ist protokollwürdig. Beispielsweise wurde Göran bei der 12. Sitzung Plenum 2022 als Mitglied kooptiert und soll nun Mitglied vom Bereich werden (können).

Einleitend möchte sich die Leitung für das hervorragende Engagement von MLp und goeranh bedanken. Es macht Freude zu sehen, dass (und was) geht.

1. Mitglieder

Clemens Haffner war bereits mehrere Legislaturen Mitglied vom Bereich. Clemens ist das funktionsfähige PVE (HCI aus 3 Servern mit Ceph) zu verdanken. Clemens wirkt noch an verschiedenen Dingen zum Betrieb der Server mit. Etwa die Verkablung (einzelne Switches mit einzelnen Servern) als redundantes System bearbeitet Clemens gegenwärtig.

Göran Heinemann ist diese Legislatur neu im StuRa. Göran hat sich mit den hervorragenden guten fachlichen Kenntnissen bei den letzten Arbeitstreffen des Bereiches eingebracht.

Matthias Jakobi war bereits mehrere Legislaturen Mitglied vom Bereich. Matthias ist das (mittlerweile in die Jahre gekommene) FreeBSD (später FreeNAS) zu verdanken. Matthias wirkt eigentlich kaum noch direkt für den Bereich mit. Jedoch ist Matthias die Beauftragung Administration Rechentechnik der Landesstudierendenvertretung (KSS) und soll so auch mitwirken können, was nahezu zwangsläufig ist, da der Server der KSS im StuRa HTW Dresden - wie auch alle anderen Server - betrieben wird.

Michael Bommhardt-Richter war bereits mehrere Legislaturen Mitglied vom Bereich.
Windows, Server vom Monitor im Foyer, etwa PHP, …

Michael Leopold ist diese Legislatur neu im StuRa. Michael hat sich bereits mit der hervorragenden arbeitswütigen Arbeitsmoral bei einer Vielzahl von häufigen Arbeitstreffen des Bereiches eingebracht.

Paul Riegel macht "den Bums" - die Betreuung vom Erbe von PT - schon länger. Leider kommt Paul (leider) viel zu selten dazu alles anstehende zu bewältigen. Naja! Paul ist aber die Leitung des Bereiches (und glaubt das auch gut zu erledigen).

Sophia von Asow war bereits letzte Legislatur Mitglied vom Bereich. Sophia waren verschiedene kleine Dinge, wie eine Schulung für Mitglieder zum Umgang mit massenhaften SPAM bei Mail, zu verdanken. Sophia ist auch die Leitung des Bereiches Webservices, womit Sophia stets sich auch als besonderes "anwendungsorientiertes" Mitglied im Bereich sehen kann.

Stehan Rankl war bereits mehrere Legislaturen Mitglied vom Bereich.
Netzwerkdosen, Windows, etwa Server vom Zugangsschließsystem, LMDE (Desktop/Laptop) und stets zuverlässig auch bei "unlustig trögen" Aufgaben

Der StuRa möge beschließen

• Clemens Haffner
• Göran Heinemann
• Matthias Jakobi
• Michael Bommhardt-Richter
• Michael Leopold
• Paul Riegel
• Sophia von Asow
• Stehan Rankl

als Mitglieder des Bereiches Administration Rechentechnik zu bestellen.

Die Leitung stimmt dem Antrag zu.

I. Berichte

I.X. pbs backup box

doku?
zu allen vorgenommenen Einstellungen (insbesondere auch Änderungen)

I.X. (pve) upgrade box

doku?
zu allen vorgenommenen Einstellungen (insbesondere auch Änderungen)

ja, das ist nur eine temporäre kiste.

also nach dem alles "hoch- und weg migriert" ist, dann kann sie einfach (platt gemacht werden und) wieder weggeschleppt werden, oder?

oder wollen wir (bewusst) eine kiste zum "ausprobieren" haben? (gefühlt hat das die leitung mal so raus gehört.) da sollten sich dann nämlich mal noch gedanken gemacht werden. (beispielsweise soll sicher das dateisystem vom vergleichsweise schnelle lokale storage - nicht dateisystem das vergleichsweise langsamen storage über das netzwerk - zum testen genutzt werden. ist es - wenn das node im verbund von proxmox, aber nicht im verbund von ceph hängen würde - möglich, dass instanzen vom zfs ins ceph "überführt" werden? riskante experimente, die die stabiltät vom bestehenden verbund (cluster) bedrohen, mag die leitung nämlich nicht "verantworten".) aber das ist dann sicherlich mal eine konzeptionierung werden.

I.X. owncloud/nextcloud upgrade party

II. Agenda zur Infrastruktur, insbesondere zum Betrieb IT-Services

Die Leitung hatte mal für ein neues aktives Mitglied eine "Roadmap MLp 2022" erstellt. Das gilt weiterhin.

Der Fokus - auch wenn das vielleicht vergleichsweise herausfordernder (weniger lustig) ist - liegt auf dem Überführen bestehender Instanzen (Jails auf FreeNAS zu LXC (PCT) auf Proxmox), die auf dem Weg aktualisiert werden sollen (müssen). Der aktuelle Prozess zur Überführung von (ownCloud/)Nextcloud ist exemplarisch dafür.

Neue Instanzen für neue Dienste können (und sollen) dann angegangen werden, wenn bestehende Dienste überführt sind. Der Anspruch an alle neuen Dienste soll es sein, dass sie an eine zentrale Verwaltung von Konten und Gruppen für Berechtigungen angebunden sind. Kleines illustrierendes (nahezu tagesaktuelles) Beispiel: Gitea können wir schon "spaßeshalber" einmal installieren, aber ernsthaft als längerfristige Instanz soll der Dienst nur angedacht werden, wenn er an eine zentrale Dienst für die Verwaltung der Konten und Gruppen (openldap, 389-ds, keycloak, freeipa, …) angeschlossen werden würde.)

III. Stelle Zuständigkeit Instandhaltung IT-Services

III.1. Vorschläge zur Verbesserung für die Ausschreibung der Stelle Zuständigkeit Instandhaltung IT-Services?

III.2. Stand zur Besetzung der Stelle Zuständigkeit Instandhaltung IT-Services

IV. Arbeitsmodus

Aufgaben via AUS ("Tickets") funktionieren ganz zumutbar. Wenn sich wer andere Arbeitsweise wünscht: Bitte Bescheid geben! (Gerade auf den wöchentlichen Arbeitstreffen geht ja auch einiges ab(zuklären).)

Paul will auch gern weiter die Leitung vom Bereich "in Anspruch" nehmen. Paul ist das gestern (illustrierende) wieder bewusst geworden: Bitte nehmt mich als (lieb gemeinte) unangenehme Instanz war, die Ansprüche "wie es laufen muss" erhebt. Selbstverständlich mag ich kein Mitglied des Bereiches damit "ärgern". Wenn es mal "Beschwerden" zu Entscheidungen (Setzen von Prioritäten, Ansprüche zu Abläufen und deren Dokumentation, Auswahl von technischen Lösungen, oder sonst etwas) gibt, dann ist Paul gern bereit das als "vergleichend" von der Leitung des Referates, vom Vorstand, oder gar vom Plenum entscheiden zu lassen. Alle können dann ihre Ansicht vortragen und dann wird eine Entscheidung - womöglich auch gegen die Leitung - getroffen. Aber bitte nicht Entscheidungen - weil sie gerade getroffen werden könnten - allein treffen. Gerade zu Instanzen, die wichtig (oder langfristig) sind, geht bitte nichts an der Leitung vorbei.

V. viele andere "putzige" Projekte

V.1. eigene "Compliance"

Die Leitung möchte noch eine Art Compliance entwickeln. Mit dem "Regelwerk" soll es "vorgefertigte" Entscheidungen geben, die für neue Aktiven einfach macht sich zu orientieren "das Richtige" zu tun.

Illustrierendes Beispiel https://wiki.stura.htw-dresden.de/index.php/Bereich_Administration_Rechentechnik#Direktiven

Hat wer Lust das mit zu erarbeiten?

Idealer Weise soll es für jede Entscheidung, die zu treffen ist, es eine Regel geben können. Also theoretisch kann (soll) jede Entscheidung als Frage an die Leitung formuliert werden und die Antwort (Entscheidung) soll in einer allgemeingültigen Regel enden.

Beispiel zur Auswahl vom Produkt (Anwendung) für den Dienst Datenbank:

1. Wenn es nicht einen guten Grund gibt davon abzuweichen, dann soll einfach der Standard - ohne notwendige weitere Konfiguration - von NixOS verwendet werden.
2. Anderenfalls und wenn die Anwendung nur mit einem bestimmten Produkt funktioniert, dann soll das bestimmte Produkt verwendet werden.
3. Anderenfalls und wenn die Anwendung mit dem Produkt funktioniert und erst einmal keine riesige Massen an Daten der Anwendung für die Datenbank zu erwarten sind, dann soll das Produkt SQLite verwendet werden.
4. Anderenfalls und wenn die Anwendung mit dem Produkt funktioniert, dann soll das Produkt PostgreSQL verwendet werden.
5. Anderenfalls und wenn die Anwendung mit einem bestimmten Produkt besonders gut funktionieren soll (etwa als Empfehlung oder Standard in der Dokumentation zur Installation), dann soll das bestimmte Produkt verwendet werden.
6. Anderenfalls und wenn die Anwendung mit dem Produkt funktioniert, dann soll das Produkt MariaDB
7. Anderenfalls und wenn die Anwendung mit dem Produkt funktioniert, dann soll das Produkt MySQL verwendet werden.verwendet werden.
8. (Anderenfalls … Anwendung nicht installieren! :-D )

V.2. Vereinbarung Rechenzentrum

siehe vielleicht 2. Beratung StuRa Rechenzentrum 2018 reloaded

V.3. "Berichtigung" Netzwerkdosen

Die Bitte zur Änderung (der "Auftrag") dazu haben 2022-03-15 mlp@, vat@ und elli@ für den Bereich an das RZ gesendet. Die Leitung hat dazu gestern noch mal - ganz dau-ig - per Mail beim RZ nachgefragt.

X. Weiteres

X.1. Rechenschaftsbericht (Bereich Administration Rechentechnik) 2022-I

X.2. kommende Sitzung

Die Leitung erklärt, dass sie jederzeit bereit ist, Sitzungen abzuhalten. Sie glaubt jedoch, dass aktuell einfach weiter (so toll wie zur Zeit) weiter gearbeitet werden sollte, anstatt zu schwadronieren.

X.3. (wöchentliche) regelmäßige Arbeitstreffen

vat freut sich, dass sich - dank MLp - ein Modus ergeben hat, dass sich mindestens freitags zum Arbeiten getroffen wird.

Die Leitung nimmt zur Kenntnis, dass aber auch wesentlich öfter gearbeitet wird, aber begrüßt die Regelmäßigkeit.

X.4. kommende Sitzung des Referates

Die Leitung wünscht sich dringlich eine Sitzung des Referates. Wie der Leitung des Referates bekannt ist, hat die Leitung (des Bereiches) Anträge, die zu beschaffen wären. Erst nach der Zustimmung können gewisse Aufgaben - etwa das testweise Erstellen von Diensten zu Mail - angegangen werden.

PLZ!