Ich war wirklich enttäuscht, als ich erfuhr, dass das auf FreeBSD basierende Speichergerät TrueNAS CORE – Eigentum von iXsystems und von diesem entwickelt – in den Wartungsmodus versetzt wird und dass das auf ( Debian ) Linux basierende TrueNAS SCALE die Zukunft ihres Angebots ist. Später begann iXsystems nach all den Backslashs, die Situation zu „beruhigen“, indem es erklärte, dass das auf FreeBSD basierende TrueNAS CORE über alle Funktionen verfüge und dass sie nicht vorhätten, die FreeBSD- basierte Lösung einzustellen … aber wir alle wissen, dass TrueNAS CORE – beispielsweise – das vom Entwickler und vom Rest der Welt aufgegebene FreeBSD Jails -Verwaltungsframework iocage verwendet. Es ist 5 oder mehr Jahre her, seit iocage das letzte Mal aus irgendeinem Grund angerührt wurde.

Man könnte einen „Umzug“ in einfache FreeBSD- Jails oder etwas, das lebendig und aktiv ist, wie BastilleBSD oder etwas Pot- / Nomad- bezogenes, erwarten, wie Klara hier – Cluster Provisioning auf FreeBSD – vor nicht allzu langer Zeit gepostet hat.

Ich war der Erste, der meine Familie und Freunde dazu ermutigte, für ihre Daten nur noch TrueNAS CORE zu verwenden – weil ich wusste, dass ZFS als erstklassiger Bürger in der FreeBSD- Welt die perfekte und stabile Kombination darstellt. Das kann ich vom Linux- Ökosystem nicht behaupten, wo die von ZFS verwendete CDDL-Lizenz gelinde gesagt wie ein Fluch behandelt wird und selbst „der“ Linux- Guru wie Linus selbst den Unterschied zwischen OpenZFS und Oracle ZFS nicht versteht – „ Verwenden Sie ZFS nicht unter Linux “: Linus Torvalds – das fühlt sich nicht richtig an – es ist wirklich schwer, das alles zu erleben.

Vor diesem Hintergrund ist Linux ( ob Debian oder nicht) kein echtes ZFS-„Zuhause“ (und wird es auch nie sein), mit allen Konsequenzen. Einer der Gründe – glaube ich –, warum iXsystems hier auf Linux statt auf FreeBSD setzt, ist die Containerwelt. Die Docker- und/oder Podman -Lösungen – diejenigen, die mehr als ein Jahrzehnt zu spät ins Container-Geschäft einsteigen, da Docker erst seit 2014 verfügbar ist – und die FreeBSD- Jails seit dem Jahr 2000. Rechnen Sie es sich selbst aus.

Es gibt noch weitere Aspekte: iXsystems bewirbt TrueNAS SCALE als Lösung für „Scale-Out“, während die FreeBSD- Version TrueNAS CORE nur für „Scale-Up“ gedacht ist. Ich finde das Thema auch interessant – und, gelinde gesagt, nicht amüsant. Versuchen wir, die einzelnen Teile in ein verständliches Puzzle zu zerlegen.

Bootvorgang

Das erste Bild unten zeigt die Boot-Ausgabe des Alma Linux 9.x RHEL-Klons – es scheint ziemlich ordentlich und sauber zu sein – vermutlich für ein auf systemd(1) basierendes System.

Jetzt die TrueNAS SCALE- Boot-Ausgabe.

Mir gefällt sehr, dass iXsystems das Netif- FreeBSD -Konzept auf einem Debian -Linux- System implementiert hat – auf dem Bildschirm als ix-netif.service bezeichnet

Nach einiger Zeit können wir schließlich das „endgültige“ Verwaltungsmenü sehen.

… und es funktioniert wie gewünscht.

Vielleicht sollte ich mir nicht allzu viele Gedanken darüber machen, solange die Web-/Browserverwaltung am Ende endlich verfügbar ist …

ZFS-Boot-Umgebungen

Während FreeBSD (und infolgedessen TrueNAS CORE ) native ZFS-Boot-Umgebungen unterstützen und von den Tools bectl(8) und beadm(8) verwaltet werden , ist die Situation an der TrueNAS SCALE- Front ganz anders.

Das TrueNAS SCALE -System selbst – basierend auf Debian Linux – wird tatsächlich als Root auf ZFS und mit Unterstützung für ZFS-Boot-Umgebungen installiert … aber kaum anders.

Anstatt Befehlszeilentools wie beadm(8) oder bectl(8) zu verwenden , wie Sie es unter FreeBSD tun würden, müssen Sie bei TrueNAS SCALE stattdessen die WebUI verwenden.

Vielleicht werden sie in Zukunft eine Art Befehlszeilentool implementieren.

Sicherheit

Es gab eine Zeit, in der ich Teil des Teams war, das entscheiden musste, ob wir das damals FreeNAS genannte oder stattdessen ein einfaches FreeBSD -System für die Daten verwenden . Diese Entscheidung war eine der Kernentscheidungen, die wir als Team für das FreeBSD Enterprise 1 PB Storage- Projekt trafen.

Nachdem ich angefangen hatte, mit der damals verfügbaren Version FreeNAS 11.2-U3 herumzuspielen , war ich mit ihrer Sicherheit alles andere als zufrieden – wie hier in den Details – Sicherheitslücken in FreeNAS 11.2-U3 – beschrieben.

Ich wollte die Pakete auch mit dem Befehl pkg(8) auf neuere Versionen aktualisieren , um die Sicherheitslücken zu schließen. Das hat aber anscheinend die gesamte middlewared(8) und alle anderen Komponenten zerstört und ein damals verfügbares FreeNAS- Gerät unbrauchbar gemacht. Letztendlich haben mein Team und ich uns für ein reines FreeBSD -System entschieden und bereuen unsere Entscheidung bis heute nicht.

Ich wollte prüfen, ob es für die neueste – aktuellste Version – TrueNAS CORE 13.0-U6.1 – besser ist, aber nicht – es ist sehr ähnlich.

root@truenas[~]# pkg audit -F

vulnxml-Datei aktuell

apache24-2.4.57 ist anfällig:

  Apache httpd – mehrere Sicherheitslücken

  CVE: CVE-2024-38709

  CVE: CVE-2024-24795

  CVE: CVE-2024-27316

  WWW: https://vuxml.FreeBSD.org/freebsd/8e6f684b-f333-11ee-a573-84a93843eb75.html

  Apache httpd – Mehrere Sicherheitslücken

  CVE: CVE-2023-31122

  CVE: CVE-2023-43622

  CVE: CVE-2023-45802

  WWW: https://vuxml.FreeBSD.org/freebsd/f923205f-6e66-11ee-85eb-84a93843eb75.html

rclone-1.57.0_2 ist anfällig:

  rclone – Mehrere Verwundbarkeiten

  CVE: CVE-2023-48795

  CVE: CVE-2023-45286

  WWW: https://vuxml.FreeBSD.org/freebsd/b5e22ec5-bc4b-11ee-b0b5-b42e991fc52e.html

python39-3.9.16 ist anfällig:

  Python – mehrere Schwachstellen

  CVE: CVE-2023-40217

  WWW: https://vuxml.FreeBSD.org/freebsd/a57472ba-4d84-11ee-bf05-000c29de725b.html

  Python – mehrere Schwachstellen

  CVE: CVE-2023-24329

  CVE: CVE-2023-0466

  CVE: CVE-2023-0465

  CVE: CVE-2023-0464

  CVE: CVE-2023-0286

  CVE: CVE-2023-2650

  CVE: CVE-2022-4303

  WWW: https://vuxml.FreeBSD.org/freebsd/d86becfe-05a4-11ee-9d4a-080027eda32c.html

py39-configobj-5.0.6_1 ist anfällig:

  py39-configobj – anfällig für Regular Expression Denial of Service

  CVE: CVE-2023-26112

  WWW: https://vuxml.FreeBSD.org/freebsd/de970aef-d60e-466b-8e30-1ae945a047f1.html

git-lite-2.34.1 ist anfällig:

  git – Mehrere Schwachstellen

  CVE: CVE-2023-29007

  CVE: CVE-2023-25652

  WWW: https://vuxml.FreeBSD.org/freebsd/d2c6173f-e43b-11ed-a1d7-002590f2a714.html

  git – Mehrere Schwachstellen

  CVE: CVE-2022-39260

  CVE: CVE-2022-39253

  WWW: https://vuxml.FreeBSD.org/freebsd/2523bc76-4f01-11ed-929b-002590f2a714.html

curl-8.0.1 ist anfällig:

  curl – mehrere Schwachstellen

  CVE: CVE-2023-28322

  CVE: CVE-2023-28321

  CVE: CVE-2023-28320

  CVE: CVE-2023-28319

  WWW: https://vuxml.FreeBSD.org/freebsd/a4f8bb03-f52f-11ed-9859-080027083a05.html

  curl – Umgehung der OCSP-Verifizierung mit Wiederverwendung der TLS-Sitzung

  CVE: CVE-2024-0853

  WWW: https://vuxml.FreeBSD.org/freebsd/02e33cd1-c655-11ee-8613-08002784c58d.html

  curl – SOCKS5-Heap-Pufferüberlauf

  CVE: CVE-2023-38545

  WWW: https://vuxml.FreeBSD.org/freebsd/d6c19e8c-6806-11ee-9464-b42e991fc52e.html

  curl – HTTP-Header verbrauchen den gesamten Speicher

  CVE: CVE-2023-38039

  WWW: https://vuxml.FreeBSD.org/freebsd/833b469b-5247-11ee-9667-080027f5fec9.html

py39-beaker-1.12.1 ist anfällig:

  py-beaker – Sicherheitslücke bei der Ausführung beliebigen Codes

  CVE: CVE-2013-7489

  WWW: https://vuxml.FreeBSD.org/freebsd/b54abe9d-7024-4d10-98b2-180cf1717766.html

openssh-portable-8.8.p1_1,1 ist anfällig:

  OpenSSH – Remotecodeausführung über einen weitergeleiteten Agent-Socket

  CVE: CVE-2023-38408

  WWW: https://vuxml.FreeBSD.org/freebsd/887eb570-27d3-11ee-adba-c80aa9043978.html

minio-2021.12.27.07.23.18_1 ist anfällig:

  MinIO – nicht privilegierte Benutzer können Dienstkonten für Administratorbenutzer erstellen

  CVE: CVE-2022-24842

  WWW: https://vuxml.FreeBSD.org/freebsd/8e20430d-a72b-11ed-a04f-40b034455553.html

libxml2-2.9.12 ist anfällig:

  libxml2 – mehrere Schwachstellen

  CVE: CVE-2023-29469

  CVE: CVE-2023-28484

  WWW: https://vuxml.FreeBSD.org/freebsd/0bd7f07b-dc22-11ed-bf28-589cfc0f81b0.html

py39-markdown2-2.3.6 ist anfällig:

  py-markdown2 – Denial-of-Service-Sicherheitslücke durch reguläre Ausdrücke

  CVE: CVE-2021-26813

  WWW: https://vuxml.FreeBSD.org/freebsd/c9b3324f-8e03-4ae3-89ce-8098cdc5bfa9.html

  py-markdown2 – XSS-Sicherheitslücke

  CVE: CVE-2020-11888

  WWW: https://vuxml.FreeBSD.org/freebsd/cf6f3465-e996-4672-9458-ce803f29fdb7.html

squashfs-tools-4.3_1 ist anfällig:

  squashfs-tools – Ganzzahlüberlauf

  CVE: CVE-2015-4645

  WWW: https://vuxml.FreeBSD.org/freebsd/317487c6-85ca-11eb-80fa-14dae938ec40.html

pixman-0.40.0_1 ist anfällig:

  pixman – Heap-Überlauf

  CVE: CVE-2022-44638

  WWW: https://vuxml.FreeBSD.org/freebsd/b278783f-5c1d-11ed-a21f-001fc69cd6dc.html

py39-sentry-sdk-1.5.12 ist anfällig:

  py39-sentry-sdk – sensible Cookies lecken

  CVE: CVE-2023-28117

  WWW: https://vuxml.FreeBSD.org/freebsd/15dae5cc-9ee6-4577-a93e-2ab57780e707.html

c-ares-1.17.2 ist anfällig:

  dns/c-ares – falsch formatierte Datei verursacht Anwendungsabsturz

  CVE: CVE-2024-25629

  WWW: https://vuxml.FreeBSD.org/freebsd/255bf44c-d298-11ee-9c27-40b034429ecf.html

py39-setuptools-57.0.0 ist anfällig:

  py39-setuptools – Denial-of-Service-Sicherheitslücke

  CVE: CVE-2022-40897

  WWW: https://vuxml.FreeBSD.org/freebsd/1b38aec4-4149-4c7d-851c-3c4de3a1fbd0.html

23 Problem(e) in 16 installierten Paketen gefunden.

Vergleichen wir das nun mit dem aktuellen FreeBSD 14.0-RELEASE-System mit denselben installierten Paketen.

freebsd # pkg audit -F

Abrufen von vuln.xml.xz: 100 % 1 MiB 545,9 kB/s 00:02

  py39-beaker-1.12.1 ist anfällig:

  py-beaker – Sicherheitslücke bei der Ausführung beliebigen Codes

  CVE: CVE-2013-7489

  WWW: https://vuxml.FreeBSD.org/freebsd/b54abe9d-7024-4d10-98b2-180cf1717766.html

1 Problem(e) in 1 installierten Paket(en) gefunden.

Ziemlich großer Unterschied … und nachdem ich versucht habe, den Befehl „pkg upgrade“ auf dem TrueNAS CORE- Host zu erzwingen, wird das System unbrauchbar, wie unten nach dem Befehl „reboot(8)“ gezeigt .

Es wird nicht unterstützt – geben Sie also nicht iXsystems die Schuld dafür.

Es gibt auch Stellen, an denen Sie die Sicherheits-/Compliance -Teams davon überzeugen müssen , dass all diese Schwachstellen nicht relevant sind. Ich erinnere mich, dass ich dasselbe tun musste und die Diskussionen verliefen etwa so:

ICH : Dieses anfällige Paket ist nur eine Abhängigkeit und wird in der eigentlichen Lösung nicht verwendet.

 SEC : Entfernen Sie es also einfach.

 ICH : Ich kann es nicht entfernen, weil das das gesamte Paket zerstören würde.

 SEC : Also wird es dann verwendet?

Diskussionen wie diese. Das andere Problem sind offene Abhörports – so sieht es für die aktuelle Version TrueNAS 13.0-U6.1 aus .

root@truenas[~]# sockstat -l -4

BENUTZERBEFEHL PID FD PROTO LOKALE ADRESSE FREMDE ADRESSE      

root python3.9 1223 5 udp4 239.255.255.250:3702 *:*

root python3.9 1223 6 udp4 *:63280 *:*

root python3.9 1223 7 udp4 10.1.1.11:3702 *:*

root python3.9 1223 8 tcp4 10.1.1.11:5357 *:*

avahi avahi-daem 1204 13 udp4 *:5353 *:*

avahi avahi-daem 1204 14 udp4 *:41119 *:*

www nginx 1086 6 tcp4 *:443 *:*

www nginx 1086 8 tcp4 *:80 *:*

root nginx 1084 6 tcp4 *:443 *:*

root nginx 1084 8 tcp4 *:80 *:*

ntpd ntpd 998 21 udp4 *:123 *:*

ntpd ntpd 998 22 udp4 10.1.1.11:123 *:*

ntpd ntpd 998 25 udp4 127.0.0.1:123 *:*

root syslog-ng 932 19 udp4 127.0.0.1:1031 *:*

root python3.9 164 28 tcp4 *:6000 *:*

Natürlich ist es ok, dass 80 und 443 offen sind, aber es gibt auch 6000 , 63280 , 3702 , 5357 , 5353 , 41119 und 123. Während 123 weggelassen werden kann (für den ntpd(8) -Daemon), die anderen? Ich könnte einen zusätzlichen offenen Port für die (REST-)API oder für einige andere Funktionen oder für TrueCommand , eine Art Verwaltung/Verbindung usw. erwarten, aber so viele?

Es wäre eine weitere Gegenfrage des Sicherheits-/Compliance- Teams. Eine davon wäre:

SEC : Python weist mehrere Schwachstellen auf und diese Dienste lauschen auf fünf zusätzlichen Ports.

     Was machen sie und können sie deaktiviert werden? Wofür werden sie verwendet?

Vielleicht könnte iXsystems eine zusätzliche Dokumentation darüber erstellen, was sie tatsächlich tun und warum sie benötigt werden – aber dann wären die auf Python basierenden Dienste immer noch anfällig und würden auf mehreren Ports lauschen …

Unterschied

Nun zur eigentlichen Frage: Gibt es einen echten Unterschied zwischen FreeBSD -basierten TrueNAS CORE- und Linux -basierten TrueNAS SCALE- Systemen?

Die, die ich herausgefunden habe, waren diese:

• Die FreeBSD- Version verwendet Bhyve zur Virtualisierung, während Linux das KVM- Subsystem verwendet .
• Die FreeBSD- Version verwendet Jails für Container, während Linux das Docker- Subsystem verwendet .

Das ist alles. Nichts weiter und nichts anderes … außer dass die „Basis“ für TrueNAS CORE FreeBSD ist und die „Basis“ für TrueNAS SCALE Debian Linux mit dem Daemon systemd(1) ist .

Noch interessanter ist, dass es in der FreeNAS Corral- Version – basierend auf FreeBSD – völlig in Ordnung war, Docker (jetzt Apps ) auf der FreeBSD -Plattform zu haben, wie im Screenshot unten gezeigt

Merkmale

Mir gefiel das Konzept der „Scale-Out“-Funktion für die TrueNAS SCALE -Systeme sehr gut – Übersicht über das Clustering von TrueNAS SCALE – dass Sie mit mehr Systemen sowohl die Daten als auch die Last auf mehrere Maschinen verteilen können … aber nachdem ich mich mit diesem Thema befasst hatte, war klar, dass TrueNAS SCALE es ermöglichte, ein verteiltes GlusterFS-Dateisystem auf mehreren TrueNAS SCALE -Boxen zu haben .

Meine Enttäuschung wäre wahrscheinlich nicht so groß, wenn ich nicht zuvor dasselbe verteilte Dateisystem GlusterFS erfolgreich auf FreeBSD ausprobiert hätte .

Meine Anleitungen zu GlusterFS unter FreeBSD sind unten aufgeführt.

• GlusterFS-Cluster auf FreeBSD mit Ansible und GNU Parallel [2019]
• GlusterFS 8 auf FreeBSD 13 [2021]

… und das Beste kommt noch

Es handelt sich nicht um eine FreeBSD- Beschränkung für das GlusterFS-Dateisystem, sondern um eine iXsystems- Beschränkung.

Bevor ich TrueNAS SCALE verwendet habe , glaubte ich, dass es eine grafische oder GUI-Methode gibt, um den lokalen Speicher mit dem GlusterFS-Dateisystem in einen verteilten Zustand zu konfigurieren/erweitern … Ich lag völlig falsch.

Es gibt keine GUI-Optionen zum Konfigurieren des GlusterFS-Dateisystems über mehrere TrueNAS SCALE- Boxen.

Die einzige mögliche Anleitung zum Verteilen dieses GlusterFS-Dateisystems auf dem TrueNAS SCALE -System war … befehlszeilenbasiert – Sechs-Knoten-Gluster-Cluster mit TrueNAS SCALE – genau dieselben Anleitungen wie meine Anleitungen zu FreeBSD .

Ich dachte, es müsste doch GUI-Optionen für eine so beworbene Option wie das Scale-Out-verteilte GlusterFS-Dateisystem über TrueNAS SCALE -Systeme geben … aber die Antwort, die ich fand, war noch enttäuschender: Man braucht nur den Manager namens TrueCommand – da hat man alle nötigen Optionen – so einfach ist das. Die Nutzung ist kostenlos und man kann bis zu 50 Laufwerke verwalten. Darüber hinaus ist ein kostenpflichtiger Plan erforderlich.

Kubernetes

Da der FreeBSD Bhyve-Hypervisor Memory Ballooning unterstützt, wäre es kinderleicht (und RAM-sparend), einfach eine weitere VM (z. B. mit AlmaLinux ) hinzuzufügen, die als „Ort“ für Docker- / Podman -Container (oder Anwendungen, wie iXsystems sie nennt) dient. Der RAM-Overhead von 30–50 MB ist vernachlässigbar, da FreeBSD im RAM oft speichereffizienter ist als Linux .

Wettbewerb

Ich denke, genau das wird auch dieses Mal passieren – das wünsche ich ihnen nicht. Als FreeNAS / TrueNAS noch auf FreeBSD basierte , bot es ein ausgereiftes und stabiles Betriebssystem – zusammen mit perfekt integriertem ZFS. Ein einzigartiges Paket, für das es kaum Konkurrenz gab. Wenn sie auf Linux umsteigen , müssen sie mit dem Rest der Welt mit ähnlichen/anderen Lösungen konkurrieren, wie zum Beispiel:

• Amahi
• OpenMediaVault
• Rockstor
• Openfiler
• Nexenta (Illumos)
• napp-it (Illumos)
• CryptoNAS
• ÖffnenDeduple
• OpenATTIC
• ESOS
• PetaSAN
• OpenIO
• Öffnen Sie vStorage
• OviOS
• Schlüsselfertiger Dateiserver

Ziemlich überfüllt, muss ich sagen – und Sie müssen WIRKLICH herausragend sein, um den Unterschied zu machen.

Community-Foren

Obwohl ich sie selten verwendet habe, waren die TrueNAS-Community -Foren voll ausgestattet und professionell.

So ähnlich sahen sie aus.

Vielleicht bin ich altmodisch (natürlich bin ich das), aber es fühlt sich einfach wie ein Downgrade an.

Zusammenfassung

iXsystems hatte es im FreeBSD- Land holprig . Neben der BSDi- Klage gab es weitere Versuche, FreeBSD zur „Basis“ für vieles zu machen . Beginnen wir zum Beispiel mit PC-BSD – der FreeBSD- Desktop-Distribution, die einige der zukunftsweisenden Funktionen wie PBI-Pakete enthielt. Heute wird die gleiche Funktionalität wie bei Flatpack- oder Snap- Paketen bereitgestellt … ja, PC-BSD bot dies ein Jahrzehnt zuvor … und es war damals nicht so schick – und wurde oft kritisiert. Jetzt, da Linux damit begonnen hat, fühlt es sich wie ein weiterer Gott der Computertechnik an, ohne den wir nicht leben können … genau wie Docker / Podman , die „zu spät“ zur Container-Party kamen, als FreeBSD Jails seit 2000 ausgeliefert wurde – und doch ist Linux heute „die“ Container-Technologie, auf die die ganze Welt abfährt – während FreeBSD Jails als eine Art Geschichtsmuseum in Erinnerung bleibt.

Mehr lesen: Techinsiderz.com Gadgets zum Erkunden der wichtigsten Technologietrends

Wenn ich mich recht erinnere, habe ich sogar am PC-BSD -Wettbewerb für das neue Logo teilgenommen – aber das ist viel zu lange her, um mich an alle Einzelheiten zu erinnern … oder war es nur ein weiteres Hintergrundbild …

Später versuchte iXsystems – glaube ich – PC-BSD als TrueOS voranzutreiben – aber auch das lief nicht so gut. Sie wechselten später zu Project Trident – ​​immer noch FreeBSD- basiert – und dann zu Void Linux als Basis für das Project Trident -System … und einige Zeit später gab iXsystems das Projekt ganz auf und stellte es ein.

Auch wenn dieser Beitrag wie ein Angriff auf iXsystems wirken mag , ist er das nicht. Ich hatte mich einfach an die Weltanschauung gewöhnt, dass iXsystems immer da sein und FreeBSD unterstützen würde, egal was passiert … Ich lag falsch. Geschäft ist Geschäft, und iXsystems muss Geld verdienen (dafür sind Unternehmen ja schließlich da) und muss sich für das entscheiden, was für sie am besten ist. Ich wünsche ihnen alles Gute, denn sie haben viel Aufmerksamkeit und Interesse in die FreeBSD- Welt gebracht – aber wenn Linux ihr aktueller Fokus ist, ist das für mich in Ordnung – iXsystems ist da sehr deutlich – es besteht kein Grund, ihre neue Version noch holpriger zu gestalten, als sie ohnehin schon ist.

Ich hoffe nur, dass die aktuelle Wette von iXsystems auf Linux- Systeme und nicht auf FreeBSD nicht so endet, wie sie in der Vergangenheit mit PC-BSD oder TrueOS oder Project Trident endete … auf einem vergessenen Pfad.

Hoffe, das hilft.

UPDATE 1 – Sam Sheridan Take

Ich bin gerade auf Sam Sheridans Meinung zu diesem Thema gestoßen und kann ihm nur zustimmen.

Details mit Kommentaren sind auf der LinkedIn -Seite verfügbar.

UPDATE 2 – TrueNAS CORE ist tot – Lang lebe zVault

Der auf FreeBSD basierende Open-Source-Nachfolger TrueNAS CORE – zVault – ist gerade in der zweiten Version verfügbar und auch seine Seite wurde aktualisiert.

Die 1. Version, die im Jahr 2024 veröffentlicht wurde, musste … aufgrund proprietärer Dateien von iXsystems, die in TrueNAS CORE verwendet wurden, widerrufen werden.

Die Liste dieser Dateien – erkennbar an der Zeichenfolge der TrueNAS Enterprise-Lizenzvereinbarung (oder Lizenz) – ist ziemlich lang (über 55 Dateien), wie Sie unten selbst sehen können.

Es scheint, dass iXsystems mit seinem TrueNAS (CORE oder nicht) nicht so Open Source ist, wie beworben.

Das zVault -Team hat einige Zeit gebraucht, um dies zu bereinigen – aber jetzt ist es geschafft und Sie können die neueste ISO-Version problemlos herunterladen und installieren.

Der Entwicklungsfahrplan ist sehr sinnvoll und sieht wie folgt aus.

Aus Neugier habe ich zVault heruntergeladen und in FreeBSD Bhyve VM installiert und es funktioniert wie ein Zauber

Die Anmeldeseite können Sie unten sehen.

Nach der Anmeldung begrüßt Sie das vertraute Dashboard.

… und wie üblich gibt es auch ein CLI-Menü auf dem Terminal.

Ich freue mich mit großer Hoffnung und Begeisterung auf diese und die nächsten zVault- Versionen.

UPDATE 3 – Mehr TrueNAS SCALE Linux-Drama

Die Ereignisse dieses Wochenendes haben mich wirklich enttäuscht. Obwohl ich all diese Memes und/oder Nachrichten gesehen/gehört habe, in denen es darum geht, es einfach nicht zu tun , unterstütze ich alle meine vertrauten Familienmitglieder und Freunde mit meinem – sogenannten – IT-Support … und nehme dafür nie Geld von ihnen – ich sage ihnen nur, dass sie etwas warten sollen, wenn ich Zeit dafür habe. Ich nehme kein Geld von ihnen, weil ich selbst Geld verdienen kann – es besteht kein Grund, ihre Geldbörsen noch mehr zu leeren – besonders in diesen chaotischen Zeiten.

Nun ist ein Kumpel von mir, der FreeNAS und später das auf FreeBSD basierende TrueNAS und noch nicht so lange das „alte“ TrueNAS CORE verwendet hat, rechtzeitig auf das empfohlene TrueNAS SCALE (oder kurz gesagt einfach das auf Linux basierende TrueNAS) umgestiegen.

Während die meisten Dinge wie gewohnt funktionieren, gab es kleine „Inkonsistenzen“, die nie auftraten, als FreeBSD die Basis für das Gerät war … aber die Hauptfunktion wurde erfüllt – mein Kumpel hatte einen ZFS-Spiegel für seine Daten und die Möglichkeit, VMs (für Home Assistant) und Apps (für Plex) auszuführen.

Die von ihm verwendete Hardware war ein Intel N3150 ITX-Motherboard – aber er wollte auf etwas Moderneres umsteigen – ein ASRock Intel N100- basiertes ITX-Motherboard kaufen … und hier begannen die Probleme.

Migration

Der Plan war einfach: alle Laufwerke vom alten Motherboard trennen, das Motherboard ersetzen, das neue Motherboard montieren, die Laufwerke wieder anschließen, die neue Hardware booten. Der einzige Nachteil, den ich erwartet hatte, war, dass die Netzwerkschnittstelle möglicherweise von einem anderen Treiber unterstützt wird oder eine andere PCI-ID hat. Daher muss das manuell mit der Netzwerkkonfiguration behoben und dieselbe IP-Adresse und dasselbe Gateway erneut eingestellt werden … aber nein.

Nach dem Anschließen der Laufwerke wurde der erwartete GRUB-Bildschirm wie unten gezeigt angezeigt.

… aber das war das letzte positive Feedback, das wir zum Linux-basierten TrueNAS 24.10.2 bekommen haben.

Nach einiger Zeit wurde der Bootvorgang mit der großen Fehlermeldung abgebrochen, dass der ZFS -Bootpool NICHT importiert werden konnte … aber das Laufwerk war für den Zugriff da und alles schien in Ordnung zu sein – es gab keinen Hardwarefehler oder ähnliches – sehen Sie selbst im Bild unten nach.

… und ich konnte meinem Kumpel hier NICHT helfen.

Wir haben uns entschieden, die neueste Version von TrueNAS (Linux-basiert) herunterzuladen und auf einem USB-Stick zu installieren – und danach den ZFS-Pool von den beiden ZFS-Spiegelfestplatten zu importieren, um die Daten anzuhängen – und genau das haben wir getan – den ZFS-Pool importiert – die Daten waren verfügbar … aber etwas fehlte.

Künstliche Einschränkungen

Obwohl alles einwandfrei zu funktionieren schien, fehlte der Abschnitt „Virtualisierung“ im linken Hauptmenü der TrueNAS-Weboberfläche. Zunächst vermuteten wir, dass die Intel VT-x- Option im BIOS/UEFI-Setup nicht aktiviert ist – doch nach einem Neustart und einer Überprüfung war alles aktiviert und einsatzbereit … Was passierte dann?

Ich musste an dem Tag meine Familie besuchen – also ließ ich meinen Kumpel mit dem Problem allein, bis ich am Abend zurückkäme … und nach einiger Zeit (Stunden später) schickte er mir eine SMS mit sehr seltsamen Informationen – seine Worte waren wie „Ich habe herausgefunden, warum es keinen Abschnitt zur Virtualisierung gibt – wenn wir TrueNAS auf einem USB-Stick installieren, ist die Virtualisierung nicht möglich – und in der Benutzeroberfläche deaktiviert.“ … das hat mich wirklich hart getroffen. Was zum Teufel ging mir da durch den Kopf – das ist UNIX, dachte ich und erinnerte mich an das berühmte Zitat von Terry Lambert : „Es ist nicht die Aufgabe von UNIX, Sie davon abzuhalten, sich in den Fuß zu schießen. Wenn Sie sich dafür entscheiden, dann ist es die Aufgabe von UNIX, Herrn Fuß auf die effizienteste Art und Weise eine Kugel zuzuwerfen, die es kennt.“ … aber das TrueNAS-Team weiß es besser.

Ich sehe in diesen erzwungenen Einschränkungen absolut keinen Sinn. Es gibt billige USB-Sticks, die schnell kaputtgehen, und es gibt gute, die jahrelang halten – ganz zu schweigen davon, dass man auf diesen USB-Sticks einen 2- oder 3-Wege-ZFS-Spiegel für das „System“-Image erstellen kann.

Als FreeBSD die BASIS für TrueNAS-Geräte war, war das Leben einfach: Das System (FreeBSD/TrueNAS) wird von JEDEM Laufwerk geladen und ausgeführt. Die Daten (und Jails/Virtualisierung/…) befinden sich auf dem DATEN-Speicher. Es scheint nicht möglich zu sein, dieselbe Trennung in Linux-Umgebungen bereitzustellen, daher die erzwungenen Einschränkungen.

Endgültige Entscheidung

Da es nicht möglich war, VMs mit TrueNAS auf einem USB-Stick zu installieren, schlug ich meinem Freund vor, eine offene Alternative zu verwenden – den zVault- Fork –, da ich wusste, dass dieser diese erzwungenen künstlichen Einschränkungen nicht aufweist und man so viele Jails oder VMs ausführen kann, wie man möchte – und zwar auf allem, was man installiert – sogar auf einer Kartoffel.

Da ich ihm versicherte, dass seine DATEN sicher sind, stimmte er zu, diesen Weg auszuprobieren – und es funktionierte einwandfrei. Wir verwendeten die neueste verfügbare zVault- Version und nach einiger Zeit verfügte er über alle Funktionen, die er vor der Migration hatte.

Ich half ihm, die neueste Home Assistant- Instanz in eine VM zu importieren, und auch eine weitere für Plex auf Ubuntu Server (da dies für seine Anforderungen der einfachste und am besten unterstützte Weg zu sein schien).

Die letzte Aufgabe bestand darin, die gemeinsame Nutzung von SMB sowohl für lokale Computer als auch für den Plex selbst zu aktivieren – auch das funktionierte wie gewünscht.

Traurigkeit

TrueNAS (und früher FreeNAS) war in der Vergangenheit ein so schönes Speicherjuwel, dass es fast wehtut zu sehen, was jetzt passiert und welche Entscheidungen und Richtungen getroffen werden – ich möchte hier nicht dramatisch klingen – aber TrueNAS mit Linux als Basis fühlt sich mental so an, als würde Broadcom VMware übernehmen und sich nur auf den Gewinn konzentrieren und sonst nichts … und damit sein gesamtes Erbe zerstören.

Ende des Lebens