SMB Freigaben erstellen

Bevor ich mit um die Einrichtung von SMB Freigaben kümmern kann muss ich dafür sorgen das die nötigen Grundlagen dafür gegeben sind.

Als erstes installiere ich also die SMB Server kernel root components nach:

$ pkg install SUNWsmbskr
             Zu installierende Pakete:    1  
              Boot-Umgebung erstellen: Nein
Sicherung der Boot-Umgebung erstellen:   Ja
                Zu ändernde Services:    1

DOWNLOAD                                PAKETE     DATEIEN ÜBERTRAGUNG (MB)
Completed                                  1/1       29/29      0.5/0.5

PHASE                                       AKTIONEN
Installationsphase                             84/84

PHASE                                       ELEMENTE
Paketstatus-Updatephase                          1/1
Abbildstatus-Updatephase                         2/2

Installiert ist er damit schon mal. Damit nun am Ende die lokalen Benutzer mittels Benutzername / Kennwort zugriff auf die Freigaben haben muss noch folgende Zeile in die Datei /etc/pam.conf aufgenommen werden:

other password required pam_smb_passwd.so.1 nowarn

So nun nur noch den SMB-Server anwerfen:

$ svcadm enable -r smb/server

Jetzt schaue ich mal schnell nach ob er auch läuft (wenn er sinnlos hängen bleibt sucht man sonst so lange):

$ svcs smb/server
STATE          STIME    FMRI
online         20:11:41 svc:/network/smb/server:default

So gefällt es mir fast schon. Als nächstes hänge ich Kiste noch in die Workgroup meiner wahl:

smbadm join -w kernel-error.de
After joining kernel-error.de the smb service will be restarted automatically.
Would you like to continue? [no]: yes
Successfully joined kernel-error.de

Nun sollte alles bereit sein um SMB-Shares zu erstellen. Für meinen Test erstelle ich einen neues ZFS Dateisystem, welche ich später freigeben möchte:

$ zfs create rpool/windoof-freigabe
$ zfs list rpool/windoof-freigabe
NAME                    USED  AVAIL  REFER  MOUNTPOINT
rpool/windoof-freigabe   31K   190G    31K  /rpool/windoof-freigabe

Die eigentlich Freigabe erstellt sich nun fast von alleine:

$ zfs set sharesmb=on rpool/windoof-freigabe
$ zfs get sharesmb rpool/windoof-freigabe
NAME                    PROPERTY  VALUE     SOURCE
rpool/windoof-freigabe  sharesmb  on        local

Wooohooo….

Auf mehrfache Nachfrage hier noch etwas zu ZFS und CIFS-Shares >>klick<<

NFS Freigaben erstellen

Mal eben schnell einen NFS Share anlegen ist mit ZFS überhaupt kein Problem. Ich greife mir mal schnell meinen 8GB USB-Stick und stopfe ihn in den Rechner. Dann lege ich schnell einen ZFS Pool auf diesem an:

$ zpool create nfs-share c3t0d0p0
$ zpool list
NAME        SIZE  ALLOC   FREE    CAP  DEDUP  HEALTH  ALTROOT
nfs-share  7,44G    91K  7,44G     0%  1.00x  ONLINE  -
platte2     149G  37,5G   111G    25%  1.05x  ONLINE  -
rpool       464G  46,6G   417G    10%  1.00x  ONLINE

Zur besseren Übersicht lege ich hier nun ein weiteres Volume an und gebe das direkt per NFS „frei“:

$ zfs create nfs-share/freigabe01
$ zfs set sharenfs=on nfs-share/freigabe01
$ zfs get sharenfs nfs-share/freigabe01
NAME                  PROPERTY  VALUE     SOURCE
nfs-share/freigabe01  sharenfs  on        local

Einmal kontrollieren welche Exports es nun gibt:

$ zfs get sharenfs nfs-share/freigabe01
NAME                  PROPERTY  VALUE     SOURCE
nfs-share/freigabe01  sharenfs  on        local

Wunderbar…. Nun könnte man diesen Share schon mounten und nutzen. Ist nicht sonderlich schwer, oder? Natürlich kann man die gängigen NFS Optionen auf einen solchen Share anwenden, alle eine Sache der Optionen Ganz lustig ist nun folgendes…. Mache ich nun ein:

$ zpool export nfs-share

Ziehe dann den USB-Stick raus und gehe zu einem anderen Rechner. Dann kann ich diesen dort ja mit:

$ zpool import nfs-share

Wieder einbinden. Alle ZFS-Einstellungen bleiben ja erhalten. Somit auch der share. Ich habe damit also einen Tragbaren NFS share. Stopfe ich diesen in einen Rechner und importiere den ZFS Pool dann habe ich auch sofort wieder meinen nutzbaren NFS Share An so einem Punkt wird einem schnell klar welche Möglichkeiten einem ZFS damit bietet diese Konfigurationen mitwandern zu lassen. Mir fällt jetzt zwar gerade kein genaues Einsatzfeld für einen Tragbaren NFS Share auf einem USB-Stick ein, denn noch schön zu wissen das es geht

ZFS RAID

ZFS unterstützt natürlich „RAID“ ein einfacher Mirror ist genau so möglich wie eine Art Raid5 (raidz genannt) oder eine Art Raid6 (raidz2 genannt). Natürlich sind spare Platte kein Problem und Striping ist überhaupt kein Problem.

Ich habe ja bereits einen Pool mit dem Namen backup. Wenn ich aus diesem nun lieber einen Mirror über zwei Platten machen möchte geht das so:

$ zpool attach backup c2d1p0 c3d0p0
Make sure to wait until resilver is done before rebooting.

Wichtig ist hier die richtige Reihenfolge der Platten. Denn man Packt ja der Platte c2d1p0 im Pool backup die Platte c3d0p0 als Spiegel hinzu. Vertauscht man die Platten im Befehlt spiegelt ZFS die leere Platte auf die Datenplatte. Auch ein schöner Mirror, sogar genau wie angegeben aber so leer

Mal angenommen alles wurde richtig angegeben, dann beginnt ZFS nun den Pool zu resilvern. Da es bei ZFS keine Trennung mehr zwischen RAID / Volumemanager bzw. Dateisystem gibt, weiss ZFS genau wo Daten liegen und spiegelt nur diese. Sind nur ein paar GB belegt ist der sync das resilvering schnell durch. Andere Systeme würden hier nun stumpf Block für Block herüber schieben. Egal ob in diesem nun Daten liegen oder nicht. Woher soll dieses auch wissen was das Dateisystem macht? Daher kann es je nach Plattengröße sehr lange dauern.
// Schon mal versucht sechs 3TB Platten eines RAID6 per Linux mdadm nach einem Plattentausch im Betrieb zu resilvern? 10 Stunden sind da nichts, selbst wenn nur 1TB belegt ist… //

Zurück zum backup Pool. Um sich den Status des Pools anzuschauen gebe ich folgendes ein:

$ zpool status backup
pool: backup
state: ONLINE
status: One or more devices is currently being resilvered.  The pool will
continue to function, possibly in a degraded state.
action: Wait for the resilver to complete.
scan: resilver in progress since Mon Oct 31 13:18:13 2011
444M scanned out of 4,04G at 18,5M/s, 0h3m to go
440M resilvered, 10,72% done
config:

NAME        STATE     READ WRITE CKSUM
rpool       ONLINE       0     0     0
mirror-0  ONLINE       0     0     0
c2d1p0  ONLINE       0     0     0
c3d0p0  ONLINE       0     0     0  (resilvering)

errors: No known data errors

Ja das Testsystem ist LANGSAM ich habe alte Hardware genommen (sehr alte Hardware). Denn noch sieht man das ZFS nur die eigentlichen Daten resilverd. Hier also knapp 4,04GB. Würde es die ganzen 80GB resilvern hätte ich eine längere Kaffeepause! Nach getaner Arbeit schaut es nun so aus:

$ zpool status backup
pool: backup
state: ONLINE
scan: resilvered 4,04G in 0h5m with 0 errors on Mon Oct 31 13:33:00 2011
config:

NAME        STATE     READ WRITE CKSUM
rpool       ONLINE       0     0     0
mirror-0  ONLINE       0     0     0
c2d1p0  ONLINE       0     0     0
c3d0p0  ONLINE       0     0     0

errors: No known data errors

Ein 80GB Mirror in 5 Minuten resilvern und das auf kack Hardware… Schöne Zeit, oder?

Will ich direkt einen Pool als Mirror anlegen geht dieses natürlich mit:

$ zpool create backup mirror c2d1p0 c3d0p0
Make sure to wait until resilver is done before rebooting.

Sind meine Datenplatten gespiegelt ist dieses gut gegen Datenverlust. Fällt eine Systemplatte aus kommen die User denn noch nicht an ihre Daten. Daher macht es Sinn einen root pool zu mirrorn. Das ist nun etwas aufwändiger, vor allem da man ja grub nicht vergessen darf. Denn was bringt einem ein gespiegelter Root Pool, wenn man den ohne Bootmanager nicht booten kann? Ich habe da nun folgendes gemacht…

So schaut der rpool meines Testsystems aus:

$ zpool status rpool
pool: rpool
state: ONLINE
scan: none requested
config:

NAME        STATE     READ WRITE CKSUM
rpool       ONLINE       0     0     0
c2d0s0    ONLINE       0     0     0

errors: No known data errors

Diesen möchte ich nun auf die Platte c2d1s0 spiegeln. Dafür lege ich auf dieser zuerst ein Lable an:

$ format c2d1s0
selecting c2d1s0
NO Alt slice
No defect list found
[disk formatted, no defect list found]
 FORMAT MENU: disk       - select a disk type       - select (define) a disk type partition  - select (define) a partition table Total disk size is 9729 cylinders Cylinder size is 16065 (512 byte) blocks Cylinders Partition   Status    Type          Start   End   Length    % =========   ======    ============  =====   ===   ======   === 1       Active    Solaris2          1  9728    9728    100 SELECT ONE OF THE FOLLOWING: 1. Create a partition 2. Specify the active partition 3. Delete a partition 4. Change between Solaris and Solaris2 Partition IDs 5. Edit/View extended partitions 6. Exit (update disk configuration and exit) 7. Cancel (exit without updating disk configuration) Enter Selection: 6 format> quit 

Nun die Partitionseinstellungen der s2 von der Hauptplatte auf die zweite Platte übernehmen:

$ prtvtoc /dev/rdsk/c2d0s2 | fmthard -s - /dev/rdsk/c2d1s2
fmthard:  New volume table of contents now in place.

Dann die zweite Platte dem Pool als mirror hinzuzwingen:

$ zpool attach -f rpool c2d0s0 c2d1s0
Make sure to wait until resilver is done before rebooting.

Damit sollte der rootpool gespiegelt sein. Nun fehlt noch der Bootmanager grub auf der zweiten Platte.

$ installgrub /boot/grub/stage1 /boot/grub/stage2 /dev/rdsk/c2d1s0
stage2 written to partition 0, 275 sectors starting at 50 (abs 16115)
stage1 written to partition 0 sector 0 (abs 16065)

Fertig….

Jetzt reiße ich einfach mal die eigentliche Hauptplatte aus dem Testsystem und starte die Kiste neu. Nach ordentlichem Boot (muuaaahhhhrrrr) schaue ich mal den Status des Pools an:

$ zpool status
pool: rpool
state: DEGRADED
status: One or more devices could not be used because the label is missing or
invalid.  Sufficient replicas exist for the pool to continue
functioning in a degraded state.
action: Replace the device using 'zpool replace'.
see: http://www.sun.com/msg/ZFS-8000-4J
scan: scrub in progress since Mon Oct 31 13:47:29 2011
17,8M scanned out of 4,06G at 261K/s, 4h30m to go
0 repaired, 0,43% done
config:

NAME        STATE     READ WRITE CKSUM
rpool       DEGRADED     0     0     0
mirror-0  DEGRADED     0     0     0
c2d0s0  FAULTED      0     0     0  corrupted data
c2d1s0  ONLINE       0     0     0

errors: No known data errors

Passt und funktioniert also wie gewünscht. Weiter gehts!

ZFS compression und deduplication

Bei Kompression auf Dateisystemebene denken viele direkt an die Implementierung von Microsoft. Mit dem gleichen Gedanken kommt oft ein *UAARRGGGSSS*. Microsoft Kisten mit eingeschalteter Komprimierung sind alles nur nicht mehr performant, es lässt sich kaum Software auf so einer Platte betreiben und man hat schneller Dateisystemfehler als man meep sagen kann. Niemand will das wirklich einschalten! Bei ZFS ist das etwas anders. Natürlich benötigt das komprimieren Systemressourcen und Datenrettungen werden um einiges Aufwändiger…. Bei heutigen CPUs merkt man kaum etwas davon, dass die CPU nun noch den Stream zur Platte komprimieren muss. Diese Funktion bringen viele CPUs schon in Hardware mit. Die CPU ist hier selten das langsamste Gliet in der Kette. Da ist viel eher die Festplatte der Flaschenhals. Mit einer neueren CPU wird es mit eingeschalteter Komprimierung eher schneller als langsamer. Warum? Na, wenn weniger Daten von der Platte gelesen bzw. weniger Daten auf die Platte geschrieben werden müssen, bringt einem das nicht nur mehr Platz auf dem Datenträger sondern zusätzlich noch weniger IOs Kompression ist also gut, sofern man nicht gerade eine alte Celeron CPU verbaut hat. Zusätzlich werden nicht beim aktivieren stumpf alle Daten komprimiert. Nein, bei aktivierter Komprimierung werden nur die Daten komprimiert abgelegt, welche in diesem Moment geschrieben werden. Schaltet man die Komprimierung wieder ab werden die neuen Daten wieder unkomprimiert gespeichert.Natürlich kann weiterhin aus jedem Zustand auf alle Daten zugegriffen werden. Will man also mal eben viele Daten ablegen / zwischenspeichern könnte man nur dafür kurz die Komprimierung aktivieren.

Dedublication also dedublizierung ist noch so ein extrem cooles Spielzeug. Ist dieses aktiviert werden einmal gespeicherte Blöcke nicht noch einmal auf der Platte gespeichert. Es wird nur hinterlegt wo man die Daten findet. Hat man also auf dem Store virtuelle Maschinen liegen hat man schnell einige gleiche Blöcke. Das kann richtig Platz sparen. Ist der Store als Fileserver oder ähnliches in einem Unternehmen kann man ebenso Platz sparen. Arbeiten viele User an bzw. mit den gleichen Dingen, taucht ein und das gleiche Dokument an den verschiedensten Stellen auf. Egal ob man nun einen Sharepoint-Server oder ähnliches einsetzt oder das ganze nur an einem Ort liegen soll.User sind halt User. Versionierung in der Entwicklung… Hier wird oft mal eine Kopie des alten Baumes angelegt um eine neue Version zu starten.
// Da gibt es bei einem Kunden meines Arbeitgebers einen Administrator. Dieser betreut eine nicht ganz unwichtige Software. Vor jedem Update das er einspielt legt er immer eine Kopie des Programmordners an, jeweils 2 GB… Diese Kopien liegen dann gerne mal noch 2 – 3 weitere Updates herum. Selbst wenn bei einem solchen Update nur 4 – 5 ini Einträge und zwei 500kb exe Dateien getauscht werden. Mit aktivierter dedubplication verbraucht eine solche Kopie nicht mehr 2GB sondern nur noch die Menge der Änderungen 10 MB…. Also soll dieser beratungsresistente Admin seine Kopien machen! //

Als kleinen Test habe ich Openindiana auf zwei baugleichen Rechnern mit gleichen Einstellungen installiert. Einmal habe ich vor der Installation compression und deduplication aktiviert einmal nicht.

Sobald die Openindianainstallation den zfs Pool (default rpool) angelegt hat führte ich in einer Konsole der LiveDVD folgendes aus:

$ sudo -s
$ zfs set compression=on rpool && zfs set dedup=on rpool

Dann lies ich die Installation ganz normal durchlaufen und habe die Kiste nach der Installation neu gestartet. Direkt nach der Anmeldung des frischen Systems habe ich mir angeschaut was an Daten auf der Platte gelandet ist. Ach ja, die Installation mit compression und deduplication (deduplication konnte hier ja noch nicht richtig ausgespielt werden, belegt nur schon mal Platz im RAM :-P) hat ca. 30 Sekunden länger gedauert….

Als erstes lasse ich mir mal den Komprimierungsgrat ausgeben:

$ zfs get compressratio rpool
NAME   PROPERTY       VALUE  SOURCE
rpool  compressratio  1.52x  -

1.52…. Da müsste ich ja fast die Hälfte an Platz gespart haben! Mal schauen was die deduplication gemacht hat:

$ zpool get dedupratio rpool
NAME   PROPERTY    VALUE  SOURCE
rpool  dedupratio  1.01x  -

Wie zu erwarten nicht _SO_ viel. Es gibt bei der Installation halt kaum doppelte Daten. Denn noch  ist es ein ganz guter Test, denn mit aktivierter deduplication laufen die ganzen Routinen schon mal mit und man sieht wie schnell oder langsam es ist! Schauen wir mal was nun wirklich auf der Platte an Platz verbraucht wurde:

$ zpool list
NAME    SIZE  ALLOC   FREE    CAP  DEDUP  HEALTH  ALTROOT
rpool    74G  2,59G  71,4G     3%  1.01x  ONLINE  -

2,59GB für die Grundinstallation mit aktivierter compression und deduplication. Mal schauen was ohne diese beiden Funktionen auf der Platte landet:

$ zpool list
NAME    SIZE  ALLOC   FREE    CAP  DEDUP  HEALTH  ALTROOT
rpool    74G  3,93G  70,1G     5%  1.00x  ONLINE  -

Joar das kann sich sehen lassen, oder? Mit entsprechend viel RAM holt man bei eingeschalteter deduplication natürlich eher mehr als weniger Leistung aus deinem Store. Denn jeder Block der nicht geschrieben werden muss lässt der Platte Luft einen anderen Block zu schreiben

Noch etwas zu ZFS compression. Man sollte natürlich darüber nachdenken für welches Volume man die Komprimieren nun einschaltet und für welches nicht. Denn ein Volume auf welchem bereits komprimierte Daten wie Videos, Bilder oder ähnliches abgelegt werden, da wird zfs compression nichts bringen. Es macht es maximal langsamer! Bei Logfiles sieht es natürlich anders aus.
Jetzt lassen sich die Optionen der Komprimierung aber noch etwas genauer anpassen. Mit einem einfachen: zfs set compression=on zfs Datenset greifen die standard Einstellungen. Zur Komprimierung wird gzip verwendet und zwar mit dem compression level 6. Möchte man nun einen höheren Komprimierungslevel haben, zum Beispiel das Maximum 9. Setzt man es wie folgt:

$ zfs set compression=gzip-9 home/kernel/textdokumente
$ zfs get compression home/kernel/textdokumente
NAME PROPERTY VALUE SOURCE
home/kernel/textdokumente compression gzip-9 local

Ebenso lässt sich auf einen anderen Algorithmus wechseln:

$ zfs set compression=zle home/kernel/textdokumente
$ zfs get compression home/kernel/textdokumente
NAME PROPERTY VALUE SOURCE
home/kernel/textdokumente compression zle local

Umso stärker die Komprimierung umso mehr CPU Zeit geht für die Berechnung drauf. Ob es jetzt beim default level 6 bleibt oder man auf 9 wechselt, dieses hat in meiner Praxis kaum einen Unterschied gemacht. Als Algorithmus zle zu nutzen macht die Sache etwas schneller, verschlechtert den Komprimierungsgrad aber deutlich. Dieses kann ich mit einem gzip-1 fast ebenfalls erreichen! Was man sich vielleicht noch einmal genauer anschauen sollte ist lzjb oder LZ4….

Es bleibt daher, wie so oft, zu bewerten was wohl in der aktuellen Situation das Beste ist!

….und noch was zu ZFS Deduplication!
Hier bitte ebenfalls darüber nachdenken ob und für welches Volume es sinnvoll ist. Deduplication sorgt zwar für Platz und Ruhe auf den Platten. Verbrennt dafür RAM und CPU Zeit!
Im Standard sorgt folgendes:

$ zfs set dedup=on home/kernel/vorlagen
$ zfs get dedup home/kernel/vorlagen
NAME PROPERTY VALUE SOURCE
home/kernel/vorlagen dedup on local

..dafür dass bei jedem zu schreibenden Block eine sha256 Checksumme erstellt wird und wenn die gleich ist mit einem bereits geschriebenen Block wird er nicht geschrieben, sondern es gibt nur eine Art Verweiß auf den bereits geschriebenen. Dieses bedeutet nun aber dass es bei einem von 2\^-256 Blöcken zu einer gleichen Checksumme kommen kann auch wenn die Daten unterschiedlich sind. Wer hier eine höhere Sicherheit haben möchte kann mit einem:

$ zfs set dedup=sha256,verify home/kernel/vorlagen
$ zfs get dedup home/kernel/vorlagen
NAME PROPERTY VALUE SOURCE
home/kernel/vorlagen dedup sha256,verify local

..dafür sorgen, dass bei einer gleichen Checksumme ein Byte-für-Byte Vergleich der Daten gemacht wird. Damit kommt man dann auch diesem Fall auf die Schliche! Ebenso lassen sich hier wieder andere Algorithmen als sha256 einsetzten. fletcher2 oder fletcher4… Gefühlt bringt hier flechter4 zusammen mit verify etwas mehr Performance. Ich bleibe derzeit denn noch lieber bei sha256!

B.t.w.: fletcher4 habe ich unter BSD und Linux Implementierungen schon ein paar mal vermisst. Ob ich hier nur auf eine „alte“ ZFS Version reingefallen bin?

Erstellen eines ZFS Pools und Dateisystem

Das erstellen eines neuen Pools ist schnell und sehr einfach erledigt. Im Grunde muss man sich zur Administration von ZFS zwei Befehle merken. zpool wenn etwas mit dem Pool passieren soll und zfs wenn etwas mit dem Volume „Dateisystem“ passieren soll.

Folgender Befehl legt nun den neuen Pool backup an, c2d1p0 ist dabei das verwendete Device, sprich Festplatte. Man könnte hier auch ein File angeben!

$ zpool create backup c2d1p0

ZFS denkt sich bei dem c2d1p0 schon das wir eine Festplatte meinen und ergänzt selbständig /dev/rdsk… ZFS denkt sich zudem das wir wohl Daten im Pool speichern wollen und legt im Pool direkt ein gleichnamiges Volume an. Um dort Daten speichern zu können muss es natürlich gemountet werden. Dieses ist ZFS klar und deswegen hängt es alles gleich unter dem root „/“ ein. Selbstverständlich lassen sich alle diese Dinge (und viele mehr) per Option beim anlegen steuern.

Nun schauen wir uns mal an was ZFS gemacht hat:

$ zpool list backup
NAME     SIZE  ALLOC   FREE    CAP  DEDUP  HEALTH  ALTROOT
backup  74,5G   132K  74,5G     0%  1.00x  ONLINE  -

Schaut gut aus, wir könnten jetzt sofort Daten dort speichern…. Mal angenommen der Pool backup wäre nun auf einer USB-Wechselfestplatte oder einem USB-Stick. Dann könnte man diesen „aushängen“ mit:

$ zpool export backup

An jedem anderen System ließe er sich wieder einbinden mit:

$ zpool import backup

Dieses funktioniert natürlich mit jedem anderen Pool genau so!

Der OpenSolaris fork Openindiana und die feste IP-Adresse (static IP-Adress)

Solaris war auf den ersten Blick noch nie so richtig einfach in Sachen IP-Adressen. Auf den zweiten Blick finde ich es aber logischer als bei allen anderen! Wie auch immer, die Meinungen gehen hier wohl auseinander.

Ab OpenSolaris dem SolarisExpress 11 also grob dem aktellen Solaris 11 hat sich etwas hinsichtlich des Netzwerkes geändert. Openindiana ist nun daraus hervorgegangen also muss man dieses hier auch beachten

So wie der Befehl ifconfig unter Linux von ip abgelöst wird, sieht es wohl unter Solaris mit ipadm aus!

Ich mache es einfach mal ganz kurz und schmerzlos:

Als erstes muss nwam (Network Auto-Magic) deaktiviert werden:

$ svcadm disable svc:/network/physical:nwam
$ svcadm enable svc:/network/physical:default

Dann listen wir uns mal kurz alle Netzwerkinterfaces auf:

$ ipadm show-if -o all
IFNAME     CLASS    STATE    ACTIVE CURRENT       PERSISTENT OVER
lo0        loopback ok       yes    -m46-v------  46--       --
net0       ip       ok       yes    bm46--------  ----       --

Schon können wir die feste IP 192.168.1.10 mit der Netmask 255.255.255.0 dem Interface net0 zuteilen:

$ ipadm create-addr -T static -a 192.168.1.10/24 net0/v4

Damit unsere IP-Pakete später den Weg ins „Internet“ finden benötigen wir noch die Defaultroute zum Router:

$ route -p add default 192.168.1.254

Jetzt noch schnell den System mitteilen wie es mit DNS Auflösungen umzugehen hat:

$ cp /etc/nsswitch.dns /etc/nsswitch.conf

Fehlen nur noch die zu fragenden Nameserver:

$ echo "nameserver 192.168.1.254" > /etc/resolve.conf
$ echo "nameserver 8.8.8.8" >> /etc/resolve.conf

Achtung, 8.8.8.8 ist google. Aber wem schreibe ich dieses und wer macht schon ungeprüftes Copy & Past?

Damit hat unsere Kiste also nun die IP Adresse: 192.168.1.10/24 fragt erst den DNS Server 192.168.1.254 und dann den DNS Server 8.8.8.8. Den Weg aus seinem eigenen Subnetz findet die Kiste über den Router 192.168.1.254

Noch Fragen?