Nunja. In der Firma in Emsdetten sprang als Auswirkung kurz die USV an. In der Überwachung ist schön zu sehen, dass für den Bruchteil einer Sekunde um 11:32 Uhr der Strom fehlte. Das war dann doch etwas zu kurz, als das der Diesel hätte anspringen müssen. In vielen Firmen in Münster und den umliegenden Kreisen war dies aber wohl ein Problem und so standen selbst bei einem sehr kurzen Ausfall von nichtmal einer Sekunde die Computer.

Da sind wir mal gespannt, was sonst noch so passiert in Zukunft…

Seit ich Xen kenne, war mir dabei klar, dass der neue Server irgendeine Form von Virtualisierung bekommen sollte. Jetzt am Wochenende wollte ich beginnen und stand erstmal wieder vor der Frage, welches Produkt denn nun einzusetzen sei?

Xen oder OpenVZ hieß es schließlich und ich habe mich nun für OpenVZ entschieden. Für meine Zwecke einer homogenen Serverlandschaft ist OpenVZ absolut ausreichend und bietet – so die verschiedenen Quellen – auch in Punkto Performance und Bedienbarkeit ein paar Vorteile gegenüber Xen.

Doch warum überhaupt eine Virtualisierung?

Ich denke mal die Geschichte meiner Jadzia ist ziemlich ähnlich dem, was mit anderen Servern passiert. Man richtet sich irgendwann mal einen dedizierten Server ein und mehr und mehr kommen neue Dienste auf die Maschine, bis sich schließlich Webserver, Mailserver, Nameserver und Telefonanlage (und das ist noch der günstigste Fall) auf ein und derselben Maschine tummeln.

Und damit beginnen die Probleme. Man nimmt sich vor an einem Abend mal ein Update des Systems zu machen. Pustekuchen. Nach fünf Stunden Arbeit funktionieren manche Pakete dann immer noch nicht wie sie sollen. Gerne und gerade passiert dies auch im Zusammenhang mit der Tatsache, dass man für ein bestimmtes Feature die neuesten Softwareversionen benötigt und die “instabilen” Pakete installiert. Dann darf man die eben genannte Zeit gerne verdoppeln…

Von der fehlenden Sicherheit natürlich ganz zu schweigen. Ich hänge zwar hinter einer prima Security-Appliance mit Firewall, IPS und dem ganzen Zipp und Zapp, aber Sicherheitslücken tauchen immer wieder auf und es ist wie in allen Lebenslagen ein Wettrennen zwischen Jäger und Gejagtem, dass das IPS eventuelle Angriffe erkennt. Kompromitiert nun ein Bösewicht meinen Server, bleiben alle Daten davon unberührt. DAS ist klasse

Wie gehe ich nun weiter vor?

Nun, da ich mitlerweile einen spitzen iMac mit Intel-Prozessor habe, habe ich den Samstag bereits damit verbracht ein neues Gentoo auf einer Parallels-VM einzurichten. Dort habe ich OpenVZ installiert und werden nun die jeweiligen Server einrichten. Ich denke die Vorgehensweise bekommt noch einen eigenen Blog-Eintrag.

Ich werde hoffentlich in den nächsten Tagen zwischendurch immer wieder Zeit finden über meine Fortschritte zu berichten, so dass hier eventuell auch ein kleines How-To entstehen kann, wie ich diesen Umzug gestalte.

So hatte ich mich gestern mit einem langjährigen Kunden unterhalten, der eigentlich alles über uns gebucht hat, nur seinen Internetzugang nicht, dessen Tocher auf eine zwar alte, aber leider immer noch sehr aktive Betrugsmasche hereingefallen ist.

In diesem speziellen Fall, lockt der Anbieter Menschen zu sich auf die Seiten, die sich von der Aufmachung Songtexte, Hausaufgaben oder Vornamen für ihr neugeborenes Kind versprechen. Lediglich seine Kontaktdaten müsse man zur Registrierung angeben, den Zugriff auf die Datenbank gibt es heute kostenlos.

Bei seriösen Anbietern bedeutet das, man darf sich heute für eine unbegrenzte Zeit kostenfrei anmelden. Nicht so bei unseriösen Anbietern. Diese nehmen das “heute” wörtlich und Punkt Mitternacht wird die Rechnung fertig gemacht, zu “günstigen” Konditionen von 7,00 € pro Monat bei jährlicher Vorauszahlung.

Was ist nun zu tun, wenn einen eine solche Rechnung überrascht? Erstmal sollte man Ruhe bwahren und genau prüfen, ob man sich überhaupt bei solch einem Verein angemeldet hat. Oftmals berichten Menschen nämlich von Rechnungen, obwohl sie ganz sicher sind, niemals eine solche Dienstleistung in Anspruch genommen zu haben.

Hat man sich dann doch irgendwo angemeldet, sollte man die Gegebenheiten prüfen. Sind Preise, Bedingungen usw. deutlich ausgewiesen oder nur irgendwo versteckt? In diesem Falle begibt sich der Anbieter aufs Glatteis und in Grauzonen. Niemand kann sagen, ob solche “Preisauszeichnungen” vor Gericht bestand haben würden.

Eine sehr gute Möglichkeit bietet aber auch die Quelle dieses Unheils: Das Internet selbst. Einfach mal den Firmen oder Angebotsnamen in eine Suchmaschine eingeben und die dann eventuell aufkommenden Foren- und Geschädigtenseiten durchforsten. Gibt es eine Betrugsmasche, kann man sicher sein, dass sich schon bald viele Betroffene im Internet finden und die Besten Strategien ausfuchsen, um unbeschadet aus dieser Sache herauszukommen.

Daher kann man bei der Mehrzahl der Angebote eher davon ausgehen, dass die Anbieter davon ausgehen, dass nur ein kleiner Teil der Rechnungsempfänger tatsächlich bezahlen, weil sie sich durch die aufgebauten Drohkulissen eingeschüchtert fühlen. In diesem Fall kann man es ruhigen Gewissens darauf ankommen lassen und damit rechnen, dass der Anbieter nicht den gerichtlichen Weg einschlagen wird. Schließlich will er ja selbst keine Präzedenzfälle schaffen und mit gewissen Gebühren in Vorleistung treten, wenn die große Gefahr besteht den Prozess zu verlieren.
Reagieren muss man erst, wenn der gerichtliche Mahnbescheid ins Haus flattert! Dann aber zügig und auf jeden Fall. Denn versäumt man die Frist steht man in der Schuld des Anbieters und hat keine Möglichkeit mehr, sich vor der Zahlung zu drücken.

Ganz wichtig sollte übrigens noch sein, sich jedes Angebot ganz genau anzuschauen. Niemand hat etwas zu verschenken auch und gerade im Internet nicht. Und sämtliche Alarmglocken sollten läuten, wenn man den Anbieter mit Adresse und Geburtsdatum füttern muss, nur um Lyrics seines Lieblingsliedes anzurufen. Auch sollte man sich AGB und Nutzungsbedingen tatsächlich aufmerksam durchlesen und nicht nur abhaken um schnell zum Angebot zu kommen.

Hui, der Artikel ist ja länger geworden als gewollt.. Na hoffen wir mal, dass es hilft

Worum geht es eigentlich? Es geht um sichere Webserver. Dabei allerdings weniger um Gefahren von außen, sondern um die Gefahr, die von innen kommt. Zwar gibt es immer mehr Nutzer, die einen eigenen Server verwalten und somit genau kontrollieren können, welche Informationen nach außen dringen, aber noch immer macht das Massenhosting einen Großteil der Homepages aus.

Massenhosting bedeutet, dass ein physikalischer Server von mehreren Homepages gleichzeitig genutzt wird, die allesamt parallel auf dem Server existieren. Zwar ist es kein großes Sicherheitsproblem, wenn die Nutzer per FTP ihre Daten hochladen und über HTTP abrufen können, problematisch wird es aber dann, wenn die hochgeladenen Daten Programme jeglicher Art sind, die auf dem Server ausgeführt werden können.

Gerade mit der unglaublich steigenden Bekanntheit von PHP, stiegen auch die Sicherheitsprobleme. Und ich habe nun einmal einige Gedanken zusammengetragen, wie man einen möglichst sicheren Webserver mit PHP-Unterstützung realisieren kann, da ich bei meiner Suche im Internet bisher leider noch nichts vergleichbares finden konnte.

Das Problem

Sicherheit steht immer im Gegensatz zur Bequemlichkeit. Eine Alarmanlage im Haus bringt große Sicherheit, stört mich aber sehr, wenn ich in der Nacht etwas erledigen muss und sie erst deaktivieren muss. Bodyguards bringen mir auch große Sicherheit nur schirmen sie mich eventuell unnötig ab und ich habe kaum noch Privatspäre.

Daher muss ein Kompromiss gefunden werden, der zum einen eine gute Sicherheit bietet, zum anderen aber auch dem Kunden sowenig Schwierigkeiten macht wie nur möglich.

Das grundlegende Problem ist folgendes:

Die meisten Webserver, auf denen PHP als Scriptsprache angeboten wird, nutzen das PHP-Modul für den Apache. Dieses Modul wird zentral in den Apache-Webserver eingebunden und steht danach allen Homepages, respektive Virtual-Hosts, zur Verfügung. Der Vorteil: Die Ausführung der PHP-Programme ist sehr schnell und die Konfiguration ist sehr einfach. Außerdem sind die PHP-Programme in dieser Konfiguration sehr flexibel und können nahezu jegliche Arbeiten verrichten, die gefordert werden.

Genau hier liegt das Problem. PHP-Programme, die über das Apache-Modul ausgeführt werden, werden im Linux/Unix-System unter dem Benutzer ausgeführt, unter dem auch der Apache ausgeführt wird. Natürlich muss der Apache auf sämtliche Dateien zugreifen können, die er an die Besucher der Internetseiten ausliefern möchte. Das bedeutet, sämtliche Dateien, die ausgeliedert werden sollen oder als PHP-Programm ausgeführt werden sollen, müssen für den Apache lesbar sein.

Im Umkehrschluss bedeutet das dann, ein PHP-Script, egal an welcher Stelle im System, welches über das Internet aufgerufen wird, hat Zugriff auf sämtliche Dateien, die vom Apache gelesen oder vom PHP-Modul ausgeführt werden sollen. Das umschließt die PHP-Programme selbst im Quelltext (jemand anderes kann also das geistige Eigentum stehlen), .inc-Dateien, die zb. Passwörter für den SQL-Zugriff enthalten oder .htpasswd-Dateien, die von Apache zum Schutz von Verzeichnissen genutzt werden.

Und genau diese Sicherheitslücke werden wir uns nun vornehmen.

Der Weg

Es gibt einige Möglichkeiten, das Problem zu lösen:

1. PHP wird nicht mehr angeboten: Zugegeben, ein drastischer Schritt, den kein Anbieter von Webhosting gehen wird, aber sicher der wirksamste
2. Safe-Mode: Safe-Mode sind verschiedene Funktionen innerhalb von PHP, die diese Sicherheitsprobleme gezielt angehen sollen. Zwei Funktionen werde ich in meiner Lösung einsetzen. Generell ist der Safe-Mode allerdings eher unwirksam, da er mehr Probleme erzeugt, denn löst. So streuben sich einige sehr bekannte PHP-Applikationen unter Safe-Mode zu laufen, da zb. populäre Funktionen, wie der Upload von Dateien immer wieder zu Problemen führen.
3. abgespeckter Safe-Mode + disable_functions: Dies dürfte die beste Lösung für Administratoren sein, die einigermaßen “humane” Kunden haben. Der Safe-Mode wird generell ausgeschaltet. Mit der open_basedir-Richtlinie setzt man die PHP-Funktionen für den Dateizugriff auf das eigene Verzeichnis fest, so dass hier nur noch Dateien der eigenen Homepage angezeigt werden können. Schließlich werden mit disable_functions alle PHP-Funktionen ausgeschaltet, die normale Unix-Befehle ausführen können und somit dennoch fremde Dateien ausspionieren können.

   Leider gibt es hier allerdings auch den Haken, dass manche Applikationen diese Funktionen zwingend benötigen, da sie auf externe Software angewiesen sind. Ein Beispiel ist Gallery. Hinzu kommt, dass disable_functions leider nur sehr unflexibel ist, da es nur global definiert werden kann.

4. PHP-CGI + suexec: Fast meine Lösung. PHP wird als externe Software über einen sog. suexec-wrapper ausgeführt. Die genaue Bedeutung kommt später. Allerdings bietet diese Lösung eine generell schlechtere Performance als die Nutzung von PHP als Modul.

Die Lösung

Zunächst, warum PHP als CGI ausführen?

Nun, zusammen mit suexec wird PHP als der Benutzer ausgeführt, dem der virtuelle Webserver gehört. Das bedeutet natürlich, dass ich nur auf Dateien Zugriff habe, die ich mit meinen eigenen Berichtungen lesen darf. Die PHP-Scripte meines “Server-Nachbarn” werden mit seinen Berechtigungen ausgeführt. Sind die Berechtigungen sorgfältig gesetzt, kann diese Lösung als sicher erachtet werden.

Daher ist zu beachten, dass gerade auf die Berechtigungen ein großes Augenmerk gelegt werden. Diese ganze Lösung ist nämlich dann für die Katz, wenn Dateien trotzdem von jedem gelesen werden können.

Um die Abarbeitung der PHP-Scripte auch schnell zu machen, kommt noch eine Komponente hinzu: FastCGI FastCGI ist ein Apache-Modul mit sehr guten Caching-Möglichkeiten, bei dem PHP als Server gestartet wird und so die Aufträge schnell abgearbeitet werden können. Es gibt sogar die Möglichkeit, externe PHP-Server zu nutzen und so zb. ein Loadbalancing der PHP-Last zu erreichen.

Dieses Howto richtet sich weniger an die grundlegende Installation von Apache, FastCGI und PHP, da sie sich unter Gentoo, welches ich nutze, recht einfach gestaltet. Wer von Source installiert, findet dazu einige Howtos im Netz, die dann allerdings meiner Meinung nach zuwenig auf die Berechtigungen der Nutzer eingehen. Wichtig ist nur, dass beim Apache die suexec-Möglichkeiten eingebunden werden und PHP mit FastCGI-Unterstützung kompiliert wird.

Unter Gentoo reicht dazu ein:

emerge -v apache php-cgi mod_fastcgi

Natürlich sollte man sich noch seine entsprechenden USE-Variablen zusammensuchen, gerade PHP bietet da eine sehr umfangreiche Liste:

emerge -pv php-cgi

Wichtig ist natürlich mitlerweile auch USE=”apache2″, da wir für den Apache Version 2 kompilieren werden.

Nach der Installation der drei Komponenten müssen wir in der /etc/conf.d/apache2 das FastCGI-Modul aktivieren:

APACHE2_OPTS="-D SSL -D DAV -D FASTCGI"

Hier ist natürlich nur der Part “-D FASTCGI” der notwendige.

FastCGI unterscheidet zwischen drei Arten von Applikationsservern, also zb. drei Arten von PHP-Servern, die in Zukunft die Arbeit machen sollen.

1. statische Server werden beim Start des Webservers gestartet und stehen dann dauerhaft zur Verfügung.
2. dynamische Server werden dann gestartet, wenn eine Anfrage an den Server gestellt wird, die die Ausführung eines PHP-Scripts beinhaltet.
3. externe Server können per TCP/UDP angesprochen werden und so zb. freie Resourcen anderer Server mit nutzen.

Hier muss man nun entscheiden, ob man virtuelle Server hat, die mit einer hohen Besucherfrequenz einen nutzen aus statischen Servern ziehen würden oder ob man virtuelle Server hat, auf denen nur sehr wenige Besucher sind. Gerade im Massenhosting macht es eher Sinn auf dynamische Server zu setzen, da das Gästebuch des lokalen Taubenzüchtervereins vielleicht einmal pro Monat aufgerufen wird. Natürlich bringt ein dynamischer Server eine leichte Verzögerung bei der ersten Anfrage. Ist der Server geladen steht er auch für weitere Anfragen des gleichen Benutzers zur Verfügung, bis er nach einer konfigurierbaren Zeit stirbt.

Da der dynamische Server zunächst Grundlage auch für die statischen Server ist kümmern wir uns erstmal darum. Folgende Zeilen kommen in den VirtualHost der jeweiligen Webservers:


ScriptAlias /cgi-bin /var/www/private/blog.commy.de/cgi-bin

SuexecUserGroup "matthias" "users"


Sämtliche Anfragen nach .php-Dateien werden auf ein Shellscript unter dem relativen Pfad /cgi-bin/php geleitet. Aus diesem Grunde benötigt man natürlich die Definition eines cgi-bin-Verzeichnisses. Ich nutze dafür die ScriptAlias-Angabe, euch stehen natürlich auch die anderen Möglichkeiten zur Verfügung.

Damit der Server auch unter den korrekten Benutzerdaten läuft, benötigt man die SuexecUserGroup-Angabe. Unter Gentoo funktioniert es nicht, das PHP unter dem Apache-Benutzer apache zu starten. Daher sollte man hier ohnehin den jeweiligen Benutzer des Webservers angeben und eine allgemeine Gruppe (alternativ kann man natürlich auch eine Gruppe webuser o.ä. anlegen).

Um PHP nun zu aktivieren, benötigt man nun auch das Shell-Script im cgi-bin-Verzeichnis. Dazu nutzt man folgendes:

#!/bin/sh
umask 027
PHPRC="/etc/php/cgi-php4/"
export PHPRC
PHP_FCGI_CHILDREN=4
export PHP_FCGI_CHILDREN
exec /usr/bin/php-cgi

Die umask-Angabe werde ich später noch erklären.

PHPRC definiert den Ort, an dem der PHP-Server die PHP-Konfigurationsdateien finden kann. Hiermit ist es also sogar möglich, jedem Kunden zu ermöglichen, mit einer php.ini im entsprechenden Verzeichnis, eigene Parameter des PHP-Servers zu definieren.

PHP_FCGI_CHILDREN definiert die Anzahl von PHP-Instanzen, die initial gestartet werden sollen. Je nach Besucherfrequenz des Servers können dies mehr oder auch weniger sein.

exec startet schließlich PHP. Der Pfad sollte natürlich entsprechend angepasst werden. Hier zeigt sich aber ein weiterer Vorteil von fastcgi; Ohne andere Webserver auf dem Server zu stören, kann hierdurch eine neue PHP-Version getestet oder unterschiedliche PHP-Versionen auf einem physikalischen Server laufen.

In der /etc/apache2/httpd.conf fehlt nun noch die Angabe des zu nutzenden suexec-Wrappers:

FastCgiWrapper /usr/sbin/suexec2

Möchte man nun statische Server nutzen, richtet man diese unter Angabe des Pfades für das obige Shell-Script und der identischen Benutzer/Gruppen-Angaben mit folgenden Zeilen ein:

FastCgiServer /var/www/private/blog.commy.de/cgi-bin/php -user matthias -group users
FastCgiServer /var/www/_SERVICES/cgi-bin/php -user wwwsystem -group users


Mit diesen Zeilen würden dann beim Start von Apache zwei PHP-Server mit jeweils unterschiedlichen Benutzerdaten starten.

Nun wird es spannend. PHP läuft jetzt zwar soweit, aber in den Standardeinstellungen ist es wenig benutzer, weil wir immer noch Sicherheitsprobleme haben. Die können wir jetzt lösen, indem wir einige Dateiberechtigungen ändern.

Durch das suexec haben wir nun erreicht, dass PHP-Dateien und Dateien, die nur von PHP gelesen werden sollen, lediglich vom Benutzer gelesen werden brauchen. Die Gruppe oder alle anderen brauchen die Dateien nicht mehr lesen, was für PHP-Dateien schon einmal ein sehr großer Vorteil ist.

Um nun die größtmögliche Sicherheit zu erhalten, habe ich folgende Berechtigungen erarbeitet:

Es sollten alle Dateien und Verzeichnisse in dem Webserver-Verzeichnis eines Nutzers dem Nutzer gehören (klar). Die Gruppe sollte dem Webserver-Benutzer gehören (im Falle von Gentoo apache). Der Benutzer sollte alles können, die Gruppe sollte nur lesen und alle anderen sollten nichts können.

Das größte Problem sind hierbei Dateien, die durch PHP neu angelegt werden. Standardmäßig bekommen diese Dateien nämlich keine Rechte für Gruppen und alle anderen. Für geheime Daten ist das OK, für Daten die hochgeladen werden und wie bei der Gallery dann zb. resized werden, ist das aber sehr schlecht, da die dann nicht per Webbrowser angezeigt werden können.

Außerdem erhalten diese Dateien die Gruppenzugehörigkeit “users”, da wir unter “users” ja den PHP-Server laufen haben.

Letzteres können wir verhindern, in dem wir mit

chmod -R g+s

die entsprechenden Verzeichnisse mit dem SetGID-Bit versehen. Somit behalten alle Dateien, die inden Verzechnissen erzeugt werden die entsprechende Gruppenzugehörigkeit.

Das Problem der Berechtigungen haben wir schon gelöst. Die Angabe umask 027 im Shell-Script bewirkt, dass neue Dateien mit den entsprechenden Berechtigungen erzeugt werden.

Nun haben wir folgendes erreicht. Dateien gehören dem jeweiligen Benutzer und können so per PHP gelesen und geschrieben werden. Ebenso ist der FTP-Zugriff voll möglich. Die Gruppenzugehörigkeit liegt beim Apache-Server, somit können alle Dateien zwar per Apache gelesen werden, aber die PHP-Scripte, die unter der Gruppe “users” laufen, können nicht auf andere Verzeichnisse zugreifen.

Zusätzlich können wir sensible Daten, die für PHP-Scripte benötigt werden, in Dateien auslagern, die nur für den Benutzer lesbar sind. Somit kann das PHP des Benutzers zwar auf diese Datei zugreifen, Apache aber nicht mehr.

Alle anderen Schutzmechanismen kann der Nutzer mit .htaccess-Dateien selbst herstellen.

Ein Sicherheitsproblem besteht allerdings weiterhin. Es gibt standardmäßig eine Vielzahl von Dateien, die jeder lesen kann. Hier ist zu beachten, dass nicht jeder sie lesen muss. Eine sorgfältige Wahl der Berechtigungen, insbesondere vieler Konfigurationsdateien, ist hier die Lösung.

Größere Sicherheit bietet nur eine chroot-Umgebung, in der der Webserver abgeschlossen läuft.

Ich hoffe dieser Leitfaden hat euch ein wenig geholfen eure Webserver etwas sicherer zu machen.

Man hat ein wunderbares Verhältnis zu bestimmten Kunden, bietet einzigartigen Service und dann irgendwann kommt aus heiterem Himmel die Kündigung. Fragt man dann einfach mal nach, kommt öfters das Argument, dass wir ja so teuer wären.

Dabei kann man doch mit uns reden. Überall scheint Handeln zur Zeit in zu sein. Nur bei uns scheint die Preisliste Gesetz zu seiin. Natürlich sind nicht alle Preise verhandelbar, aber man sollte sich auch trauen zu fragen. Man findet garantiert immer einen Weg.

Als Firma der New-Economy verlieren sämtliche Kunden, denen man seine Dienste in Rechnung stellt, natürlich ca. 10.000 Euro pro Minute, wenn keine E-Mails abgerufen werden können oder so. Daher gibt es natürlich eine 24-Stunden Hotline. Und an diesem langen Wochenende mach ich das.

OK, das wird sehr gut entlohnt, ist aber natürlich auch blöd, wenn irgendein Server heute Nacht auf einmal keine Lust mehr hat zu arbeiten. Schauen wir mal

Aber was will man von solch einem Brückentag schon erwarten. Natürlich ist nicht allzu viel los. Das habe ich heute morgen schon gemerkt, als ich doch tatsächlich in eine ganz ungewohnte Ampelphase reingerutscht bin, weil so wenig Autos unterwegs waren. Und die Kunden, die angerufen hatten, waren auch ganz dankbar, wenn man etwas ausgiebiger fachsimpeln wollte, als sonst…

Das Wetter in Münster ist jedenfalls – nun sagen wir mal – abwechslungsreich. Ich konnte heute schon Regen- und Hagelschauer, sowie heftige Windböen beobachten. Und jetzt gerade? Alles wieder normal, blanglos, bewölkt, grau…

Ich stürze mich nun in das verdiente Wochenende, nach diesem so wahnsinnig anstrengenden Tag

Der Mac mini schafft es irgendwie auch die eingefleischten Mac-Hasser zu versöhnen und erntete nur positive Resonanz Allerdings ist es eigentlich eine Unverschämtheit, was sich Apple mit der Standard-Speicherausrüstung von lediglich 256 MB gedacht hat. Ein vernünftiges Arbeiten war jedenfalls nicht möglich.

Wenigstens kamen dann gestern die ersehnten 1024 MB und das Arbeiten macht nun richtig Spaß. Immer wieder erstaunlich, wieviel Leistung doch eigentlich durch zu wenig Speicher verbraten werden kann.

Jedenfalls ist nun auch im Büro mein bisheriger Linux-Rechner rausgeflogen und ich bin nun auch die restlichen 8 Stunden am Tag veräppelt .