[Sammelthread] ZFS Stammtisch

[morph027]

Geht ja auch schon jetzt Proxmox kommt ja auch damit. Aktuell fehlt es halt mal an einfachen Installeren für so Geschichten wie direkt mal ein Ubuntu auf ZFS installieren. Von ZFS@LUKS reden wir ja noch gar nicht. Da muss man sich halt immer alles umständlich selber zusammenbasteln....aber snapshotting am Desktop wäre schon geil.

 

[MaxRink]

ich gehe eher davon aus, das Canonical damit böse auf die Schnauze fällt. Die Lizenzen sind und bleiben schlicht inkompatibel.

 

[besterino]

Gehen tut vieles. Aber im Kernel, von einer großen Distri, das macht Hoffnung. Die Lizenzthematik ist für mich an dieser Stelle Sekundär.

 

[Digi-Quick]

ich denke die nutzen eher ZoL - wie andere Linuxe auch.
ZFS On Fuse ist seit gut 2 oder 3 Jahren Geschichte!

Eine direkte Kernelintegration ist ZoL aber auch nicht, davon steht im verlinkten Artikel auch nichts - nur das es fest im System integriert wird.
ZoL läuft halrt als Kerneltreiber im Kernel Mode und nicht mehr im Userland wie ZFS on Fuse.

 

[supemole]

Ich habe eine Frage zum Upgrade Vorgehen bei OmniOS Versionen.

Ich betreibe eine OmniOS Stable r151016. Das System ist Member einer Windows Domain und es gibt zahlreiche ZFS-Filesysteme mit entsprechenden Shares. Nutzer greifen mit Windows und Mac Clients über CIFS zu. Es gibt keine iSCSI Volumes. Wenn die neue Stable r151018 kommt, möchte ich gerne auf diese Version upgraden um SMB 2.1 zu nutzen. Dazu habe ich folgendes Vorgehen gedacht:

1. System aus der Windows Domain entfernen
2. Pool exportieren
3. Neue Stable r151018 als neues Betriebsystem installieren, d.h. die alte Version wird vollständig überschrieben (Neuinstallation)
4. Neues System in die Windows Domain aufnehmen
5. Pool importieren

Ist das ok bzw. geht es einfacher oder besser?

 

[zos]

Ich habe eine Frage zum Upgrade Vorgehen bei OmniOS Versionen.

Ich betreibe eine OmniOS Stable r151016. Das System ist Member einer Windows Domain und es gibt zahlreiche ZFS-Filesysteme mit entsprechenden Shares. Nutzer greifen mit Windows und Mac Clients über CIFS zu. Es gibt keine iSCSI Volumes. Wenn die neue Stable r151018 kommt, möchte ich gerne auf diese Version upgraden um SMB 2.1 zu nutzen. Dazu habe ich folgendes Vorgehen gedacht:

1. System aus der Windows Domain entfernen
2. Pool exportieren
3. Neue Stable r151018 als neues Betriebsystem installieren, d.h. die alte Version wird vollständig überschrieben (Neuinstallation)
4. Neues System in die Windows Domain aufnehmen
5. Pool importieren

Ist das ok bzw. geht es einfacher oder besser?

Das ist ja dann eher eine Neuinstallation als ein Upgrade. Ein Upgrade sollte mit

/usr/bin/pkg unset-publisher omnios
/usr/bin/pkg set-publisher -P --set-property signature-policy=require-signatures -g [url]http://pkg.omniti.com/omnios/r151018/[/url] omnios
/usr/bin/pkg update

zu erledigen sein. Das ist, etwas ausführlicher, auch hier beschrieben.

 

[supemole]

Das ist ja dann eher eine Neuinstallation als ein Upgrade.

Stimmt natürlich, ist eher kein Upgrade. Ich möchte gerne hohe Sicherheit, dass ich danach nicht schrauben muss und alles weiterhin läuft. Vielen Dank für die Hinweise.

 

[zos]

Stimmt natürlich, ist eher kein Upgrade. Ich möchte gerne hohe Sicherheit, dass ich danach nicht schrauben muss und alles weiterhin läuft. Vielen Dank für die Hinweise.

Gut, aber ein Upgrade kannst Du doch risikolos ausprobieren. Legst Du halt vorher ein BootEnvironment an, auf dass Du zurück gehst, falls es durch das Upgrade zu irgendwelchen Seiteneffekten kommt. Eine Neuinstallation ist mMn schon etwas aufwändiger, die kannst Du dann ja ggf. immer noch machen.

 

[supemole]

Gut, aber ein Upgrade kannst Du doch risikolos ausprobieren. Legst Du halt vorher ein BootEnvironment an, auf dass Du zurück gehst, falls es durch das Upgrade zu irgendwelchen Seiteneffekten kommt. Eine Neuinstallation ist mMn schon etwas aufwändiger, die kannst Du dann ja ggf. immer noch machen.

Genau das werde ich machen, ich habe mir die Beschreibung gerade genauer durchgelesen. Besten Dank!

 

[Handle]

Eine kleine Frage zum Verhalten des Pool wenn ich compression und dedup nachträglich einschalte. Werden bereits bestehende Daten automatisch im Hintergrund gededupt und kompriert oder muss ich das für bestehende Daten manuell anstoßen?

Dedup lohnt sich aber nur in Ausnahmefällen, also wenn die Daten wirklich hauptsächlich aus Duplikaten bestehen. Der Ressourcenverbrauch dafür ist enorm und lohnt sich selten.

 

[fdiskc2000]

Ich versuche mich gerade am manuellen Backup über das LAN und verstehe nicht, warum es nicht klappt. Folgende Situation:

Quellserver:


Zielserver:


Mein Befehl:


Was mache ich denn hier falsch? Danke für Eure Unterstützung

 

[besterino]

Standard
Bin kein Experte, aber ich habe immer nur Datasets repliziert, Du machst das mit einem ganzen Pool (weiss gar nicht, ob das geht).

Ansonsten: was auch nicht geht ist send/receive zwischen aktuellem Solaris (11.3) und nicht-Solaris wie OmniOS & Co.

Ich such mal noch das HowTo, mit dem ich das seinerzeit manuell hinbekommen hatte...

Ansonsten napp-it extension holen das ist soooooo komfortabel...

- - - Updated - - -

Hab ihn gefunden: das hat mit am meisten geholfen - hatte das dann für meine Zwecke etwas abgewandelt, wie genau weiss ich aber gar nicht mehr.

https://dan.langille.org/2013/07/25/2405/

 

[fdiskc2000]

Danke Dir für den Link. Also beides ist omni OS, auch gerade eben noch mit pkg update aktualisiert.
Mit einem einzelnen Datatset gleicher Fehler. Manchmal ist man ja auch nur zu doof: nach dem Fehler gegoogelt kommt, das der ssh login nicht klappt. Und der manuell probiert geht wirklich nicht. Wobei ich nicht ganz begreife was da das Problem ist: vom lokalen Rechner komme ich auf beide Server drauf, aber von Server1 auf Server2 geht kein ssh.

 

[millenniumpilot]

Hallo Gea,

da meine verwendete OmniOS-Installation schon ziemlich altbacken war und ich auf SMB2.1 wert lege (MS Office macht sonst Probleme beim Arbeiten direkt auf Netzwerkshares) habe ich heute meine VM neu installiert.
Verwendet wurde OmniOS r151017. OmniOS installiert, dann upgedatet und Nappit 16.02 installiert. Dank vorzüglicher Dokus kein Problem.

Die Napp-it Konfiguration der alten Installation wurde mit Deinem eingebauten Backupscript gesichert.
Anschließend wurden die Daten aus backup napp-it/etc und var zurückkopiert.
Aus dem Folder backup napp-it/web-gui wurden nur die Ordner _my und _log zurück kopiert., da ja schon eine funktionsfähige Installation vorhanden ist und beide Versionsstände gleich sind.
Aber wo gehören die Dateien aus dem Order "settings" hin, sprich die Dateien idmap.log und smbgroups.log?

Im Augenblick habe ich den Stand, das meine Jobs alle wieder vorhanden sind und auch die SMB-User.
Die SMB-Groups fehlen aber alle.
Gibt es eine aktuelle Anleitung, was alles wohin kopiert werden muss, um die komplette Konfiguration wieder herzustellen?
Ich möchte ungern das gesamte Filesystem neu verrechten müssen.

Hast Du noch einen Hinweis oder jemand anderes schon Erfahrung beim Restore einer Nappit-Konfig?

 

[bogomil22]

Hallo Gea,

da meine verwendete OmniOS-Installation schon ziemlich altbacken war und ich auf SMB2.1 wert lege (MS Office macht sonst Probleme beim Arbeiten direkt auf Netzwerkshares) habe ich heute meine VM neu installiert.
Verwendet wurde OmniOS r151017. OmniOS installiert, dann upgedatet und Nappit 16.02 installiert. Dank vorzüglicher Dokus kein Problem.

Die Napp-it Konfiguration der alten Installation wurde mit Deinem eingebauten Backupscript gesichert.
Anschließend wurden die Daten aus backup napp-it/etc und var zurückkopiert.
Aus dem Folder backup napp-it/web-gui wurden nur die Ordner _my und _log zurück kopiert., da ja schon eine funktionsfähige Installation vorhanden ist und beide Versionsstände gleich sind.
Aber wo gehören die Dateien aus dem Order "settings" hin, sprich die Dateien idmap.log und smbgroups.log?

Im Augenblick habe ich den Stand, das meine Jobs alle wieder vorhanden sind und auch die SMB-User.
Die SMB-Groups fehlen aber alle.
Gibt es eine aktuelle Anleitung, was alles wohin kopiert werden muss, um die komplette Konfiguration wieder herzustellen?
Ich möchte ungern das gesamte Filesystem neu verrechten müssen.

Hast Du noch einen Hinweis oder jemand anderes schon Erfahrung beim Restore einer Nappit-Konfig?

Falls man ein Feature Request an gea stellen darf und er mal Zeit findet:
Ich fände es auch super wenn es in NappIt ein menü-punkt gäbe wie "Restore from napp-it-backup" sodass Nappit automatisch das Backup bzw die dateien/ordner zurückkopiert. (z.B. den service von nappit stoppen, dann mit 'cp' die dateien zurückkopieren und service wieder starten).

Ansonsten nutze ich die Gelegenheit und bedanke mich nochmal bei gea für den mega support im Forum und vorallem NappIt kostenfrei bereitzustellen!!!!! Ich glaube da spreche ich für viele Nutzer.

 

[gea]

Die Logfiles sind die Ausgabe von "smbadm show" und "idmap list"

Ersteres kann man nutzen um die SMB Gruppen wieder anzulegen,
zweiteres um ein optionales Mapping von SMB Gruppen auf Unix Gruppen oder
von AD Usern auf Unix User wieder anzulegen (z.B. AD administrator=root)

Ein Restore Menü mit einem vorherigen Systemsnap ist auf meiner todo Liste

 

[fdiskc2000]

@gea: hast Du auch eine Idee zu meinem SSH-Problem wegen dem send/receive?

 

[millenniumpilot]

Die Logfiles sind die Ausgabe von "smbadm show" und "idmap list"

Ersteres kann man nutzen um die SMB Gruppen wieder anzulegen,

Hallo Gea,

kannst Du bitte ganz kurz schreiben, was ich als Befehlszeile mit den Infos aus dem file smbgroup.log eingeben muss?

Wäre Dir echt dankbar.

Edit: sind die lokalen User auch schon in den Gruppen oder muss ich diese neu Aufnehmen?
Edit2: benötige ich die SID auch oder reicht ein smbadm create "gruppe"?

 

[gea]

Usermanagement auf der Console
https://docs.oracle.com/cd/E19120-01/open.solaris/820-2429/smbadmcommand/index.html

Das Logfile aus dem Backup listet die Gruppen auf


Idmapping auf der Console
https://docs.oracle.com/cd/E23824_01/html/821-1449/mapusergroupidentities.html

Das Logfile zeigt die Mappings z.B.
add -d wingroup:mitarbeiter undixgroup:staff
Wenn man da ein idmap davorschreibt, hat man schon den Befehl um das wieder anzulegen

SMB-Gruppen anlegen/ verwalten und Idmappings ginge auch über das Menü "User"

 

[millenniumpilot]

Hallo Gea,

also mit den Infos aus smbgroups.log alle Gruppen manuell neu anlegen. <reine Fleißarbeit>
Wenn ich das über das Menü User machen, wird das Mapping auf Unixgroups sowieso automatisch erledigt. Das Mapping mit add -d ist dann nicht mehr notwendig!
Benötige ich die SIDs noch für irgendetwas?

Die Zuordnung User zu SMB-Gruppen ist aber weg... oder?!

Werden die neu angelegten SMB-Gruppen als die alten Gruppen auf den Filesystemen der Pools erkannt?
Ich arbeite im Workgroupmodus, also nur mit lokalen Gruppen und Usern, keine AD mehr im Rücken.

 

[Pac2]

Hi,

auf meinem NAS läuft OmniOS und Napp-It.

Komischerweise geht der MC nicht.

-bash: mc: command not found

Versuche Ich den MC zu installieren, kommt nur eine Meldung das kein Update erforderlich ist.

pkg install mc
No updates necessary for this image.

Hat jemand eine Idee? Ich stehe gerade etwas auf dem Schlauch.

Vielen Dank

 

[gea]

Mapping braucht man generell nur, wenn man mit den gleichen Accounts mit SMB und anderen Unix Diensten arbeiten möchte. Ansonsten sollten die Rechte funktionieren, wenn man mit dem gleichen Hostnamen, gleichen Usern (uid/gid) und SMB Gruppen weiterarbeitet (Ich habe das mal früher getestet, aktuell ist bei mir alles auf Active Directory).

Die Gruppenmitgliedschaften werden momentan nicht mitgesichert, werde ich noch anpassen. Sun hat halt über die Jahre wahnsinnig viel in Solaris eingebaut. Da geht nicht alles auf einmal per GUI zu managen.

- - - Updated - - -

Hi,

auf meinem NAS läuft OmniOS und Napp-It.

Komischerweise geht der MC nicht.

-bash: mc: command not found

Ein
ln -s /opt/csd/bin/mc /bin/mc sollte das Problem beheben.
Im aktuellen wget Installer mache ich das auch.

Ursache
Die Installation über das Repository der Uni Maryland geht derzeit in /opt/csd/bin ohne einen Link zu setzen.
Alternativ mc mit /opt/csd/bin/mc starten

 

[fdiskc2000]

Also mein SSH Problem scheint irgendwie von der NappIT OVA-Vorlage zu kommen. Das darin enthaltene omniOS scheint trotz einem pkg update eine ältere SSH Version? zu nutzen als meine gestern noch gezogene omniOS Installation, die jetzte direkt auf der Hardware (N40L) läuft.
Der Fehler besagt ja wohl, das beide SSH Seiten sich nicht auf einen Algorithmus einigen könne, da jede andere unterstützt. Die aus der OVA-Vorlage nur 2 ältere.

Hat jemand eine Idee, wie ich die beiden dazu bringe miteinander zu reden?
Beide vertragen sich zumindest mit FreeNAS 9.3, wo dann auch das ZFS send/receive klappt.

 

[millenniumpilot]

Hallo Gea,

danke. Etwas schlauer als vorher.

ich hoffe, ich kann die Frage richtig stellen:
Woran machen die ACLs des bestehenden Pools die Gruppenzugehörigkeit fest? Müssen die neu angelegten SMB-Gruppen den gleichen Namen oder die gleiche GID haben? Oder beides?
Leider funktioniert bei meinen Systemen kein ls -v oder ls -V, so dass ich da nicht weiterkomme mit meiner eigenen Fehlersuche.
getacl und getfacl funktionieren auch nicht.

 

[gea]

Also mein SSH Problem scheint irgendwie von der NappIT OVA-Vorlage zu kommen. Das darin enthaltene omniOS scheint trotz einem pkg update eine ältere SSH Version? zu nutzen als meine gestern noch gezogene omniOS Installation, die jetzte direkt auf der Hardware (N40L) läuft.
Der Fehler besagt ja wohl, das beide SSH Seiten sich nicht auf einen Algorithmus einigen könne, da jede andere unterstützt. Die aus der OVA-Vorlage nur 2 ältere.

Hat jemand eine Idee, wie ich die beiden dazu bringe miteinander zu reden?
Beide vertragen sich zumindest mit FreeNAS 9.3, wo dann auch das ZFS send/receive klappt.

OmniOS stellt von SunSSH auf OpenSSH um.
Eventuell liegts daran. Am Besten auf beiden Servern die gleiche OmniOS Version einsetzen

ReleaseNotes/r151016

- - - Updated - - -

Hallo Gea,

danke. Etwas schlauer als vorher.

ich hoffe, ich kann die Frage richtig stellen:
Woran machen die ACLs des bestehenden Pools die Gruppenzugehörigkeit fest? Müssen die neu angelegten SMB-Gruppen den gleichen Namen oder die gleiche GID haben? Oder beides?

GID ist dem Solaris SMB Server eigentlich egal. Es zählt nur die Windows SID.
Bei gleichem Hostname, Username und UID/GID sollte aber die Windows SID gleich bleiben.

Leider funktioniert bei meinen Systemen kein ls -v oder ls -V, so dass ich da nicht weiterkomme mit meiner eigenen Fehlersuche.
getacl und getfacl funktionieren auch nicht.

Solaris benutzt im default Path die GNU tools (wie Linux). Die könnern abet keine nfs4 ACL, getacl und getfacl sind auch obsolet da die auch keine Solaris ZFS/nfs4 ACL können. Das ist historisch bedingt. Hat halt seit 15 Jahren keiner geändert.

Die richtigen Tools für Solaris ZFS sind
/usr/bin/ls oder /usr/bin/chmod

vgl https://docs.oracle.com/cd/E18752_01/html/819-5461/gbabw.html

 

[Pac2]

Ein
ln -s /opt/csd/bin/mc /bin/mc sollte das Problem beheben.

Vielen Dank

 

[fdiskc2000]

OmniOS stellt von SunSSH auf OpenSSH um.
Eventuell liegts daran. Am Besten auf beiden Servern die gleiche OmniOS Version einsetzen

ReleaseNotes/r151016

Danke ein Upgrade hatte nicht geholfen und ich bin zu ungeschickt, den SSH Teil zu tauschen. Habe jetzt eine neue eigene VM installiert, etwas holprig und auch noch nicht ganz rund, aber ssh unter den Maschinen geht jetzt.

 

[CommanderBond]

Kann man eigentlich einen onboard SATA Controller "durchreichen" an OmniOS wenn man ein NAS virtualisieren möchte? z.B. mittels Exsi? Oder muss das zwingend immer eine pcie Steckkarte sein? Die Container für die VMs sollen dann auf eine NVMe, in dem Fall wäre der SATA Controller ja frei oder klappt das nicht weil er onboard ist?

 

[morph027]

Wird schon gehen, ist auch meist ein PCI Gerät. Darf nur nix dran hängen,was das laufende System nutzt.

 

[millenniumpilot]

Hallo Gea und andere,

konnte weitere Tests durchführen, um eine OmniOS- und Nappit-Neuinstallation mit anschließender Konfigurationsübernahme durchzuführen.

Der Filer arbeitet im Workgroupmodus, bei AD-Integration existiert das Problem nicht.
Problem: nach dem Einspielen der Backup-Napp-it Sicherung waren zwar alle Nappit-Einstellungen wieder hergestellt und auch die SMB-User wieder vorhanden, aber leider nicht die SMB- und Unixgruppen für die Rechtevergabe auf das Storagefilesystem.

In den ACLs des Pools stehen die Unixgruppennummern. Werden die SMB-Gruppen auf dem neuen System einfach nach Laune angelegt, stimmt die Zuordnung im Filesystem nicht mehr. Plötzlich hat die Gruppe "FilmeRW" Zugriff anstatt die Gruppe "GeheimR"

Also vorher in der alten Installation unter Benutzer->Unixgroups die Zuordnungen gruppenname zu group-id notieren. Aktuell fangen die Gruppennummern mit 100 an.
Auf dem neuen System die SMB-Gruppen in genau der selben Reihenfolge wie im Altsystem anlegen und die group-id kontrollieren!!!!
Anschließend stimmen auch im Filesystem die SMB-Gruppen-Zuordnungen.
Was bleibt ist noch die Neuzuordnung der SMB-User zu den SMB-Gruppen, dies muss aktuell auch von Hand vorgenommen werden.
Leider habe ich bisher im Filesystem noch keine Auflistung hierfür finden könne, bin also auf mein Gedächtnis angewiesen.

Hoffe diese Info hilft anderen....

PS: bis vor 1 Woche lief der Filer noch im AD-integrierten Modus und wurde jetzt erst auf den Workgroupmodus umgestellt. Wenn ich das vorher geahnt hätte....