Anouncement: napp-it cs, any OS, 1/4/6/8 node management for RustFS on ZFS software raid

[guenther-alka]

We are pleased to announce the availability of napp-it cs rc9. This release focuses on comprehensive code refactoring, security audits, and enhanced AI-friendly capabilities for managing cross-platform ZFS and S3 RustFS server groups in 1/4/6/8-node, "single disk" setups (=ZFS raid in managed in ZFS) and RustFS Site replication planned for network mirrors.

Key Features & Architecture

• Client-Server Architecture: A single frontend management server (Web-GUI) connects to and controls multiple backend servers using a lightweight, highly efficient 50K remote control socket service with RustFS S3 and Restic encryption keys only on Frontend, never on Nodes.

• Sngle folder, copy and run setup: No installation required

• Cross-OS Support: Fully compatible with FreeBSD, Illumos (OmniOS, OpenIndiana), Linux, macOS, Solaris, and Windows.

• main focus: OmniOS LTS serverside (Unix, Solaris fork) due its ultra fast and minimalistic setup and superiour ZFS stability and Linux/Proxmox due marketshare

Storage Technology Integration: Unified management for OpenZFS (including Illumos and Solaris ZFS native flavors), S3 Object Storage via RustFS, Restic and Rclone, and Windows Storage Spaces.

• AI-Driven Customization: Designed to be AI-friendly. Developers can upload the complete napp-it cs folder to an AI assistant (such as Claude) to seamlessly implement private menus, fix bugs, or perform code reviews based on our integrated behavior guidelines

• https://www.napp-it.org/pdf/csweb-gui_use_ai.pdf

Release Candidate 9 download
single node setup is always free, 3 node setup free for noncommercial use

• http://napp-it.org/doc/downloads/napp-it_cs.zip (all OS, unzip csweb-gui to /var and run)
• http://napp-it.org/doc/downloads/xampp.zip (Windows, unzip xampp to c:\xampp and run)

discuss:
https://forums.servethehome.com/index.php?forums/solaris-nexenta-openindiana-and-napp-it.26/ or https://hardforum.com/threads/openzfs-nas-bsd-illumos-linux-osx-solaris-windows-storage-spaces-with-napp-it-web-gui.1573272/

[guenther-alka]

I have added a Menu Pool > S3 > Site Replication to current rc 9.1
but I am undecided about options

Opt1: single bucket replication
Opt2: multiple bucket replication
Opt3: all buckets=site replication

Site replication=single node only or n x node cluster?

As I mainly want to use single node, single disk setup (on a ZFS pool) with a 1:1 replication to a second RustFS,
my preferred option is propable single node with single bucket or site (all buckets) replication

I will add rc client for management

[guenther-alka]

My RustFS use case are S3/ZFS serverfarms on any OS with centralized management by napp-it cs. With ZFS I basically use RustFS always in single node/ single disk mode (=ZFS filesystem with snap versioning). Rust FS site replication (Internet Lan/WAN) is a core strategy for Internet sharing and HA backup in this concept beside local ZFS replication as this is much faster and preserves ZFS properties, snaps and ACL.

For ZFS replication you can use SSH (encrypted) for transport or a much faster and simpler netcat or mbuffer with an additional pv to limit transfer in a shared Internet connectivity.

In my newest napp-it cs I have added a simple single binary multi-OS Go based zstream to fully replace ssh, netcat, mbuffer or pv. It encrypt transfers like SSH but faster with a single case key per transfer, offers buffers like mbuffer, can limit like pv and can show progress and transfer statistics.

https://github.com/guenther-alka/zstream/releases/tag/v1.1.0
https://forums.servethehome.com/index.php?threads/napp-it-cs-first-steps.55325/page-2#post-506457

[guenther-alka]

Claude AI with agents for rw, ssh and terminal access is the key for efficient and fast web-ui extensions for any-OS RustFS and ZFS clusters,

My howto, see
https://forums.servethehome.com/index.php?threads/napp-it-cs-first-steps.55325/page-2#post-506963

[guenther-alka]

AI performance depends on the efficiency of the AI (Anthropic Claude is currently leading) and on how well it is trained for a given environment (my napp-it cs comes with extensive training data).

Helpdesk process (1h)

unclear error message
initial analysis by Claude AI, with follow-up question for logs
code analysis
code improvement

That was for an error message reported in a forum. With a local Claude installation including local and remote access (file and shell to cluster member servers), analysis + fix + test would have taken 5 minutes.

(use Chrome to translate on the fly)
https://www.hardwareluxx.de/community/threads/napp-it-cs-web-gui-für-fast-jeden-zfs-server-oder-servergruppen.1349039/page-11#post-31228989

[guenther-alka]

Rustfs in our napp-it cs management tool for S3 RustFS/ZFS Cluster,

https://forums.servethehome.com/index.php?threads/napp-it-cs-web-ui-for-any-os-server-and-cluster.55325/page-2#post-507775

[guenther-alka]

Not everyone has a cluster with a dozen servers. Regardless of the OS, whether it’s a 1 GB mini IoT device or a petabyte system, whether using Storage Spaces, S3 object storage, or any ZFS—not everyone wants to manage everything centrally with simple, fast, encrypted file sync or any-to-any ZFS replication (e.g., via https://github.com/guenther-alka/cs-stream).

However, that is precisely our target audience with napp-it cs. S3 integration, in particular, is a hot topic right now. It allows you to publish local files to the internet easily and securely (e.g., setting up a private cloud with RustFS). RustFS can also run independently in a "set-and-forget" mode to keep two servers or buckets in bidirectional sync. High availability and real-time backups over the internet or LAN, plain and simple.

What’s currently missing is the bridge between "shared multi-user SMB with ACLs" and object storage, which inherently lacks multi-user locking with file ACLs. This is where I'm stepping in with the cs-sync module.

With cs-sync, my goal is to keep two folders—such as an SMB share on a NAS and an S3 share—in sync in real time using event triggers (reacting instantly on change, without needing full file comparisons), including SMB ACLs. Regardless of the OS, this is now possible thanks to Go, with the option for real-time automated backups of changes over the network to a backup system (see https://github.com/guenther-alka/cs-sync).

I would love to get your feedback or suggestions on this concept! A first preview featuring napp-it cs and real-time sync is coming soon. Anyone interested in serious testing should consider getting Claude Pro along with the Filesystem and Desktop Commander extensions/agents (on Windows or other OSs via Plink/SCP SSH access for Claude to inspect scripts, logs, and members) for analysis, stress testing, audits, etc.

[guenther-alka]

RustFS on ZFS — my summary

RustFS single disk mode on top of a ZFS pool is superior to RustFS software raid/-native multi-disk erasure coding in every dimension — checksums (block-level + self-heal vs. object-level only), snapshots (COW, near-free vs. per-object versioning at real storage cost), caching (ARC/L2ARC/SLOG hybrid tiering vs. plain page cache), and no redundant Reed-Solomon CPU overhead for redundancy ZFS already provides. "Single disk" here means a single RustFS target — the ZFS pool underneath can itself be a mirror/RAIDZ/Draid and Anyraid in near futurw across multiple physical disks, so no physical redundancy is actually given up.

This holds even for large multi-node deployments. Distributed erasure coding across nodes is still the right tool for whole-node-failure tolerance without replication lag, single-namespace capacity beyond one node, and aggregate multi-node throughput — but each node's own local storage should still be a ZFS-redundant pool underneath, not RustFS-managed raw disks. Local disk faults get absorbed by ZFS before they ever reach the distributed EC layer at all, with no downside.

Ideal: RustFS single node, single target-on-ZFS, plus RustFS bucket/site replication for redundancy across nodes/locations — for small/medium setups this is the whole answer; for large setups it's the same pattern per node, with distributed EC layered on top only when node-count/throughput/namespace needs actually call for it.

Open wish, not yet real: exposing ZFS snapshots of RustFS's data directory as read-only S3 object versions natively in RustFS. Not implemented today — would need RustFS to actively integrate with .zfs/snapshot/ and reconcile that against its own object metadata DB, a real feature request to the project, not a config option. Until then, the two mechanisms stay complementary but separate: zfs snapshot for whole-store point-in-time recovery, RustFS's own object versioning for granular per-object history.

The one remaining exception: hosts without ZFS. If OpenZFS on Windows/macOS support matures to production-ready, that exception may shrink or disappear — worth confirming current status before relying on it for winpool or macOS hosts specifically. OpenZFS is released on OSX now with a nearly ready rc on Windows.

This is how i integrate it in napp-it cs S3/ZFS Cluster management