WiSe13 AK FachschaftsIT: Unterschied zwischen den Versionen
Keine Bearbeitungszusammenfassung |
Keine Bearbeitungszusammenfassung |
||
Zeile 75: | Zeile 75: | ||
* Drucker (Leasing oder eigener Drucker?) | * Drucker (Leasing oder eigener Drucker?) | ||
* ... | * ... | ||
== Mailingliste == | |||
Die Adresse der Mailingliste ist: zapfadmins@lists.physik.tu-berlin.de | |||
Eintragen könnt ihr euch [https://lists.physik.tu-berlin.de/mailman/listinfo/zapfadmins HIER] | |||
== Protokoll == | == Protokoll == |
Version vom 16. November 2013, 12:32 Uhr
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 (Flimen die Vorlesungen), verwenden Ansible
TU Graz: Wird von nicht selbst administriert, Plone wird verwendet,
Leipzig: hoffnungslos veraltete Homepage, haben jVerteiler, 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, Mailingsliste, 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 über 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 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 PW 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, 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. Fragt, wie man anderen Leuten das beibringen kann. Daher auch fast nie aktuell. Der Rechner wird als Datenablage verwendet. Mailing läuft über Physik-Rechenzentrum. 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. 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, Infos helfen sehr, neue Leute haben direkt alle wichtigen Infos. Rechenzentrum kümmert sich um Mailingliste etc. Vorlesungsumfrage: FS hat ein Skript gebastelt, jeder FSler kann sich anmelden, Bögen werden eingelesen. Am Ende kommt Latex-Skript aus 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 VS ändern. Haben Forum eingerichtet, aber etwas unübersichtlich bei mehreren gleichzeitigen Themen.
Erstes Topic: Dateiaustausch/Ordnerstruktur
LMU hat einmal einen Cut gemacht, sich hingesetzt, sortiert und aufgeräumt und seitdem läuft es gut. 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: Ordner für spezielle Veranstaltungen im Voraus anlegen, damit die komplette Arbeit dort sofort abgelegt werden kann.
Marburg: hab 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.
TU Berlin: jedes halbe Jahr wird aufgeräumt, die Leute halten sich eh nicht dran.
LMU: Nicht jeder darf Ordner anlegen, sodass gar nicht so viele Ordner entstanden sind (Erziehung!). Als Maßnahme, um sich mit der neuen Struktur vertraut zu machen. Größtes Problem: Dateistrukturen 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 hoch (sehr wohl große Datenmengen). Das klappt alles sehr gut, das Wiki läuft da super.
Patrick: Nerds versus Browser-Struktur im Wiki. Nerds sind unzufrieden, Normalus 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: 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. Aachen: Es gibt Tracker-Indizes, mit denen man für jedes Dateiformat eine Freitextsuche machen kann.
TOP 2: Admin-Nachwuchs Wie kann eine Übergabe, gerade einer etwas größeren Infrastruktur stattfinden?
Dresden hat selbes Problem. Empfielt eine Screen-Shot-Anleitung, die zwar sehr aufwendig, aber hilfreich ist.
Würzburg: wurde ins kalte Wasser geschmissen, aber alter Admin konnte angerufen werden. Viel Zeit investiert, aber lerning-by-doing war sehr effizient. Erreichbarkeit der alten Admins sicherstellen!
Marburg: Hat nicht nur einen Experten, haben zur Zeit 2 Leute, damit Infos nicht verloren gehen. 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 zu übergeben.
Dresden: neue Generation arbeitet sich selber ein. Es kümmern sich viele verschiedene Leute darum. Wie kann man eine komplexe Struktur sinnvoll übergeben?
TOP 3: Wie kann man andere aktive FSler 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 "es gibt ja 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: Welche Möglichkeiten gibt es, online fachschaftsintern zu kommunizieren?
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.