Archiv der Kategorie: Alix

Streaming-Audio-Server – Ein Versuch

Veröffentlicht am von
Antworten

Die Folge 39.5 von Anfang September mit dem Thema „Mein eigener Server“ des c’t Uplink Podcasts hat auch bei mir wieder Lust auf einen eigenen Home-Server geweckt. In den letzten zwölf Monaten habe ich verstärkt auf meine digital gespeicherte Musiksammlung – also im Wesentlichen MP3-Dateien – zurückgegriffen. Sei es, weil mein einfacher, kleiner MP3-Player unerwartet kaputtgegangen ist und ich mir einen neuen kaufte, ohne dass ich die Ordnerstruktur mit den Musikdateien vorher noch vom alten Player auf einem Computer zwischenspeichern konnte, oder weil mein Hörinteresse insgesamt in dem benannten Zeitraum auch wieder von den Podcasts weg zu mehr Musik gewandert ist. Anders als viele andere möchte ich aber kein Network Attached Storage (kurz NAS) betreiben und habe es auch bisher noch nicht. Stattdessen habe ich die archivierten Dateien auf einer externen Festplatte gespeichert, wie viele einfache Computernutzer es auch handhaben. – Allerdings mit dem Unterschied, dass ich sie auf zwei externen Festplatten gespeichert habe, um immer wenigstens noch einen redundanten Datenträger zu haben, falls eine kaputtgeht. Der Nachteil gegenüber einem NAS ist aber, dass ich nicht von jedem Gerät immer sofort auf die Dateien zurückgreifen kann. Das liegt zum einen daran, dass die Gehäuse der externen Festplatten unterschiedliche Schnittstellen haben, und zum anderen daran, dass sie mit einem Apple Dateisystem formatiert sind. Je nach Computer und dem darauf installiertem Betriebssystem kann ich also nicht eine der externen Medien immer direkt anschließen, an dem ich sie verarbeiten möchte. Ich muss sie also immer an einen bestimmten Mac mit der richtigen Schnittstelle anschließen und die Dateien mittels einem flexibleren Wechseldatenträger wie einem mit dem Dateisystem exFAT formatierten USB-Stick auf meinen Zielcomputer übertragen, was sehr umständlich und zeitraubend ist. Ich muss nicht immer regelmäßig auf alle meine archivierten Dateien zugreifen, aber da es sich bei denen, wo es in letzter Zeit der Fall ist, um Audio-Dateien handelt, liegt doch der Gedanke nahe, einen Streaming-Server für Musik zu bauen, von dessen mit jedem Gerät sofort die gewünschte Musik abgespielt werden kann. Das sorgt außerdem dafür, dass wenn die Dateien nicht auf dem Endgerät vorhanden sind, sie auch nicht den begrenzten Festspeicherplatz des Endgeräts in Anspruch nehmen und auch die Backups dieser unnötig vergrößern.

Vor dreizehn Jahren habe ich mir für meinen ersten Home-Server das Alix.1C Embedded Board von PC Engines angeschafft. Anfangs einige Zeit mit NetBSD und später durchgängig mit OpenBSD betrieben, diente der Computer für irssi in einer Screen-Session, dann mal als Konsolen-Torrent-Client oder Tor Middle-Node und war meistens über dynamischen DNS aus dem öffentlichen Internet im eigenen Heimnetzwerk erreichbar. Auf die 32 Gigabyte CompactFlash-Karte, die ich einige Jahre später dazu gekauft habe, würde ich meine MP3-Sammlung zwar gespeichert bekommen, aber die Karten sind in ihrer Lese- und Schreibgeschwindigkeit sehr langsam gegenüber den moderneren Festplatten (späte IDE- und generell SATA-Laufwerke). Zum Glück habe ich aber noch irgendwo eine gebrauchte SATA-SSD mit 256 Gigabyte Speicherkapazität herumliegen. Da die Alix-Boards noch einen 44-Pin IDE Port für 2,5″ IDE-Laufwerke besitzt, bin ich das Wagnis eingegangen und habe mir für 12 Euro mal einen 2,5 Zoll SATA (Female) HDD Drive auf IDE 44 Pin Konverter bestellt. Ich war anfangs etwas skeptisch, aber so ein SATA auf 44 Pin IDE-Konverter funktioniert doch problemlos. Der einzige Nachteil, der durch den Konverter entstanden ist, ist der, dass er mit dem 2,5″ Medium die Höhe des schmalen Gehäuses etwas überschreitet und ich das System nicht mehr geschlossen bekomme. Das SATA-Medium wird durch den IDE-Controller vom Board wie ein IDE-Medium erkannt und angesteuert.

ALIX.1C Innenansicht

Ich habe in den letzten vier Jahren das Alix-System zwar nicht mehr nennenswert im Einsatz gehabt, aber vor gut zwei Jahren musste ich feststellen, dass das System von dem OpenBSD Installations-Image auf einem USB-Stick spätestens seit der damaligen Version 6.5 nicht mehr in der Lage ist zu booten. Was der Grund für den Fehler ist, konnte ich bis jetzt nicht herausfinden. Auch der Versuch von einem OpenBSD Installations-Image für die x86 64-Bit statt der x86 32-Bit hat nicht geholfen und die Gesamtsituation hat sich bis zu der vor gut zwei Wochen erschienen OpenBSD Version 7.0 nicht gebessert. Zum Glück hatte ich mir zu Anfang dieses Jahres die be quit! Bastel- und Retro-Workstation zusammengebaut, um von dem Installationsmedium aus zu booten und das System auf den Zieldatenträger zu übertragen. Der erste Boot-Vorgang von dem Zieldatenträger als Hauptdatenträger im Alix-System funktioniert dann zum Glück wieder fehlerfrei, sodass die weitere Konfiguration damit kein Problem darstellt.

2,5 Zoll SATA (Female) HDD Drive auf IDE 44 Pin Konverter

Mit dem nun nach wie vor unter OpenBSD betriebenen Alix-System als wirklich sinnvollen Home-Server habe ich mir auch das Ziel gesetzt, einen eigenen benutzerdefinierten Kernel zu kompilieren. Die Standard-Kernel der drei großen bekannten BSD-Systeme sind zwar schon wesentlich kleiner als die der großen bekannten Linux-Distributionen, aber in Hinblick darauf, dass das Alix-System nur 256 MiB Arbeitsspeicher besitzt, finde ich es nicht verkehrt, es noch Resourcen-schonender zu konfigurieren. Bisher hatte ich benutzerdefinierte Kernel unter NetBSD und zu Anfangs mal kurz unter FreeBSD erstellt. Die Verfahrensweisen und Abläufe sind aber prinzipiell bei allen BSD-Betriebssystemen identisch. Bei meinem jetzt unter OpenBSD 7.0 selbsterstellten Kernel habe ich die Treiber für alle auf dem Alix-Board verbauten Hardware-Komponenten beibehalten und alle diejenigen entfernt, die auch nicht auf dem Board verbaut wurden. Zusätzlich habe ich noch die Unterstützung für einige Dateisysteme entfernt, mit denen ich hier zu Hause eh nicht (mehr) mit dem Alix-System in Berührung kommen könnte (Linux ext2, UDF, CD9660 und NFS). Außerdem habe ich die Software-RAID Funktionalität entfernt und die Farbgebung für Kernel-Ausgaben auf den seriellen Konsolen von der standardisierten weißen Schrift auf blauen Hintergrund zu der für mich angenehmer zu lesenden weißen Schrift auf schwarzem Hintergrund. Ich hätte gerne noch alle Funktionalitäten des Point-to-Point Netzwerkprotokolls und die Unterstützung der VPN-Protokolle entfernt, aber der Kernel hat auf der Standardausgabe während des Boot-Vorgangs (noch) zu viele Fehler geworfen, auch wenn der Rest trotzdem funktioniert hätte. Trotzdem konnte ich die Größe des Kernels signifikant verkleinern. War die ausführbare Kernel-Datei des generischen Kernels noch fast 15 Megabyte groß, war die Datei meines Kernels nur fast 5 Megabyte groß. Während der generische Standard-Kernel im Arbeitsspeicher 20 Megabyte belegte, benötigte mein Kernel nur noch die Hälfte im RAM. Für die Statistik: Da der AMD Geode LX Prozessor – bassierend auf AMDs K7 Mikroarchitektur – nur 500 Megahertz, 2 mal 64 KiB Level-2 und nur 128 KiB Level-2 Cache besitzt, dauert der Kompiliervorgang des generischen Standard-Kernels von OpenBSD 7.0 zwei Stunden und 55 Minuten. Der Kompiliervorgang meiner Kernel-Konfiguration hat dann nur noch 41 Minuten gedauert.

Ich habe mir gedacht, dass es prinzipiell nicht verkehrt sein kann, dass auf dem Alix-Home-Server auf alle Fälle auch ein FTP-Server verfügbar sein sollte, denn schließlich will ich die MP3-Dateien von der an einen meiner Mac’s angeschlossenen, externen Festplatte auf den zukünftigen Musik-Streaming-Server übertragen, beziehungsweise die MP3-Dateien auf einen mobilen Computer oder Abspielgerät für unterwegs herunterladen. – Wie gesagt, ich möchte nicht immer jedes Mal eine der beiden externen HDDs herauskramen müssen.

ALIX.1C mit SATA zu 44 Pin IDE Konverter und 2,5″ SATA-HDD

Da ich mich alleine in meinem privaten Heimnetz befinde, habe ich auf eine Transportverschlüsselung für FTP verzichtet. Nachdem ich meine MP3-Sammlung also via FTP auf dem Server transferiert habe, musste ich feststellen, dass beim Versuch die MP3s via FTP zu lesen und wieder auf ein Endgerät zu kopieren, der FTP-Client bei einigen Dateien Fehlermeldungen ausgab. Offensichtlich sind bei dem Transfer der Dateien auf den FTP-Server bei den betroffenen Dateien einige Bits gekippt. Erst nachdem ich auf dem FTP-Server die Sammlung gelöscht und anschließend die Dateien statt via FTP mit scp erneut auf den Server transferiert habe, funktionierten sie auch alle ausnahmslos. Die effektive Transferrate bei scp ist allerdings etwas geringer als bei FTP, sodass der Datei-Transfer auch etwas länger dauert, aber das macht nichts.
Für den eigentlichen Streaming-Audio-Server hatte ich mir zwei Software-Lösungen ausgesucht.: Den Icecast, welcher von Internetradios gern für das Streamen verwendet wird, und die Media-Streaming-Weboberfläche Ampache.

  • Ampache: Ampache ist ein Kofferwort aus Amplifire und dem bekannten Web-Server Apache. Mit Ampache kann man seine Musik-Bibliothek verwalten, ähnlich wie mit iTunes und bietet verschiedene Berechtigungsstufen. Es ist aber auch möglich, eine Playliste als reinen HTTP-Stream in einem Netzwerk zur Verfügung zu stellen. Von den Entwicklern wird nur Linux und FreeBSD unterstützt. Unter FreeBSD habe ich Ampache nicht zum Laufen bekommen, sondern leider nur unter einem Debian 10 Buster, was schon unter die Kategorie old-stable fällt. Ich hatte mir schon gedacht, dass die 500 Megahertz und 256 MiB RAM der Alix zu wenig sind für Webserver, PHP und SQL-Datenbank sind. Die ganze Implementation ist zwar nicht sehr schnell, aber es funktioniert wie es soll. Problematisch bei der begrenzten Rechenleistung wird es aber mit ffmpeg. Bei einer MP3-Datei mit 320 kbps und einer Spielzeit von zwei Stunden hat sich dann der ffmpeg-Enkoder verschluckt und der Prozessor lief am Limit. Konnte Ampache dann wieder andere, kleinere MP3-Dateien mit ffmpeg verarbeitenund abspielen, sah es so aus, dass von den großen MP3s noch ffmpeg-Zombieprozesse übrig blieben, die es zu killen galt. Für das Alix-System dann doch keine so zufriedenstellende Lösung.
  • Der Icecast-Server ist prinzipiell so ausgelegt, dass er aus einer Audioquelle an der Soundkarte einen HTTP-Livestream ins Netz stellt. Icecast kann aber auch von Audio-Dateien einen Stream erzeugen. Dafür ist eine Textdatei nötig, die als Playliste fungiert. Um sich spontan eine Liste zusammen zustellen ist dies aber doch etwas umständlich. Da auch Icecast sich ffmpeg bedient, wird das auch hier wieder der Bottleneck bei großen Audio-Dateien sein, auch wenn Datenbank und PHP nicht nötig sind.

Da ich auf meinen Desktop-Computern relativ kleine und schlanke Medienplayer mit einer einfachen Listenfunktionalität benutze, die Drag-and-drop fähig sind, wollte ich mal ausprobieren, wie diese damit klarkommen, wenn sie direkt auf die Dateien von einem gemounteten FTP-Share zugreifen sollen. Sowohl der ältere Cog als auch der moderne IINA laden alle Dateien immer vollständig. Sind es viele auf einmal wie zum Beispiel ein Ordner mit 200 Stück, sind die Player je nach Menge zu Anfangs immer etwas ausgelastet. Der Vorteil: alle ID3-Tags und weitere Meta-Daten wie Album-Cover sind verfügbar. Der Nachteil ist, dass das Hörvergnügen zu Anfangs kurze Startschwierigkeiten haben kann.
Der VLC Media Player verhält sich da schon ganz anders. Bei dem Lesen der Dateien von einem FTP-Share wendet dieser tatsächlich das Streaming-Prinzip an. Das heißt, dass er kontinuierlich immer nur das benötigte Stück der Audio-Datei lädt. Damit werden die langen Ladezeiten eliminiert. Die Nachteile sind aber, dass er erstens die Meta-Daten von den Dateien nicht lädt, zweitens kommt der VLC überhaupt nicht damit klar, wenn die Dateinamen sich mit Zeichen aus der aktuellen UTF-Implementation bedienen, die nicht mit den Buchstaben des ASCII-Codes übereinstimmen. Kurz gesagt: enthält der Dateiname beispielsweise einen Akzent über einem Vokal oder er enthält einen kyrillischen Buchstaben, kann der VLC Media Player die Datei nicht lesen.

Fazit:
Alles in allem ist die Lösung, dass ich mit einem lokalem Medienplayer auf einem meiner Endgeräte auf die Dateien via FTP zugreife, für mich zurzeit die am gangbarsten. Allerdings werde ich extra für den VLC Media Player jetzt nicht alle Dateinamen mit Buchstaben aus dem ASCII-Zeichensatz ersetzen.

Links:

Tor-Server unter OpenBSD

Veröffentlicht am von

Da ich schon seit längerer Zeit meine Irssi-Instanz von meinem ALix-Homeserver auf einem V-Server verlegt habe, kann man die ungenutzte Bandbreite zu Hause für andere gemeinnützige Dienste nutzen. Deswegen habe ich mal auf den Rechner einen Tor-Server aufgesetzt um den Privacy-bewussten Computernutzer zu unterstützen.

Anbei erst einmal die Installationsanleitung unter OpenBSD.:

1. mit pkg_add installieren:

   # pkg_add tor

2. Tor beim Booten starten:

Dazu muss die /etc/rc.local editiert werden

if [ -x /usr/local/bin/tor ];
then
echo -n ' tor';
/usr/local/bin/tor -f /etc/tor/torrc
fi

3. Konfigurieren

Damit Tor beim booten in den Hintergrund forked, muss folgendes in der /etc/etc/tor/torrc aktiviert werden:

   RunAsDaemon 1

Als nächstes muss ein Verzeichnis für Tor’s Daten in der torrc festgelegt werden:

   DataDirectory /var/spool/tor

Weiterhin muss ein Verzeichnis für Tor’s Logfiles in der torrc festgelegt werden:

   Log notice syslog /var/log/tor

Dann müssen diese Verzeichnise noch erstellt und den Benutzern tor und root müssen die Rechte dafür gegeben werden:

# mkdir /var/spool/tor
# chmod 40700 /var/spool/tor
# chown _tor:_tor /var/spool/tor
# mkdir /var/log/tor
# chmod 40700 /var/log/tor
# chown _tor:_tor /var/log/tor

Die ganze Server-Geschichte lasse ich erst einmal weiterhin als Entry-Node laufen, bis ich mir eventuell mal ein paar Gedanken dazu gemacht habe, wie ich den Dienst für bestimmte Services weiterhin öffnen kann, ohne in Konflikt mit Ermittlungsbehörden zu kommen.
Entsprechend sieht der Abschnitt zur Exit-Policy in der /etc/tor/torrc wie folgt aus.:

   ExitPolicy reject *:* # no exits allowed

Anleitung zum Erstellen eines bootbaren USB-Stick als Installationsmedium unter OpenBSD

Veröffentlicht am von

Nachdem ich nun sehr lange meine Alix mit NetBSD in der Version 4.0 betrieb und sie aber im letzten Jahr für die meiste Zeit doch nicht im Betrieb wahr, dachte ich mir, man könnte doch mal bei der Reaktivierung eine neue OS-Version installieren. Allerdings ist es mir absolut nicht gelungen, unter NetBSD einen neuen entsprechend bootfähigen USB-Stick als Installationsmedium zu erstellen.

Nach ein wenig Suchen im Web bin ich allerdings auf ein HowTo gestossen, wie man dies unter OpenBSD mit etwas knapp-eleganten Befehlen löst. Also habe ich dieses selber mit Erfolg versucht und stattdessen mal ein aktuelles OpenBSD auf mein Maschinchen geworfen.

Dieses HowTo habe hier mal übernommen und ein wenig erweitert:

 

1 Securelevel herabsetzen

Zuerst als root anmelden und in der Datei /etc/rc.securelevel den securelevel auf -1 setzen.

securelevel=-1

Danach erst einmal das System neu booten.

 

2 Ermitteln der Geometrie des Sticks

Bei dem einstecken des USB-Stick in einen Slot werden folgende Parameter angezeigt:

sd0 at scsibus1 targ 1 lun 0: <USB, Flash Disk, 3000> SCSI0 0/direct removable

sd0: 247MB, 247 cyl, 64 head, 32 sec, 512 bytes/sec, 506880 sec total

Sie teilen einem die Geometrie des verwendeten Sticks mit.

 

3 Schreiben des Master Boot Record (MBR)

# fdisk -i -c 247 -h 64 -s 32 sd0

 

4 Partitionieren des Mediums

# disklabel -f /tmp/fstab -E sd0

Um die vorhandenen Partionen sich anzuzeigen zu lassen:

>p

Nun die vorhandenen Partionen löschen:

>d a

Neue Partionen erzeugen:

>a a

offset: <enter>

size: <enter>

FS type: <enter>

mount point: /<enter>

Sichern und Beenden:

>q

 

5 Formatieren des Mediums

# newfs sd0a

 

6 Mounten des Devices

# mount /dev/sd0a /mnt

 

7 Kopieren des Kernels

# cp /bsd /mnt/

 

8 Schreiben des Partition Boot Record (PBR)

# cp /usr/mdec/boot /mnt/

# /usr/mdec/installboot /mnt/boot /usr/mdec/biosboot sd0

 

9 Mounten und kopieren der Daten der Orginal-Installations-CD

# mkdir /image

# mount -t cd9660 /dev/cd0a /image

# cp -R /image/4.8 /mnt

# cp -R /image/etc /mnt

 

10 Unmounten der Devices

# umount /mnt

# umount /image

 

11 Securelevel wieder heraufsetzen

In der der Datei /etc/rc.securelevel den Wert von securelevel=-1 wieder auf einen seiner Wahl setzen. Standardmässig ist 1 eingestellt. Am Ende das System neu starten.

Angepasster NetBSD-Kernel für das ALIX.1C

Veröffentlicht am von

Anbei gebe ich mal eine erste Version für eine individuell angepasste Kernelkonfiguration von NetBSD 4.0 für das ALIX.1C Board an. Auch wenn NetBSD als solches als ein Betriebssystem angesehen wird, welches auf möglichst vielen Hardwareplattformen (z.B.: Embedded-Systeme, alte UNIX-Workstations) zum Einsatz kommen soll, macht diese Vorgehensweise auf einer Single-Board-Lösung wie dem ALIX besonders viel Sinn. Zum einem handelt es sich dabei um Hardware, die aufgrund ihrer Konzeption nur sehr geringe Leistung erbringen kann und diese auch nicht ausbaufähig ist, zum anderen basiert diese gleichzeitig auch auf der gewöhnlichen und handelsüblichen i386-Architektur, die aus historischer Sicht und aufgrund ihrer sehr umfangreichen technischen Weiterentwicklung unter den frei verfügbaren Unix-Entwicklungen sehr viel Unterstützung in Form von Treibern vieler zusätzlich erhältlichen Hardware-Komponenten gefunden hat. Konkret heißt das für mich, dass ich durch das Weglassen vieler (alten) verfügbaren Bustechnologien (z.B. MCA, EISA oder Bluetooth) und der dafür verfügbaren Hardwarekomponenten den Kernel um ein wesentlichen Anteil verkleinern konnte. Zusätzlich habe ich noch bewusst auf die Unterstützung einiger Schnittstellen, die das ALIX-Board anbietet, verzichtet. Dies währe zum einem der verbaute Sound-Chip, da er für einen Serverbetrieb nicht benötigt wird. Zum anderen kann man auch auf die Funktionalität einer Parallelen Schnittstelle verzichten, wenn man wie ich das Board in das kleinste verfügbare Gehäuse verbaut, wo es keine Möglichkeit gibt, sie von dem internen Pfostenstecker heraus zu leiten. Auf diese Weise konnte ich also nun wie gesagt die Größe des generischen Standartkernel um mehr als die Hälfte senken. Aber sicherlich ist an der Konfiguration noch einiges an Optimierung möglich.

Alix.1c-Kernelkonfiguration

Das ALIX

Veröffentlicht am von

Neues Spielzeug hat am Dienstag den Weg in meine Stube gefunden. Es handelt sich um ein Alix.1C Board nebst Zubehör des schweizerischen Unternehmen PC Engines. Neben den anderen des selben Herstellers angebotenen Boards, welche auch für eine Vielzahl von Lösungen geeignet ist, besitzt dieses durch einige zusätzliche Features die Möglichkeit als Thin Client genutzt zu werden. Heraus zu heben sind zwei Eigenschaften, die diese Dinger haben: Erstens – obwohl die CPU nur mit maximal 500 MHz getaktet ist, ist sie so designed, dass sie weder mit einem Kühlkörper bestückt ist, geschweige denn ein Lüfter die ganze Zeit herum surrt um die Abwärme ab zu führen. Und zweitens verbraucht das Alix durch das Single-Board-Design ohne angeschlossener Erweiterungskarte oder einem Datenträger nur 5 Watt Strom. Das macht das gute Stück, egal ob mit Festplatte in einem größerem Gehäuse oder auch nicht, zu einem kleinen Homeserver den man einfach in eine Ecke verfrachten und tun lassen kann ohne das er einem in irgendeiner Form weh tut. Es produziert weder Wärme noch Lärme durch irgendwelche Lüfter und verbraucht sehr sehr wenig Strom.
Ich habe mir das Board mal mit folgendem Zubehör zukommen lassen: einem schwarzen verzinktem Stahlgehäuse, 2 GB CompactFlash-Karte, 12V Netzteil und einem 3 Meter Nullmodemkabel.

ALIX1C-Frontansicht

Im folgendem erst auch noch ein paar technische Daten:

Technische Daten:

– Prozessor: AMD Geode LX800 (500 MHz, 64 + 64 KByte L1 Cache, 128 KByte L2 Cache)
– 256 MByte SD-RAM Speicher (fest installiert)
– 512 KByte Flash-Speicher (Award-BIOS)
– 1 x Batterie für Real Time Clock
– 1 x Summer für einfache akustische Rückmeldungen
– Spannungsversorgung: 12V Gleichstrom über 5,5mm Hohlstecker
– Leistungsaufnahme: ca. 4-5W (ohne Erweiterungskarten und ohne Festplatte)
– Abmessungen: 170 x 170 mm, Mini-ITX

Externe Anschlüsse:

– 1 x 10/100 MBit/s (VIA VT6105M) Netzwerkinterface
– 1 x serielle Schnittstelle (1 x DB9 Stecker)
– 1 x kombinierter PS/2 Tastatur- und Mausanschluss
– 2 x USB 2.0 Ports (2 x USB-A Buchsen)
– 1 x 15-poliger VGA Anschluss
– 1 x AC97 Audio Codec (Line In, Line out, Kopfhörer, Mikrofon)

Interne Anschlüsse:

– 1 x CompactFlash-Anschluss (Master/Slave konfigurierbar, ohne Hot Swap)
– 1 x 44-poliger IDE-Anschluss für 2″ Notebookfestplatten
– 1 x serielle Schnittstelle (1 x 10-poliger Pfostenstecker)
– 1 x Parallelport (26-poliger Pfostenstecker)
– 2 x USB 2.0 Ports (2 x 10-poliger Pfostenstecker)
– 1 x GPIO Anschluss (26-poliger Pfostenstecker)
– 1 x LPC Anschluss (20-poliger Pfostenstecker)
– 1 x I2C Anschluss (4-poliger Pfostenstecker)
– 1 x Front Panel Anschluss (Power Switch, Reset Switch, Hard Disk LED, Power LED)
– 1 x miniPCI (z.B. für Wireless LAN und VPN miniPCI Karten)
– 1 x PCI Steckplatz (3,3 Volt)

ALIX1C-Rückansicht

ALIX1C-Innenansicht

Wie bereits angedeutet, habe ich mich als festen Datenträger gegen eine Notebookfestplatte und stattdessen für eine nur 2 GB große CompactFlash-Karte entschieden. Da ich das System erst einmal nur für ein paar IRC-Instanzen nutzen will und eventuell noch einem Anonymisierungsdienst anbieten möchte, reicht dies als Festplattenplatz erst einmal völlig aus. Ein entscheidender Vorteil dieses Board’s für mich ist, das es als einziges Modell in dem Portfolio sowohl einen VGA-Anschluss als auch einen PS/2 Anschluss für eine Tastatur bietet. Da ich nämlich bereits bisher noch keine Erfahrung mit einer seriellen Konsole über das Nullmodem habe, bietet es mir so erst einmal einen sicheren Anfang in das Aufsetzen eines Servers ohne grafische Benutzeroberfläche. Als Betriebssystem habe ich mich für ein NetBSD 4.0 entschieden, welches ich aufgrund dem Fehlen einer Diskettenschnittstelle oder eines CD-ROM Laufwerkes mittels eines extra mit NetBSD formatierten und bootbaren USB-Stick auf die CompactFlash-Karte installiert habe. Während der Installation des Betriebssystem habe ich bewusst auf folgende Sets verzichtet: Als erstes die Spiele aus reinem Desinteresse. Zweitens dem Compiler, da ein angepasster Kernel aus Zeitgründen auf einem schnelleren 2,8 GHz PC erstellt wird und alle weiteren Programme lediglich direkt als Binärprogramm installiert werden. Und drittens dem kompletten X11 Sets, da dies System nicht als grafische Workstation dienen soll. Folgende weitere Programme wurden also darauf folgend zusätzlich installiert (welche zum Teil noch weitere Pakete in Abhängigkeit mit sich ziehen und auch installieren):

nload-0.7.0 = Netzwerkmonitoring für Traffic und Bandbreitenverbrauch
irssi-0.8.12nb1 = Sicherer und modularer IRC-Client auf Kommandozeilenbasis
screen-4.0.3nb2 = Multi-screen Windowmanager
wget-1.11.4 = Downloaden von Ressourcen über ein Netzwerk über HTTP oder FTP
w3m-0.5.2nb2 = Textbasierter Webbrowser
tor-0.2.0.31 = Netzwerk zur Anonymisierung der Verbindungsdaten über TCP

Mal sehen, was ich mir demnächst noch so für Dinge mit dem ALIX erschließe. Der miniPCI Slot lacht mich schon ein wenig nach einer WLAN-Karte an. Abwarten und mal schauen was die Zukunft bringt.

Veröffentlicht unter Alix