Allgemeine Hinweise und Neuigkeiten zum Webdienst

In den letzten Monaten kam es zu einigen Neuerungen zu den Webdienstleistungen. Da einige davon nicht allen Webmastern bekannt waren, möchte ich die Gelegenheit nutzen um einige Hinweise und Informationen geben, die auch für andere interessant sein könnten.

1. Zusätzlicher Domainname mit „fau.de“.
Alle beim RRZE-Webteam verwalteten Webauftritte, die mit „uni-erlangen.de“ enden, können seit April auch mit der Endung „fau.de“ aufgerufen werden. Zusätzlich sind auch die Namen mit und ohne dem „www.“ am Anfang eingetragen.

Dies bedeutet, daß wenn Sie einen Webauftritt mit den Namen
www.meinlehrstuhl.fakultat.uni-erlangen.de
haben, dieser Webauftritt nunmehr auch unter den folgenden Adressen abrufbar ist:
meinlehrstuhl.fakultat.uni-erlangen.de
www.meinlehrstuhl.fakultat.fau.de
meinlehrstuhl.fakultat.fau.de

Welche Namensform Sie verwenden, ist -solange es keine verbindlichen Regelungen seitens der Uni, ihrer Fakultät oder dem Department gibt- Ihnen selbst überlassen.

Sie sollten sich aber bewusst sein, daß alle Formen Vor- und Nachteile haben:
So ist die kurze Form möglicherweise bei Vorträgen und Präsentationen geeigneter, dafür ist sie im internationalen Kontext jedoch verwechselbar mit den Webauftritten der Florida Atlanta Universität (die sich seit Jahrzenten bereits ebenfalls mit „FAU“ kennzeichnete und die Domains fau.edu und fau.com innehat) und sie hat im Sinne der Suchmaschinenoptimierung schlechtere Chancen zu einem guten Ranking bei Suchmaschinenausgaben als die lange Form.
Die lange Form wiederum sorgt durch das Vorhandensein von Schlüsselworten im Namen für ein besseres Suchmaschinenranking, ist aber dafür eben nunmmal lang.
Die Formen ohne „www.“ sind wiederum kürzer, dafür allerdings sind sie beim Lesen in einem Textabsatz nicht so intuitiv erfassbar und werden von Textverarbeitungsprogrammen nicht automatisch erkannt.

2. Das Webteam-Blog
Jegliche Änderung, Ankündigung oder Planung zu Webdienstleistungen können Sie seit mehreren Jahren schon auf dem Webteam-Blog ablesen. Sie finden es unter der Adresse
https://blogs.fau.de/webworking

Die Beiträge können ebenfalls via RSS-Feed, als auch über den Twitterkanal
http://twitter.com/RRZEWebteam
abbonniert werden.

Wir bitten eindringlich darum, daß Webmaster von Webauftritten der FAU dieses Blog regelmässig beobachten, damit Sie bei geplanten Serverwartungen oder anderen wichtigen Information zu Webauftritten informiert sind.
Es ist auch möglich, sich beim Abo via RSS allein auf Meldungen der Kategorie „Webdienst“ zu beschränken um nur Meldungen zu betriebsbedingten Dingen zu erhalten.

Ganz allgemein möchte ich darauf hinweisen, daß der Blogdienst nach Einführung einer neuer Software (WordPress) sich in den letzten Monaten als am häufigsten benutzter Webdienst der Universität etablierte.
Sehr viele Einrichtungen setzen das System erfolgreich ein um aktuelle Meldungen und Nachrichten zu publizieren. Aufgrund der leichten Bedienbarkeit, die keinerlei HTML- Kenntnisse verlangt, fand es in kurzer Zeit viele Anhänger.

3. Planungen zur Verbesserung der Webdienstleistungen
Erstmal nur kurze Vorabinformationen:

  • Performance
    Die bislang in Benutzung befindliche Hardware ist den stetig wachsenden Anforderungen nicht mehr gewachsen und muss durch neue Geräte ersetzt werden. Hierzu werden wir noch in diesem Jahr entsprechende „HBFG-Anträge“ erstellen, um die notwendige Finanzierung sicherzustellen.
  • „Webbaukasten II“
    Das im Jahr 2006 initierte und 2009 in den „Regelbetrieb“ gegangene Projekt um einen allgemeinen Webbaukasten war überaus erfolgreich. Mehr als 50% aller Webauftritte der Uni nutzen es bereits, obgleich sich der Webbaukasten nur als optionales Angebot versteht.
    Wir planen den Webbaukasten in diesem Jahr weiter zu optimieren und auch um eine größere CMS-Option (zusätzlich zum bereits vorhandenen Mini-CMS „NavEditor“) zu ergänzen.
    (So denn der in Vorbereitung befindliche Antrag genehmigt wird).

4. Statistiken
Die Zugriffsstatistiken aller bei uns gehosteten Webauftritte können über folgender Adresse abgerufen und verglichen werden:
http://www.statistiken.rrze.uni-erlangen.de

Die Statistiken sind tagesgenau. Aus Sicherheitsgründen können die Statistiken nur von Rechnern aus dem Uninetz abgerufen werden.
In Bezug auf die Rechneradressen von Besuchern von Webauftritten wurden die Statistiken gemäß den Empfehlungen von Datenschützern „anonymisiert“.

5. HTTPS – Verschlüsselung für alle Webauftritte
Seit Ende April sind alle Webauftritte auch mit einem selbst signierten SSL-Zertifikat versehen. Vertrauliche Kommunikation kann daher auch via https:// an den Webauftritt verschickt werden.
Dieser Zertifikat ist ein durch das RRZE Webteam signiertes Zertifikat.
Da dieses wahrscheinlich ihrem Browser noch nicht bekannt ist, wird es in der Regel Warnungen vom Browser geben, bei der gefragt wird, ob der Besucher der Seite dem Aussteller des Zertifikats (also dem RRZE Webteam) vertrauen möchte. Ob Sie uns vertrauen können, müssen Sie selbst entscheiden 🙂
An der Sicherheit der Verschlüsselung ändert dies jedoch nichts.

Falls dennoch ein akkreditiertes Zertifikat gewünscht wird, kann dieses von uns nachträglich ergänzt werden. Aufgrund von formal notwendigen Schritten , die nicht vollständig automatisch ausgeführt werden können, ist dies jedoch mit einem Unkostenbeitrag verbunden.

Bugfix Feedimport-Skript vom 11. April (Updated)

In der letzten Version des Feedimport-Skriptes vom 11. April, die vorallem Performanceverbesserungen mit sich bringt, befand sich ein kritischer Fehler.
Leider ist der Fehler ist kürzlich bemerkt wurden.
Der Fehler machte sich dadurch bemerkbar, daß der Index der Beiträge falsch war und teilweise Artikel nicht korrekt verlinkt wurden.
Der Fehler wurde gerade eben behoben und die neuen Dateien zum Download bereitgestellt.

Aktualisierung des Skriptes durchführen

Die neue Version kann wie üblich über die ZIP-Files aus dem Downloadbereich oder über eine Kopie aus dem Musterverzeichnis /proj/websource/docs/muster/www.defaultwebauftritt.uni-erlangen.de/cgi-bin/feeds geholt werden um sie in den eigenen Webauftritt zu integrieren.
Neu sind die beiden Dateien feedimport.pl und Feedimport.pm.

Ergänzung:
Leider haben einige Webmaster Probleme darin, Skripten zu aktualisieren oder sich sogar via (s)FTP auf dem Server anzumelden um Dateien hochzuladen (trotz vorhandener Dokumentation).
Wer bei dem Feedimport an dieser Stelle Probleme hat, kann sich gern an uns vom Webteam wenden. (Bitte per E-Mail an webmaster@rrze.uni-erlangen.de). Wir können den Update auch für Sie durchführen.

Falls das Skript zu langsam für Sie ist, gibt es ausserdem die Möglichkeit, die Ausgabeseiten „schnell“ zu machen, indem diese statisch generiert werden. So kann man auf der Seite der der Graduiertenschule sehen, wie schnell die Seite ausgegeben werden kann, wenn man alles entsprechend konfiguriert und einstellt.

Cache Control bei dynamischen Webauftritten

Mit dem neuen Apache 2.2 haben wir zur Steigerung der Performance das Cache-Modul von Apache aktiviert („Mem Cache“).

Dieses Modul bewirkt, daß Webseiten, darunter auch dynamisch generierte Seiten, vom Webserver zwischengespeichert werden und beim nächsten Request wieder ausgeliefert werden, ohne daß dann die Seite nochmals von vorne „gebaut“ werden muss. Dadurch ergibt sich teilweise ein merkbarer Performancegewinn.
Dem Voraus gingen verschiedene Tests, über die ich im letzten Jahr bereits in diesem Blog berichtete. Vgl: Vorbereitungen zum Umstieg auf den Webcluster: Performance

Leider mussten wir nun feststellen, daß es doch Probleme gibt:  Bei Webangeboten, die verschiedene Inhalte immer vom selben Skript liefern (z.b. immer von einer „index.php“), kann es passieren, daß zunächst der falsche Content geliefert wird und der richtige erst dann kommt, wenn man  die Seite nochmal explizit neu anforderte.

Eine genauere Analyse der Vorgänge zeigte zwei mögliche Ursachen, bzw Lösungen:

  • Das Skript liefert bei der Generierung der Inhalte bislang keine Antwort-Header, die spezielle Cache-Control-Anweisungen beinhalten. So fehlt beispielsweise eine solche Zeile in den Antwort-Headern:

    Cache-Control: no-cache

    Die Lösung wäre also, daß das Skript um diese oder andere Angaben ergänzt wird.
    Bei einigen CMS, wie beispielswiese bei Typo3, gibt es entsprechende Funktionen und auch Extensions, die dies automatisch setzen.

  • Sollte das Problem nicht über eine Anpassung oder Konfiguration der Skripte lösbar sein, besteht ansonsten die Möglichkeit, daß das Caching für den kompletten Webauftritt oder für einzelne Verzeichnisse daraus serverseitig deaktiviert wird.
    Im dem Fall, daß der Webauftritt auf unseren Webcluster liegt, wird dies das Webteam tun. Wir werden dann in der Konfiguration des Webauftritts die Anweisung 

    CacheDisable  /

    ergänzen.
    Im Webmasterportal kann jeder angemeldete Webmaster über die Ansicht der Konfiguration, unter dem Unterpunkt „VirtualHost-Konfiguration“, nachprüfen, ob und welche Direktiven gesetzt sind und ob diese dabei ist.

Sollten Sie hinsichtlich dieses Themas Unterstützung des Webteams benötigen, setzen Sie sich bitte mit uns in Kontakt.

 

Neues Blogsystem im Testbetrieb

Seit über 5 Jahren betreiben wir auf diesem Server den Blogdienst der Uni Erlangen-Nürnberg.
Dabei wurde die Software Antville verwendet, die sich durch Stabilität und sehr gute Performance auszeichnet.

Wir werden jedoch noch Laufe dieses Sommers auf WordPress Mu wechseln.
Dabei werden alle aktuellen vorhandenen Blogs des Altsystems, inklusive aller Nachrichten und Benutzerollen übernommen.

Alle Benutzer können ab sofort das neue System testen, bzw. sich in der Benutzung des neues Systems einarbeiten.
Es ist abrufbar unter folgender Adresse:
http://www.beta.blogs.uni-erlangen.de/

Alle Blogs wurden in das neue Testsystem übernommen.
Bei öffentlichen Blogs wurden die vorhandenen Artikel mit übernommen. Bei intern gestellten Blogs kann der Import der Altbeiträge über den RSS-Import manuell durch jeden Blogbetreiber selbst vorgenommen werden.
(Der Import der bisherigen Einträge ist ein paar Tage her. Bitte daher nicht wundern.)

Die Adressen der Blogs sind wie bisher, nur das der Domainname auf dem Testsystem natürlich nicht gleich sein kann. Bspw. findet man das Webworking-Blog, welches hier unter http://www.blogs.uni-erlangen.de/webworking ist, auf dem testsystem unter der Adresse http://www.beta.blogs.uni-erlangen.de/webworking.

Testphase und weiteres Vorgehen

Die mit den heutigen Tag offiziell beginnende Testphase wird mindestens 2 Wochen andauern.
Sollten sich keine wesentlichen Probleme ergeben, werden wir nach Ablauf der Zeit ein Datum festlegen, an dem das Altsystem abgeschaltet wird und das neue System die Adresse des alten Systems übernimmt.
An diesen Datum werden wir nochmals ein Reimport aller Einträge aus dem jetzigen Antville-System machen, der dann auch alle Beiträge aus der Testphase entfernt.

Durch das neue System werden sich die Adressen der Blogs nicht bedeutend ändern (sieht man von der Groß- / Kleinschreibung ab). Auch die Adressen der Feeds (auch die der parameterisierten Anwiesungen für den Feedimport in Webseiten) werden gleich bleiben, bzw. sich nur marginal ändern. Alle alten URLs sollten jedoch weiterhin nutzbar sein.

Eine wesentliche Änderung betrifft jedoch die Funktionalität von eigenen Designs:
Es wird im neuen System nicht mehr möglich sein, auf auf Quellcode-Ebene in die Gestaltung der Blogs einzugreifen. Stattdessen erhalten Sie „Widget“-Funktionen mit denen Sie innerhalb von Teilbereichen des Blogs Inhalte plazieren können.
Die generelle Optik der Blogs wird jedoch nur mehr auf Basis einer Auswahl an Designs aus dem Web-Baukasten der Universität möglich sein.

Wir möchten alle Benutzer und alle Tester um regen Feedback bitten.
Entweder an die E-Mailadresse blogs@uni-erlangen.de oder im eigenen Forum zum Blogdienst

Hintergründe zur Abkehr von Antville und dem Wechsel zu WordPress

Leider ist die Software was die Funktionalität angeht „in die Jahre“ gekommen. Heutzutage gängige Funktionen von Blogsystemen werden von Antville nicht bereit gestellt. So zum Beispiele die Verwendung von Tags oder die Nutzung von mehr als einer Kategorie.
Zwar gab es in den letzten Jahren immer wieder Versuche, die Weiterentwicklung von Antville voranzutreiben, jedoch führten diese bis heute zu keinen zufriedenstellenden Ergebnissen.
Wir haben zwar im Webteam lange versucht, eigene Entwicklungen und Verbesserungen an der Software einzubringen, jedoch wurden diese oft nicht berücksichtigt. Auch stellt sich Antville mehr und mehr als Insellösung dar, für die eigene Weiterentwicklungen allein aufgrund des Erlernens der Sprachbasis zu teuer werden.
Ein Wechsel zu dem kommerziellen Clon von Antville (TwoDay von der Firma Knallgrau), welche von der Uni Wien erfolgreich eingesetzt wird und welches auch viele neue Funktionen hat, ist uns aus finanziellen Gründen nicht möglich.

Es musste daher ein neues System gefunden werden, welches alle oder zumindest die meisten Funktionen von Antville erfüllt, zum anderen aber in einer Programmsprache vorliegt, die eine eigene Weiterentwicklung und Pflege leicht macht. Ebenso muss das System leicht zu pflegen und zu betreuen sein und auf Basis von gängigen LAMPP-Systemumgebungen laufen.

Mit einigen Bauchschmerzen haben wir uns letzlich zu WordPress entschieden.
Die Bauchschmerzen liegen im wesentlichen darin, dass WordPress an vielen Stellen im Quellcode sehr unsauber programmiert wurde und es nach wie vor ist. Dies führte und führt zu häufigen Sicherheitsproblemen von WordPress-Versionen, die dann ein zeitlich aufwendiges Eingreifen eines Admins notwendig machen. Auch ist die Performance eines unveränderten WordPress-Systems bei weitem nicht so gut wie die von Antville.
Dennoch führt aufgrund der weiten Verbreitung von WordPress (was eine leichte und gewohnte Bedienung durch die Anwender nach sich zieht), den umfangreichen Erweiterungsmöglichkeiten und der großen Entwicklergemeinde kaum ein Weg an diese Software vorbei.

Tipp zur Performancegewinnung

Webauftritt die mit dem Web-Baukasten der Uni erstellt werden, enthalten mehrere interaktive Skripten. Die Seiten werden während des Aufrufs dynamisch erzeugt.
Zwar sorgen Caches und Proxys bereits dafür, daß bekannte Seiten schnell ausgeliefert werden, jedoch kann die echte neugenerierung einer Seite auf unseren alten Servern (die auch noch nicht loadbalanced sind) doch schon 1.2 Sekunden dauern.

Ein Tipp zur Verbesserung der Performance betrifft solche Webauftritte, bei denen die Zielgruppennavigation (in den Seiten oben) nicht benutzt wird oder sich so gut wie nie ändert.

Die Zielgruppennavigation wird in der SSI-Datei websource/ssi/kopf.shtml definiert.

Dort finden Sie folgenden HTML-Code:

 <div id="hauptmenu">
          <h2 class="skip"><a name="hauptmenumarke" id="hauptmenumarke">Zielgruppennavigation</a></h2>
          <!-- #include virtual="/cgi-bin/navigation/inhalt.pl?type=ziel&noU=1&nodfn=1"  -->
       </div>

Dabei wird bei jedem Laden der Seite das Skript aufgerufen, welches die Navigation aufbaut. Auch in dem Fall, wenn gar keine Zielgruppennavigation definiert ist.

Um hier einen Performancegewinn zu erfahren, gehen Sie folgendermaßen vor:

a) Wenn Sie gar keine Zielgruppennavigation nutzen, löschen Sie einfach die Zeile mit der Include-Anweisung.

b) Wenn Sie eine Zielgruppennavigation haben, dann schreiben Sie die statisch an der Stelle des Includes. Kopieren Sie sich dazu die URI /cgi-bin/navigation/inhalt.pl?type=ziel&noU=1&nodfn=1 und fühen davor ihren DOmainnamen an. Diese Adresse rufen Sie dann im Browser auf.
Die erhalten dann das erzeugte dynamische Menu.
Von diesem kopieren Sie sich den Quellcode, den Sie dann in der websource/ssi/kopf.shtml anstelle der Include-Anweisung einsetzen.