[Sammelthread] ZFS Stammtisch

[gea]

Alle Schreibvorgänge gehen bei ZFS grundsätzlich wegen der besseren Performance über den rambasierten Schreibcache. Ohne sync ist der Inhalt beim Absturz verloren auch wenn ZFS wegen Copy on Write keine Dateisystemfehler dadurch bekommt. Aktiviert man sync so wird jeder einzelne bestätigte Schreibvorgang protokolliert damit er bei einem Absturz beim nächsten Reboot nachgeholt werden kann. Dabei ist es zunächst egal ob die Protokollierung auf dem ZIL-Bereich eines langsamen Pools oder einem darauf optimierten externen schnellen Slog erfolgt.

Erfolgt die Protokollierung auf dem Pool, so ist der Inhalt des ZIL (das Schreibprotokoll) nur verloren wenn auch der Pool verloren ist. Nur bei einem Slog kann diese Protokollierung unabhängig vom Pool verloren gehen.

Ein Datenverlust ist bei einem Absturz immer dabei es sei denn die zu schreibenden Daten sind bereits komplett im Schreibcache und Log. Es geht um den Aspekt bestätigte Schreibvorgänge und damit Datenbank und Dateisystemkonsistenz. Für den Rest muss und kann ein schreibendes Programm selber sorgen (tmpfile, eigenes Log)

 

[mrpasc]

@mrpasc
Der HPE Smart Array P440ar läuft im HBA-Modus, die Raid-Funktion wird nicht genutzt. Mit der Batterie könnte ich eine PowerLessProtection bei den SAS-HDD nachbilden (glaube ich zumindest).

@nukim
Nein, wenn der P440ar wirklich sauber im HBA Modus läuft wird der Controller Cache umgangen, d.h. du kannst dir auch die Battery sparen. Sollte er den Cache im HBA Modus nutzen wirds wieder gefährlich für die Daten, weil ZFS keinerlei Zugriff und Rückmeldung auf diesen Cache hat!

 

[Bierjpg]

gae ich möchte da noch einmal nachfragen:

-Single Slog
Wenn das Slog einfach ausfällt: Pool wird zum protokollieren genutzt. Kein Datenverlust - Pool wird nur langsamer

Ist klar.

Wenn das Slog ausfällt und der Rechner abstürzt: Datenverlust

Slog fällt aus, Wenn der PC innerhalb der nächsten paar Sekunden abstürzt Datenverlust. Aber doch nicht wenn schon umgeschwenkt wurde Pool Logging

Wenn das Slog beim Schreiben disconnected (z.B. man zieht das Kabel oder die Platte). Io Error, System steht, Datenverlust

Dies wirkt unlogisch? Daten werden vom RAM aufs SLOG übertragen. Dabei entsteht ein IO Error (slog wird entfernt) Sollte dann nicht auf den Pool geschrieben werden nach einem Timeout/kurzer Zeit?

Oder meinst du wenn vom Slog auf den Pool geschrieben wird?

Nach allem was ich bisher gelesen habe gibt es diese kritischen Situationen:

Slog fällt gleichzeitig mit dem System aus. (Blitz grillt Mainboard + Slog) Nicht zu verhindern außer mit der richtigen USV
Slog fällt aus gleichzeitig mit einem System absturzt aus.
Slog fällt aus, wenn Daten vom Slog aufs Storage kopiert werden.

Oder sehe ich hier etwas falsch?

 

[gea]

gae ich möchte da noch einmal nachfragen:

Ist klar.

Slog fällt aus, Wenn der PC innerhalb der nächsten paar Sekunden abstürzt Datenverlust. Aber doch nicht wenn schon umgeschwenkt wurde Pool Logging

korrekt, Datenverlust nur wenn noch Daten im Slog sind die nicht auf den Pool geschrieben sind. Nach dem Umschwenken ist das defekte Slog nicht mehr aktiv. Lebt das System nach dem Slog Ausfall noch ein paar Sekunden wird der Inhalt das Ramcache normal geschrieben und anschließend der Pool zum loggen benutzt.

Dies wirkt unlogisch? Daten werden vom RAM aufs SLOG übertragen. Dabei entsteht ein IO Error (slog wird entfernt) Sollte dann nicht auf den Pool geschrieben werden nach einem Timeout/kurzer Zeit?

Eine Sata/SAS Platte kann hotplug.
Beim Schreibprozess selber sieht das anders aus.

Das Problem hat man auch bei einem Pool aus einem Basic vdev. Abziehen während des Schreibvorgangs führt zu einem io Error. Danach ist der ZFS Pool suspended. Pool export/destroy geht auch nicht. Abhilfe bringt nur ein reboot, vgl https://hardforum.com/threads/opens...-and-napp-it.1573272/page-213#post-1045265767

Liese sich zwar auch abfangen, ist aber ein sehr spezieller und sehr seltener Fehlerfall. Redundanz (Mirror, Raid-Z) vermeidet das Problem.

Oder meinst du wenn vom Slog auf den Pool geschrieben wird?

Nach allem was ich bisher gelesen habe gibt es diese kritischen Situationen:

Slog fällt gleichzeitig mit dem System aus. (Blitz grillt Mainboard + Slog) Nicht zu verhindern außer mit der richtigen USV
Slog fällt aus gleichzeitig mit einem System absturzt aus.
Slog fällt aus, wenn Daten vom Slog aufs Storage kopiert werden.

Oder sehe ich hier etwas falsch?

 

[oyster]

Mir kam gerade ein Gedanke. Ich weiß nicht ob das so funktionieren könnte: Angenommen ich habe einen Pool mit SSDs ohne Power Loss Protection. Kann ich dies kompensieren indem ich ein schnelles SLOG mit Power Loss Protection verwende und Sync writes auf dem Pool enable?

 

[asche77]

Ich _vermute_ nein/nur eingeschränkt, denn ZFS wird immer noch die Daten per sync write auf deinen Pool schreiben wollen = langsam ohne PLP. Du sparst Dir aber immerhin den zweifachen sync write auf den Pool (da nun 1x ins SLOG).

 

[gea]

Bei einem SSD Pool ohne plp + Slog mit plp hat man folgende Situation

Jeder bestätigte Schreibvorgang landet sofort auf dem Slog.
Auch bei einem Absturz sind diese sync Daten beim nächsten Reboot auf dem Pool

Alle Schreibvorgänge werden unabhängig davon im RAM Schreibcache gesammelt um die im Anschluß schnell in großen Blöcken zu schreiben. Stürzt der Rechner hier ab, so ist der Stand auf Platte bei SSD ohne plp im Zweifen nicht genau definiert, je nachdem wann der Absturz stattfindet. ZFS hat ja keine volle Kontrolle über sein Copy on Write das ansonst ZFS davor schützt unklare Verhältnisse auf dem Pool zu haben. SSD ohne plp - also ohne das ein schreibender Prozess sicher sein kann dass und wann Daten auf SSD - sind immer ein Problem, auch ohne sync write, auch wenn meist alles gut geht. Meine ersten SSD Pools vor 10 Jahren hatten alle kein plp, heute würde ich aber nicht darauf verzichten wollen. Ist wie Sicherheitsgurt, hatte man früher auch nicht.

Fazit: Nicht Fisch noch Fleisch, nur minimale Verbesserung. Wenns dumm läuft: korrupte Daten.
Bei SSD daher bei kritischen Daten immer powerloss protection fordern. Bei mechanischen Platten ist das kein Thema. Da sind Daten nach einem Commit immer (zwar langsam) auf Platte da ZFS den writeback cache ausschalten kann. Bei SSD ist das leider eine Datacenter Option. Nur da ist darantiert dass Daten nach der Bestätigung des Schreibvorgangs wirklich auf SSD sind und nicht "lost in transition"

 

[bbott]

Ich möchte einen alten Pool auf einen neuen Pool kopieren, danach wollte ich im alten Pool nochmal mit Daten von alten Platten befüllen, Daten kopieren und dann diese Daten nochmal auf den neue Pool kopieren. Dadurch möchte ich eine Fragmentierung auf dem neuen Pool minimieren. Jetzt hatte ich gelesen, dass bei send Pool die Daten des Ziel Pools gelöscht werden. Oder muss ich beim zweiten mal send pool den parameter "i" verwenden?

 

[gea]

Fragmentierung eines Copy on Write Dateisysstems wie ZFS steigt mit dem Füllgrad des Pools. Beim Replizieren auf einen leeren Pool sinkt die daher. Insgesamt ist Fragmentierung für ZFS aber wegen des überragenden rambasierten Schreib/Lesecache kein so großes Problem sofern man ausreichend RAM hat und nach Möglichkeit unter ca 80% Füllgrad bleibt.

ZFS löscht bei incrementeller Replikation den Zielpool nicht, sondern macht ein rollback auf den letzten gemeinsamen Snap.

Parameter -i für incrementelle Replikation erwartet zwei Snaps als Parameter (gemeinsamer Basissnap und neuer Quell-Snap). Das Ziel macht ein Rollback auf den gemeinsamen Basissnap, dann wird der neue Quell-Snap mit geänderten Datenblöcken übertragen. Gibt es weitere Quell-Snaps zwischen Basissnap und neuem Quellsnap kann man die mit -I übertragen. Recursiv -R werden alle Quell Datasets (Snaps, Dateisysteme, Zvols, Mountpoints) übertragen.

 

[Badrig]

Macht Lesecache und ZIL auf SSD (M.2 NVMe, Mirrored) Sinn bei einem 8 Platten Z2 oder spar ich mir das Geld? Oder ZIL auf SSD weglassen und nur eine einzelne SSD als Lesecache?
Zugriffe sind überwiegend sequentiell.

Und wie groß empfiehlt sich so ein Lesecache?

 

[asche77]

SLOG macht nur Sinn bei sync writes. Hast Du davon viele?

Im Zweifel sind weder slog noch L2ARC sinnvoll, v.a. bei sequentielle Zugriffen.

 

[gea]

Macht Lesecache und ZIL auf SSD (M.2 NVMe, Mirrored) Sinn bei einem 8 Platten Z2 oder spar ich mir das Geld? Oder ZIL auf SSD weglassen und nur eine einzelne SSD als Lesecache?
Zugriffe sind überwiegend sequentiell.

Bitte Begriffe eindeutig verwenden sonst verwirrt es etwas

ZIL=vorbelegter Bereich auf dem Datenpool selber um bestätigte Schreibvorgänge zu protokollieren. Der ZIL Bereich hat damit eine geringere Latenz und keine Fragmentierung im Vergleich zu normalen Schreibvorgängen auf den Pool.

Slog=ZIL Funktionalität auf einer separaten dafür optimierten Platte

Protokollierung bestätigter Schreibvorgänge auf ZIL oder Slog findet nur statt wenn sync Sicherheit aktiviert ist, Wenn man diese Absicherung des RAM Schreibcaches nicht braucht immer sync deaktivieren weil das selbst mit dem besten Slog erheblich schneller ist.

Lesecache=RAM (Arc)
Erweiterung des Arc Lesecache auf eine SSD=L2Arc

Und wie groß empfiehlt sich so ein Lesecache?

Bei ausreichend RAM (je nach Use Case 16-128GB) bringt ein L2Arc wenig bis nichts. Arcstat gibt Auskunft über die Cache Auslastung/Trefferquote.

Da ein L2Arc zum Verwalten RAM braucht sollte L2Arc nicht größer als sagen wir mal 5x RAM sein. Da L2Arc inzwischen persistent ist (übersteht Reboot) kann es bei sehr vielen wahlfreien Zugriffen auch mit viel RAM sinnvoll sein. Beispiel Mailserver mit > 1Mio Files und 1000 Usern. Auch kann man bei L2Arc read ahead aktivieren. Auch das kann was bringen.

 

[Luckysh0t]

read ahead

Was macht das ? Eine Suche im Netz brachte nicht wirklich Informationen fazu.

 

[gea]

Ich würde read ahead als vorausschauendes Lesen übersetzen.
Wenn z.B. der Anfang einer Datei benötigt und gelesen wird, so sorgt read ahead dafür dass auch folgende Teile der Datei "auf Verdacht" in den Cache gelesen werden. Wird diese Information dann tatsächlich benötigt steht sie sofort zur Verfügung.

readahead - Wikipedia

en.wikipedia.org

 

[Badrig]

@gea danke, dann spare ich mir das alles und investiere nur in die 64gb ECC ram

 

[bbott]

Ich habe nun den Pool gesendet, mit

zfs send -R <Poolname>/<Name bzw. Pfad zum Dataset>@migrate | zfs receive -F <Neuer Pool>/<Name bzw. Pfad zum gewünschten Dataset>

Kann ich nun einfach die Snapshots in beiden Pool löschen?

Den alten/Quell Pool wollte ich nun mit neuen Daten nochmals füllen, um ihn den alten Pool mit den neuen Daten auf dem neuen Pool zu kopieren. Da es im gleichen Server ist könnte ich es auch per cp kopieren statt zfs send zu senden. Oder gibt es einen Grund zfs zu bevorzugen, weil z. B. zfs send noch Prüfsummen überprüft?

 

[gea]

Ich habe nun den Pool gesendet, mit

zfs send -R <Poolname>/<Name bzw. Pfad zum Dataset>@migrate | zfs receive -F <Neuer Pool>/<Name bzw. Pfad zum gewünschten Dataset>

Kann ich nun einfach die Snapshots in beiden Pool löschen?

Den alten/Quell Pool wollte ich nun mit neuen Daten nochmals füllen, um ihn den alten Pool mit den neuen Daten auf dem neuen Pool zu kopieren. Da es im gleichen Server ist könnte ich es auch per cp kopieren statt zfs send zu senden. Oder gibt es einen Grund zfs zu bevorzugen, weil z. B. zfs send noch Prüfsummen überprüft?

Vorteile von zfs send

- Prüfsummenkontrolle
- Überträgt auch offene Dateien durch Snapshots
- Kopiert viele ZFS Eigenschaften mit
- Überträgt inkrementell nur geänderte ZFS Datenblöcke (weniger Daten)
- Sendet einen Datenstrom, ist damit fast so schnell wie es der Pool (oder das Netz) hergibt

- Bei Verschlüsselung kann man sogar raw (verschlüsselt) übertragen

Wenn man die Erst-Replikation inkrementell fortsetzen will darf man die Snapshots nicht löschen da ansonst die Replikation nicht fortgesetzt werden kann (Man muss dann erneut eine Erst/Komplettreplikation starten)

 

[bbott]

Also snapshot nicht löschen alten Pool Daten löschen und dann mit (-i)

zfs send -i <Poolname>/<Name bzw. Pfad zum Dataset>@migrate | zfs receive -F <Neuer Pool>/<Name bzw. Pfad zum gewünschten Dataset>

Die neuen Daten hinzufügen?

Wir dann nicht aber ein diff erstellt? Und mehr Speicherplatz benötigt?

 

[gea]

Für incrementelles send mit -i muss man zwei Snaps angeben
1. Den gemeinamen Basissnap der auf beiden Seiten identisch sein muss
2. Den neuen Quellsnap mit den seither geänderten Datenblöcken

siehe ältere Originaldoku von Oracle (noch auf deutsch verfügbar)

Senden und Empfangen von ZFS-Daten - Oracle Solaris ZFS-Administrationshandbuch

Dieses Handbuch richtet sich an alle Personen, die für die Einrichtung und Verwaltung von ZFS-Dateisystemen von Oracle zuständig sind. Sofern zutreffend, werden Themen für SPARC- und x86-basierte Systeme behandelt.

docs.oracle.com

 

[you]

Eine, wie ich finde, schöne Erklärung zum COW:

Datenschutzhinweis für Youtube

An dieser Stelle möchten wir Ihnen ein Youtube-Video zeigen. Ihre Daten zu schützen, liegt uns aber am Herzen: Youtube setzt durch das Einbinden und Abspielen Cookies auf ihrem Rechner, mit welchen sie eventuell getracked werden können. Wenn Sie dies zulassen möchten, klicken Sie einfach auf den Play-Button. Das Video wird anschließend geladen und danach abgespielt.

Youtube Videos ab jetzt direkt anzeigen

Video anzeigen

 

[Wesumat]

@gea

Kurze Frage im Hinblick auf das neue Konzept der Oracle Solaris 11.4 CBE im Vergleich zu GA-Version (Announcing the First Oracle Solaris 11.4 CBE) und der
Unterstützung für napp-it, ist da mit irgendwelchen Problemen zu rechnen oder sollte das problemlos weiterhin laufen, da es sich ja teils nur um Vorabversionen
oder Teilmengen der später erscheinende generellen SRU Versionen (für subscription Inhaber) handeln wird?

 

[besterino]

Oi, das ist ja mal spannend! Habe ich gar nicht mitbekommen. Danke für den Hinweis! (Vielleicht funzt ja die Connectx-4 jetzt mit dem freien 11.4!)

 

[gea]

@gea

Kurze Frage im Hinblick auf das neue Konzept der Oracle Solaris 11.4 CBE im Vergleich zu GA-Version (Announcing the First Oracle Solaris 11.4 CBE) und der
Unterstützung für napp-it, ist da mit irgendwelchen Problemen zu rechnen oder sollte das problemlos weiterhin laufen, da es sich ja teils nur um Vorabversionen
oder Teilmengen der später erscheinende generellen SRU Versionen (für subscription Inhaber) handeln wird?

Eigentlich sollten keine Probleme auftauchen. Einzig ein Update mit einem neuen Perl hatte kurz Probleme bereitet da ein neues io.tty Modul für Expect benötigt wurde. Das ist aber kein grundsätzliches Problem und ist durch Neukompilieren von IO::Tty einfach zu lösen, https://napp-it.org/downloads/io-tty.html (Modul wird für interaktive Befehle via Expect z.B. passwd benötigt)

Allenfalls wenn Oracle völlig neue Features in eine Servicerelease integrieren sollte, stellt sich die Frage der Unterstützung dieser Features. Dass es jetzt ein aktualisiertes "freies" Solaris gibt, macht es aber einfacher Anpassungen vorzunehmen. Ich heißt ja, dass Oracle das regelmäßig wiederholt - hoffentlich nicht nur alle 4 Jahre.

 

[bbott]

Ist es ein Problem wenn ich eine HDD an einen anderen SATA-Port hänge? Ich hatte ein defektes SFF Kabel, deshalb hatte ich einer HDD einen am SATA Port genutzt. Jetzt ist das neue Kabel da und ich könnte die Platte an dem SFF Port betreiben, oder würde dann ein zfs (File) Check ausgelöst?

 

[gea]

Ein ZFS Pool speichert die Plattenkennung aus denen der Pool besteht. Wenn diese Kennung einen physikalischen Anschluß beschreibt (c0t0d0, sda etc) und man eine Platte woanders ansteckt so ist die aus ZFS Sicht fehlend/disconnected. Erst nach einem Pool Export/Import werden die Platten des Pools neu zugeordnet. Ein Scrub (ZFS File/Prüfsummencheck hilft nicht).

Wird die Platte über ihre WWN erkannt z.B. c3t5000CCA0BEC6E3F4d0 (eine eindeutige Kennung die der Hersteller in der Firmware der Platte hinterlegt hat) so wird die Platte über Controller und Server hinweg eindeutig identifiziert.

 

[asche77]

... Und den Pool kann man einfach über einen Export und Import auf wwn umstellen.

Müsste lt Google lauten:

zpool import -d /dev/disk/by-id <pool>

 

[gea]

... Und den Pool kann man einfach über einen Export und Import auf wwn umstellen.

Müsste lt Google lauten:

zpool import -d /dev/disk/by-id <pool>

Das geht unter Linux so wo es mehrere Arten der Plattenerkennung gibt.
Solarish mit einem aktuellen HBA macht ausschließlich WWN

 

[Wesumat]

Eigentlich sollten keine Probleme auftauchen. Einzig ein Update mit einem neuen Perl hatte kurz Probleme bereitet da ein neues io.tty Modul für Expect benötigt wurde. Das ist aber kein grundsätzliches Problem und ist durch Neukompilieren von IO::Tty einfach zu lösen, https://napp-it.org/downloads/io-tty.html (Modul wird für interaktive Befehle via Expect z.B. passwd benötigt)

Allenfalls wenn Oracle völlig neue Features in eine Servicerelease integrieren sollte, stellt sich die Frage der Unterstützung dieser Features. Dass es jetzt ein aktualisiertes "freies" Solaris gibt, macht es aber einfacher Anpassungen vorzunehmen. Ich heißt ja, dass Oracle das regelmäßig wiederholt - hoffentlich nicht nur alle 4 Jahre.

Habe jetzt mal in einer VM testweise von 11.4 GA auf 11.CBE upgedatet. Danach scheint die angedeutete Problematik aufgetreten zu sein.

In der GUI erscheint folgende Fehlermeldung beim Versuch beispielsweise die Pool-Übersicht zu laden.

Can't load '/var/web-gui/data/napp-it/CGI/auto/IO/Tty/Tty.so' for module IO::Tty: ld.so.1: perl: relocation error: R_AMD64_PC32: file /var/web-gui/data/napp-it/CGI/auto/IO/Tty/Tty.so: symbol __start_crt: value 0xffff80428e5fdb67 does not fit at /usr/perl5/5.32/lib/i86pc-solaris-thread-multi-64/DynaLoader.pm line 193. at /var/web-gui/data/napp-it/CGI/IO/Tty.pm line 30. Compilation failed in require at /var/web-gui/data/napp-it/CGI/IO/Pty.pm line 7. BEGIN failed--compilation aborted at /var/web-gui/data/napp-it/CGI/IO/Pty.pm line 7. Compilation failed in require at /var/web-gui/data/napp-it/CGI/Expect.pm line 22. BEGIN failed--compilation aborted at /var/web-gui/data/napp-it/CGI/Expect.pm line 22. Compilation failed in require at /var/web-gui/data/napp-it/zfsos/_lib/illumos/zfslib.pl line 2207. BEGIN failed--compilation aborted at /var/web-gui/data/napp-it/zfsos/_lib/illumos/zfslib.pl line 2207. Compilation failed in require at admin.pl line 434.

Allerdings kommt ich mit der beschriebenen Vorgehensweise nicht ganz zurecht.

Die Perl Versionen ändern sich offenbar von 5.22.1 (GA) zu 5.32.0 (CBE), soweit so gut. Nach der beschriebenen perl CPAN Aktion findet sich unter /root/.cpan auch einige neue
Dateien unterhalb von build/ um die es vermutlich geht? Aber was von welcher Stelle dann genau wohin gehört, erschliesst mich aktuell noch nicht so Recht.

root@solCBE:~/.cpan/build/IO-Tty-1.16-0# ls -al
total 510
drwxr-xr-x   6 root     root          25 Mar  6 07:44 .
drwxr-xr-x   6 root     root           6 Mar  6 07:44 ..
drwxr-xr-x   8 root     root           8 Mar  6 07:44 blib
-rw-r--r--   1 root     root        9429 Jan 22  2021 ChangeLog
drwxr-xr-x   2 root     root          21 Mar  6 07:44 conf
-rw-r--r--   1 root     root       37562 Mar  6 07:44 Makefile
-rw-r--r--   1 root     root       15274 Jan 22  2021 Makefile.PL
-rw-r--r--   1 root     root         295 Jan 22  2021 MANIFEST
-rw-r--r--   1 root     root         125 Jan 22  2021 MANIFEST.SKIP
-rw-r--r--   1 root     root        1086 Jan 22  2021 META.json
-rw-r--r--   1 root     root         663 Jan 22  2021 META.yml
-rw-r--r--   1 root     root        1086 Mar  6 07:44 MYMETA.json
-rw-r--r--   1 root     root         663 Mar  6 07:44 MYMETA.yml
-rw-r--r--   1 root     root           0 Mar  6 07:44 pm_to_blib
-rw-r--r--   1 root     root        9471 Jan 22  2021 Pty.pm
-rw-r--r--   1 root     root        5661 Jan 22  2021 README
drwxr-xr-x   2 root     root           4 Mar  6 07:44 t
-rw-r--r--   1 root     root        2880 Jan 22  2021 try
drwxr-xr-x   2 root     root           3 Mar  6 07:44 Tty
-rw-r--r--   1 root     root           0 Mar  6 07:44 Tty.bs
-rw-r--r--   1 root     root       31176 Mar  6 07:44 Tty.c
-rw-r--r--   1 root     root       76872 Mar  6 07:44 Tty.o
-rw-r--r--   1 root     root        8334 Jan 22  2021 Tty.pm
-rw-r--r--   1 root     root       23943 Jan 22  2021 Tty.xs
-rw-r--r--   1 root     root       12793 Mar  6 07:44 xssubs.c

Da ein passender Perl-Versionsordner zur 5.32 schon unter /var/web-gui/data/tools/omnios/ existiert in einer aktuelle napp-it Testinstallation, vermute ich mal, dass man hier nichts weiter anlegen muss,
sondern direkt den passenden Versions-Ordner als Ziel (perl_5.32) als Ziel der neuen Module verwenden kann?

root@solCBE:/var/web-gui/data/tools/omnios# ls -al
total 38
drwxr-xr-x  12 napp-it  root          13 Mar  6 07:50 .
drwxr-xr-x  20 napp-it  root          21 Mar  6 00:40 ..
-rwxr-xr-x   1 napp-it  root         250 Mar  6 00:40 info.txt
drwxr-xr-x   3 napp-it  root           4 Mar  6 00:40 parted2
drwxr-xr-x   3 napp-it  root           3 Mar  6 00:40 perl_5.16
drwxr-xr-x   3 napp-it  root           3 Mar  6 00:40 perl_5.22
drwxr-xr-x   3 napp-it  root           3 Mar  6 00:40 perl_5.24
drwxr-xr-x   3 napp-it  root           3 Mar  6 00:40 perl_5.26
drwxr-xr-x   3 napp-it  root           3 Mar  6 00:40 perl_5.28
drwxr-xr-x   3 napp-it  root           3 Mar  6 00:40 perl_5.30
drwxr-xr-x   3 napp-it  root           3 Mar  6 00:40 perl_5.32
drwxr-xr-x   3 root     root           3 Mar  6 07:51 perl_5.32.backup
drwxr-xr-x   3 napp-it  root           3 Mar  6 00:40 perl_5.34

 

[gea]

Grundsätzliche Vorgehensweise

Unter Solaris werden die io.tty binaries in /var/web-gui/data/tools/solaris/ erwartet
- Bis klar ist dass Solaris mit dem OmniOS binary arbeitet.

Am erstes mal /var/web-gui/data/tools/omnios/perl_5.32/ nach /var/web-gui/data/tools/solaris/ kopieren.
Wenn es dann Probleme gibt die Dateien die unter Solaris erzeugt wurden in
/var/web-gui/data/tools/solaris/perl_5.32/CGI/ ersetzen,

mindestens die
/var/web-gui/data/tools/solaris/perl_5.32/CGI/auto/IO/Tty/Tty.so

Finden kann man die mit (sollten unter root liegen)
find /root -name Tty.so

alternativ in Datei /var/web-gui/data/wwwroot/cgi-bin/admin.pl Zeile 954 ändern von
$r="solaris/perl_$p"; in
$r="omnios/perl_$p";


Ich werde das selber auch noch probieren und dann napp-it updaten

 

[Wesumat]

Hallo gea,

habe es mal ad hoc getestet, kam aber leider nicht zum Erfolg. Bin mir aber ziemlich sicher, dass
dies eher an meinen mangelnden Fähigkeiten diesbezüglich liegen wird.

Getestet habe ich zum einen quasi:

1.) nur "doppeln" aus .../omnios/perl_5.32 nach ../solaris/perl_5.32/

root@solCBE:/var/web-gui/data/tools/omnios# cp -r perl_5.32.backup/* ../solaris/perl_5.32/
root@solCBE:/var/web-gui/data/tools/omnios# chown -R napp-it ../solaris/perl_5.32

wobei das perl.32.backup dem unveränderten Zustand aus perl_5.32 entspricht

Fehlerbild weiterhin:

Can't load '/var/web-gui/data/napp-it/CGI/auto/IO/Tty/Tty.so' for module IO::Tty: ld.so.1: perl: relocation error: R_AMD64_PC32: file /var/web-gui/data/napp-it/CGI/auto/IO/Tty/Tty.so: symbol __start_crt: value 0xffff80189f3fdb67 does not fit at /usr/perl5/5.32/lib/i86pc-solaris-thread-multi-64/DynaLoader.pm line 193. at /var/web-gui/data/napp-it/CGI/IO/Tty.pm line 30. Compilation failed in require at /var/web-gui/data/napp-it/CGI/IO/Pty.pm line 7. BEGIN failed--compilation aborted at /var/web-gui/data/napp-it/CGI/IO/Pty.pm line 7. Compilation failed in require at /var/web-gui/data/napp-it/CGI/Expect.pm line 22. BEGIN failed--compilation aborted at /var/web-gui/data/napp-it/CGI/Expect.pm line 22. Compilation failed in require at /var/web-gui/data/napp-it/zfsos/_lib/illumos/zfslib.pl line 2207. BEGIN failed--compilation aborted at /var/web-gui/data/napp-it/zfsos/_lib/illumos/zfslib.pl line 2207. Compilation failed in require at admin.pl line 434.

2.) "doppeln" von modifiziertem .../omnios/perl_5.32 nach ../solaris/perl_5.32/

Hierbei waren hoffentlich die richtigen 4 Dateien aus dem cpan build Ordner zusammengesucht und dort ausgetauscht worden (Tty.so, Tty.pm, Pty.pm und Constant.pm)

root@solCBE:/var/web-gui/data/tools/omnios# cp -r perl_5.32/* ../solaris/perl_5.32/
root@solCBE:/var/web-gui/data/tools/omnios# chown -R napp-it ../solaris/perl_5.32/

Fehlerbild weiterhin:

Can't load '/var/web-gui/data/napp-it/CGI/auto/IO/Tty/Tty.so' for module IO::Tty: ld.so.1: perl: relocation error: R_AMD64_PC32: file /var/web-gui/data/napp-it/CGI/auto/IO/Tty/Tty.so: symbol __start_crt: value 0xffff801a55dfdb67 does not fit at /usr/perl5/5.32/lib/i86pc-solaris-thread-multi-64/DynaLoader.pm line 193. at /var/web-gui/data/napp-it/CGI/IO/Tty.pm line 30. Compilation failed in require at /var/web-gui/data/napp-it/CGI/IO/Pty.pm line 7. BEGIN failed--compilation aborted at /var/web-gui/data/napp-it/CGI/IO/Pty.pm line 7. Compilation failed in require at /var/web-gui/data/napp-it/CGI/Expect.pm line 22. BEGIN failed--compilation aborted at /var/web-gui/data/napp-it/CGI/Expect.pm line 22. Compilation failed in require at /var/web-gui/data/napp-it/zfsos/_lib/illumos/zfslib.pl line 2207. BEGIN failed--compilation aborted at /var/web-gui/data/napp-it/zfsos/_lib/illumos/zfslib.pl line 2207. Compilation failed in require at admin.pl line 434.

Ich glaube ich warte erst mal deine Erkenntnisse ab ;-)


Auch noch aufgefallen war mir, dass man die Schritte zum ermöglichen des TLS-Emails Versands unter Solaris nach dem Update von GA auf CBE noch
einmal wieder durchlaufen musste, damit der TLS Email Versand funktionierte.

Das fluten der shell mit den Hinweisen zum fehlenden pam modul bei Autorisierungen liessen sich zumindestens einfach durch ein
auskommentieren in /etc/pam.d/other von folgendem Eintrag unterbinden.

#auth required pam_dhkeys.so.1