[Sammelthread] ZFS Stammtisch

Schreibleistung = eine Platte pro Mirror
Leseleistung = die Summe aller Platten

Kurzum, mit 3er Mirrors reduzierst du die Schreibleistung bei unveränderter Leseleistung. Natürlich abhängig davon wie die Daten über die Mirror verteilt sind.
 
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
1. Da ZFS gleichzeitig von allen Platten lesen/schreiben kann, ergibt sich bei einer ersten Betrachtung
n-way mirror: Schreibleistung wie eine Platte, Leseleistung n * eine Platte. Ein 3way Mirror ist also beim Lesen 3 * so schnell wie eine Platte, 2way nur doppelt so schnell (Datenblock gelesen wenn irgendeine Platte liefert) und beim Schreiben immer wie eine Platte (jede Platte muss Datenblock geschrieben haben bis ok)

2. Nur SAS arbeitet voll Duplex, Sata nur Halbduplex. Bei gleichzeitigem Lesen/Schreiben kann die Schnittstelle einen Unterschied machen. Bei SSD auch noch ob man 12/24G SAS oder nur 6G SAS/Sata hat. Bei SAS kann man mit 2*12G mpio zusätzlich Performance herausholen. Bei napp-it und einem Pool > Benchmark sieht man das gut beim Filebench singlestreamread vs fivestreamread

3. Bei unbalanced Mirrors (ungleichmäßiger Füllgrad) kann das Ergebnis schlechter sein, auch skaliert ZFS nicht linear mit der Anzahl der vdevs sondern der tatsächliche Leistungszuwachs nimmt mit der Anzahl der vdev Mirrors ab und erreicht nicht das rechnerische Maximum.
 
Zuletzt bearbeitet:
Hallo zusammen,

jetzt hätte ich ich auch mal eine Frage; Ich möchte meinen RaidZ2 Pool mit 4x1TB komplett gegen 4x2TB tauschen ohne den Pool neu zu erstellen.
Ich habe jetzt diverse Seiten gegoogelt, der Parameter autoexpand ist gesetzt:

# zpool get autoexpand tank
NAME PROPERTY VALUE SOURCE
tank autoexpand on local
# zpool get autoreplace tank
NAME PROPERTY VALUE SOURCE
tank autoreplace off default
#

Ich habe das jetzt so verstanden, dass wenn ich alle Platten nacheinander gegen größere tausche, dass die Kapazität dann automatisch größer wird (z.B. hier beschrieben https://tomasz.korwel.net/2014/01/03/growing-zfs-pool/ )

Ist das so richtig ?
Zum Thema Resilvern: Ist ja ein RaidZ2, könnten da nicht zwei HDDs gleichzeitig getauscht werden ?

Viele Grüße,
DJ
 
Mit jeder aktiven HDD die Du ziehst, verlierst Du an Redundanz. Ziehst Du 2 aktive Platten eines Raidz2, hast Du damit gar keine Redundanz mehr. Fällt Dir dann eine HDD aus > goodbye data.
-> Aktive Disks eines Zpools zu ziehen und ihn damit "degraded" hinterlassen ist daher eine schlechte Vorgehensweise. Manche User gehen das Risiko ein, damit temporär eine von zwei Redundanzdaten zu verlieren.
Bei den heutigen Multi-TB-Disks, speziell bei Consumer-Disks, eine schlechte Idee aufgrund der statistischen Fehlerwahrscheinlichkeiten.

Richtige Vorgehensweise:
Du ersetzt daher Disks/SSDs eines Zpool, indem Du diese erstmal einsteckst. D.h. Du brauchst einen freien Port.
Dann weist Du ZFS per ZFS REPLACE-Befehl an (ggf. nach Vorbereitung der Disk wie ggf. Partitionierung wenn man ZFS auf GPT-Partitionen legen will, etc), eine Disk eines Pools durch eine andere zu ersetzen. ZFS wird daraufhin die Daten der zu ersetzenden Disk auf die neue Disk schieben.
Wenn das durch ist, nimmst Du die ursprüngliche offline und kannst sie ziehen.

Damit behältst Du stets das Redundanz-Level eines Pools und riskierst keinerlei Daten durch ausfallende Disks. Ob ZFS das für mehrere HDD gleichzeitig tun kann, hab ich noch nicht probiert; ich würde es vermuten.
Hast Du Autoexpand an (vorher prüfen bzw. einschalten) wird der Pool dann mit Ersetzen der letzten Disk den zusätzlichen Speicher verfügbar haben.
 
Zuletzt bearbeitet:
Mit jeder aktiven HDD die Du ziehst, verlierst Du an Redundanz. Ziehst Du 2 aktive Platten eines Raidz2, hast Du damit gar keine Redundanz mehr. Fällt Dir dann eine HDD aus > goodbye data.

Du ersetzt daher Disks/SSDs eines Zpool, indem Du diese erstmal einsteckst. D.h. Du brauchst einen freien Port.
Dann weist Du ZFS per ZFS replace-Befehl an, eine Disk durch eine andere zu ersetzen. ZFS wird daraufhin die Daten der zu ersetzenden Disk auf die neue Disk schieben.
Wenn das durch ist, nimmst Du die ursprüngliche offline und kannst sie ziehen.

Damit behältst Du stets das Redundanz-Level eines Pools und riskierst keinerlei Daten.
Okay, das ergibt Sinn, auch wenn ich vor dem Replace noch ein komplettes Backup des Pools mache. Mit zpool replace habe ich mich schon ein wenig eingelesen, leider hat Truenas meine Platten im Pool nicht eindeutig benannt:

pool: tank
state: ONLINE
scan: scrub repaired 0B in 02:44:37 with 0 errors on Sun Oct 9 02:44:39 2022
config:

NAME STATE READ WRITE CKSUM
tank ONLINE 0 0 0
raidz2-0 ONLINE 0 0 0
gptid/735c7830-81c3-11eb-9436-00199998a157 ONLINE 0 0 0
gptid/743e2f3c-81c3-11eb-9436-00199998a157 ONLINE 0 0 0
gptid/7448165d-81c3-11eb-9436-00199998a157 ONLINE 0 0 0
gptid/7475b349-81c3-11eb-9436-00199998a157 ONLINE 0 0 0
logs
mirror-1 ONLINE 0 0 0
gpt/zlog0 ONLINE 0 0 0
gpt/zlog1 ONLINE 0 0 0
cache
gpt/l2arc0 ONLINE 0 0 0
gpt/l2arc1 ONLINE 0 0 0

errors: No known data errors

Ich gehe hier aber davon aus, das ich den Pool falsch erstellt habe. Ich denke, ich habe den Pool seinerzeit manuell erstellt weil man über das Frontend von Freenas kein RaidZ2 erstellen konnte, bin mir aber nicht sicher.
Der L2ARC/ZIL verschwindet noch, der ist oversized für mich. Wie kann ich denn rausfinden, welche Platte welche ist ?
 
Mal eine Grundlagenfrage

Gegeben sind zwei Platten, die sollen im Raid1 laufen und verschlüsselt sein. Am Ende muss ZFS stehen um es in Proxmox einzubinden. Das Crypt von ZFS will ich nicht verwenden.
Stellt sich nun die Frage was mehr CPU bzw. IO frisst:
- mdraid mit luks und darauf das zfs
- 2 mal luks und darauf zfs mirror

Hat da schon jemand Erfahrungen?
Wie sieht dann eigentlich die Blocksize in Proxmox aus. Beim RAIDZ1 wäre minimum 16k, aber bei mirror noch 8k oder?

Vielen Dank im Voraus
 
Ich benutze native ZFS Verschlüsselung schon seit Jahren ohne Probleme, deswegen interessieren mich deine Bedenken, die einzusetzen?
Alleine schon wegen der Möglichkeit, verschlüssele Snapshots zu übertragen, ohne am Zielsystem den Schlüssel zu kennen.
Flexibler und performanter wirds nicht.

cu
 
Nach dem was ich gelesen habe, verschlüsselt ZFS nicht alles. Diverse Metadaten und Filenamen wären davon nicht erfasst.
Dazu gibt es angeblich Probleme beim automatischen öffnen mit einem Keyfile, die konnte ich aber in meinem Fall nicht bestätigen. Betrifft wohl nur das Booten von ZFS, das brauche ich aber nicht.
 
Ich schlage vor, du liest dich nochmal ein wenig ein. Deine Informationen bezüglich was alles nicht verschlüsselt wird, ist falsch.
Nicht verschlüsselt sind dataset properties (quasi die config) und snapshot namen.
Solange du keine Snapshots per Hand erstellst mit @hierstehtwasgeheimesdrin bist du save.
Die Frage, wo die passphrases aufzubewahren sind, musst du dir auch mit luks überlegen.

cu
 
@gea
Nach dem Update von napp-it 22.03b auf 22.06a ist die GUI "nicht" mehr aufrufbar. Hat das was mit dem angekündigtem Wechsel auf apache zu tun?
Das ganze unter Solaris 11.4 CBE. Es findet sich dann noch ein rudimentärer http (der alte mini_httpd?) unter Port 81, der auch Werbung für Apache auf 80, bzw. 443 macht,
aber aufrufen lässt sich unter diesen Ports irgendwie nichts. Als wenn der apache gar nicht laufen würde.

Muss man nach dem Update noch irgendwas spezielles beachten oder tun, damit es funktioniert? Bin erst mal wieder auf die alte BE zurück.

Viele Grüße
 
Auf meinem N40L startet die GUI / napp-it nicht mehr automatisch.

Hast Du es mal auf der Kommandozeile manuell gestartet?

on start problems after an update (or if you have forgotten to install Apache first), run:
/etc/init.d/napp-it start
 
Ich hatte es mal mit '/etc/init.d/napp-it restart' versucht, aber das Bild hatte sich dadurch irgendwie nicht verändert.
Es sei denn, dass sich start anders als restart verhalten würde, müsste ich gegebenenfalls auch noch mal testen.
 
Ab v22.06 wird für https in OmniOS und Solaris Apache genutzt.
Falls die Gui nach dem Update nicht startet:

1. Webserver neu starten: /etc/init.d/napp-it restart oder reboot

wenn das nicht hilft, kontrollieren ob Apache installiert ist:
pkg install server/apache-24
pkg install library/security/openssl

Anschließend sollte auch unter Solaris 11.4cbe Apache installiert sein
(wird normalerweise durch wget installer installiert, /usr/apache2/2.4/bin/apachectl)

dann: /etc/init.d/napp-it restart

ohne https kann man weiter wie bisher über Port 81 zugreifen,
mit Apache zusätzlich auch auf Port 80, https dann auf dem normalen Port 443
 
Habe jetzt noch mal geschaut, zusätzliche Pakete wollte er nicht installieren, da ergab es beim resolver
kein weiteres todo. Allerdings bin ich auf folgenden Fehler im logfile gestossen. Er findet offenbar das Verzeichnis
nicht, wo er das PID file anlegen will/soll. Ich habe mal testweise unterhalb von /var/run die weiteren
Ordner .../apache2/2.4/ angelegt. Restartet man napp-it dann noch mal, verschwindet der [core:error]
im log und die Prozesse scheinen dann auch aktiv zu sein.

Code:
root@storage01:/var/apache2/2.4/logs# cat error_log
[Fri Oct 28 23:42:52.529914 2022] [ssl:warn] [pid 2340:tid 1] AH01906: 127.0.0.1:443:0 server certificate is a CA certificate (BasicConstraints: CA == TRUE !?)
[Fri Oct 28 23:42:52.529991 2022] [ssl:warn] [pid 2340:tid 1] AH01909: 127.0.0.1:443:0 server certificate does NOT include an ID which matches the server name
[Fri Oct 28 23:42:52.552780 2022] [ssl:warn] [pid 2342:tid 1] AH01906: 127.0.0.1:443:0 server certificate is a CA certificate (BasicConstraints: CA == TRUE !?)
[Fri Oct 28 23:42:52.552855 2022] [ssl:warn] [pid 2342:tid 1] AH01909: 127.0.0.1:443:0 server certificate does NOT include an ID which matches the server name
[Fri Oct 28 23:42:52.554482 2022] [core:error] [pid 2342:tid 1] (2)No such file or directory: AH00099: could not create /var/run/apache2/2.4/httpd.pid.MDBIQd
[Fri Oct 28 23:42:52.554568 2022] [core:error] [pid 2342:tid 1] AH00100: httpd: could not log pid to file /var/run/apache2/2.4/httpd.pid
[Fri Oct 28 23:42:52.555209 2022] [cgid:error] [pid 2343:tid 1] (2)No such file or directory: AH01243: Couldn't bind unix domain socket /var/run/apache2/2.4/cgisock.2342
[Fri Oct 28 23:45:44.357921 2022] [ssl:warn] [pid 2679:tid 1] AH01906: 127.0.0.1:443:0 server certificate is a CA certificate (BasicConstraints: CA == TRUE !?)
[Fri Oct 28 23:45:44.358022 2022] [ssl:warn] [pid 2679:tid 1] AH01909: 127.0.0.1:443:0 server certificate does NOT include an ID which matches the server name
[Fri Oct 28 23:45:44.382108 2022] [ssl:warn] [pid 2680:tid 1] AH01906: 127.0.0.1:443:0 server certificate is a CA certificate (BasicConstraints: CA == TRUE !?)
[Fri Oct 28 23:45:44.382196 2022] [ssl:warn] [pid 2680:tid 1] AH01909: 127.0.0.1:443:0 server certificate does NOT include an ID which matches the server name
[Fri Oct 28 23:45:44.386176 2022] [mpm_event:notice] [pid 2680:tid 1] AH00489: Apache/2.4.51 (Unix) OpenSSL/1.0.2za configured -- resuming normal operations
[Fri Oct 28 23:45:44.386326 2022] [core:notice] [pid 2680:tid 1] AH00094: Command line: '/usr/apache2/2.4/bin/httpd -f /var/web-gui/data/tools/httpd/apache24/solaris/config/httpd.conf'
chmod: WARNING: can't access /tmp/nappit/htm
chmod: WARNING: can't access /tmp/nappit/htm
root@storage01:/var/apache2/2.4/logs# netstat -an | grep 443
      *.443                *.*                  0      0 2097152      0 LISTEN
192.168.1.94.443     192.168.1.10.58871   2102272      0 2098020      0 ESTABLISHED
192.168.1.94.443     192.168.1.10.58889         0      0 2098020      0 SYN_RCVD
      *.443                             *.*                               0      0 2097152      0 LISTEN
root@storage01:/var/apache2/2.4/logs#

Nach 'nem Reboot läuft der apache dann aber wieder nicht und das error.log setzt sich wie folgt fort:
Code:
[Fri Oct 28 23:52:47.001572 2022] [core:warn] [pid 2680:tid 1] AH00045: child process 2682 still did not exit, sending a SIGTERM
[Fri Oct 28 23:56:24.191462 2022] [ssl:warn] [pid 1142:tid 1] AH01906: 127.0.0.1:443:0 server certificate is a CA certificate (BasicConstraints: CA == TRUE !?)
[Fri Oct 28 23:56:24.191729 2022] [ssl:warn] [pid 1142:tid 1] AH01909: 127.0.0.1:443:0 server certificate does NOT include an ID which matches the server name
[Fri Oct 28 23:56:24.211694 2022] [ssl:warn] [pid 1143:tid 1] AH01906: 127.0.0.1:443:0 server certificate is a CA certificate (BasicConstraints: CA == TRUE !?)
[Fri Oct 28 23:56:24.211783 2022] [ssl:warn] [pid 1143:tid 1] AH01909: 127.0.0.1:443:0 server certificate does NOT include an ID which matches the server name
[Fri Oct 28 23:56:24.214909 2022] [cgid:error] [pid 1144:tid 1] (2)No such file or directory: AH01243: Couldn't bind unix domain socket /var/run/apache2/2.4/cgisock.1143
[Fri Oct 28 23:56:24.217736 2022] [core:error] [pid 1143:tid 1] (2)No such file or directory: AH00099: could not create /var/run/apache2/2.4/httpd.pid.LI2abb
[Fri Oct 28 23:56:24.217838 2022] [core:error] [pid 1143:tid 1] AH00100: httpd: could not log pid to file /var/run/apache2/2.4/httpd.pid

Die vorher angelegte Verzeichnisstruktur /apache2/2.4/ unterhalb von /var/run ist dann auch wieder verschwunden.

Legt man die Verzeichnis-Struktur wieder an und restartet napp-it, dann läuft der apache wieder. Möglichweise ist der Ablageort ungeignet oder ein Berechtigungsproblem,
theoretisch sollte er das Verzeichnis ja eigentlich selbst anlegen können.
 
Napp-it nutzt unter Solaris die Default Installion von Apache. Dabei werden die Apache Ordner bei der Installation angelegt. Lediglich die Apache config und die Zertifikate für https werden angepasst. Gestartet wird der Apache als Programm in der /etc/init.d/napp-it und nicht als System Service.

Fehlt nach einem Reboot die Installation, so klingt das eher danach dass ein älteres BE gebootet wird. Wenn Apache läuft, im Menü Snapshot > Bootenvironment kontrollieren ob das aktuelle BE das Default für den nächsten Reboot ist (N)ow = (R)eboot

Auch ohne Apache bleibt napp-it mit http://ip:81 erreichbar
 
Die Apache Installation ist ja vorhanden, der Punkt scheint meines Eindrucks nach eher die verwendete config (httpd.conf) zu sein, die beim Start mittels apachectl beim Start mit -f übergeben wird (Aufruf im napp-it Startskript) Die verwendete BE wurde nicht erneut verändert. Mit dem Ablageort fürs pid file scheint er aber irgendwie nicht ganz glücklich zu sein. War mir gestern dann aber zu spät zum weiter schauen.
 
Nach weiteren Tests sieht es für mich so aus, dass offenbar manuell angelegte Verzeichnise unterhalb von /var/run nicht persistent nach einen reboot sind.

Neben der mitgelieferten config werden auch noch zwei OS-Standard Konfiguration in der mitgelieferten httpd.conf mit angezogen:

aus /var/web-gui/data/tools/httpd/apache24/solaris/config/httpd.conf:
Code:
...
###
#IncludeOptional /etc/apache2/2.4/conf.d/*.conf

Include /var/web-gui/data/tools/httpd/apache24/solaris/config/httpd-ssl.conf

#additional
Include /etc/apache2/2.4/samples-conf.d/mpm.conf
Include /etc/apache2/2.4/samples-conf.d/default.conf

#
# Note: The following must must be present to support
#       starting without SSL on platforms with no /dev/random equivalent
#       but a statically compiled-in mod_ssl.
#
<IfModule ssl_module>
SSLRandomSeed startup builtin
SSLRandomSeed connect builtin
</IfModule>
...

In der /etc/apache2/2.4/samples-conf.d/mpm.conf findet sich die PidFile Direktive, welche zum ersten Problem im error_log
bezüglich der Anlage des PID-File führte
Code:
...
<IfModule !mpm_netware_module>
    PidFile "/var/run/apache2/2.4/httpd.pid"
</IfModule>
...

Ändert man diese ab auf: "PidFile "/var/run/httpd.pid", tritt ein Problem schon mal nicht mehr auf. Dafür meckert dann immer
noch das cgid Modul wegen der nicht möglichen Anlage des socket files:
Code:
[Sat Oct 29 10:16:41.298681 2022] [ssl:warn] [pid 4075:tid 1] AH01906: 127.0.0.1:443:0 server certificate is a CA certificate (BasicConstraints: CA == TRUE !?)
[Sat Oct 29 10:16:41.298835 2022] [ssl:warn] [pid 4075:tid 1] AH01909: 127.0.0.1:443:0 server certificate does NOT include an ID which matches the server name
[Sat Oct 29 10:16:41.341305 2022] [ssl:warn] [pid 4076:tid 1] AH01906: 127.0.0.1:443:0 server certificate is a CA certificate (BasicConstraints: CA == TRUE !?)
[Sat Oct 29 10:16:41.341437 2022] [ssl:warn] [pid 4076:tid 1] AH01909: 127.0.0.1:443:0 server certificate does NOT include an ID which matches the server name
[Sat Oct 29 10:16:41.346012 2022] [cgid:error] [pid 4077:tid 1] (2)No such file or directory: AH01243: Couldn't bind unix domain socket /var/run/apache2/2.4/cgisock.4076
[Sat Oct 29 10:16:41.350328 2022] [mpm_event:notice] [pid 4076:tid 1] AH00489: Apache/2.4.51 (Unix) OpenSSL/1.0.2za configured -- resuming normal operations
[Sat Oct 29 10:16:41.350534 2022] [core:notice] [pid 4076:tid 1] AH00094: Command line: '/usr/apache2/2.4/bin/httpd -f /var/web-gui/data/tools/httpd/apache24/solaris/config/httpd.conf'
[Sat Oct 29 10:16:41.350783 2022] [cgid:crit] [pid 4076:tid 1] AH01238: cgid daemon failed to initialize

Hierzu habe ich testweise die folgende Direktive in der /var/web-gui/data/tools/httpd/apache24/solaris/config/httpd.conf ergänzt.
Code:
DefaultRunTimeDir /var/run

Das Ergebnis war, dass der cgi Fehler nun auch nicht mehr auftrat, beide Dateien werden nun unter /var/run angelegt.

root@storage01:/var/run# ls -altr httpd* cgisock*
srwx------ 1 napp-it root 0 Oct 29 10:55 cgisock.1131
-rw-r--r-- 1 root root 5 Oct 29 10:55 httpd.pid

Auch nach einem reboot ist der Apache nun aktiv und die Web-GUI kann darüber aufgerufen werden.

Der Apache wird hier ja durch das napp-it Skript manuell gestartet/gestoppt und in einem User Kontext, vielleicht verhält sich
das dann auf der Maschine einfach anders, als wenn der apache als Service laufen kann, welche dann gegebenenfalls noch fehlende
Verzeichnisse unterhalb von /var/run anlegen kann?

Die Problematik besteht haber aber eher in Form der Konfiguration, als in dem Vorhandensein von binaries, denn die
sind ja da OS-seitig.
 
Danke für die detaillierten Infos

Ich werde mir das Setup unter Solaris 11.4cbe auch nochmal ansehen.
Ich hatte Apache für https extra gewählt weil das neben OmniOS auch unter Solaris im Repository bereitsteht - leider jeweils in unterschiedlichen Verzeichnissen und Konfiguration.

update:
ich habe diese Änderungen für Solaris in 22.dev und 22.06 integriert, danke nochmal
 
Zuletzt bearbeitet:
Hallo Forum,
ich verwende schon seit einiger Zeit ZFS, zuerst auf FreeBSD direkt sowie später auch in der FreeNAS Lösung - damals alles virtualisiert auf XEN und gentoo Linux. Bereits vor einiger schon bin ich auf napp-it mit OmniOS gewechselt und bisher sehr zufrieden damit.
Das momentane Setup im Home-Lab schaut wie folgt aus: VMWare ESXi bootet von einer SSD und von deren lokalem Datastore werden drei primäre VMs bedient und automatisch gestartet:
  1. Firewall pfSense
  2. Windows Server Core als DC1
  3. OmniOS mit napp-it - stellt SMB Shares für die Windows Welt sowie NFS als gemeinsamen Speicher für die Linux Systeme sowie insbesondere auch als Datastore für die anderen VMs über NFS bereit
Die weiteren VMs - mehrere Devuan Linux Server (für smtp, imap, Spam- und Virenprüfung, monitoring, etc.) sowie ein weiterer Windows Server Core als DC2 und ein Windows 10 System für die Verwaltung der beiden Server Core Systeme funktioniern einwandfrei und werden nach Verfügbarkeit des NFS-Shares für VMWare ESXi ebenso automatisch gestartet. Alle Windows Server sowie napp-it sind auch in die bestehende Domain (mit den beiden AD-Domaincontrollern DC1 und DC2) eingebunden.

Mit einem weiteren Windows Server bzw. genauer gesagt dem darauf zu installierenden MS SQL Server (keine Server Core sondern eine Server mit GUI Installation) gibt es nunmehr aber Probleme: Der MS SQL Server soll nach meiner Vorstellung nämlich alle Datenbankdateien auf einem SMB-Share, das napp-it zur Verfügung stellt, speichern. Einige Klippen bei der Installation habe ich bereits umschifft - so war es beispielsweise erforderlich, gMSAs (group managed service accounts) in der Windows Domaine anzulegen damit der SQL Server unter diesen Accounts betrieben werden kann. Normalerweise läuft der SQL Server ja unter einem lokalen Service Account, welcher aber keinen Zugriff auf Domain-Ressourcen (und damit SMB Shares von napp-it) hat. Erst mit einem gMSA (oder MSA) ist ein Zugriff auf die napp-it SMB Shares in der Domain möglich.

Woran ich aber momentan gerade scheitere ist folgende Fehlermeldung, welche bereits während der Installation von SQL Server auftaucht und den Abschluß der Installation verhindert:
Das Konto für SQL Server-Setup weist für den angegebenen Dateiserver unter dem Pfad "\\napp-it\SQLServer\MSSQL15.DB\MSSQL\Data" keine SeSecurityPrivilege-Berechtigung auf. Diese Berechtigung wird im SQL Server-Setupprogramm für Aktionen zum Festlegen der Ordnersicherheit benötigt. Zum Erteilen diese Berechtigungen verwenden Sie die Konsole "Lokale Sicherheitsrichtlinie" auf diesem Dateiserver, um der Richtlinie "Verwaltung von Überwachungs- und Sicherheitsprotokollen" das Konto für SQL Server-Setup hinzuzufügen. Diese Einstellung ist in der Konsole "Lokale Sicherheitsrichtlinien" unter "Lokale Richtlinien" im Abschnitt "Zuweisen von Benutzerrechten" verfügbar.
Die Installation von SQL Server erfolgt dabei mit einem Domain Administrator Account und der Pfad für das Datenstammverzeichnis wird korrekterweise auch als UNC (\\napp-it\SQLServer\) angegeben, wobei SQLServer der SMB Freigabename des ZFS Filesystems tank/SQLServer ist und napp-it der DNS-Name des OmniOS Servers. Die Berechtigungen der SQLServer Share werden wie folgt in der napp-it Oberfläche angezeigt:
  • Folder ACL: tank/SQLServer user:root:full_set:fd-----:allow, everyone@:modify_set:fd-----:allow
  • Share ACL: shares/SQLServer everyone@:full_set:-------:allow
  • Perm: ACL
  • RDONLY: off
Das user maping innerhalb von napp-it ist auf die empfohlenen Werte konfiguriert:
  • idmap add 'winuser:administrator' 'unixuser:root'
  • idmap add 'wingroup:administrators' 'unixgroup:root'
Trotz entsprechender Suche habe ich bisher keine Möglichkeit gefunden, dem Konto für die Installation des MS SQL Servers (Domain Administrator) auf dem napp-it Server das SeSecurityPrivilege zuzuweisen. Vielleicht hat einer der Wissenden hier den entscheidenden Ratschlag, wie ich hier weiterkomme. Aktuell geht einfach die Installation nicht weiter, bis der Fehler behoben ist.

Besten Dank im voraus, Atom2
 
Das idmapping sorgt nur dafür dass administrator volle Rechte auf dem Unix Server hat. Für manche Aktionen ist es zusätzlich nötig, unter OmniOS root in die lokale SMB Gruppe administrators aufzunehmen (Solaris unterstützt zusätzlich zu lokalen Unix Gruppen Windows kompatible lokale SMB Gruppen). Das wird das Problem aber vermutlich nicht lösen da die Installation als administrator ausgeführt wird. Das benötigte Recht muss man daher dem Windows administrator zuweisen.

Wenn es dann immer noch Probleme gibt, könnte man als Workaround den SQL Server auf ein iSCSI Target installieren. Aus Windows Sicht ist das Installation auf eine lokale ntfs Festplatte.
Beitrag automatisch zusammengeführt:

In der Zwischenzeit erreichen regelmäßige aktuelle OmniOS Stable Sicherheits- und Bugfix-Updates r151042z (2022-10-26)

Nächste Woche ist OmniOS Stable 151044 angekündigt. Wer mag kann den Release Candidate jetzt evaluieren.

Um auf den Release Candidate zu aktualisieren, sind die folgenden Paket-Repositories zu verwenden:
https://pkg.omnios.org/r151044/rc (omnios)
https://pkg.omnios.org/r151044/extra (extra.omnios)

Wer auf den Release Candidate aktualisiert, kann später auf die endgültige Version upgraden.

Installationsmedien
 
Zuletzt bearbeitet:
Hallo @gea,
danke für die rasche Antwort. Dein Kommentar mit der Aufnahme von root in die lokale SMB Gruppe administrators hat mich jetzt einen kleinen Schritt weitergebracht, aber das Problem noch nicht gelöst. Durch den Kommentar bin ich nämlich auf das - von Dir wohl gemeinte - Kommando smbadm gekommen. Dort gibt es eine Möglichkeit zur Anzeige der aktivierten Privilegien für lokale SMB Gruppen (durch "smbadm show -pm") und das zeigt - für die Gruppe administrators - folgendes an:
administrators (Members can fully administer the computer/domain)
SID: S-1-5-32-544
Privileges:
SeTakeOwnershipPrivilege: On
SeBackupPrivilege: On
SeRestorePrivilege: On
BypassAclRead: Off
BypassAclWrite: Off
No members
Daraus leite ich ab, daß das für die Installation erforderliche Privileg - SeSecurityPrivilege - der Gruppe administrators gar nicht zugeordnet ist und daher eine Aufnahme von root in diese Gruppe auch nichts zu ändern vermöchte.

Gibt es eine Möglichkeit, Privilegien für eine Gruppe auf dem OmniOS Server zu ändern - also das erforderliche Privileg der Gruppe zuzuordnen? Auf einem Windows System ist das über die Lokale Sicherheitsrichtline möglich: Man startet das Programm secpol.msc auf dem betreffenden Windows (Server-)System und unter dem Unterpunkt "Lokale Richtlinien -> Zuweisen von Benutzerrechten" kann man im Eintrag "Verwalten von Überwachungs- und Sicherheitsprotokollen" - das entspricht nach meinen Recherchen dem SeSecurityPrivilege - einzelne User oder Gruppen hinzufügen und diesen damit das Privilege zuweisen; die Gruppe "Administratoren" ist dort (für das lokale System) standardmäßig bereits hinzugefügt. Das gilt aber eben nur für das lokale System. Wie man eine solche Änderung aber für den Solaris SMB-Server macht, erschließt sich mir bisher nicht. Die von mir bisher versuchten Windows Remote Admin Tools lassen einen Zugriff auf napp-it für eine solche Aktion leider nicht zu ...

Auf einer NetApp wäre das laut meinen zwischenzeitlichen weiteren Recherchen möglich und erfordert offenbar auch eine Aktion direkt auf dem NetApp System. Man sollte daher - positiv gedacht - annehmen können, das selbiges doch eigentlich unter Solaris/OmniOS auch irgendwie machbar wäre.

Wenn es dann immer noch Probleme gibt, könnte man als Workaround den SQL Server auf ein iSCSI Target installieren. Aus Windows Sicht ist das Installation auf eine lokale ntfs Festplatte.
Das ist mir soweit klar, hilft mir aber bei meiner Umsetzungsidee - ebenso wie die zweite Variante, dem Windows Server einfach eine zusätzliche virtuelle VMFS Festplatte über VMWare ESXi für die Datenbankdateien zuzuweisen - leider nicht. In beiden Fällen wird dafür nämlich ntfs als Dateisystem verwendet. Mein Ziel wäre aber, auf die Datenbankdateien mit OmniOS direkt zugreifen zu können. Mit anderen Worten sollen die MS SQL Server Datenbankdateien als einfache Files unter OmniOS aufscheinen und damit für alle möglichen Tools (cp, grep, cmp, etc.) direkt verfügbar sein.

Besten Dank, Atom2
 
Zuletzt bearbeitet:
Die Installation benötigt Rechte für den User der die Installation startet, also Windows\user oder Domain\user. OmniOS\user ist unerheblich. OmniOS\user in der lokalen OnniOS Admin Gruppe ist nur relevant damit man über Windows Computermanagement remote den OmniOS SMB Server managen kann.

Ansonsen: Kann man die Datenbankdateien nicht unabhängig von der Softwareinstallation speichern? (SQL Server "lokal" und Datenbanken remote auf SMB)
 
Hallo @gea,
danke für die weitere Unterstützung.
Die Installation benötigt Rechte für den User der die Installation startet, also Windows\user oder Domain\user. OmniOS\user ist unerheblich. OmniOS\user in der lokalen OnniOS Admin Gruppe ist nur relevant damit man über Windows Computermanagement remote den OmniOS SMB Server managen kann.
Du hast natürlich völlig recht, daß die Installation - sprich der Installationsbenutzer - die notwendigen Rechte bzw. Privileges benötigt. Aber diese hat er (zumindest lokal auf dem Windows Server) auch: Ich habe das im sysinternals Process Explorer für den Installationsprozeß (und vorher auch in der Power Shell) geprüft und das Privilege "SeSecurityPrivilege" ist vorhanden und auch aktiviert. Offenbar gilt dieses Privilege dann aber nur für das "lokale" System, nicht aber für den OmniOS Server welcher insoweit ja ein "remote" System ist. Darauf deutet auch die Fehlermeldung hin, die ich hier auszugsweise (mit Hervorhebung) nochmals anführe:

Zum Erteilen diese Berechtigungen verwenden Sie die Konsole "Lokale Sicherheitsrichtlinie" auf diesem Dateiserver, um der Richtlinie "Verwaltung von Überwachungs- und Sicherheitsprotokollen" das Konto für SQL Server-Setup hinzuzufügen.
Ich verstehe das so, daß auf dem Dateiserver - also jenem, auf dem die Daten gespeichert werden sollen - die dortige "Lokale Sicherheitsrichtlinie" derart angepaßt werden muß, damit dem auf dem Windows Server für die Installation benutzten User (Domain\Administrator) dieses Privilege auf dem OmniOS Dateiserver zukommt. Auf OmniOS ist dieses Privileg aber offenbar nicht vorhanden und damit auch für den zur Installation benutzen User nicht vorhanden (vgl. dazu den Output von "smbadm show -pm" auf der Shell des OmniOS Systems). Auch die Lösung für NetApp (siehe Link) deutet eigentlich darauf hin, daß etwas auf der NetApp getan werden muß, nicht aber Änderungen unter Windows für den zur Installation verwendeten User erforderlich sind.

Ansonsen: Kann man die Datenbankdateien nicht unabhängig von der Softwareinstallation speichern? (SQL Server "lokal" und Datenbanken remote auf SMB)
Das ist ja genau das Ziel, welches ich verfolge: Die Installation des SQL Servers erfolgt ja "lokal", aber bei der Installation wird als ein Schritt des menugeführten Installationsprozesses auch das Datenbankstammverzeichnis abgefragt. Dieses muß für SMB über einen UNC-Pfad spezifiziert werden und soll eben auf einer SMB-Freigabe des OmniOS SMB-Servers liegen. Nach meinem Verständnis will die Installation dann dieses Verzeichnis mit den korrekten Berechtigungen derart vorbereiten, daß es später im Betrieb keine Probleme gibt - und dafür ist offenbar in der lokalen Sicherheitsrichtlinie auf dem (OmniOS) Dateiserver das Privilege "SeSecurityPrivilege" für den Installationsbenutzer des SQL Servers erforderlich.

Besten Dank, Atom2
 
In der NetApp Doku steht ja
The domain user account used for installing the SQL server must be assigned the “SeSecurityPrivilege” privilege to perform certain actions on the CIFS server that require privileges not assigned by default to domain users.

Diese Rechte Erweiterung muss so wie ich das verstehe für den Installationsuser auf dem AD Server erfolgen und nicht auf dem SMB/CIFS Server. Dort gibt es diesen AD User ja auch garnicht als lokalen Account.
 
Hallo @gea,
danke für die Unterstützung und die Ideen.

In dem von mir angeführten Link von NetApp zu dem, für die Zuweisung des SeSecurityPrivilege an den entsprechenden Installationsuser erforderlichen Kommando steht dazu aber, daß das folgende Kommando auszuführen ist:

vserver cifs users-and-groups privilege add-privilege -vserver vserver_name -user-or-group-name account_name -privileges SeSecurityPrivilege
Der verwendete "vserver cifs" Befehl, den es im übrigen in einer Vielzahl von Inkarnationen gibt, ist nach meinem Verständnis Teil von ONTAP, also dem Betriebsystem der NetApp Lösungen (vgl. dazu die Doku von NetApp, zu finden auf der linken Seite unter dem ausklappbaren Heading "vserver cifs commands".

In meinem Link von NetApp steht darunter auch gleich ein konkretes Beispiel inklusive Abfrage, ob das Privilege durch den Befehl auf dem vserver "vs1" auch tatsächlich zugewiesen worden ist:

cluster1::> vserver cifs users-and-groups privilege add-privilege -vserver vs1 -user-or-group-name EXAMPLE\SQLinstaller -privileges SeSecurityPrivilege

cluster1::> vserver cifs users-and-groups privilege show -vserver vs1
Vserver User or Group Name Privileges
--------- --------------------- ---------------
vs1 EXAMPLE\SQLinstaller SeSecurityPrivilege
Ich selbst kenne mich mit NetApp übrigens überhaupt nicht aus und habe mir meine Interpretation jetzt nur durch Recherchen und Suchen im Internet logisch zusammengefügt. Und diese macht aus meiner Sicht momentan durchaus Sinn ... aber möglicherweise liege ich auch total daneben.

Der "vserver" Befehl ist jedenfalls kein mir bekanntes Windows Kommando, das irgendwie auf einer Kommandozeile unter Windows (cmd oder PowerShell) ausgeführt werden könnten und der Prompt im Beispiel oben schaut auch nicht aus, wie jener von cmd oder PowerShell - wobei dieser unter Windows natürlich grundsätzlich angepaßt hätte werden können - sondern gemäß dieser Doku genau so, wie der Standardprompt auf dem CLI von ONTAP.

Ich wüßte jedenfalls nicht - und habe dazu auch bisher nichts gefunden -, wie ich dem Installationsuser ein Privilege auf einem Nicht-Windows SMB/CIFS Server zuweisen kann. Für einen Windows Dateiserver könnte man das wohl über die "Lokale Sicherheitsrichtlinie" direkt auf dem Dateiserver zuweisen.

Möglicherweise kennt aber der SMB-Server von Solaris/OmniOS ja das "SeSecurityPrivilege" nicht einmal. Darauf würde schließlich auch die Ausgabe des "smbadm show -pm" Kommandos im CLI von OmniOS hindeuten: Dort ist dieses Privilege ja nicht einmal angeführt, andere aber schon, teilweise aktiviert (on), teilweise deaktiviert (off).

Spannend ist dabei auch noch, daß die unter OmniOS aktivierten Privileges auch unter Windows existieren und dort für den Domain Admin (group administrators) auch als aktiv zugewiesen sind, jene, die aber "off" sind, unter Windows nicht einmal bekannt sind.

Besten Dank, Atom2
 
Zuletzt bearbeitet:
Eine neue stable r151044 des minimalistischen OmniOS ZFS Servers ist da
siehe Release Schedule
Hallo @gea , seit dem Update auf OmniOS r44 hagelt es bei mir perl-Fehler:
Subject: Cron <root@omniosce> perl /var/web-gui/data/napp-it/zfsos/_lib/scripts/auto.pl
Tty.c: loadable library and perl binaries are mismatched (got first handshake key 12200080, needed 12280080)

Und napp-it startet nicht / bietet keine weg-GUI (keine Verbindung zu :81). Auch manueller Start mit /etc/init.d/napp-it start hilft nicht.

Napp-it Version ist 21.06a9 wenn ich mich Recht erinnere.

Macht da das Update auf Perl 5.36 Probleme?
 
Zuletzt bearbeitet:
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