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.
For more details you may have a look at the logs, but you are right a short message what happened could be helpfull.
@dev_team What do you think?
@danb35 is right, but some errors can’t be catch.
For example, if OpenVPN fails to start, you need to inspect the specific log. The signal-event process doesn’t know how to get such information.
There is no solution right now for such scenario.
…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.
In other words the UI does not validate the input… This is a bug for sure!
For OpenVPN however it could be difficult to validate the uploaded file by parsing its contents.
For UPS, I’m not sure I catched the problem: can you describe a procedure that reproduces it?
Perhaps, but the GUI (and/or the administrator’s manual) could state what file format is required, which they don’t appear to at this point.
It happens when configuring the system to connect to a networked UPS, as described here: [NS6.8] NUT and APC Network Management Card - #4 by alefattorini
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?
Yes, the code does not implement any validation
We could implement a basic format check with a trivial system validator, like the “Server certificate” page does: /cc @giacomo
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.
Thank you for pointing them out, @danb35!
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.
Sadly not ATM. It needs a command to implement a validation procedure: can you suggest a workable one?
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.
As regards the error message:
Would it be a solution to do some cosmetics and show something like “Unknown error” if we don’t get an error message or #?