Ein wunderschönes Bild, dass statt mit tausend Worten erklärt, warum das Zusammenarbeiten mit Wiki Zeit spart:

Erfunden hat diese Darstellung Chris Rasmussen von der "US National Geospatial Intelligence Agency", darum das für ungeübte Augen nach US-Militär wirkende Logo...

via Wikinomics-Blog , IsaVisutalisierung

Seit mehr als fünf Jahren (September 2002) betreibe ich meinen Wiki-Server ohne Lesebeschränkungen. Jedermann kann weltweit alle Wikiseiten lesen. Diese Offenheit (Biblionetz:w01882) ist mir wichtig, denn ich bin der Meinung, dass wir bei eLearning immer noch am Anfang stehen und voneinander lernen können sollten. Learning Management Systeme, bei denen ich nicht über den Login-Screen hinaus komme, ermöglichen mir aber kein Lernen an anderen Beispielen.

Die Inhalte dieses Wikiservers sind aber meist nur für Personen interessant und relevant, die den Kontext ihrer Entstehungsgeschichte einordnen können. Wenn Schüler/innen den zweiten Weltkrieg bearbeiten, dann sind ihre Gedanken für sie selbst, die Lehrperson, ihre persönliche Umgebung und andere eLearning-Interessierte relevant, nicht aber für den Rest der Welt. Aus diesem Grund ist es nicht sinnvoll, dass die Seiten dieses Wikiservers von Suchmaschinen gefunden werden. Darum schliesse ich mit der Datei robots.txt von Anfang an alle Suchroboter aus. Die grossen Suchmaschinen wie z.B. Google halten sich an diesen Hinweis und verzichten darauf, Seiten dieses Wikiservers zu indexieren.

Nicht an diesen Hinweis halten sich hingegen Spambots, d.h. bösartige Suchroboter auf der Suche nach E-Mailadressen oder der Möglichkeit, Werbung auf einem Wiki zu deponieren. In den letzten Monaten musste ich eine Zunahme solcher Spambots feststellen, die teilweise mit der gesamten zur Verfügung stehenden Bandbreite die Inhalte dieses Wiki-Servers abgegrast haben.

Um keine Lesebeschränkungen für Besucherinnen und Besucher einführen zu müssen, musste ein anderer Schutz gefunden werden. Gestern hat nun Benedikt eine Spambot-Falle installiert, die folgendermassen funktioniert: Auf allen Wikiseiten ist ein für den Menschen unsichtbarer Link platziert. Dumme Spambots, die allen Links nachgehen, werden auch diesen Link abrufen. Dies löst jedoch eine sofortige Sperre ihrer IP-Adresse aus. Somit sollten Spambots vom Abgrasen des gesamten Wikis abgehalten werden, während normale Wikiuser nichts von dieser Massnahme bemerken sollten.

Bevor nun ein schlauer Schüler auf die Idee kommt, das Wiki seiner Schule durch den Abruf dieses verbotenen Links aus dem Schulnetz lahmzulegen und damit eine Wikistunde zu sabotieren, hier noch folgende Hinweise: Gesperrte IP-Adressen erhalten als Antwort eine Erklärungsseite mit Captcha (Biblionetz:w01616) zurück, auf der sie die Sperre durch Eingabe von nur menschenlesbaren Zahlen wieder aufheben können. Zudem kann ich einzelne IP-Adressen auch in eine Whitelist eintragen, so dass das Abrufen des verbotenen Links von dieser IP-Adresse aus wirkungslos bleibt.

Ein letzter Hinweis für Techies: Bitte die Spambotfalle nicht an meinem Wiki testen: Erstens erhalte ich jeweils ein Mail, wenn sich ein Spambot in der Falle verfängt und zweitens will ich eine unverfälschte Statistik, wie viele Spambots wir fangen konnten. Wer die Funktionsweise testen will, ist eingeladen, dies auf der Website der verwendeten Software zu tun: http://www.spider-trap.de/

Why do I blog this:

• Naja, einerseits damit die User dieses Wikis von diesem Feature wissen. Dieser Blog dient auch als Announcement-Board für das Gesamtwiki.
• Andererseits, weil diese Massnahme ein schönes Beispiel für soft security (Biblionetz:w01915), die zeigt, dass man mit dem notwendigen technischen Know-how nicht nur die Wahl zwischen sicher und brauchbar hat, sondern dass differenzierte Lösungen möglich sind.

Patrick Lambe verweist in einem Blog-Posting auf eine Präsentation von Benjamin Greenberg der non profit Organisation Physicians for Human Rights, der die mailflutsenkende Wirkung von Weblogs vorrechnet:

Eine ähnliche Rechnung gilt für die Aussage Wiki kann die E-Mailflut verringern (Biblionetz:a00731)

Diese Woche ist auf meinem Wiki-Server in einem Bereich eines Gymnasiums ein dummer Fehler beim Umbenennen von Seiten geschehen, der mich ca. 2-3h Arbeit und etwas Nerven gekostet hat. Ich möchte diesen Zwischenfall nicht unterschlagen, da ich nicht nur die problemlosen Seiten des Wikibetriebs aufzeigen will. Andererseits scheinen mir diese 2-3h Arbeit im Verhältnis zu den Aktivitäten und Userzahlen auf dem Wiki relativ wenig zu sein, so dass ich Wiki weiterhin als Erfolgsmodell bezeichnen würde.

Was ist passiert? Jemand hat vor einiger Zeit - entgegen meinen Empfehlungen - Wikiseiten mit Seitennamen erstellt, die kein WikiWord sind, nämlich Seiten mit den Namen A, B, C usw. Bisher wehrt sich mein Wikiserver nicht gegen solche Seitennamen (aber vielleicht muss ich hier eine Einschränkung einbauen).

Diese Woche nun hat jemand anders gesehen, dass da Seiten mit einem einzigen Buchstaben als Namen bestehen und hat diese Seiten alle umbenannt, so dass sie alle Wiki-Words als Namen tragen. Um bei solchen Umbenennungen tote Links zu verhindern, bietet TWiki an, alle internen Verweise auf die umzubenennende Seite anzupassen. Hier kommt nun ein Implementationsproblem von TWiki ins Spiel: Weil TWiki davon ausgeht, dass Seitennamen immer WikiWords sind und somit jedes Auftreten eines solchen Worts auch einen Verweis darstellt, sucht TWiki einfach alle Vorkommen des zu ändernden Seitennamens und bietet dem User an, diese Verweise umzubenennen. Konkret: TWiki hat bei der Umbenennung der Seite A nach LiteraturverzeichnisA in allen Wikiseiten des Bereichs nach dem Auftreten des freistehenden Buchstabens A gesucht.

TWiki ist gegen 2300 mal fündig geworden und hat den User gefragt, ob er diese 2300 Seiten mit dem Buchstaben A im Text auch anpassen möchte. Da diese Frage nicht gross und blinkend dargestellt wurde und die Auflistung der 2300 Seiten erst durch runterscrollen sichtbar geworden wären, hat der ahnungslose User der Frage zugestimmt und schwupps wurden in 2300 Seiten der freistehende Buchstabe A durch den Text LiteraturverzeichnisA ersetzt. Und um die Sache noch etwas komplexer zu machen, geschah dies nicht nur mit dem Buchstaben A, sondern mit vielen Buchstaben im Alphabet, da der User mehrere Seiten umbenannt hat.

Als ich vom Vorfall Kenntnis erhielt, waren schon einige Stunden vergangen, in denen andere ahnungslose User Seiten bearbeitet hatten. Unser Server macht zwar alle paar Stunden einen Snapshot aller Daten, hätte ich aber diesen Snapshot wieder eingespielt, so wäre ein Tag Arbeit des betroffenen Gymnasiums auf dem Wiki verloren gewesen (das entsprach ca. 75 Seitenänderungen).

Nun hat das Wiki zwar eine Versionsverwaltung, aber es ist doch etwas mühsam, an den betroffenen 2300 Seiten die Veränderungen einzeln wieder rückgängig zu machen. Die Seite LiteraturverzeichnisA wieder nach A zurück zu benennen ist auch keine Lösung, da TWiki dann erkennt, dass A kein WikiWord ist und besondere Massnahmen trifft, damit diese 2300 A's im Wiki als Link dargestellt werden.

Ich habe dann die besagten 2-3h benötigt, um mich in RCS und die Verwendung von RCS in TWiki einzuarbeiten und den Ursprungszustand wieder herzustellen, ohne dass irgendwelche Spuren im TWiki zurückgeblieben sein sollten. Da ich gleichzeitig noch an einer fiebrigen Grippe gelitten habe, geschah das alles im Halbdelirium und ohne Dokumentation, so dass ich heute nicht mehr genau sagen kann, welcher Kniff schlussendlich zum Ziel geführt hat.

Wie gesagt: Dieser Unfall bringt mich nicht davon ab, weiterhin die Offenheit von Wikis zu propagieren. Erstens ist dies der erste derartige Vorfall in fünf Jahren und zweitens hätte ich - auf meinen Perfektionismus verzichtend - mit dem Einspielen des gebackupten Snapshots innert einer Viertelstunde das Problem ebenfalls lösen können, wobei dann halt 75 Bearbeitungen verloren gegangen wären.

Für die Zukunft muss ich mir überlegen, wie ich meine TWikiuser dazu anhalten kann, nur WikiWords als Seitennamen zu verwenden. Nach der Automatisierung des Problems von vergessenen Passwörtern mit der TWiki-Version 4.12 ist das verwenden von Non-WikiWords das grösste, wenn nicht das einzige Supportproblem.

Gestern Mittwoch, den 12. Dezember 2007 war dieser Server zeitweise nicht mehr erreichbar. Auf meiner Seite betraf dies das Biblionetz, das Weblog hier, das gesamte Wiki (inkl. der Gymnasial-Wikis), aber auch meine private Mail.

Ich möchte betonen, dass es nicht an unserem Server lag, der friedlich (und etwas gelangweilt) vor sich hin schnurrte, sondern am Netzwerk dazwischen, wie auf diesem Netzwerkdiagramm zu sehen ist (der Unterbruch in der grünen Kurve):

klicken zum Vergrössern

Für den User kommts aufs selbe raus, für uns ist die Fehlerbehebung schwieriger: Wir sind zwar nicht schuld, können aber dafür auch wenig dagegen tun. ,