Discussions in the forums have prompted me to think about a few sensible refinements which could actually be fairly easy to implement for our devs here.
Cluster / Node Admin Page:
A simple small display showing node status on or off, with options for restart / shutdown.
If there are more nodes in a Cluster than the default 0, then:
Display this for ALL nodes, but additionally with the option to use either
WOL (Real Hardware or VM, if supported. Proxmox does not support WOL for VMs, AFAIK.)
Custom Command (For Nodes running on Hypervisors like Proxmox)
Here the options could then be:
Reboot Node
Shutdown Node
Node in Maintenence Mode (Just as a Info note)
Wake Node
The dotting of āiā, or topping on the cake would be:
Since WOL is installed anyways, Have a Screen for using WOL for waking Clients or other Devices supporting WOL.
Put in WSDD - the cluster has already all infos it needs for a customized start command, to make this ready for a multi node file server, whenever this comes.
WSDD is really simple, itās a one liner!
Trashcan:
Options for a Trashcan:
Per Share enabling
Emptying Options including Cron, both with some plausible defaults added in
All these are simple options in the config file, but GUI options should be there. NS8 is supposed to be easy
If leader node is turned off there is no control over UI of any of the nodes, so at least a minimal UI with node status and control from each cluster node could be useful to some degree. If a worker node is remote that will save a few calls and travels just to reach to the physical/virtual button.
But before that Iād prioritize extending AD functionality (permissions, wsdd, trashcan, user profilesā¦)
Sometimes easy to forget.
I think that is the hardest part of all and far to become real. (going by some music lyricsā¦ this task ahead, this task at hand, ominous and daunting, crippling undertakingā¦ where to begin eludes me, ruling ever deeper, this massive endeavorā¦)
A path, without having though as much as the devs surely already did, could be:
Migrate from CentOS 7 to Rocky Linux 8 or CentOS 8 (no Debian) and from there to Rocky 9:
Move (or copy, although could hit space limitation) data / databases from NS7 module to NS8 app + fix ownership and permissions
Put NS7 module in maintenance mode (disable it, recoverable if copied, troublesome if data moved and permissions changed)
Fire up NS8 app (reconfiguring it to old account provider if needed)
At this stage, the server will be a mixture of NS7 modules and NS8 apps, controlled by different server managers / control panels.
After every NS7 module supported by NS8 is successfully migrated (as there are modules that have no direct migration path), remove NS7 remnants.
Cons:
Many possible sources of problems (apps, firewall, taking over used ports from one module to the app, grub boot-loader, etc.)
Daunting task for devs (not only programming, but lots of testing involved)
Time consuming efforts put on in-place migration, stale advancement of NS8, NethSecurity, NethVoiceā¦
I love FOSS in the broader sense (freedom as well as free beer) but if I were on a Business management/executive position and had to seriously consider an in-place upgrade path, Iād be tempted to put it behind a paywall (subscription) to try to get some revenue for the unaccounted hard work, increase of support request and having customers breath on my neck.
I though of start/pause/restart/stop or enable/restart/disable, but all depends on how safe it is for the data, clock, and what is allowed by the underlying technology. For instance, traefik shall not be hardly ever touched, AD could be troublesome for all the apps that depend on itā¦
About the internal app services, that might be a second layer of control in contrast of the whole app as a unit.
Agree. It should be easy enough to add on the next app update.
I love ideas for products but itās hard to discuss them on the same topic and track upcoming comments/developments. Can I split it into 3 requests?
Do you have existing discussions to bump?
