Google betritt nun auch den heiss umkämpften Browsermarkt und will gegen die Platzhirsche Microsoft, Mozilla und Apple antreten. Unter der Haube von „Google Chrome“ steckt allerdings auch bewehrte Technik: WebKit (auch bei Safari im Einsatz). Laut Aussagen von Google ist der Browser speziell auf Webapplikationen (GMail, Google Docs) ausgerichtet und mit einer komplett neuen und schnellen JavaScript-Engine (mit dem Namen V8) ausgestattet. Wer nicht selbst testen möchte, kann sich ein ausführliches Review bei Golem.de durchlesen, inkl. einen Video oder aber den Kurztest von heise online, aber natürlich hat sich auch der Spiegel Online schon eine Meinung gebildet ;)

Mein Eindruck: Die Installation dauert eine gefühlte halbe Stunde (liegt vll. daran, das bei der Installation das eigentliche Programm erst heruntergeladen wird und derzeit wohl einige am installieren sind, bei netgestalter.de waren es nur 30sec). Beim ersten Start darf man auswählen, ob und welche Einstellungen man gerne importieren möchte (ich hab mich mal komplett dagegen entschieden). Der Aufruf der ersten Webseite (mein Blog) schlug fehl… Aeh? Nunja, das Problem wurde schnell gefunden. Chrome benutzt anscheinend die Einstellungen des Internet Explorers bzgl. des Netzwerkes/Proxy (doofe Idee). Nach der Umstellung wurde dann meine Seite auch recht zügig geladen. Fehler bei der Darstellung konnte ich keine erkennen (hatte aber auch nichts anderes erwartet).

Erstes Fazit: mmh. Braucht man den Browser wirklich? Ich glaube nein, bei mir wird weiterhin FireFox im Einsatz sein. Insgesamt kann ich den Eindruck „Schulterzucken“ von Robert Basic nur bestätigen. Was mir ganz und gar nicht gefällt ist die Tatsache, das Google Chrome auf Einstellungen des Internet Explorers zurückgreift und die fehlende Statusleiste am unteren Rand (sowie meine vielen kleinen Helferlein die dort „wichtige“ Informationen anzeigen). Die Optik ansonsten wirkt natürlich sehr aufgeräumt und bietet viel Platz für die Darstellung der Seite. Für Webapplikationen dürfte die sicherlich von Vorteil sein und genau diesen Markt peilt Google wohl an. Somit kann man wohl sagen, alles richtig gemacht, nur leider bin ich nicht die passende Zielgruppe ;)

Eine eher unscheinbare Einstellung die es in sich hat. Standardmässig werden bei MySQL (unter Debian) die InnoDB Datenbanken/Tabellen alle in einer Datei (ibdata1) gespeichert und aufgrund der Art und Weise der Speicherung wird auch nicht mehr benötigter Speicher nicht mehr freigegeben (z.B. bei mysqlcheck -o). Aufgrund meines bisherigen Unwissens hatte sich die Datei auf über 4GB aufgebläht und ist bei einem Crash nun leider in Mitleidenschaft gezogen worden. MySQL hat daraufhin jegliche Mitarbeit verweigert und ich hatte mich auf die Suche gemacht, was es denn mit der Fehlermeldung auf sich hat und bin dabei über „innodb_file_per_table“ gestolpert. Hat zwar nicht geholfen die Daten zu retten, aber erspart mir vll. in Zukunft das eine oder andere Problem.

Damit nicht mehr alle Tabellen in einer Datei gespeichert werden, muss die Konfiguration (my.cnf) um „innodb_file_per_table“ erweitert werden. Einen Haken hat die Sache allerdings, die Änderung gilt nur für neue Tabellen. Die bisherigen Tabellen werden auch weiterhin in ibdata1 gespeichert. Der Versuch mit ALTER TABLE <table> ENGINE=InnoDB; hat bei mir leider nicht funktioniert. Und so blieb mir nur der Umweg, alle Datenbanken zu sichen, zu löschen und nochmal von vorne Anzufangen (mysql_install_db) und die Backups zurück zu spielen. Aufgrund der Datenmenge zieht sich das Ganze allerdings sehr in die Länge :(

Bei meinen „Recherchen“ bin ich auch noch über „MySQL Tuner“ gestolpert. Und muss sagen, auch das Tool gefällt mir. Bisher hatte ich auf tuning_primer.sh gesetzt, werde in Zukunft aber auch den MySQL Tuner befragen.

Nunja, wie heisst es doch so schön, Unwissenheit schützt vor Strafe nicht. Es ist mir allerdings unbegreiflich, weshalb die Einstellung nicht standardmässig auf einzelne Dateien gesetzt ist. Vorteile dieser Methode sind mir aktuell auch noch unbekannt. Werde aber versuchen mich noch weiter Schlau zu machen, aber vll. hat ja jemand ein paar Info’s?

Da schaut man mal einen Tag nicht in die Adminoberfläche und muss es dann bei Golem.de lesen: Openfire 3.6.0 ist draussen. An Neuerungen gibt es u.a. eine verbesserte LDAP-Unterstützung, eine Entschlackung der XML-Konfigurationsdatei (-> Daten werden nun in der DB gespeichert), bessere Integration in Clearspace und eine Überarbeitung der HTTP-Bindings + Update auf BOSH 1.6, sowie viele kleinere Fixes…

Soweit so gut, ich hatte mich auch gleich daran gemacht (ohne vorher das Forum zu lesen *gna*), und siehe da, Openfire wollte sich nicht mehr starten lassen. Leider wurden nicht alle Einstellungen aus dem XML in die Datenbank übertragen. Wie es scheint, tritt das Problem häufiger auf :( Wie auch immer, zum Glück hatte ich vorher ein Backup erstellt und nun einfach erstmal wieder zurückgespielt. Insgesamt scheint das Release nicht so ganz ausgereift und der Eine oder Andere überlegt auch schon, sich erst mit dem Release von 3.6.1 wieder am Update zu versuchen…

Wie schon vor ca nem Monat geschrieben, gibt es nun Version 2.3 von Openfiler (NAS/SAN-Appliance Software) und heute stand nun auch das Update bei nem Produktiv-System an. Als erstes war ein Fullbackup dran. Aufgrund der Datenmenge, knapp 0,5 TB, entschied ich mich, die Daten nicht wie sonst planmässig auf Band sondern auf einer entsprechend grossen Festplatte zu sichen, dank Gigabit-Anbindung ging es recht „fix“ (nur um im Nachhinein festzustellen, das beim Update nichts schief ging, und die Zeit somit unnötig vergeudet wurde *g*). Während des Backups hatte ich mich dann schoneinmal durchs Forum gekämpft und einen inoffiziellen Updatepfad gefunden (scheint insbesondere mit iSCSI problematisch zu sein, war aber hier bisher nicht im Einsatz). Mit folgenden Befehlen und etwas Zeit liess sich die Version 2.2 auf 2.3 updaten:

> mv /usr/lib/heartbeat/cts /usr/lib/heartbeat/cts_old
> mv /usr/lib/heartbeat/lrmtest /usr/lib/heartbeat/lrmtest_old
> conary migrate group-openfiler=@ofns:2 --interactive
> mv /usr/lib/heartbeat/cts_old /usr/lib/heartbeat/cts
> mv /usr/lib/heartbeat/lrmtest_old /usr/lib/heartbeat/lrmtest

Probleme sind keine Aufgetreten, alle Einstellungen waren noch vorhanden und es funktioniert alles noch immer wie vorher, aeh ja, zumindest soweit es das eben soll ;)

Insgesamt war ich doch, ob der Einfachheit des Updates überrascht. Bei früheren Updates ging einfach häufiger mal etwas schief. Seelisch hatte ich mich auch schon auf eine komplette Neuinstallation vorbereitet, bin aber dennoch froh das es nicht soweit kommen musste. Was ich allerdings noch immer Suche sind die „Per-network NFS Tuning“-Einstellungen, wo auch immer sie sich verstecken, ich hab sie noch nicht gefunden. Nunja, vll. stolpere ich ja noch im Laufe der nächsten Tage darüber. Als nächstes ist dein neuer Anlauf in Sachen iSCSI geplant (wollte unter 2.2 einfach nicht funktionieren).

Heute hatte ich das Glück/die Aufgabe Zimbra (Open Source Edition), ein Mail/Calender-Server, zu installieren. Der Erste Eindruck ist durchaus positiv (einfache Installation), aber es zeigen sich leider auch recht schnell ein paar kleinere Mankos.

Installation:

Da leider von Zimbra keine Pakete für Debian/AMD64 zur Verfügung gestellt werden (die aktuelle Version von Zimbra gibts für Ubuntu derzeit leider auch nur für 6.06 *narf*) durfte ich mir heute wiedereinmal CentOS anschauen. Die „Installation von CentOS 5.2 unter XEN“ (Sprich Image auspacken, Inhalt auf ein LVM-Laufwerk kopieren und ne Konfigurationsdatei schreiben) verlief, wie nicht anders erwartet, ohne besondere Vorkommnisse. Auch die Installation von Zimbra ist eigentlich ein Kinderspiel (bei CentOS sollte man allerdings gleich „./install.sh –platform-override“ verwenden, man wird darauf aber auch hingewiesen, falls man doch nur install.sh aufgerufen hatte). Nur der Versand von E-Mails wollte ersteinmal nicht funktionieren. Ein Blick ins Maillog brachte allerdings schnell die Erleuchtung, es fehlte noch das Paket „file“ (dank yum war aber auch das schnell installiert).

Bedienung:

Der Webclient macht einen modernen Eindruck (dank AJAX und Co). Doch er offenbart (zumindest zumindest für mich) direkt nach dem Login ein kleines Manko, so etwas wie ein Dashboard (Aktuelle Termine/Aufgaben/E-Mails als Übersucht) fehlt, man landet direkt im „E-Mail-Client“. Ansonsten hat er alles so erledigt wie ich es mir gedacht hatte.

Der nächste Versuch galt Sunbird. Der Kalender lässt sich einfach via CalDAV integrieren (Link: http://server.domain.com/dav/username/Calendar ). Es fehlen allerdings die Aufgaben. Ein Blick ins Forum half weiter. Die Aufgaben sind derzeit anscheinend nur via .ics zu bekommen, und sofern man nun also einfach einen zweiten Kalender in Sunbird anlegt hat man auch die Termine (Link: http(s)://mail.example.com/home/<user>/Tasks). Nachdem hinzufügen von ein paar Aufgaben kam allerdings schon wieder die ernüchterung. Keine der Aufgaben wollte sich im SunBird wieder löschen lassen. Aber auch dafür gibt es Abhilfe: Man ändere einfach der Status der Aufgabe auf „Cancelled“ und siehe da, die Aufgabe ist verschwunden (sowohl in Sunbird als auch im WebClient).

Erstes Fazit:

Zimbra (Open Source Edition) scheint, sofern man mit dem WebClient zufrieden ist eine Runde Sache zu sein (den Desktop Client habe ich mir noch nicht angeschaut). Einfache Installation, einfache Bedienung. Die Anbindung an Sunbird ist leider nicht optimal, aber durchaus zu verschmerzen (für Thunderbird/Lightning gilt das Gleiche). Mal schauen, was die nächsten Tage/Wochen an weiteren Erkenntnissen bringt und ob Zimbra es schafft das bisher im Einsatz befindliche Scalix zu ersetzen (wobei ich da eher keine Bedenken habe).

Vorneweg, es geht hier nicht um einen neuen super tollen Spamfilter, sondern vielmehr um Techniken zum Vermeiden, dass die eigene E-Mail-Adresse in irgendwelchen Spamlisten landet.

Bei Dr. Web bin ich im Blog über folgenden Beitrag gestolpert: Wirklich wirksamer Schutz für E-Mail-Adressen. Ausgangsbasis für den Artikel ist eine „Studie“ von Silvan Mühlemann von Techblog. Er hatte über ein Jahr getestet, welche Technik zum „Verschleiern“ der E-Mail-Adresse bei Veröffentlichung auf einer Internetseite am wirksamsten gegen Bots hilft. Wenig verwunderlich ist, die Plain-Text-Methode hat natürlich am meisten Spam angezogen. Interessant sind eher die anderen Ergebnisse, so haben z.B. zwei ausschliesslich auf CSS basierende und damit leicht umzusetzende Methoden (Änderung der Schreibrichtung / Trennung mittels unsichtbarer Elemente) es geschafft, das keine der E-Mail-Adressen Spam erhalten hat (Alle Methoden sind im Techblog im Detail nachzulesen). Eines Gemeinsam haben allerdings alle Methoden, nebem einem möglichen Schutz vor dem automatischen Erfassen durch Bots, bieten sie auch (kleinere) Nachteile für den normalen Besucher. Zumeist funktioniert ein „mailto:“-Link nicht mehr, die E-Mail-Adressen lassen sich häufig nicht oder nur fehlerhaft per „Copy and Paste“ kopieren. Ältere Browser und/oder Browser, bei denen z.B. JavaScript etc abgeschalten ist/die CSS nicht „vernünftig“ bearbeiten kommen in Schwierigkeiten, das sie für den Besucher keine brauchbaren Ergebnisse liefern können. Nicht vergessen sollte man dabei auch, die Rechtslage bzgl. eines Impressum. Nach einem aktuellen Urteil reicht unseren Gerichten die Angabe eines Formulars anstatt einer E-Mail-Adresse z.B. nicht aus, wie ein Gericht bzgl. einer verunstalteten E-Mail-Adresse urteilt ist allerdings noch nicht bekannt. Weiterhin helfen derartige Methoden natürlich nur, wenn man bei der veröffentlichung der E-Mail-Adresse einfluss hat, gibt man allerdings die selbe E-Mail-Adresse in einer Community (Social/Forum) und es besteht dort z.B. eine Sicherheitslücke, so landet man schneller als einem lieb ist auch damit wieder in den Listen der Spammer. Es kann auchreichen, das ein Freund die E-Mail-Adresse in seinem E-Mail-Programm speichert und dieses wegen mangelnder Sicherheitsmassnahmen z.B. durch ein Trojaner ausgelesen wurde, und schwupps bekommt man auch Spam…

Fazit: Sofern man eine E-Mail-Adresse nur auf der eigenen Seite (den eigenen Seiten) veröffentlicht, kann man mit diesen Methoden die Hürde sicherlich sehr hoch setzen, dennoch ist es kein 100%-tiger Schutz. Ein serverseitiger Spamfilter (oder zur Not auf Clientseite) ist damit sicherlich nicht zu ersetzen. Der Spamfilters kann damit aber gegenenfalls entlastet werden :)

JAWStats

Wer bisher schon AWStats für das Aufbereiten der Webserver Logfiles nutzt, und sich an der doch eher „altbackenen“ Optik stört, der sollte einmal JAWStats anschauen. Aufbauend auf den von AWStats generierten Daten erstellt JAWStats viele Charts, Diagramme und verleiht dem Ganzen eine schicke neue Optik inkl. Sortierung der Ausgabe nach allen Spalten und einigem mehr. Für Betreiber grösserer Webserver mit vielen Seiten dürfte der Geschwindigkeitsvorteil beim generieren der HTML-Seiten sein, die dafür verbrauchten Resourcen können einfach sinnvoller genutzt werden.