Ziel war es, den syslog (/var/log/messages) zu Archivierungszwecken auf einem entfernt stehenden Nadeldrucker in realtime zu sichern.  Ich habe ein paar Anleitungen gefunden wie man syslog per UDP durchs lokale Netz schickt. Habe dann aber doch was eigenes gefrickelt. Der Server läuft auf Scientific Linux der Druckerserver auf Debian.

Druckerserver (DEBIAN) einrichten

Legen Sie am besten einen extra Benutzer an und fügen Sie Ihm der Gruppe lp hinzu. Als Beispiel nenne wir mal den Benutzer drucker

# adduser drucker --ingroup lp

• SSH Server muss installiert sein und laufen
• Der Login mit dem Publickey Verfahren muss aktiviert sein (standard)
• Feste IP Adresse einrichten
• Infos zu Nadeldrucker Setup in meinem vorherringen Artikel

SSH KEY erzeugen (Scientific)

Zuerst legen wir auf dem Server / Rechner dessen syslog ausgedruckt werden soll einen SSH-Schlüssel an. Mit dem Befehl

# ssh-keygen -t rsa

legen wir einen Schlüssel an. Kein Passwort eingeben. Ansonsten kann das spätere Script nicht laufen. Den öffentlichen Schlüssel kopieren Sie mit

# ssh-copy-id drucker@druckerserver-ip

auf den Druckerserver.

Server einrichten (Scientific)

Erst einmal müssen wir ein Scipt erstellen.

# vi /usr/local/sbin/drucker.sh

Das folgende Script können Sie übernehmen. Die Daten die noch geändert werden müssen habe ich farbig markiert:

#!/bin/bash
while [ 1=1 ]
do
tail -F /var/log/messages | ssh -i /root/.ssh/id_rsa drucker@druckerserver-ip "cat > /dev/lp0"  #eine Zeile kein Umbruch
done


(Die Schleife ist dafür da, falls einmal die Verbindung abbricht)
Speichern Sie das Script ab und machen Sie es mit

chmod +x drucker.sh

ausführbar.

Nun noch das Script an die rc.local hängen

vi /etc/rc.local

und am Ende eintragen

/usr/local/sbin/drucker.sh

Nach einem Neustart sollte der Drucker nun munter in Realtime den Log ausdrucken. Ausprobieren kann man dies auch indem man das Script von Hand zum testen startet.

Anmerkung

Das Script lässt sich natürlich auch auf andere Logs anweden. Ob es /var/log/secure ist oder ein IRC Log.

Nadeldrucker mit Tweets

Mal wieder etwas neues aus dem Hackerspace fNordeingang.

Nachdem wir einen alten Nadeldrucker geschenkt bekommen haben, entsinnten wir uns doch an das Projekt aus dem Chaosdorf mit dem Nadeldrucker und der Twitteranbindung zu finden unter: http://wiki.chaosdorf.de/index.php?title=Nadeldrucker.

Das gleiche haben wir dann auch nachgebaut. Die Projektseite vom fNordeingang ist zu finden unter: http://fnordeingang.de/wiki/Twitternadeldrucker.

Hardware

Der obligatorische Nadeldrucker wird benötigt, der dann über den Parallelport an der Rechner angeschlossen wird. Sollte im Ordner /dev kein lp0 vorhanden sein muss das Modul über

modprobe lp

von Hand geladen werden, sowie in die /etc/modules eingetragen werden damit es beim hochfahren mit startet.

Mit einem

echo "Test Test 1 2 3" > /dev/lp0

sollte der Drucker eine Zeile ausgeben.

Software

Um die Tweets abzurufen brauchen wir noch den konsolenbasierten Twitterclient der sich mittels

apt-get install twidge

installieren lässt, und danach noch mit

twidge setup

eingerichtet werden muss.

Script

Im Gegensatz zu dem Chaosdorfscript läuft unseres allerdings lokal und als cronjob. Folgend das Scipt vom fNordeingang:

#!/bin/bash
(
TWEETS=$(twidge lsreplies -u -s | iconv -f utf-8 -t cp437)
if [[ -n $TWEETS ]]; then
echo "$(date)";
echo "${TWEETS}";
echo "";
echo "";
fi
) > /dev/lp0


In der /etc/crontab wird dann noch folgende Zeile angehangen. Den Pfad natürlich so ändern das er zu dem Script führt.

* *     * * *   root    /bin/bash --login /usr/local/sbin/nadeltweet.sh

Das wars. Nun sollte der Drucker jedes mal wenn jemand eine Nachricht an den eingerichteten Twitteraccount schreibt, diese Nachricht mit Zeitstempel ausgeben. Dazu ruft der cronjob jede Minute das Script auf, welches mittels twidge die Tweets abruft.

Das ganze läuft natürlich wieder auf dem Igel Winestra. Langsam kommt es mir vor das ich über nichts anderes mehr blogge.

Der Aufbau mit Igel und Webcam

Letzte Woche erwähnten meine Großeltern dass sie Nachts immer geweckt würden, weil irgendetwas auf dem Dachspeicher herumläuft. Da das Aufstellen von Lebendfallen leider nichts brachte, aber auf dem von meiner Großmutter verstreuten Mehl trotzdem Spuren zu finden waren, vermutete man einen Marder oder ähnliches auf dem Dachspeicher.

Nebenbei erwähnte ich das man ja eine Kamera aufstellen könnte um mal zu schauen ob diese etwas aufnimmt und ich da ja was für hätte.

Meine Großmutter war von der Idee total begeistert  so dass ich ein paar Tage später den Igel Winestra ThinClient mit einer USB-Webcam auf den Dachspeicher aufbaute. Da die Spuren auf einer von mehreren gepuderten Mehlstelle jeden Tag neu waren, stellten wir den Igel mit Kamera darauf gerichtet auf. Da der Igel keinerlei Lüfter hat und nur ein blaues Licht, welches ich mit schwarzen Isolierband abgeklebt habe, hofften wir das uns was in die Kamera läuft.

Tag 1

Auf dem Mehl waren zwar wieder neue Spuren, allerdings wurden keine Fotos gemacht. Ich vermutete das es daran lag das auf dem Dachspeicher nur eine kleine Lampe “glühte”, so dass wir dem nächtlichen Gast noch eine zusätzliche Leselampe hingestellt haben um ihn ins Rampenlicht zu bringen.

Tag 2

Leider wieder keine Fotos trotz eingeschalteten Licht. Die Spuren waren schon wieder da und auch das Licht war stark genug gewesen. Leider war die Auslösung nicht fein genug eingestellt, sodass ich diese so einstellte, dass bei weniger Pixeländerungen ausgelöst wird, auch mit dem Risiko durch Bildrauschen ein paar mehr Falschaufnahmen zu haben weil die Sonne mal durch das Dachfenster herein kam. Dafür war in der Lebendfalle eine kleine Maus. Den Versuch Sie einzufangen und auszusetzen endete damit das diese sich beim öffnen der Falle auf und davon machte.

Tag 3

Zwei Mäuse erwischt

Endlich was auf den Aufnahmen. Nur leider kein Marder. Sondern nur 2 Mäuse die vor der Kamera rumwuselten. Und dies über mehrere Stunden verteilt.

Da meine Großeltern aber auch die letzten Tage nichts mehr gehört haben ist entweder der Marder weg, wenn er jeh da war, oder die Mäuse sind leiser geworden. Ansonsten werde ich den Igel wieder aufbauen und schauen ob doch noch was größeres auf dem Dachspeicher rumläuft.

Technische Seite

Die Aufnahmesoftware heisst motion. Ich habe darüber auch einen Artikel geschrieben (Überwachungskamera mit motion). Der Artikel ist für openSUSE geschrieben lässt sich aber im großen auf andere Distributionen verwenden. Die Option threshold musste ich von dem Standardwert 1500 auf 400 herunternehmen, da die kleinen Mäuse zu wenig “Pixel” haben.

Jos in seinem Element

Wie Jos schon in seinem Blogpost berichtet hat, waren die Chemnitzer Linux Tage auch dieses Jahr wieder erfolgreich gewesen. Von den Gesprächen mit den Interessenten ging es im groben meistens um die neue 12.1 Release und welche neuen Features diese bietet. Auch kamen einige zu uns weil sie Probleme mit ihren Rechnern / Laptops hatten. Teilweise konnten wir auch dort helfen. Insgesamt was mir komisch vorkam, dass einige Leute bei uns die Übersetzung von openSUSE 12.1 bemängelten, was ich allerdings in den Szenarien nicht ganz nachvollziehen kann.

Da wir bei uns am Stand die von SUSE gesponserten T-Shirts und das openSUSE Bräu gegen eine geringe Spende an die Leute verteilt haben, konnten wir die gesammte Summe von 250 bis 300 Euro an die Organisatoren der Chemnitzer Linux Tage weitergeben.

Auch Klaas Freitag war bei uns mit bei der Partie und hat das ownCloud Projekt mit vorgestellt, welches er hauptberuflich mitentwickelt. Hier ist in der nächsten Zeit wohl auch noch mehr aus dem Projekt zu erwarten.

Mal so am Rande: Skuril war die Reperatur eines ThinkPad Edge 520 mit Intel Centrino N 1000 W-LAN Chipsatz der auch nach 2 Stunden gebastel nicht laufen wollte. Erst nachdem wir zwei mal das Kernel neu installiert haben und das acer_wmi Modul geblacklistet wurde funktionierte dieses. Warum es beim ersten mal nicht klappte? Keine Ahnung. Anmerken möchte ich auf jedenfall die unendliche Geduld der Praxis Dr. Tux die sich (zeitweise mit mir) mit dem Problem auseinandergesetzt hat.

Nebenstehend noch das Foto des kläglichen Versuches mit dem fedora Projekt zusammen die fedora-Flaggen aufzuhängen. Und ich sagte noch irgendwie sieht das Logo komisch aus. Das umdrehen ging dann zum Glück schnell.

Anders wie letztes Jahr werde ich mir allerdings die Zeit nehmen und ein paar Vorträge anschauen. Da dieses Jahr das Hauptaugenmerk der Vorträge auf das Linuxkernel gelegt wurde, was auch den Slogan dieses Jahres andeutet “Kernelkraft und erneuerbare Synergien”, ist mein Besuchsprogramm in der Hinsicht mit ein paar Vorträgen gefüllt.

In diesem Sinne, bis Samstag oder Sonntag.

• Packman Repo einbinden
• Codecs installieren
• Updates einspielen
• wichtige Programme nachinstallieren

Jedesmal sind solche Arbeiten ziemlich lästig, da man sich alles irgendwo wieder zusammen suchen muss. Um diese ganze Prozedur etwas zu beschleunigen habe ich ein Script geschrieben, dass einem die ganze Arbeit abnimmt. Es installiert die neuesten Updates, bindet das Multimedia Repository Packman ein und installiert alle notwendigen Codecs um auch mp3 und andere Formate abzuspielen. Vor dem Beginn der Installation hat man die Möglichkeit einige Pakete an und abzuwählen.

Die Benutzung ist natürlich auf eigene Gefahr. Benutzen Sie das Script nur bei einer noch frischen Neuinstallation. “Normalerweise” sollte es auch später risikolos sein. Allerdings habe ich dies vorher nicht ausprobiert, da jeder sein System in Nachhinein anderen konfiguriert.

Download: ununseptikum-12.1-1.1.2.sh.tar.gz (alte Version)

(Die aktuelle Version finden Sie unter der openSUSE Seite meines Blogs.)

HOWTO

Laden Sie die Datei herunter und entpacken Sie diese mit:

tar xzvf [Dateiname].tar.gz

Machen Sie das Script ausführbar mit:

chmod +x [Dateiname].sh

und führen Sie das Script als root aus:

su gefolgt von ./[Dateiname].sh

oder

sudo ./[Dateiname].sh

Ich bitte um Kritik, Vorschläge und Ressonanz.

Igel Winestra - aktueller Stand

Nachdem ich nun in der letzen Woche mal mehr – mal weniger am Gerät rumgespielt habe ein paar Infos von mir wie es um das Gerät steht. Wer noch nicht weiß worum es geht sollte erst diesen Artikel von mir lesen.

Die gute Nachricht ist, dass der IGEL noch funktioniert, die schlechte, dass nicht alles so funktioniert wie ich es erhofft habe. Aber mehr dazu im folgenden Artikel:

PCI-Steckplatz

Der PCI Steckplatz ist von den Maßen her sehr knapp bemessen. Eine USB-PCI-Karte hat nur mit viel gefummel und dem kompletten auseinanderschrauben der Karte sowie des Einbaurahmens gerade so hinein gepasst. Einen Gigabit Netzwerkkarte wollte garnicht hineinpassen. Der PCI Slot ist wohl dafür optimiert den nicht vorhanden Kartenleser aufzunehmen.

Internes USB

Der interne USB-Anschluss hat nach dem Anschluss eines USB-PCI-Brackets für die PCI Blende angefangen interessante Gerüche abzusondern. Scheinbar sind die Stifte nicht wie sonst angeschlossen. Leider habe ich im Netz nichts gefunden wie die Stiftleiste richtig belegt werden. Der USB Controller hat den Kurzschluss zum Glück ohne Probleme überlebt.

RAM nachrüsten

Der RAM-Einschub unterstützt nur Singe-Side-RAM Module. Ein 1GB-Double-Side-Riegel wurde nur mit 512 MB erkannt aber funktionierte. Ein anderer Riegel wurde vom BIOS nicht unterstützt und dieses quietierte dies mit einem Dauerpiepen.

Betriebssystem

GNUstep auf dem IGEL Winestra

Der VIA C7 Prozessor ist nett gesagt sehr langsam. Damit ich ein halbwegs komplettes System installieren kann, habe ich die Flashkarte durch ein 8GB Modell aufgerüstet. Ein openSUSE mit GNUstep startet zwar relativ schnell. Leider gibt es aber kaum Pakete für GNUstep im Build Service, so dass ich im Nachhinein ein minimales Debian installiert habe, welches auch halbwegs flott arbeitet. Leider lässt sich der BeOS Nachbau Haiku nicht dazu bewegen mit dem Thinclient zu arbeiten. Es stürzt schon beim booten ab. Schade eigentlich, da bei Haiku die Oberfläche im Kernelmode läuft und so eventuell noch was Leistung rauszuholen gewesen wäre.

Update: Da GNUstep zwar ganz nett ist, aber letztendlich an der Bedienung scheitert habe ich ein LXDE installiert. Dies ist genauso schnell und verbraucht in etwa genauso wenig RAM wie GNUstep.

Spielereien

Da der TMDS Chip etwas warm wird habe ich einen passiven aufklebbaren Kühlkörper darauf geklebt. Dies ist eigentlich unnötig. Ich hatte nur noch Kühlkörper übrig.

Was noch ansteht ist die Netzwerk-LED. Dafür werde ich wohl noch ein Loch in die Abdeckung bohren. Mal sehen was sich sonst noch damit anfangen lässt. Zurzeit arbeitet die Kiste als aufgebohrter Terminal Emulator im Neusser Hackerspace.

Interessante Links zum Thema:

• http://www.debianhelp.co.uk/gnustep.htm > GNUstep unter Debian installieren

Igel 4210 LX Winestra

Nachdem ich schon länger damit geliebäugelt habe mit einen Thinclient anzuschaffen (ehr aus der Hinsicht das die Thinclients bei der Bucht günstig zu bekommen sind und man damit rumbasteln kann) habe ich mir ein Igel 4210 LX Winestra gekauft. Das System selber ist ausgestattet mit einem 1Ghz VIA Prozessor, 256MB DDR2 RAM und einer 128 MB Compact Flash Karte als Datenspeicher. Da das System also etwas schwachbrüstig ist muss man hier schon einiges bei der Distributionswahl beachten. Es sei denn man bootet von Netwerk oder bastelt sich etwas zurecht.

Man hat nun die Wahl das Gerät aufzurüsten was ohne weiteres geht. So lässt sich das RAM auf bis zu 1 GB erweitern und die Compact Flash Karte austauschen. Hier ist allerdings auf Kompatibilität zu achten. Auch ein normaler IDE Anschluss ist am Mainboard verbaut. Allerdings muss man dann schauen wie man das Laufwerk mit Strom versorgt. Dies ist nur von einer externen Stromversorgung möglich. Praktischerweise sind Pins für USB intern vorhanden sowie ein aufgelöteter Temperaturmesser. Dazu ist eine PCI Schnittstelle verbaut, so das sich eine Erweiterungskarte einbauen lässt. Die CPU ist passiv gekühlt und somit ist das gesammte Gerät geräuschlos. An der Frontblende sind Anschlüsse für eine LED vorhanden die die Netzwerkaktivität anzeigt. Diese muss allerdings aufgelötet werden.

Hardware

Igel Mainboard

Folgend ein paar Informationen über die verbaute Hardware. Eingebaut ist wie erwähnt ein  VIA C7 Prozessor mit 1 GHz (128KB Cache, MMX, SSE, SSE2). Die Grafikkarte Der TMDS Chip ist ein Silicon Image SIL 164CTG64. Der Ethernetcontroller, sowie Audio sind im Southbridge untergebracht. Dabei handelt es sich um ein VIA VT8235. Der Verbrauch des Systems soll bei Auslastung um die 20 Watt liegen.

Grün = IDE Stiftleiste, Rot = USB Stiftleiste, Blau = Temperatursensor, Orange = PCI Slot

Linuxdistributionen

SliTaz Linux

Als Linuxdistribution fallen die großen Majordistributionen wie openSUSE, ubuntu oder fedora etc. leider aus, da sich diese nur mit sehr viel Aufwand auf 128 MB Speicher mit grafischer Oberfläche installieren lassen. Aus diesem Grunde habe ich mich für SliTaz Linux entschieden, welches bei der Standardinstallation knapp 110 MB benötigt so das noch etwas Luft vorhanden ist. Durch entfernen von ein paar Pakete kann man sogar noch etwas herausholen.

Hacken

Da ich das Gerät erst seit ein paar Tagen besitze werde ich wohl noch etwas damit rumbasteln. Da das Gerät einen internen USB Anschluss hat werde ich eine alte USB Blende benutzen um diese an die USB Steckleiste anzuschließen und daran einen USB-Stick. Das Kernel wird dann auf die Compact Flash Karte geschrieben (wegen Treiber) und die restlichen Daten auf den USB Stick. Dies ist eine wesentlich kostengünstigere Methode, als eine neue große Compact Flash Karte zu kaufen. Das RAM werde ich noch auf 1 GB mit einem alten Arbeitsspeicherriegel erweitern. So sollte sich auch eine normale Distribution aufspielen lassen. Falls noch Platz bleibt könnte man noch eine TV Karte oder zusätzliche Netzwerkkarte einbauen. Mehr dazu werde ich hier später noch schreiben.

Interessante Links zum Thema

YouTube Video über das System > http://www.youtube.com/watch?v=v1LlTvM2r_E

Alle Befehle werden als root ausgeführt.

Zuerst müssen wir einige Pakete nachinstallieren (falls noch nicht installiert).

yum install httpd mod_perl php-mbstring perl-string-Multibyte php php-mysql

Abhängigkeiten werden automatisch aufgelöst. Nach der Installation wechseln wir mit

cd /var/www/html

in das Webverzeichnis vom apache. Laden Sie mit

wget http://owncloud.org/releases/owncloud-2.0.1.tar.bz2

die aktuelle Release herunter. Der Link oben war zum Zeitpunkt des Artikels aktuell. Nach dem Herunterladen entpacken Sie das Verzeichnis mit

tar xvjf owncloud-2.0.1.tar.bz2

Dann ändern Sie mit

chown -R apache:apache /var/www/html

den Verzeichnisbesitzer sowie mit

chmod 0770 /var/www/html/owncloud/data

die Schreibrechte des späteren Datenverzeichnisses von ownCloud.

Nun müssen wir den apache noch so Konfigurieren, dass die gespeicherten Dateien nicht direkt herunterladbar sind. Öffnen Sie die Konfigurationsdatei mit

vi /etc/httpd/conf/httpd.conf

und ändern Sie die unten stehende Optionen wie folgt ab (Sie müssen die Taste i drücken um in den Einfügemodus zu gelangen; speichern mit ESC :wq):

<Directory "/var/www/html">
Options None
AllowOverride None
Order allow,deny
Allow from all
</Directory>

und fügen Sie am Ende der Datei noch folgendes ein:

<Directory “/var/www/http/owncloud/”>
Options +Indexes
AllowOverride All
Order allow,deny
allow from all
</Directory>

Damit Dateien über 2 MB hochgeladen werden können müssen wir die php.ini noch bearbeiten. Mit dem Befehl:

vi /etc/php.ini

Öffnen Sie die Datei und ändern unten stehende Werte wie folgt ab:

upload_max_filesize=8MB
upload_max_size=8MB

Nun müssen Sie noch mit

system-config-firewall-tui

die Firewall einrichten und Port 80 freigeben. Klicken Sie auf Anpassen und wählen Sie den Punkt WWW (HTTP) aus (weiter unten in der Liste). Dann auf Schließen > OK > Ja.

Nun können Sie ownCloud mit

service httpd start

starten. Erreichbar ist es unter

IP.des.Servers/owncloud.

Tipp: Im Ordner /var/www/html liegt noch die owncloud tar.gz Datei. Diese können Sie nun löschen.

Interessante Links zum Thema

• http://www.howtoforge.com/forums/showthread.php?t=13702 > Tipp weil owncloud nicht ohne php-mbstring läuft
• http://demo.owncloud.org/files/index.php > ownCloud DEMO

Da ich nun eh schon am Server dran war habe ich mir Gedanken gemacht inwieweit es sinnvoll ist openSUSE weiterhin auf dem Server zu betreiben. Nicht aus Gründen des Systems sondern aus der Sicht des Supportzeitraums. Spätestens Ende 2012 müsste ich mir Gedanken über in Upgrade auf die nächst höhere Version machen. Das dies meistens nicht klappt ist wohl bekannt (siehe Versionsprung auf 11.4 mit dem AppArmor Bug und SMB). Da ich allerdings auch kein Debian(derivat) verwenden wollte blieb im Endeffekt nur noch CentOS und Scientific Linux übrig. Ich habe mich dann letztendlich für Scientific entschieden, da dort die Updates schneller gepackt werden.

CentOS oder Scientific

Scientific Linux

CentOS und Scientific sind beides Nachbauten von RHEL. Da Red Hat die Quellpakete offen legen (muss), kann daraus eine Distribution gepackt werden die binärkompatibel mit RHEL ist. Und da RedHat seine Distribution 5 bzw. 7 Jahre mit Updates versorgt, können CentOS und Scientific die Updates einfach verpacken und ausliefern. Zwar habe ich kein Support durch RedHat, diesen werde ich aber bei mir Zuhause wohl kaum benötigen.

Scientific Linux

Wie schon erwähnt ich Scientific Linux ein Klon von RHEL. Gebaut wird die Distribution zum großen Teilen von CERN, Fermilab, ETH Zürich, und dem DESY. Diese haben sich zusammenschlossen um auf einer Basis eine eigene Distribution zu schaffen, damit nicht jede Institution ihre eigene Distribution pflegen muss. Mehr dazu findet sich auf der Wikiseite von Scientific Linux.

Servereinsatz

Auf dem Server macht sich Scientific gut, auch wenn ich manch praktische Dinge von openSUSE vermisse. Das Einrichten von rsync ist etwas aufwendiger. Das voreingestellte SELinux ist bisweilen (für mich) unbrauchbar. Weder rsync noch SMB ließen sich mit den voreingestellten SELinux Regeln benutzen. Auch nachdem ich die Regeln so geändert  habe das es laufen sollte, lies sich rsync immernoch nicht verwenden. Ich habe SELinux dann einfach vom System genommen. An der Stelle finde ich AppArmor bei weitem einfacher zu konfigurieren und warten.

Desktopeinsatz

Scientific Linux Screenshot

Auf dem Desktop kann ich Scientifc Linux zum Teil empfehlen. Es kommt darauf an was machen möchte. Das KDE liegt in Version 4.3 vor. Neuere Versionen müsste man sich selber kompilieren und aktualisieren. Das Gnome liegt in Version 2.28 vor und macht einen stabilen Eindruck. Für Arbeitsplatzrechner oder für einfache Arbeiten ist der Desktop völlig in Ordnung. Wer allerdings “bleeding edge”-Software haben möchte sollte dann doch lieber zu einer schneller veröffentlichenden Distribution wie openSUSE oder Fedora wechseln. Ansonsten bekommt man ein stabiles System, das für die normalen Office und Internetanwendungen völlig ausreichend ist. Sollte man Scientific für den Desktop verwenden und hat nicht mehr als 4 GB RAM empfehle ich die 32bit Version, da es dort mehr Pakete für gibt die man sich sonst extra raussuchen muss. CentOS und RHEL Paketquellen können eigentlich ganz normal benutzt werden da alle Distributionen zueinander kompatibel sind.

Interessante Links zum Thema:

• Scientific Linux Wiki > http://www.scientificlinux.org/about/history.long
• CERN Scientific Linux Seite > http://linux.web.cern.ch/linux/