4. Sitzung Bereich Administration Rechentechnik 2022/2023

4. Sitzung des Bereiches Administration Rechentechnik 2022/2023
Wann 10.01.2023 um 19:00 bis
11.01.2023 um 00:30
Wo A002
Name
Termin übernehmen vCal
iCal

 

 

Formalia

 

goeranh@ ist anwesend.

offbyone@ ist anwesend.

Paul (als Leitung) ist anwesend.

 

 

Mitglieder

 

Was ist denn mit

  • Max Patecky und
  • Jonas Hirche?

Haben wir die verloren?

Bisher sind sie auch noch nicht in den Bereich bestellt. Oder?

Bei Max ist das gerade auch wegen der Teilnahme von software engineering etwas verwunderlich.

Bei Jonas besteht die Hoffnung, dass er bei der kommenden Sitzung vom Referat (am Freitag) von selbst kommen wird.

 

 

Plan für die "Abschaffung" von srs1337

 

Die Leitung möchte gern den Plan zur "Abschaffung" vom Host srs1337 (und srs100034) besprochen haben.

Zum Jahresende fand schon ein "Ausmisten" statt. (https://pro.stura.htw-dresden.de/issues/1512)

Die Leitung stellt folgenden Plan vor:

  • Alle Instanzen, die (vermeintlich erfolgreich) migrierte wurden, werden als "Datengrab" in eine Instanz mit ZFS (weg) gesichert. Danach sollen die Instanzen (Container (FreeBSD Jails)) gelöscht werden (können). Konkret betrifft das:
    • srs13
      • früher für wiki.…
      • Anwendung MediaWiki
        • arg veraltete Version (dort Version 1.17, dann Version 1.36, nun schon Version 1.38)
    • srs15
      • früher für pro.…
      • Anwendung Redmine
        • arg veraltete Version (dort Version 2, nun Version 4, bald vielleicht Version 5)
    • owncloud_1
      • früher für cloud.…
      • Anwendung ownCloud (nun Anwendung Nextcloud)
        • arg veraltete Version (dort Version 9.1, dann Version 22 oder Version 23, nun Version Version 24)
    • srs33
      • KSS
      • wki.kss-sachsen.de
      • Anwendung MediaWiki
      • vermutlich schon seit Jahren migriert (aber vielleicht auch vom eigenen Server hin zum Container migriert)
      • 2022-12-29T19:19 Absprache (telefonisch) mit admin@kss-sachsen.de (pt@), dass die Instanz nicht mehr gebraucht werden, da sie bereits migriert sind.
    • srs34
      • KSS
      • lists.kss-sachsen.de
      • Anwendung GNU Mailman (und vielleicht auch Mail im Allgemeinen)
      • vermutlich schon seit Jahren migriert (aber vielleicht auch vom eigenen Server hin zum Container migriert)
      • 2022-12-29T19:19 Absprache (telefonisch) mit admin@kss-sachsen.de (pt@), dass die Instanz nicht mehr gebraucht werden, da sie bereits migriert sind.
  • Alle Instanzen, deren Daten nicht (ohne unglaublichen Aufwand) zugänglich sind, werden gelöscht.
    • owncloud_2 (Anwendung ownCloud (arg veraltete Version, und nun Anwendung Nextcloud) für cloud.…)
      • (früher) für hfa.htw.stura-dresden.de
      • Anwendung ownCloud
        • arg veraltete Version (Version 9.1, aktuell wäre wohl 10.11)
      • Daten vom Härtefallausschuss (vermutlich Anträge, samt Anlagen)
      • Die Daten sind verschlüsselt. (Kein Mensch, der aktuell im StuRa Mitglied ist, hat die Zugangsdaten. (Vermutlich war der letzte Mensch, der das wusste, Martin Kalisch.))
      • vermutlich genutzt von 2016 bis 2018
        • (Nach Absprache mit dem Referat Finanzen sind die betreffenden Jahresabschlüsse bereits durch die Innenrevision und die Daten nicht mehr relevant.)
  • Alle Instanzen, die irgendwann einmal noch migriert werden könnten, aber aktuell als nicht mehr für den Gebrauch notwendig erachtet werden, werden als "Datenhalde" in eine Instanz mit ZFS (weg) gesichert.
    • owncloud_3
      • (früher) für owncloud.fsr-et.htwdd.de
      • Anwendung ownCloud (arg veraltete Version)
      • FSR ET
    • im_data
      • (lief früher) als 141.56.51.132
      • vermutlich Anwendung für (Datenbanken mit) SQL & Co
      • vermutlich schlicht zum Speichern von Daten für die Instanz im_web
    • im_web
      • (lief früher) als 141.56.51.131
      • vermutlich selbst geschriebene Software für http & Co
      • Kein Mensch, der aktuell im StuRa Mitglied ist, hat eine Ahnung wozu das System dient. (Vermutlich war der letzte Mensch, der das wusste, Paul Patolla, der das Projekt höchstens angefangen hatte.)
    • srs1_haproxy
      • …
    • srs20
      • https://pro.stura.htw-dresden.de/issues/1518
    • vHost1
      • früher 192.168.…
      • nun 141.56.51.230
      • mit
        • ispconfig (aka srs29)
          • früher 141.56.50.29
          • nun 141.56.51.229
  • …

 

Umgang mit der Jail für Website

 

Vielleicht - durch das monatelange Stochern, insbesondere von goeranh - ist ein Weg über FreeBSD (Version 10) und dem Bauen aus Ports möglich.

Paul, der sich das (theoretisch) angeschaut hat, glaubt an den Weg. Das wäre (endlich) tatsächlich ein Weg. goeranh hat als Indikator schon "damals zeitgemäße" Version von zodbbrowser (https://pypi.org/project/zodbbrowser/) installiert und konnte das sonst übliche Problem, dass die Datenbank gar nicht "gelesen" werden kann.

FreeBSD (Version 10 (Version 10.4)) installieren, cd /usr/ports/www/plone && make install clean, filestore und blobstorage kopieren und starten. Hoffen!

Vor dort aus (FreeBSD 10) soll dann zum Cluster (Debain mit plone unified installer für Plone 4) umgezogen werden.

 

 

Umgang mit der Jail für Mail

 

Paul möchte kurz seine Gedanken zur möglichen Überführung von srs14 auf srs100034 benennen.

TrueNAS CORE als Virtualisierung (und vorübergehenden Dauerbetrieb) installieren, eine neue Jail erstellen. Die neu erstellte Jail komplett durch die alte Jail (FreeNAS 11.1) ersetzen und Funktionalität prüfen.

Alternativ könnte q&d in ein Debian 10 umgezogen werden (mailman (Version 2) - aber auch postfix - sind dort verfügbar). Dazu müsste der Dienst Mail aber für die Dauer der Migration ausgeschaltet (nicht erreichbar) sein. Danach könnte eine Aktualisierung der Anwendung mailman (Version 3) erfolgen, eine Aktualisierung auf Debian 11 (samt allen anderen Paketen) erfolgen.

Artikelaktionen

Versenden
Drucken