Archiv der Kategorie: Familie

Rund um uns 5

Cubian auf Cubietruck SD 2

Inzwischen sind weitere Anpassungen am „Glotzenrechner“ vorgenommen worden, die ich hier kurz dokumentieren will:

WLAN

Der Netzwerkmanager fand meine WLAN Netze zuerst nicht. Ursache war ein fehlendes Modul. Nach einem

auto wlan0

Eintrag in die /etc/network/interfaces und einem

sudo modprobe bcmdhd

ging es.

Das Modul bcmdhd kann aus einer Zeile in der /etc/modules beim Boot aufgerufen werden, dann spart man sich den händischen Aufruf nach einem Neustart.

Tastatur und Tasten

Ein Nachtrag noch zu den Keyboardhinweisen im ersten Teil: Anpassungen an den Tastenkürzeln und Shortcuts können vorgenommen werden in

~/.config/openbox/lxde-rc.xml

DIe XML Datei ist selbsterklärend. Dass ein STRG ALT t ein Terminal öffnet, kann z.B. mit dem folgenden Eintrag im Abschnitt <keyboard></keyboard> erledigt werden:

<keybind key=“A-C-t“>
<action name=“Execute“>
<execute>/usr/bin/lxterminal</execute>
</action>
</keybind>

Ein

openbox –reconfigure

schaltet die Einstellungen dann scharf. Bevor ich hierauf kam, blieben alle Eintragungen auch nach einem Reboot schlicht unwirksam.

Sollte man sich über die eigenen Tastenbelegungen nicht ganz sicher sein, dann helfen xev und diese Seite im Debian Wiki.

ownCloud

Fedora 20 bringt einen für ARM kompilierten owncloud-client (mirall) mit. Der fehlt für Debian und kann auch – aus meiner heutigen Sicht – nicht so leicht erstellt werden, weil das Paket qtkeychain ebenfalls nicht für Debian ARM vorliegt. Wirft man den Compiler an, dann spaziert man in die Abhängigkeitshölle. Man kann jedoch auf die Anbindung des eigenen ownCloud-Servers über WebDAVs ausweichen.

mkdir ownCloud

sudo apt-get install davfs

sudo dpkg-reconfigure davfs2

Hier den normalen Benutzern erlauben davfs2 zu verwenden.

sudo usermod -aG davfs2 cubie

sudo mount.davfs https://www.server.domain/owncloud/remote.php/webdav /home/cubie/ownCloud/

Derartige Eintragungen können in der fstab hinterlegt werden … oder man schreibt sich einen mount und umount alias in die .bash_aliases sofern der Rechner – wie hier – von vielen Familienmitgliedern verwendet wird. [Lektüre]

Samba

Unseren Sambaserver habe ich gleich über die /etc/fstab gemountet. Benötigt werden die cifs-utils:

sudo apt-get install cifs-utils

Das Tauschverzeichnis ist auch der Dokumentenpfad für alle lokal installierten Programme, was nicht nur Speicher auf der SD Karte spart, sondern den Zugriff von sonstigen Arbeitsstationen im Haus erleichert.

//ip.des.smb.servers/pfad/zu/tausch /home/cubie/fileserver cifs auto,username=tausch,password=geheim,uid=1000,gid=1001 0 0

Geheime Passwörter sollte man nicht direkt in der fstab hinterlegen – aber die für den Familienserver sind intern eh bekannt. [Lektüre]

Sonstiges

Bei mir fehlte die Möglichkeit zur Vervollständigung der Befehle durch TAB. EIn

sudo apt-get install bash-completion

installiert die fehlende Funktion nach.

Alle anderen inzwischen vorgenommenen Veränderungen sind weniger technischer Natur und dienten vor allem der „Verschönerung“ des Systems.

Einen Tipp evtl. noch: dwb ist ein empfehlenswerter schlanker, schneller Browser für Cubian-Benutzer, die auf der Shell mit vi arbeiten oder unter Firefox den vimperator installiert haben: http://portix.bitbucket.org/dwb/

OT: Auf neueren Ubuntuversionen – ab Quantal – ist dwb ebenfalls zu finden.

Cubian auf Cubietruck SD 1

Statt weiter mit der F20 Installation auf dem Cubietruck zu spielen, kam gestern Abend das neueste Cubian – ein Debian Abkömmling – auf eine 16GB microSDHC Karte von SanDisk (SDSDQX-016G-U46A). Die für den Betrieb des Logitech K400 nötigen USB HID Treiber sind schon mit an Bord und auch die Größenanpassung des Dateisystems nach der „Installation“ auf die Karte läuft automatisch ab.

Die folgenden Anpassungen halfen dann dabei, das System benutzbar zu machen:

dpkg-reconfigure keyboard-configuration

dpkg-reconfigure locales

dpkg-reconfigure tzdata

Das Keyboard Layout systemweit setzen:

sudo vi /etc/xdg/lxsession/LXDE/autostart

Hier den folgenden Eintrag am Ende hinzufügen:

setxkbmap -layout de

Dann die folgenden Pakete installieren:

sudo apt-get install libreoffice-l10n-de libreoffice-grammarcheck-de vlc pavucontrol smplayer pulseaudio keepassx mtpaint iceweasel oxygen-icon-theme vim gvfs-backends abiword aspell-de cifs-utils cups-pdf task-lxde-desktop libreoffice-help-de gigolo

Von box-loog.org noch ein hübsches Theme installieren … und man hat auf dem Cubietruck ein System, auf dem sich ohne große Wartezeiten LibreOffice und Iceweasel inklusive der für mich wichtigen Add-Ons benutzen lassen.

Auch die Tonausgabe über HDMI funktioniert – allerdings im Moment nur mit dem smplayer.

Cubietruck und Fedora 20 LXDE

Der Cubietruck ist nun richtig angekommen. Das Fedora 20 LXDE Image gepaart mit einer Logitech K400 als Tastatur erlaubt die Bedienung aus dem Sessel heraus.

Unser heimischer Fileserver wird mit Gigolo über SSH eingebunden – das war einfacher, als allen Familienmitgliedern zu erklären, wie man auf der Shell einen CIFS Mount macht. Beim Browsen neige ich zu Qupzilla, der relativ schnell startet und die meisten Webseiten auch gut darstellt. Firefox ist zwar auch eine Option, aber man muss sich auf längere Wartezeiten einstellen. Als Videoplayer ist hier whaawmp mit verschiedenen gstreamer Plugins an Bord. Das mag wenig elegant sein, dafür frisst er kaum Ressourcen. Leider scheint es keinen vorkompilierten VLC für Fedora ARM zu geben – sonst hätte ich das gerne ausprobiert. Zum Schluss: Einen ownCloud client habe ich ebenfalls installiert. Der holt sich die mit dem Tablet gemachten Photos automatisch und diese können dann auf dem TV betrachtet werden. Soweit ist demnach alles rund – selbst Abiword ist benutzbar.

Einziges Manko ist der network-manager, der in der Gnome Version vorinstalliert bei dem F20 Image mit dabei ist. Dieser holt sich zwar eine IP von unserem IPFire, aber dann klemmt es. Ohne ein sudo dhclient „kommt diese nicht bis zum Desktop“ – soll heißen: Trotz im network-manager angezeigter IP läuft das Netz nicht wirklich. Ich vermute, dass kein dhclient Prozess gestartet wird – aber da muss ich noch forschen … Was auch noch fehlt ist sound über HDMI. Das geht wohl nur über die analogen Ausgänge, habe ich aber noch nicht getestet. Bastelarbeit bleibt demnach genug. Und auch der Umzug des F20 Images vom NAND auf eine schnelle SD Karte steht noch an.

Katzenbefreiung

Unsere zwei Katzenkinder durften heute zum ersten Mal an die frische Luft – leider noch mit Halsband ausgestattet, falls sie hektisch davon laufen und sich finden lassen müssen. Die Katzenmama besteht darauf.

Carlson zeigte sich sehr vorsichtig und ging systematisch vor: Immer wieder die gleichen Wege laufen und von mal zu mal den Radius leicht erweitern, dann den Rückzug ins Wohnzimmer alle paar Minuten testen. Frieda nutzte die hektischere Variante: Geduckt bis zu Carlson huschen, dann vor irgendwas erschrecken und panisch wieder zurück ins Wohnzimmer rennen.

Mal sehen, wie lange es die beiden hier durchhalten. Irgend ein Nachbar frisst hier unsere Katzen. Im Schnitt sind unsere Miezen nach 2 Jahren spurlos verschwunden.

Senfnebel

Gestern war die Alb in Hochnebel gehüllt, der zusammen mit dem Raureif die Landschaft in einen zarten Senfton tauchte.

Kurz hinter Melchingen in süd-süd-westliche Richtung aufgenommen – aber leider als Bild nicht so beeindruckend wie in der Realität.

VirtualBox NAT Port-Weiterleitung

Wird die nach „Außen“ zeigende Schnittstelle einer VM über VBox NAT geleitet, erscheint diese nicht selbst im Netz, sondern nur der Host. Will man von Außen durch das VBox NAT zurück auf die Gast-Maschine, muss VBox die Weiterleitung der Pakete übernehmen.

Sollte aus Sicherheitsgründen die VM aus einem normalen Benutzeraccount heraus gestartet worden sein, dann weigert sich VBox jedoch, die Ports 1-1024 als Weiterleitungen einzurichten. Diese Ports gehören root. Man kann sich aber wie hier für Port 443 beschrieben helfen und damit auch Webserver-VMs (Port 80 und 443) mit ihrer öffentlichen / roten / nach Außen zeigenden Schnittstelle am VBox NAT betreiben.

Auf dem Router wird eine Weiterleitung auf den Host eingerichtet:

Port 443 wird schlicht auf Port 4433 auf dem Host weitergeleitet. Mit Port 80 ginge das genau so. Den könnte man z.B. auf Port 8080 weiterleiten.

Welche Ports man als Weiterleitungsziel wählt ist wie beschrieben egal – Hauptsache diese liegen im Bereich zwischen 1025 und 65536.

In der VM und dort am ge-nat-etten Adapter klickt man auf „Port-Weiterleitung“.

Der Host-Port ist dann der auf dem Router eingestellte Port über 1024 (hier: 4433), der lokale Port ist wieder 443.

Den Apachen muss man also nicht umbiegen. Host-IP und Gast-IP kann man freilassen – die Zuordnung übernimmt dann VBox.

Sollte man die Webserver-VM im orangenen Netz der Firewall liegen haben, dann sind die entsprechenden Regeln auf dieser anzulegen – siehe Netzwerksetup für Homeserver NXT.

Netzwerksetup für Homeserver NXT

Die ID88 bringt wie bereits geschildert zwei Netzwerkschnittstellen mit, die dann an die virtuellen Maschinen durchgereicht werden müssen. Damit dies reibungslos funktioniert und auch die Zusammenarbeit mit dem Router (hier: Fritzbox) klappt, kann man wie folgt vorgehen, um sich eine virtualisierte Firewall zu installieren:

In der Fritzbox wird der DHCP abgeschaltet. Die IP für den Host / den Homeserver wird auf dessen nach Außen / zum Router zeigendem / rotem Interface händisch vergeben. In meinem Fall wäre das eth1 auf dem Host.

Der Router hat die IP 192.168.2.1 und nutzt eine Netzmaske 255.255.255.0
Das vom Host zum Router zeigende Interface erhält im folgenden Beispiel die IP 192.168.2.200

Auf dem nach Innen / zum Heimnetz zeigenden / grünen Interface des Hosts / Homeservers (in meinem Fall eth0) benötigt man eine Bridge, damit alle virtuellen Maschinen im internen Netz mit ihren eigenen MACs (und damit später auch ihren eigenen IP-Adressen) auftauchen können. Hier ist die IP der Bridge auf dem Host nicht mehr als die IP eines Switches – die IP Adresse des Gastes wird im Gast selbst festgelegt.

Nach Innen erhält der Host die IP 10.16.1.100 (eingestellt auf dessen Bridge br0 und nicht auf eth0. Eth0 auf dem Host bleibt komplett unkonfiguriert)
Das Heimnetz selbst ist ein 10.16er Netz mit Netzmaske 255.255.0.0 oder 10.16.0.0/16 (damit bekomme ich genug Freiraum für die nächsten Jahre und kann außerdem dafür sorgen, dass Geräte, die ich zwischen Schule und zu Hause hin und her trage immer die gleiche IP haben)

Sollte Ubuntu als Host-Betriebssystem zum Einsatz kommen, dann greift man zur Server-Ausgabe. Diese bringt keinen network-manager mit, der einem beim Setup dazwischen schießen würde. Setzt man eine Desktop-Version ein, dann muss der network-manager zuerst entfernt werden. Das Setup funktioniert nur, wenn man die Interfaces selbst konfigurieren kann.

Zusammengefasst: Auf dem Host steht in /etc/network/interfaces:

# Das Interface in Richtung Router
auto eth1
iface eth1 inet static
address 192.168.2.200
netmask 255.255.255.0
network 192.168.2.0
broadcast 192.168.2.255
gateway 192.168.2.1
dns-nameservers 213.73.91.35 192.168.2.1 85.214.20.141

# Das Interface in Richtung Heimnetz
auto br0
iface br0 inet static
address 10.16.1.100
netmask 255.255.0.0
bridge_ports eth0
bridge_fd 5
bridge_stp no

Eth0 auf dem Host bleibt – wie oben schon geschildert – unkonfiguriert. Der Host ist dann aus dem Heimnetz unter der IP der Bridge direkt zu erreichen und lässt sich so leicht warten.

Eth1 auf dem Host habe ich nicht nur mit dem Nameserver auf dem Router, sondern zusätzlich noch mit den DNS des CCC und Foebud versorgt. Man weiß ja nie.

Nun legt man sich die erste Virtuelle Maschine (hier unter VirtualBox, das unter einem normalen Benutzeraccount läuft) mit zwei Netzwerkkarten an.

Das „zum Router“ zeigende Interface der VM wird als NAT angelegt.

Damit ich die Netzwerkkarten später in der VM wieder finde, schreibe ich deren MAC Adressen immer so um, dass „rot“ eine 1 (für eth1 des Hosts) am Ende hat – und „grün“ eine 0 (für eth0 des Hosts).

Das „nach Innen“ ins Heimnetz zeigende Interface der VM wird an die Bridge br0 des Hosts angeschlossen.

Ist der erste Host (hier IPFire als Firewall) gestartet, richtet man dessen Interfaces ebenfalls händisch her. Das nach Außen zeigende, rote Interface erhält vom DHCP auf dem NAT der VirtualBox irgendeine 10er Adresse. Welche, ist relativ egal. Später eingerichtete Portweiterleitungen übernimmt VirtualBox. Wichtig sind die Angaben für das interne, grüne Interface (also das, das an der Bridge des Hosts hängt). Hier muss die /etc/network/interfaces des Gastes angepasst werden (im Falle von IPFire über dessen Weboberfläche).

# Das rote Interface zeigt in Richtung Router und haengt am VBox NAT
auto eth0
iface eth0 inet dhcp

# Das gruene Interface zeigt in Richtung Heimnetz und haengt an der Bridge des Hosts
auto eth1
iface eth1 inet static
address 10.16.1.1
netmask 255.255.0.0

Die erste VM ist aus dem Heimnetz dann unter 10.16.1.1 zu erreichen.

So lange auf dem IPFire noch kein DHCP Server auf grün läuft, muss man sich auf einem Client eine 10.16.er Adresse händisch selbst zuweisen, damit man an die Weboberfläche kommt.

Die Installation weiterer VMs hängt direkt vom Sicherheitsbedürfnis ab. Zwei Wege sind möglich: einer führt über virtuelle Netzwerkkarten an der Firewall-VM (blau und orange), der andere richtet VMs „neben“ der Firewall ein.

Wählt man die sicherere Variante (weitere Netzwerkkarten in der Firewall-VM), richtet man diese NICs in VirtualBox als „Internes Netzwerk“ ein. Die VMs hängen dann mit ihrem roten Interface direkt an der Firewall und ebenfalls im VM-internen-Netzwerk. Das wäre z.B. ein Weg, um ein orangenes Netz einzurichten (siehe Bild oben für die Netzwerkkarte eines Webservers im orangen Netz von IPFire).

Aside: Ein blaues Netz ist nicht so einfach zu haben, weil WLAN Karten auf dem Host nicht als solche in VMs hinein gereicht werden können. Man kann sich hier aber mit USB-WLAN-Sticks helfen, die an die VM gebunden und aus dieser heraus konfiguriert werden.

Wählt man die unsicherere Variante, richtet man weitere VMs „neben“ der Firewall ein. Das Setup entspricht hierbei jeweils der Einrichtung der ersten VM: Eth1 des Gastes mit VBox-NAT zeigt nach Außen. Die nach Innen zeigende Schnittstelle des Gastes (eth0) wird im Gast händisch mit einer IP versorgt und klebt an der Bridge br0 auf dem Host.

Fällt ein derartiger Gast in fremde Hände, steht dem Angreifer das komplette interne Netz offen. Die Firewall ist hier reduziert auf ihre Webfilter-/DHCP-Funktionen für das interne Netz. Schutz von Außen bietet sie so nur bedingt. Man sollte aber wegen einer derartigen Konstruktion nicht gleich in Panik ausbrechen. Ge-nat-ete VMs dürften von Außen schwer zu knacken sein. Bei Portweilterleitungen vom Router auf eine solche VM macht man jedoch ein Türchen für Angriffe auf und muss eine derartige VM (eine Brücke zwischen Internet und Heimnetz) dann noch einmal gesondert absichern (iptables, fail2ban, tripwire etc. pp.). Oder man spart sich das interne Interface gleich komplett.

Hier vermehren sich die VMs fast täglich: Die Firewall war zuerst da, dann kam ein Fileserver, dann ein Nameserver, ein Webserver, ein Gameserver … 10er Netze und viel RAM auf dem Host lassen viel Raum für Spinnereien 🙂

Latitude E6410 Keyboardchaos

Janis bekommt zu Weihnachten einen seiner dickeren Wünsche erfüllt und erhält unter Selbstbeteiligung plus Beteiligung der Großeltern sowie unter Verzicht auf Geburtstagsgeschenke einen „neuen“ Laptop. Das bei Lapstore bestellte Gerät hat Vattern mit 8GB RAM und einer SSD konfiguriert, damit die nächsten paar Jahre Ruhe im Karton ist. Flott ist die Büchse – Hut ab.

Allerdings erhielt ich eine Konfiguration, bei der die linke Hälfte der Tastatur (QWERTZ) deutsch und die rechte Hälfte US war. So lange man weiß, wo Umlaute zu finden sind fällt einem das nicht weiter auf. Ich installierte fröhlich vor mich hin und erst als ich zum ersten Mal eine Umleitung und eine Pipe brauchte blickte ich auf die Tasten …

Größer-/Kleinertasten sowie Pipe gibt es nicht, wenn man ein US Keyboard auf deutsch betreibt, da darf man umschalten. Nicht weiter schlimm, aber nervig, wenn man das Umschalten des Layouts beim Wechsel auf eine Shell verschnarcht und dann erst wieder verstehen muss, was eigentlich los ist.

Also hab ich die Jungs von Laptstore angeschrieben und umgehend eine andere Tastatur zugeschickt bekommen. Mit Hilfe von Youtube war dann klar: Der Tastaturenwechsel ist kein Problem.

https://www.youtube.com/watch?v=m25N1eZj1FQ

Früher gab es Handbücher.

Zentyal bare metal

Im Kontext des Projektes Homeserver NXT verfolgte ich zuerst eine monolithische (in Nachhinein: blöde) Denke. Firewall, Fileserver und Nameserver integriert Zentyal. Zentyal basiert auf Ubuntu – also wäre da auch der Gameserver integrierbar gewesen. Dazu: eine hübsche, moderne Weboberfläche zur Administration vom Sofa aus. Das wollte ich mir zumindest mal ansehen.

Der erste Versuch, Zentyal direkt auf die Zotac ID88 zu bekommen, klemmte schon am Kernel des Installers, der nicht erkennen wollte, dass ich von USB installierte und nicht von CD. Die Meldung war, wenn ich mich richtig erinnere

Your installation CD-couldn’t be mounted. This probably means that the CD-ROM was not in the drive. If so you can insert it and try again.

Retry mounting the CD-ROM?

Dieser Fehlermeldung kann man abhelfen, wenn man die zentyal.iso mit auf den Stick kopiert, von dem aus man installieren will.

Taucht dann die Fehlermeldung auf, wechselt man mit Alt F2 auf eine Shell, aktiviert diese mit Enter und erstellt sich zuerst ein Verzeichnis, in das man den USB Stick mounten kann:

mkdir /media/stick

mount -t vfat /dev/sdb /media/stick

Dann erstellt man sich ein Loop Device und wirft über dieses dem Ubuntu/Zentyal Installer die gewünschte CD-Rom zum Fraß vor:

mount -t iso9660 -o loop /media/stick/zentyal.iso /cdrom

Mit Alt F1 kommt man zurück zum Installer und kann diesem nun vergaukeln, alles wäre OK.

Zentyal kommt so zwar auf die ID88 – aber das hilft nicht viel, weil die Chips des NICs zu neu sind.

Welcher Idiot kauft auch Hardware mit Realtek Chips?

Sofern man unbedingt die alte Ubuntu 12.04 LTS / Zentyal Distri auf der ID88 haben muss, dann darf man ab hier die Realtek NICs umschiffen, bis ein neuerer Kernel und Treiber an Bord sind. Der einfachste Weg ist, sich die WLAN Karte der ID88 (Intel) zu konfigurieren und über diese dann weiter zu arbeiten. Wie das geht wird hier beschrieben (man kann sich bei den nötigen Schritten auch mit einem lokalen Repo auf USB Stick helfen) – aber ich hatte da schon eingesehen, dass die Idee, Zentyal direkt auf das Metall zu werfen, zu unflexibel ist.

Also kam ein aktueller Ubuntu 13.10 Server (der sich reibungslos vom USB Stick installieren lässt) an Bord, VirtualBox dazu und Zentyal in eine VM. Aber das ist wiederum im nächsten Post beschrieben …

Homeserver NXT

Bin grad kaum zum Bloggen gekommen, weil mein Kopf voll war mit Heimnetzkram. Da ist aber nun der Knoten geplatzt und in den nächsten Posts schildere ich dann Schritt für Schritt, wie ich dieses aufgesetzt habe.

Angefangen hatte alles damit, dass meine Smoothwall auf ihrem P III langsam zu lahm wurde. Je älter die Kinder desto mehr Geräte im Haus und desto heftiger die Belastung auch für die Firewall. Außerdem wollte ich ausmisten. In den letzten Jahren hatte sich eine solch große Zahl an Computern bei mir im Arbeitszimmer versammelt, dass auf dem Fußboden schon kein Platz mehr war.

Jedes Stück Hardware hatte einen Platz im Hinterkopf, irgendein Projekt, das ich unbedingt mal machen wollte … aber die Zeit war nie da. Am Ende standen da 8 ungenutzte Rechner der Pentium IV Klasse rum, dazu Tastaturen, Mäuse, Bildschirme, weitere Netzwerk- und Grafikkarten … Nerdbastelkram eben. Nichts, was man heute noch wirklich haben will und auch nichts, was ich als Firewall nutzen wollte, weil selbst der Sparsamste von diesen Kisten (ein FSC mit Siemens-Mainboard) noch 90 Watt die Stunde beim Nixtun verbriet.

Energiesparend und vor allem auch möglichst klein sollte die neue Lösung sein.

Zuerst dachte ich an einen Nachbau des in der c’t beschriebenen 11-Watt-Servers, konnte aber das Netzteil nicht auftreiben. Auf der Suche nach einem Standort für diesen Rechner in meinem Arbeitszimmer fiel mir auf, dass diese Kiste schon wieder in Midi-Tower-Größe anrücken würde. Möglichst klein wäre das auch nicht.

Ein Raspberry Pi dann also? Dem traute ich nicht zu, als Firewall ausreichend zügig zu arbeiten. Außerdem trieb mich die Idee um, doch noch andere Dienste zu betreiben. Die Projekteideen – einst für die P4 Hardware vorgesehen – ploppten immer wieder aus dem Hinterkopf wieder ins Bewusstsein und verhinderte eine schnelle Entscheidung zwischen Mini und Midi …

Ein permanent laufenden Fileserver als Backup-Rechner und Tauschordner, ein eigener Nameserver als Ergänzung zur Firewall für eine noch bessere Kontrolle der Webzugriffe und noch weniger Schnüffelei von Außen … und für uns Jungs und Freunde noch ein dezidierter Gameserver für Minecraft, OpenArena und World of Padman.

Am Ende und nach viel Hin und Her wurde es nun ein Zotac ID 88 mit Core i3-3220T CPU mit 16 GB Ram und einer WD NAS Festplatte mit 1 TB. Der schluckt Idle 18 Watt und unter Last bisher nicht mehr als 23 Watt, was ein wenig unter dem Verbrauch der alten Firewall liegt. Dem Basteltrieb ist damit eine physikalische Grenze gesetzt: Erweiterungen sind unmöglich, das Kästchen ist voll.

Installiert sind inzwischen IPFire als Firewall, ein Fileserver unter Samba und ein Nameserver mit Bind. Der Gameserver muss bis zu den Ferien warten.

Unter dem Tag homeserver nxt geht es dann bald weiter mit Hinweisen zur Einrichtung und meinen Erfahrungen …

/localhost

127.0.0.1