Sep 182014
 

Der SSL-Server-Test bei den Qualys SSL Labs hat sich als de facto Standard zum Testen der SSL-Verschlüsselung entwickelt. Es werden vier prozentuale Ratings ermittelt und eine abschließende Qualitätsstufe. Die vier Ratings lauten:

  1. Güte des Zertifikats
  2. Protokoll-Support, je neuer desto besser und je weniger alte Protokolle, desto besser.
  3. Art des Schlüsselaustauschs
  4. Güte der Verschlüsselung

In Zusammenarbeit mit meinem Kollegen Dominik Kupschke haben wir erarbeitet, wie man einen Apache 2.4 so konfiguriert, dass man ein “A+”-Rating mit 100%/95%/100%/100% erhält.

A+ Rating

Durch dieses Rating bedingt können sich Oracle Java Clients und Windows XP-Clients nicht mehr verbinden. Für normales Web Browsing reicht das typischerweise aus. Wenn es nötig ist, dass sich auch diese Clients verbinden, sind kleinere Änderungen nötig, die weiter unten beschrieben werden.

Hinweis!
Ein Apache 2.2 unter Ubuntu kann kein “A+”-Rating erreichen, weil er kein Elliptic Curve Diffe-Hellman unterstützt und einige Windows-Varianten kein Ephemeral Diffie-Hellman unterstützen.

Das Zertifikat

Ein gutes Zertifikat sollte folgende Kriterien erfüllen:

  1. Der Common Name (CN) sollte zum Hostname passen.
  2. Der Zeitbereich sollte passen, also nicht abgelaufen sein.
  3. Es sollte durch eine offizielle CA signiert worden sein.
  4. Der Schlüssel sollte mindestens 2048 Bit breit sein. Spielt Performance keine Rolle, sind 4096 Bit besser.
  5. Das Zertifikat muss mindestens mit SHA256 signiert worden sein. Neuerdings meldet SSL-Labs Intermediate CAs als “weak”, wenn sie selbst mit SHA1 signiert wurden.
  6. Das Zertifikat sollte nicht widerrufen worden sein und die CA sollte OCSP und CRL unterstützen.

Sind Intermediate Zertifikate im Spiel, sollten diese mit dem Apache-Befehl SSLCertificateChainFile ausgewiesen werden. Da der Befehl typischerweise in der Virtual Host-Umgebung benutzt wird, sollten auch nur die benötigten Intermediate CAs hier angegeben werden, was den SSL-Handshake beim Aufbau der Verbindung beschleunigt.

Der Protokoll-Support

Moderne Browser unterstützen mindestens TLSv1, was der Nachfolger von SSL3 ist. Da TLSv1.1 nur wenig Bedeutung findet, reicht die Aktivierung von TLSv1.0 und TLSv1.2 im globalen Server Context des Apache. In der Datei /etc/apache2/conf-enabled/ssl.conf wird daher das Protokoll global konfiguriert.

SSLProtocol  all -SSLv3 -TLSv1.1

Hier kann man nur ein Rating von 95% erreichen. Für 100% müsste man auch TLSv1.0 ausschalten, was aber unter heutigen Bedingungen nicht praktikabel ist, denn es sind noch viele Browser im Feld, die kein TLSv1.2 unterstützen.

Key Exchange und Cipher Strength

Diese beiden Ratings werden im Apache im selben Kommando konfiguriert. Wir bevorzugen Ephemeral Diffie-Hellman vor Elliptic Curve Diffie-Hellman. Beides sind Perfect Forward Secrecy-Verfahren und gelten als besonders sicher. Braucht man Java und Windows XP nicht, muss Apache 2.4 tatsächlich nur vier Ciphers unterstützen. Damit der Client einen Cipher aus der Prioritätenliste des Apache benutzt, ist noch das Kommando SSLHonorCipherOrder On nötig.

Hier bietet es sich an, gleich OCSP-Stapling mit zu konfigurieren. OCSP-Stapling hat den Vorteil, dass der Apache ermittelt, ob das Zertifikat noch gültig ist und diese Information dem Client mitteilt. Dazu muss allerdings die CA OCSP unterstützen. Die CA schreibt in das Zertifikat die URL des OCSP-Responders hinein. Diese kann ganz einfach mit folgendem Kommando ermittelt werden:

openssl x509 in  -noout -ocsp_uri

Wird keine OCSP-URL ausgegeben, sollte man OCSP-Stapling sicherheitshalber abschalten (das ist Default im Apache 2.4).

Die gesamte Datei /etc/apache2/conf-enabled/ssl.conf enthält daher nur fünf Kommandos:

SSLProtocol           all -SSLv3 -TLSv1.1
SSLHonorCipherOrder   On
SSLCipherSuite        DHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES256-SHA:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-SHA
SSLUseStapling        On
SSLStaplingCache      "shmcb:${APACHE_RUN_DIR}/stapling_cache(128000)"

Unterstützung für Oracle Java

Leider unterstützt Oracle Java im Gegensatz zu OpenJDK keine AES-256-Bit-Verschlüsselung. Soll Java auch unterstützt werden, senkt sich leider für die Cipher Strength das Rating auf 90%. Das gesamte “A+”-Rating bleibt jedoch erhalten. Hierfür muss nur das Kommando SSLCipherSuite durch weitere Cipher ergänzt (nicht ersetzt) werden:

  1. Oracle Java 8:
    SSLCipherSuite ...:ECDHE-RSA-AES128-GCM-SHA256
  2. Oracle Java 8 und 7:
    SSLCipherSuite ...:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-SHA
  3. Oracle Java 8, 7 und 6:
    SSLCipherSuite ...:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-SHA:AES128-SHA

Falls die Kontrolle über alle Oracle Java Installationen gegeben ist, kann durch die Installation der Java Cryptography Extension (JCE) die Unterstützung für 256-Bit Verschlüsselungen nachgerüstet werden. Die beiden .jar Files aus diesem Zip müssen einfach in den Ordner $JAVA_HOME/lib/security/ verschoben werden. Diese Maßnahme läuft allerdings client-seitig ab und ändert nichts an den server-seitigen Einstellungen für die Java-Unterstützung.

Hinweis!
Java 6 unterstützt kein Perfect Forward Secrecy!

Unterstützung für Windows XP

Obwohl Microsoft Windows XP abgekündigt hat, setzen gerade viele größere Unternehmen Windows XP mit einer erweiterten Support Lizenz ein. Sollen auch Windows XP-Clients auf die Website zugreifen können, müssen zwei Varianten unterschieden werden:

  1. Windows XP mit Internet Explorer 8
    Für Windows XP muss der Cipher DES-CBC3-SHA ergänzt werden.
  2. Windows XP mit Internet Explorer 6
    Diese Variante sollte nicht mehr in Betracht kommen, wird hier aber der Vollständigkeit halber mit ausfgelistet. Hierfür muss zusätzlich noch SSLv3 aktiviert werden, was auch das Protokoll-Rating von 95% auf 90% herunterzieht.

Hinweis!
Windows XP unterstützt kein Perfect Forward Secrecy!

Hinweis!
Wird Windows XP benötigt, Java allerdings nicht, kann Java sich trotzdem mit dem für Windows XP benötigtem Cipher DES-CBC3-SHA verbinden. Das ist an dieser Stelle kein wirkliches Sicherheitsproblem, allerdings empfiehlt es sich, trotzdem die Cipher für Oracle Java 6-8 mit zu übernehmen.

Strict Transport Security

Mit Strict Transport Security wird durch einen HTTP-Header-Eintrag dem Browser mitgeteilt, dass er für die konfigurierte Dauer diese Website ausschließlich verschlüsselt aufzurufen hat. Eine unverschlüsselte Verbindung ist für den Browser dann nicht mehr möglich. Diese Erweiterung ist schon seit ein paar Jahren in allen gängigen Browsern implementiert. Wir empfehlen eine Verwendung von einem Jahr. Die Konfiguration sollte im Virtual Host Context gesetzt sein. Das Modul mod_headers muss für die Funktion aktiviert sein.

<VirtualHost ...:443>
...
        Header always set Strict-Transport-Security "max-age=31556926"
...
</VirtualHost>

In der Online-Literatur wird fast immer ergänzend der Wert includeSubDomains erwähnt. Werden mehrere Hosts unter derselben Domain verwendet, werden dadurch zu allen anderen Servern verschlüsselte Verbindungen eingefordert. Dies ist aber typischerweise nicht erwünscht und so sollte jeder Virtual Host einzel konfiguriert werden.

Hinweis!Erst HSTS sorgt bei den SSL-Labs dafür, dass aus einem “A”-Rating ein “A+”-Rating wird.

Server Name Indication

Auf Grund des Mangels an IP-Adressen, wird häufig sog. Name Based Virtual Hosting verwendet. Dabei teilen sich eine IP-Adresse mehrere Hostnames. Das führt zu Problemen bei SSL-Verbindungen, da in der Virual Host-Umgebung das richtige Zertifikat ermittelt werden muss. Da die Verbindung erstmal nur über die IP-Adresse zustande kommt, musste der SSL-Handshake um die Server Name Indication (SNI) ergänzt werden. Hier ist nur zu erwähnen, dass Windows XP und Java 6 die SNI nicht beherrschen.

An dieser Stelle sei auch erwähnt, dass die gemachten Cipher Einstellungen auch im Virtual Host Context funktionieren. Somit können in einer Apache-Instanz mehrere Virtual Hosts konfiguriert werden, in denen unterschiedlichen Anforderungen an das SSL gestellt werden.

Referenzen:

Sep 132014
 

Es kommt häufig vor, dass man beim Apache nicht gegen eine htpasswd-Datei authentifizieren möchte, sondern das gegen eine MySQL-Datenbank erledigen möchte. Unter Ubuntu muss zu diesem Zweck das Paket libaprutil1-dbd-mysql installiert werden:

sudo apt-get install libaprutil1-dbd-mysql

Danach müssen die passenden Module aktiviert werden. Der Restart kann erfolgen, wenn die Konfiguration angepasst wurde:

sudo a2enmod authn_dbd

Für die Datenbank sollte ein eigener DB-User eingerichtet werden, der nur Lesezugriff auf die Tabelle mit den Passwörtern hat. In unserem Beispiel heißt die Tabelle User und hat mindestens zwei Spalten names login und password. Die Spalte password sollte das verschlüsselte (Warnung) Passwort enthalten. Für den Apache ergeben sich für die Basic Authentication folgende Bedingungen für den Inhalt der password-Spalte:

  1. Plain Text Passwort (sehr unsicher (!))
    Hier steht das Passwort im Klartext in der Spalte. Davon ist dringend (!) abzuraten!
  2. SHA1 Passwort (SHA1 gilt inzwischen als weich (!))
    Dabei wird das SHA1-gehashte Passwort als Base64 enkodiert und “{SHA}” vorangestellt. Also z.B.: {SHA}YusNsXhRioN2sjZ2wmOesnMsC+g=
  3. MD5 Passwort (unsicher (!))
    Dabei wird das MD5-gehashte Passwort als Base64 enkodiert und “$apr1″ vorangestellt. Also z.B.: $apr1$KJJD/S8O$rY.oEVoZ.wovVwDnu1qUK1
  4. crypt
    Diese Methode greift unter Linux auf die crypt()-Funktion der libcrypt zu. Hiermit lassen sich MD5, blowfish, SHA1, SHA-256 uns SHA-512 realisieren.

Welche Methode Apache benutzt hängt also von dem einzelnen Passwort ab, so wie es in der Datenbank steht. Es lassen sich also die Passwort-Formate mischen. Mit der crypt-Variante kann man auf SHA-512 zurückgreifen. Das in der Datenbank hinterlegte Format lautet:

$6$<salt>$<40-byte-hash>

Ich will hier zwei Methoden vorstellen, wie man einen SHA-512 mit crypt-Format für die Datenbank erzeugen kann: erstens mit C und zweitens mit Java.

SHA-512 mit C

Unter Linux lässt sich unter Verwendung der crypt()-Methode, die auch Apache verwendet, ein Text mit SHA-512 hashen. Die Methode nimmt ein Passwort und ein Salt. Dem Salt wird die Hashing-Methode in "$"-Zeichen vorangestellt. Für SHA-256 ist das $5$ und für SHA-512 $6$ vorangestellt. Das folgende Code-Beispiel erzeugt einen gehashten Text aus dem Passwort “test” und dem Salt “1234“, den der Apache verarbeiten kann:

#define _XOPEN_SOURCE
#include <stdlib.h>
#include <stdio.h>
#include <unistd.h>
 
int main(int argc, char *argv[])
{
    const char *salt = "$6$1234$";
    const char *pass = "test";
    char *result = crypt(pass, salt);
 
    printf("%s\n", result);
    return EXIT_SUCCESS;
}

Das Programm muss noch kompiliert und ausgeführt werden:

gcc crypt.c -o crypt -lcrypt
./crypt

Als Ausgabe erfolgt:

$6$1234$RtjH4vyYsWBTNKMNb.n8pesSjKQm4e/mTwC8kGIX4G29pNGyRUWvUETb/z1emQuQ8R6h6kou8eriOKZ0j2IAi0

SHA-512 mit Java

Für Java benötigt man die Apache Commons Codec. In ihr ist eine zu Linux kompatible crypt()-Methode in der Klasse org.apache.commons.codec.digest.Crypt enthalten. Der Aufruf ist zu der mit C kompatibel und sieht im Vergleich so aus:

import org.apache.commons.codec.digest.Crypt;
...
    public static String encrypt()
    {
        return Crypt.crypt("test", "$6$1234$");
    }
...

Konfiguration im Apache

Die Konfiguration besteht aus zwei Teilen

  1. Die Kontaktdaten zur Datenbank
  2. Die Konfiguration der Basic Authentication

Die Kontaktdaten zur Datenbank müssen zwingend außerhalb der Location- bzw. Directory-Tags stehen. Die Konfiguration der Basic Authentication selbst ist einfach. Neben der üblichen Kommandos AuthType, AuthName und Require muss nur der AuthBasicProvider und die DB-Query mittels AuthDBUserPWQuery angegeben werden. Der User wird über das %s in der Query ersetzt. Das Passwort wird mit dem ersten Ergebnis der ersten Spalte verglichen. Apache wandelt das Passwort automatisch in das Format um, wie das Passwort in der Datenbank hinterlegt ist. So können sogar gemischte Werte in der Tabelle hinterlegt werden.

...
<IfModule mod_dbd.c>
        DBDriver mysql
        DBDParams "host=<DB-Host> dbname=<DB-Name> user=<DB-User> pass=<password>"
</IfModule>
...
<Location ...> oder <Directory ...>
        AuthType Basic
        AuthName "Authentifizierter Bereich"
        AuthUserFile /dev/null
                 
        <IfModule mod_authn_dbd.c>
                AuthBasicProvider dbd
                AuthDBDUserPWQuery "SELECT u.password FROM User u WHERE user.login = %s"
                Require valid-user
        </IfModule>
</Location> oder </Directory>
...

Die Werte DB-Host, DB-Name, DB-User und password müssen den eigenen Gegebenheiten angepasst werden. Nachdem die Module aktiviert und der Apache konfiguriert wurde, muss er neu gestartet werden:

sudo service apache2 restart

Authentifizierung über Rollen

Das Modul mod_authn_dbd ermöglicht auch das Login über Rollen. Dazu muss statt einem Require valid-user ein Require dbd-group konfiguriert werden. Zusätzlich muss eine Query zum Ermitteln der Rolle eines Users konfiguriert werden. Dabei handelt es sich um eine Mapping-Tabelle, die vom User auf eine Gruppe zielt:

...
<Location ...> oder <Directory ...>
        ...
        Require dbd-group 
        AuthzDBDQuery "SELECT ur.group FROM UserRole ur WHERE ur.user = %s"
        ...
</Location> oder </Directory>
...

Alternative: mod_auth_mysql

Alternativ kann man auch das Modul mod_auth_mysql benutzen. Leider wird es nur bis Apache 2.2 unterstützt, so dass ich hier nicht näher auf die Konfiguration eingehe.

Referenzen:

Aug 312014
 

Um einen möglichst hohen Performance Gewinn unter MySQL zu erzielen, sollte die Größe der Buffer Pools mindestens die Größe der Datenmenge umfassen. So funktioniert MySQL wie eine in-Memory-Datenbank. Für die Default Storage Engine InnoDB ist dafür der Parameter innodb_buffer_pool_size verantwortlich. Mit dem Tool mysqltuner kann man noch Hinweise bekommen, wie man noch weitere Parameter anpassen sollte.

Ein Beispiel für eine solche Ausgabe mit mysqltuner sieht folgendermaßen aus:

-------- Performance Metrics -------------------------------------------------
[--] Up for: 1d 0h 17m 42s (3M q [42.492 qps], 150K conn, TX: 12B, RX: 304M)
[--] Reads / Writes: 98% / 2%
[--] Total buffers: 1.5G global + 18.6M per thread (150 max threads)
[OK] Maximum possible memory usage: 4.3G (27% of installed RAM)
[OK] Slow queries: 0% (10K/3M)
[OK] Highest usage of available connections: 55% (83/150)
[OK] Key buffer size / total MyISAM indexes: 16.0M/97.0K
[OK] Key buffer hit rate: 99.1% (1K cached / 17 reads)
[!!] Query cache efficiency: 6.8% (30K cached / 443K selects)
[OK] Query cache prunes per day: 0
[OK] Sorts requiring temporary tables: 0% (0 temp sorts / 13K sorts)
[OK] Temporary tables created on disk: 3% (14K on disk / 412K total)
[OK] Thread cache hit rate: 87% (19K created / 150K connections)
[OK] Table cache hit rate: 27% (584 open / 2K opened)
[OK] Open file limit used: 0% (71/41K)
[OK] Table locks acquired immediately: 100% (112K immediate / 112K locks)
[OK] InnoDB data size / buffer pool: 652.3M/1.0G

-------- Recommendations -----------------------------------------------------
General recommendations:
    Run OPTIMIZE TABLE to defragment tables for better performance
Variables to adjust:
    query_cache_limit (> 256M, or use smaller result sets)

In diesem Beispiel kann man sehen, dass die Datenmenge ohne Probleme in den Speicher passt. Ein maximaler Speicherverbrauch von 4,3 GB ist für heutige Verhältnisse schon als klein zu betrachten. Ich habe schon in meinem Artikel über die SSL-Connections beschrieben, dass man die Default-Konfiguration nicht ändern sollte und statt dessen im Verzeichnis /etc/mysql/conf.d eine weitere Konfigurationsdatei anlegen sollte. Hier können die angepassten Werte z.B. in die Datei /etc/mysql/conf.d/003-performance.cnf eingetragen werden.

Huge Pages

Einen weiteren Performance-Schub kann man erreichen, in dem der Buffer Pool Huge Pages benutzt. In meinem Artikel Huge Pages unter Linux für die JVM nutzen beschreibe ich, wie man grundlegend Huge Pages unter Linux aufsetzt. Sind die Huge Pages eingerichtet, muss der User mysql in die Gruppe eingetragen werden, die auf die Huge Pages zugreifen darf. In meinem Artikel ist das die Gruppe hugetlb. Das kann mit folgendem Befehl durchgeführt werden:

usermod -G hugetlb mysql

Damit MySQL die Huge Pages auch benutzt, muss in die Section mysqld der Parameter large-pages ergänzt werden. Danach muss MySQL nur noch neu gestartet werden:

service mysql restart

Referenz:

http://dev.mysql.com/doc/refman/5.5/en/large-page-support.html

Aug 242014
 

MySQL lässt den verschlüsselten Zugriff mit SSL zu. Dazu sollte das passende Zertifikat im Ordner /etc/ssl hinterlegt werden.

Konfiguration

Unter Ubuntu oder Debian empfiehlt es sich, die vom Paketverwalter mitgelieferte Datei /etc/mysql/my.cnf unangetastet zu lassen. Stattdessen können im Verzeichnis /etc/mysql/conf.d beliebig viele Dateien mit Endung .cnf ergänzt werden. Für die verschlüsselte Connection legen wir daher folgende Datei in /etc/mysql/conf.d/001-ssl.cnf an:

[client]
ssl-ca      = /etc/ssl/certs/ca-certificates.crt
 
[mysqld]
ssl
ssl-ca      = /etc/ssl/certs/ca-certificates.crt
ssl-cert    = /etc/ssl/localhost-cert.pem
ssl-key     = /etc/ssl/localhost-key.pem
ssl-cipher  = DHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA:AES256-SHA:AES128-SHA

Das Zertifikat für Client und Server darf nicht mit SHA256 signiert werden, ansonsten erscheint folgende Fehlermeldung, wenn man sich mit dem mysql-Client verbinden will:

mysql -p
Enter password:
ERROR 2026 (HY000): SSL connection error: ASN: bad other signature confirmation

Es gibt auch einen vermeintlichen Bug unter Ubuntu 12.04 LTS. Ein dort generierter SSL-Private Key kann nicht von MySQL eingelesen werden. Mit der Anweisung kann der Schlüssel jedoch umgewandelt werden:

openssl rsa -in /etc/ssl/localhost-key.pem  -out /etc/ssl/localhost-key.pem 

Neustart

Die Datei des Private Key darf nur für Root und der Gruppe ssl-cert lesbar sein. Daher muss der MySQL-User mysql auch in die Gruppe ssl-cert eingetragen werden. Nach diesen Eintragungen muss MySQL mit

usermod -G ssl-cert mysql
service mysql restart

neu gestartet werden.

Testen der verschlüsselten Verbindung

Jetzt kann überprüft werden, ob sich ein Client mit SSL verbindet. Dazu benutzt man einfach das Terminal-Programm mysql und verbindet sich mit beliebigen Benutzerdaten mit einer beliebigen Datenbank. Als nächstes gibt man nur:

status

ein und erhält folgende Ausgabe:

mysql> status
--------------
mysql  Ver 14.14 Distrib 5.5.38, for debian-linux-gnu (x86_64) using readline 6.2

Connection id:          5000
Current database:
Current user:           root@localhost
SSL:                    Cipher in use is DHE-RSA-AES256-SHA
Current pager:          stdout
Using outfile:          ''
Using delimiter:        ;
Server version:         5.5.38-0ubuntu0.12.04.1 (Ubuntu)
Protocol version:       10
Connection:             Localhost via UNIX socket
Server characterset:    utf8
Db     characterset:    utf8
Client characterset:    latin1
Conn.  characterset:    latin1
UNIX socket:            /run/mysqld/mysqld.sock
Uptime:                 7 days 5 hours 48 min 30 sec

Threads: 21  Questions: 321745  Slow queries: 0  Opens: 1197  Flush tables: 1  Open tables: 413  Queries per second avg: 0.514

Die Zeile mit “SSL” deutet auf den verwendeten Verschlüsselungsalgorithmus hin.

Verschlüsselte JDBC-Verbindung

Damit die typischen Application Server auch eine verschlüsselte Verbindung zu MySQL aufbauen, ist nur ein weiterer Connection Parameter notwendig: useSSL=true. Ein kompletter Connection String könnte also so aussehen:

jdbc:mysql://localhost:3306/database?autoReconnect=true&characterEncoding=utf8&useSSL=true

Referenz:

http://dev.mysql.com/doc/refman/5.5/en/ssl-connections.html

Mrz 192014
 

Seit geraumer Zeit entwickele ich mit meinem Kollegen Dominik Pieper an einem JEE-Generator, mit dem es auf einfache Art und Weise möglich ist, eine CRUD-Webanwendung zu generieren. In einem kleinen Einführungsvideo stelle ich einen kleinen Einstieg in den Generator dar.

Der generierte Code ist eine JEE6-Applikation basierend auf JSF 2.0 und EJB 3.1. Alle Masken können vollständig generiert werden. Zusätzlich kann eigener Code zusätzlich hinzugefügt werden. Somit wird eine maximale Flexibilität gewährleistet. Weitere Features sind:

  • Rollenbaseierte Sicherheit mit JAAS
  • Lokalisierung
  • Vollständige Eclipse-Integration
  • Deployment in JBoss 7 und Glassfish 3
  • u.v.a
Dez 262013
 

Die neuesten Nachrichten aus den USA über das Mitlauschen der NSA des nahezu gesamten Internet-Verkehrs hat gezeigt, dass es heißt mit Daten sehr sensibel umzugehen. Es hat sich aber auch gezeigt, dass die bloße Verschlüsselung z.B. über HTTPS alleine nicht ausreicht, da häufig Verschlüsselungsalgorithmen (z.B. RC4) eingesetzt werden, von denen man vermutet, dass die erzeugten verschlüsselten Daten von der NSA in Echtzeit mitgelesen werden können. Insbesondere Sparkassen und Banken in Deutschland bevorzugen leider immer noch RC4. Hier kann man sich z.B. bei Benutzung des Firefox dagegen schützen, indem man hier RC4 ausschaltet. Die Banken bieten häufig genug andere, bessere Verschlüsselungsalgorithmen an, sodass die Seiten weiterhin uneingeschränkt benutzt werden können. Bei itemis habe ich mit meinem Kollegen Dominik Kupschke sämtliche verschlüsselten Dienste auf sichere Algorithmen gehärtet, sodass sie z.B. gar nicht erst RC4 anbieten. Dieser Artikel soll eine Zusammenfassung dieser Ergebnisse liefern und Aufschluss über gute Verschlüsselungsverfahren bieten. Es soll hier nicht auf deren Funktionsweise eingegangen werden, hierfür gibt es genug Quellen im Internet.

Für eine gute SSL-Verschlüsselung sind vier Punkte wesentlich:

  1. Das Zertifikat
  2. Der Schlüsselaustausch für die synchrone Verschlüsselung
  3. Die synchrone Verschlüsselung
  4. Die Prüfung der Authenzität

Die verwendeten Algorithmen werden in ihrer Kombination Cipher genannt. Diese können bei den meisten Diensten konfiguriert werden.

Das Zertifikat

Das Zertifikat ist ein Public Key, der von einer Zertifizierungsstelle (CA) signiert wurde, bei einem Verbindungsaufbau gegen diese Zertifizierungsstelle verifiziert werden. kann. Die entscheidende Kenngröße ist die Breite des Schlüssels. Für die typischerweise verwendeten RSA-Schlüssel sollten mindestens 2048 Bits verwendet werden. Für wirklich sensible Daten sollten mindestens 4096 Bits verwendet werden.

Der Schlüsselaustausch

Mit dem asynchronen Verschlüsselungsverfahren wird das Verteilungsproblem des Schlüssels gelöst. Mit dem Public Key kann nur verschlüsselt werden und mit dem Private Key kann entschlüsselt werden. Wie die Namen schon andeuten, darf der Public Key in fremde Hände geraten. Der Private Key verbleibt auf dem Server und muss entsprechend gegen unberechtigten Zugriff geschützt werden. Diese Verschlüsselungsart ist gegenüber der synchronen Verschlüsselungsart sehr langsam. Es gibt Verfahren, die mit asynchroner Verschlüsselung einen zufälligen synchronen Schlüssel aushandeln, der dann für den weiteren Verbindungsverlauf verwendet wird. Hier gibt es zwei herausragende Verfahren:

  1. Diffie-Hellman
  2. Elliptic Curves

Beide Verfahren behandeln sog. Perfect Forward Secrecy. Damit werden auch im Laufe der Verbindung die synchronen Schlüssel ausgetauscht. Das erhöht die Sicherheit, da mit immensen Aufwand nur ein Teil der Verbindung geknackt werden könnte. Bei den Perfect Forward Secrecy Verfahren lassen sich aufgezeichnete Verbindungen nicht mit dem Privaten Schlüssel des Servers entschlüsseln, hier spricht von man Folgenlosigkeit.  Das Verfahren, das die Elliptic Curves benutzt wurde von dem amerikanischen Normungsinstitut spezifiziert. An diesem Verfahren hat die NSA mitgewirkt und daher steht dieses Verfahren im Verdacht, eine Backdoor der NSA zu haben. Das Diffie-Hellman-Verfahren kann mit unterschiedlichen Schlüsselbreiten arbeiten. Natürlich sollte auch hier ein möglichst breiter Schlüssel verwendet werden.

Zusammenfassung:

Auch wenn Elliptic Curves performanter sind, sollte auf dieses Verfahren verzichtet werden! Das empfohlene Schlüsselaustauschverfahren lautet DH Group 15.

Die synchron verschlüsselte Verbindung

Aus Gründen der Performance wird für den Datentransport synchrone Verschlüsselung verwendet. Hierbei wird zum Ver- und Entschlüsseln derselbe Schlüssel verwendet. Folgende Verfahren werden typischerweise angeboten:

  • RC4
  • DES
  • 3DES
  • AES
  • CAMELLIA

Man geht davon aus, dass RC4 von der NSA in Echtzeit mitgelesen werden kann. Daher sollte dieser Algorithmus dringend vermieden werden! Leider bevorzugen gerade viele Banken und Sparkassen diese Verschlüsselung. Im Firefox kann man die Verwendung dieser Verschlüsselung abschalten. Dazu ruft man die URL about:config auf. Im Suchfeld sucht man nach “rc4″. Die sechs angezeigten Werte werden mittels Doppelklick auf “false” gesetzt.

RC4

DES benutzt eine Schlüsselbreite von nur 56 Bits und ist somit ebenfalls zu schwach. 3DES ist ein dreifach hintereinander durchgeführter DES. Derzeit gilt dieser Algorithmuss noch als sicher. AES ist der bevorzugte Algorithmus. Er kann mit 128, 192 und 256 Bits Schlüsselbreite verwendet werden. AES ist über einen Wettbewerb ausgeschrieben worden, der unter Anderem die Implementierung in Soft- und Hardware erleichtern soll. AES mit 256 Bits ist daher der bevorzugte Algorithmus. Java kann in der handelsüblichen Form nur AES mit 128 Bits. Diese Verschlüsselung ist dem 3DES vorzuziehen. CAMELLIA ist ein weiterer Algorithmus, der nicht selten auftaucht und ebenfalls als sicher gilt.

Zusammenfassung:

AES256 ist optimal. 3DES ist zwar noch sicher, aber AES128 ist 3DES vorzuziehen.

Die Prüfung der Authenzität

Um beim Schlüsselaustausch sog. Man in the middle-Attacken zu vermeiden, gibt es sog. HMAC-Verfahren. Hier werden Hashing-Algorithmen eingesetzt. Häufig wird SHA eingesetzt. Lässt sich SHA 256 oder SHA2 einsetzen, sollte dieser benutzt werden. Auf MD5 sollte dringend verzichtet werden.

Gesellschaftliche Aspekte

Verschlüsselung und das Abschöpfen des Internet-Verkehrs ist für IT-Laien ein undurchschaubares Thema. Im Zusammenhang mit der NSA-Affäre taucht sehr häufig das Argument auf: “Ich habe nichts zu verbergen!”. Vielleicht veranschaulicht die Tatsache, dass wir nicht nackt rumlaufen, weil wir was zu verbergen haben, diesen Unterschied. Hier muss zwischen Unschuld und Scham unterschieden werden. Man hat sich nichts zu Schulden kommen lassen und es wird durch das Abschöpfen der Internet-Daten mit gutem Gewissen nichts ans Licht kommen. Allerdings ist im Grundgesetz das Recht auf Privatsphäre festgeschrieben. Wir hängen unsere Kontoauszüge auch nicht an den nächsten Baum und hier greift das Argument: “Wenn es den Nachbarn nicht zu interesssieren hat, dann hat es die NSA auch nicht zu interessieren!”.

Die NSA schöpft ohne zu fragen die Daten ganzer Völker ab und stellt damit ganze Völker unter Generalverdacht. Das ist der Anfang eines Überwachungsstaates und untergräbt bestehende rechtsstaatliche Demokratien.

Mehr zu diesem Thema:

Feb 232011
 

Vor ein paar Tagen war ich bei meinem Freund Tobias Braeker. Er hat sich als Dipl. Ing. (Maschinenbau) einen Kindheitstraum verwirklicht und einen Radlader im Maßstab 1:12 nachgebaut. Der O&K L25 ist aus Edelstahl gefertigt, wiegt stattliche 12 kg und kann bis zu 9 kg heben. Das Modell ist sehr detailliert gearbeitet. Jedes Rad wird durch einen eigenen Glockenankermotor (Faulhaber) angetrieben, die Schaufel wird hydraulisch betätigt. Ein Soundmodul sorgt für Hörgenuss, denn das Motorengeräusch passt zu den gesteuerten Fahrkommandos. Natürlich ist das Modell auch vorbildlich mit Leuchten (Blinker, Rückfahrscheinwerfer, etc.) ausgestattet. Übrigens kann die Schaufel hydraulisch durch ein anderes Anbaugerät ausgewechselt werden.

Radlader

Die Steuerung ist ein waschechtes Embedded System. Sie beinhaltet den Empfänger, die Motorensteuerung, die Sound- und Lichtsteuerung. Der linke Steuerhebel bedient das Fahrzeug selbst, der rechte Steuerhebel bedient die Schaufel. Die Bedienung braucht natürlich Übung, denn meistens ist man es gewöhnt, mit links die Geschwindigkeit und mit rechts die Lenkung zu bedienen. Es macht aber in jedem Fall viel Spaß, Sand und Steine durch das Gelände zu transportieren.

Tobias verkauft das Modell als Bausatz oder als Fertigmodell. Die Preise können über seine Homepage erfragt werden. Auf YouTube können weitere interessante Filme mit dem L25 betrachtet werden. Für die Zukunft plant er die Konstruktion eines Kippers. Ich bin mal gespannt :-)

Feb 092011
 

Linux bietet auf x86-Architekturen die Möglichkeit, statt der normalerweise 4K großen Memory Pages auch 2M große Pages zu nutzen. Der Vorteil hierbei ist, dass die MMU der CPU deutlich seltener ein Address Mapping von virtuellem Speicher auf die physikalische Adresse durchführen muss. Dieser Vorgang wird auch Table Walk genannt. Er hat den Nachteil, dass der Zugriff auf diese Mapping-Tabellen am Cache vorbei durchgeführt werden muss und somit sehr langsam ist. Das Ergebnis des Table Walks landet seinerseits in einem speziellem Cache, dem sog. TLB. Es bietet sich unter Linux an, Software mit hohem Speicherverbrauch diese Huge Pages oder Huge Tables nutzen zu lassen. Gerade Server-Prozesse wie JBoss fallen da schnell ins Auge.

Will man unter Java diese sog. Huge Pages verwenden, reicht da die JVM-Option -XX:+UseLargePages. Allerdings ist das nicht die gesamte Arbeit. Dazu muss man den Linux-Kernel anweisen, Huge Tables zur Verfügung zu stellen. Dazu muss man sich erst klar werden, dass Huge Tables dem allgemeinen Memory Pool entzogen wird und nicht mal dem Linux Caching mehr zur Verfügung steht. Es ist also Speicher, der dem Java-Prozess dediziert zur Verfügung steht. Es empfiehlt sich, 512M mehr als Huge Tables bereitzustellen, als man mit -Xmx der virtuellen Maschine zur Verfügung stellt. Hat man 8G RAM, und will man 3,5G dem Java bereit stellen. Müssen wir 4G an Huge Tables bereitstellen. Das geschieht in der Datei /etc/sysctl.d/hugetlb.conf. Dort müssen drei Einträge gemacht werden:

  1. kernel.shmmax=<max-shared-memory-in-bytes>
    Da Huge Tables als Shared Memory allokiert werden, muss die Maximalzahl hier auf die verwendete Speichergröße hochgesetzt werden.
  2. vm.nr_hugepages=<amount>
    Die Zahl der Huge Tables selbst. Will man 4G an Huge Tables haben, muss hier eine 2048 eingetragen werden, weil 2048 * 2M = 4G ist.
  3. vm.hugetlb_shm_group=<gid>
    Hier muss die Usergroup eingetragen werden, die Huge Tables benutzen darf.

Sind die Werte eingetragen, muss man ein sysctl -p -f /etc/sysctl.d/hugetlb.conf ausführen, um die Werte dem Kernel mitzuteilen. Hat der Server schon eine relativ lange Uptime, muss er vielleicht durchgestartet werden. Grund ist, dass die Huge Tables im Stück im Speicher liegen müssen. Da es auch beim Hauptspeicher eine Fragmentierung geben kann, kann evtl. die Zuteilung der Huge Tables nur teilweise gelingen. Kontrollieren kann man das, indem man cat /proc/meminfo ausführt. Das ergibt dann so eine Ausgabe wie:

HugePages_Total:     512
HugePages_Free:      512
HugePages_Rsvd:        0
HugePages_Surp:        0
Hugepagesize:       2048 kB
DirectMap4k:       47040 kB
DirectMap2M:     4147200 kB

Hier sind 512 (= 1G) Huge Tables zugewiesen worden. Als Nächstes muss dem entsprechenden Benutzer, der die Huge Tables benutzen möchte, die Erlaubnis geben, diesen Speicher fest im Speicher zu halten, so dass er nicht im Swap landen kann. Das erfolgt in der Datei /etc/security/limits.conf. Hier wird die Größe des Wertes kernel.shmmax aus der Datei /etc/sysctl.d/hugetlb.conf übernommen. Die Einträge lauten:

<username> soft memlock <locked-memory-in-kbytes>
<username> hard memlock <locked-memory-in-kbytes>

Benutzt man für den Usernamen “*”, gilt diese Einstellung für alle Benutzer, ausgenommen root. Für ihn muss man explizit einen Eintrag machen, wenn gewünscht. Üblicherweise läuft JBoss nicht als root, sondern hat einen dedizierten Benutzer, den man dann auch hier eintragen sollte. Hierbei muss man darauf achten, das PAM so konfiguriert ist, dass die Limits auch als Benutzer entsprechend konfiguriert werden. Hat man als Shell die bash, kann man mit ulimit -a überprüfen, ob der Wert max locked memory korrekt gesetzt wurde. Ein Reboot ist hierfür nicht erforderlich!

jboss@master:~$ ulimit -a
core file size          (blocks, -c) 0
data seg size           (kbytes, -d) unlimited
scheduling priority             (-e) 20
file size               (blocks, -f) unlimited
pending signals                 (-i) 16382
max locked memory       (kbytes, -l) 3145728
max memory size         (kbytes, -m) unlimited
open files                      (-n) 65536
pipe size            (512 bytes, -p) 8
POSIX message queues     (bytes, -q) 819200
real-time priority              (-r) 0
stack size              (kbytes, -s) 8192
cpu time               (seconds, -t) unlimited
max user processes              (-u) unlimited
virtual memory          (kbytes, -v) unlimited
file locks                      (-x) unlimited

Sind die Huge Tables verfügbar und die Limits gesetzt, kann man jede JVM mit der Option -XX:+UseLargePages starten und Java benutzt Huge Tables.

Kann Java keine Huge Tables allokieren, kommt es zu folgender Fehlermeldung:

Java HotSpot(TM) 64-Bit Server VM warning: Failed to reserve shared memory (errno = 22).

In diesem Falle allokiert Java “normalen” Speicher. Wenn zu viele Huge Tables belegt wurden, kann es dann zu einem Engpass an normalen Speicher kommen. Die Wahl der Option -Xmx ist daher wichtig!

Unter JBoss sollte diese Option in die Datei $JBOSS_HOME/bin/run.conf übernommen werden.

oAW-Tools jetzt Open Source

 Eclipse, MDSD, Software  Kommentare deaktiviert
Jul 092010
 

Die oAW-Tools sind ab sofort auf SourceForge als Open Source verfügbar. Die oAW-Tools beinhalten eine Reihe kleiner Komponenten und Beautifier. Die Startseite ist unter http://sourceforge.net/apps/trac/oaw/ erreichbar. Der Quellcode kann aus dem Subversion-Repository heruntergeladen werden. Ferner gibt es noch eine Update-Site, die direkt aus dem Eclipse benutzt werden kann.

Viel Spaß!


Jul 072010
 

Das Projekt der modell(-bau-)basierten Eisenbahnsteuerung ist ab sofort auf SourceForge als Open Source verfügbar. Die Startseite ist unter http://sourceforge.net/apps/trac/mrw/ erreichbar. Der Quellcode und die Schaltungen können aus dem Subversion-Repository heruntergeladen werden.

Viel Spaß!


Apr 012010
 

Seit der Veröffentlichung von EJB3.0 ist der Umgang mit Persistenz erheblich vereinfacht worden. Hintergrund ist die Verwendung sog. POJOs (Plain Old Java Object), die den Entwicklungsvorgang erheblich vereinfachen. Völlig in den Hintergrund ist dabei die Verwendung sog. POPOs (Plain Old Paper Object) geraten. Gerade diese Variante wurde schon von den alten Ägyptern eingesetzt. Es ist der Nachweis gelungen, dass die Persistenz über mehrere tausend Jahre erhalten bleibt. Den Beweis, die Persistenz über diesen Zeitraum aufrecht erhalten zu können, müssen die POJOs noch erbringen, ist die damit einhergehende Technologie erst ein paar Jahrzehnte alt.

Ein POPO wird angelegt.

Bild 1: Ein POPO beim Anlegen. Dieses wird später offline gestellt, um gezielt einen Nachschub-Auftrag durchführen zu können.

POPOs stehen in ihrer Funktionalität den POJOs in nichts nach, sind doch alle Patterns gemäß des CRUD-Paradigmas verwendbar. Selbst das redundante Schreiben und getrennte Aufbewahren ist damit möglich und somit auch das Lesen parallelisierbar. Auch Transaktionen mit Commit und Rollback stellen kein Problem dar. Einzig die Zugriffszeit ist mit POPOs ein Problem. Der größtenteils biomechanische Zugriff kann unter Umständen mehrere Minuten bis Stunden dauern. Gerade hier spielt die Parallelisierbarkeit mit enormen Zeitgewinn zu Lasten der Betriebskosten eine wesentliche Rolle. Typischerweise sind auch die räumlichen Erfordernisse größer als bei POJOs, wenngleich die klimatischen Bedürfnisse z.B. an Trockenheit und Lichteinflüsse vergleichbar sind.

Ein Storage für POPOs

Bild 2: Dieses Bild zeigt ein Storage für POPOs. Es ist deutlich erkennbar, dass Zugriffe hierauf parallel ablaufen können. Auch der größere Platzaufwand lässt sich hier unschwer erkennen.

Auch in heutiger Zeit sind POPOs nicht aus dem Alltagsleben wegzudenken. Es gibt sogar Varianten für den Embedded Bereich. Auch das Offline-Stellen für z.B. Nachschub-Aufträge lässt sich realisieren und sind sogar praktikabler, als POJO-Varianten. Insgesamt darf man gespannt sein,wie lange sich diese Technologie halten wird.

Ein POPO wird zum Löschen vorgemerkt.

Bild 3: Dieses POPO ist für das endgültige Löschen vorgemerkt. Dieser Vorgang kann durch ein Rollback wieder rückgängig gemacht werden.


Mrz 022009
 

Auf der Internetpräsentation der Firma itemis AG ist ein Artikel über die modellbasierte Entwicklung einer Eisenbahnsteuerung veröffentlicht worden. Zu diesem Zweck wurde eigens eine elektronische Steuerung auf Basis des ATmels ATmega32 Mikrocontrollers entwickelt. Es wird an zwei Stellen modellbasiert gearbeitet: Zum einen wird der Gleisplan durch ein EMF-basiertes Modell beschrieben. Dieses Modell wird in der Stellwerks-Software interpretiert, um Fahrstrecken zu ermitteln und die Eisenbahnanlage zu überwachen. An zweiter Stelle wird das Steuerungsprotokoll als Zustandsautomat der Mikrocontroller beschrieben. Daraus wird ein Teil der Firmware generiert, der für die Kommandoverarbeitung zuständig ist.

Die Modellierung des Gleisplans verwendet ein eigenes Metamodell, das mittels der oAW-Cartridge UML2ECore in einen EMF-Editor im Eclipse umgewandelt. Das Metamodell und der Zustandsautomat des Mikrocontrollers wurde mit MagicDraw modelliert.

Der gesamte Artikel kann hier eingesehen werden:

http://www.itemis.de/29970/

Nov 182008
 

Auf dem Yakindu-Tag wurde die modell(-bau-)getriebene Eisenbahnsteuerung vorgestellt. Dabei wurde der Gleisplan schon modellgetrieben generiert. Bisher war die Firmware der CAN-Knoten als Referenzimplementierung noch klassisch implementiert. Die Kommandoverarbeitung in der Firmware der CAN-Knoten war ein unschönes Stück Spaghetti-Code. Aus diesem Grund wurde ein Zustandsdiagramm gefertigt, das die Betriebszustände der CAN-Knoten enthält. Die eingehenden Kommandos sind als Zustandsübergänge modelliert. Aus diesem Diagramm wird mit Hilfe von openArchitectureWare der Code für die Kommandoauswertung generiert.

Zustandsdiagramm des CAN-Knotens

Der generierte Code enthält zwar relativ viele Callbacks und switch/case-Anweisungen und bläht den Binärcode um ca. 1,5 KByte auf. Das ist aber nicht weiter schlimm, da jetzt noch Platz für ca. 18 KByte im Flash des ATmega32 vorhanden ist. Ein weiterer Vorteil ist, dass der generierte Code wesentlich übersichtlicher aussieht. Änderungen und Erweiterungen der Steuerkommandos lassen sich jetzt viel leichter einpflegen. Die Integration des generierten Codes in den bestehenden Firmware-Rahmen gestaltete sich als unproblematisch, da der restliche klassisch implementierte Teil nur aus Service-Methoden zur Ansteuerung der Hardware dient.

Jul 232008
 

Jede Festplatte besitzt einen eingebauten Standard, der vielleicht Jemandem beim Booten als BIOS-Meldung aufgefallen ist, aber noch nicht aktiv genutzt hat: Das S.M.A.R.T. Es ist eine Abkürzung für Self-Monitoring, Analysis and Reporting Technology. Es handelt sich dabei um die Möglichkeit, den Zustand der Festplatte zu überwachen. Hier werden Werte wie Start/Stop-Zyklen, Betriebssystunden und Fehlerzähler verwaltet. Da heutzutage jede Festplatte über diesen Standard verfügt, macht es gerade in IT-Infrastrukturen Sinn, diese Werte permanent zu überprüfen. Selbst bei Desktop-Rechnern oder Laptops macht es Sinn, von Zeit zu Zeit über diesen Standard den Zustand der Festplatte abzufragen.

Unter Linux gibt es für die automatische Überwachung die sog. smartmontools. Diese haben das Abfragetool smartctl, was den Zustand einer Platte abfragen kann. Ferner gibt es noch einen Daemon, der in regelmäßigen Abständen den Zustand der Festplatte(n) abfragt und im Fehlerfalle sogar eine EMail verschickt. Dadurch ist eine engmaschige Überwachung der Festplatten gewährleistet. Einer Studie von Google zufolge, kann auf diesem Wege ein Ausfall einer Festplatte zu 64% Wahrscheinlichkeit rechtzeitig vorhergesagt werden. Häufigster Indikator ist das Bad-Block-Remapping. Wird ein Festplattensektor schadhaft, verwendet die Festplatte automatisch einen Alternativblock. Dieser Vorgang wird von SMART mitgezählt. Häufen sich Remappings, wird es Zeit, die Platte auszuwechseln. Auch ein relativer langsamer Temperaturanstieg über Wochen ist ein Indikator für ein baldiges Ableben der Mechanik. Platten in kühlen Umgebungen (z.B. durch eine Klimaanlage) sollten nicht über 40 Grad überschreiten, tun sie es trotzdem, kann das ein Indikator für einen baldigen Ausfall sein. Was durch S.M.A.R.T nicht erfasst werden kann, ist der Ausfall der Elektronik.

Ich kann nur Jedem IT-Verantwortlichen die smartmontools ans Herz legen. Mir selbst haben die Tools schon viele Crashes vorhergesagt und größeren Schaden abgewendet. Gerade Betreiber von Root-Servern sollten auf den Einsatz der smartmontools nicht verzichten, da gerade dort die eingesetzten Festplatten nicht redundant in RAID-Verbünde eingegliedert sind.

Quellen:
http://labs.google.com/papers/disk_failures.pdf
http://smartmontools.sourceforge.net

Beispiel für ein Mail-Script:

SMART_MSG=/tmp/smart.msgcat > $SMART_MSG

echo "======================================================================" >>$SMART_MSG

# Append the output of smartctl -a to the message:

/usr/sbin/smartctl -a -d $SMARTD_DEVICETYPE $SMARTD_DEVICE >> $SMART_MSG

echo "======================================================================" >>$SMART_MSG

echo "-- " >>$SMART_MSG

echo "System administrator" >>$SMART_MSG

# Now email the message to the user at address ADD.  Solaris and

# other OSes may need to use /bin/mailx below.

/usr/bin/mail -s "$SMARTD_SUBJECT" $SMARTD_ADDRESS < $SMART_MSG

rm $SMART_MSG

und die Einbindung in die smartd-Konfiguration über die Datei smartd.conf:

/dev/sda -d ata -S on -m <EMail-adresse-des-Admins> -a -M exec /root/bin/smartmail.sh
Jul 102008
 

Nach der Entwicklung der CAN-Controller, wird jetzt als nächster Schritt das Bauen der Prototypen angegangen. An ihnen kann man das erste Mal testen, wie sich mehrere CAN-Controller an einem Bus verhalten. Erwartungsgemäß funktioniert der CAN-Bus mit mehreren Teilnehmern gemäß Spezifikation. Auch das Flashen einer neuen Firmware funktioniert einwandfrei. Dabei wird ein Bootloader verwendet, der die Firmware über den CAN-Bus entgegennimmt.

Auf dem Bild kann man vier CAN-Teilnehmer erkennen. Man kann inzwischen auch von den itemis Hardware Labs Lünen sprechen.

itemis Hardware Labs Lünen

Als nächster Schritt wird ein Platinen-Layout entwickelt, um die endgültigen CAN-Controller zu erhalten. Desweiteren werden jetzt die Schaltungen für die Leistungselektronik entwickelt. Schließlich sollen die CAN-Controller ja eine Modellbahn steuern.

Subversion im Alltag

 Linux, Systemmanagement  Kommentare deaktiviert
Jul 032008
 

Subversion wird seit acht Jahren entwickelt und hat im Februar 2004 die erste stabile Version 1.0 erreicht. In dieser Zeit wurden viele Entwickler von den Vorzügen von Subversion überzeugt. Wer CVS kennt, wird sich als Entwickler nicht wensentlich umgewöhnen müssen, da das Konzept Copy-Modify-Merge gleich geblieben ist. Administrativ hat sich allerdings Einiges geändert. Die Versionsdaten werden wie in einer Datenbank gespeichert. Die Backend-Schnittstelle ermöglicht es, verschiedene Backends zu verwenden. Der Vorteil gegenüber CVS ist hier, dass die Dateien nicht direkt manipuliert werden können, da sie nur als Binärdaten vorliegen. Bei CVS werden in einer ASCII-Datei Diffs gespeichert, sodass Manipulationen möglich sind.

In der Praxis hat sich Subversion durch die Stabilität bewährt. Der Verwaltungsaufwand ist nur minimal. Nach dem Einrichten mit svnadmin kann man sofort arbeiten. Es gibt aber noch ein paar Tipps, wie man durch Feintuning die Disziplin der Entwickler fördern kann. Zwei herausragende Punkte sind einerseits die Commit-Meldungen und andererseits die anonymen Commits. Unter Subversion sind leere Commit-Meldungen möglich. Möchte man die Entwicklungsgeschichte nachverfolgen, sind leere Kommentare teilweise frustrierend. Wenn Dutzende von Revisions committed wurden, ohne dass sich scheinbar was geändert hat, muss man ein Difftool bemühen, um Änderungen nachverfolgen zu können. Ähnlich verhält es sich bei anonymen Usern. Subversion lässt bei falscher Konfiguration anonyme Commits zu.

Um leere Commit-Meldungen zu unterbinden gibt es das Mittel der Hook-Skripte. Diese werden zu bestimmten Zeitpunkten während eines Commits aufgerufen. Dadurch können Plausibilitätschecks durchgeführt werden und ggf. ein Commit verhindert werden. Baut man in den sog. pre-commit-hook eine Prüfung ein, die eine leere Meldung verhindert, bleiben die Log-Meldungen deutlich informativer

Das folgende Beispiel zeigt das pre-commit-Skript. Es überprüft, ob mindestens 15 Zeichen und alphanumerischer Text eingegeben wurde.

#!/bin/bash

REPOS="$1"
TXN="$2"

LOG=`svnlook log -t "$TXN" "$REPOS"`
COUNT=`echo $LOG |wc -c`

# Check for at least some chars.
if [ $COUNT -lt 15 ]
then
echo 1>&2
echo 1>&2  "Need at least 15 characters for commit message!"
exit 1
fi

# Check for some clear text characters
echo "$LOG" | grep "[a-zA-Z0-9]" > /dev/null && exit 0
echo 1>&2
echo 1>&2  "Need a clear text message!"
exit 1

Die Konfiguration, um anonyme Commits zu verhindern, muss im Apache erfolgen. In unserer Firma authentifiziert und authorisiert Apache gegen OpenLDAP. Hier kann eine Authentifizierung erzwungen werden und anonymer aber lesender Zugriff erlaubt werden. Bei Schreibzugriffen wird eine Authorisierung gegen eine LDAP-Gruppe durchgeführt.

Die Konfiguration für ein vollständiges Subversion-Repository sieht wie folgt aus:

<IfModule mod_dav_svn.c>

<Location /subversion/webdev>>
        DAV svn
        SVNPath /data/subversion/webdev
        Options +Indexes
        Allow from all

        AuthType Basic
        AuthName "Subversion Repository: webdev"

        AuthzLDAPAuthoritative off
        AuthBasicProvider ldap
        AuthLDAPURL "ldap://master.domain.de slave.domain.de/ou=Users,dc=domain,dc=de?uid?sub?(objectClass=*)"
#       <LimitExcept GET PROPFIND OPTIONS REPORT>
                Require ldap-group cn=webdev,ou=Groups,dc=domain,dc=de
#       </LimitExcept>
        AuthLDAPGroupAttribute memberUid
        AuthLDAPGroupAttributeIsDN off
        SSLRequireSSL
<Location>
</IfModule>

Diese Konfiguration verlangt eine Authorisierung gegen die LDAP-Gruppe webdev. Soll lesender anonymer Zugriff gestattet werden, müssen die # entfernt werden. Zusätzlich wird durch die Direktive SSLRequireSSL SSL-Verschlüsselung verlangt.

Quellen:
www.apache.org
subversion.tigris.org

Mehr Komfort mit C++

 Eingebettete Systeme  Kommentare deaktiviert
Jun 212008
 

In der Elektronikpraxis ist ein Artikel von mir erschienen, der sich mit der Verwendung von C++ im Embedded Systems beschäftigt. Obwohl mit C++ schon seit über 20 Jahren entwickelt wird, hält diese Sprache nur langsam in die Mikrocontroller-Programmierung Einzug. Sie enthält aber viele Sprachkonstrukte die die Qualität der Firmware erheblich verbessern kann und dem Entwickler die Arbeit vereinfacht. Ein Grund für die zögerliche Nutzung liegt im höheren Ressourcen-Bedarf. Viele moderne Mikrocontroller haben diese Hürde aber nicht mehr.

Der gesamte Artikel kann hier eingesehen werden: http://www.elektronikpraxis.vogel.de/themen/embeddedsoftwareengineering/implementierung/articles/120537/

Jun 122008
 

Auf den ersten Blick scheinen Modellbau und Anforderungsverwaltung (= Requirements Engineering) nichts miteinander zu tun zu haben, aber bei der Erstellung der Stellwerks-Software wird deutlich, wie viel Komplexität hinter diesem Thema steckt. Beim Entwurf einer Modellbahnsteuerung stand am Anfang die Idee, möglichst kostengünstig mit Standardtechnologien eine Steuerung zu entwickeln, um simpel Weichen schalten zu können. Dabei stand im Wesentlichen die Technik im Vordergrund. Nach und nach hat sich gezeigt, dass es die Software-Steuerung am Front-End in sich hat.

Anfangs stand die Darstellung des Soll-Zustand im Vordergrund. Es wurde über Start/Via/Ziel-Checkboxen ein Fahrtweg vorgegeben. Dieser soll so eingestellt werden, dass nur freie Gleise benutzt werden. Wurde eine freie Fahrstraße gefunden, sollen die Weichen geschaltet und die Signalfreigabe erteilt werden. Diese Anforderung war für den Anfang schnell implementiert. Bei genauerer Betrachtung zeigt sich, dass die Darstellung des Ist-Zustandes inkl. des Soll-Zustandes für den Benutzer erforderlich ist. Beim Studium von Berichten, wie realen Stellwerke funktionieren, hat sich gezeigt, dass das Thema sehr komplex ist. Die erste Idee war insofern nicht falsch angedacht. Tatsächlich erfolgt beim Suchen einer Fahrstraße erst eine Route, die frei ist. Diese muss durch das Stellen von Weichen erreicht werden. Dieser Vorgang heißt in der Realität Weichenumlauf. Hierbei ist der Vorgang an sich interessant, weil eine Rückmeldung erfolgen muss, dass die sog. Weichenendlage erreicht ist. Danach wird die Weiche verschlossen. Dieser mechanische Vorgang soll verhindern, dass sich durch die Erschütterung des darüberfahrenden Zuges die Weiche verstellt und somit den Zug zur Entgleisung bringt. Desweiteren ist eine versehentliche Umstellung durch den Fahrdienstleiter im Stellwerk dadurch nicht mehr möglich. Der mechanische Verschluss ist im Modellbau nicht möglich, wohl aber die Rückmeldung. Ein einfacher Schalter soll das Durchbrennen des Antriebes verhindern. Somit ist nur eine Spule unter Strom. Es lässt sich also mit einem hochohmigen Strom festellen, in welcher Lage sich die Weiche befindet ohne die Weiche durch den Strom selbst zu stellen. Somit kann diese Information dafür ausgewertet werden, ob eine Fahrstraße korrekt geschaltet wurde.

Erst danach kann eine Gleisfreigabe erfolgen. Die Realität weicht an dieser Stelle erheblich vom Modell ab. Die Gleisfreigabe erfolgt in der Realität durch Signale. Diese haben eine sog. punktuelle Zugbeeinflussung. Überfährt man ein auf rot stehendes Signal, löst ein unter dem Signal angebrachter Schwingkreis an der Lok eine Zwangsbremsung aus. Beim Modellbau sind Signale eher Kosmetik, allerdings kann keine Lok fahren, wenn kein Strom auf dem Gleis anliegt. Somit werden der Optik halber erst die Signale gestellt und danach erfolgt die Gleisfreigabe über das Aufschalten von Fahrstrom.

Jeder dieser Vorgänge ähnelt einer Transaktion so wie wir es aus der Informatik her kennen. Ein Vorgang (Weichenschalten) muss vollständig erfolgreich ausgeführt werden. Erst danach darf der nächste Vorgang (Signale schalten) folgen, denn sonst würde der Zug schon die Freigabe erhalten, während sich noch fatalerweise die Weichen schalten. Ist ein Vorgang nicht erfolgreich, müssen ggf. Vorgänge zurückgenommen werden. Weichen müssen nicht wieder zurückgestellt werden, wohl aber Signale und die Gleisfreigaben.

Die Steuerungs-Software muss diesen Anforderungen Rechnung tragen. Die Mikrocontroller müssen sowohl für eine korrekte Ansteuerung der Geräte (Weichen, Signale und Gleise) sorgen, eine korrekte Zustandsmeldung liefern und Zustandsmeldungen korrekt melden. Die Steuerungs-Software am Front End muss diese Meldungen korrekt darstellen und Fehlbedienungen ausschließen. Speziell bei der Fehlbedienung kommt eine Simulation des Verschlusses ins Spiel. Ist eine Fahrstraße erst einmal eingestellt, dürfen alle beteiligten Geräte nicht mehr verstellt werden. Mangels mechanischen Verschlusses kann das bei Modellweichen durch manuelles Verstellen trotzdem passieren. In diesem Fall muss eine dadurch betroffene Fahrstraße sofort deaktiviert werden. Desweiteren spielt das visuelle Feed-Back eine entscheidende Rolle. Da Mechanik im Spiel ist, dauert das Einstellen der Fahrstraße ggf. mehrere Sekunden. Dieser Vorgang muss auf der GUI dargestellt werden, ohne dass diese dadurch bedienungsunfähig wird. Das wird durch Multi-Threading erreicht. Das Versenden von Schaltkommandos wird in einem eigenen Thread durchgeführt. Diese Kommandos werden pro Vorgang in Batches zusammengefasst. Das Empfangen von Rückmeldungen erfolgt wiederum in einem eigenen Thread. SWT kann architekturbedingt nur Änderungen an der eigenen GUI im Haupt-Thread durchführen. Somit ist Message Passing nötig, um Zustandsänderungen in der GUI des Haupt-Threads visualisieren zu können. Optisch wird das so dargestellt, dass der Gleisplan in schwarz-weißen Strichen dargestellt wird. Durch Loks belegte Gleise werden immer orange dargestellt. Eine sich schaltende Fahrstraße ist schwarz-gelb. Weichen im Umlauf haben blinkende Weichennummern (in einem weiteren Thread als TimerTask implementiert). Ist die Fahrstraße erfolgreich eingestellt, wird diese grün dargestellt. Diese Darstellung ähnelt der eines voll-elektronischen Stellwerks der Realität. Hier werden weitere Sicherungsmaßnahmen genutzt, die im Modellbau schlicht Overkill wären: Ein Farbbalken, der zeigen soll, dass der Bildschirm auch wirklich alle Farben zeigen kann. Das alles nochmal als blinkender Farbbalken. Zusätzlich ist der darstellende Rechner mit zwei Grafikkarten ausgestattet, welche das Gleiche darstellen müssen.

Somit zeigt sich, dass Sicherungstechnik der Realität auch im Modellbau Anwendung findet. Viele Anforderungen zeigen sich erst währen der Implementierungsphase. Man muss einerseits den Entwicklungsprozess darauf abstimmen, andererseits muss die Architektur der Software so gestaltet sein, dass sich erweiterte Anforderungen leicht ergänzen lassen.

Quellen:
http://www.stellwerke.de
http://www.uni-stuttgart.de/iev/index.htm?/vwi/lupse/LUPSE.HTM

Jun 052008
 

Seit geraumer Zeit programmiere ich mit einem Kollegen der itemis AG an einer Mikrocontroller-gesteuerten Modellbahnanlage. Im Großen und Ganzen ging die Entwicklung sehr zügig voran. Es kam aber zu einigen Fallstricken, über die ich hier gerne mal berichten möchte. Zuerst bleibt zu erwähnen, dass die Entwicklungsumgebung für die AVR-Mikrocontroller recht gut sind. Die Gesamtanlage ist ein relativ komplexes System. In der Kette wurden Stellwerkssoftware in Java, ein Übertragungskanal über RS232-Schnittstelle an ein CAN-Gateway mit ATmega32 und MCP2515 gekoppelt. Daran sind mehrere CAN-Knoten derselben Hardware miteinander gekoppelt. Die Firmware ist C programmiert. Die Entwicklung aller Komponenten kann sowohl unter Windows, als auch unter Linux erfolgen. Linux hat den Vorteil, dass auch mal Remote entwickelt werden kann.

Nachdem die erste Schaltung gesteckt war, wurde schnell deutlich, dass die Kommunikation zum CAN-Controller nicht mehr stattfand. Offensichtlich ist die Kommunikation über das SPI zusammengebrochen. Ein kurzes Kontrollprogramm zeigt mithilfe eines Oszilloskops, dass die Verbindung tatsächlich zusammengebrochen ist. Ein genauer Blick ins Datenblatt des ATmega32 zeigte schnell, woran es lag: Es gibt einen Pin names Slave Select, der das SPI-Interface von außen in den Slave-Modus versetzen kann. In diesem Fall war er als offener Eingang – also ohne Anschluss – konfiguriert und beschaltet. Die Lösung bestand darin, das /CS-Signal für den MCP2515 als Ausgang daran anzuschließen.

Ein weiterer Punkt war, dass ein CAN-Knoten nach kurzer Betriebszeit nur durch einen Kaltstart wiederzubeleben war. Die Ursache war schnell gefunden: Als Takt wurde der Taktausgang des MCP2515 verwendet. Der Taktausgang ist nach einem Reset per Default eingeschaltet, kann aber per Software ausgeschaltet werden. Wenn der Takt erst einmal aus ist, besteht per Software keine Möglichkeit mehr, den Takt zu reaktivieren. Ein eigener Quartz für den ATmega32 bestätigte die Vermutung. Warum der Takt ungewollt ausgeschaltet wurde, wurde nicht geklärt. Vermutlich wurde durch eine Race Condition das entsprechende Register mit falschen Daten beschrieben. Ein ausführlicher Code Audit hat das Problem behoben, denn der CAN-Knoten funktioniert jetzt einwandfrei.

Zum guten Schluss haben wir noch ein Problem gehabt, dessen Lösung sich lange hingezogen hat: Es gingen CAN-Frames verloren. Das kann sehr unangenehm sein, denn es wird ein Messaging System vorausgesetzt, dass sich dadurch auszeichnen soll, dass nicht dauernd Informationen und Zustände abgefragt werden sollen (Polling). Es darf also keine Information verloren gehen. Interessanterweise ist dieser Effekt gehäuft beim Konfigurieren der CAN-Knoten aufgetaucht. In diesem Fall ist sporadisch ein Reset aufgetaucht. Ein Reset war nach der Konfiguration gewollt. Dieser hier tauchte aber während der Konfiguration auf. Die erste Vermutung, dass ein fehlkonfigurierter Interrupt eine nicht konfigurierte Interrupt Service Routine anspringt, hat sich nicht erhärtet. Woher kommt aber der Reset? Ein dummer Zufall brachte des Rätsels Lösung, als im Millisekunden genauen Logfile eine Pause von etwa 700 Millisekunden nach dem Ende der Konfigurierung auftauchte. Das ist gefährlich nahe am Timeout des Watchdogs, der mit einer Sekunde aktiv war. Laut Datenblatt dauert das Speichern eines Bytes im EEPROM 8.5 Millisekunden. Das Speichern einer Flash Page (128 Bytes) hingegen nur etwa fünf Millisekunden. In dieser Zeit kann kein Watch Dog Reset durchgeführt werden. Die Lösung bestand also darin, während dieser Zeit den Watch Dog zu deaktivieren. Eines hat die lange Suche aber noch gebracht: Der Code ist jetzt wesentlich effizienter und aufgeräumter.

Zusammenfassend kann man feststellen, wie eng gerade in Embedded Systems alle Komponenten miteinander abgestimmt sein müssen. Zwei scheinbar unabhängige Komponenten (Watch Dog und EEPROM) haben letztlich doch miteinander zu tun. Es lohnt sich immer, bei Problemen zuerst in Ruhe (!) einen Blick in die Datenblätter zu werfen. Wie bei der SPI-Schnittstelle kommt man dann schnell auf die Lösung. Wenn man mit Interrupts arbeitet, muss man ein Gespühr für Nebenläufigkeit (Threads) haben. So kann man das Zeitverhalten einschätzen und Race Conditions vermeiden. Dead Locks treten hierbei mit geringerer Wahrscheinlichkeit auf, sind aber nicht unmöglich. Dieser kann auf den ATmega Controllern wenigstens mit dem Watch Dog aufgelöst werden. Alles in Allem braucht man einen klaren Kopf und die Geduld, auf die Lösung des Problems hinzuarbeiten.

Mai 282008
 

Am 13.05.2008 kam eine Meldung über den Heise-Ticker, dass Debian durch einen Patch eine Schwachstelle bei der Schlüsselgenerierung eingepflegt hat. Das Brisante daran ist, dass dieser Patch vor nahezu zwei Jahren eingespielt wurde.

Was passiert genau dabei? Der Patch hat dafür gesorgt, dass der Zufallszahlengenerator aus den Prozess-IDs gefüttert wird. Der Wertebereich ist unter Linux mit 1-32767 äußerst eingeschränkt. Jede Software, die diesen Generator benutzt, erzeugt somit schwache Schlüsselpaare. Dazu gehört z.B. SSH. Jeder Rechner, der nach dem September 2006 mit Debian oder Ubuntu installiert wurde, generiert somit bei der Installation ein schwaches Host-Key-Pärchen. Jeder Benutzer, der unter Ubuntu oder Debian einen neuen Private Key zum Einloggen generiert hat, hat somit auch ein schwaches Schlüsselpärchen generiert. Damit können die Schlüssel sehr schnell geknackt werden.

Was heißt das in der Konsequenz? Das heißt, dass alle mit Debian oder Ubuntu erzeugten Schlüssel die nach dem September 2006 generiert wurden neu generiert werden müssen. Macht man über den üblichen Weg ein Software Upgrade, wird das für die SSH Host Keys automatisch erledigt. Loggt man sich danach auf so einem aufgefrischtem Rechner ein, wird man abgewiesen mit dem Hinweis, dass in der known_hosts-Datei der Schlüssel nicht mehr passt. Der Eintrag in dieser Datei sollte daher gelöscht werden. Das SSH-Paket hat jetzt ein neues Tool: ssh-vulnkey, mit dem die Schlüssel in der authorized_keys-Datei überprüft werden können. Schwache Schlüssel sollten aus dieser Datei entfernt werden. Zusätzlich lässt ein SSH-Daemon diese Schlüssel beim Einloggen nicht mehr zu. Das Neugenerieren eines Schlüssels ist dabei kein Problem. Eher ist es problematisch, dass der Public Key auf Dutzenden von Rechnern untergebracht sein kann. Ein weiteres Problem sind SSL-Zertifikate, so wie sie für Webseiten verwendet werden. Selbst, wenn man keine selbstsignierten Zertifikate verwendet und Zertifikate kauft, wird der Private Key selbstgeneriert. In der Konsequenz müssen nicht nur die Zertifikate neu generiert bzw. gekauft werden, sondern der Private Key muss komplett neu samt Certificate Request generiert werden.

In einem Unternehmen wie itemis mussten nicht weniger als 30 Zertifkate neu generiert werden. Diese mussten natürlich auch auf den Hosts installiert werden. Hierbei kam wenigstens die modellgetriebene Serverkonfiguration unterstützend zum Einsatz. Die Entwicklungsrechner haben zwar selbstsignierte Zertifikate, aber gerade für die öffentlich zugänglichen Server mussten neue Zertifkate gekauft werden. Zusätzlich kam die Überprüfung der SSH-Schlüssel. Die Software-Upgrades haben die Host Keys automatisch erneuert. Die Überprüfung und der Ersatz der User-Schlüssel hat aber sehr viel mehr Aufwand gekostet. Alles in Allem hat dieser Vorgang zwei Tage Arbeit gekostet.

Hat sich der Aufwand gelohnt? Wer hier nein sagt, handelt schlichtweg grob fahrlässig! Im Moment ist es nur Aufwand. Aber langfristig möchte man sich nicht der Gefahr aussetzen, dass Daten auspioniert werden oder gar Rechner gehackt werden. Die heutige Meldung begründet diese Sorge. Es lassen sich ohne wenig Probleme von außen Rechner ermitteln, die sich hacken lassen!

Wer mehr zu diesem Thema lesen möchte und wie man mit dieser Schwachstelle umgeht, können Sie hier lesen:
http://www.heise.de/security/Der-kleine-OpenSSL-Wegweiser–/artikel/108001

Es gibt auch ein Tool, das schwache Schlüssel ausfindig machen kann. Es hat aber den Nachteil, dass es nicht alle Schlüssel erkennt. Im Zweifel sollte man lieber einen Schlüssel zu viel als zu wenig neu generieren:
http://security.debian.org/project/extra/dowkd/dowkd.pl.gz

Mai 232008
 

Die Schaltung, um Weichen und Signale über Mikrocontroller zu steuern ist jetzt fertig entwickelt. An einem Steckbrett wurde ein Steuerungsknoten und ein Gateway zusammengebaut und programmiert. Das Gateway ist ein Protokollumsetzer. Die CAN-Frames werden vom PC über RS232 zu diesem Gateway getunnelt und von dort aus über den CAN-Bus weitertransportiert. Die Kommunikation ist dabei bidirektional. Dabei ist zu beachten, dass die Steuerungsknoten sich nicht untereinander unterhalten, sondern jede Information an das Gateway schicken. Das Schalten von Weichen und die Gleisbesetztanzeige werden auch schon korrekt im controller verarbeitet. Jetzt müssen die mehrere Prototypen auf testweise auf Laborplatinen gelötet werden.

Danach muss die Leistungselektronik entwickelt werden. Diese übernehmen die eigentliche Ansteuerung der Weichen und Signale. Diese Aufgabe ist reine Fleißarbeit. Denn es müssen mindestens 15 Steuerungsknoten, vier Gateways und unzählige Module zur Ansteuerung gelötet werden.

schaltung.jpg

Das Bild zeigt links unten das unscheinbare Steckbrett. Auf der linken Hälfte des Bretts ist der Steuerungsknoten auf der rechten das Gateway. Dieses kommuniziert mit einer kleinen Zusatzplatine über die serielle Schnittstelle am PC mit der Steuerungssoftware. Die Steuerungssoftware kann man auf dem linken Monitor erkennen. Der rechte Monitor zeigt die Entwicklungsumgebung Eclipse. Am rechten Bildrand kann man ein MacBook erkennen. Auf diesem läuft die Entwicklungsumgebung, um die Firmware der Mikrocontroller über JTAG zu debuggen.

Die Steuerungssoftware kommuniziert bereits mit den Mikrocontrollern und kann schon Aufgaben verteilen. Die Steuerungsaufgaben werden in mehreren Stapeln verarbeitet. So dürfen erst Signale geschatet werden, wenn alle Weichen die gewünschte Fahrstraße eingestellt haben. Erst danach kommt die Gleisfreigabe.

Feb 292008
 

Vor einem Jahr hat unser Unternehmen eine neue IT-Infrastruktur in Betrieb genommen. Grund genug zu hinterfragen, ob die Umstellung erfolgreich war. Nachdem entschieden war, dass fünf neue Server samt weiterer Infrastruktur wie z.B. unterbrechnungsfreie Stromversorgungen, angeschafft werden sollen, kam die Frage auf, welches Betriebssystem dafür benutzt werden sollte. Die Frage ob Microsoft oder Linux genutzt werden sollte stellte sich gar nicht erst, da ausreichend Linux-Know-How zur Verfügung stand. Ferner sind die Fernwartungsmöglichkeiten unter Linux deutlich höher. Eine Sicherheitsabwägung zwischen Windows und Linux gibt es nicht, da auch unter Linux nicht minder häufig viele Patches und Updates auf Grund von Sicherheitslücken notwendig sind.

Blieb also noch die Frage, welche Linux-Distribution gewählt werden sollte. Hier war zuerst die Wahl zwischen SuSE bzw. openSuSE und Debian. Debian hat gegenüber SuSE den Vorteil, dass langfristig die Upgrades wesentlich wartungsärmer ausfallen, als unter SuSE. Wer z.B. schon mal von SuSE 9.2 auf SuSE 10.1 ein Upgrade durchgeführt hat, weiß wovon die Rede ist. Ein Debian-basiertes System hat deutlich weniger Probleme mit Upgrades selbst über mehrere Jahre hinweg. Grund hierfür ist ein ausgereiftes und durchdachtes Paketmanagement, das es selbst nach Jahren ermöglicht, aktuelle Software samt Abhängigkeiten zwischen unterschiedlichen Paketen zu pflegen. SuSE hat den Vorteil, dass die angebotenen Software-Pakete aktueller sind. Gerade bei relativ neuer Hardware spielt das eine Rolle. Hier lag Debian z.T. erheblich zurück, war vor einem Jahr nur die Distribution Sarge aktuell und der Nacholger Etch ließ noch auf sich warten. Ferner konnte Debian nicht mit einer stabilen 64-Bit-Variante für Opterons aufwarten.

Hier kam Ubuntu auf den Plan. Ubuntu basiert mit seinem Paketmanagement auf Debian, weist aber eine deutlich höhere Aktualität in der Software auf. Ferner gab es auch eine stabile 64-Bit-Variante. Genutzt haben wir den Ubuntu-Server-Zweig. Daduch konnte eine sehr schlanke Basisinstallation erfolgen, die nur ca. 600 MByte umfasst. Denn: Jede Software, die nicht installiert ist, kann nicht durch Sicherheitslücken auffallen. Im Gegensatz dazu SuSE oder SLES, welche aus Bequemlichkeit das Rundum-Sorglos-Paket – also nahezu alles – installieren. Ob das dann wirklich sorglos ist, muss danach entschieden werden.

Sicherlich hat Ubuntu noch Probleme bei der Hardware-Erkennung. Hier ist SuSE eindeutig besser. Das trifft sowohl auf alte Hardware (“attic hardware”) zu, als auch auf sehr neue Hardware. Hier ist Ubuntu eher am Mainstream orientiert. Ist aber erst einmal ein funktionierendes Ubuntu lauffähig, kann es fast nur noch mutwillig die Arbeit verweigern.

Die Erstinstallation umfasste Ubuntu Edgy Eft und wurde inzwischen ohne Probleme auf Gutsy Gibbon aktualisiert. Jeder Server hat also schon zwei Upgrades hinter sich. Nachdem auf einem Staging System die kleinere Probleme bei neueren Konfigurationsdateien erkannt wurden, konnten diese komfortabel per modellgetriebener Serverkonfiguration bei den Upgrades anderer Server umgangen werden. Das Staging System läuft auf einer virtuellen Maschine, wodurch keinerlei Hardware-Anschaffung nötig waren. Einer der vielen Vorteile der Virtualisierung – aber das nur am Rande.

Abschließend lässt sich sagen, dass ein Umstieg auf Ubuntu die richtige Entscheidung war. Es liegt eine wartungsarme Distribution vor, die Sicherheitsupdates mit nur kleiner Zeitverzögerung nach Bekanntwerden aktualisiert. Im Alltag haben sich nahezu keine Probleme in Sachen Stabilität gezeigt. Insofern kann man Ubuntu alles Gute für die weitere Zukunft wünschen.

Feb 292008
 

Ich habe ja schon über die technischen Details einer Modelleisenbahnsteuerung berichtet. Damit man auch etwas zum Testen hat, braucht man natürlich auch eine Anlage. Bestandteil dieser Anlage ist natürlich auch die Modelllandschaft. Ein Teil wird derzeit aufgeforstet, wie auf dem Bild zu erkennen ist:
wald.jpg
Dieses Bild zeigt nur einen Ausschnit meiner neuen Modelleisenbahnanlage. Es sind schon 300 Bäume gepflanzt worden. Am Wochenende werden die nächsten 100 Stecktannen den Wald vergrößern. Natürlich werden noch weitere Bilder folgen und Berichte über den Ausbauzustand der Microcontroller-Steuerung werden ergänzt.

Feb 292008
 

In der Regel sind die Anwendungsfälle für modellgetriebene Architekturen ist der Software-Entwicklung zu finden. Es gibt aber auch die Möglichkeit, die Konfiguration für eine ganze Server-Landschaft zu generieren. Zu diesem Zweck wird die Server-Landschaft als UML2-Modell modelliert. Dieses Modell entspricht dem Sollzustand. Um diesen in den Istzustand zu überführen, werden mittels openArchitectureWare aus dem Modell Konfigurationsdatien erzeugt. Für jeden Server entsteht so ein Verzeichnisbaum. Dieser Verzeichnisbaum wird mit scp -r auf die Zielmaschine kopiert. Danach wird ein Deploy-Script aufgerufen, das die betroffenen Dienste über die neue Konfiguration informiert.

Das Modell erfasst dabei sowohl Hardware, als auch Dienste. Die Hardware muss erfasst werden, wenn die Funktionstüchtigkeit überprüft werden soll. Dazu gehören Temperaturstände, Fehlerzustände von Festplatten, die über S.M.A.R.T. abgefragt werden können und auch Füllstände von Partitionen. Dabei kann eine langfristige Erfassung mit MRTG erfolgen, mit der auch Trends erfasst werden können. Eine schnelle Erfassung kann mit Nagios erfolgen. Das nützt besonders dann, wenn tatsächlich etwas schlagartig ausfällt.

An Software-Diensten werden folgende Dienste mitkonfiguriert:

  • Nagios/MRTG/SNMP
  • DHCP
  • LDAP
  • Apache/Webalizer
  • PAM über LDAP, passwd oder NIS
  • smartmontools
  • 3ware RAID-Controller
  • NTP
  • SSL
  • APC UPS Daemon

Alle diese Dienste sind mehr oder weniger miteinander verwoben. So liefert DHCP auch Informationen über NTP oder DNS aus. Auch der Apache kann sich unter Umständen an andere Dienste (z.B. LDAP) hängen. Auch Master-Slave-Konfigurationen sind möglich. Insbesondere bei OpenLDAP kann dieses Feature genutzt werden.

Es stellt sich die Frage, welche Vorteile die modellgetriebene Serverkonfiguration hat. Sicherlich ist dieser Weg sehr individuell und in ihrer ersten Form an die Gegebenheiten unserer eigenen Infrastruktur angepasst. Es hat sich gezeigt, dass ein großer Vorteil dann besteht, wenn Abhängigkeiten zwischen mehreren Servern bestehen. Dazu ist vor Allem Nagios, MRTG und SNMP zu nennen. Aber auch die Master-Slave-Konfiguration von LDAP, die auch als Load Balancing für die LDAP-Apache-Authentifizierung genutzt werden kann. Gegenüber dem klassischen Systemmanagement hat dieser Ansatz den Vorteil, dass ein Sollzustand definiert wird und nicht ein Istzustand ergründet wird, auf dem weitergearbeitet wird. Denn dieser Zustand kann auch schon fehlerhaft sein. Desweiteren lassen sich Unterlassungsfehler und Copy/Paste-Fehler vermeiden, was insgesamt die Qualität der Konfiguration steigert.

Unsere IT hat mit diesem Ansatz gute Erfahrungen gemacht, sodass die modellgetriebene Serverkonfiguration seit fast einem Jahr produktiv genutzt wird.

Feb 282008
 

Kann man modellgetrieben eine Modelleisenbahnsteuerung aus Mikrocontrollern bauen? Dieser Frage gehen Entwickler des Yakindu-Projektes nach. Hintergrund ist, dass eine digitale Ansteuerung der Weichen und Signale über konventionelle Mittel sehr teuer ist. Eine digitale Steuerung hat aber den Vorteil, dass der Verdrahtungsaufwand minimiert wird. Dieser fällt deswegen unangenehm auf, weil ein Großteil der elektrischen Verkabelung kopfüber geschehen muss. Hier setzt die Idee an, die Mikrocontroller bequem an einem ergonomischen Arbeitsplatz zu bauen und nur die fertigen Module kopfüber zu montieren und anzuschließen. Als Mikrocontroller werden von ATmel die ATmega32 eingesetzt. Diese sind vielseitig einsetzbar und es gibt sehr viele fertige freie Tools, um diese Controller zu programmieren. Zusätzlich gibt es eine große Auswahl an weiteren Spezial-ICs, wie z.B. den CAN-Controller MCP2515.

An den Mikrocontrollern sollen spezielle Ansteuerungsmodule verwendet werden. So können unterschiedliche Aufgaben an die Microcontroller vergeben werden, ohne jeweils eine spezielle Hardware bauen zu müssen. Dazu erhalten die Microcontroller eine universelle Firmware. Diese wird dann so konfiguriert, wie der Anschluss der Ansteuerungsmodule erfolgt. Als Ansteuerungsmodule sind derzeit geplant:

  • Lichtsignal-Ansteuerung, im Prinzip eine einfache LED-Ansteuerung
  • Magnetartikel-Ansteuerung. Darüber werden Weichen und Formsignale angesteuert.
  • Gleisabschnitt-Steuerung mit Gleisbesetztmeldung
  • JTAG-Modul zum Debuggen

Die drei letzten Module werden direkt mit den einzelnen Ports des ATmega gekoppelt ein Port fällt für spezielle Aufgaben weg, da z.B. die Microcontroller untereinander kommunizieren müssen. Diese Kommunikation soll über CAN-Bus erfolgen. Dieser ist sehr robust gegenüber Störungen und gilt nach 20 Jahren als ausgereift. Es gibt günstige Bauteile, die die Kommunikation auf physikalischer Ebene übernehmen. Darin enthalten ist z.B. eine Fehlerkorrektur über CRC und das Protokoll-Handling. Bei einem ATmega32 bleiben so drei Ports für die Module frei, was den individuellen Verbau der Module ermöglicht.

stellwerk.jpg

Als zweite Software-Komponente neben der Microcontroller-Firmware gibt es das Frontend. Diese GUI-Applikation ermöglicht die bequeme Ansteuerung der Microcontroller mit einer Visualisierung als Stellwerk. Insbesondere ist hier die Fahrstraßenschaltung zu nennen. Durch Anklicken von Stützpunkten welche die Route definieren und anschließender Auswahl von Rangieren oder Fahrt, wird eine freie Gleisroute vom Anfangspunkt über die Stützpunkte zum Endpunkt gesucht, danach die Weichen und Signale geschaltet und die Gleisabschnitte unter Fahrstrom gesetzt. Diese Applikation ist mit Eclipse und dem SWT/RCP-Framework umgesetzt. So kann das Stellwerk plattformunanhängig eingesetzt werden.

Zum Schluss bleibt die Frage offen, was daran modellgetrieben ist? Die gesamte Modellbahnanlage wird in einem EMF-Modell nachmodelliert. Daraus wird die Gesamtkonfiguration für die Microcontroller generiert sowie die GUI für das Stellwerk. Das generierte Gleisschema wird dann durch den universellen Router-Algorithmus für die Fahrstraße ergänzt. Dieser wertet noch Informationen aus, wie Langsamfahrstellen und bevorzugte Fahrwege an Weichen. In der Zukunft ist geplant, die Modellierung mittels GMF zu erreichen, weil die Eingabe über EMF gerade bei einer Modelleisenbahn wenig intuitiv ist.