Support for Tripplite SUINT1500LCD2U

[agentpatience]

Hello,

Can you advise if Tripplite SUINT1500LCD2U is supported by NUT?

Thanks!

[clepple]

The SUINT1500LCD2U shares the same Advanced Users Manual as several other supported models (such as the SU2200RTXLCD2U), which means it might be close enough. Are you planning to use the USB interface? If so, what does lsusb -d 09ae: return?

Reference: https://networkupstools.org/stable-hcl.html?manufacturer=Tripp%20Lite

[agentpatience]

Hi Charles. Thanks for your support. I am a bit of a noob with this software, used it long ago for USB mode but I want to setup NUT with SNMP mode now. I will however try that command with the USB cable attached. I have 2-3 servers attached to each UPS. I have installed the nut software via "dnf install nut" in rock linux 8.10. That is as far as I have got. Can you clue me in on the next steps? Thanks!

[clepple]

That sounds like you are looking for something like https://networkupstools.org/docs/user-manual.chunked/Features.html#_advanced_configuration (instructions in the next section: https://networkupstools.org/docs/user-manual.chunked/Configuration_notes.html)

I am aware of the SNMP driver, but the UPSes I use day-to-day only have USB or serial connections. From https://networkupstools.org/docs/man/snmp-ups.html (and the fact that no Tripp Lite UPSes have been marked as tested for "network" in the HCL link I sent earlier) it looks like maybe the SNMP support is still pretty basic.

[jimklimov]

Yes, in fact the "Tripplite MIB" is an alias to standard default fallback IETF mapping at the moment (just uses detection of vendor-specific OID to match).

[jimklimov]

Do you know the settings from UPS side? If SNMP is enabled at all, if it is on standard port (161/udp), if its SNMP v1/v2c community is set and is not default public (R/O) or private (R/W), or if SNMPv3 credentials and crypto are used?..

[agentpatience]

We used tripplite webgui to check that. We wanted to try v1 to try and keep it simple but i'm all ears. They all appear to be "On" Our default configuration on UPS side:

[agentpatience]

We are making some progress. We changed port to 161 and manually added "public" for the community string and "tripplite" for the community string on the tripplite profile.

You can see the snmp query worked with net-scanner and snmpwalk. WE are still a little needy on proceeding to get a working setup. We really just need to be able to detect when the battery goes to 50% or so and shutdown servers gracefully.

[agentpatience]

Here is some output from one of the snmp-ups driver commands says to contact nut developers on one line. Sorry if it is false alarm 🚨

[agentpatience]

Ahh the upsec command is talking to localhost server client duh!

[agentpatience]

Trying to do some sanity testing now, I wonder what we are missing?!

upsdrvctl -t shutdown
Network UPS Tools - UPS driver controller 2.8.2
Network UPS Tools - Generic SNMP UPS driver 1.31 (2.8.2)
Can't open /run/nut/snmp-ups-public: No such file or directory
Detected SUINT1500LCD2U on host 192.168.0.105 (mib: tripplite 1.55)
Initiating UPS shutdown
Shutdown failed!
upsnotify: failed to notify about state 4: no notification tech defined, will not spam more about it
Driver failed to start (exit status=1)
Network UPS Tools - Generic SNMP UPS driver 1.31 (2.8.2)
Can't open /run/nut/snmp-ups-tripplite: No such file or directory
Detected SUINT1500LCD2U on host 192.168.0.105 (mib: tripplite 1.55)
Initiating UPS shutdown
Shutdown failed!
upsnotify: failed to notify about state 4: no notification tech defined, will not spam more about it
Driver failed to start (exit status=1)

"Create a upsd user for upsmon to use while monitoring this UPS."

Does this user need to be a SNMP user on the UPS side?

[jimklimov]

"Create a upsd user for upsmon to use while monitoring this UPS"

That's from... where? Don't see an exact match above. Anyhow, this is about creating an entry in upsd.users file with the specific upsmon role (primary or secondary). Not related to account/community names in SNMP (may be or not be coincidentally similar; security-wise better not).

Note that on the UPS side, the SNMP public community is read-only, so by design should not be able to handle any variable settings or issue commands to the device.

As for the test itself, can you please retry it with some more debug verbosity, perhaps as upsdrvctl -DDDDDD -d -t shutdown ?

On the one hand, looking into code https://github.com/networkupstools/nut/blob/v2.8.2/drivers/upsdrvctl.c I see that all (hopefully) executions and signal sending are fenced by testmode variable; on the other - I don't see the effects of printf("*** Testing mode: not calling exec/kill/signal\n"); etc. above, and it apparently does try to run the driver programs.

So the drivers did try to power off your UPS despite the testing mode, just by some chance failed to.

First I've suspected a non-capable SNMP community, but then remembered an issue fixed a couple of months ago (part of upcoming NUT v2.8.3 release) to let sdcommands be specified. As of your version, in https://github.com/networkupstools/nut/blob/v2.8.2/drivers/snmp-ups.c the upsdrv_shutdown() method cycles through "shutdown.return", "shutdown.reboot", "load.off.delay" and now I found that the IETF OID mapping (used also for Tripplite as noted above) in https://github.com/networkupstools/nut/blob/v2.8.2/drivers/ietf-mib.c actually defines none of these names. So that is probably why it gets to upslogx(LOG_ERR, "Shutdown failed!");

So I suppose these devices have no way of triggering a shutdown with NUT v2.8.2 or older, and might be able to with custom sdcommands configuration with current master branch, eventually NUT v2.8.3 or newer.

Orthogonally to this, note that nut-driver-enumerator can automatically generate systemd units that wrap your driver instances, see https://github.com/networkupstools/nut/wiki/nut%E2%80%90driver%E2%80%90enumerator-(NDE) - so using directly the driver programs or old upsdrvctl becomes trickier, especially with non-networked UPSes (serial/USB) due to exclusive-link conflicts. A newer executed copy of the driver can try to kill off the older one (so first the one you run manually kills the one under the service, then the unit is revived and kills your manually-spawned copy).

Here socket files like /run/nut/snmp-ups-public were absent, so the respective drivers were not running. Probably :)

[agentpatience]

"Create a upsd user for upsmon to use while monitoring this UPS

That's from... where?

https://networkupstools.org/docs/user-manual.chunked/ar01s06.html under "NUT User Creation"

It seems that we chased some rabbits today one being that in order to start getting ups.status returned we need to run upsd manually via cli. For whatever reason installing from packages does not allow it to startup when the server boots? I cannot seem to find the instructions to have it init at start?

We are going to try a basic shutdown config per the docs. I however, lack experience with this project and please forgive me if it sounds elementary.

[agentpatience]

At some point previously, I started getting these complaints about SElinux blocking in logs. I will put them here for review I am not sure if any are related to our issues. For now, I put SElinux into permissive mode. I have not confirmed it is an issue.

UPS-Testbed setroubleshoot[2610]: SELinux is preventing /usr/sbin/upsd from connectto access on the unix_stream_socket /run/nut/snmp-ups-tripplite. For complete SELinux mes>
Feb 24 13:22:27 UPS-Testbed setroubleshoot[2610]: SELinux is preventing /usr/sbin/upsd from connectto access on the unix_stream_socket /run/nut/snmp-ups-tripplite.
***** Plugin catchall (100. confidence) suggests **************************
If you believe that upsd should be allowed connectto access on the snmp-ups-tripplite unix_stream_socket by default.
Then you should report this as a bug.
You can generate a local policy module to allow this access.
Do
allow this access for now by executing:
# ausearch -c 'upsd' --raw | audit2allow -M my-upsd
# semodule -X 300 -i my-upsd.pp

[jimklimov]

Thanks for the latter. I don't think interaction of NUT with SELinux was ever explored or automated, at least not in this upstream project. No idea if any distribution packages have additional lore or files for that - would be great to find and upstream here, if any :)

But this may be behind your service not starting (or being useful) when the server boots... I've lost the detail a bit - which OS release is that on?

[agentpatience]

upsdrvctl -DDDDDD -d -t shutdown

Network UPS Tools - UPS driver controller 2.8.2
*** Testing mode: not calling exec/kill/signal
0.000000 [D1] upsdrvctl commanding all drivers (2 found): (null)
0.000009 [D1] Shutdown UPS: public
0.000013 [D2] exec: /usr/sbin/snmp-ups -a public -k
0.000016 [D1] Shutdown UPS: tripplite
0.000020 [D2] exec: /usr/sbin/snmp-ups -a tripplite -k
0.000023 [D1] upsdrvctl: successfully finished
0.000025 [D1] Completed the job of upsdrvctl tool, cleaning up and exiting now
0.000029 [D1] Completed the job of upsdrvctl tool, clean-up finished, exiting now

[agentpatience]

But this may be behind your service not starting (or being useful) when the server boots... I've lost the detail a bit - which OS release is that on?

Our test bed is Rocky Linux 8.10.

[agentpatience]

But this may be behind your service not starting (or being useful) when the server boots...

[agentpatience]

My bad, I hit the wrong button and accidentally closed the issue. I wanted to add that we tested a reboot with SElinux=Permissive and still we needed to run it by hand. I am not exactly sure if we should be testing in this mode or not.

[agentpatience]

Some state changes are happening now but we want to shutdown after about 60 seconds on. Battery 🔋

We have been unable to get it to send the shutdown signal after this time.

OK, we let the UPS run to battery 🪫 depletion of around 15% a double time beep alarm 🚨 started and about 1 min after NUT initiated a graceful shutdown of the server.

[jimklimov]

For the latest post, it seems like you are after upssched integration to trigger the time-based shutdowns. Just in case: is it configured as the NOTIFYCMD in upsmon.conf?

[agentpatience]

For now we will just use the defaults. We have an issue when we do a server reboot where we don't have NUT actively monitoring on a boot:

[root@UPS-Testbed ~]# upsc tripplite@localhost:3493
Error: Connection failure: Connection refused
[root@UPS-Testbed ~]# upsd
Network UPS Tools upsd 2.8.2
fopen /run/nut/upsd.pid: No such file or directory
Could not find PID file '/run/nut/upsd.pid' to see if previous upsd instance is already running!
listening on ::1 port 3493
listening on 127.0.0.1 port 3493
Can't connect to UPS [tripplite] (snmp-ups-tripplite): No such file or directory
Can't connect to UPS [public] (snmp-ups-public): No such file or directory
Found 2 UPS defined in ups.conf
[root@UPS-Testbed ~]# upsc tripplite@localhost:3493
Init SSL without certificate database
Error: Driver not connected

so now we run this command:
snmp-ups -a tripplite

it seems to initialize everything needed too start monitoring and reading back status information from the ups:
[root@UPS-Testbed ~]# upsc tripplite@localhost:3493
Init SSL without certificate database
battery.charge: 17
battery.runtime: 180
battery.runtime.low: 300
battery.temperature: -273
battery.voltage: 39.10
device.contact: localadmin@poweralert
device.description: Ubuntu 18.04 Linux 4.4.31 flash: 3.34G ram: 506844kB process or: armv7l software: PowerAlert 20.1.0 (Build 87)
device.location:
device.mfr: TRIPP LITE
device.model: SUINT1500LCD2U

further, status monitoring is not active at boot in order to get it to start monitoring UPS power conditions we must now run upsmon

[root@UPS-Testbed ~]# upsmon
Network UPS Tools upsmon 2.8.2
fopen /run/nut/upsmon.pid: No such file or directory
Could not find PID file to see if previous upsmon instance is already running!
UPS: tripplite@localhost (primary) (power value 1)
Using power down flag file /etc/killpower
[root@UPS-Testbed ~]#

Broadcast message from root@UPS-Testbed (somewhere) (Wed Feb 26 14:54:51 2025):

UPS tripplite@localhost battery is low

Broadcast message from root@UPS-Testbed (somewhere) (Wed Feb 26 14:54:51 2025):

Executing automatic power-fail shutdown

Broadcast message from root@UPS-Testbed (somewhere) (Wed Feb 26 14:54:51 2025):

UPS tripplite@localhost on battery

Broadcast message from root@UPS-Testbed (somewhere) (Wed Feb 26 14:54:51 2025):

Auto logout and shutdown proceeding

How do we fix this? Is there something missing to have this stuff running after boot?

Thanks!

[jimklimov]

Quite strange indeed. What do NUT service units say in detail? Blocked on SELinux and so not starting? Anything else upsets them?

Can you please check and post:

:; systemctl status nut-server nut-monitor nut-driver@tripplite

and maybe other units if you have them (e.g. multiple nut-driver-enumerator* related units may be available, not all would be enabled at the same time though).

I suppose the later report about shutdown is not immediately after you started upsmon, but part of test to check that it works when the UPS is unplugged from the wall power?

[agentpatience]

Alternatively, it seems “upsdrvctl start” can be used in conjunction with running upsd and upsmon as observed after a reboot:

[agentpatience]

systemctl status nut-server nut-monitor nut-driver@tripplite

Upon server boot we ran:

[root@UPS-Testbed ~]# systemctl status nut-server nut-monitor nut-driver@tripplite
● nut-server.service - Network UPS Tools - power devices information server
Loaded: loaded (/usr/lib/systemd/system/nut-server.service; enabled; vendor preset: disabled)
Active: inactive (dead)

● nut-monitor.service - Network UPS Tools - power device monitor and shutdown controller
Loaded: loaded (/usr/lib/systemd/system/nut-monitor.service; enabled; vendor preset: disabled)
Active: inactive (dead)

● [email protected] - Network UPS Tools - device driver for tripplite
Loaded: loaded (/usr/lib/systemd/system/[email protected]; disabled; vendor preset: disabled)
Active: inactive (dead)

[agentpatience]

I suppose the later report about shutdown is not immediately after you started upsmon, but part of test to check that it works when the UPS is unplugged from the wall power?

As long as we run upsmon + upsd in shell the following occurs:

Communications with tripplite@localhost established.

{unplug UPS AC}

UPS tripplite@localhost on battery

{plug UPS back into AC supply}

UPS tripplite@localhost on line power

[agentpatience]

We noticed mode=none in nut.conf so we changed to mode=standalone to try in the meantime. Rebooting now.

[agentpatience]

no change.

[jimklimov]

Hm, there are also NUT target units, and those might have not been enabled by packaging - they pull in the rest.
I think there was a bug for RHEL, Fedora or CentOS about that a few months ago. Something like #2721 or #1712 ... Should have got solved by #2746 (part of upcoming NUT v2.8.3).

Try this (and post the logs so we can see if they confirm the hypothesis):

:; systemctl disable nut.target nut-driver.target
:; systemctl enable nut.target nut-driver.target
:; systemctl start nut.target nut-driver.target