Posts

Der CertBot von der Electronic Frontier Foundation geht dabei zur Hand.

…hat schon jemand geschrieben. Man kann es bereits hier nachlesen. rsync nutzt SSH und SSH verschlüsselt. Das kostet Zeit und Performance, vor allem wenn man im LAN mit Gigabit unterwegs ist. Kurz gesagt nutzt man die richtigen Optionen und macht’s damit schneller: rsync -aHAXxv --numeric-ids --delete --progress \ -e "ssh -T -c arcfour -o Compression=no -x" \ user@<source>:<source_dir> <dest_dir>

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.

Von Googles Webmastertools wurde ich eben darauf hingewiesen, dass eine meiner MODx Revo Sites offenbar URLs für Spammer redirected. Sie Website verwies also auf dubiose Shops mit Medikamenten und anderem Gedöns. Nach einer ausgedehnten Analyse habe ich dann zunächst in core/cache/ mehrere tmp-* Dateien gefunden, die offenbar immer dann angelegt wurden, wenn eine dieser URLs aufgerufen worden ist. Die Datei selbst enthielt etwas PHP Code, der sich gegenüber Google und anderen Suchmaschinen unsichtbar machte, in dem der Code nur ausgeführt wurde, wenn der Request nicht von bestimmten IPs oder Agents kam. Im Web habe ich darüber etwas unter dem Begriff “Google Conditional Hack” gefunden, z.B. hier. Scheinbar existiert dieser Hack für diverse CMS Systeme, nicht nur für MODx Revo. In meinem speziellen Fall scheint der Angriff zumindest auf MODx angepasst worden zu sein, denn er gibt sich als Core Komponente aus, damit Benutzer ihn nicht finden oder sich nicht trauen ihn zu löschen: ...

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. ...