Marco Gabriel

Ich hatte irgendwann mal ein paar Scripte entwickelt, die ich nun wieder suchte. Ich hatte grob eine Ahnung, wo sie sein könnten. Da das schon eine Weile her war, konnte ich mich nur an den Server, nicht aber mehr an das Verzeichnis erinnern. Die meisten Scripte lege ich in Standardverzeichnisse wie /usr/local/bin, weil ich sie dort auch wieder finden würde. Hier handelte es sich aber um ein git Repository und nicht um fertige, ausführbare Scripte.

Zur Hilfe kam wie so oft find:

~# find / -name ".git" -type d
/opt/checks/prj/.git

Gefunden .

Kürzlich hatte ich ein Update direkt an der Konsole eines Linux Servers gestartet. Das Update dauerte länger und ich wollte aber nicht noch länger vor der Konsole stehen und warten. Aber ich wollte die Ausgabe des bereits gestarteten Updates natürlich sehen.

Eine einfache und praktische Lösung dazu ist, sich per SSH von extern aus einzuloggen und sich die Konsole anzeigen zu lassen. Das erledigt der Befehl "screendump" für uns. Wenn ich nun den Fortschritt noch sehen möchte, verwende ich dazu "watch" und beschränke die Anzahl der anzuzeigenden Zeilen mit tail. 

Fertig sieht's dann so aus:

~# watch "screendump | tail -n <anzahl_zeilen>"

Neulich testete ich eine neue Software zur Verwaltung vieler Systeme. Um die Systeme unterscheiden zu können ist die Seriennummer der Hardware häufig recht hilfreich, denn daraus lassen sich eventuelle Herstellungsdaten und genaue Systeminformationen beim Hersteller erfragen.

Bei Windows Systemen funktionierte das Auslesen der Seriennnummer auch problemlos. Nur das Auslesen der Seriennummer von Linux Systemen funktioniert leider gar nicht.

Dabei geht das unter Linux sehr einfach:

~# dmidecode -t system|grep -i "serial"
    Serial Number: xxxxxxx

dmidecode kann übrigens noch mehr auslesen. Ein Blick in die Dokumentation oder ein einfaches dmidecode auf der Shell lohnt sich.

ZFS hat Snapshots um regelmäßige Sicherungspunkte zu erstellen. Das lässt sich mittels zfs-auto-snapshot sogar automatisieren.

Wenn man nun aber plötzlich Platz benötigt kann es mühsam sein, hunderte von Snapshots manuell zu löschen. Das geht auch mit einem Einzeiler:

for snapshot in `zfs list -H -t snapshot | cut -f 1`; do zfs destroy $snapshot; done

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>

Auch Hetzner als Provider für Rootserver ist vor Bugs nicht sicher. Durch einen Bug wurde auf neu installierten Servern möglicherweise ein Host Key nicht sauber neu erstellt und so ist genau dieser eine SSH Host Key nun in ganz vielen unterschiedlichen Servern mit drin. 

Hetzner empfiehlt, diesen Key neu zu generieren. Mehr dazu im Hetzner Wiki:

• http://wiki.hetzner.de/index.php/Ed25519

Weil's so schön ist, muss ich's hier auch noch mal rein tun:

????
He's making a database
He's sorting it twice
SELECT * from contacts WHERE behavior = 'nice'
SQL Clause is coming to town
????

???? He's making a database He's sorting it twice SELECT * from contacts WHERE behavior = 'nice' SQL Clause is coming to town ????

— Karen Kringle (@KarenMN) 16. Dezember 2015

Früher tat's ein funktionierender und guter Virenscanner. Heute ist das nicht mehr so. Für die inett habe ich daher mal in einem Blogbeitrag die wichtigsten Tipps für sichere Unternehmensnetzwerke zusammengefasst.

Da schaut man länger nicht auf die eigene Blog Software, schon gibt's eine neue Version. Ich hab dann mal auf Serendipity 2.0.1 geupdated und das lief - wie immer - völlig stressfrei und automatisch.

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:

Aber woher kamen diese Dateien? Ein auffälliger String im Code ("tmhapbzcerff") war wie gemacht als Suchmuster. Also bemühte ich grep um das Muster vielleicht auch noch in anderen Dateien zu finden. Tatsächlich wurde ich fündig: Auch in core/cache/includes/elements/modplugin/20.include.cache.php existierte dieser String. 

Cache und tmp Dateien löschen führte zwar dazu, dass die Dateien weg waren, aber kurze Zeit später tauchten sie wieder auf. Also musste es noch einen tiefer liegenden Auslöser dafür geben. 

Das core/cache/includes/elements/modplugin/ Verzeichnis wird als Cache erstellt, wenn MODx Plugins ausgeführt werden. Der erste Zahlenwert des Dateinamens, so vermutete ich, könnte die ID eines Datensatzes sein.

Ein Blick in die Datenbank von MODx zeigte eine Tabelle namens modx_site_plugins. Das könnte passen.

In dieser Tabelle gab es einen Datensatz mit der ID 20 und dem Namen "Search Highlighter". In den Details sah man dann auch den Schadcode, zwar encrypted, aber durchaus identifizierbar. Nach dem entfernen dieses Datensatzes und dem erneuten Löschen des Cache und der tmp Dateien ist der Schadcode nun verschwunden.

Wie der Code jedoch in die Datenbank kam, konnte ich noch nicht herausfinden. Da ich die aktuellste Version von MODx Revo einsetze (2.3.2-pl) könnte es natürlich darin eine Sicherheitslücke geben, eine Suche ergab dazu jedoch keine Treffer. Theoretisch könnte der Schadcode schon sehr lange drin gewesen sein und entweder nicht aktiv oder unbemerkt. Möglich wäre auch eine SQL Injection in der Vergangenheit in einer älteren MODx Version.

Update am 23.12.2014: Ich hatte noch nicht alles erwischt und entfernt. Nach einigen Stunden waren dann wieder die gleichen Dateien vorhanden. Durch einen Hinweis von @JayGilmore kam ich dann auf die Seite http://forums.modx.com/thread/89564/warning-hacking-attack-on-revo-2-2-4-using-core-services-plugin und sah dort, dass ich ein Plugin noch nicht entfernt hatte. Das war mir gestern auch schon aufgefallen, aber ich rechnete es nicht dem Hack zu. Das habe ich jetzt auch noch entfernt - mal sehen ob das nun alles war.

Es handelt sich wohl um einen Hack, der vor MODx 2.2.14 bereits durchgeführt, aber bis vor kurzem nicht ausgenutzt wurde.

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:

Ausgabe von varnishhist: Unter (1) sieht man die Hits, unter (2) die an den Webserver weitergeleiteten Requests. Von links nach rechts erhöht sich die Antwortzeit.

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.