…which was why I posted this as a feature request, not as a support request. An error message should give you actionable information: “uploaded file was not in $FORMAT”. “Unable to connect to $PORT”. etc. “It didn’t work, check the logs (and we won’t tell you which ones) to figure out why” just isn’t very useful.
The particular ones I’ve encountered shouldn’t be. When the user is configuring the UPS, it should be expected that the user would enter bogus information, such that nut wouldn’t be able to connect (it’d be nice if the form would let you directly enter an IP address for the port, so the error wouldn’t be encountered in the first place, but that’s a separate issue). When the user is uploading a config file for an OpenVPN tunnel client, it should be expected that the file could be in the incorrect format (especially since Neth doesn’t seen to accept the standard .ovpn config file, and there’s no documentation of what it does want). When a connection is configured, an inability to connect should be expected. None of these is a bizarre, rare, or unexpected event.
The validation procedure checks the input of the “Master server address” field is a valid IP or host name. It does not check if the given host is reachable, working etc. Is this the problem? Did I understand correctly?
No on both counts, I’m afraid. That form is used when you’re connecting to a remote nut instance. But when the UPS itself is on the network, it’s configured as a “local” UPS–the procedure is described in the link I gave above.
That’s a use-case that the server-manager NUT/UPS page does not implement ATM. The procedure suggested by @syntaxerrormmm is not subjected to UI validation thus cannot give back any useful information in the error message.
On the other hand, I filed a card to implement a basic validation in OpenVPN tunnels.
Well, yes, it is. When you fill out the form and leave the Device field set at “USB (auto)”, the system attempts to connect to the UPS using the specified driver and device. It fails (which is to be expected–SNMP expects a network connection, not a USB connection), and the UI knows enough to know that something went wrong, but either doesn’t know or doesn’t share what went wrong–it just raises the error message I posted at the start of this thread.
Now, once you do the config setprop nut-server..., the GUI has no way to validate that or raise an error–but the issue arises before this point.