Successfully monitoring a UPS connected to a Synology RS?
-
I'll have to connect a UPS to my Synology to test. Tomorrow night.
Did the remote access work?
-
Not sure what you mean by "Did the remote access work?". pfSense was trying to connect to the SynologyRS but the logs said "connection refused". I do have it's IP (192.168.1.1) set in the "allowed access IP's" on the SynologyRS UPS prefs.
I have a second Synology (411j) connecting as a UPS slave to the SynologyRS and it works perfectly with no configuration needed BTW.
-
I mean did pfSense remote access work with user "remoteuser" and password "sdcsfewrfgwdv"?
-
The person that did the NUT plugin for Synology either didn't have a good understanding of NUT, or was totally focused on keeping Synology's support costs to zero. Their remote access depends upon every node using master mode which is very bad from a NUT point of view. There should be only one upsmon in master mode, the rest should be in slave mode. Also the use of a globally known password for a remote master is horrible from a security pov. The good news is that they let you edit the files, so you can fix it after the fact.
I have a second Synology (411j) connecting as a UPS slave to the SynologyRS and it works perfectly with no configuration needed BTW.
-
I mean did pfSense remote access work with user "remoteuser" and password "sdcsfewrfgwdv"?
No it didn't. Logs said "connection refused" but I think this was due to the SynologyRS not being connected to the UPS as soon as I modified the default user password in upsd.users.
I will try again tonight with only adding the [remoteuser] and not changing the default user password at all.
-
So, mixture of good news and bad news.
Bad news first: There is a change of behavior, which I assume is part of DSM 6.0. The change is that upsmon.conf is rewritten on each system boot. Even though upsd.users continues to not be rewritten each time, this still means that you can no longer change the default username/password of monuser/secret. Serious bummer.
On to the good news: Synology no longer requires master for remote monitoring. This applies to both locally hosted UPS units and remote hosted units. What this means is that you can host the UPS on pfSesnse with monuser/secret declared as a slave, and the Synology will happily connect to it even though Synology is attempting to say it's a master. You can also host the UPS on the Synology, and use it as a remote connection for pfSense. If you host the UPS on the Synology, you can either add a user to upsd.users as discussed above, or you can use the default monuser/secret.
Regardless of the username/password, if you host on the Synology, you need explicitly list the IP address of pfSense in the list of permitted remote hosts in the Synology (Control Panel -> Hardware & Power -> UPS). This may have been why you were getting permission denied previously.
Given a choice, I would host the UPS on pfSense and use remote connections on the Synology units. If you want to do this, you will need to enable remote access as described in this post.
For the remote user, you will need to use this in order to match the expectations of the Synology:
[monuser] password = secret upsmon slave
However if you want to host on one of the Synology units, that will work as well.
Hope this helps.
-
Thanks dennypage for taking the time to look into this, much appreciated.
I did have the pfSense IP added into the allowable IPs on the Synology unit from the start. I'll give it another go tonight and report back..
-
OK I've set it up as I understand it based on your post. Not working. Here's my settings:
UPS is connected to the Synology unit.
Setting screenshots are below.
SS1 = Synology unit ups.users
SS2 = Synology UPS Settings
SS3 = pfSense settings
SS4 = pfSense log
-
Can you post the MONITOR line from /usr/local/etc/nut/upsmon.conf on the pfSense box please? And the MONITOR lines from /usr/syno/etc/ups on both Synology boxes please?
-
Sure:
pfSense:
No MONITOR line, is commented out. Also the upmon.conf is called "upsmon.conf.sample"Synology 1 (has the UPS plugged in to this one):
MONITOR ups@localhost 1 monuser secret masterSynology 2
MONITOR ups@192.168.2.20 1 monuser secret slave -
Hmm…. if there is no /usr/local/etc/nut/upsmon.conf it means that NUT is not actually configured and enabled. I'm at a loss to explain how there are upsmon error messages in the log when there is no upsmon configuration file.
Can you check a couple version things please?
pkg info | grep -i nut pkg which /usr/local/etc/nut/upsmon.conf.sample
Following that, please go to Services / UPS / Settings and press the save button. Then check contents of /usr/local/etc/nut/upsmon.conf.
pfSense:
No MONITOR line, is commented out. Also the upmon.conf is called "upsmon.conf.sample" -
OK I had a thought, at the time I checked on the pfSense upsilon.conf I had the NUT package disabled because it wasn't working. Turned it back on and now there was a upsmon.conf file there. Here is its contents:
MONITOR ups@192.168.2.20 1 monuser secret slave SHUTDOWNCMD "/sbin/shutdown -p +0" POWERDOWNFLAG /etc/killpower
Here are the other outputs:
/root: pkg info | grep -i nut nut-2.7.4_1 Network UPS Tools pfSense-pkg-nut-2.7.4_2 Network UPS Tools
: pkg which /usr/local/etc/nut/upsmon.conf /usr/local/etc/nut/upsmon.conf was not found in the database [2.3.2-RELEASE][admin@Yukon.lan]/usr/local/etc/nut: ls cmdvartab nut.conf.sample upsd.conf.sample upsmon.conf upssched.conf.sample driver.list ups.conf.sample upsd.users.sample upsmon.conf.sample
That result seems not right? I did ls so you could see it right there
-
OK I had a thought, at the time I checked on the pfSense upsilon.conf I had the NUT package disabled because it wasn't working. Turned it back on and now there was a upsmon.conf file there. Here is its contents:
MONITOR ups@192.168.2.20 1 monuser secret slave SHUTDOWNCMD "/sbin/shutdown -p +0" POWERDOWNFLAG /etc/killpower
Okay, that makes much more sense.
: pkg which /usr/local/etc/nut/upsmon.conf /usr/local/etc/nut/upsmon.conf was not found in the database [2.3.2-RELEASE][admin@Yukon.lan]/usr/local/etc/nut: ls cmdvartab nut.conf.sample upsd.conf.sample upsmon.conf upssched.conf.sample driver.list ups.conf.sample upsd.users.sample upsmon.conf.sample
That result seems not right? I did ls so you could see it right there
I was asking for pkg which on "/usr/local/etc/nut/upsmon.conf.sample". The sample config file should be owned by nut-2.7.4 or nut-2.7.4_1. The file "/usr/local/etc/nut/upsmon.conf" is generated by the configuration and is not owned by any package.
Anyway, the remote access configuration matches the remote access configuration of the slave Synology unit. About the only thing left is that IP address of the pfSense box isn't what the master Synology box thinks it is. Or perhaps there is some a bug again in the Synology NUT configuration for remote clients. Btw, you are running DSM 6, yes?
Two things you can try:
1. On the master Synology, delete each permitted device and save. Disable remote the network UPS server and save. Re-enable the remote network UPS server and save. Re-add each (slave Synology and pfSense) IP address to the Synology permitted devices and save. If you have multiple local network addresses for pfSense, add them all. This is simple and easy, and I would do this first.
2. On the master Synology, log in as root and run
tcpdump -n port 3493
You should begin seeing traffic from the slave Synology.
On the pfSense box, log in as root and run
/usr/local/etc/rc.d/nut.sh restart
You should see upsmon on pfSense connect to upsd on the Synology.
If you want to listen in on the conversation you can run tcpdump with the -A option
tcpdump -n -A port 3493
There will be a number of things that don't print, but you should be able to follow the gist of the conversation.
-
OK got it sorted out and it is working now. Much thanks for your help.
I did both of your suggestions below. #1 didn't make a difference.
#2, When running "tcpdump -n -A port 3493" I saw this:
09:38:33.744802 IP 192.168.2.20.3493 > 192.168.2.1.61499: Flags [FP.], seq 19:37, ack 22, win 114, options [nop,nop,TS val 268312 ecr 1101366621], length 18 E..FC\@.@.q............;y.O..3.....r....... ....A..]ERR ACCESS-DENIED
This shows the pfSense box being denied from 192.168.2.1, I was using its actual IP of 192.168.1.1. As soon as I entered the 192.168.2.1 IP into the allowed devices on the Synology unit it worked instantly. I'm guessing it has to do with the Gateway, the Synology is on LAN 2.1 instead of 1.1.
Anyhow big thanks for all your help, much appreciated.
Not sure if you are still interested, but here is the output for the users.conf.sample anyhow:
/root: pkg which /usr/local/etc/nut/upsmon.conf.sample /usr/local/etc/nut/upsmon.conf.sample was installed by package nut-2.7.4_1
-
No problem. Glad you got it working.
-
I have a similar setup working thanks to this thread and some others.
Question though, with my Synology the master as soon as it goes on battery pfsense shuts down immediately. Is there an option I can use on upsmon to make it wait until low battery reached?
-
The master side (Synology) controls all the signals, including low battery and forced shutdown. There is no way to override these from the slave side (pfSense). There is a pull down in the Synology config that says whether to initiate shutdown immediately or wait for low battery. This is the only control available to my knowledge.
-
Note that even if there were a way to override the fsd signal on the slave, it would be a bad idea because the signal generally indicates that the master is about to instruct the UPS to turn the load off.
-