Neulich stellte ich eine Modx Revo Seite von http auf https um. Allerdings hatte ich danach damit zu kämpfen, dass in der Base URL mal http:// und mal https:// Links auftauchten. Da Modx die [[++base_url]] selbst ermittelt, kam dann je nach erstem Abruf entweder ein http oder https zum Zug.
Im Modx Forum habe ich eine Lösung dazu gefunden: [[!++site_url]] verwenden und diese im verwendeten Kontext einfach festschreiben. Danach sollten alle Links sauber sein.
Varnish ist ein extrem schneller caching reverse Proxy, der einem normalen Webserver vorgeschaltet wird. In der Regel beantwortet Varnish dann die Anfragen der Benutzer, entscheidet, ob er aus seinem eigenen Cache liefern kann und den Webserver dahinter nicht mehr fragen muss. Da Varnish den Proxy im Speicher hält, bedient er Anfragen extrem schnell. Was er nicht selbst bedienen kann, z.B. weil die Seiten aktive Inhalte haben oder nicht gecached werden dürfen, gibt er an den dahinter liegenden Webserver weiter. Darüber hinaus überwacht er die Webserver und verteilt Anfragen an mehrere Webserver. Fällt einer der Webserver aus, leitet Varnish dort einfach keine Anfragen mehr hin. Benutzer bekommen davon überhaupt nichts mit. Varnish ist übrigens auch völlig anpassbar über eine eigene Konfigurationssprache. Damit lassen sich extrem tolle Dinge relativ einfach realisieren.
Ich kam irgendwann auf die Idee, auch normale, einzelne Webserver mit einem Varnish auszustatten, um die Auslieferung von Web Inhalten zu beschleunigen. Zunächst klang das für mich bei allen oben genannten Vorteilen wie eine Verbesserung. Zumal der Varnish auf dem gleichen Host lief und über eine iptables Regel eingebunden wurde, d.h. mein Varnish war jederzeit im Betrieb transparent ein- und abschaltbar. Nicht mal die Webserver Konfiguration musste ich ändern.
Als ich mir die Statistiken des Varnish ansah, war dort allerdings kaum ein positiver Effekt zu erkennen. Die Cache Hit Rate war oft unter 1%, so dass sich kein erkennbarer Gewinn daraus erzielen liess. Varnishhist zeigt ein ähnliches Ergebnis, aber etwas schöner als Varnishstat:
Der Grund dafür ist recht schnell ausgemacht. Sobald Cookies existieren, geht Varnish von einer Session aus und leitet einfach alle Anfragen an den Webserver weiter. Da heute die meisten Websites Content Management Systeme für alles einsetzen, läuft bereits beim ersten Besuch ein Cookie auf und eine Session startet. Damit ist Varnish außen vor.
Varnish handelt an dieser Stelle völlig korrekt, um die Stabilität der Webanwendungen vor die Performance zu stellen.
Bei kleinen Webservern, die verschiedene Websites ausliefern und alle nicht auf Varnish optimiert sind, ergibt der Einsatz von Varnish deshalb (leider) auch keinen Sinn. Man kann mittels der Scriptsprache Varnish beibringen, dass er trotzdem statische Dateien wie Bilder, CSS, etc. cached, der Aufwand lohnt sich aus meiner Erfahrung heraus trotzdem nicht.
Neulich hatte ich eine Unterhaltung darüber, wie man die Laufzeit eines Programms möglichst einfach misst. Im konkreten Fall wollten wir wissen, wie lange ein mysqldump benötigt hat. Dazu gibts unter Linux den Befehl time, den man dem zu messenden Programm einfach voranstellt.
time <Programm und Parameter> [...Ausgabe des Programms...] real 0m56.754s user 0m0.784s sys 0m4.004s
Der Wert hinter real zeigt an, wie lange das Programm gelaufen ist, im obigen Beispiel 0 Minuten, 56 Sekunden und 754 Millisekunden.
Für ein Zarafa Upgrade von 6.40 auf 7.1 musste ich eine MySQL Datenbank von einem alten auf einen neuen Server übernehmen. Da es sich um eine relativ große Datenbank handelte, testete ich den Vorgang vorab und alles funktionierte - inklusive dem Dump und dem Restore der Datenbank.
Beim eigentlichen Upgrade dann brach der Dump mit der folgenden Meldung ab:
mysqldump: Error 2020: Got packet bigger than ‘max_allowed_packet’
Das Problem ist, dass mysqldump nicht die gleichen Konfigurationsparameter wie der mysqld verwendet. In der /etc/mysql/my.cnf kommt ganz weit unten eine Sektion namens [mysqldump], in der man die max_allowed_packet Größe anpassen muss, wenn der Server ebenfalls größere Pakete zulässt. Passt man diese Größe nicht an, können Backups unbrauchbar sein weil sie mittendrin abbrechen.
Der Standardwert liegt bei 16M und sollte je nach Anwendung höher gesetzt werden. Bei Zarafa ist in der Regel 32M bis 64M völlig ausreichend, da die MAPI Objekte zwar größer sein können, die Attachments jedoch im Filesystem und nicht in der Datenbank liegen. Demnach muss die Datenbank meist weniger als 32M liefern.
Wenn man mysqldump von einem anderen Host aus startet (der keine my.cnf besitzt) oder die Koonfiguration nicht anpassen möchte, kann man auch als Parameter --max-allowed-packet=32M angeben. Damit wird der Eintrag in der Konfiguration übersteuert.
...ist bei mir jetzt von deutsch auf französisch gewechselt. Ja, ich surfe von einem französischen Anschluß aus, aber das System sowie alle Einstellungen sind auf deutsch gestellt. Alles außer dem App Store scheint auch nach wie vor auf deutsch zu sein.
Entweder möchte Apple mein französisch verbessern (Danke, Apple) oder es möchte mir ein noch besseres Benutzererlebnis bescheren, in dem es für mich Dinge automatisch einstellt (Danke, aber nein danke, Apple) oder es handelt sich schlicht um einen Bug in einem neuen Betriebssystem (Shit happens, Apple).
Die Optik von Yosemite gefällt mir sehr gut, aber es fühlt sich auf meinem zugegeben nicht mehr ganz taufrischen Macbook Air ziemlich zäh an. Ich hoffe, das wird noch besser.
Update vom 19.20.1014 22:36: Wo We hat mich auf den richtigen Weg gebracht. Ganz unten rechts im App Store kann man die Sprache wieder anpassen. Jetzt ist mein App Store auch wieder auf deutsch wie vor dem Update.
Sicherlich ist es nicht nur legitim, sondern auch sinnvoll, die irgendwann einmal getroffenen Entscheidungen neu zu bewerten und zu prüfen, ob man richtig entschieden hat. So tut es die Stadtverwaltung München im Moment. Diese möchte erneut prüfen, ob man nicht zurück zu Windows wechseln möchte. München hatte vor Jahren für Aufsehen gesorgt als es entschied, die Stadtverwaltung auf Open Source Software umzustellen um damit langfristig kosten zu sparen und unabhängig von einzelnen Herstellern zu werden.
Wie ich nun in einem Golem Artikel gelesen habe, ist eine fehlende oder nicht ausreichende Groupware. Ich frage mich dabei, ob die Stadt München schon mal etwas von Zarafa gehört hat und ob ein Umstieg auf Zarafa für die gemeinsame Nutzung von E-Mail, Kalendern und Kontakten in Betracht gezogen wurde. Die vom Oberbürgermeister angesprochenen Probleme erscheinen damit auch meiner eigenen Erfahrung nach jedenfalls sehr, sehr lösbar zu sein.
Natürlich halten sich auch Gerüchte, dass der plötzliche Wechsel vielleicht auch etwas mit dem neuerlich angekündigten Umzug der Microsoft Deutschland Zentrale nach München zu tun hat.
Was leider viel zu oft nicht bedacht wird, ist der Lock-In-Effekt bei der Verwendung proprietärer Software. Dieser sorgt vor allem beim Beenden einer Geschäftsbeziehung und dem Umstieg auf eine andere Lösung für Kosten. So sollte man auch betrachten, welche Kosten bei der Umstellung auf Linux entstanden sind, die eigentlich auf die vorher eingesetzte Software verbucht werden müssten - allerdings kommt diese Betrachtung meist zu kurz oder wird gar nicht erst gemacht.
Meiner Meinung nach macht die Stadt München einen gewaltigen Fehler, wenn sie nicht ergebnisoffen an diesen Rückblick geht und sich Microsoft an den Hals wirft. Gerade die öffentliche Hand sollte hier Vorreiter sein und auf offen verfügbare Standards setzen statt einem Hersteller die Tür zu öffnen, der sie dann auf Jahre in der Hand hat. Gerade jetzt, wo München die Umstellung quasi geschafft hat und nur noch die Verbesserung der Infrastruktur vorantreiben müsste.
Heute schon den Kontostand geprüft oder online etwas eingekauft? Meist verwendet man dazu eine verschlüsselte Verbindung, auch wenn das vielen nicht bewusst ist, weil es automatisch irgendwie im Hintergrund geschieht.
Obwohl wir alle fast täglich Verschlüsselung im Internet einsetzen, weiß kaum jemand, wie das überhaupt funktioniert. Auf Youtube gibt's nun ein schönes Video, das erläutert, wie zwei Personen (oder Systeme) Daten miteinander austauschen können ohne sich vorher jemals getroffen zu haben.
Geht nicht? Geht doch.
Und das Beste daran ist: "vimtutor" ist sehr wahrscheinlich schon installiert.
Einfach auf der Shell starten und den Anweisungen folgen:
vimtutor
Delicious war toll und ich habe es lange genutzt um meine eigenen Bookmarks unabhängig vom Browser zu verwalten. Ich habe Delicious übrigens auch als Suchmaschine genutzt, da die Inhalte jeweils von Menschen zusammengestellt waren, aber das ist eine andere Geschichte.
Zwischenzeitlich hat Delicious mehrmals den Besitzer gewechselt und ist heute auch für mich nicht mehr das was ich eigentlich möchte. Daher habe ich mich nach einer eigenen Verwaltung für meine Bookmarks umgeschaut, die ich auch auf meinem eigenen Webspace betreiben kann, um auch unabhängig zu werden.
Ich bin dabei auf Shaarli gestossen (Felix sei dank) und nutze es nun seit über einem halben Jahr. Es ist minimalistisch, macht genau was es soll, einfach bedienbar und schön in beliebige Browser integrierbar. Darüber hinaus benötigt es nur noch PHP und da es nur dateibasiert arbeitet benötigt es nicht mal eine Datenbank.
...könnte darauf hindeuten, dass rsync noch gar nicht installiert ist.
apt-get install rsync
behebt das Problem.
Eben habe ich einen schönen Artikel gefunden, der diff, kompare und meld mal im Detail beschreibt. Ich nutze diff beispielsweise immer um bei Upgrades zu sehen, welche Optionen bei einer neuen Konfigurationsdaten dazu gekommen sind.
Sehr schöne Lösung: https://www.zabbix.com/forum/showpost.php?p=91083&postcount=18
Zabbix hat uns heute unseren Mailserver zugespammt mit berechtigten Fehlermeldungen. Eine einfache Möglichkeit, Mails eines bestimmten Absenders aus einer Postfix Queue zu löschen, bevor diese zugestellt werden, zeige ich hier (alles in einer Zeile):
mailq|grep absender@example.com|awk '{print $1}' > /tmp/zmails.tmp && while read LINE; do postsuper -d $LINE; done < /tmp/zmails.tmp && rm /tmp/zmails.tmp
Merke: Zeit richtig einstellen auf dem Zabbix Server hilft.
Der besagte Zabbix Server hatte die falsche Zeitzone und ging damit zwei Stunden nach. Damit kamen bestimmte Pakete von anderen Agents nicht "rechtzeitig" und wurden verworfen.
Nach Anpassung der Zeitzone mit
dpkg-reconfigure tzdata
lief die Queue auch schön leer.
Dazu gibts doch eine nette Präsentation, die zwar aus 2011 stammt, aber nach wie vor gültig ist.
