I’ve noticed in a few places that the server manager really drops the ball on giving error messages. For example, when attempting to upload an OpenVPN configuration file, I get this:
Good, I guess, that it lets me know the operation wasn’t successful, but useless as far as letting me know what was wrong. I’ve seen the same thing with UPS configuration.
…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.
I agree with Giacomo: you’re right but some error conditions are unexpected and cannot be easily catched.
With a Cockpit based interface we could ease the log analysis, by reporting a related log excerpt, useful to understand the issue, open bug reports and support requests.
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.
Of course it does. It throws an error under those circumstances:
Ergo, it knows enough to know that something went wrong.
As to how the GUI would know what went wrong, that’s a harder question. Here are what I think are the critical lines from my log, maybe they will help answer it:
Jan 8 18:46:50 neth upsdrvctl: [UPS] nut_snmp_init: snmp_open: Unknown host (auto)
Jan 8 18:46:50 neth upsdrvctl: Unable to establish communication
Jan 8 18:46:50 neth upsdrvctl: Network UPS Tools - Generic SNMP UPS driver 0.72 (2.7.2)
Jan 8 18:46:50 neth upsdrvctl: Driver failed to start (exit status=1)
Jan 8 18:46:50 neth upsdrvctl: Network UPS Tools - UPS driver controller 2.7.2
Jan 8 18:46:50 neth systemd: nut-driver.service: control process exited, code=exited status=1
Jan 8 18:46:50 neth systemd: Failed to start Network UPS Tools - power device driver controller.
Jan 8 18:46:50 neth systemd: Dependency failed for Network UPS Tools - power devices information server.
Jan 8 18:46:50 neth esmith::event[31952]: A dependency job for nut-server.service failed. See 'journalctl -xe' for details.