WiSe16 AK TOPF

Vorstellung des AKs

Verantwortliche/r: Robert (UKN), Jörg (FUB), Jan (FUB)

In dem AK sollen aktuelle Projekte/Probleme des Technische Organisationsausschuss aller Physikfachschaften (TOPF) vorgestellt werden. Der AK dient allen ZaPF-IT-Interessierten als Austauschplattform. Interessierte an einer künftigen Arbeit im/mit dem TOPF sind gerne gesehen ;-)

Arbeitskreis: TOPF und IT-Dinge

Protokoll vom 12.11.2016

Beginn

11:06 Uhr

Ende

12:42 Uhr

Redeleitung

Robert Löffler (KN)

Protokoll

Niklas Westermann (KN)

Anwesende Fachschaften

Uni Konstanz

TU Kaiserslautern

FSU Jena

Uni Münster

Uni Siegen

Freie Uni Berlin

Wichtige Informationen zum AK

• Ziel des AK: Austausch über ZaPF-IT
• Handelt es sich um einen Folge-AK: Im weiteren Sinne, da es immer einen ZaPF-IT-AK gibt, aber die sind relativ unabhängig.
• Materialien und weitere Informationen: Link zu Protokollen, Artikeln, Gesetzen etc. angeben, Dateien hochladen
• Wer ist die Zielgruppe?: Alle IT-Interssierten und sonstigen ZaPFika sind gerne willkommen, Kenntnisstand in IT ist nebensächlich, da auch Probleme angesprochen werden können, die man nicht selbst lösen kann.
• Wie läuft der AK ab?: Offener Austausch
• materielle (und immaterielle) Voraussetzung: Laptop

Protokoll

Robert berichtet:

• Es gibt noch keinen zentralen LDAP-Server für die Account-Verwaltung
• Wir haben einen neuen Mailman (Mailman3, [1] ) mit coolem Management Frontend. Da hin sollen demnächst alle Listen umziehen
• Es gibt eine neues Design im Wiki. Allerdings gibt es noch ein paar kleine Bugs. Auch der Studienführer ist im neuen Design. Dort und auch bei den Lists kann demnächst SSL aktiviert werden. Der Umzug für die ZaPFList dauert evtl. noch ein bisschen, da im neuen Release z.B die Benutzeraccounts nicht mehr so gut verwaltet werden können.
• Auf dem Server selbst läuft ein postfix, Richard wirft ein, dass das ein Problem ist, da der Server nicht gewhitelistet ist. Wir brauchen einen etablierten SMTP, das Problem an in Jena war, dass Richards Server kein Sender-Score hatte.
• Robert würde sich gerne noch mit dem StaPF zusammen setzen, da der das OpenProject (Ticketsystem) aktuell nicht genutzt wird. Aktuell nutzt es Berlin. Ein Problem ist, dass es oft Verbindungsabbrüche gibt.
• Der ZaPF e.V. will eine Nextcloud
• Mit der Nextcloud und Edupads könnte das OpenProject hinfällig werden. Aktuell wird unter anderem das SplinePad genutzt.
• Robert sucht einen Deckel. Jan (FUB) meldet sich, wer möchte auch?
• Robert hätte gerne, dass das Geld für die Domains regelmäßig überwiesen wird.
• Die Domains liegen bei INWX.
• Die Server an sich liegen bei Strato.

Allgemeine Diskussion

• Man sollte auf eine Root-Server und keinen VServer benutzen, da eine NextCloud zu viel Ressourcen frisst. Allerdings könnte man sich für weniger Geld einen NextCloud-Server mieten. Außerdem ist die Administrationsarbeit sehr aufwendig. Des weiteren stellt sich die Frage nach der Ausfallsicherheit. Robert hat nachgeschaut, für 10€ bekommen wir eine Nextcloud mit 100GB. Robert redet mit dem StaPF darüber
• Es kommt die Frage auf, ob der Phabricator auch für andere Projekte genutzt werden kann. Es kann ausprobiert werden, ist aber für ein Projektmanagement nicht besonders sinnvoll.
• Diskussion über LDAP
  • Aufwand
  • Für ein Zentrales Anmeldesystem nötig
  • Oauth funktioniert nicht mit Mumble, Etherpad und Mailman, mit LDAP geht das
  • Man könnte das ganze über OpenID laufen lassen.
  • Da es im Wiki eine Versionierung mithilfe der Benutzer(namen) gibt, sollten die alten Benutzer nicht gelöscht werden. Robert möchte die Nutzer neu anlegen, die Nutzer des Wiki sollte "anständig" migriert werden.
  • Richard ist dagegen, dass wir uns wieder selbst eine Lösung zusammen basteln und damit wieder mehr Arbeit haben.
  • Bei LDAP gibt es folgenden Probleme: Auf die Rechtevergabe muss sehr viel Wert gelegt werden.
  • Wir wollen ein LDAP, das nicht zu komplex wird.
• Wir sollten uns das Bundesdatenschutzgesetz halten und auch eine Datenschutzerklärung veröffentlichen. Eine Rechtsberatung bzw. eine Absicherung bei Fehlern/Verstößen sollte geplant werden.

• AZAS
  • Dresden benutzt das AZAS von Richard, Berlin hat evtl. ein selbst erstelltes, Siegen hat noch keine Ahnung
  • Chemie benutzt auch das AZAS
  • Das Frontend ist nicht sicher (das Backend ist sehr sicher), muss es aber nicht sein. Allerdings ist es noch ausbaufähig, da anscheinend kleinere Bugs auftreten.
  • In scala geschrieben
  • Robert möchte erst auf eine zentrales Accountsystem hinarbeiten und danach auf ein zentrales Anmeldesystem.
  • Persönliche Tokens wären gut um private Daten zu schützen
  • Richard mag kein System, auf dem gleichzeitig ein Mailserver laufen muss um z.B. die Mails zu verifizieren.
  • Robert lagert diese Diskussion in einen Bier-AK oder ähnlichem aus.

• Da es keine weiteren Punkte gibt, wird die Sitzung beendet.