[Sammelthread] ZFS Stammtisch

Prinzipiell gibt es viele Sachen in pkgin oder sfe. Vielleicht fehlt noch etwas.

Prinzipiell könnte man nut auch in ESXi bereitstellen, https://gist.github.com/Dids/ebba2e09a39e273d6adcdfd8028fa439
Für ZFS ist ansonsten ein unerwarteter Stromausfall unkritisch. Dafür gibts ja Copy on Write dass dadurch kein defektes ZFS Dateisystem entsteht.

Der rpool auf vmfs kann beschädigt werden, worst case ist meist ein Booten eines früheren BE. Auch transaktionsbasierte Dienste, Datenbanken und VMs auf ZFS ohne funktionierendes sync write (z.B. kein powerloss protection bei SSD) können problematisch sein.
 
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
Der ESXi Link bezieht sich nach meinem Verständnis eher darauf, einen Nut Client unter ESXi bereitzustellen. Die USV hängt da an einer Synology. Den ESXi später runterfahren, wenn die VMs runter gefahren sind, ist sicher noch ein Thema, aber erstmal muss der Nut Server zum Laufen gebracht werden.

Mir geht es nicht (nur) um die Absicherung des Fileservers, sondern auch um die anderen VMs, die auf der gleichen Maschine laufen. Da der Filer quasi in jeder anderen VM über Shares eingebunden ist, ist es in meinen Augen sinnvoll, ihn zum Nut Server (Master) zu machen, die anderen VMs (und den ESXi Host) zu Nut Clients. Folglich muss ich diesen USB-Driver zum Laufen bekommen.

Hier https://mirrors.omnios.org/nut/ ist noch eine neuere Nut Version (2.8.0) vorhanden, mit pkgin bekomme ich nur die 2.7.4 angeboten. Das wäre noch eine Option gewesen.

Dass noch was fehen könnte, war ja meine Vermutung, weshalb ich wie weiter oben geschhrieben ups-nut-usb über pkgin installieren wollte. Aber da passen die libusb Pakete nicht zusammen... Wenn ich das richhtig interpretiere, ist die installierte libusb eine neuere Version...
Beitrag automatisch zusammengeführt:

Ich habe noch ein wenig bei SmartOS gestöbert und bin auf das Trunk x86 Repository gestoßen. Da ist Nut in Version 2.8.0 enthalten.


Kann ich problemlos auf das Repository schwenken (und falls ja, wie)? DIe Hoffnung wäre, dass entweder der USB-Treiber schon in ups-nut-2.8.0 enthalten ist, oder aber das ups-nut-usb-2.8.0 mit der installierten libusb zurecht kommt...
 
Zuletzt bearbeitet:
Wenn pkgin konfiguriert ist sollte man alle verfügbaren apps installieren können.
Vor größeren Versuchen am Besten ein Bootenvironment erstellen. Dann kann man zurück auf den vorherigen OS Stand.


Im sfe IPS repository ist auch v2.8

Anmelden des sfe Repository:
pkg set-publisher -g http://sfe.opencsw.org/localhostomnios localhostomnios

dann
pkg install ups/nut
 
Zuletzt bearbeitet:
Danke! Habe nun die Version 2.8.0 aus dem SmartOS Repository installiert, aber auch da gab's Inkompatibilitäten mit der installierten libusb. Über pkgin ls habe ich mich rückversichert, dass die inkompatible Version über pkgin installiert wurde und sie dann mittel pkgin remove libusb-0.1.12nb7 wieder runter geschmissen. Danach hat dann auch die Installation von ups-nut-usb funktioniert. So einfach kann es dann doch sein. Dann kann ich mich jetzt mal an die Konfiguration von Nut machen...

Danke für die Unterstützung!
 
Timemachine OSX 12, OSX 13

Ich habe hier gerade ein Macbook Air M1 mit OSX 12.2.1 Monterey
Ich hatte damit kein Problem per SMB ein Timemachine Backup auf OmniOS 151044 (Nov 07) zu erstellen,
SMB funktioniert ebenfalls

Update auf 12.6.2
Timemachine funktioniert, SMB ebenfalls

Update auf 13.1 Ventura
Timemachine funktioniert, SMB ebenfalls

Ich habe auch kein Problem mit einem neu installiertem Windows 11 (22H2) auf OmniOS zuzugreifen (ohne Win 11 auf 128bit Cipher umzustellen)

OmniOS Settings

Service > Bonjour
/usr/bin/dns-sd -R "omnisan" _smb._tcp local 445 &
/usr/bin/dns-sd -R "omnisan" _device-info._tcp local 445 model=Xserve &
/usr/bin/dns-sd -R "omnisan" _adisk._tcp local 445 'sys=waMa=0,adVF=0x100' 'dk0=adVN=timecapsule,adVF=0x82' &

Dateisystem für Timemachine z.B. timecapsule
sync disabled
nbmand on

SMB Settings (Service > SMB > properties)
min_protocol=2.1
oplock_enable=true
signing_enabled=false
signing_required=false

ps
https://www.illumos.org/issues/15214 ist fertig und sollte demnächst auch zur Verfügung stehen (Pending RTI)

Ich habe Thema OmniOS (Solaris) und OSX nochmal zusammengefasst unter
 
Zuletzt bearbeitet:
Performancebetrachtungen für verschiedene Anwendungsfälle
bei Solaris basierten ZFS Servern. Vieles gilt aber generell für ZFS.

Siehe (hab das in Englisch geschrieben, wer da nicht so gut ist, nimmt Google Chrome mit Translate)
 
Ich weiß nicht ob die Frage hier rein passt, aber gibt es ein Backupprogramm mit GUI (Linux), welches ZFS Features wie Datasets unterstützt? Per CMD wird es ja leicht unübersichtlich.
Ich hab schon einige Test von Backupprogrammen gelesen, aber von ZFS nichts entdeckt. Jedes Prog macht irgendwie sein eigenes Süppchen.
 
Jede Plattform die ZFS unterstützt bietet die beiden Consoleprogramme zfs und zpool. Damit lassen sich Dateisysteme syncron halten (Replikation per zfs send/receive) entweder lokal oder mit einem anderen Server, siehe Originaldokumentation von Oracle, https://docs.oracle.com/cd/E24841_01/html/820-2313/gbchx.html

Normale Backupprogramme arbeiten üblicherweise unabhängig von Dateisystem Features. Man hat jetzt die Option eine der vielen Replikationsscripte fürs Backup zu nutzen oder eine allgemeine Storageserver GUI wie FreeNAS, TrueNAS oder mein napp-it zu nehmen. Die unterstützen alle auch ZFS Replikation.
 
Existierenden ZFS Pool ersetzen?

Ich brauche mal eure Hilfe: Ich habe Anfang des Jahres meinen existierenden RAIDZ1 Pool (4x 2TB von 2013!!!) exportiert und in ein neues (DIY) NAS importiert (System 2”). Seitdem habe ich mehrere Nutzer und Gruppen sowie etliche Freigaben erstellt (lokal via User und Group ACLs - nicht über SMB/NFS Freigaben) und alles läuft soweit ganz gut. Jetzt habe ich kürzlich 6x 8TB erworben und möchte den bestehenden RAIDZ1 Pool einfach durch einen neuen RAIDZ2 Pool mit den sechs HDDs ersetzen.

Ich habe noch das ‘alte’ NAS System (“1”), welches aber nur über sechs SATA Anschlüsse verfügt. Meine Idee wäre, die neuen sechs HDDs dort als RAIDZ2 Pool aufzusetzen (mit OS (welches?) auf einem USB Stick), dann die Daten vom neuen System (“2”) auch das RAIDZ2 zu schieben. Dann den RAIDZ2 Pool aus dem alten System exportieren, die Platten in das neue System einbauen und den Pool wieder zu importieren. Fertig.

Geht das? Und gibt’s da Tricks wie ich das ganze migrieren kann, ohne sämtliche User/Groups/Permissions erneut von Hand zu erstellen?

Ach ja, ich nutze omniOS + napp-it!

Vielen Dank!
TLB
 
Das sind eigentlich zwei Fragen.

1.) wie behält man die Windows Datei-Rechte

Das ist bei dem kernelbasierten OmniOS/ Solaris SMB Server besonders einfach da man nicht irgendwelche Mappings zwischen Unix Usern/Gruppen (uid/gid) und Windows Usern/SMB Gruppen braucht. Der kernelbasierte SMB Server nutzt direkt Windows SID als Rechtebezug für lokale Nutzer und kennt Windows kompatible lokale SMB Gruppen sowie für AD Server/Domäne, AD Gruppen und AD Nutzern und speichert die Windows SID als erweiterte ZFS Datei-Eigenschaft ab.

Ist OmniOS in einer AD Domäne? Dann bleiben alle Rechte im neuen Pool automatisch erhalten wenn OmniOS AD Mitglied ist. Wenn nicht (Arbeitsgruppe) wird die Windows User SID aus der Unix uid erzeugt. Wenn man OmniOS neu aufsetzt muss man also nur die alten User mit ihrer alten uid neu anlegen damit die Rechte bleiben, Die zusätzlichen (zu den Unix Gruppen) lokalen Windows SMB Gruppen unter OmniOS/Solaris behalten eh ihre eindeutige Windows SID.

2. wie macht man den Umzug am Einfachsten

Ich würde den Z1 Pool exportieren, in Server 1 einbauen und importieren.

In Server 2 dann die neuen Platten einbauen und den Z2 Pool anlegen. Auf Server 2 dann eine Appliance Gruppe mit Server 1 anlegen (bei napp-it free mit einem 2 Tages Key von https://www.napp-it.org/extensions/evaluate.html). Anschließend auf Server 2 Replikationsjosb anlegen um die Dateisysteme von Server 1 zu holen also z.B. Server1/pool/dateisystem1 -> Server2/pool. Ergebnis ist Server2/pool/dateisystem1. Das mit allen Dateisystemen so machen.

Nach der Replikation sind alle Daten inkl. den alten Rechten und der gleichen Struktur auf Server2. Server 1 mit dem Z1 Pool so lassen und künftig als Backup nutzen.
 
Zuletzt bearbeitet:
Hallo liebe ZFSler,

als Ende 2019 OmniOS r151032 released wurde, gab es kurz darauf hier im Thread eine kurze Diskussion über Probleme im Zusammenhang mit SMB Freigaben und gewissen Android Apps wie beispielsweise Total Commander und FolderSync. Diese Apps konnten bis r151030 mittels SMBv1 ordnungsgemäß auf Freigaben zugreifen, ab r151032 (wo viel bezüglich SMB verändert wurde, unter anderem kam wohl auch der Support für SMBv3 dazu) funktionierte das insoweit nicht mehr, als das man nur noch ins Startverzeichnis kam, nicht aber tiefer in die Verzeichnisstruktur, da der erste Ordner sich einfach immer wiederholte.
Besser beschrieben wird das ganze in diesem Post von damals:

Das SMB Protokoll Serverseitig auf SMBv1 zu begrenzen führte damals leider nicht zum Erfolg und das Ergebnis war letzten Endes andere Android Apps zu nutzen (wobei es für FolderSync meines Wissens bis heute keine funktionierende Alternative gibt), oder vorerst bei r151030 zu bleiben. Da ich Total Commander und Foldersync (bis heute) täglich nutze, hatte ich mich für letzteres entschieden, r151030 wieder installiert und bin seitdem mit napp-it Pro dort geblieben. Habe es zwischenzeitlich immer mal wieder mit aktuellen Releases versucht, aber es funktioniert bis heute auch mit der nunmehr aktuellen r151044 nicht mehr.
Die Android Apps haben seit dem, wie OmniOS auch, Update für Update erhalten. Total Commander und FolderSync haben beide Support bis SMBv3, allerdings zeigt SMBv1 das oben beschriebene Problem und SMBv2 sowie v3 bekommen bei beiden Apps nach wie vor gar keinen Zugriff auf die Freigabe ab r151032. Mit Windows 10 funktioniert hingegen wie immer alles reibungslos. Liegt das scheinbar unlösbare Problem nun an OmniOS oder Android ? Hat irgendwer zwischenzeitlich eine Lösung dafür gefunden ? Es wird ja sicher einige betroffen haben damals... Könnte Solaris 11.4 CBE, von der ich zwischenzeitlich nun noch las, eventuell eine Alternative sein ?
Mal abgesehen davon das r151030 damals sogar eine LTS war, deren Support aber im Mai 2022 ausgelaufen ist und ich nicht mehr ewig auf dieser Version verharren kann, bringt erst die r151032 native ZFS Verschlüsselung, ein Feature das ich auch ganz gerne nutzen würde.


Nachtrag: Auweia, seit über 9 Jahren hier angemeldet und heute der erste Post... und dann steht da aktuell unter dem kryptischem Namen auch noch "Experte" 🙈
 
Zuletzt bearbeitet:
Ich nutze SMBSync2 (SMB2/3) mit OmniOS 151044 (mit Login/pw eines OmniOS Accounts)

Kann sich denn TC oder foldersync als User anmelden oder will es anonymen Gast Zugang?
Der hat sich seit einem älteren OmniOS geändert.

Guest access on OmniOS requires:
- add a user guest
- enable guest access: smbadm enable-user guest
The guest account password is ignored by SMB

Bei der Freigabe "guest allowed" anklicken.
 
Zuletzt bearbeitet:
AW: Existierenden ZFS Pool ersetzen?
Danke für deine detailierte Antwort, gea!

AW: 1.) wie behält man die Windows Datei-Rechte
Das ist mein "Wohnzimmer-NAS" zu Hause, also keine AD-Anbindung.

AW: 2. wie macht man den Umzug am Einfachsten
Das hat schon mal fast alles gelöst. Ich laufe aber in Probleme, da ich einige Filesysteme nicht replizieren kann.
Da wo es hakt, habe ich folgende Verzeichnisstruktur:
Code:
<tank>/Media
<tank>/Media/Filme
<tank>/Media/Filme/Kinder_Filme
<tank>/Media
<tank>/Media/Videos
<tank>/Media/Videos/Kinder_Videos
usw. für Bilder, Musik, Dokumente
Das sind alles Dateisysteme und die Replizierjobs erlauben mir nicht, tiefer als <tank>/Media/ für's Zielverzeichnis einzugeben.
Verstosse ich da mit der Verzeichnisstruktur (Filesystem im Filesystem im Filesystem) gegen irgendwelche ZFS Konvetionen oder ist das ein Bug in nappit? Die Zugrifsrechte funktionieren soweit. Die Idee ist, dass
  1. die Kinder eben nur ''Kinder_Filme", "Kinder_Videos", usw. sehen wenn sie sich mit dem NAS verbinden
  2. ich (als SU) eine einfache Hierachie von der "Media-Ebene" sehe
  3. die Eltern "einfach" im "Filme" Verzeichnis das "Kinder_Filme" Verzeichnis sehen können, und recht einfach (Windows) Filme hin-und-her kopieren können
Alternativ müsste ich eine komplett flache Verzeichnisstruktur erstellen, wo ich das eigentlich "sauber" im "Media" Verzeichnis haben wollte.

Danke!
TLB
 
Wenn es tatsächlich ZFS Dateisysteme sind (in napp-it im Menü ZFS Dateisysteme stehen) sollte Replikation kein Problem sein,
das jeweilige Parent Zieldateisystem muss aber bereits existieren. z.B.
altpool/media/videos -> neupool/media gibt als Ergebnis neupool/media/videos (repliziertes Dateisystem wird unterhalb des Zieldateisystems angelegt)

Unter OmniOS ist es möglich per SMB in tieferliegende Dateisysteme zu wechseln sofern man das in Service > SMB Properties zuläßt (traverse). Solaris läßt das beispielsweise garnicht zu und das aus gutem Grund. Jedes ZFS Dateisystem kann ja unterschiedliche ZFS Eigenschaften haben u.A. Zeichensatz, Dateiblocking, Beachtung von Groß/Kleinschreibung wie bei Unix oder Ignorieren wie bei Windows oder aclinherit bzw aclmode. Im Dateisystem sieht man das nicht. Da stellen sich ZFS Dateisysteme wie einfache Ordner dar, Auch Snaps= Windows vorherige Version kann dann etwas verwirrend arbeiten weil Snaps eine strikte Eigenschaft des zugehörigen Dateisystems und nicht geschachtelt sind. Unter SAMBA kennt man eventuell dieses Problem da SAMBA nicht zwischen einfachem Ordner und ZFS Dateisystem unterscheiden kann.

Neben diesem ZFS Grund würde ich es aber auch lassen weil es keinen echten Vorteil hat und nur alles komplizierter macht z.B. mehr Replikationsjobs oder umfangreichere rekursive. Ich würde ganz einfach nur das Dateisystem Media nutzen und freigeben und alles darunte wie Videos/* oder Musik/* als simple Ordner. Von den Dateirechten sind beide Varianten identisch einzustellen bis auf Probleme wegen anderen ZFS Eigenschaften wie aclinherit.
 
Zuletzt bearbeitet:
Kann sich denn TC oder foldersync als User anmelden oder will es anonymen Gast Zugang?
Total Commander und FolderSync melden sich normal als User mit Passwort an, welcher in nappit hinterlegt wurde. Einen Gastzugang hatte ich nicht eingerichtet, jetzt aber mal getestet. Nachdem ich signing_required noch auf false gesetzt habe, haben die beiden Apps nun zwar Gastzugang, allerdings auch wieder nur über SMBv1 und tiefer wie ins oberste Verzeichnis kommen sie nicht, sprich gleiches Fehlerbild. Auch der User root kommt hier übrigens nicht weiter.

Ich nutze SMBSync2 (SMB2/3) mit OmniOS 151044 (mit Login/pw eines OmniOS Accounts)
SMBSync2 hatte ich vor einer gefühlten Ewigkeit mal getestet, dann aber doch FolderSync wegen der Optik und deutscher Sprache vorgezogen. Damals funktionierten ja noch beide Apps für OmniOS.
Aber was soll ich sagen, es ist halt nicht alles Gold was glänzt, bzw besser aussieht, denn mit SMBSync2 funktioniert der Zugang perfekt. Die unzähligen Einstellungsmöglichkeiten, sowie der Tasker Support sind super und lassen mich positiv gestimmt sein hier alle FolderSync Profile mit teils sehr speziellen Einstellungen migrieren zu können.
Als Alternative für Total Commander hab ich nun X-plore installiert. Diese App wurde hier ja bereits 2020 empfohlen und funktioniert auch bei mir.

Testweise hab ich übrigens auch noch OpenIndiana 2022.10 installiert. Total Commander und FolderSync, welche ich in ihrem Feld ja als das non plus ultra angesehen hatte, haben wie bei OmniOS das selbes Fehlerbild und mit SMBSync2 und X-plore funktioniert es einfach.

Tausend Dank gea für deine schnelle Antwort und den alternativen Appvorschlag (y)(y)(y)
 
Ein Solaris/OmniOS ZFS Server im laufenden Betrieb
"Set and forget" ist keine gute Idee

(in Englisch, Google Chrome kann englische Seiten inzwischen sehr gut übersetzen, Maus Rechtsklick auf die Seite und übersetzen in deutsch)
 
  • Danke
Reaktionen: you
Ich versuche gerade die Replikation zwischen zwei napp-it Servern basierend auf OmniOS derart zu automatisieren, daß der Backup-Server eingeschaltet wird wenn die tägliche Replikation ansteht, dann die Replikation der erforderlichen ZFS-Filesysteme nacheinander durchgeführt wird sowie einmal wöchentlich nach der Replikation ein Scrub des Pools angestoßen wird und der Backup Server schließlich wieder heruntergefahren wird.

Die Automatisierung erfolgt dabei über ssh mit key-basiertem Login und Aufrufen der perl Scripts von nappit über bash-Kommandos auf dem Backup-System. Das geht soweit eigentlich schon recht vernünftig, die Replikation scheint durchgeführt zu werden und auf beiden Systemen sind nach der Replikation die snapshots mit Namen <epoch>_repli_zfs_<backup-hostname>_nr_N vorhanden.

Wo ich mir derzeit allerdings noch unsicher bin, ist die Ausgabe des aufgerufenen Perl Scripts /var/web-gui/data/scripts/job-replicate.pl: Zunächst kommt - auch beim manuellen Start direkt auf dem Backup-Server - immer folgende Ausgabe: "2489:". Das habe ich nach Durchsicht des Perl Scripts auf die Zeile 2617 im Script
Code:
print "2489: $jobid('daisy')\n"
zurückgeführt und scheint daher o.k. zu sein. Deaktivieren ließe es sich nur über eine Änderung des Scripts, die ich aber nicht machen möchte. Das läßt sich aber über Umleitung von stdout recht gut handhaben.

Wo ich allerdings nicht weiß, ob das eine Bedeutung hat oder nicht, ist die Ausgabe danach. Diese lautet in der nächsten Zeile einfach
Code:
Killed
Nachdem ich mich mit Perl nicht wirklich auskenne, kann ich damit nicht wirklich viel anfangen und ein schnelles Durchsuchen der Scripts im Verzeichnis von job-replicate.pl brachte auch keinen Treffer. Allenfalls ist das aber auch ganz harmlos und zeigt nur, daß der Prozess beendet worden ist?

Schließlich macht mich auch noch der Return Wert (Exit-Code) des Perl Script etwas unsicher, weil dieser (offenbar immer?) 137 ist. Konvention in Unix wäre 0 als Returnwert, wenn kein Fehler aufgetreten ist - bedeutet 137 also, daß ein Fehler passier ist und welcher wäre das? Oder hat der Rückgabewert 137 die Bedeutung, alles ok? Wie gesagt, die Replikation scheint ja grundsätzlich das zu tun, was man erwartet ...

Vielleicht könnte ja @gea als Vater von napp-it dazu etwas sagen ...

Besten Dank im voraus, Atom2
 
Wenn man job-replicate.pl manuell starten möchte, benötigt man als Parameter run_jobid z.B. job-replicate.pl run_1234567.
Das Script soll bei Aufruf von der Console Debug/Statusmeldungen ausgeben. Das Script startet einen Monitorprozess
der immer mit einem kill (exitcode 137) endet, https://specificlanguages.com/posts/2022-07/14-exit-code-137/

Bei Aufruf des Scripts ohne Parameter wird es beendet, egal ob es als Vordergrund Programm oder im Hintergrund läuft (kill)

Als Alternative kann man einen Job auch auf every,every,every,once stellen. Dann wird er einmal nach dem Booten ausgeführt, also jedesmal wenn der Backupserver gestartet wird, vgl

Zum Herunterfahren könnte man einen "other-job" oder ein Script starten das nach der Replikation ausgeführt wird, (_log/jobs/jobid.post). Das sollte aber vor einem init 5 prüfen ob noch ein zfs receive oder scrub läuft (ps axw). In Perl z.B. via $r=`ps axw`; Die aktiven Prozesse sind dann in $r.
 
Zuletzt bearbeitet:
Hallo gea,
danke für die rasche Antwort.
Wenn man job-replicate.pl manuell starten möchte, benötigt man als Parameter run_jobid z.B. job-replicate.pl run_1234567.
Ich rufe das Script so auf, wie ich es in der Ausgabe von "ps axl" geseehen habe, wenn der job über die GUI gestartet wird -also wie folgt:
Code:
/usr/bin/perl /var/web-gui/data/scripts/job-replicate.pl "'run_<jobid> $(/usr/bin/date '+%s')'" "''"
wobei <jobid> die Bezeichnung des angelegten, in der GUI als manuell gesetzten Jobs ist, und $(/usr/bin/date '+%s') die aktuelle Zeit als epoch Wert ausgibt
Da das Script bei Aufruf von der Console Debug/Statusmeldungen ausgeben soll, ist der Rückgabewert nicht 0
Das heißt, ob das Script fehlerfrei durchgelaufen ist oder nicht, kann man beim Start von der Console nicht erkennen?
Bei Aufruf des Scripts ohne Parameter wird es beendet, egal ob es als Vordergrund Programm oder im Hintergrund läuft (kill)
Die Ausgabe "Killed" kommt aber trotz Start mit den Parametersn wie oben beschrieben ... also doch ein Grund zur Sorge deswegen?
Als Alternative kann man einen Job auch auf every,every,every,once stellen. Dann wird er einmal nach dem Booten ausgeführt, also jedesmal wenn der Backupserver gestartet wird, vgl
Ich bin gerade dabei, mich dort zu registrieren, weil ohne Registrierung sieht man das nicht wirklich ...
Zum Herunterfahren könnte man einen "other-job" oder einen Script starten das nach der Replikation ausgeführt wird, (_log/jobs/jobid.post). Das sollte aber vor einem init 5 prüfen ob noch ein zfs receive oder scrub läuft (ps axw). In Perl z.B. via $r=`ps axw`; Die aktiven Prozesse sind dann in $r.
Das mache ich aktuell über das bash-Script von einem dritten System, welches auf dem napp-it Backup Server über ssh-login die Replications - eine nach der anderen wie oben beschrieben - startet, erforderlichenfalls den einmal wöchentlichen Scrub anstößt und auf dessen Beendigung wartet und dann den Rechner herunterfährt.
 
Das Script gabelt sich in zwei Prozesse (receive und monitor). Beide können das Script mit kill beenden. Rückgabe ist dann 137 (kill).
Bei Aufruf von der Konsole sieht man den Ablauf

ps
Wie wird der Backupserver eingeschaltet.
Zum Steuern kann man den Hauptserver mit einem "other job" nehmen
 
Das Script gabelt sich in zwei Prozesse (receive und monitor). Beide können das Script mit kill beenden. Rückgabe ist dann 137 (kill).
Bei Aufruf von der Konsole sieht man den Ablauf
Danke - dann bin ich beruhigt ... Ich checke jetzt den Erfolg der Replikation über die beiden Dateien /var/web-gui/_log/{monitor,remote}.log und prüfe dort (mittels head und awk), ob für die Job-ID der zuletzt gestarteten Replikation (das sollte jeweils die erste Zeile in den beiden Dateien sein) hinter der Job-ID am Anfang der Zeile, getrennt durch ein Leerzeichen, die Zeichenfolge "ok" steht. Wenn das gegeben ist, gehe ich davon aus, daß die Replikation erfolgreich war, ansonsten wird eine Fehlermeldung ausgegeben und im Ablauf weiter gemacht.
ps
Wie wird der Backupserver eingeschaltet.
Das ist ein alter Intel S2600CP Server mit Intel RMM. Das Intel RMM kennt zwar ssh (und ein rudimentäres, nicht scriptbares Webinterface), aber keinen login mit key. WOL geht leider auch nicht. Daher blieb nur eine ssh Verbindung über sshpass, wobei das login password über das Environment (export SSHPASS="password") vom aufrufenden bash-Script bereitgestellt wird. Damit läßt sich der Rechner dann doch noch einschalten.
Zum Steuern kann man den Hauptserver mit einem "other job" nehmen
Hatte ich mir zunächst auch überlegt, aber sshpass zum Einschalten des Backup Servers habe ich im OmniOS repository nicht gefunden und daher erfolgt die Steuerung jetzt komplett cron-gesteuert über eine anderen Linux Server unter devuan, bei dem sshpass in den Repositories vorhanden war.
 
Zuletzt bearbeitet:
Hatte ich mir zunächst auch überlegt, aber sshpass zum Einschalten des Backup Servers habe ich im OmniOS repository nicht gefunden und daher erfolgt die Steuerung jetzt komplett cron-gesteuert über eine anderen Linux Server unter devuan, bei dem sshpass in den Repositories vorhanden war.
sshpass für OmniOS siehe

Kann man von da per pkgin installieren oder einfach das Binary per 7zip aus dem .tgz auspacken
 
Zuletzt bearbeitet:
@gea: Eine Frage hat sich bei mir jetzt noch ergeben: Wie erkennt man nach dem Booten eigentlich, ob napp-it bereits aktiv ist oder nicht - mit anderen Worten: Ab wann kann nach dem Start des Rechners eine Replikation erfolgreich gestartet werden? Zur Erklärung dazu:

Ich habe jetzt die Replikation über ein bash-Script soweit fertig, daß es funktioniert. Der Ablauf ist dabei wie folgt, wobei jeder einzelne Schritt voraussetzt, daß der vorhergehende erfolgreich abgeschlossen worden ist - das wird im Script auch geprüft, und so lange gewartet, bis das eben gegeben ist:
  1. einschalten des Backup Servers
  2. Warten, bis ping möglich ist - damit ist der Backup-Server grundsätzlich im LAN
  3. Warten bis ssh-Verbindung möglich ist - damit kann kommuniziert werden
  4. ssh-Verbindung aufbauen und
    Code:
    /usr/bin/perl /var/web-gui/data/scripts/job-replicate.pl "'run_<jobid> $(/usr/bin/date '+%s')'" "''"
    für jedes zu replizierende ZFS-Filesystem aufrufen und für jede Replikation prüfen, ob diese erfolgreich war; falls nicht, Fehlermeldung, aber trotzdem nächste ausführen
  5. falls der richtige Tag, scrub für jeden spezifizierten Pool durchführen
  6. heruterfahren des Rechners
  7. Prüfen, ob Rechner down, falls nicht Fehlermeldung
Was ich nunmehr noch gerne hätte, wäre eine Prüfung, ob napp-it bereits läuft nach Schritt 3 und vor Schritt 4. Das Problem scheint nämlich zu sein, daß ich mit dem Schritt 4 zu schnell starte und damit keine Replikation stattfindet. Meine Vermutung ist, daß napp-it noch nicht bereits ist und damit die perl-Scripts nicht funktionieren. Ich leite das daraus ab, daß ein Start der Replikation bei laufendem System - Aufruf genauso, wie vorher über cron - etwas später einwandfrei geht. Einfach ein delay einbauen - einige Sekunden warten - halte ich nicht für korrekt, weil die Zeit bis alles läuft, ja variieren kann. Und die erste Replikation ewig wiederholen, bis sie geht, ist auch nicht in Ordnung, weil dort ja auch andere Fehler auftreten könnten. Klarerweise würde ich trotzdem alles unter ein Timeout setzen ...

Meine Frage ist daher:
  • Gibt es irgendeinen Prozeß, der, wenn er läuft, definiert, daß napp-it tatsächlich vollständig gestartet und für Replikationen bereits ist?
  • Oder wäre dafür auch ein check, ob port 82 auf dem backup-Server erreichbar ist, die richtige Vorgangsweise?
  • Oder gibt es eine Datei, die, wenn vorhanden, angibt, daß napp-it vollständig initialisiert ist?
  • Oder was wäre sonst der beste check, der über ein script abgefragt werden kann?
Besten Dank im voraus, Atom2
 
Entweder mit ps axw prüfen ob mhttp gestartet ist, z.B. via (+extra wait von ca 1s)
ps axw | grep mhttpd | grep -v grep

oder per wget ein web-connect auf port 81 probieren
 
Entweder mit ps axw prüfen ob mhttp gestartet ist, z.B. via (+extra wait von ca 1s)
ps axw | grep mhttpd | grep -v grep

oder per wget ein web-connect auf port 81 probieren
@gea: Danke für die Antwort. Ich habe das auch bereits so umgesetzt, aber das löst das Problem leider nicht. Nach der Aktivierung aller möglicher debug-Optionen in der Bash denke ich aber, jetzt einen Ansatzpunkt gefunden zu haben ... und der deutet zumindest auf den ersten Blick auf einen möglichen Bug in napp-it hin.

Beim - wie ich glaube: korrekten - Start der Replikation über mein Bash-Script nach dem Hochfahren des Backup Servers bringt ein trace folgende Ausgabe (gekürzt auf die wesentlichen Teile):
Code:
+ cd /var/web-gui
++ date +%s
+ now=1672739761
+ wait
+ perl data/scripts/job-replicate.pl 'run_1672437316 1672739761' ''
(lib-1356 read_dir: /tmp/nappit/) Programmfehler: Kein Directory (ref task_getstate 61)
+ zfs list -H -t snapshot tank/configs@1672437316_repli_zfs_bkp-napp-it_nr_2
+ echo '!! ERROR replicating 192.168.13.2:tank/configs -> 192.168.13.3:tank/configs [ID:1672437316]'
!! ERROR replicating 192.168.13.2:tank/configs -> 192.168.13.3:tank/configs [ID:1672437316]
+ [[ -n '' ]]
Beim Aufruf von job-replicate.pl mit den nach meiner Ansicht korrekten Parametern (Job-ID und timestamp als Argument 1, Leerstring als Argument 2) kommt eine Fehlermeldung von napp-it, nach welcher das Verzeichnis /tmp/nappit nicht vorhanden sei - was auch den Tatsachen entspricht.
Dieses Verzeichnis wird nach meinen Erkenntnissen aber offenbar nicht automatisch beim Start von napp-it angelegt, sondern - sofern man das System nicht interaktiv benutzt - wohl erst, sobald der Zeitpunkt eines möglichen automatischen Jobs zur Überprüfung ansteht.
Da das Auto service bei mir auf "enable auto 15min" gestellt ist, wird das Verzeichnis /tmp/napp-it daher erst zur Minute 00, 15, 30 oder 45 - was auch immer der erste Zeitpunkt nach dem Start ist - angelegt.
Wird das idente bash-Script nach dem Vorhandensein des Verzeichnisses /tmp/napp-it erneut - wieder vom cron - gestartet, so funktioniert die Replikation einwandfrei.
 
Zuletzt bearbeitet:
Ich antworte mir mal selbst: Die nach meiner Ansicht einfachste und sauberste Lösung (zumindest für jemanden, der Perl nicht kennt), um das Problem zu lösen, ist das Startup-Script von napp-it zu modifizieren und dort das Verzeichnis anzulegen. Dazu einfach in der Datei /etc/init.d/napp-it in der bash-Funktion "startcmd()", die ganz am Anfang der Datei steht, die folgende Zeile einfügen:
Makefile:
mkdir -p /tmp/nappit
Ich habe diese Zeile ziemlich am Anfang zwischen den beiden ersten "if / fi" Blöcken eingefügt und halte das (oder den Beginn der Datei) für die korrekte Position.

Zur Erklärung: "mkdir -p" erzeugt das Verzeichnis und generiert auch dann keine Fehlermeldung, falls das Verzeichnis bereits existiert. Wenn man die Zeile daher an der Stelle so eingefügt, kann man sich auch jegliche Abfrage, ob das Verzeichnis bereits existiert, sparen. Auch mit napp-it, welches das Verzeichnis - sofern es noch nicht existiert - ja irgendwann selbst anlegt, kommt man nicht ins Gehege, weil napp-it zum Zeitpunkt der Erstellung des Verzeichnisses durch /etc/init.d/napp-it ja noch nicht läuft. Soweit ich gesehen habe, wird im Code von napp-it vor Erstellung des Verzeichnisses "/tmp/nappit" übrigens an allen Stellen geprüft, ob das Verzeichnis schon existiert und dieses nur dann angelegt, wenn es nicht bereits vorhanden ist.

Diese Lösung ist daher nach meiner Ansicht minimal-invasiv und sollte zu keinen Problemem führen. Falls von @gea eine andere/bessere Variante kommt, ist mir das aber natürlich auch recht. Er kennt seine Software mit Sicherheit besser als ich ...

Besten Dank, Atom2
 
Normalerweise werden alle jobs über auto.pl gestartet. Da wird dann auch ein (otional fehlendes) /tmp/nappit Verzeichnis angelegt.
Es spricht aber nichts dagegen, das vorab bereits im init Script zu machen. Ich habe das in 22.dev (wird gerade 23.01) mal so eingefügt.
 
@gea: Ich hätte da noch einmal eine Verständnisfrage und allenfalls, wenn mein Verständnis korrekt ist, einen Vorschlag, einen zentralen Aspekt von napp-it zu optimieren. Wenn das hier nicht gerne gesehen wird, bitte einfach ignorieren bzw. mir mitteilen und ich lösche dann den Inhalt meines Postings. Ansonsten beschreibe ich mal in aller Kürze, was ich glaube, in bezug auf die Funktionsweise von napp-it verstanden zu haben:

Einer der zentralen Prozesse von napp-it ist nach meinem Verständnis das bash-script "taskserver.sh". Dieses sorgt dafür, daß requests, welche über verschiedenste Kanäle (GUI bzw. automatische Jobs) initiiert werden können, gestartet und dann ausgeführt werden. Dazu überprüft der Prozeß "taskserver.sh" in kurzen Intervallen - wenn nichts ansteht nach meinem Verständnis offenbar jede Sekunde - das Verzeichnis /tmp/nappit auf neue Dateien und sorgt dafür, daß Requests, die dort als Datei hinterlegt worden sind, gestartet werden. Es wird im Ergebnis also ein aktives polling eines Verzeichnisses auf Änderungen - das Vorhandensein von neuen Request-Dateien - durchgeführt. Dieses regelmäßige (sekündliche, vorsorgliche und anlaßlose) polling - es könnte ja zu jeder Zeit ein Request anstehen - ist nach meiner Ansicht nicht wirklich effizient und ließe sich ohne wesentliche Änderung des Rests von napp-it wohl optimieren: Nämlich dadurch, daß der Prozeß "taskserver.sh" einfach über das Vorhandensein von neuen Dateien informiert wird und daher, anstatt selbst im Sekundenrhythmus zu prüfen, einfach bis zu zum Vorhandensein neuer Dateien nichst tut und erst dann aktiv wird. Der gesamte mit der regelmäßigen vorsorglichen Prüfung verbunden Aufwand würde damit mit einem Schlag wegfallen.

Wenn mein Verständnis von der Arbeitsweise von napp-it soweit korrekt ist, denke ich eine Lösung gefunden zu haben, bei der der "taskserver.sh" Prozeß einfach bis zum Vorhandensein einer neuen Datei wartet und nichts tut. Wenn gewünscht, können wir die Diskussion dazu gerne - entweder hier, aber auch per PN - weiterführen, wenn das nicht gewollt ist, bitte einfach um kuze Info und ich lösche dann den Inhalt dieses Postings.

Besten Dank, Atom2
 
Ganz besonders in diesem Forum gibt es einige, die sich bereits intensiver mit den Internas von napp-it beschäftigt haben - bis hin zur Veröffentlichung von Community Add Ons wie Mediaserver oder Infiniband Support. Die Möglichkeit ganz einfach in /var/web-gui/_my/zfsos/ eigene private Menüs hinzuzufügen lädt auch zu eigenen Erweiterungen ein, die unabhängig von napp-it Up/Downgrades bleiben. Der Taskserver kann da gute Dienste leisten.

Prinzipiell ist napp-it eine reine interaktive cgi Anwendung bei der vom Webserver je nach Menü Konsoleprogramme wie zpool oder zfs aufgerufen oder ausgewertet werden. Der ZFS Server läuft damit auch bei deaktiviertem napp-it. Der Taskserver wird für die Grundfunktionen von napp-it nicht eingesetzt. Die Laufzeit von cgi Anwendungen ist aber begrenzt. Langlaufende oder Hintergrund-Aktionen wie anfängliche Replikationen die auch Stunden oder Tage laufen können oder das Löschen tausender Snaps sind mit cgi nicht möglich. Da kommt der Taskserver ins Spiel. Das ist ein Hintergrundprozess der jede Sekunde nachschaut ob es ein neues Shellscript *.sh gibt das ebenfalls im Hintergrund als Dienst gestartet werden möchte. Das Script wird nach dem Start als Hintergrund-Prozess gelöscht. Der Taskserver verbraucht ca 50k RAM und auf einem langsamen Dualcore Atom ca 0,1% CPU, siehe prstat. In der allermeisten Zeit macht Taskserver nichts sondern ist im Sleep Modus und prüft jede Sekunde ob neue Aufgaben anliegen. Da nicht vom Datenpool gelesen wird und das Lesen nur von rpool und fast immer aus dem Arc Lesecache erfolgt, gibt es auch keine Storage Last.

Ich lasse mich aber gerne überzeugen falls es eine effizientere Methode gibt. Taskserver ist aber bereits extrem minimalistisch, zuverlässig und sehr effizient da er praktisch nichts macht außer Warten. Ich habe für diese Anwendungen ursprünglich "at now" benutzt. Damit können aus einer cgi Anwendung direkt Hintergrundprozesse gestartet werden. allerdings war das nicht so zuverlässig. Manchmal blieben Jobs in der at Queue hängen.
 
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