IT security, FreeBSD, Linux, mail server hardening, post-quantum crypto, DNS, retro computing & hands-on hardware hacks. Privater Tech-Blog seit 2003.
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*.
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.
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 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.
Fragen? Einfach melden.
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.
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
Veraltet: OpenIndiana und Solaris werden kaum noch eingesetzt. Lokale Paketquellen lassen sich unter FreeBSD mit poudriere und unter Linux mit apt-mirror oder createrepo einrichten.
Man kann zwar über das „klickbunit“ Interface XenCenter für seinen einzelnen XenServer neue ISO libarays anlegen, diese können dann leider nur auf einem Windows File Shareing (CIFDS) oder NFS ISO Share liegen. Klar, man könnte nun eine VM auf dem XenServer installieren und dort einen solchen Share anlegen. oder eine Kiste neben den Server stellen, welcher die ISOs vorhält. In größeren Umgebungen kein Problem… Im „Kleinen“ schon mal nervig.
Ich habe für mich eine einfache Lösung gefunden. Ich schraube einfach eine weitere kleine Platte in den Server, lege dort die für mich wichtigen ISOs ab und baue mir eine lokale ISO library. So habe ich die nötigen ISOs immer auf der Kiste, selbst wenn alles andere aus sein sollte.
Also lokalen Speicherplatz für die ISOs habe ich an eine 160GB SATA Platte von WD gedacht. Diese wird nicht gespiegelt oder ähnliches, da die ISO Files für mich erstmal keinen Wert haben. Brennt die Platte wirklich ab, kopiere ich die ISO Files halt auf eine neue.
Nach dem Einbau ist die WD Platte in meinem System als /dev/sde zu finden. Als erstes werde ich nun auf ihr eine primäre Patrion vom Type 83 (Linux) anlegen:
$ fdisk /dev/sde The number of cylinders for this disk is set to 19457. There is nothing wrong with that, but this is larger than 1024, and could in certain setups cause problems with: 1) software that runs at boot time (e.g., old versions of LILO) 2) booting and partitioning software from other OSs (e.g., DOS FDISK, OS/2 FDISK) Command (m for help):
Die Hilfe zu fdisk kann sicher jeder selbst lesen… Ich schaue als erstes über p nach ob ich wirklich auf der richtigen Platte bin, denn p listet mir die Partitionen auf der Platte auf. Dann erstell ich mit n ==> p ==> 1 eine neue primäre Partition und schreibe am Ende alles mit w auf die Platte. q beendet als letztes fdisk.
Nun muss ich die neue Partition noch formatieren. Als Dateisystem finde ich ext3 ganz passend:
$ mkfs.ext3 -L ISO-Store /dev/sde1
mke2fs 1.39 (29-May-2006)
Filesystem label=ISO-Store
OS type: Linux
Block size=4096 (log=2)
Fragment size=4096 (log=2)
19546112 inodes, 39072080 blocks
1953604 blocks (5.00%) reserved for the super user
First data block=0
Maximum filesystem blocks=0
1193 block groups
32768 blocks per group, 32768 fragments per group
16384 inodes per group
Superblock backups stored on blocks:
32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208,
4096000, 7962624, 11239424, 20480000, 23887872
Writing inode tables: done
Creating journal (32768 blocks): done
Writing superblocks and filesystem accounting information: done
This filesystem will be automatically checked every 26 mounts or
180 days, whichever comes first. Use tune2fs -c or -i to override.
Nun erstelle ich einen Mountpoint unter welchem ich die Platte einbinden möchte:
$ mkdir /ISOs
Schon kann ich die Platte mounten:
$ mount /dev/sde1 /ISOs
Noch schnell eine kontrolle ob alles dort ist wo es hin soll:
$ mount|grep ISO /dev/sde1 on /ISOs type ext3 (rw)
Mit einem Eintrag in die fstab (ich muss immer aufpassen nicht vfstab zu schreiben) sorge ich nun dafür dass die neue Platte bei jedem Start des Servers wieder eingebunden wird.
$ vi /etc/fstab
und dann folgende Zeile einfügen:
/dev/sde1 /ISOs ext3 defaults 0 0
Jetzt kommt das wirklich spannende. XEN die neue Platte als localen ISO Speicher schmackhaft zu machen:
$ xe sr-create name-label=ISOs type=iso device-config:legacy_mode=true device-config:location=/ISOs content-type=iso 00da02b3-8b46-bade-6d00-e109e262ede9
Schaut doch schon gut aus, oder? Dann lassen wir uns mal die neue ISO library anzeigen:
$ xe sr-list uuid=00da02b3-8b46-bade-6d00-e109e262ede9
uuid ( RO) : 00da02b3-8b46-bade-6d00-e109e262ede9
name-label ( RW): ISOs
name-description ( RW):
host ( RO): xenserver01-kernel-error.local
type ( RO): iso
content-type ( RO): iso
Warum auch immer, wird die Platte bei mir an diesem Punkt immer ausgehangen. Ich könnte es jetzt einfach wieder mounten und nutzen, würde denn noch vorschlagen hier den Server selbst einmal zu rebooten. So kann man gleich sehen ob die Platte wieder richtig eingebunden wird. Nach dem Reboot schaue ich also nach ob die Platte wieder richtig eingehangen wurde:
$ mount|grep ISO/dev/sde1 on /ISOs type ext3 (rw)
Jetzt kopiere ich das nötige ISO auf die Platte:
scp WindowsSvrStd2008R2.iso root@10.44.2.88:/ISOs WindowsSvrStd2008R2. 100% |******************************************************************************************************************************************************************************************| 3052 MB 01:28
Im XenCenter sollte man nun schon das neue SR mit dem Namen „ISOs“ sehen. Klicke man nun am Reiter Storage auf Rescan wird das hochgeladene ISO gefunden und kann verwendet werden. Ich muss nun also nur noch alle meine ISOs dort hochschieben und fertig ist!
Siehe auch: Citrix XenServer Updates manuell über Bash installieren, Citrix XenServer local storage größer >2TB, XenServer mit Nagios überwachen, XenServer Linux Softwareraid
Hinweis: Dieser Artikel beschreibt die ZFS-Verschlüsselung unter Solaris 11 und OpenIndiana. Unter OpenZFS (FreeBSD 13+, Linux) gibt es seit 2019 native Verschlüsselung mit zfs create -o encryption=aes-256-gcm -o keyformat=passphrase pool/dataset — das funktioniert ohne die Solaris-spezifischen PAM-Module. Für verschlüsselte Backups auf FreeBSD mit geli siehe ZFS-Backup auf USB-Platte mit geli.
Ab ZFS Version 30 lässt sich ein Dataset beim Erstellen verschlüsseln — mit AES-128, AES-192 oder AES-256. Bei Schlüsseln größer 128 Bit macht eine Hardwarebeschleunigung Sinn (SPARC T2/T3, Intel AES-NI). Für die meisten Szenarien reicht AES-128 völlig aus.
zfs create -o encryption=on rpool/export/home/kernel/DatenSafe Enter passphrase for 'rpool/export/home/kernel/DatenSafe': Enter again:
Nach einem Reboot wird das verschlüsselte Dataset nicht automatisch eingehängt — man muss es manuell mounten:
zfs mount rpool/export/home/kernel/DatenSafe Enter passphrase for 'rpool/export/home/kernel/DatenSafe':
Statt einer Passphrase kann der Schlüssel auch als Datei auf einem USB-Stick liegen:
zfs create -o encryption=on -o keysource=raw,file:///media/usb-stick/schluessel \ rpool/export/home/kernel/DatenSafe
Dann den USB-Stick getrennt vom System aufbewahren — und eine Kopie des Schlüssels an einem sicheren dritten Ort. Ohne Schlüssel oder Passphrase sind die Daten nicht wiederherstellbar.
Unter Solaris 11 gibt es ein PAM-Modul (pam_zfs_key.so.1), das den Encryption Key des ZFS-Homedirectories an das Unix-Passwort des Benutzers koppelt. Beim Login wird das Homedirectory automatisch entschlüsselt und eingehängt — transparent für den Benutzer, funktioniert mit Konsole, SSH und GDM.
Konfiguration in /etc/pam.conf:
login auth required pam_zfs_key.so.1 create other password required pam_zfs_key.so.1 sshd-kbdint auth requisite pam_authtok_get.so.1 sshd-kbdint auth required pam_unix_cred.so.1 sshd-kbdint auth required pam_unix_auth.so.1 sshd-kbdint auth required pam_zfs_key.so.1 create gdm auth requisite pam_authtok_get.so.1 gdm auth required pam_unix_cred.so.1 gdm auth required pam_unix_auth.so.1 gdm auth required pam_zfs_key.so.1 create
Neuen Benutzer anlegen und beim ersten Login zur Passwortänderung zwingen — dabei wird das verschlüsselte Homedirectory automatisch erstellt:
useradd sebastian passwd sebastian passwd -f sebastian
Beim ersten Login passiert alles automatisch:
login: sebastian Password: Choose a new password. New Password: Re-enter new Password: login: password successfully changed for sebastian Creating home directory with encryption=on. Your login password will be used as the wrapping key.
Prüfen:
zfs get encryption,keysource rpool/export/home/sebastian NAME PROPERTY VALUE SOURCE rpool/export/home/sebastian encryption on local rpool/export/home/sebastian keysource passphrase,prompt local
So sieht der Vorgang im GDM (Gnome Display Manager) aus:
Ein bestehendes ZFS-Dataset lässt sich nicht nachträglich verschlüsseln. Der Weg: Dataset umbenennen, Benutzer zur Passwortänderung zwingen (erstellt neues verschlüsseltes Home), Daten zurückkopieren:
# Als anderer Admin mit root-Rechten: zfs rename -f rpool/export/home/kernel rpool/export/home/kernel-alt passwd -f kernel # Nach dem Login (neues verschlüsseltes Home wurde angelegt): cp -rp /export/home/kernel-alt/* /export/home/kernel/ zfs destroy rpool/export/home/kernel-alt
Wichtig: Die alten unverschlüsselten Daten liegen nach dem Destroy noch physisch auf der Platte und werden erst nach und nach überschrieben. Für echte Sicherheit müsste man die gesamte Platte überschreiben — oder besser: gleich bei der Installation verschlüsseln.
Mehr zu ZFS: ZFS Compression und Deduplication. Fragen? Einfach melden.
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.
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
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.
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 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.
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 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
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
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.
Siehe auch: ZFS Pool und Datasets erstellen: Die Grundlagen, ZFS RAID: Mirror, RAID-Z und Root-Pool spiegeln, ZFS: Warum dieses Dateisystem anders ist
ZFS kann Daten transparent beim Schreiben komprimieren und beim Lesen dekomprimieren. Bei heutigen CPUs merkt man davon nichts — im Gegenteil: Weil weniger Daten auf die Platte geschrieben werden müssen, sinkt die I/O-Last und es wird oft sogar schneller. Man bekommt also mehr Platz und mehr Performance gleichzeitig.
Wichtig: Beim Aktivieren werden nicht rückwirkend alle Daten komprimiert. Nur neue Schreibvorgänge werden komprimiert abgelegt. Schaltet man Compression wieder ab, bleiben die komprimierten Daten lesbar — neue Daten werden unkomprimiert geschrieben.
Aktivieren:
zfs set compression=lz4 pool/dataset
LZ4 ist heute der empfohlene Algorithmus — schnell, niedriger CPU-Verbrauch, gutes Kompressionsverhältnis. Es ist seit OpenZFS 0.7 und FreeBSD 12 der Default bei compression=on. Alternativ gibt es gzip (Level 1–9, stärkere Kompression aber mehr CPU) und zstd (seit OpenZFS 2.0, guter Kompromiss zwischen gzip und lz4).
Für Daten, die bereits komprimiert sind (Videos, Bilder, Archive), bringt Compression nichts — ZFS erkennt das und legt solche Blöcke unkomprimiert ab. Für Logfiles, Konfigurationen, VMs und Datenbanken lohnt es sich fast immer.
Test mit einer frischen Betriebssystem-Installation auf zwei baugleichen Rechnern — einmal mit, einmal ohne Compression:
# Kompressionsverhältnis prüfen zfs get compressratio rpool NAME PROPERTY VALUE SOURCE rpool compressratio 1.52x - # Plattenverbrauch mit Compression zpool list NAME SIZE ALLOC FREE CAP HEALTH rpool 74G 2,59G 71,4G 3% ONLINE # Plattenverbrauch ohne Compression zpool list NAME SIZE ALLOC FREE CAP HEALTH rpool 74G 3,93G 70,1G 5% ONLINE
2,59 GB statt 3,93 GB — ein Drittel weniger Plattenverbrauch bei einer Standard-Installation. Die Installation dauerte mit Compression etwa 30 Sekunden länger.
Pro Dataset lässt sich der Algorithmus und Level anpassen:
# LZ4 — schnell, empfohlen für fast alles zfs set compression=lz4 pool/data # gzip-9 — maximale Kompression, mehr CPU zfs set compression=gzip-9 pool/archiv # zstd — seit OpenZFS 2.0, guter Kompromiss zfs set compression=zstd pool/logs # Prüfen zfs get compression pool/data
Bei aktivierter Deduplication werden identische Blöcke nur einmal gespeichert. ZFS bildet für jeden Block eine SHA-256-Checksumme — existiert ein Block mit derselben Checksumme bereits, wird nur ein Verweis angelegt statt die Daten erneut zu schreiben.
Das spart Platz bei VMs (viele identische OS-Blöcke), Fileservern (dasselbe Dokument an verschiedenen Stellen) oder Versionierungs-Kopien. Aktivieren:
zfs set dedup=on pool/vms
Für zusätzliche Sicherheit gegen Hash-Kollisionen kann man einen Byte-für-Byte-Vergleich erzwingen:
zfs set dedup=sha256,verify pool/vms
Deduplication frisst RAM. Die Dedup-Tabelle (DDT) muss im Arbeitsspeicher gehalten werden — pro Block ein Eintrag. Faustformel: ~320 Bytes pro Block, bei 128K-Blockgröße also ~2,5 GB RAM pro TB gespeicherter Daten. Passt die DDT nicht mehr in den RAM, wird sie auf die Platte ausgelagert und die Performance bricht dramatisch ein.
Ob sich Dedup lohnt, kann man vorher mit einem Trockenlauf prüfen — zdb -S pool zeigt das erwartete Dedup-Ratio ohne tatsächlich zu deduplizieren. In den meisten Fällen ist Compression allein die bessere Wahl: weniger Komplexität, kein RAM-Overhead, und der Platzvorteil ist oft vergleichbar.
Mehr zu ZFS: TRIM im ZFS-Pool aktivieren und Linux Mint mit verschlüsseltem ZFS Root Pool. Fragen? Einfach melden.
Veraltet: OpenIndiana und Solaris werden kaum noch eingesetzt. Wer heute einen Unix-ähnlichen Server betreiben will, ist mit FreeBSD oder Linux besser bedient.
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?
© 2026 -=Kernel-Error=- — RSS
Theme von Anders Norén — Hoch ↑