-=Kernel-Error=-

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 8 von 10)

ZFS Snapshots: Erstellen, Zugreifen und per SSH replizieren

22. März 2012 / / Keine Kommentare

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

22. März 2012 / / Keine Kommentare

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.

ZFS Compression und Deduplication: Konfiguration und Praxis

22. März 2012 / / Keine Kommentare

Compression

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.

Compression in der Praxis

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.

Algorithmus-Wahl

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

Deduplication

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

Dedup-Warnung: RAM-Verbrauch

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.

ZFS Pool und Datasets erstellen: Die Grundlagen

22. März 2012 / / Keine Kommentare

Für die Administration von ZFS muss man sich zwei Befehle merken: zpool wenn es um den Pool geht (Platten, Redundanz, Status) und zfs wenn es um Datasets geht (Dateisysteme, Properties, Snapshots).

Pool erstellen

Ein Pool auf einer einzelnen Platte:

zpool create backup da0

zpool list backup
NAME     SIZE  ALLOC   FREE  CAP  HEALTH
backup  74,5G   132K  74,5G   0%  ONLINE

ZFS erkennt automatisch, dass da0 eine Platte ist, legt ein gleichnamiges Root-Dataset an und mountet es unter /backup. Man kann sofort Daten speichern. Für Redundanz siehe ZFS RAID: Mirror und RAID-Z.

Datasets anlegen

Innerhalb eines Pools legt man Datasets an — vergleichbar mit Partitionen, aber flexibler. Jedes Dataset kann eigene Properties haben (Compression, Quota, Mountpoint):

# Dataset anlegen
zfs create backup/daten

# Quota setzen — maximal 50 GB
zfs set quota=50G backup/daten

# Reservation — mindestens 10 GB garantiert
zfs set reservation=10G backup/daten

# Mountpoint ändern
zfs set mountpoint=/mnt/daten backup/daten

# Ergebnis prüfen
zfs list backup/daten
NAME           USED  AVAIL  REFER  MOUNTPOINT
backup/daten    31K   50,0G    31K  /mnt/daten

Datasets teilen sich den freien Platz im Pool — ohne Quota kann jedes Dataset den gesamten Pool füllen. Mit Quota begrenzt man den Verbrauch, mit Reservation garantiert man einen Mindestanteil. Properties wie Compression lassen sich pro Dataset setzen.

Pool export und import

Einen Pool kann man jederzeit exportieren und auf einem anderen System importieren — alle Datasets, Properties und Snapshots wandern mit:

# Pool exportieren (z.B. vor dem Abziehen einer USB-Platte)
zpool export backup

# Auf einem anderen System importieren
zpool import backup

# Verfügbare Pools anzeigen (ohne Import)
zpool import

Details zu allen Pool-Optionen in der OpenZFS-Dokumentation. Fragen? Einfach melden.

ZFS mit NTFS-ACLs: Windows-Berechtigungen unter Solaris/OpenIndiana

20. März 2012 / / Keine Kommentare

ZFS unter Solaris/OpenIndiana kann mehr als einfache SMB-Freigaben — man kann Windows-Berechtigungen (NTFS-ACLs) direkt auf dem ZFS-Dataset setzen. Dateien und Ordner lassen sich dann vom Windows-Client aus genauso berechtigen wie auf einem Windows-Server. Das funktioniert über NFSv4-ACLs, die ZFS nativ unterstützt.

Voraussetzung: Der Kernel-SMB-Server muss laufen und in eine Workgroup eingebucht sein. Die Einrichtung ist im Beitrag ZFS SMB-Freigaben mit sharesmb beschrieben — hier geht es nur um die ACLs.

Dataset mit Windows-Kompatibilität anlegen

Windows unterscheidet nicht zwischen Groß- und Kleinschreibung. Damit das auf ZFS korrekt funktioniert, setzt man casesensitivity=mixed. Für gleichzeitige NFS-Nutzung empfiehlt sich zusätzlich nbmand=on (Non-Blocking Mandatory Locking):

zfs create -o casesensitivity=mixed -o nbmand=on fileserver/daten

Freigabe mit benutzerdefiniertem Namen und Beschreibung erstellen:

zfs set "sharesmb=name=DatenShare,description=Der Testdaten Share" fileserver/daten

ACL-Vererbung konfigurieren

Damit Berechtigungen korrekt an neue Dateien und Unterordner vererbt werden, braucht man zwei ZFS-Properties:

# ACL-Vererbung: Berechtigungen werden 1:1 an Kind-Objekte weitergegeben
zfs set aclinherit=passthrough fileserver/daten

# ACL-Modus: chmod ändert nur die POSIX-Bits, nicht die ACLs
zfs set aclmode=passthrough fileserver/daten

Benutzer und Besitz setzen:

useradd -g cifsshare -s /bin/false -c TestUser -m test
passwd test
chown -R test:cifsshare /fileserver/daten

NFSv4-ACLs setzen

Jetzt kommt der entscheidende Schritt — die initialen ACLs für Owner, Group und Everyone setzen. Wichtig: Man muss das Solaris-/usr/bin/chmod verwenden, nicht das GNU-chmod:

/usr/bin/chmod A=\
owner@:rwxpdDaARWcCos:fd-----:allow,\
group@:rwxpdDaARWcCos:fd-----:allow,\
everyone@:rwxpdDaARWcCos:fd-----:allow \
/fileserver/daten

Die Buchstaben nach dem @ sind die NFSv4-ACL-Rechte — rwx (read/write/execute), p (append), d (delete child), D (delete), a (read attributes), A (write attributes), R (read named attrs), W (write named attrs), c (read ACL), C (write ACL), o (write owner), s (synchronize). Die Flags fd bedeuten: Vererbung auf Files und Directories.

Hier werden erstmal alle Rechte für alle vergeben — als Basis zum Testen. In der Praxis schränkt man die Rechte natürlich ein und setzt sie dann granular vom Windows-Client aus.

Berechtigungen vom Windows-Client setzen

Nach der Verbindung mit \\hostname\DatenShare lassen sich die Berechtigungen im Windows-Explorer über Rechtsklick → Eigenschaften → Sicherheit setzen — genau wie auf einem NTFS-Volume:

Windows Explorer: Netzlaufwerk verbinden mit dem ZFS-SMB-Share.
Windows Explorer: Dateien und Ordner auf dem ZFS-Share.
Windows Sicherheitsdialog: Berechtigungen auf dem ZFS-Share anzeigen.
Windows Sicherheitsdialog: Erweiterte Berechtigungen bearbeiten.
Windows: Detaillierte Berechtigungseinträge mit Vererbung.
Windows: Besitzer des ZFS-Shares ändern.

ACLs auf der Kommandozeile prüfen

Die vom Windows-Client gesetzten Berechtigungen sind auch auf Systemebene sichtbar — mit dem Solaris-ls -V:

ls -V /fileserver/daten
-rwxrwxrwx+  1 test  cifsshare  345088 Nov 20  2010 cmd.exe
                 owner@:rwxpdDaARWcCos:------I:allow
                 group@:rwxpdDaARWcCos:------I:allow
              everyone@:rwxpdDaARWcCos:------I:allow
drwxrwxrwx+  2 test  cifsshare      12 Mär 22 17:39 de-DE
                 owner@:rwxpdDaARWcCos:fd----I:allow
                 group@:rwxpdDaARWcCos:fd----I:allow
              everyone@:rwxpdDaARWcCos:fd----I:allow

Das I in den Flags zeigt an, dass die ACL vererbt wurde — genau das, was aclinherit=passthrough bewirkt. Dateien bekommen die ACL ohne fd (keine weitere Vererbung), Ordner mit fd (Vererbung an Kinder).

Mehr zu ZFS: ZFS SMB-Freigaben mit sharesmb, ZFS NFS-Freigaben und ZFS Compression. Details zu den ACL-Flags in der Oracle Solaris ZFS Administration Guide. Fragen? Einfach melden.

Solaris ipadm

2. März 2012 / / Keine Kommentare

Veraltet: OpenIndiana und Solaris werden kaum noch eingesetzt. Wer heute einen Unix-ähnlichen Server betreiben will, ist mit FreeBSD oder Linux besser bedient.

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?

ZFS Boot Environments: Sichere Updates unter Solaris/OpenIndiana

15. Februar 2012 / / Keine Kommentare

Boot Environments (BEs) sind eine der besten Funktionen von Solaris/OpenIndiana: Vor einem Update erstellt man einen Snapshot des laufenden Systems. Geht etwas schief, bootet man einfach die alte Umgebung — kein Rollback-Stress, kein Datenverlust. Das Ganze basiert auf ZFS-Snapshots und ist mit dem Befehl beadm in Sekunden erledigt.

Boot Environments anzeigen

beadm list
BE                                     Active Mountpoint Space  Policy Created
oi_151a2-Sebastians-geht-steil-Version NR     /          14,7G  static 2012-02-14 16:18
openindiana                            -      -          26,5M  static 2011-09-28 19:06
openindiana-1                          -      -          22,6M  static 2011-10-27 20:04

N bedeutet: aktuell gebootet. R bedeutet: wird beim nächsten Reboot gestartet. NR heißt beides. Die BEs erscheinen auch im GRUB-Bootmenü.

Neue Boot Environment erstellen und aktivieren

Vor einem Update — hier ein VirtualBox-Upgrade als Beispiel:

# Neue BE anlegen (Snapshot des aktuellen Systems)
beadm create Nach-Virtualbox-Update
Created successfully

# Beim nächsten Reboot diese BE starten
beadm activate Nach-Virtualbox-Update
Activated successfully

Updates in der neuen BE installieren

Das Besondere: Man kann die neue BE mounten und dort Pakete installieren oder deinstallieren — ohne das laufende System zu berühren. Der Ausfall beschränkt sich auf den Reboot.

# Neue BE mounten
beadm mount Nach-Virtualbox-Update /mnt
Mounted successfully on: '/mnt'

# Alte Version in der neuen BE deinstallieren
pkgrm -R /mnt SUNWvbox
Removal of  was successful.

# Neue Version in der neuen BE installieren
pkgadd -R /mnt -d VirtualBox-4.1.8-SunOS-r75467.pkg
Installation of  was successful.

# BE wieder aushängen
beadm unmount Nach-Virtualbox-Update
Unmounted successfully

Nach dem Reboot startet das System in der neuen BE mit der aktualisierten Software. Funktioniert alles? Fertig. Funktioniert etwas nicht? Im GRUB die alte BE auswählen und man ist sofort zurück auf dem vorherigen Stand.

GRUB-Bootmenü mit mehreren ZFS Boot Environments unter OpenIndiana.

Aufräumen

# Alte BE löschen (wenn nicht mehr gebraucht)
beadm destroy openindiana-1
Are you sure you want to destroy openindiana-1? [y|n] y
Destroyed successfully

Alte BEs belegen nur so viel Platz wie sich seitdem geändert hat — genau wie bei ZFS-Snapshots. Trotzdem lohnt es sich, nicht mehr benötigte BEs zu löschen.

Eine Warnung

Boot Environments machen nachlässig. Man gewöhnt sich daran, dass man alles zurückrollen kann — und hört irgendwann auf, sich den vorherigen Stand zu merken oder Konfigurationsdateien vorher zu sichern. Bis man dann an einem System ohne BEs sitzt und sich fragt, warum man keine Kopie gemacht hat.

Mehr zu ZFS: ZFS Snapshots und ZFS Pool erstellen. Unter FreeBSD gibt es mit bectl ein äquivalentes Tool. Fragen? Einfach melden.

Spec-Files und Extra-Repositorys: Paketverwaltung unter Solaris optimieren

16. Oktober 2011 / / Keine Kommentare

Veraltet: OpenIndiana und Solaris werden kaum noch produktiv eingesetzt. Die hier beschriebene Paketverwaltung mit IPS und Spec-Files ist Solaris-spezifisch.

Es gibt eine ganze Hand breit Software, welche man gerne auf seinem Solaris System hätte. Nicht alle sind in den Basis Repositorys dabei

Daher gibt es das Spec Files Extra Projekt. Das OpenIndiana Projekt hat eines in ihrem Spec Files Extra Repository untergebracht. So lassen sich schnell und einfach über den Paketmanager Dinge installieren wie: Python3, PostgreSQL, Postfix, LaTeX, ffmpeg, vlc, wine……

Gut beschrieben inkl. ggf. nötiger „Workarounds“ findet man im Openindiana Wiki.

Es gibt zwei verschiedene SFE Repositorys. Eines mit Paketen bei denen die Lizenzbedingungen ein problemloses Nutzen zulässt und eines bei dem es ggf. zu Problemen kommen kann.

Wobei man hier beim in den meisten europäischen Ländern kein Problem mit den Lizenzen bekommen sollte. Jeder sollte es aber für sich selbst prüfen.

Eingerichtet ist beides wie folgt:

# pkg set-publisher -p http://pkg.openindiana.org/sfe
# pkg set-publisher -p http://pkg.openindiana.org/sfe-encumbered

Nach diesem Zweizeiler hat man nun schon die Möglichkeit die Pakete bequem per Paketmanager zu installieren.

Solaris Dual-Screen mit NVIDIA: Anleitung zur Einrichtung von zwei Monitoren​

10. Oktober 2011 / / Keine Kommentare

Veraltet: OpenIndiana und Solaris werden kaum noch als Desktop eingesetzt. Dual-Monitor-Konfiguration unter Linux erfolgt über xrandr oder die jeweilige Desktop-Umgebung.

Der OpenSolaris fork Openindiana und Dualscreen / TwinView

Solaris dual screen desktop with NVIDIA TwinView

Die automatische Konfiguration des X-Server läuft auf den meisten Systemen mehr als zuverlässig. Mir ist noch kein System unter die Finger gekommen bei welchem es wirklich ein Problem war den Xorg-Server lauffähig zu bekommen.

Ich bin seit langem schon ein Fan von Nvidia-Karten. Schuld ist da wohl die alte Firma Elsa (die vor der Pleite…)! Die Treiberunterstützung unter Linux oder Solaris ist bei Nvidia-Karten auch wunderbar. Es funktioniert einfach und sauber.

NVIDIA settings manager for dual monitors on Solaris

Jetzt habe ich also einen Arbeitsplatzrechner mit zwei Monitoren an einer Nvidia VGA Karte. Openindiana fährt hoch, erkennt die Karte, schaltet den primären Monitor ein und richtet Auslösung/Farbtiefe usw. korrekt ein. Ich kann mich anmelden und per Klickibunti ganz Windooflike unter ==> System == > Einstellungen ==> NVIDIA X-Server-Einstellungen den zweiten Monitor einfach aktivieren. Nvidias TwinView auswählen, sagen wie und wie der Monitor sein soll und fertig. Klappt alles sofort und so einfach das man weinen könnte (sofern man sich früher schon mal an so etwas probiert hat).

Dumm nur dieses bei jedem Reboot neu einstellen zu müssen. Also sollte man diese Einstellungen am besten gleich in seine xorg.conf schreiben, oder? Richtig….. Selbst dafür bieten die nvidia-settings einen Button: „Save to X Configuration File“. Dieses nun einfach noch als xorg.conf unter „/etc/X11/xorg.conf“ speichern und auch nach dem Reboot ist alles gut

Für Spaß findet man >>hier<< meine xorg.conf, auch wenn das ja so einfach ist, das es jeder schaffen sollte!

Solaris USB unmount

1. Oktober 2011 / / Keine Kommentare

Veraltet: OpenIndiana und Solaris werden kaum noch eingesetzt. Unter Linux: umount /dev/sdX, unter FreeBSD: umount /dev/daX.

Der OpenSolaris fork Openindiana und das USB mount Problem

Inzwischen ist man selbst als Unix Mensch verwöhnt von seinem GUI. Daher nerven kleinere Problemchen welche einen zwingen doch wieder die Konsole zu öffnen sehr….Openindiana unmount umount USB Stick So ging es mir mit allem was man so mal eben in die Kiste stopfen kann. Ob es nun ein USB-Stick, eine CD/DVD oder eine Wechselplatte ist. Sie wird sauber erkannt und automatisch eingebunden. Es gibt ein schönes Symbol auf dem Gnome Desktop und in dessen Dateiverwaltung. Selbst der Zugriff auf alles klappt tadellos. Aber wehe man möchte das Teil wieder los werden. Sobald man auf „Aushängen“ klickt, springt einem das System mit der GUI-Meldung an: cannot unmount volume Sehr nervig…. Konsole aufmachen, su, unmount….. Dass dieses ein Problem mit irgendeiner Berechtigung sein muss ist schnell klar, aber welcher? Google konnte mir schnell helfen. Das Problem besteht seit 147 bzw. Solaris Express, soll aber inzwischen gefixt sein. Ist es auch, nur taucht es inzwischen durch eine andere Änderung wieder auf. Das ganze ist bekannt und soll gelöst werden. Bisher gibt es einen Workaround. Einfach nachstehende Zeile in die folgende Datei packen: 
/etc/logindevperm
/dev/vt/console_user    0620    /dev/console            # workaround for defect.opensolaris.org 12133
Einen einfachen Reboot später klappt dann alles mit dem unmount per GUI.
« Ältere Beiträge Neuere Beiträge »

© 2026 -=Kernel-Error=- — RSS

Theme von Anders Norén — Hoch ↑