[Sammelthread] ZFS Stammtisch

gea schrieb:
Für OmniOS 151032 stable gibt es ein Update
Installation per "pkg update"
Neustart ist nötig
Zum Vergrößern anklicken....

Nach Update von r151028 via r151030 auf r151032 bekomme ich folgende Meldungen beim Booten:

nappit.PNG

Die Datei /etc/system habe ich mir angeschaut, die beiden Einstellungen sind nur jeweils einmal vorhanden.
Was hat diese Warning also zu bedeuten?

Und was genau bedeutet protocol not supported beim in.tftpd.
Der hat bislang problemlos funktioniert.
EDIT: in.tftpd funktioniert jetzt auch. Warum es von Win10 nicht funktioniert, weiß ich nicht, aber aus dem CentOS und meinem Cisco Phone funktioniert es.
`
Also offensichtlich nur kosmetische Probleme?
 
Zuletzt bearbeitet:
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
OmniOS setzt ahci hotplug und kürzeres Timeout seit 151030 lts per default.
Deshalb den (doppelten) Eintrag in /etc/system löschen. (passiert aber nichts weiter wenn man das so läßt)

omnios-build/ReleaseNotes.md at r151030 · omniosorg/omnios-build · GitHub

A default set of system default parameters are now installed in /etc/system.d/_omnios:system:defaults. These can be overidden if necessary by creating additional local files under /etc/system.d/.

Zu tftpd Meldung kann ich jetzt auch nichts sagen.
 
Wie bekomme ich es in nappit hin dass ich ein Dateisystem nicht jedesmal unlocken muss beim reboot?
Also mein Ziel ist dass ich bei einem reboot keinen Schlüssel eingeben möchte.
Im Grunde soll sich das ganze also "transparent" verhalten so wie mit nicht verschlüsselten Dateisystemen. Lock/unlock will ich ausschließlich manuel durchführen.
 
Bei neueren Clients (CentOS7/8) habe ich aktuelle das Problem, dass beim CIFS mounten eines ZFS Filesystems folgende Fehlermeldungen in der Console erscheinen:

Code: 
[ 1840.470034] No dialect specified on mount. Default has changed to a more secure dialect, SMB2.1 or later (e.g. SMB3), from CIFS (SMB1). To use the less secure SMB1 dialect to access old servers which do not support SMB3 (or SMB2.1) specify vers=1.0 on mount.
[ 1840.472748] CIFS VFS: buffer length 24 smaller than minimum size 28
[ 1840.473267] CIFS VFS: ioctl error in smb2_get_dfs_refer rc=-5

Wenn ich mit der Option vers=2.1 mounte, dann ist die erste Fehlermeldung weg. Die Meldung

Code: 
[ 1840.473267] CIFS VFS: ioctl error in smb2_get_dfs_refer rc=-5

bleibt allerdings.

Es handelt sich um OmniOS 151032 mit dem neuesten Update und napp-it on top.

Fragen:
Ist es richtig, dass OmniOS SMB2.1 implementiert?
Was bedeutet die zweite Fehlermeldung und was kann ich dagegen tun?

Mit vers=1.0 sind übrigens beide Fehlermeldungen weg. Ich vermute aber, dass dies nicht die beste Idee ist, oder?
Auf älteren Clients (CentOS6.5) erhalte ich diese Fehlermeldungen übrigens nicht. ggf. verwenden diese von Hause aus SMB1.0?
 
CommanderBond schrieb:
Wie bekomme ich es in nappit hin dass ich ein Dateisystem nicht jedesmal unlocken muss beim reboot?
Also mein Ziel ist dass ich bei einem reboot keinen Schlüssel eingeben möchte.
Im Grunde soll sich das ganze also "transparent" verhalten so wie mit nicht verschlüsselten Dateisystemen. Lock/unlock will ich ausschließlich manuel durchführen.
Zum Vergrößern anklicken....

Man könnte einen "other Job" mit Trigger once nehmen um das Dateisystem beim Booten zu entschlüsseln. Open-ZFS selber bietet dafür keinen Mechanismus. Man sollte den Key halt nicht lokal speichern, sonst könnte man das Verschlüsseln (Schutz bei Diebstahl) ja gleich lassen. Solala wäre ein abziehbarer USB Stick für den Key, besser ein remote Verfahren wie ein iSCSI Lun oder ein Webserver von dem man den Key per wget abruft.

- - - Updated - - -

jonofe schrieb:
Es handelt sich um OmniOS 151032 mit dem neuesten Update und napp-it on top.

Fragen:
Ist es richtig, dass OmniOS SMB2.1 implementiert?
Was bedeutet die zweite Fehlermeldung und was kann ich dagegen tun?

Mit vers=1.0 sind übrigens beide Fehlermeldungen weg. Ich vermute aber, dass dies nicht die beste Idee ist, oder?
Auf älteren Clients (CentOS6.5) erhalte ich diese Fehlermeldungen übrigens nicht. ggf. verwenden diese von Hause aus SMB1.0?
Zum Vergrößern anklicken....

OmniOS 151032 kann SMB 1, 2.1, 3.02
Das Protokoll mein Mounten angeben ist sicher gut, ansonsten eventuell dranhängen an
Topicbox
 
gea schrieb:
Man könnte einen "other Job" mit Trigger once nehmen um das Dateisystem beim Booten zu entschlüsseln. Open-ZFS selber bietet dafür keinen Mechanismus. Man sollte den Key halt nicht lokal speichern, sonst könnte man das Verschlüsseln (Schutz bei Diebstahl) ja gleich lassen. Solala wäre ein abziehbarer USB Stick für den Key, besser ein remote Verfahren wie ein iSCSI Lun oder ein Webserver von dem man den Key per wget abruft.
Zum Vergrößern anklicken....

Wieso hat es was mit OpenZFS zu tun? Letztendlich ist es doch nur eine Sache die das OS tut.
iSCSI ist für Privat bzw SOHO vielleicht etwas zuviel. Finde USB gar net so schlecht. Muss ja nicht direkt nen Stick sein der dran hängt sondern könnte auch per Kabel angebunden sein und der Stick ist im Netzwerkschrank fest verschraubt. Ein Dieb wird sich in meinen Augen eher nicht die Mühe machen einen Cent Artikel abzuschrauben dann.
Bei der Verschlüsselung hatte ich jetzt auch den Wiederverkauf der Festplatten in Blick oder RMA Sachen sprich defekten Datenträgern um da nicht irgendwem anders die Daten auszuhändigen.

Ist USB Stick in Nappit denn schon integriert oder ein Pro Feature? Weil bei der Home Version wird nur die Eingabe eines Keys angeboten.
 
Zuletzt bearbeitet:
Native ZFS Verschlüssellung ist kein Illumos oder Linux Feature sondern ein Open-ZFS Feature.

Automatische Entschlüssellung mit einem Key auf einem ZFS Pools auf dem USB Stick müsste ein "other job" Script selbsständig leisten. Napp-it unterstützt das (noch) nicht. In Entwicklung sind ein Keyserver und Ent/Verschlüssellung per SMB Share. Die USB Stick Variante kann man aber einfach selber erledigen. Ein verschlüsseltes Dateisystem mit keysource file auf der Console anlegen. Dann die Console Befehle zum ver/entschlüsseln in ein Shell-Script packen und als zwei "other Jobs" einbinden. Ent/Verschlüsseln dann durch Starten des jeweiligen Jobs (manuell, boot oder zeitgesteuert)
 
Zuletzt bearbeitet:
Man könnte sicher vieles in nappit integrieren, aber ist halt die Frage wie Aufwand zu Nutzen dabei aussieht.
Deine Anforderung ist doch etwas speziell und eher eine Nischenkonstellation.
 
Prinzipiell kann man napp-it ja auch selber anpassen, entweder durch "other jobs" mit einem Perl oder Shellscripts oder indem man die GUI selber durch private Menüs erweitert.

In dem Fall dreht es sich aber lediglich darum einen Key der als keyformat=passphrase eingegeben wurde von keylocation=prompt auf file umzustellen um ihn dann per file zu entschlüsseln. Das solle nachträglich möglich sein.

Code: 
keyformat = raw | hex | passphrase
    Controls what format the user's encryption key will be provided as. This property is only set when the dataset is encrypted.

    Raw keys and hex keys must be 32 bytes long (regardless of the chosen encryption suite) and must be randomly generated. A raw key can be generated with the following command:

    # dd if=/dev/urandom of=/path/to/output/key bs=32 count=1

    Passphrases must be between 8 and 512 bytes long and will be processed through PBKDF2 before being used (see the pbkdf2iters property). Even though the encryption suite cannot be changed after dataset creation, the keyformat can be with zfs change-key 


keylocation = prompt | file:// </absolute/file/path>
    Controls where the user's encryption key will be loaded from by default for commands such as zfs load-key and zfs mount -l This property is only set for encrypted datasets which are encryption roots. If unspecified, the default is prompt.

    Even though the encryption suite cannot be changed after dataset creation, the keylocation can be with either zfs set or zfs change-key If prompt is selected ZFS will ask for the key at the command prompt when it is required to access the encrypted data (see zfs load-key for details). This setting will also allow the key to be passed in via STDIN, but users should be careful not to place keys which should be kept secret on the command line. If a file URI is selected, the key will be loaded from the specified absolute file path.
 
Servus,
mal ne blöde Frage: Unterverzeichnisse per smb freigeben unter omnios, wie geht das?

Die Idee war das Archiv und das Share auf einem ZFS Filesystem zu haben, so das snapshots nicht wachsen wenn Dateien ins Share/Archiv verschoben werden. Das Archiv soll nur für Admins und das Share für jeden (incl Gast) lesbar (sichtbar) sein.
Das beste was ich so hinbekomme ist share/archiv und share/public als eine Freigabe mit acl so gesetzt das nur admins das archiv öffnen können.

Da gibt es doch sicher einen Weg den ich nicht gefunden habe, oder?
 
Kurzform: Du hast nichts übersehen, das geht nicht.

Langform: Mit SAMBA würde es gehen, beim kernelbasierten SMB ist Share eine Eigenschaft des Dateisystems und ist immer eine Freigabe pro Dateisystem. Du könntest zwar unter OmniOS ein Dateisystem /Tank/Share haben und ein Dateisystem /Tank/Share/Archiv. Das ist dann aber dort nur eingehängt und die verschobenen Daten wären anschließend in beiden Snapshots, was Du ja nicht willst.

Die sinnvollste Variante wäre eine Freigabe /Tank/Share. Dort ein Unterordner Archiv.
Auf diesen Unterordner dann nur Admins berechtigen.
Wenn Du noch ABEs aktivierst, sieht außer den Admins diesen Unterordner auch niemand.
Es ist dann aber halt immer noch eine Freigabe mit gemeinsamen Snapshots etc.
Vorteil beim Verschieben ins Archiv: die Daten müssen nicht per Netzwerk kopiert werden, sondern werden tatsächlich verschoben.
Um trotzdem eine "etwas getrennte Freigabe" zu haben, können die Admins aber auch Share/Archiv als separaten Laufwerksbuchstaben in Windows einbinden.
 
Danke.
Der Vorschlag ist auch gut, so sollte es funktionieren. Wenn das Archiv ein Unterverzeichnis ist ist das nicht schlimm, hat sogar den erwähnten Vorteil das Verschieben über die Freigabe funktioniert.
(vorher ware genau andersrum, das share war ein unterordner der per samba freigegeben war (unter linux noch))
 
Hi, nutze auf meinem Fileserver Solaris 11.4 mit der tollen NappIT Management Oberfläche. Darüber habe ich für ein Filesystem einen ZFS Auto Snaphot eingerichtet.

Snapshot_01.png

Seltsamerweise werden die alten Snapshots nicht gelöscht, obwohl in der Konfig 12 aufzuhebende Snaps angegeben sind. zusätzlich werden auch die leeren Snapshots nicht gelöscht.

Snapshot_02.png

Hat einer eine Idee woran das liegen könnte?
 
Ich war noch auf der 18.12, habe mal das Update auf 19.10 durchgeführt und teste die Auto Snaps nochmal. Danke für den Hinweis.
 
omnios ärgert mich :(

Sobald ich einen zpool auf meinem Backupserver auf den 16 Platten anlege stürzt der hal Dingens ab und auch home/user wird nicht mehr eingebunden, z.b. "zpool list" hängt die ganze Kiste auf.
Wahrscheinliche Ursache: ein doofer 10-port SATA Controller (oder eine von den Platten die dran hängt) wenn ich den raus baue funktioniert es wieder, aber das zpool ist natürlich kaputt wegen der fehlenden Festplatten.
Vorher war ein 4-port billig-teil drin, da hat die Kiste nicht mal bis zum Login gebootet. Das OS ist echt sehr empfindlich auf exotische/billige/consumer Hardware...

kurz: ich brauche leider einen neuen SATA Controller

Ich habe 6 onboard sata und einen asus pikeII-8i, daran müssen 16 wd red sata und 1 boot ssd (und wenn geht 1 frei für DVD-Laufwerk)
idealerweise bekomme ich den pike frei für meinen anderen Server. (also werden mindestens 12 Ports benötigt)

gleich noch eine Frage hinterher: welche bezahlbare SATA SSD eignet sich als root-Platte wenn der Server 1 mal pro Nacht eingeschalten wird und dann wieder aus geht?
 
Recht alternativlos dürften die LSI/BroadCom HBAs sein.
Ich würde nach zwei 8 Port Controller mit LSI 2008 oder 2308 Chipsatz suchen, LSI RAID Controller and HBA Complete Listing Plus OEM Models | ServeTheHome and ServeThe.Biz Forums

Gibts gebraucht teilweise recht günstig. Man muss lediglich darauf achten, dass eine IT Firmware oder IR (Raid 1/10) Firmware drauf ist. Manche wie IBM 1015 kommen mit Raid-5 Firmware, lassen sich aber umflassen. Ansonst Finger weg von allem was keinen LSI Chipsatz hat oder Raid 5/6 etc.
 
Moin!

Ich möchte meinen neuen Home-Server (OS=proxmox) auch endlich von single disk (256gb ssd) ext 4 für das system + raid6 ext4 (daten, 5x8TB WD RED) auf zfs mirror (2x 256gb ssd) system + raidz2 zfs (wd reds werden weitergenutzt) umsteigen.
Bei den Daten möchte ich eine Ausfalltoleranz von zwei haben (entsprechend bisher raid6 und zukünftig raidz2).

Spricht hier generell etwas dagegen? ECC hat der neue Server.
 
Die Speed Werte mit dem special vdev sind Wahnsinn
(Zil = Optane + special mirror /dev/sdc /dev/sdd mirror /dev/sde /dev/sdf)

ist gearde für einen großen Festplattenpool der Hammer !
 
Zuletzt bearbeitet:
Ashift kann man nur beim Anlegen/Hinzufügen eines vdevs angeben und nicht nachträglich ändern

ZFS Eigenschaften kann man ansonst abfragen mit
zfs get property Dateisystem (Dateisystem ist optional)

z.B.
zfs get recsize
zfs get recsize tank/data


ZFS Eigenschaften werden gesetzt mit
zfs set property=value Dateisystem

z.b.
zfs set recsize=256k tank/data
zfs set special_small_blocks=64k tank/data

vgl
illumos: manual page: zfs.1m
 
Ich vermute, man muss aber trotzdem aufpassen mit den Special vdevs. Wenn man VMs oder Datenbank-Tablespaces hat, wo das OS in der VM oder die DB multiblock-writes (Windows kann ja afaik bis 1M blocks wegschreiben und auch Oracle kennt Multiblock-Writes, wo nicht einzelne 8k/16k-blocks sondern nach Möglichkeit Vielfache davon geschrieben werden können, bei großen "Create Table As" oder Bulk Insert statements in DWH-Szenarien) durchführt, dann würde ZFS ggf. solche Blocks auf die langsamen vdevs ablegen.

D.h. bei solche Daten würde ich nicht via Special vdev vorgehen, sondern sowas immer auf einen expliziten schnellen Pool legen.
 
Zuletzt bearbeitet:
Das sollte egal sein.
Egal was ein Client schreibt (4k oder 1M), alles geht zunächst in den ZFS RAM-Schreibcache z.B. 4GB. Ist der zur Hälfte voll, schreibt ZFS das in recsize Blöcken auf den Pool. Ist die recsize <= small blocksize, so landet das auf den spezial vdevs andernfalls auf den normalen vdevs.
 
Zuletzt bearbeitet:
Zwischenfrage: ist die Western Digital Ultrastar DC HC510 10TB gut? Ich will 6 davon im raidz2 betreiben. (unter Omnios)
Und welche Version ist die Beste? Ich habe einen Asus PIKE II 3008 SAS Controller, also sind alle Möglichkeiten bis 12GB/s SAS offen. (meine Maus war eben suf dem Bestellbutton für 12G SAS mit 4k und ISE, aber ich habe nicht geklickt)
 
Ich habe einen Filer mit OmniOS r151032 und Napp-it. Wenn ich eine SMB-Freigabe erstelle und diese für TimeMachine nutzen möchte, funktioniert das nicht. Gibt es dafür einen Trick?
Soweit mir bekannt ist mit der r151032 ja eine neue SMB Version reingekommen, die die eigentlich für TimeMachine ausreichen müsste? Es gibt unter MacOS nur die Meldung, dass das Dateisystem relevante Optionen nicht unterstützt. Ich würde gerne meine XPENOLOGY abschalten... :-)
 
Hallo Leute,
ich mache gerade meine ersten Gehversuche mit ZFS (napp-it)
Betreibe auf meinem Dell PowerEdge T30 ein VMware vSphere Hypervisor (ESXi 6.7U3) mit HBA im IT-Mode. Wollte das "All-in-one" Szenario nachbauen.
In diesem Zuge habe ich die nappit AIO-VM (ZFS appliance v. 18.12w4 (free) am laufen.

Dummerweise habe ich mich wohl auf dem OmniOS (Konsole/ssh) "ausgesperrt". Ich kenne nicht mehr die Passwörter für "root" bzw den "napp-it".
Kann mich nicht mehr erinnern, ob ich die Passwörter überhaupt selbst mit PASSWD gesetzt habe, oder es evtl. ein DEFAULT Kennwort gibt?
Vollen Adminzugriff auf das Webfrontend mit dem User "admin" besitze ich noch.

Zu meinen Fragen:

- Wie kann ich das root-Kennwort für die Console zurücksetzen oder ändern?
- Alternativ habe ich schon überlegt, einfach ein neues OVA -Template zu deployen, allerdings würde ich dann gerne meine bisherige Konfiguration und die zRaids Pools dort "importieren/benutzen".
- Wie sichere ich meine Konfig aus dem "alten nappit-VM" ?

Über einen Tipp / Link zur Anleitung/Howto o.ä. wäre ich sehr dankbar.

VG

gravis
 
Wenn Du in die Doku siehst, liest Du, dass root standardmäßig ohne Passwort initialisiert wird.
Insofern einmal als root ohne PW anmelden und dann per passwd Passwort vergeben.
 
sashXP schrieb:
Ich habe einen Filer mit OmniOS r151032 und Napp-it. Wenn ich eine SMB-Freigabe erstelle und diese für TimeMachine nutzen möchte, funktioniert das nicht. Gibt es dafür einen Trick?
Soweit mir bekannt ist mit der r151032 ja eine neue SMB Version reingekommen, die die eigentlich für TimeMachine ausreichen müsste? Es gibt unter MacOS nur die Meldung, dass das Dateisystem relevante Optionen nicht unterstützt. Ich würde gerne meine XPENOLOGY abschalten... :-)
Zum Vergrößern anklicken....

OmniOS unterstützt zwar SMB 3.02, nicht aber alle Apple spezifischen Erweiterungen
vgl Feature #11017: Support Apple FULL_SYNC feature - illumos gate - illumos

Im Moment sehe ich nur zwei Optionen für OmniOS
1. AFP via netatalk (end of life)
2. SAMBA, Bug #10577: avahi/dns-sd not propagating services using port - OpenIndiana Distribution - illumos


Ich habe mal ein Feature Request Ticket angelegt. Vielleicht kommt da was.
Feature #12039: Kernelbased SMB should support Apple Timemachine - site - illumos
 
Zuletzt bearbeitet:
martingo schrieb:
Wenn Du in die Doku siehst, liest Du, dass root standardmäßig ohne Passwort initialisiert wird.
Insofern einmal als root ohne PW anmelden und dann per passwd Passwort vergeben.
Zum Vergrößern anklicken....

Danke das Problem, lag wohl an der ESX Remotekonsole. Ich habe es nun mit leeren Passwort hinbekommen und neu gesetzt.
 
Zuletzt bearbeitet:
Anmelden, um zu antworten.

Ähnliche Themen

G
Wieviel ZFS steckt in Qnap ZFS ??
Antworten
5
Aufrufe
880
gea
G
Shihatsu
ZFS Pool "verschicken"
Antworten
9
Aufrufe
592
sandreas
S
thor17
Ceph Node auf bestehenden ZFS Pools
Antworten
3
Aufrufe
533
gea
G
G
[Übersicht] napp-it cs, Web-GUI für fast jeden ZFS Server oder Servergruppen
4 5 6
Antworten
158
Aufrufe
9K
gea
G
AliManali
*erledigt* Perc H310 flashen
Antworten
2
Aufrufe
309
AliManali
AliManali
Hardwareluxx setzt keine externen Werbe- und Tracking-Cookies ein. Auf unserer Webseite finden Sie nur noch Cookies nach berechtigtem Interesse (Art. 6 Abs. 1 Satz 1 lit. f DSGVO) oder eigene funktionelle Cookies. Durch die Nutzung unserer Webseite erklären Sie sich damit einverstanden, dass wir diese Cookies setzen. Mehr Informationen und Möglichkeiten zur Einstellung unserer Cookies finden Sie in unserer Datenschutzerklärung.


Zurück
Oben Unten refresh