WiSe13 AK FachschaftsIT

Aus ZaPFWiki

Arbeitskreis: Fachschafts-IT

Protokoll vom 16.11.2013

Beginn
08:35 Uhr
Ende
10:05 Uhr
Redeleitung
Patrick (RWTH Aachen)
Protokoll
Larissa Boie (FU Berlin)
Anwesende Fachschaften

RWTH Aachen, FU Berlin, TU Berlin, Uni Bonn, TU Braunschweig, Uni Bremen, TU Dresden, Uni Düsseldorf, TU Graz, Uni Hamburg, Uni Karlsruhe, Uni Konstanz, Uni Leipzig, Uni Marburg, LMU München, Uni Würzburg, PsyFaKo

Einleitung/Ziel des AK

Verantwortliche/r: Patrick (RWTH Aachen)

Ziel des Arbeitskreises ist der Austausch der Verantwortlichen für FS-IT (aka Admins). Falls ihr irgendwelche Probleme mit eurer Infrastruktur habt und/oder ihr gerne etwas an eurer IT ändern wollt, könnt ihr euer Problem gerne dem AK vorstellen um von den bestehenden Erfahrungen der Anwesenden profitieren zu können.

Mögliche Fragen, die diskutiert werden könnten:

  • Verwendete Betriebssysteme/Distributionen
  • Vorhandene Server (Hardware und Serverdienste, Virtualisierung?)
  • IT-Angebot für aktive Fachschaftler und alle Studis
  • Konfigurationsmanagementsysteme (Ansible, Puppet, FAI usw...)
  • Drucker (Leasing oder eigener Drucker?)
  • ...

Mailingliste

Die Adresse der Mailingliste ist: zapfadmins@lists.physik.tu-berlin.de

Eintragen könnt ihr euch HIER

Protokoll

In der Runde werden kurz die Strukturen vorgestellt, man kann direkt Zwischenfragen stellen.

Aachen: Fachschafts-Admin, relativ große FS mit Mathe/Info zusammen, haben 8 Clients mit Debian, Server sind bei einem Lehrstuhl im Serverraum gehostet, betreiben eigene Firewall, haben Video-AG mit viel Traffic (filmen die Vorlesungen), verwenden Ansible

TU Graz: Wird von nicht selbst administriert, Plone wird verwendet

Leipzig: hoffnungslos veraltete Homepage, haben Verteiler, machen viel mit Cloud-Computing (Google drive)

KIT: 3 FS-Admins, 2 PCs mit Ubuntu 12.04, 1 Server mit Debian wo Website liegt, haben ein Forum, internes Wiki, Mailingliste, Protokollverleih (sehr alt und schwierig zu warten), Website mit Opal, bekommen .edu-Adresse (wegen VS), Zukunft: Dürfen sie noch eigene Rechenzentren betreiben? Das Rechenzentrum will das nicht mehr.

Bremen: Sie haben einen Homepage-Beauftragten (aber nur der Postfachbeauftragte, der Mails verwaltet, ist da). Er hat keine Ahnung wie die HP funktioniert. Nutzen jetzt Titan-Pad und organisieren darüber Dinge, Fragen etc. können von allen da rein geschrieben werden, Einträge werden in Sitzungen diskutiert.

Würzburg: Wie werden gemeinsame Verzeichnisse/Archivordner gehandhabt?

Psyfako: Wollen ihr Netzwerk zum Laufen bringen. Auf Bundesebene eigener Server mit Wordpress. Interessiert sich für File-Ablagen/Online-Server.

Dresden: Haben Domain gekauft, die an Uniseite weitergeleitet wird. Uni hat CMS, sie müssen das auch machen. Haben auch ein internes Wiki mit Protokollen, für Diskussion, laden dort Fotos hoch, öffentlich sichtbar für alle, Rechner im FSR-Raum laufen mit Ubuntu

TU Berlin: haben zwei Clientsysteme, die sie manchmal zu wenig finden. Dürfen von ihrer IT aus keine eigene Mail haben. Aber Physik darf eigenen Mailserver betreiben. Sind gerade dabei, ihre Sitzungen transparenter zu gestalten, nutzen dafür Piraten-Pad, wollen irgendwann mal ihre Sitzungen streamen. Teilweise aber unzufrieden, weil das Piraten-Pad nicht auf dem eigenen Server liegt.

Aachen: Hosten allgemein viele Basis-Dienste. Machen auch Pads. Konstanz macht das auch so.

Braunschweig: Haben nur Homepage, sind relativ klein, brauchen nicht mehr. Wollen aber auch Dateien verwalten. Einziger Mensch mit Admin-Zugang ist verschwunden.

Bonn: haben Server für interne Dinge, Homepage wird extern gehostet, aber schon sehr veraltet. Haben ein Wiki mit z.B. How-Tos. Protokolle sind auf dem Server abgelegt, nicht im Wiki, man kann von den Clients drauf zugreifen. Nachtrag dazu: hatten schon immer ein Konto-Managementsystem, damit FSler alles selbst machen können. Vor zwei Jahren wollten sie die Webseite verschönern, mittlerweile wohl ein Design aber noch keine Ergebnisse vorhanden, deshalb wird die alte Webseite vernachlässigt, Server wurde mal von außen abgeschossen. EDV und Webseite sind zwei getrennte Referate.

Hamburg: Haben Plone, Idee war, dass alle mitarbeiten, aber nur 3-4 Leute beherrschen das, daher auch fast nie aktuell. Fragt, wie man anderen Leuten das beibringen kann. Der Rechner wird als Datenablage verwendet. Mailing läuft über Physik-Rechenzentrum (RZ). RZ ist restriktiv. FS hat zwar einen Router, den dürfen sie aber nicht anschließen.

LMU: komplett verzahnt mit komplettem FS-Hosting. haben ein Admin-Team für alle FSen gemeinsam. Haben 4 Clients, hosten ziemlich alles (2 Wikis, Channel, Ether-Pad).

FU Berlin: Haben eine Homepage, haben ein Wiki, aber recht leer. Haben Ether-Pad, von der Informatik gehostet. FSI hat keine eigenen Rechner. Protokolle werden getext und stehen auf der Homepage. Haben Mailingliste und Prüfungsdatenbank, aber ohne fancy Drumrum.

Marburg: Hat seit ca. 7 Jahren ein Wiki mit allem drin: Infos über Feiern (organisatorisches), Protokolle etc. Infos helfen sehr, neue Leute haben direkt alle wichtigen Infos. Rechenzentrum kümmert sich um Mailingliste etc. Machen auch die Vorlesungsumfrage: FS hat ein Skript gebastelt, jeder FSler kann sich anmelden, Papier-Lehrevaluationsbögen werden eingelesen. Am Ende kommt Latex-Skript raus mit der Auswertung. Ordnung im Wiki wird nach "Jahreskalender" chronologisch sortiert.

Konstanz: Haben 1 Rechner, der auch Server ist, da läuft auch die mäßig aktuelle Homepage. Haben kein Wiki. Mit Cloud von außen zugreifbar. Haben externe und interne Mailinglist. Protokolle werden im Etherpad geschrieben, wird sich aber sicher mit Verfasster Studierendenschaft (VS) ändern. Haben Forum eingerichtet, aber etwas unübersichtlich bei mehreren gleichzeitigen Themen.

TOP 1: Dateiaustausch/Ordnerstruktur

LMU hat einmal einen Cut gemacht, sich hingesetzt, sortiert und aufgeräumt und seitdem läuft es gut, was Ordnung betrifft. Aber im ersten halben Jahr mussten alle mehr suchen. Hamburg: Clone hat eine nette Suchfunktion, die erzieht Leute, vernüftige Beschreibungen/Titel anzugeben. Über die Suche findet man alles. Würzburg: Hat auch vor ein paar Wochen geordnet, Befürchtung: Nach einem Jahr alles wie früher. Aachen gibt einen Tipp: Ordner für spezielle Veranstaltungen im Voraus anlegen, damit die komplette Arbeit dort sofort abgelegt werden kann.

Marburg: Hatten txt- und Word-Dokumente erstellt. War nicht so gut, haben jetzt alles im Wiki, weil man jedes Jahr wieder zugreifen will. Haben Kapitel mit Semester, kopieren die Inhalte aus dem Vorjahr, Leute können sich neu eintragen für Dienste etc.

TU Berlin: Jedes halbe Jahr wird aufgeräumt, die Leute halten sich eh nicht an Vorgaben.

LMU: Um Chaos zu vermeiden, darf nicht jeder Benutzer Ordner anlegen, sodass gar nicht so viele Ordner entstanden sind (Erziehung!). War als Maßnahme gedacht, um sich mit der neuen Struktur nach dem Aufräumen vertraut zu machen. Größtes Problem: Dateistrukturen/Verzeichnisse und Wiki: Wo liegen die Infos? Diskrepanz? Wo ist die aktuelle Version? Wiki nicht für größere Dateimengen geeignet, Dateien nicht so gut zu ordnen.

Marburg lädt sogar Bilder ins Wiki hoch (große Datenmengen funktionieren sehr wohl). Das klappt alles sehr gut, das Wiki läuft da super.

Aachen: Nerds versus Browser-Struktur (anwenderfreundlich) im Wiki. Nerds sind unzufrieden, Normalos wollen aber auch damit klarkommen.

Hamburg verwendet Plone: CMS, mächtig, einfach.

TU Berlin hat mit distributed Dropbox (BTSync) angefangen. Funktioniert nur mäßig. Struktur ist etwas chaotisch. Aachen empfiehlt OwnCloud. TU Berlin rät: keine hypersensiblen Daten in OwnCloud lagern! Der Security sei nicht zu trauen.

Bonn will alle FS-Daten in Wiki integrieren. Haben keinen "Kampf" zwischen extern mounten und Anwendung für normale. Sie finden zur Zeit einfach keine Daten wegen chaotischer Sortierung. Aachen: Es gibt Tracker-Indizes, mit denen man für jedes Dateiformat eine Freitextsuche machen kann.

TOP 2: Admin-Nachwuchs

Aachen fragt: Wie kann eine Übergabe, gerade einer etwas größeren Infrastruktur, an neue Admins stattfinden? Dresden hat das selbe Problem. Sie empfehlen eine Screen-Shot-Anleitung für Edits/Wartung etc., die zwar sehr aufwendig zu erstellen, aber hilfreich für Neue ist.

Der Würzburger Vertreter wurde ins kalte Wasser geschmissen, aber der alte Admin konnte angerufen werden. Er hat viel Zeit investiert, aber lerning-by-doing war sehr effizient. Erreichbarkeit der alten Admins sollte man unbegdingt sicherstellen!

Marburg hat nicht nur einen Experten, sondern sie haben zur Zeit 2 Leute, damit Infos nicht verloren gehen und immer einer ausgetauscht werden kann, ohne dass Expertise verloren geht. Deren Sytem ist nicht sonderlich komplex, einfaches Warten. Manche Dinge werden outgesourct.

Aachen: Komplexität kleinhalten ist eine gute Idee. Wenn Dinge zu sehr als Hobby spezieller Personen angesehen werden, ist es schwierig, die Strukturen an weniger begeisterte Bastler zu übergeben.

Dresden: Die neue Generation arbeitet sich selber ein. Es kümmern sich viele verschiedene Leute darum. Sie stellen nochmal die Frage, wie man eine komplexe Struktur sinnvoll übergeben kann.

TOP 3: Beteiligung anderer an Admin-Prozessen

Wie kann man andere aktive Fachschaftler dazu bewegen, einen Artikel auf einer Homepage zu erstellen?

Aachen ist auf Wordpress umgestiegen, es klappt jetzt besser, neue Leute trauen sich. Katja glaubt, dass viele sich nicht angesprochen fühlen, und das Problem nicht darin liegt, dass die Leute Angst vor der Software etc. haben (verbreitete Meinung: "Es gibt ja spezielle Leute, die das machen").

KIT: Es gibt ein paar Leute, die sich kümmern. Sie benutzen Drupal. Die Admins bieten einen Crashkurs an.

Leipzig: Nach jeder Sitzung schreibt wer anders eine Zusammenfassung, die auf die Homepage kommt. Dadurch lernen es viele Leute und im Anschluss an die Sitzung kann auch Hilfe geleistet werden.

TOP 4: Fachschaftsinterne online-Kommunikation

Genny: Channels (FUB verwendet Freenode) sind eine gute Diskussionsplattform. Man kann von der Homepage auch direkt eine Frage in den Channel schicken. Würzburg fragt, welche Kommunikationsplattformen zur Zeit verwendet werden.

FUB: Facebook ist "verboten". Viele Fachschaften haben auch eine generelle Facebook-Abneigung.

Hamburg: Wer ist die ganze Zeit online? Dann ist Channel nicht so hilfreich. Etherpad ist nicht so gut aufgenommen worden, weil wohl die Internetverbindung nicht immer so gut ist. Konstanz hat ein LAN-Kabel, dass der Protokollant bekommt, damit die Verbindung gegeben ist.

Bonn: Hat eine FB-Seite, haben auch einen rege benutzten Twitter-Account, mit dem sie Infos nach außen geben.

Bremen: Studierendenvertretung, muss sich auch an Masse der Studies anpassen. Daher FB-Gruppe, auf der einmal pro Woche das Protokoll verlinkt wird. Protokoll aushängen scheint mehr Leute zu erreichen.

Leipzig: Erreicht mehr Leute, seit sie FB haben. Die Uni hat die FSRs angehalten, FB-Gruppen zu gründen.

Aachen: macht jetzt auch FB für Öffentlichkeitsarbeit, aber keine interne Kommunikation. Verpflichtung, dass alle FB-Infos auch auf der Homepage verbunden werden. Leipzig hat RSS-Feed-Verknüpfung mit Facebook.

Aachen stimmt zu, dass man nicht zu viele verschiedene Kanäle haben sollte. ABer z.B. Channel und Email werden für verschiedene Dinge verwendet.

Hamburg: macht auch Mails mit einer Zeile, die über den Verteiler laufen. Es bekommen alle ein Jabber/IRC account

TU Berlin: hat eine WhatsApp-Gruppe, aber es gab Beschwerden von Leuten, die das nicht haben. Daher jetzt wieder aufgehört.

TOP Verschiedenes: Hamburg hostet den Studienführer. Sie sind auch damit einverstanden, das Wiki Internationaler Studienführer auf dem selben Serven zu hosten. Sebastian kann Admin machen.

Gibt es ein Ticketsystem o.ä. um herauszufinden, wer Mails beantwortet etc? Konstanz hat das nicht, lesenswerte Mails werden gefiltert und erst dann auf internen Verteiler geleitet. Aber die Liste wird in CC gesetzt, damit die anderen wissen, dass und was geantwortet wurde. Würzburg hat Archivordner für die letzten Jahre, Inbox ist standartmäßig leer. Es gibt einen Ordner "in Arbeit", ankommende Mails werden von den Leuten gelesen, wer sich drum kümmert, verschiebt die Mail in den "in Arbeit"-Ordner. Hamburg macht es so, dass sobald einer geantwortet hat, die folgende Kommunikation nur mit einer Person läuft. Trifft nicht so auf Zustimmung, weil nicht jeder alle Antworten zu Fragen kennt. Problem bei Tickets: Es werden so viele Tickets erstellt, dass man mit bearbeiteten Tickets nicht hinterher kommt.

Werden Mails von außen (Werbung, Umfragen etc) moderiert/gefiltert? Moderation findet größtenteils statt. Spam etc wird nicht weitergeleitet. An LMU wollten Leute vom Verteiler gestrichen werden, als sie Umfragen etc. bekamen. Marburg hat eine Umfragen@-Adresse, sodass man nichts weiterleiten muss. LMU hat das auch für Jobs. Jeder kann sich ein- oder austragen. Bei Aachen gibt es Jobs-Spam@ und Umfragen-Spam@. In Hamburg werden solche Dinge gelöscht. Allerdings stellt sich die Frage, wie man Studies erreicht, wenn man wirklich was interessantes verteilen will? In Dresden kann man sich in einen Newsletter eintragen. Außerdem moderiert das Rektorat Studi-Mails. Leipzig geht in die Erstivorlesungen, sodass sich jeder mit seiner favorisierten Adresse auf einen Infoverteiler schreibt.

Wie erreicht man Studis bei wichtigen Infos? In Konstanz gibts nen Studi-Verteiler. In Hamburg muss man 3 verschiedene Adressen abrufen. Es scheint Leute zu geben, die sich keine Weiterleitung/Zusammeführung einrichten (können). In Marburg gibt es eine bebilderte Anleitung, wie man sich auf ne Mailingliste einträgt. Marburg hat sich explizit dagegen entschieden, an Studis zu schreiben. An LMU muss man sich, bevor man den Uni-Account hat, für Ersti-Programm online anmelden. Daher hat die LMU auch die anderen Mailadressen. Problem: Datenschutzrechtlich bedenklich? Ist es opt-in oder opt-out? FSen gelten als Privat, was Recht betrifft. TU Berlin hat das ähnlich wie Uni Konstanz.

KIT: Besteht Interesse, eine Mailingliste "Fachschafts-Admins" einzurichten? Der Zapf-Verteiler ist zu groß für solche Probleme. Meinungsbild sehr positiv aufgenommen. Ein solcher Verteiler wird eingerichtet. Da Zapf-Verteiler auf TU Berlin läuft, wird der auch dort eingerichtet. Name: Zapf-FS-IT oder so. Die TU Berlin beschließt den tatsächlichen Namen. Auf dem Plenum wird das verkündet.

Zusammenfassung