Contact me

Mainboarder

Better with IT.
informiert via RSS, Facebook und Twitter

Wie ich eine hohe SWAP-Latenz beseitigte

Von Mainboarder am 11.04.2014 veröffentlicht
Tags: , ,

Letztens, und damit meine ich, dass das schon eine Weile her ist, klingelte mein Handy immer wieder in der Nacht. Grund war eine zu hohe SWAP-Latenz. Das passiert, wenn der RAM voll ist und auf die wesentlich langsamere Festplatte Teile des RAMs ausgelagert werden.
Je mehr die Festplatte zu schreiben hat, desto länger dauert das und damit steigt auch die Latenz.

Ich machte mich also daran den Fehler zu suchen.

Obwohl der RAM nicht vollständig ausgeschöpft war, swappte der Server. Mittels iotop stellte ich im Grunde nichts wirklich außergewöhnliches fest. Gut, MySQL swappte ein bisschen. Aber das hat mich nicht sonderlich beunruhigt.

Doch nach einigen Minuten stellte ich fest, dass auf einmal viel RAM frei wurde. Damit musste natürlich auch nicht mehr im hohen Maße geswappt werden.
Das lag an einem Cronjob der die Last auf dem System steigerte.

Da ich BOINC mit der niedrigst möglichen nice laufen lasse, war mir klar, damit hat es zu tun. Allerdings hatte ich vorher keine Probleme damit. Die Last ging hoch und der Prozessor beschäftigte sich mit höher priorisierten Prozessen, wie zum Beispiel dem Cronjob.

Ich stellte fest, dass nach dem Durchlauf des Cronjobs tatsächlich der RAM wieder voll wurde. Um zu überprüfen, ob es wirklich an BOINC liegt, beendete ich den Manager. Mein Verdacht bestätigte sich.

Da ich immer nur an einem Projekt gleichzeitig mitrechne, war klar, dass das Problem Rosetta@home auslöste. Ich beendete die aktuelle Workunit, verwarf die anderen und wechselte das Projekt.
Der RAM ist nun weit weniger stark belastet und alles läuft flüssig. Man kann Fehler offenbar auch relativ schnell durch Zufall finden.


Heartbleed und was viele vergessen

Von Mainboarder am 9.04.2014 veröffentlicht
Tags: , , ,

Ein Bug, von dem man noch lange Zeit wissen wird. Das ist Heartbleed. Am späten Montagabend wurde er veröffentlicht. Manche, wie Cloudflare, waren informiert, andere, wie Linuxdistributionen, nicht. Ein Vorgehen das an sich hätte besser laufen sollen, bei solch einer schwerwiegenden Lücke. Aber von vorn.

Diese Einstellung sollte in Chrome unbedingt gesetzt werden.

Diese Einstellung sollte in Chrome unbedingt gesetzt werden.

OpenSSL wird sehr oft genutzt um verschlüsselte Verbindungen zwischen Client und Server herzustellen (Onlinebanking, E-Mail made in Germany, vermutlich De-Mail, Onlineshops). Dafür gibt es einen Algorithmus, welcher nicht das gleiche Passwort zum Ver- und Entschlüsseln benötigt. Ähnlich wie bei PGP (was nach Snowden mehr Leute kennen dürften).

Es gibt einen öffentlichen Schlüssel, mit dem Nachrichten des Clients verschlüsselt werden und einen privaten Schlüssel, um die Nachrichten zu entschlüsseln.
Der Bug lässt es zu bis zu 64 kByte aus dem Hauptspeicher eines Rechners ohne größere Mühen auszulesen. 64 kByte ist für Text verhältnismäßig viel und so kann man darin auch viel finden: wie zum Beispiel Passwörter oder auch Teile des privaten Schlüssels. Ließt man die richtigen Speicherbereiche aus, so erhält man den vollständigen Schlüssel.

Diese Möglichkeit führt dazu, dass wenn man streng nach Vorschrift geht, nun alle Zertifikate und Passwörter schnellstmöglich geändert werden müssen. Erst dann kann ein System als nicht mehr kompromittiert angesehen werden. Schließlich bestand die Lücke seit über zwei Jahren.

Aber auch hier gibt es wieder ein Problem. Die SSL-Zertifikate (also die zur Verschlüsselung verwendeten Passwörter), werden durch Firmen vergeben, meist gegen Geld. Ein Rückruf kostet nun oftmals Geld. Man hat die Wahl: entweder Bares in die Hand nehmen und alles ordentlich machen, oder darauf vertrauen, dass man selbst ein zu uninteressantes Ziel war und der Aufwand für den Angriff bei einem sich nicht lohnte.

Ein weiteres, aber viel schwerwiegenderes Problem sehe ich noch. Nutzt ein Besucher Chrome, so prüft dieser gar nicht, ob ein Zertifikat als ungültig erklärt wurde. Er akzeptiert es, solange es plausibel scheint. Erst durch Änderung der Standardeinstellungen: Einstellungen, Erweiterte Einstellungen anzeigen, HTTPS/SSL -> Serverzertifikate auf Sperrung prüfen, prüft Chrome dies.

Da es sich um eine unsichere Standardeinstellung handelt, werden die wenigsten Nutzer jemals eine vernünftige Einstellung erhalten. Dadurch kann sich ein Angreifer zwischen Client und Server positionieren und die Kommunikation ändern, da er im Besitz des Zertifikates eigene Nachrichten erstellen und als der Server signieren kann.


Ich fange mal mit letzterem an: Ich rantete über Java, ein Grund: von Haus aus kennt es kein AES. Mir wurde erklärt, dass das wohl nicht damit ausgeliefert werden darf, wegen rechtlicher Gründe. Angeblich darf Software nicht von vornherein sicher verschlüsseln in Amerika.

So wirklich glaube ich das nicht. AES ist ein offener Standard. Ein Algorithmus den man doch wohl implementieren darf. In Anbetracht des merkwürdigen Urheberrechtes und des NSA-Skandals aber zumindest nicht komplett abwegig. Dagegen spricht aber auch, dass es in PHP von Haus aus möglich ist: mcrypt-encrypt().

Apropos PHP… aus gleicher Quelle erfuhr ich heute von der Existenz von RedBeanPHP. Ein absoluter PHP-Profi bin ich ja nicht und ein Fan von Frameworks und großartig vorgefertigten Sachen auch nicht. Alles was ich so nutze ist meist Smarty, fremde und eigene Klassen.

SQL ist da anfangs immer mühselig. RedBeanPHP aber ändert das.

RedBeanPHP ist eine simpel gehaltene ORM-Klassensammlung. Damit coded man sein Programm und RedBeanPHP sorgt dafür, dass die Datenbank wie gewünscht angelegt und mit Daten befüllt wird.

Ist man mit der Struktur zufrieden, so freezet man diese ein. Dann können nur noch Daten bearbeitet werden. Tabellen und Spalten lassen sich nicht mehr anlegen.

Dadurch hat man keinen direkten Kontakt mit der Datenbank mehr und kann es leicht für MySQL/MariaDB (bei Letzterem aber vermutlich nur die zu MySQL identischen Funktionen), SQLite und PostgreSQL einsetzen. Weitere Datenbankunterstützung gibt es mit Erweiterungen.

Hier ein kleines Beispiel:

<?php
require 'rb.php';
 
R::setup('mysql:host=localhost;dbname=datenbank',
        'nutzer','passwort');
 
//DBStruktur unveränderbar
R::freeze(false);
 
//Tabelle post anlegen
$post = R::dispense('post');
 
//Spalte titel mit Eintrag 'Überschrift' hinzufügen
$post->titel = 'Überschrift';
 
//Spalte content mit Eintrag 'Lorem Ipsum' hinzufügen
$post->content = 'Lorem Ipsum';
 
//Objekt $post schreiben und id hinzufügen
R::store($post);

Soweit so gut. Jetzt gibt es eine Tabelle mit den Spalten id, titel, content und einem Eintrag. Darauf aufbauend kann man mehrere Tabellen mit den üblichen Relationen (1-n, m-n, 1-1) verknüpfen. RedBeanPHP managet das. Ebenso der Datentyp in den jeweiligen Spalten: Gibt es zunächst lediglich eine 100 zu speichern, so wählt RedBeanPHP Tinyint. Wird der Wert auf 93.34 geändert, wird auch der Datentyp auf Double modifiziert.

Mit r::nuke(); wird eine bestehende Datenbank gelöscht – sinnvoll in der Entwicklungsphase.

Darauf aufbauend habe ich mal eine IP-Seite gebaut, deren gesammelte Informationen man weiterschicken kann. Das hilft bei unbedarften Kunden. Allerdings nutze ich nur eine Tabelle und damit gibt es auch keine Beziehungen untereinander.
Da ist noch viel anderes eigentlich unnützes Zeug mit dabei, ich hatte aber mal Lust möglichst viel zu verwenden.

Code findet ihr auf Github.

Viel Spaß!

[Update 02.04.2014 23:40]

Das mit der unsicheren Verschlüsselung wird noch vom Stempler bestätigt. Ein paar googlebare Schlagwörter gibts auch.


Ein Rant über Java

Von Mainboarder am 30.03.2014 veröffentlicht
Tags: , ,

Vermutlich ist das für einige jetzt nicht nachvollziehbar, für andere hingegen altbekannt: Java ist unfassbar großer Mist.

Ich bin gerade dabei mir Netbeans einzurichten. Netbeans weil ich Eclipse noch schlechter finde. Beide sind mit Java geschrieben und manchmal funktionieren sie.

Kaum öffne ich Netbeans das 5. mal, hängt es sich beim Start auf. Nachdem ich den Prozess abgeschossen habe, läuft es wieder.

Da wollte ich die tolle Funktion nutzen um Code direkt auf den Server mittels SFTP und Key-Authentifizierung zu laden.

Alles eingetippt und: Fehlermeldung.

Irgendwas von wegen aes-256 ist nicht bekannt.

AES ist der wohl wichtigste Algorithmus für synchrone Verschlüsselung. Und Java nicht ohne weiteres bekannt.
Es ist nicht der neueste Shizzle, sondern seit dem Jahr 2000 ein Standard. 14 Jahre sind in Sachen Technik eigentlich viel.

Zur Auflösung: Man muss Java Cryptography Extension herunterladen und in Java patchen. Dabei werden zwei Dateien überschrieben.

Warum geht das nicht von vornherein?


Blaupause für einen Imagefilm

Von Mainboarder am 21.03.2014 veröffentlicht
Tags: ,

Viele Worthülsen, Marketingsprech, kräftige Farben. Das ist was einen guten Imagefilm ausmacht. Selbst wenn man eine noch so uninteressante Firma bewirbt.

Wie man es richtig macht, zeigt der Obststandl Didi.