We present Synex Server 13 R7, an update that advances on three fronts. The installer expands the available ZFS topologies, with support for multi-VDEV configurations in RAIDZ and assisted disk selection. ServerHub incorporates one of the central novelties of this version: a unified data preservation criterion that makes the uninstallation and reinstallation of its modules recoverable, along with five new modules. And synex-control unifies its navigation model across the entire tool.
synex-installer: multi-VDEV configurations for RAIDZ
synex-installer 2.7.0 introduces support for ZFS pools with multiple RAIDZ VDEVs. Until this version, the installer allowed the creation of a single RAIDZ VDEV per pool, regardless of the number of available disks. That limitation left out of the installer's scope configurations that are common practice in deployments with many disks.
What a multi-VDEV pool provides
A ZFS pool is composed of one or more VDEVs, and ZFS distributes writes among them. With a single RAIDZ VDEV, every operation involves all of the disks. By dividing those same disks into several VDEVs, the pool gains parallelism: operations are spread out and rebuild times in the event of a failure are reduced, because the resilver affects a subset of disks instead of the entire pool.
The trade-off is capacity. Each VDEV dedicates its own parity, so more VDEVs means more disks devoted to redundancy.
An example with twelve disks and RAIDZ1 illustrates the range of the decision:
- 1× RAIDZ1 (12 disks): 11 usable disks, resilver over 12
- 2× RAIDZ1 (6+6): 10 usable disks, resilver over 6
- 3× RAIDZ1 (4+4+4): 9 usable disks, resilver over 4
- 4× RAIDZ1 (3+3+3+3): 8 usable disks, resilver over 3
None of these configurations is universally better. The choice depends on the type of workload, the size of the disks, and how much recovery time weighs against available capacity.
Assisted configuration selection
Determining which layouts are valid for a given number of disks requires calculating integer divisions, verifying the minimums for each RAIDZ level, and estimating the resulting capacity in each case. R7 moves that calculation into the installer.
When the administrator selects a RAIDZ topology and more than one configuration is possible, the installer presents all valid alternatives with their usable capacity:
========================================RAIDZ Layout Selection========================================You have 22 disks. Configure as:1) 1x RAIDZ2 (22 disks, 20 usable disks)2) 1x RAIDZ2 (21 disks + 1 hot spare, 19 usable disks)3) 1x RAIDZ2 (20 disks + 2 hot spares, 18 usable disks)4) 2x RAIDZ2 (11+11 disks, 18 usable disks)5) 2x RAIDZ2 (10+10 disks + 2 hot spares, 16 usable disks)6) 3x RAIDZ2 (7+7+7 disks + 1 hot spare, 15 usable disks)7) 4x RAIDZ2 (5+5+5+5 disks + 2 hot spares, 12 usable disks)8) 5x RAIDZ2 (4+4+4+4+4 disks + 2 hot spares, 10 usable disks)
The limit is six VDEVs per pool, with the minimums corresponding to each level: three disks per VDEV in RAIDZ1, four in RAIDZ2 and five in RAIDZ3. When the number of disks admits a single configuration, the installer applies it directly without presenting the menu.
Automatic hot spares
The calculation contemplates up to two disks as hot spares. When the number of disks does not divide exactly according to the chosen layout, the remaining disks are assigned as hot spares instead of being left unused. Each menu option explicitly indicates how many spares it includes, so that the decision between capacity and recovery margin remains visible.
Selection of all available disks
The disk selection prompts, both in ZFS and in the RAID configurations for ext4 and XFS, now accept the option a to select all available disks in the system. On machines with many disks, this replaces the manual entry of each device.
The installation medium is excluded from the automatic selection, so that booting from USB does not expose the medium itself to being formatted.
Validation
Multi-VDEV configurations were tested on a virtual machine with twenty-two disks, covering the three RAIDZ levels, layouts with and without hot spares, native ZFS encryption and boot redundancy. The tests included booting from disks selected at random from the pool —including those assigned as spares— and the replication of /boot after a kernel update.
Beyond the installer, R7 introduces the most far-reaching change of this version in ServerHub, the application deployment tool of Synex Server.
ServerHub: idempotency, data preservation and new modules
The most significant update of this version is not in a specific module, but in an underlying change that runs through the entire ServerHub catalog. The installation and uninstallation criteria of the modules were completely redesigned to guarantee that deployments are recoverable: a module can be uninstalled while keeping its data and be installed again, recovering everything automatically.
A unified criterion of idempotency and preservation
Until this version, the uninstallation of a module and its subsequent reinstallation did not offer consistent guarantees about user data. A reinstalled module could recreate its database from scratch, and an uninstallation that claimed to preserve data could, in practice, destroy it upon reinstalling. R7 corrects this at the root, applying the same criterion to every module in the catalog.
The guiding principle is simple: preserving data only makes sense if a reinstallation recovers it. From this version onward, each module detects whether a previous installation exists and, in that case, reuses the configuration, the database and the user data instead of regenerating them. The detection signal adapts to the nature of each application: a preserved configuration file, the existence of the database, or the volume data in container-based modules.
Uninstallation now distinguishes precisely between the application code and the user data. The code is always removed; data, configuration and credentials are kept unless their complete deletion is explicitly requested. In database engines, this distinction was implemented respecting the behavior of the package system: when keeping data, packages are removed without purging, so that the data directories remain intact; when complete deletion is requested, they are purged entirely, leaving the state of the package system consistent for a subsequent clean installation.
This work reached all existing modules. GLPI, LAMP, Nextcloud, Odoo, Zabbix and FreeIPA were reformulated under the new criterion, each one with the particularities of its architecture.
Existing modules: notable changes
In addition to the general reformulation, several modules received specific updates.
Odoo was updated to version 19.0 and now preserves the master password and the credentials when reinstalling.
Zabbix incorporated the automatic generation of the en_US locale before starting the services, resolving a frontend warning, and adjusted its uninstallation to preserve configuration and database where appropriate.
Nextcloud now generates a random administrator password instead of a default one, and preserves its configuration and its files when reinstalling, redistributing the application code without touching user data.
GLPI was updated to version 11.0.8, simplified its dependency chain by relying on the PHP 8.4 stack available in the Debian 13 base repositories, and corrected its uninstallation to allow clean reinstallations.
LAMP now detects the active PHP version instead of assuming a fixed one, and preserves the databases and the web content unless explicit deletion is requested.
FreeIPA now detects a previous installation and starts the already configured server instead of reinstalling the domain, preserving the original administrator password. The port declaration was also corrected —including those for Kerberos over UDP— so that they open correctly when the firewall is active.
The passwords generated by the modules are sanitized consistently to avoid characters that could invalidate connection strings or configuration files.
Five new modules
R7 expands the ServerHub catalog with five modules, all developed under the new criterion of idempotency and preservation from their conception.
Keycloak incorporates identity and access management with Single Sign-On. Deployed through containers with a PostgreSQL database, it allows centralizing the authentication of multiple applications through OAuth2, OIDC and SAML, and can federate users from an existing directory such as FreeIPA. Together with the latter, it completes an identity category that covers both the user directory and the authentication broker for web applications.
Grafana adds an analytics and metrics visualization platform. Installed from the official APT repository, it connects to multiple data sources —Prometheus, Zabbix, databases— to build dashboards and alerts, and works as a unified visualization layer for the monitoring stack.
Prometheus provides a complete metrics collection and alerting system. The module deploys a monitoring stack with Prometheus and its time series database, node_exporter for host metrics, cAdvisor for per-container metrics, blackbox_exporter for endpoint probing and Alertmanager for alert routing. It includes ready-to-use alert rules and integrates with Grafana as a data source.
Netdata offers real-time performance monitoring with per-second metrics, anomaly detection and a local dashboard that requires no additional configuration.
Mattermost incorporates a self-hosted team messaging and collaboration platform, an alternative to proprietary solutions, with a PostgreSQL backend and checksum-verified installation.
Core improvements
The ServerHub core accompanied these changes. When an already installed module is selected, the system offers to reinstall it preserving the data instead of blocking the operation, which enables repairing a configuration without loss of information. The output of the installation and uninstallation commands is now displayed live within the interface. And for security reasons, log directories and files are restricted to root-only access, given that the output of the scripts may contain credentials.
The third front of this version is in synex-control, the system administration tool.
synex-control: unified navigation model
synex-control 1.3.0 concentrates its work on the interface. The tool had covered the intended administration tasks for several versions, but navigation had grown unevenly: each module resolved in its own way how to go back, and not all input fields responded the same.
ESC and 0 with defined roles
Until this version, the ESC key worked in most menus but not in all of them. In the text fields of the network module —hostname change, DNS, gateway, interface configuration— there was no way to cancel the operation once started. The 0 option, for its part, meant different things depending on where it was pressed: go back one level, return to the module menu, or exit the program.
R7 assigns a single meaning to each key, consistent throughout the tool:
- ESC goes back one level, both in menus and in text input fields
- 0 returns to the main menu from any depth
- 0 means exiting the program only in the root menu
The difference is noticeable in the most nested paths. Getting from the main menu to the firewall port opening goes through four levels; until this version, exiting from there required four successive presses of ESC. Now a single key returns to the starting point, without losing the possibility of going back one step at a time when that is what is wanted.
Each menu also incorporates a line indicating the behavior of ESC, so that the convention is visible without needing to discover it by trial:
1) Create new user2) Delete user3) Modify user4) List users5) Manage groups0) Return to main menuESC returns to the previous level
Network module aligned with the rest
The network module was the only one that had not migrated to the filtered input handler used by the users and services modules. Its text fields read directly from the terminal, which explained both the absence of ESC and the appearance of spurious characters when pressing function or arrow keys. The seven pending prompts moved to the common handler.
Three inherited details were corrected in the same work: the static IP configuration fields displayed their text in English even when the interface was in Spanish, the hostname change did not contemplate empty input as cancellation, and the format of the menus —numbering, indentation and color— differed from the one used by the rest of the tool.
Exit messages
The messages emitted when returning from a module to the main menu were removed. They were three different variants for the same action and none of them was ever read, because the screen redraw erased them immediately. Interruption via Ctrl+C now displays the same closing message as a deliberate exit, given that in both cases the user is ending the session.
System updates
This version includes all cumulative package updates available in the Debian Trixie repositories up to the build date. Critical security patches for server environments are incorporated, along with the optimized kernel for the amd64 architecture. Main components include Linux kernel 6.12.101, systemd 257.13, OpenSSL 3.5.6 and ZFS 2.3.2.
Availability
Synex Server 13 R7 is available for immediate download. As always, we recommend verifying the checksums of the downloaded images before creating the installation medium.
Download Synex Server 13 R7 from here.