Napp-it cs web-gui for (m)any ZFS server or heterogeneous serverfarms

[gea]

In ZFS on Windows 2.2.3 from yesterday there was a problem with CPUID detection that could crash Windows during setup

Redo cpuid feature detection, part 2 · openzfsonwindows/openzfs@ad3d9f7

Turns out using GCC cpuid() clobbers registers with first symptoms dying in tunables. MS has intrinsic cpuid() so we might as well use it. Also make sure the tnable get functions use static memory...

github.com

There is a new version that fix this.

Releases · openzfsonwindows/openzfs

OpenZFS on Linux and FreeBSD. Contribute to openzfsonwindows/openzfs development by creating an account on GitHub.

github.com

 

[gea]

I have uploaded a new nightly of the client/server ZFS GUI napp-it cs (Mar. 20)

- Allows large zfs list or get all (up to several MB)
- Client/ Frontend web-ui app (Windows): Copy and Run
- Server/ Backend software (BSD, Linux, OSX/ Solaris/Illumos, Windows): Copy and Run from any location like /var/web-gui, desktop or ZFS pool
- Jobs like snap or scrub run remote, replication any source /any destination memberserver is next.
- Gui performance: I would say very good especially as there is no local ZFS database to allow CLI modifications

see napp-it // webbased ZFS NAS/SAN appliance for OmniOS, OpenIndiana and Solaris , ZFS Server for Windows

 

[gea]

There are new release candidates of Open-ZFS 2.2.3 for OSX and Windows

OpenZFS on OS X • View topic - zfs-macOS-2.2.3rc4 release

Releases · openzfsonwindows/openzfs

OpenZFS on Linux and FreeBSD. Contribute to openzfsonwindows/openzfs development by creating an account on GitHub.

github.com

btw
the more people are testing Open-ZFS 2.2.3 on OSX or Windows and report problems,
the faster remaining installer, driver or integration problems get fixed.

ZFS 2.2.3 on OSX or Windows is quite identical to Upstream Open-ZFS 2.2.3 so data security
should be already as good or bad as ZFS on Linux

Issues · openzfsonosx/openzfs
Issues · openzfsonwindows/openzfs

 

[gea]

To add a TrueNAS Server to a servergroup

- Enable SSH, allow root (sharing options) or SMB
- Copy napp-it cs_server to a filesystem dataset ex tank/data (/mnt/tank/data)
- open a root shell and enter:
perl /mnt/tank/data/cs_server/start_server_as_admin.pl
Add Truenas to your servergroup (ZFS Servergroup -> add)



Anyone with a Qnap ZFS Box?
Can you confirm a similar setup

 

[gea]

Next step:

Replication from any server to any server is basically working
on local transfers and between some combinations. Need to check why it does not on others,



Howto:
- add all servers to menu ZFS servergroup
- create replication jobs from any to any server (remote between hosts not working on any combination)

If you start a job, it runs minimized, so you can open the cmd Window to check
- click on "replicate" in joblisting to check last runs
- click on date of a replication job in joblisting to see datails of last run
- enter rl (remotelog) or cl (commandlog) intro the cmd field to get remote logs (rld or cld to delete)
- open menu System > Process List to see running processes on a selected server

Use menu Pools , Filesystem and Snaps to check remote servers

Setup:

napp-it // webbased ZFS NAS/SAN appliance for OmniOS, OpenIndiana and Solaris , ZFS Server for Windows

napp-it.org - ZFS NAS SAN Server with user editable web-gui // All In One server = virtualized ready to run ZFS-Server

www.napp-it.org

 

[gea]

napp-it cs beta, current state (apr.05)

Server groups with remote web-management: (BSD, Illumos, Linux, OSX, Windows): ok
ZFS (pool,filesystem,snap management): ok on all platforms
Jobs (snap, scrub, replication from any source to any destination): ok beside Windows as source or destination
(Windows as source works with nmap/netcat on Windows)

 

[gea]

How much RAM do I need for napp-it cs

RAM for a ZFS filer has no relation to pool or storage size (beside dedup)!

Calculate 2 GB for a 64bit OS, add 1-2 GB for a Solaris based filer and 3-4 GB for a BSD/Linux/OSX/Windows based filer for minimal read/write caching or ZFS can be really slow. RAM above depends on web-gui, number of users or files, data volatility or wanted storage performance. Add more RAM for diskbased pools than SSD pools for a good performance.

With napp-it cs I suggest 8 GB for the Windows machine where the frontend web-gui is running, 16GB if you additionally use ZFS on Windows on that machine.

For the ZFS filers that you want to manage with napp-it cs there is no additional RAM requirement for the server app what means that napp-it cs can manage a Solaris/Illumos based ZFS filer with 2-3 GB RAM and a BSD/Linux/OSX/Windows ZFS filer with 4-6 GB RAM what may allow to manage even a small ARM filerboard with ZFS like a Raspbee up from 2GB remotely with a ZFS web-gui (you only need ZFS and Perl on it).

If you use ZFS on such a board, you may try and report.

 

[gea]

Update:
The current napp-it cs now consists of three components (previously only 1st and 2nd)

1. The web-gui frontend under Windows
This allows you to manage the server or servers via browser and http/https.

2. The server backend cs_server.
These are two Perl scripts that should run on every server where Perl is installed.
These scripts run with admin rights so that you can call zfs and zpool. The backend scripts are addressed by the frontend via a socket connection on port 63000. The connection requires authorization and can be limited to the IP of the frontend computer. Console commands and the corresponding answers are transmitted unencrypted.

3. Https server to transmit encrypted commands and responses via “callback”.
A command such as zfs list is uploaded encrypted as a file to an https server. This can be the Apache server from napp-it cs, also with a self-signed certificate, or another https server with a valid, secure certificate. Curl is required to upload and download the commands and responses. This is usually included (also in Windows 10/11) or has to be installed, e.g. in Free-BSD 14 with pkg install curl. The module /cgi-bin/cs/cs-connect.pl is required on the https server. It should run on any CGI capable web server. Under Linux/Unix, the first line of the script must be adjusted (path to Perl, /usr/bin/perl). This allows you to quite elegantly get around the problem that a web gui on the LAN usually only uses insecure https with a self-signed certificate. The disadvantage of an external https server is a slightly higher latency in the web GUI. I'll try to keep this tolerable with command caching.

Callback is generally used if the response to a command is extensive because a socket connection has problems with it. To activate callback, enter the IP of the server in napp-it cs under About > Setting, e.g. www.university.org . You can also specify an https server in the server script to force only encrypted transmission.

Current information: napp-it // webbased ZFS NAS/SAN appliance for OmniOS, OpenIndiana and Solaris : Downloads