[Sammelthread] napp-it 4ai, client-server Web-GUI für ZFS Server (any/mixed OS)

[gea]

Im Kern bleibt es natürlich so dass die Qualität eines Passwort(hash) mit der Länge des pw steigt.

Es geht bei dieser Funktion letztlich darum,:
- alle key gleich lang, auch bei kurzem pw
- wenn der Hash oder ein Teil davon abgegriffen wird, so soll man daraus nicht einfach per Tabelle auf das pw schliessen können
- dataset name ist quasi das Hash Salz. Damit wird verhindert dass besonders einfach aus dem Hash das pw ermittelt wird
- man kann damit einfach merkbare pw als key nehmen wie "meine Katze heisst Fritz"

Insgesamt gilt natürlich, das ist nur ein Kiss Hilfsmittel. Bei Besonderheiten oder Änderungen auch bei alten Datasets muss man den alten Key kennen und eingeben, die easy 123 Option geht dann nicht.

ps
wenn man den alten key kennt, kann man einen neuen, passenden setzen: zfs change-key pool/dataset.
In System > SHA256hash kann man den key aus hash der art datasetpath + pw generieren

 

[Rach78]

okay das verstehe ich. Aber als salt würde ich persönlich doch eher eine Dataset Eigenschaft nehmen die nicht veränderbar ist wie zB entstehungsdatum oder ein random string der als optionales ZFS Parameter an das Dataset geheftet werden kann (sofern möglich). So würde ein rename von Pool und/oder Dataset hier für keine Probleme sorgen. Den Namen finde ich etwas suboptimal hier aus den genannten Gründen weil ich damit eine ungewollte und unnötige Abhängigkeit zwischen 2 Dingen herstelle die gar nicht vorhanden sein muss.

Änderungen auch bei alten Datasets muss man den alten Key kennen und eingeben,

Wie entsperrt man denn in CS ein Dataset was schon etwas älter ist und mit SE erstellt worden ist? Habe das nicht hinbekommen. Der Key 1:1 wird von SE akzeptiert von CS aber nicht. Und wenn ich in CS über die sha256 hex funktion Poolname+Datasetname+Key nehmen und dadurch nen Hash generiere und mit diesem Hash versuche zu entsperren geht auch nicht.

Also ist kein Weltuntergang weil entsperren durch SE ja nocht geht aber wollte eigentlich komplett nur noch CS am Ende irgendwann dann am laufen haben.

 

[gea]

ist wie immer ein Kompromiss zwischen KISS und Sicherheit.
Eine deutliche Verbesserung wäre nur ein random salt, dann muss man den aber irgendwo mitführen. Eine private ZFS property ist auch nicht unproblematisch weil die nur bei zfs send -p oder -r übertragen wird. Ein salt als Keyanfang wäre denkbar, ist aber inkompatibel zum aktuellen key. Käme als Switch infrage wenn künftig nötig.

Generell gilt, der dataset name soll vor allem die Sicherheit bei sehr kurzen PW wie 123 verbessern, ansonst

Gemini: "Ein SHA-256-Hash (unabhängig davon, ob er als Hexadezimal-String oder Rohdaten dargestellt wird) gilt nach heutigem Stand der Wissenschaft und Technik als extrem sicher und für praktische Angriffe als unknackbar"

Zum Öffnen von enc se datasets in cs Menüs
Das Problem ist, dass cs kurze keys aus se <31 char als Passwort und nicht als Key sieht. Man müsste also das Dataset mit dem alten key in se oder auf console in cs entsperren und dann mit einen langen oder passenden sha256hex key versehen.

 

[Rach78]

Käme als Switch infrage wenn künftig nötig.

Ja ich seh das halt nur als suboptimal an was die usebility angeht. Einmal den Namen geändert und schon lässt sich nicht mehr entsperren mit dem kurzen pw und am Ende weiß kein Mensch mehr wieso "ach stimmt da war ja was hab das Dataset mal umbenannt". Auf meinem Backupserver heißt der Pool ggf auch anders.

Eine private ZFS property ist auch nicht unproblematisch weil die nur bei zfs send -p oder -r übertragen wird

Muss ja einfach nur etwas sein was halt über die ganze "lebzeit" des Datasets quasi identisch bleibt. Ansonsten muss man es irgendwie mit speichern ja. Könnte man aber ja mit dem Backup der Configuration machen.

Der Salt selbst muss ja darüber hinaus auch kein Geheimnis sein. Wäre ggf auch okay wenn jedes Dataset was auf dem selben Server erstellt wird erstmal das gleiche bekommt und optional dann zu ändern wäre.

 

[gea]

Letztendlich führt nichts an der Erkenntnis vorbei, das jedes Bemühen ohne eine Mindestkomplexität des PW vergeblich ist. Jede Salt oder Pepper Variante um kurze PW hash sicher zu machen sind vergeblich wenn Salt oder Pepper auf dem Rechner oder dem Dataset verfügbar sind.

Ich werde wohl dazu übergeben
- das jetzige Verfahren mit passsphrase und dataset zu belassen (Kompatibilität), hilft etwas gegen Hash Tabellen für pw wie 123)
- bei der PW Eingabe deutlich zu machen oder gar zu fordern, dass ein PW aus drei Worten, getrennt durch Sonderzeichen, idealerweise mit einer Zahl bestehen MUSS um sicher zu sein z.B. Katze-Mond-Hammer oder noch besser mit einer Zahl zusammen wie Katze-Mond-Hammer24 (Groß/Kleinschreibung egal)
- Beim Öffnen Kompatibilität mit kurzen se Alt-Keys herstellen z.b. durch retry on error

 

[Rach78]

Jede Salt oder Pepper Variante um kurze PW hash sicher zu machen sind vergeblich wenn Salt oder Pepper auf dem Rechner oder dem Dataset verfügbar sind.

Nein. Afaik ist die Aufgabe von Salt die einen Angriff über Rainbow Tables zu verhindern. Sprich auf große Tabellen zurückgreifen zu können wo man einfach nur nach dem Hash suchen kann, der dann auf das Passwort "123" zurückzuführen ist.
Durch den Salt ist das Passwort von dem der Hash gebildet wird nicht mehr 123 sondern 123+Salt und die Rainbow Table ist nutzlos sofern sie nicht zu exakt diesem Salt passt was äußerst unwarscheinlich ist.
Also der Salt an sich ist nichts was besonders schützenswert ist, das Geheimnis sollte am Ende so oder so das Passwort sein. Wenn man einfache Passwörter unterbinden will muss man sie bei der Vergabe schon ablehnen (Mindestlänge, mindestens GroßKleinschreibung, Zahlen etc)

Was einfache Passwörter angeht verhindert ein Salt auch nur den Angriff über RainbowTables. Der Salt muss ja so oder so immer auf dem Rechner gespeichert sein sonst kann der Rechner bei der Passworteingabe ja den korrekten Hash mit der Salt gar nicht bilden.
Und der Poolname und Datasetname ist ja ohnehin immer sichtbar und über den Quellcode vo Nappit bzw Doku ist ja eh bekannt wie der Salt lautet. Wenn ich Poolname und Dataset Name kenne kenne ich eh schon den Salt.
Das ist nicht schlimm, aber im Grunde könntest du statt diesem String auch einen anderen nehmen, das würde sicherheitstechnisch gar kein Unterschied machen.

Beispiel wie es bei mqtt Broker Mosquito läuft: https://dmelo.eu/blog/mosquitto_passwd_gen/

Der salt wird einfach zufällig erzeugt und dann mit abgespeichert.

wenn Salt oder Pepper auf dem Rechner oder dem Dataset verfügbar sind.

Sind sie bei der aktuellen Umsetzung aber eh weil Dataset und Poolname bekannt sind.

Ich sehe hier eine grundsätzliche Frage die man klären muss: Möchte ich das Dataset mit dem kurzen Passwort auch auf anderen Servern öffnen können oder will ich das nicht.
Wenn ich das eh nicht will würde ja nichts dagegen sprechen den Salt einfach auf dem Server selbst zu belassen. Dann kann ich das Dataset in Server1 der den passenden Salt zu dem Dataset kennt eben mit dem kurzen Passwort öffnen, aber anderswo benötige ich dann die volle passphrase.
Will ich auf Server2 auch mit dem Passwort öffnen können muss ich den Salt mit rüber kopieren. Ich meine es gibt ja pro Dataset eindeutige IDs worüber dann die Salt mit dem passenden Dataset zu verknüpfen wäre sodass Nappit weiß welche Salt es für welches Dataset nehmen muss. ggf wäre auch die guid denkbar als salt. Diese sollte ja immer gleich bleiben auch wenn ich den Pool umbenenne (mit dem Nachteil dass diese dann natürlich nicht mehr zu ändern ist so einfach), da bin ich aber nicht tief genug in ZFS drin und weiß net was bei Cloning ggf passiert mit der GUID etc.

Oder man spart sich das mit dem Salt und sagt einfach der User soll vernünftige Passwörter einsetzen.

 

[gea]

Genau das ist der Kern des Problems

Pw 123 oder 123Salt unterscheiden sich nur in der Frage ob es Sekunden, Minuten oder allenfalls Stunden dauert um das PW aus dem Hash zu ermitteln. Wenn man das so akzeptiert kann man den Salt/Pepper Aufwand bei single Word PW lassen. Ohne vernünftige PW (z.B. 3 Worte mit Bindestrich, idealerweise mit Zahl z.B. Hase-Mond-Stein24) wird das nichts.

 

[gea]

Interaktive Remote Console (Puttý alike)
Für Nutzer voller Consolezugriff (System > Console)

Für AI nach Console Modus Freigabe + manueller PW Eingabe
AI kann dann selbstständig Checks, Installationen oder Reparaturen vornehmen.

napp-it_4ai_rc_26.09.06.09
(currently you must download dev edition for new features)

- cs-console for any member OS (first rc)
Console and Expect mode for interactive commands eg change user pw
https://github.com/guenther-alka/cs-console

Update in About > Frontend Update (update dev release)
Use menu About > Download cs tools to download cs console on member
Open Menu System > Console for a full intractive console on member

 

[Rach78]

Wenn man das so akzeptiert kann man den Salt/Pepper Aufwand bei single Word PW lassen. Ohne vernünftige PW (z.B. 3 Worte mit Bindestrich, idealerweise mit Zahl z.B. Hase-Mond-Stein24) wird das nich

Bei der aktuellen Umsetzung würde ich persönlich es lieber weglassen weil mir die Verbindung Salt=Poolname+Datasetname nicht gefällt und ich hier eine unnötige Fehlerquelle sehe wie schon erklärt wegen Umbenennung oder weil mein Pool auf meinem Backuprechner vielleicht schon anders heißt.
Sofern nicht geschehen sollte das zumindest in die Doku dass ein Umbennenen hier etwas "kaputt machen" kann. Sonst weiß man ggf nichtmal woran es liegt.

 

[gea]

Ich werde in der nächsten Version nur noch hash aus pw als hash quelle nutzen, kein Pfad mehr aber mit der Aufforderung drei Worte mit Trennzeichen optional mit Zahl al pw zu nehmen. Das bisherige Verfahren bleibt dann nur als Fallback beim Unlock, genau wie Keys aus se. Kompletteingabe des SHA256 Keys bei unlock bleibt immer eine Option, kompletter key sollte immer irgendwo gesichert sein.

Bin nur die nächsten Tage eingespannt, das muss ein paar Tage warten.

 

[Rach78]

Kompletteingabe des SHA256 Keys bei unlock bleibt immer eine Option, kompletter key sollte immer irgendwo gesichert sein.

Ja das wäre vom Verhalten dann identisch zu Windows und Bitlocker. Normalerweise reicht der Pin zum entsperren. Und im WorstCase das Wiederherstellungspasswort.

Mit dem langen Schlüssel bekomme ich es dann auch entsperrt in anderen Betriebssystemen wie zB TrueNAS etc.

Der einzige " Schönheitsfehler" ohne Salt wäre nur dass identische Keys/Passwörter zu gleichen Hashes führen. Aber der Hash selbst ist ja sowieso nicht auf dem Server gespeichert weil er das eigentliche Geheimnis darstellt. Denke das dürfte hier aber irrelevant sein und stellt kein Problem da.

Das Problem ist, dass cs kurze keys aus se <31 char als Passwort und nicht als Key sieht. Man müsste also das Dataset mit dem alten key in se oder auf console in cs entsperren und dann mit einen langen oder passenden sha256hex key versehen.

Ich weiß nicht ob ich das korrekt verstehe aber meine alten SE Keys sind 64 zufällige Zeichen. Dürften also nicht unter die Kategorie unter 31 Zeichen fallen und er nimmt sie trotzdem nicht.

 

[gea]

Ich weiß nicht ob ich das korrekt verstehe aber meine alten SE Keys sind 64 zufällige Zeichen. Dürften also nicht unter die Kategorie unter 31 Zeichen fallen und er nimmt sie trotzdem nicht.

Waren die Keys in se passphrase?
Dann sollten sie funktionieren, wenn nicht müsste man das umstellen.

 

[Rach78]

ssdpool/123	encryption	aes-256-ccm	-
ssdpool/123	keylocation	prompt	local
ssdpool/123	keyformat	passphrase	-

Beitrag automatisch zusammengeführt: 07.09.2026

Wenn ich in CS versuche zu unlocken ist das Feld aber auch vorausgefüllt mit "prompt". Keine Ahnung ob das etwas zu sagen hat. Mein Key nimmt er jedenfalls nicht

Nachdem man den Key eingegeben hat und auf Bestätigen klickt kommt:

oops...​

error:: keylocation must be file:// (is: prompt)


back/ return to former menu



Die Datasets wurden damals auch über Nappit SE angelegt, also die WebUI

 

[gea]

es gibt eine neue .dev die enc datasets aus se öffnen sollte.

 

[Rach78]

Ja funktioniert. Allerdings tauchen die SMB Freigaben (von den entsperrten Datasets) bei mir erst dann auf wenn ich nach dem entsperren nochmal den SMB Server neustarte über die Webgui

 

[gea]

Das ist das Normalverhalten. Ich kann aber ein SMB restart nach unlock in napp-it 4ai/cs für Linux und OmniOS einbauen.

 

[Rach78]

Weiß nicht ob das notwendig ist, wenn dann konfugierbar. Weil ggf unterbricht ein Restart ja andere Filetransfers und da ist dann die Frage ob man das will

 

[gea]

Ein Restart des SMB Servers wird sonstige laufende Transfers abbrechen, ein automatisches Restart kann in der Tat problematisch sein. Ein Refresh/Reload wäre eine Option. Eigentlich sollten SMB Shares automatisch ohne SMB Server restart wieder zur Verfügung stehen.

Eine Unlock Funktion die mit jedem ZFS auf jedem OS mit jedem Client arbeitet, sollte aber vermutlich besser auf ein auto reload verzichten.

 

[Rach78]

Ja. Spielt für mich in der Praxis aber eh nicht so die Rolle weil beim Hochfahren des Servers die Datasets dann einfach automatisch entsperrt werden sollen und bleiben.
Ein Backup Server hat dann im Idealfall eh keinen Schlüssel, den er zum sichern ja eh nicht benötigt.
Man könnte beim manuellen Entsperren ggf ne Checkbox machen in dem Fenster die den SMB dann neustartet. Die kann man dann optional beim entsperren aktivieren bevor man auf okay drückt.

 

[gea]

Ja, sehe ich auch so, SMB restart allenfalls als Option beim Unlock

 

[gea]

Die neuen CS-Tools insbesondere das AI Helpdesk mit optionalem AI Consolezugriff als root/administrator nach Bestätigung und manueller Passworteingabe (ai soll ja nicht alles wissen, ideal für Fehlersuche und Setup) sowie eine echte interaktive Console (wie Putty für jede der 8 unterstützten OS Optionen) sind jetzt im normalen napp-it 4ai (client/server)

CS-Tools (sind eigenständige Binaries, laufen auch ausserhalb von napp-it)

CS-Tools & Scripts — napp-it

 

[gea]

Update cs-aihelpdesk auf 1.2.7
improved ui and ai communication

GitHub - guenther-alka/cs-aihelp: AI Helpdesk module for napp-it cs: chat helpdesk in the web-GUI with free/cloud LLM providers, RAG, optional web research and chat history.

AI Helpdesk module for napp-it cs: chat helpdesk in the web-GUI with free/cloud LLM providers, RAG, optional web research and chat history. - guenther-alka/cs-aihelp

github.com

CS-Tools & Scripts — napp-it

Update:
About>Update Frontend
About>Update cs-tools

 

[AliManali]

Ja, @gea, so sehr ich Deine Arbeit schätze. Aber mich verunsichern die ganzen neuen Versionen alle Nase lang. Hatte echt eine Woche rum gebastelt, bis ich nur mal SE und CS auf beiden Servern zum laufen gebracht habe. Die napp-it ai wäre eine dritte GUI daneben, sehe ich das richtig? Fragt sich halt, ob ich das brauche. Und ob die allenfalls meine GUIs irgendwie beeinträchtigen könnten.

Habe es auch nicht wirklich so installiert wie von Dir vorgesehen. Napp-it SE läuft hier auf :81, napp-it CS auf :8080. Und funktioniert halt so auch nicht ganz alles, aber für meine Zwecke reicht es soweit. So z.B. die Links, um von SE nach CS zu switchen. Ist ja auch logisch, wenn die auf anderen Ports laufen. Musste da sehr kreativ vorgehen, dass ich es überhaupt irgendwie zum laufen gekriegt habe.

Würde ungern nochmal eine Woche investieren. Und noch schlimmer: habe da bisschen Angst vor, die beiden Filer noch komplett abzuschiessen. Ist ja immerhin kritische Infrastruktur.

Wie gesagt, sind zwei alte OmniOS, welche ich von Deiner alten Website als ESXi AiO OVA mal runter geladen hatte. Halt super verbastelt, aber läuft.

 

[gea]

Es gibt zwei Versionen

1. napp-it SE (Illumos/Solaris Edition) seit über 15 Jahren
Benötigt einen Online Installer der den Webserver, SMB, sudo und user installiert/konfiguriert und läuft nur auf Illumos/Solaris.
Diese Version erhält nur noch bugfixes, keine neuen Features

2. Die neue client-server Version die zentrales Management eines any/mixed OS Storage Cluster erlaubt.
Der volle Name lautet napp-it 4ai (client-server). Die ist noch rc und wird napp-it se ablösen.

Den Zusatz 4ai habe ich angefügt weil es folgende AI Features hat
- AI Helpdesk (voller interaktiver console Zugriff für AI nach Freigabe und manueller root pw Eingabe)
- AI Video/Audio Indexer mit Selectfunktion (Ordner mit links auf Originale)
- AI Inhouse Provider (Mac mini/Studio oder dicke Workstation mit api key Verwaltung
- AI Training data für napp-it damit AI erweitern, helfen oder auditieren kann

Künftig wird die neue Version die alte SE ablösen. Es sind bereits jetzt alle wichtigen SE Features enthalten.
Die neue Version ist echtes Copy and Run, läuft ohne irgendwelche Änderungen am Host OS.

 

[gea]

Napp-it 4ai (client-server) unterstützt jedes OS für die Frontend web-gui und das backend remote management, auch gemischte Cluster von Free-BSD über Linux, Illumos/OmniOS, OSX, Solaris bis Windows Desktop oder Server, wo angebracht für Arm64 oder X64. Für Neueinsteiger oder bei größeren Anpassungen stellt sich aber immer wieder die gleiche Frage: welches OS, teils welche Hardware und welches Dateisystem?

Wenn man die Wahl hat, entweder weils ein eigens konfiguriertes System ist und OS und NAS nicht fest verbunden sind (Synology, Qnap etc)
oder weil man ein beliebiges OS aufspielen kann, dann sehe ich das so.

Hardware:
Eher X86 als Arm (bei OSX Arm)
4-16 GB für reines NAS, 16-128GB für All in One (Hypervisor + NAS z.B. mit ESXi oder Proxmox),
48-196 GB für Inhouse AI Provider (Arm Mac mini/studio), ECC wenns der Geldbeutel und die Hardware zuläßt.

Tiny hardware z.B. Raspberry: möglich aber arg limitierend, besser uATX/ATX mainboards mit AMD/Intel CPU
Wechseleinschübe für Platten: sehr sinnvoll
Anzahl Platten: 1x OS ab 64 GB+ 2x NVMe (special vdev) + 2HD (Daten) oder mehr

Dateisysstem
ganz klar ZFS, ist was Features und Stabilität angeht ntfs, ext3, XFS oder anderen neuen Dateisystemen wie btrfs/ReFS überlegen
Eine sinnvolle Ergänzung ist S3 für inhouse Internet Clouds mit ZFS im Lan.

Mainstream OS
Neueste ZFS Features: Linux, meine Lieblingsdistribution ist Proxmox weil da sehr guter Hypervisor und ZFS immer dabei ist
Windows 11 Pro ider Workstation (Desktop), weil mans kennt, ZFS ist noch release candidate, vorher für die geplante Nutzung testen
Windows Server (billige Essentials), wenn man SMB Direct und 25/100G für 4/8k Videoschnitt braucht

Spezialisten
Besonders robust, minimalistisch und einfachster SMB Server mit Top ACL Unterstützung: OmniOS (Solaris Fork mit nativem SMB/NFS/ZFS)
Wenn mans kennt und liebt: Free-BSD, immer noch etwas schneller und robuster als Linux
Wenn mans kennt und liebt, oder einen Inhouse AI Provider zusätzlich braucht: OSX

 

[gea]

Disclaimer
Ist mir hier im Luxx noch nicht passiert aber anderswo erhalte ich häufig Kommentare, dass ich lediglich AI Müll poste.

Dies ist kein AI Text sondern meine Empfehlung. Bei ZFS und Storage wird AI teils mit meinen Erfahrungen trainiert, z.B. mein 3M Thread https://hardforum.com/threads/openz...-storage-spaces-with-napp-it-web-gui.1573272/

Man kann auch gerne AI z.B. Gemini fragen:
Is Gea a well known ZFS and Storage specialist?

Yes, Gea is very well known in the storage and ZFS community.

He is best known as the creator and developer of napp-it, a premier web-based management GUI and appliance tool for ZFS (and enterprise storage). For well over a decade, he has been a prominent figure on storage forums—particularly on ServeTheHome and ComputerBase—where he is widely recognized as an expert voice on ZFS implementations, cross-platform file sharing (SMB/NFS), and storage management across operating systems like Illumos/OmniOS, Solaris, Proxmox/Linux, FreeBSD, and Windows.

 

[gea]

Ich habe mal ein Perl basiertes Benchmarkscript hochgeladen. Damit kann man schnell Pools auf verschiedenen OS vergleichen und testen ohne dass man im OS etwas installieren muss, https://github.com/guenther-alka/cs-scripts/tree/main/benchmark

Das Script kann man auch ohne napp-it nutzen via
perl /path_to_script/benchmark_worker.pl profile=quick pool=tank

Es ermittelt auf die schnelle grob sequ read/write, sync write und iops, vergleicht 1 user vs 2 oder 5 user sowie concurrenr read write. Man kann auch andere Profile wählen als quick dazu für SSD einen steady write test für 45min um zu sehen wie stark die SSD einbricht. Im Scriptordner liegt danach ein Detail-Log

Dazu das Menü und das AI Helpdesk mehrsprachig. In About > Settings die default Sprache und im Topmenü eine ad-hoc Umschaltung

 

[gea]

Ich habe gerade Claude gebeten den RAM Verbrauch von napp-it 4ai im idle und unter Last zu ermitteln.

Napp-it 4ai besteht im Wesentlichen aus zwei Teilen

1. Frontend (web-gui) mit den Diensten
- webserver.pl (Perl basierter webserver)
- proxy (http,https,AI api keyverwaltung)
- auto.pl (Jobverwaltung)

Die Frontend Dienste werden nur auf dem Rechner benötigt, mit dem man den oder die Server managen will.
Ein Rechner kann viele Member verwalten.

2. Backend (remote control)
- server.pl (socket server für remote control)
- monitor.pl (Monitoring, Diensteüberwachung, Caching)

Die Backend-dienste werden auf den Member benötigt damit das Frontend remote darauf zuzugreifen kann.
Bei nur einem Server laufen sowohl Frontend wie Backend-dienste auf diesem Rechner.

Im Idle hat Claude folgendes ermittelt

und unter Last

Insgesamt zu vernachlässigen. Das Client Server Prinzip mit dem Perl basierten Webserver ist extrem effizient und nimmt Proxmox fast nichts weg,
viel weniger als übliche Lösungen mit Apache oder z.B. TrueNAS wo der Resourcenverbrauch in GB und nicht MB gerechnet wird, Napp-it cs geht damit
auch auf einem 2GB Raspberry.

Natürlich kann es im Betrieb ganz anders aussehen. Ein "zfs get all" auf einem großen Server wird schnell sehr viell Speicher anfordern. Auch Dienste wie
RustFS oder Echtzeit Folder/Server Sync können viel RAM verbrauchen.

 

[gea]

RustFS S3 Server ist released

RustFS | High-Performance S3 Object Storage for AI & Cloud-Native

RustFS is an open-source, Apache 2.0-licensed distributed object storage system built in Rust. A high-performance, drop-in replacement for MinIO and Amazon S3 engineered for AI workloads.

rustfs.com

Warum RustFS?
- 1:1 Ersatz für minIO, der bisherigen Hauptoption für ein inhouse/at home S3 Share (nur noch kommerziell verfügbar)

Warum überhaupt S3 shares, ich habe doch ZFS und SMB shares?
- ZFS ist ideal als gemeinsame Lan Ablage mit SMB. Man kann gemeinsam mit aktuellen Daten arbeiten und den Zugriff mit ACL regeln
Zugriff oder Freigabe der Daten im Internet ist aber ein Problem. Direktes Arbeiten über VPN + SMB ist zwar möglich,
aber meist nicht sinnvoll wegen zu geringer Performance. Meist sollte man das Dokument erst herunterladen.

SMB im Internet ohne VPN ist ein nogo/ massives Sicherheitsleck, ideal ist Zugriff über authentifiziertes https so wie bei Cloud Providern wir Google. Genau das bietet S3. Da ist jede Datei eine Url im Internet, direkt herunterladbar per browser oder RustFS web-console (die auch hochladen kann). Alternativ kann man beliebige S3 Browser nehmen, als Einfachsten WinSCP im S3 Folder Modus.

Ein weiterer Aspekt ist Backup. Zwar bietet ZFS remote Replikation, das ist aber nicht realtime, benötigt ein spezielles Job Setup sowie VPN oder Tunnellösungen oder SSH als root. Mit S3 kann man einfach Backups übers Internet erstellen, entweder mit rclone (rsync for cloud) oder restic. Das verschlüsselt, dedupliziert und versioniert die Daten.

Realtime Backup
Ein weiterer Aspekt ist realtime Backup. Das bietet RustFS mit Realtime 2Wege Single Bucket Sync or Host Sync (alle Buckets). Dabei wird eventgesteuert jede Änderung auf einer oder der anderen Seite sofort auf dem Partner aktualisiert. Einmal eingerichtet, handhabt das RustrFS selber im Hontergrund

SMB +S3
Die beiden ergänzen sich ideal, SMB lokal und S3 als Share im Internet. Allerdings kennt S3 keine File ACL und kein File Locking, arbeitet immer auf Uer Basis (User hat Zugriff oder nicht. Ideale Ergänzung für SMB+S3 Shares ist eventgesteuertes bidir sync zwischen S3 und SMB. Damit erscheint jedes per SMB angelegte oder S3 hochgeladene Dokument sofort im anderen Share, https://github.com/guenther-alka/cs-sync

Setup in Napp-it
Vorab Dateisystem "pool"/s3_storage anlegen, dann

1. RustFS, rc, rclone und restic herunterladen (Menü Pool > S3 > local services)
2. Rustfs configurieren und starten
3. Cluster einrichten (mehrere RustFS) in Menü Pool > S3 > Remote Pool

Backup Jobs für rclone oder restic anlegen
Sync Service S3 <-> SMB anlegen (Menü Services)

https://www.napp-it.org/pdf/s3_storage_guide_de.pdf

Im Clustermodus werden S3 secrets und restic pw nur auf dem Frontend Management Server gespeichert, nich auf den Cluster Members

 

[gea]

Howto

Jobs mit napp-it 4ai (client server)
https://www.napp-it.org/downloads.html (jobs & services.pdf)

Jobs werden im Menü Jobs angelegt und können je Jobart angezeigt werden. Jobs könnnen manuell, zeitbasiert über den auto.pl Dienst oder beim Booten ausgeführt werden. Mit Klick auf die Jobid können Parameter geändert werden. Menü Jobs zeigt Übersicht der letzten Job aktionen, Mit Klick auf Jobart z.B. replicate sieht man die letzten logs dieses jobs, mit Klick auf "last" sieht man die Details der letzten Jobausführung

Backup Jobs folgen üblicherweise der 321 Regel als Minimalforderung: Drei Kopien der Daten (idealerweise mit Snap Versionierung stündlich für heute, täglich diesen Monat,..), auf zwei Datenträgern, einer davon extern.

Napp-it 4ai client-server unterstützt Backup/Restore Jobs auf gemischten Servern mit jedem OS von Free-BSD über Linux, Illumos, OSX bis Solaris und Windows. OS-einheitliche Verfahren sind da normalerweise schwierig bis unmöglich, da jedes OS andere Tools, Varianten und Optionen bereitstellt. Gelöst wurde das Problem mit den cs-tools für jedes OS die nicht nur eine einheitliche Schnittstelle bereitstellen, sondern Fähigkeiten bereitstellen, die so normalerweise nicht zur Verfügung stehen.

Napp-it Backup Jobs arbeiten Optionen mit cs-tools (single file binaries für jedes OS die mit Go erstellt wurden).
Die cs-tools sind Bestandteil von napp-it 4ai/cs, können aber auch ausserhalb z.b. in eigenen Scripts oder Batchfiles genutzt werden.

CS-Tools & Scripts — napp-it

Services sind Hintergrunddienste die entweder bei Bedarf oder automatisch zusammen mit napp-it gestartet werden
more to come

ZFS Replikation, das "traditionelle" Verfahren der Datenübertragung bei ZFS (Menü Jobs > Replikation)

Dabei werden zwei ZFS Datasets (Dateisysteme oder Zvols) lokal oder über das Netz syncron gehalten. Es basiert auf ZFS Snapshots und überträgt nur neue oder geänderte ZFS Datenblöcke als Datenstrom und ist daher überragend schnell. Selbst Petabyte Hochlastserver mit Millionen Dateien lassen sich damit im Minutenbereich syncron halten inkl. offener Dateien im letzten Stand. Übers Netzwerk nutzt man oft mbuffer bzw netcat unverschlüsselt oder ssh verschlüsselt zum Transport der Daten. Replizieren kann man prinzipiell OpenZFS mit Illumos ZFS und Qnap ZFS als eigenständige ZFS Entwicklungen nicht aber mit Oracle Solaris Original-ZFS.

Das cs-stream Tool ersetzt dabei für jedes OS einfaches netcat oder mbuffer (schnellere gepufferte Übertragung), ssh (Verschlüssellung) oder pv (reduzierte Datenraten damit ein langsmer Internetzugang nicht blockiert wird). Auch unverschlüsselte ZFS Dateisysteme werden über einen mittels Einmalpasswort verschlüsselten Tunnel gesichert übertragen, siehe https://github.com/guenther-alka/cs-stream

Beim Anlegen eines Replikationsjobs (any Server to any Server) kann neben den Zeiten und sonstigen Transporteinstellungen "keep" und "hold" je Job eingestellt werden. Die Replikationssnaps werden je Job fortlaufend nummeriert. Die letzten zwei Snaps werden immer behalten. Um eine inkrementelle Replikation fortsetzen zu können, benötigt man einen identischen Snap auf beiden Seiten (gleiche Jobnr, gleiche laufende Nummer)

hold
Das ist die Anzahl der neuesten Replikationssnaps die behalten werden mit n=Tage z.B. 8 oder ns z.B. 8s (letzte 8 Snaps)

keep
Das sind Behalteregeln basierend auf Stunden, Tagen, Monaten oder Jahren z.B.
hours:24,days:32,months:12,years:2

hours:24 bedeutet dass für die letzten 24h je Stunde ein Snap geblockt wird
days:32 bedeutet dass für die letzten 32 Tage je Tag ein Snap geblockt wird
months:12 bedeutet dass für die letzten 12 Monate je Monat ein Snap geblockt wird
years:2 bedeutet dass für die letzten 2 Jahre je Jahr ein Snap geblockt wird

Es werden keine doppelten Snaps behalten wenn auf ein Snap mehrere Regeln zutreffen
Gelöscht werden ältere Replikationssnaps die weder mit einer hold noch einer keep Regel geblockt sind.

Die blockierende keep Regel ist Teil des Snap Namens, z.B. daten1/backup_iso/nvme_nfs@1716449451_repli_zfs-kd0830_omnios_nr_439
ist eine Replikation des Jobs mit id 1716449451 und laufender Nummer 439 für den Tag 30. Aug. des aktuellen Jahres


Filesync Jobs (basiert auf Dateivergleich)
Filesync kann jederzeit ausgeführt werden, hat keine Vorraussetzung wie Replikation mit identischem Basissnap

Filesync ist eine eigene Jobart die aber auch auf einem verschlüsselten cs-stream Tunnel aufbaut und mit Snaps arbeiten kann. ACL werden bei gleichem Quell und Ziel OS unterstützt indem die ACL in einer .csv Datei gespeichert und wiederhergestellt werden. Filesync arbeiter durch parallele Streams sehr schnell. Als Sync tool wird rclone genutzt (rsync for Clouds)

Menü Jobs