WiSe15 AK ZaPF IT

Vorstellung des AKs

Verantwortliche/r: Jörg (FU Berlin), Fabs (TU Berlin), Björn (RWTH)

Es soll ein bisschen über die IT-Probleme der ZaPF gesprochen werden bzw. was die ZaPF so braucht. Konkret:

• Wo brauchen wir Hilfe
• Zentrales Anmeldesystem für zaPFEn
• Homepage der ZaPF

Es wird explizit darum gebeten nicht in einen ``Plausch-AK zu rutschen, sondern konstruktiv motivierte Menschen für einzelnen Aufgaben und Lösungen zu finden.

Arbeitskreis: ZaPF-IT

Protokoll vom 20.11.2015

Beginn

16:32 Uhr

Ende

Redeleitung

Fabian Freyer (TU Berlin)

Jörg Behrmann (FU Berlin)

Björn Guth (RWTH Aachen)

Protokoll

Jörg Behrmann (FU Berlin)

Anwesende Fachschaften

RWTH Aachen,

FU Berlin,

HU Berlin,

TU Berlin,

Uni Bremen,

TU Dresden,

Uni Düsseldorf,

Uni Frankfurt,

Uni Jena,

Uni Konstanz,

TU München,

WWU Münster,

Uni Siegen,

Uni Wien,

Einleitung/Ziel des AK

Bericht von der Arbeit des TOPFes und Aquise neuer Henkel und Abstecken zukünftiger Projekte.

Protokoll

Der TOPF berichtet, dass das Konfigurationsmanagementsystem Ansible für die Projekte des TOPF gewählt wurde. Für Erprobungen wurde ein Testsystem aufgebaut, bevor Projekte in den Produktiveinsatz gehen. Derzeit ist noch nichts im Produktiveinsatz, aber einige Dinge, allen voran ein Issue Tracker (Phabricator), läuft auf dem Testsystem und sollen bald auf das Produktivsystem (Debian stable) migriert werden. Weiterhin berichtet der TOPF von seinen Abenteuern diversen Softwareprojekten der ZaPF nachzuspüren.

Projektvorschläge

Im Folgenden werden Projektvorschläge diskutiert:

• ein Projektmanagementsystem
• Etherpad
• Backup
• ZaPF-Anmeldesystem
• zentrales Authentifizierungssystem

Alle Interessierten, die Henkel werden wollen, werden aufgefordert einen Account im Ticket-Tracker zu machen und Projekte zu planen und zu diskutieren, damit sie implementiert werden können.

Projektmanagementsystem

Die Fachschaften Konstanz, Frankfurt, TU München und Aachen berichten von der Benutzung der Projektmanagementsystem Redmine und trac.

Die Benutzung eines Projektmanagementsystems für die Organisation der ZaPF wird positiv bewertet und Aachen weist darauf hin, dass dies bei der KIF schon lange Tradition hat, wodurch ausrichtende Fachschaften auf einen sehr breiten Fundus an Material (BMBF-Anträge, etc.) und bekannten Problemstellungen und Lösungsansätzen zurückgreifen können. Es wird aber darauf hingewiesen, dass das Projektmanagementsystem geschlossen sein muss und nur ausrichtende Fachschaften darauf Zugriff haben sollen

Etherpad

Die TU Berlin wünscht die Einrichtung eines Etherpads. Dies wird aufgrund des administrativen Albtraums, den ein Etherpad darstellt, abgelehnt.

Backup

Die TU München erfragt den Stand von Backuprozeduren. Bis jetzt sind dafür noch keine Verfahren etabliert, da Backupplatz auch weitere Kosten aufwerfen würde, wenn eine von Universitäten unabhängige, nur vom ZaPF e.V. getragene, Lösung gefunden werden soll.

Zentrales Anmeldesystem

Einige Mitglieder des AK finden sich zusammen um ein Anmeldesystem zu bauen. Es wird vorgeschlagen es in Front- und Backend zu trennen und eine API zu definieren, damit Fachschaften ihre eigenen Frontends implementieren können, falls sie das wollen.

Fachschafts-IT

Wie zuletzt auf der ZaPF in Wien wird ein kurzer Überblick nach IT-Projekten.

• Aachen: bietet "everything and the kitchen sink", IT ist vollständig autark
• FU Berlin: hat keine eigenen IT, aber gute Verbindungen zur EDV des Fachbereiches
• HU Berlin: keine eigenen IT-Projekte
• TU Berlin: eigene, autarke IT
• Bremen: keine eigenen IT-Projekte, hängt an den Diensten des Hochschulrechenzentrums
• Düsseldorf: war vollständig autark und hat alles an das Hochschulrechenzentrum abgegeben
• Dresden: hat keine eigene IT und nutzt hauptsächlich Services Dritter
• Frankfurt: betreibt eigenen IT-Projekte
• Konstanz: betreibt eine Owncloud und viele selbtgestrickte Projekte, daunter ein Anmeldesystem für Erstiefahrten
• Jena: eigene IT-Projekte
• Siegen: Website der Fachschaft ist bei Wordpress, starke Nutzung nicht-universitärer Dritter, Rückmigration auf eigene Dienste wird von Nutzern nicht angenommen
• TU München: eigenen autarke IT, Hoster für andere
• Münster: keine eigenen IT-Projekte, hängt an den Diensten des Hochschulrechenzentrums
• Uni Wien: eigenen autarke IT, Hoster für andere

Zusammenfassung

Der TOPF berichtete von aktuellen Stand und hat mit prospektiven Henkeln zukünftige Projekte diskutiert.