Was NAS-119769
Problem/Justification
There are various situations in which tweaking these config values is useful, if not outright required.
One example is UPS hardware that is finicky with the default settings (e.g. CP1500PFCLCD) and requires modifying some like DEADTIME to prevent data from going stale and the UPS being considered dead.
The only way to avoid this right now is use a post/pre-init script to manually append the values to the config.
Impact
An inability to communicate with a UPS properly on a NAS system is a potentially significant issue, making this a somewhat important feature despite the fact it can technically be done though a workaround.
User Story
Go to Services->UPS and add any auxiliary parameters to upsmon.conf needed for a user’s UPS to function correctly 
1 Like
Auxiliary parameters are pretty much forbidden in our UI/API because its very fragile and a maintenance burden.
This really should be a request to expose DEADTIME or any extra option you may need for it to work correctly.
I would better understand this fundamentally if auxiliary parameters weren’t already accepted for ups.conf and upsd.conf
The format of upsmon.conf is the same XDG/INI like format as the other two, so if those aleady have extensive handling to forcefully override some of the values that users place there with specific ones to keep the system from breaking, sanitize user input, etc, that handling should already be abstracted in order to cleanly apply to both and adding a third configuration file that pertains to the same utility shouldn’t be that complicated.
I can understand the reluctance to add more since I know these blanketed “user-append” fields are something that feel ugly and that you’d prefer to do without entriely, but IMO they’re simply a necessary evil.
If I may play devils advocate for a moment:
Having full auxiliary entries for this file allows anyone who needs them to make the changes they need, whereas DEADTIME only helps my particular case. If adding that one parameter is really so much more preferable that its likely to be added, how long until nearly every parameter in all three if these files is in the UI due to one-offs like this? If the auxiliary fields are such a pain, why do the other two exist in the fiest place? Why not just remove them and tell everyone “you can just use a pre-init script”?
Still, if you insist (and I recognize that the other two files are more likely to need user modification than upsmon.conf, ill make a separate suggestion specifically for DEADTIME.
2 Likes
In Core, I use these auxiliary parameters for UPS, otherwise I’ll have alerts and constant spamming in my logs / console messages:
Under “Auxiliary Paramters (ups.conf)”:
pollinterval = 30
Under “Auxiliary Paramters (upsd.conf)”:
MAXAGE 25
So I guess we need to expose three new options in the GUI?
- DEADTIME
- pollinterval
- MAXAGE
Or how about allowing users to expose “Advanced” / “Dangerous” options, which will hit them with a BIG RED DISCLAIMER, and they can proceed with access to Auxiliary Parameters in UPS, NFS, SMB, SSH, etc.
Their system can even trigger a “tainted” flag, so that they are not eligible for bug reports and troubleshooting.
That way we don’t need to have to add a new option to the GUI for every possible parameter.
EDIT:
Wait. Those Auxiliary Parameter fields remain in SCALE? That makes this even more confusing. Why weren’t those removed, if this is the case:
I meant to mention the disclaimer thing, so thanks for bringing that up. Yea, kind of like when you access the Advance section and get a warning saying you can screw up your system (if that happens in Core as well).
And yes, those fields are in scale:
I feel like I’m brining my own doom by pointing this out and they’ll get the can… but uh, they’re they are.
2 Likes
Existing auxiliary parameters does not justify addition of future ones.
Past sins should not be an excuse to commit more sins.
Removing things is not easy.
