IT security, FreeBSD, Linux, mail server hardening, post-quantum crypto, DNS, retro computing & hands-on hardware hacks. Privater Tech-Blog seit 2003.

Schlagwort: Sysadmin (Seite 9 von 12)

RSS-Feed Reader für Openindiana / Solaris 11

Veraltet: OpenIndiana und Solaris werden kaum noch als Desktop eingesetzt. Unter Linux gibt es zahlreiche RSS-Reader (Thunderbird, Liferea, Newsboat).

Ich habe gerade meinen lieblings RSS-Feed Reader Liferea auf der Solariskiste kompiliert. Ich finde es gibt einfach keinen besseren! Spannenderweise konnte ich auch keinen „fertigen“ finden. Na bis auf Thunderbird…. Aber Thunderbird? So gefällt es mir besser *hüpf*.

Liferea auf Solaris 11 Opensolaris

Solaris 11 und OpenIndiana: gMTP für die Dateiübertragung einrichten

Mein Creative ZEN Mozaic lässt sich nur per MTP mit Daten befüllen. Unter Windows kein Problem, unter Linux bringen die meisten Distributionen FUSE-Treiber mit. Solaris und OpenIndiana bringen von Haus aus nichts mit. Die Lösung: gMTP.

gMTP installieren

Das Paket gibt es direkt auf der gMTP-Downloadseite. Auspacken und installieren:

gunzip gmtp-1.3.1-i386.pkg.gz
pkgadd -d gmtp-1.3.1-i386.pkg

Fehlende Abhängigkeiten aus dem SFE-Repository nachinstallieren:

pkg install medialib libid3tag id3lib

libmtp kompilieren

libmtp war zum Zeitpunkt dieses Beitrags nicht als Paket verfügbar und musste selbst gebaut werden. Quellcode gibt es auf SourceForge.

gunzip libmtp-1.1.1.tar.gz
tar xvf libmtp-1.1.1.tar
cd libmtp-1.1.1
./configure --prefix=/usr
gmake
gmake install

Danach lässt sich gMTP über /usr/local/bin/gmtp starten. Der Creative ZEN Mozaic wird erkannt, Dateien lassen sich per Drag and Drop übertragen.

Screenshots

Screenshot vom gMTP MTP USB auf Solaris.
Screenshot vom Creative ZEN Mozaic mit gMTP - MTP Device Properties
Screenshot vom Creative ZEN Mozaic mit gMTP - Raw Device information

Fragen? Einfach melden.

Solaris 11: USB-Kamera und Scanner mit XSane einrichten

Veraltet: OpenIndiana und Solaris werden kaum noch als Desktop eingesetzt. USB-Kameras und Scanner funktionieren unter Linux mit SANE/XSane problemlos.

Man man man… Jetzt habe ich mich doch tatsächlich 1 Stunde lang in etwas sehr sinnlosem verrannt. *kopfschüttel*

Da will ich mal eben ein Bild mittels xsane von einem USB-Scanner einlesen. Da findet xsane auf dem Solaris 11 System den Scanner nicht. Genau so verhält es sich mit einer USB Digitalkamera…..  Ich habe ja überall nachgeschaut, nur wohl ohne Verstand!

Die Lösung war natürlich recht simpel. Einfach mal das Paket: libusbugen installieren. *Narf*

Fragen? Einfach melden.

XenServer mit Nagios überwachen

Veraltet: Citrix XenServer wird seit 2024 nicht mehr in dieser Form angeboten. Die hier beschriebene Nagios-Überwachung bezieht sich auf XenServer 6.x/7.x. Wer heute Virtualisierung überwachen will, sollte sich Proxmox VE oder XCP-ng anschauen.

Das folgende habe ich auf den Citrix XenServer in Version 5.6SP2 bis 6.2.0 anwenden können.
Im Grunde geht es darum auf dem „freien“ Citrix XenServer nrpe (Nagios Remote Plugin Executor) zu installieren um diesen mit Nagios auf einfache Weise überwachen zu können. Natürlich bietet der Cirtix XenServer ebenfalls die Möglichkeit ihn per SNMP zu überwachen und diese Version zu zu bevorzugen…. Für das eine oder andere Script ist die Ausführung per nrpe denn noch einfacher und schneller umzusetzen, als per snmp. Denn noch bitte beachten… Diese Version ist zwar absolut funktionsfähig und fast gefahrlos für das System, denn noch ist es „hereingefummelt“ und muss nach Versionsupgrade wieder (passend für die jeweilige Version) eingespielt werden. Die eigentliche Nagiosanbindung soll hier nicht Thema sein. Beispiele dazu kann man gerne bei mir erfragen.

So dann wollen wir mal:

Ich habe eine -schlechte- Angewohnheit. Ich erstelle immer gerne im Root das Verzeichnis 001 um dort meine Daten „herum zu würfeln“.

$ mkdir /001
$ cd /001

Im Grunde basiert der Citrix XenServer auf Redhat Linux/Fedora… Also können wir für diesen Fall auch die (Extra Packages for Enterprise Linux) epel nutzen.

$ wget http://dl.fedoraproject.org/pub/epel/5/x86_64/epel-release-5-4.noarch.rpm
$ rpm -hiv epel-release-5-4.noarch.rpm
$ sed -i 's/enabled=1/enabled=0/g' /etc/yum.repos.d/epel.repo

So und schon sollten wir die zusätzlichen Pakete nutzen können. In diesen findet sich sinnigerweise auch direkt nrpe, was wir gleich installieren:

$ yum install --enablerepo=epel nrpe
$ chkconfig nrpe on

Das chkconfig nrpe on sorgt dafür dass der Service direkt beim Start des Systems mitgestartet wird. Wichtig ist nun noch die passenden Löcher in die Firewall des XenServers zu schießen. Sonst läuft zwar der Dienst, wir bekommen von außen aber keine Verbindung. Hier muss nur in der folgenden Datei eine Zeile ergänzt werden:

$ nano -w /etc/sysconfig/iptables
…..
-A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 80 -j ACCEPT
-A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 443 -j ACCEPT
-A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 5666 -j ACCEPT
-A RH-Firewall-1-INPUT -j REJECT --reject-with icmp-host-prohibited
COMMIT
….

Damit wären wir schon feritg. Natürlich sollte man nun noch die Nagios Plugins installieren, Programme und Temperaturen von Festplatten oder IPMI auszulesen.

$ yum install --enablerepo=epel nagios-plugins hddtemp ….

Für IPMI (Intelligent Platform Management Interface) müssen ggf. noch die nötigen Kernelmodule geladen werden:

$ modprobe ipmi_devintf
$ modprobe ipmi_si

Konfigurieren lässt sich nrpe nun wie bekannt über:

$ nano -w /etc/nagios/nrpe.cfg

Die Konfiguration von nrpe und Nagios ist aber unabhängig von der Installation auf dem XenServer.


Ich habe gerade den Hinweis bekommen, dass es helfen könnte wenn ich hier erwähne dass man sich die Nagios Plugins noch zusätzlich installieren muss. Dieses Stimmt natürlich. Ich habe mir mit der Zeit einen Satz recht weit „angepasste“ Nagios Plugins zusammengestellt. Diese schiebe ich mir oft (unter Berücksichtigung der Abhängigkeiten) einfach passend hin und her kopiere. Vielleicht ein Grund warum ich das -vergessen- habe zu erwähnen.


Siehe auch: Citrix XenServer Updates manuell über Bash installieren, Citrix XenServer local storage größer >2TB, XenServer Linux Softwareraid

XenServer Linux Softwareraid

Veraltet: Citrix XenServer wird seit 2024 nicht mehr in dieser Form angeboten. XenServer 8 hat ein anderes Lizenzmodell, Software-RAID wird dort anders gehandhabt. Alternativen: Proxmox VE oder XCP-ng.

Wer die Freie Version des Citrix XenServers einsetzt hat in den meisten Fällen seine virtuellen Maschinen im Local Storage liegen. Natürlich hat ein Hardwareraid für diesen Speicherplatz Vorteile, aber er hat auch Nachteile.
Wie man hier dem XenServer nun einen Local Storage auf der Basis eine Softwarraids unterschieben kann, darum geht es hier!

Alle nötigen Schritte lassen sich direkt auf der Konsole des XenServers ausführen und ist vollständig mit Boardmitteln realisierbar. Die Konfiguration überlebt auch jegliche Updates/Upgrades von der Citrix XenServer Version 5.6 bis 6.1.0.

Wir gehen nun mal davon aus, eine 60GB SSD als Systemplatte für den eigentlichen Citrix XenServer zu haben und ein Softwareraid Level 5 aus drei Festplatten bauen zu wollen.
Damit hätten wir folgende Konfiguration:

/dev/sda    =>    Systemplatte
/dev/sdb    =>    Erste Festplatte RAID
/dev/sdc    =>    Zweite Festplatte RAID
/dev/sdd    =>    Dritte Festplatte RAID

Die für das Softwareraid vorgesehenen Festplatten sollten natürlich keine Daten enthalten und keine Informationen im MBR (Master Boot Record) haben. Diesen löschen wir also zur Sicherheit mit:

$ dd if=/dev/zero of=/dev/sdb bs=1 count=1024
$ dd if=/dev/zero of=/dev/sdc bs=1 count=1024
$ dd if=/dev/zero of=/dev/sdd bs=1 count=1024

Auf den drei Festplatten muss anschließend jeweils eine neue Partition angelegt werden. Diese Partition muss vom Type FD (Linux Raid Autodetect) sein.

$ fdisk /dev/sd[b,c,d]
N => neue Partition
T => Type setzten => FD
W => neue Partitionstabelle auf Platte schreiben
Q => fdisk beenden

Mit diesen vorbereiteten Platten kann nun das eigentliche Softwarraid erstellt werden:

$ mdadm --create /dev/md0 --level=5 --raid-devices=3 /dev/sdb1 /dev/sdc1 /dev/sdd1

Nun heißt es warten bis das Resilvering durchgelaufen ist. Wie weit es fortgeschritten ist lässt sich so beobachten:

$ watch –n 1 'cat /proc/mdstat'

Natürlich können wir jetzt schon auf das neue Softwareraid Laufwerk zugreifen. Ein Reboot sollte man aber erst nach dem ersten korrekten Resilvering durchführen.

Damit nun der Citrix XenServer Kenntnis von diesem neuen Speicherplatz erzählt, müssen wir es ihm noch „schmackhaft“ machen!
Zuerst legen wir auf diesem neuen Laufwerk nun eine Partition vom Type 8E (Linux LVM) an:

$ fdisk /dev/md0
N => neue Partition
T => Type setzten => 8E
W => neue Partitionstabelle auf Platte schreiben
Q => fdisk beenden

Wunderbar. Dann schieben wir es mal dem XenServer unter:

$ mdadm --examine --scan > /etc/mdadm.conf
$ pvcreate /dev/md0p1
$ xe sr-create type=lvm content-type=user device-config:device=/dev/md0p1 name-label="RAID-5"

Fertig…. Nun kann man schon im XenCenter den neuen lokalen Speicher RAID-5 finden und nutzen.

Citrix XenCenter management console showing software RAID

Es ist auch möglich dem Citrix XenServer einen lokalen Storage auf dieser Basis unter zu schiebe, der größer ist als 2TB. Dieses geht leider nicht mehr ganz mit Boardmitteln, da fdisk einfach die nötige Struktur nicht mehr anlegen kann. Der eingesetzte Kernel kann es aber sehr wohl ansprechen und verwalten. Hierzu schreibe ich sich später noch mal was..


* U-P-D-A-T-E *

Zusammen mit gdisk lassen sich nun auch GPT Partitionen anlegen.

Siehe auch: Citrix XenServer Updates manuell über Bash installieren, Citrix XenServer local storage größer >2TB, XenServer mit Nagios überwachen

ZFS iSCSI-Target mit COMSTAR auf OpenIndiana einrichten

COMSTAR (Common Multiprotocol SCSI Target) ist das Framework in Solaris/OpenIndiana, das iSCSI, FC und FCoE unter einem Dach vereint. Es ersetzt den alten iSCSI Target Daemon aus Solaris 10. Hier die Einrichtung eines iSCSI-Targets auf Basis eines ZFS-Volumes für einen Windows-Initiator.

ZFS-Volume anlegen

Zuerst einen eigenen Pool und darin ein ZFS-Volume mit fester Größe erstellen — das Volume wird später die LUN:

zpool create iscsi-target-pool c4t2d0

zfs create -V 10g iscsi-target-pool/iscsi_10gb-lun01
zfs list iscsi-target-pool/iscsi_10gb-lun01
NAME                                   USED  AVAIL  REFER  MOUNTPOINT
iscsi-target-pool/iscsi_10gb-lun01    10,3G  19,6G    16K  -

Die feste Größe (-V 10g) ist wichtig — sonst würde die Poolgröße das Target begrenzen, und bei mehreren Targets im selben Pool wird es unübersichtlich.

COMSTAR-Dienste starten

Das SCSI Target Mode Framework (STMF) aktivieren:

svcadm enable stmf
svcs stmf
STATE   STIME    FMRI
online  13:02:50 svc:/system/stmf:default

stmfadm list-state
Operational Status: online
Config Status     : initialized

Das iSCSI-Target-Paket installieren und den Dienst starten:

pkg install /network/iscsi/target

svcs iscsi/target
STATE   STIME    FMRI
online  13:23:56 svc:/network/iscsi/target:default

Logical Unit erstellen

Eine LUN auf Basis des ZFS-Volumes anlegen:

sbdadm create-lu /dev/zvol/rdsk/iscsi-target-pool/iscsi_10gb-lun01
Created the following LU:

GUID                             DATA SIZE     SOURCE
-------------------------------- ------------- ----------------
600144f051c247000000523ed0050001 10737418240   /dev/zvol/rdsk/iscsi-target-pool/iscsi_10gb-lun01

Prüfen ob die LUN online ist:

stmfadm list-lu -v
LU Name            : 600144F051C247000000523ED0050001
Operational Status : Online
Provider Name      : sbd
Alias              : /dev/zvol/rdsk/iscsi-target-pool/iscsi_10gb-lun01
Data File          : /dev/zvol/rdsk/iscsi-target-pool/iscsi_10gb-lun01
Size               : 10737418240
Block Size         : 512

Damit der Initiator die LUN sehen kann, einen View erstellen:

stmfadm add-view 600144F051C247000000523ED0050001
stmfadm list-view -l 600144F051C247000000523ED0050001
View Entry: 0
  Host group   : All
  Target group : All
  LUN          : 0

iSCSI-Target anlegen

Zwischenstand:

  • STMF und iSCSI-Target-Dienst laufen
  • 10 GB ZFS-Volume als LUN angelegt
  • View erstellt, damit Initiatoren die LUN sehen

Fehlt noch das Target selbst:

itadm create-target
Target iqn.2010-09.org.openindiana:02:6c3939bf-f5e5-4f28-a8d0-d0f0bbb2e1c4 successfully created

itadm list-target -v
TARGET NAME                                                          STATE   SESSIONS
iqn.2010-09.org.openindiana:02:6c3939bf-f5e5-4f28-a8d0-d0f0bbb2e1c4 online  0
  alias:             -
  auth:              none (defaults)
  targetchapuser:    -
  targetchapsecret:  unset
  tpg-tags:          default

Zum Schluss sicherstellen, dass das Target im Discovery auftaucht:

devfsadm -i iscsi

Windows-Initiator verbinden

Auf der Windows-Seite den eingebauten Microsoft iSCSI-Initiator öffnen (ab Windows 7 vorinstalliert):

  • Portal über die IP-Adresse des OpenIndiana-Hosts ermitteln lassen
  • Das Ziel suchen und verbinden
  • Die neue Festplatte in der Datenträgerverwaltung initialisieren und ein Volume erstellen
Screenshot der Windows Fehlermeldung: You do not have permission to update Windows.Screenshot der Windows Fehlermeldung: Setup could not find the update.inf file.Screenshot des Windows iSCSI-Initiators mit der Zielportal-Einstellung.Screenshot des Windows iSCSI-Initiators mit dem erkannten Ziel.
Screenshot des Windows iSCSI-Initiators beim Verbinden mit dem Ziel.Screenshot des Windows iSCSI-Initiators mit der Volumeliste.Screenshot der Windows Datenträgerinitialisierung mit dem erkannten iSCSI-Datenträger.Screenshot der Windows Datenträgerverwaltung mit dem fertig konfigurierten COMSTAR SCSI Device.

Mehr zu ZFS: ZFS Compression und Deduplication. Fragen? Einfach melden.

ZFS SMB-Freigaben unter Solaris/OpenIndiana mit sharesmb einrichten

Hinweis: Dieser Artikel beschreibt SMB-Freigaben mit dem eingebauten SMB-Server von Solaris/OpenIndiana. Unter FreeBSD und Linux nutzt man stattdessen Samba — dort wird sharesmb nicht unterstützt.

SMB-Server einrichten

Die SMB Server Kernel-Komponenten installieren:

pkg install SUNWsmbskr

Damit lokale Benutzer sich per Benutzername und Passwort authentifizieren können, das PAM-Modul in /etc/pam.conf eintragen:

other password required pam_smb_passwd.so.1 nowarn

SMB-Server starten und prüfen:

svcadm enable -r smb/server

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

In die gewünschte Workgroup eintreten:

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

ZFS-Freigabe erstellen

Ein neues ZFS-Dataset anlegen und direkt per SMB freigeben — ein einziges Property reicht:

zfs create rpool/daten-freigabe

zfs set sharesmb=on rpool/daten-freigabe

zfs get sharesmb rpool/daten-freigabe
NAME                 PROPERTY  VALUE  SOURCE
rpool/daten-freigabe sharesmb  on     local

Das war es. Das Dataset ist jetzt als SMB-Share im Netzwerk sichtbar. Kein Samba, keine smb.conf — der Kernel-SMB-Server von Solaris arbeitet direkt mit ZFS zusammen. Alle ZFS-Features (Snapshots, Compression, Quotas) gelten für die Freigabe genauso wie für jedes andere Dataset.

Zugriff

Von einem Windows-Client aus die Freigabe über \\hostname\daten-freigabe erreichen. Die Authentifizierung läuft über die lokalen Unix-Benutzer — das PAM-Modul synchronisiert die Passwörter automatisch.

Mehr zu ZFS: ZFS Compression und Deduplication. Fragen? Einfach melden.

ZFS NFS-Freigaben unter Solaris/OpenIndiana mit sharenfs einrichten

ZFS bringt NFS-Freigaben als eingebaute Funktion mit — kein separater NFS-Server nötig, ein einziges Property reicht. Das funktioniert unter Solaris, OpenIndiana und teilweise auch unter FreeBSD.

NFS-Freigabe erstellen

Dataset anlegen und per NFS freigeben:

zfs create rpool/daten

zfs set sharenfs=on rpool/daten

zfs get sharenfs rpool/daten
NAME        PROPERTY  VALUE  SOURCE
rpool/daten sharenfs  on     local

Das war es. Das Dataset ist jetzt per NFS im Netzwerk verfügbar — für alle Clients, ohne Einschränkung.

NFS-Optionen

Statt on lassen sich die üblichen NFS-Optionen direkt im Property angeben — zum Beispiel Zugriff nur für ein bestimmtes Subnetz:

# Nur Lesen/Schreiben für ein Subnetz
zfs set sharenfs="rw=@192.168.1.0/24" rpool/daten

# Nur Lesen für alle, Schreiben für ein Subnetz
zfs set sharenfs="ro,rw=@10.0.0.0/8" rpool/daten

# Freigabe prüfen
share -F nfs

Auf dem Client mounten:

mount -t nfs server:/rpool/daten /mnt/daten

Portabilität

Ein netter Nebeneffekt: ZFS-Properties wandern mit dem Pool. Exportiert man den Pool und importiert ihn auf einem anderen System, ist die NFS-Freigabe sofort wieder aktiv:

# Pool exportieren (z.B. vor dem Umstecken einer USB-Platte)
zpool export nfs-share

# Auf einem anderen System importieren — Share ist sofort da
zpool import nfs-share

Alle ZFS-Einstellungen — Compression, Quotas, Snapshots, Freigaben — bleiben erhalten. Für SMB-Freigaben statt NFS siehe ZFS SMB-Freigaben mit sharesmb. Mehr zu ZFS: ZFS Compression und Deduplication. Fragen? Einfach melden.

ZFS Snapshots: Erstellen, Zugreifen und per SSH replizieren

Was sind ZFS-Snapshots?

ZFS arbeitet mit Copy-on-Write — jede Änderung wird an eine neue Stelle geschrieben, die alten Blöcke bleiben erhalten. Ein Snapshot friert diesen Stand ein: Die Blöcke werden einfach nicht mehr zum Überschreiben freigegeben. Deshalb ist ein Snapshot schneller erstellt als eine Datei gespeichert — er kostet nur so viel Platz, wie sich danach ändert.

Was man damit machen kann:

  • Einzelne Dateien aus dem Snapshot herauskopieren
  • Das gesamte Dataset auf den Snapshot-Stand zurückrollen
  • Einen beschreibbaren Clone aus dem Snapshot erstellen
  • Den Snapshot (oder nur die Differenz zum nächsten) per SSH auf ein anderes System replizieren

Snapshot erstellen und nutzen

Dataset mit Testdaten vorbereiten:

zfs create rpool/testdaten
dd if=/dev/zero of=/rpool/testdaten/image01.img bs=10240 count=10240   # 100 MB

zfs list rpool/testdaten
NAME              USED  AVAIL  REFER  MOUNTPOINT
rpool/testdaten   100M  9,02G   100M  /rpool/testdaten

Snapshot erstellen — der Name nach dem @ ist frei wählbar:

zfs snapshot rpool/testdaten@vor-aenderung

Auf den Snapshot zugreifen — das versteckte Verzeichnis .zfs taucht nicht in ls auf, ist aber direkt erreichbar:

ls /rpool/testdaten/.zfs/snapshot/
vor-aenderung

ls /rpool/testdaten/.zfs/snapshot/vor-aenderung/
image01.img

Von hier aus lassen sich versehentlich gelöschte Dateien einfach zurückkopieren. Um das gesamte Dataset auf den Snapshot-Stand zurückzurollen:

zfs rollback rpool/testdaten@vor-aenderung

Snapshot per SSH replizieren

Mit zfs send und zfs recv lässt sich ein Snapshot auf ein anderes System schieben — ein Einzeiler:

zfs send rpool/testdaten@vor-aenderung \
  | ssh root@backup-server zfs recv backup/testdaten@vor-aenderung

Danach muss nur noch die Differenz zwischen zwei Snapshots übertragen werden — bei 1 GB Änderungen auf einem 100 GB Dataset werden auch nur 1 GB übertragen. Alle ZFS-Properties (NFS-Shares, SMB-Shares, Quotas) wandern mit. Mehr dazu im Beitrag zur ZFS-Datensicherung und zur Fehlerbehebung bei zfs send/recv.

Time Slider und Boot Environments

Unter OpenIndiana/Solaris gibt es den Time Slider — ein Nautilus-Plugin, das automatisch Snapshots erstellt und eine grafische Zeitleiste bietet. Alte Snapshots werden automatisch aufgeräumt wenn die Platte voll wird.

Noch mächtiger sind Boot Environments (beadm). Vor einem Systemupdate wird automatisch ein Snapshot des Root-Pools erstellt und davon ein Clone gebootet. Geht beim Update etwas schief, bootet man einfach das alte Environment — kein Stress, kein Ausfall:

beadm list
BE                  Active Mountpoint Space  Policy Created
openindiana         NR     /          11,6G  static 2011-09-28 19:06
openindiana-1       -      -          37,3M  static 2011-10-27 20:04

# Neues Boot Environment anlegen
beadm create vor-experiment

Für automatisierte Snapshots unter FreeBSD siehe automatische ZFS-Snapshots mit zfs-auto-snapshot. Fragen? Einfach melden.

ZFS RAID: Mirror, RAID-Z und Root-Pool spiegeln

ZFS bringt RAID als eingebaute Funktion mit — kein separater Volumemanager nötig. Mirror, RAID-Z (ähnlich RAID-5), RAID-Z2 (ähnlich RAID-6) und RAID-Z3 sind direkt im Pool konfigurierbar. Spare-Platten und Striping ebenfalls.

Mirror anlegen

Einen neuen Pool direkt als Mirror erstellen:

zpool create backup mirror da0 da1

Einem bestehenden Pool eine Spiegelplatte hinzufügen:

zpool attach backup da0 da1
Make sure to wait until resilver is done before rebooting.

Wichtig: Die Reihenfolge der Platten zählt. Die erste Platte (da0) ist die Quelle, die zweite (da1) wird als Spiegel hinzugefügt. Vertauscht man die Platten, spiegelt ZFS die leere Platte auf die Datenplatte.

RAID-Z

RAID-Z verteilt Daten und Parität über mehrere Platten — ähnlich wie klassisches RAID, aber mit Copy-on-Write und ohne Write Hole:

# raidz — 1 Platte darf ausfallen (wie RAID-5), mindestens 3 Platten
zpool create tank raidz da0 da1 da2

# raidz2 — 2 Platten dürfen ausfallen (wie RAID-6), mindestens 4 Platten
zpool create tank raidz2 da0 da1 da2 da3

# raidz3 — 3 Platten dürfen ausfallen, mindestens 5 Platten
zpool create tank raidz3 da0 da1 da2 da3 da4

# Mit Hot-Spare
zpool create tank raidz da0 da1 da2 spare da3

Resilvering

Beim Resilvering zeigt sich ein großer Vorteil von ZFS: Da Dateisystem und Volumemanager nicht getrennt sind, weiß ZFS genau, wo Daten liegen. Es spiegelt nur belegte Blöcke. Ein 80-GB-Mirror mit 4 GB Daten war in 5 Minuten fertig resilvered — klassische Lösungen wie mdadm würden stumpf alle 80 GB Block für Block kopieren.

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
    backup      ONLINE       0     0     0
      mirror-0  ONLINE       0     0     0
        da0     ONLINE       0     0     0
        da1     ONLINE       0     0     0

errors: No known data errors

Root-Pool spiegeln

Gespiegelte Daten helfen nichts, wenn die Systemplatte ausfällt und man nicht booten kann. Daher den Root-Pool ebenfalls spiegeln — und den Bootloader auf beide Platten schreiben.

Unter Solaris/OpenIndiana:

# Partitionslayout der Quellplatte auf die Zielplatte kopieren
prtvtoc /dev/rdsk/c2d0s2 | fmthard -s - /dev/rdsk/c2d1s2

# Zielplatte dem Root-Pool als Mirror hinzufügen
zpool attach -f rpool c2d0s0 c2d1s0
Make sure to wait until resilver is done before rebooting.

# Grub auf die Zielplatte schreiben
installgrub /boot/grub/stage1 /boot/grub/stage2 /dev/rdsk/c2d1s0

Unter FreeBSD ist es einfacher — gpart für die Partitionierung und gptzfsboot für den Bootloader. Unter Linux mit UEFI reicht oft ein zpool attach und die Kopie der EFI-Partition.

Praxistest — Hauptplatte gezogen, System von der Spiegelplatte gebootet:

zpool status rpool
  pool: rpool
 state: DEGRADED
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

Degraded, aber online — genau wie gewünscht. Nach dem Einsetzen einer neuen Platte übernimmt zpool replace den Rest.

Details in der OpenZFS-Dokumentation zu zpool create. Mehr zu ZFS: ZFS Snapshots und ZFS Compression und Deduplication. Fragen? Einfach melden.

« Ältere Beiträge Neuere Beiträge »

© 2026 -=Kernel-Error=-RSS

Theme von Anders NorénHoch ↑