FAQ Webdienste

Laden Sie sich das entsprechende Formular zur Beantragung oder Verwaltung von Webauftritten herunter, füllen Sie es aus und senden es uns eingescannt per E-Mail an webmaster@fau.de oder per Hauspost zu.

Sie haben hier zwei Möglichkeiten:

Eine RRZE-CMS-Instanz

Hier bekommen Sie den Rundum-Service: Auf unserer Multisite-Instanz legen wir für Sie eine WordPress-Installation an, die von uns ausgewählte Plugins enthält, die Sie aktivieren können.

Der Vorteil für Sie: Sie brauchen sich als Webmaster nur noch um die Inhalte zu kümmern, denn wir halten WordPress und die Plugins auf dem neuesten Stand und sorgen so dafür, dass Hacker keine Chance haben. Die Konditionen hierfür finden Sie auf den Seiten des RRZE.

Pro & Contra:

Webhosting

Hier stellen wir Ihnen den Speicherplatz zur Verfügung, die Installation Ihres Webauftritts und die Pflege übernehmen Sie. Auch hierfür finden Sie die Konditionen auf den Seiten des RRZE.

Wenn Sie sich für diese Möglichkeit entscheiden, können Sie das von Ihnen gewählte Theme aus GitHub herunterladen und selbst installieren. Sie können in diesem Fall entscheiden, ob Sie lieber den Webbaukasten nutzen möchten oder WordPress – die Installation der jeweiligen Basis bleibt ebenfalls Ihnen überlassen.

Pro & Contra:

Auf der Multisite-Instanz können wir keine zusätzlichen Anwendungen hosten. Wenn Sie aber Ihre Anwendung auf einem eigenen Ort hosten und entsprechend pflegen, spricht nichts dagegen, sie innerhalb des Angebots auf unserer Multisite-Instanz zu verlinken oder einzubinden.

Alternativ ertüchtigen Sie die Anwendung um eine oEmbed-Schnittstelle. In diesem Fall können Inhalte der Webanwendung auch in CMS-Webauftritten angezeigt werden. Näheres hierzu lesen Sie unter dem Plugin FAU oEmbed.

Auf der Multisite-Instanz ist das leider nicht möglich. Wenn Sie nur Webhosting bei uns buchen und die Pflege und Aktualisierung des Themes und der Plugins selbst übernehmen, können Sie das tun; einen Support dafür können wir nicht leisten.

Falls Sie ein eigenes Plugin entwickeln und einreichen wollen, lesen Sie dazu unsere Vorgaben.

Die Umstellung eines Webauftritts auf ein neues Design und ein neues System, ein sogenannter Relaunch, kostet immer Zeit. Alte Inhalte müssen gesichtet und unter Umständen gleich erneuert werden. Arbeitet man mit visuellen Informationen, um die Inhalte darzustellen, müssen diese möglicherweise auch gesondert aufbereitet werden. Zudem bedeutet ein neues Design üblicherweise auch, dass man die Navigation des Webauftritts ändert.
Allen Relaunches gemeinsam ist jedoch die Anforderung, dass während der Umstellungsphase der bisherige Webauftritt nicht einfach abgeschaltet werden kann.

Wir gehen daher wie folgt vor:

1. Zunächst benötigen wir einen belegbaren Auftrag.
   (Dieser muss in schriftlicher Form erfolgen: Als E-Mail reicht es, wenn diese entweder vom Webmaster oder dem Verantwortlichen des bestehenden Webauftritts über dessen FAU-Mailadresse kommt. Ansonsten muss das Standardformular für die Beantragung von Webauftritten verwendet werden, bei dem die Unterschriften von Webmaster und Verantwortlichem vorhanden sein müssen. Außerdem sollte dort das Kreuz bei „CMS-Instanz“ gesetzt sein. Domainname und vorhandene Webmasterkennung bitte hinzufügen und oben „Änderung“ angeben).
2. Nach Einrichtung der neuen Instanz durch das RRZE erhält der eingetragene Webmaster von uns eine E-Mail, in der angegeben ist, wie der Zugriff auf die neue Instanz erfolgt. Hierbei wird bei der täglichen Bearbeitung nicht mehr die Webmasterkennung verwendet, sondern die eigene IdM-Kennung. Der eingetragene Webmaster wird mit der Rolle Administrator in der CMS-Instanz eingetragen.
   Die Webmasterkennung wird nur noch zu technischen Zwecken als Absender von E-Mails aus der Instanz verwendet. Die Mailbox der Webmasterkennung kann weiterhin genutzt werden.
3. Nach Bereitstellung der CMS-Instanz und dem erfolgreichen Login durch den Webmaster kann dieser beginnen, Inhalte vom alten Webauftritt in den neuen zu übertragen.
   Zuvor sollte er jedoch den Webauftritt konfigurieren:
   1. Unter dem Punkt „Design“ kann das gewünschte Webdesign ausgewählt werden. Dieses ist zu aktivieren und danach anzupassen (ggf. eigene Logos einstellen, den Namen der Einrichtung eingeben, etc.). Eine genaue Beschreibung hierzu findet sich in der Dokumentation unter wordpress.rrze.fau.de .
   2. Wenn weitere Redakteure oder andere Benutzer im System arbeiten sollen, können sie unter dem Punkt „Benutzer“ eingetragen werden.
   3. Falls besondere Plugins verwendet werden sollen, kann man diese unter dem Punkt „Plugins“ aktivieren. Tun Sie dies jedoch nur, wenn Sie die Plugins tatsächlich brauchen. Aktivieren Sie nicht einfach alles, nur weil man es später ja mal nutzen könnte!
   4. Handelt es sich bei der bisherigen Präsenz ebenfalls um eine WordPress-Installation, kann die Import-Funktion zur Übertragung der alten Inhalte verwendet werden.
4. Die eigentliche Arbeit erfolgt nun: Seiten müssen neu angelegt werden und gegebenenfalls via Copy&Paste vom alten in den neuen Webauftritt kopiert werden. Zudem müssen diese Seiten auch einem oder mehreren Menüs zugeordnet werden, damit sie auch gefunden werden können.
   Auch hier sei auf die umfangreiche Dokumentation verwiesen.
5. ist der Webauftritt aus Ihrer Sicht „fertig“, teilen Sie dem Webteam des RRZE mit, wann Sie die finale Umstellung wünschen. Das RRZE-Webteam wird dann den alten Domainnamen auf die CMS-Instanz umschreiben. Nach außen hin sieht das dann so aus, als ob Sie zu dem Zeitpunkt relauncht hätten.
   Bitte achten Sie dabei darauf, dass Sie ab dem Relaunch-Zeitpunkt Suchmaschinen (wieder) erlauben, die Seite zu indizieren. Oft wird für die Umstellungsphase den Suchmaschinen verboten, die Instanz zu indizieren. (Einstellbar unter dem Punkt „Einstellungen“ -> „Lesen“). Dieses Verbot sollte bei der Veröffentlichung des neuen Auftritts natürlich aufgehoben werden.

Hinweise:

Bei der WordPress-Instanz handelt es sich um ein eigenes Angebot für das Hosting von Webauftritten. Im Unterschied zum Webspace-Angebot hat es in Teilen auch etwas andere Konditionen. Insbesondere ist zu beachten:

• Die Kostenpauschale für eine CMS-Instanz mit 1 GB Speicherplatz beträgt 10,- Euro pro Monat (zum Vergleich: Der bisherige Webspace kostet 2,50 Euro pro Monat zzgl. Kosten für optionale Datenbanken).
• Bei der CMS-Instanz wird dafür die Betreuung des WordPress-Systems durch das RRZE übernommen. Das RRZE stellt eine Liste von geeigneten Plugins und Themes bereit, die auch gewartet und aktuell gehalten werden.  Dies bedeutet im Gegenzug jedoch auch, dass Kunden der CMS-Instanz keine Möglichkeit haben, eigene Plugins oder Themes zu installieren.  Auf Anfrage an das RRZE können nur solche Plugins und Themes bereitgestellt werden, die durch Entwickler aktuell gehalten und durch das RRZE dauerhaft wartbar sind.
  (Änderungs- oder Erweiterungswünsche an den Themes werden jedoch gern entgegen genommen. Verwenden Sie hierzu auch das zugehörige GitHub-Projekt).
• Eine Änderung der CSS- oder JavaScript-Anweisungen der angebotenen Themes ist nicht möglich.
• Ein Zugang via SFTP oder SSH zu den Dateien des Webauftritts ist bei den CMS-Instanzen nicht möglich.
• Eine kostenfreie Einrichtung von Testauftritten auf der CMS-Instanz ist nicht möglich. Während der Umstellungsphase sind zwei Webauftritte in Betrieb. Diese müssen daher auch beide in Rechnung gestellt werden. Kann eine Umstellung vor Monatsende abgeschlossen werden, entfallen die Kosten des dann deaktivierten alten Webspace-Angebotes für den Monat.
• Bei der CMS-Instanz kann es pro Webauftritt nur einen sichtbaren Domainnamen geben. Alle anderen Domainnamen (Alias-Adressen), die ein Webauftritt möglicherweise hat, werden hierauf umgeleitet. Der sichtbare Domainname muss den gültigen Domainnamensregeln für Web folgen. Ein Bestandsschutz für alte Domainnamen, die diesen Regeln nicht folgen, wird auf diesem neuen Dienst nicht gewährt. Solche Domains erhalten daher einen neuen, regelkonformen Namen auf den umgeleitet wird.
• Wir empfehlen die Nutzung von CMS nur bei solchen Einrichtungen und Webseiten, bei denen mindestens zwei verschiedene Personen an der Seite arbeiten. Für kleine Webauftritte, die nur ab und zu von einer Person bedient werden, kann eine Nutzung des normalen Webspace-Angebotes mit dem eigenen, bevorzugten und gewohnten Editor sinnvoller sein.
  Wenn Sie sich unklar darüber sind, ob für einen Webauftritt besser die CMS-Instanz oder der selbst verwaltete Webspace verwendet werden sollte, lassen Sie sich vor einer Entscheidung von uns ergebnisoffen beraten.

Inhalte von Online-Diensten wie YouTube, SlideShare oder Flickr aber auch von selbst entwickelten Anwendungen aus dem Bereich der FAU können mittels der oEmbed-Schnittstelle in Webseiten „embedded“ werden.

Ist gewünscht, dass FAU-Dienste oder an Einrichtungen entwickelte Speziallösungen und Anwendungen in den Webauftritten integriert werden, müssen die jeweiligen Entwickler „ihre“ Anwendungen lediglich um eine oEmbed-Schnittstelle ertüchtigen und danach dem RRZE-Webteam mitteilen.  Sollte die Schnittstelle fehlerfrei und standardkonform funktionieren sein und ein Ansprechpartner auf Anwendungsseite vorhanden sein, wird die Quelle in der Liste der unterstützten oEmbed-Dienste in dem Plugin aufgenommen und somit für alle CMS-Anwender nutzbar gemacht.

Jeder Empfänger von Verteilermailadressen kann bei einer Maillast oder zur Organisation seines eigenes Postfaches jederzeit eigene Mailfilter einrichten. Nutzer von Exchange können über die automatische Verarbeitung solche Mails ganz einfach in ein eigenen Ordner verschieben oder andere Aktionen ausführen lassen.

Hinsichtlich Webauftritte gibt es die sowohl vertraglich, als auch über die UL festgelegte Regelung, dass jederzeit ein administrativer Ansprechpartner erreichbar sein muss. Die automatisch eingerichtete Verteilermailadresse webmaster-SUBDOMAIN@fau.de gewährleistet dies, da sie automatisch an alle Personen geht, die bei einem CMS die Rolle Administrator tragen (und durch diese Rolle Verfügungsgewalt und unbeschränkte Änderungsmöglichkeiten über den gesamte Webauftritt haben). Wenn Personen diese Rolle nicht tragen wollen oder sollen, ist die Lösung schlicht die Zuteilung einer anderen Rolle. Beispielsweise die Rolle Redakteur, mit der ebenfalls alle Inhalte veröffentlicht werden können. Auch für diese Mails ist Seitens der Empfänger eine individuelle Filterung möglich und auch sinnvoll.

Werden Mails über ein Skript oder ein Plugin von einer Domain mit der automatischen Mailadresse webmaster-SUBDOMAIN@fau.de gesendet werden, bietet dies den Vorteil, dass im Falle eines Fehlers eindeutig und schnell erkennbar ist, von wlecher Domain diese Mails ausgingen. Dies wäre bei anderen Mailadressen nicht der Fall.

– Wenn ein Webserver, wie bspw. ein CMS Server, eine Mail mit falschen und nicht validierbaren Absendemailadressen sendet, kann es geschehen, dass der empfangene Mailserver bzw. der zugehörige Provider, unsere Server und damit alle Mailadressen der FAU pauschal temporär oder dauerhaft blockt; oder noch schlimmer, auf eine der gängigen Blockfilter setzt, die von weiteren Providern genutzt werden.

– Wird als Absender eine Mailadresse einer fremden Domain eingetragen, führt dies fast zwangsläufig zu einer Abweisung der Mail oder im schlimmsten Fall zu einer Blockade des sendenden Servers und dessen Maildomain. Also in unserem Fall von @fau.de .

– Ebenso ist der Massenversand von Mails problematisch und kann ebenfalls dazu führen, dass die Mailserver der FAU auf entsprechende Block-Listen landen. Daher sind die Mailserver so konfiguriert, dass sie von den Webservern nur eine gewisse Anzahl von Mails pro Stunde akzeptieren und versenden. Grundsätzlich sollten daher auch niemals Massenmails (d.h. mehrere Dutzend oder Hunderte Adressaten) ohne Rücksprache und ohne die Dienste der Postmaster (nicht die Dienste des Webteams) versendet werden.

– Jeder Empfänger eine Mail aus der FAU muss die Möglichkeit haben, den Absender oder involvierte Personen für Rückfragen zu erreichen und zu identifizieren. Somit ist eine Discard-Absenderadresse eher ungeeignet, da dies eine Barriere für den Empfänger darstellt. Zudem ist zu beachten, daß eine eher unpersönlich gestaltete Mail mit anonymer Absenderadresse ebenfalls Gefahr läuft, als Spam oder Phishing einsortiert zu werden.

– Zu beachten ist der Unterschied zu weiteren Angaben einer Mail, die man hier nutzen kann und sollte: So zum Beispiel Reply-To und Errors-To.  Diese können dazu genutzt werden, um Mails im Fehlerfalle zu kanalisieren.

– FAU-Mailadressen von Personen sind problematisch, da diese nicht validiert oder zertifiziert werden können und es damit die konkrete Gefahr gibt, dass Mails in den Namen von Personen gesendet werden, die davon nichts wissen.

– Für Mails, die automatisiert von Webauftritten ausgehen sollen, sollte daher entweder die automatisch erstellte Verteilermailadresse webmaster-SUBDOMAIN@fau.de verwendet werden oder eine eigens eingerichtete Verteilermailadresse oder eine Funktionsadresse.

Die E-Mail-Server der FAU nehmen nur gültige Mailadressen als Absender an. Insbesondere von den Webservern, da Webserver als Angriffsziel für Attacken gelten um sie für den Spam- und Phishingmail-Versand zu missbrauchen.

Jede Webseite auf unserem CMS hat Ihre eigene Funktionsadresse im Format webmaster-<>@fau.de.

Diese Funktionsadresse sendet automatisch Hinweise und Informationen zur eigenen Webseite an alle Administratoren.
Wenn Sie also eine E-Mail von dieser Funktionsadresse erhalten, dann liegt es vermutlich daran, dass Sie auf der genannten Seite noch als AdministratorIn hinterlegt sind.

Der jeweils zuständige Webmaster kann Sie in diesem Fall aus der Benutzerverwaltung entfernen.
Alternativ können Sie sich auch an webmaster@fau.de wenden, damit wir Ihren Zugang von der Webseite entfernen.

Die Benutzerverwaltung kann über Dashboard | Benutzer | Alle Benutzer aufgerufen werden.

Im übrigen raten wir deutlich davon ab, allen Bearbeitern einer Website die vollen Administratorrechte zu geben. Die normale Rolle als Redakteur ist vollkommen ausreichend, wenn keine Änderungen am Design der Webseite notwendig sind.

Die Zugriffe auf Webangebote, die am RRZE gehostet werden, sind aus dem Netz der Universität auf statistiken.rrze.fau.de abrufbar. Die Statistik wird mittels der Software webalizer erstellt und basiert auf die anonymisierten Zugriffe auf die Webserver.

In der Statistik werden unterschiedliche Begriffe verwendet:

• „Hits“, „Anfragen“, „Gesamtabrufe“
  
  Die Begriffe „Hits“, „Anfragen“, „Gesamtabrufe“ und deren anderssprachige Formen stehen fuer die Summe der Anfragen auf einer Domain. Sie stehen aber nicht allein für die Summe der Anfragen fuer eine Seite. Genau gibt die Zahl an, wie oft Dateien innerhalb der Domain auf dem sich die Zahl bezieht, abgerufen wurden. Diese Dateien bestehen jedoch nicht nur aus den HTML-Dateien, sondern auch aus den in diesen referenzierten Bildern, Stylesheet-Dateien und Skript-Aufrufe.
  Beispiel: Die Seite index.html enthält 3 Bilder und eine Referenz auf eine Stylesheet-Datei. Wird diese Seite aufgerufen werden in der Logdatei 5 Hits vermerkt:
  
  1 Hit fuer die Datei index.html
  3 Hits fuer jeweils ein Bild
  1 Hit fuer die Stylesheet-Datei
  
  Die Zahl der „Hits“ in einer Statistik einer Domain kann nicht durch eine andere Abrufszahl überschritten werden.
• „Seiten“, „Seitenabrufe“, „Pageviews“, „Page Impressions“
  
  Diese Begriffe beinhalten die Zahl der Abrufe auf Dokumentseiten _exklusive_ Referenzen auf Bilder, Stylesheet-Dateien oder Skript-Abrufen. Ausserdem werden zusätzlich nur Abrufe der Seiten gezählt, wenn diese vollstaendig vom Webserver geladen wurden. (Dies bedeutet, dass Seiten, die aus einem Proxy -also einem Zwischenspeicher für Webdokumente- geladen wurden, nicht mitgezählt wurden.)
  Beispiel: Die Seite index.html enthält 3 Bilder und eine Referenz auf eine Stylesheet-Datei. Wird diese Seite aufgerufen werden in der Logdatei 5 Hits vermerkt:
  
  1 Hit fuer die Datei index.html
  3 Hits fuer jeweils ein Bild
  1 Hit fuer die Stylesheet-Datei
  
  Die Zahl der „Pageviews“, bzw. der „Seiten“ ist jedoch nur 1. Für den Fall, daß ein Proxy die Seite gespeichert hatte bei dem der Browser des Benutzers die Seite abgerufen hat, ist die Zahl der Seitenabrufe sogar nur 0.
  
  Die Zahl der „Pageviews“ kann niemals größer als die der „Hits“ sein.
• „Dateien“, „Files“
  
  Diese Zahl gibt an, wieviele Dateien erfolgreich von der Domain geladen wurden. Dateien sind alle Dokumente auf der Webseite, inkl. Bilder und Skripten.
  Der Unterschied zur Zahl der „Anfragen“/“Hits“ besteht darin, dass hier die Abrufe, bei denen der Seiteninhalt über einen Proxy geladen wurde, nicht mitgezählt werden. D.h.: ‚Zahl der „Hits“‚ – ‚Zahl der „Dateien“‚ = ‚Zahl der Seiten, die über einen Proxy abgerufen wurden.‘ Die Zahl der „Dateien“ ist meist nur für Interesse fuer den Webmaster, da diese Einfluss auf die Größe des Datentransfers hat.
  
  Die Zahl der „Dateien“ kann niemals größer als die der „Hits“ sein. Sie ist größer als die Zahl der „Seitenabrufe“
• „Besuche“, „Sessions“, „Sitzungen“
  
  Diese Zahl beschreibt wieviele Besucher innerhalb eines festgelegten Zeitintervals Seiten, d.h. richtige Webseiten (die Grafiken etc nicht mitgezählt), vom Webserver erfolgreich abgerufen haben. Üblicherweise wird ein Wert von 90 Sekunden für den Zeitinterval benutzt.
  
  Die Zahl der Seitenabrufe geteilt durch die Zahl der Besucher ergibt dabei die Zahl der Seiten, die ein Besucher auf der Seite betrachtet. (Portals und Suchmaschinen werden in der Regel eine kleinere Zahl haben, als inhaltlich bezogene Seiten, die nicht sofort auf externe Angebote verweisen.)
  Kurz gesagt: Je größer der Wert „Seitenabrufe“/“Besuche“ ist, je laenger bleiben die Besucher auf der Seite.
  
  Die Zahl der „Besuche“ kann niemals größer als die der „Pageviews“ sein.
• „Rechner“, „Hosts“
  
  Diese Zahl gibt an, wieviele verschiedene Rechner innerhalb eines Zeitintervalles „Seitenabrufe“ tätigten. (Bitte beachten Sie hierbei, dass Benutzer der großen Onlinedienste meist unter einem einzigen Rechner identifiziert werden.)
  Interessant ist diese Zahl dadurch, dass sie zusammen mit der Zahl der „Besuche“ eine Abschätzung zuläßt, wie oft ein spezieller Besucher zu der Seite zurückkommt, d.h. wie interessant das auch über längere Zeiträume hinweg ist.
  
  Die Zahl der „Rechner“ kann niemals größer als die der „Besuche“ sein.
  

Die statistische Werte halten dabei folgende Reihenfolge ein:
#“Hits“ >= #“Dateien“ >= #“Seiten“ >= #“Besuche“ >= #“Rechner“

(wobei das Zeichen ‚#‘ sich auf die Zahl bezieht.)

Unabhaengig von diesen Zahlen wird in den meisten Statistiken auch noch die Zahl der übertragenen kBytes angegeben. Diese Zahl bezieht sich in der Regel auf den Datentransfer aller Dateien innerhalb des Zeitintervals.
Der Wert #“Dateien“ / #’kBytes‘ gibt dabei die durchschnittliche Dateigröße pro Datei an.

Ja, Teile der Webstatistiken, die mit webalizer erstellt werden, können auch direkt abgerufen werden und danach mit einer geeigneten Software analysiert oder anders dargestellt werden.

Die folgenden Dateien liegen mit den entsprechenden Datumsformat (YYYY = Jahreszahl, MM = zweistellige Monatszahl, DD = zweistellige Tageszahl) jeweils in dem Statistik-Ordner des Webauftritts unter statistiken.rrze.fau.de/webauftritte/logs/Webauftritt/ .

Bitte beachten Sie, dass der Zugriff nur für Rechner aus den Netzen der Universität möglich ist.

Folgende Dateien stehen im Verzeichnis im CSV- bzw im XML-Format zur Verfügung:

• Useragents:  agent_YYYYMM.tab
• Tagesdelta bei URL-Zugriffen: url_delta_YYYYMMDD.tab
• Referer: ref_YYYYMM.tab
• Suchbegriffe: search_YYYYMM.tab
• Usage: usage_YYYYMM.xml
• Site: site_YYYYMM.tab
• URL-Zugriffe: url_YYYYMM.tab
• Fehler: err_YYYYMM.tab
• Jahreszahlen: webalizer.hist

Der API Key kann online über die Dokumentation von api.fau.de beantragt werden:

Dokumentation: https://api.fau.de/doc

Für FAU-Studium-Fachanteile wird die Berechtigung auf den Endpoint edu in der Version 1 benötigt.