[Plugin] ControlR


Recommended Posts

  • 3 weeks later...
2 hours ago, jbrodriguez said:

Also, which of the following files are present in your system ?


/var/run/nut/upsmon.pid
/var/run/apcupsd.pid
/sbin/apcaccess
/usr/bin/upsc
/boot/config/plugins/nut/nut.cfg

 

upsmon.pid is there

I don't have apcupsd.pid as i don't have a APC UPS.

I do have apcaccess though.

I also do have upsc

I also have the nut.cfg file.

(all within the specified directories) :D

Link to comment

@jbrodriguez I see you added nut support. I probably broke it though. The latest update I change some nut.cfg variables.  USERNAME and PASSWORD to MONUSER and MONPASS and encoded the passwords instead of just plain text.

 

Also I noticed I get this in the system log

Nov 3 19:17:16 Server nginx: 2017/11/03 19:17:16 [error] 6414#6414: *977223 FastCGI sent in stderr: "Primary script unknown" while reading response header from upstream, client: 192.x.x.x, server: , request: "GET /plugins/dynamix.system.temp/include/SystemTemp.php?unit=C&dot=.%2C HTTP/2.0", upstream: "fastcgi://unix:/var/run/php5-fpm.sock:", host: "192.x.x.x:xxxx"

 

Link to comment

Thanks for the heads up @dmacias !

 

I'm not using those variables, although ... I probably should ? :o O.o

 

Are they used to access nut's UI ?

 

The status report from the nut binary seem to work ok without presenting those credentials.

 

I'll take a closer look.

 

11 hours ago, dmacias said:

Also I noticed I get this in the system log

 

Is it possible that you don't have the dynamix.system.temp plugin installed ?

 

That log entry should be coming from the ControlR app trying to get the system temp, but failing to do so since it's not installed.

Link to comment
15 minutes ago, jbrodriguez said:

Thanks for the heads up @dmacias !

 

I'm not using those variables, although ... I probably should ? :o O.o

 

Are they used to access nut's UI ?

 

The status report from the nut binary seem to work ok without presenting those credentials.

 

I'll take a closer look.

 

 

Is it possible that you don't have the dynamix.system.temp plugin installed ?

 

That log entry should be coming from the ControlR app trying to get the system temp, but failing to do so since it's not installed.

I wasn't thinking. You don't need username and password to access UPS variables, those are just for the monitor. I just assumed thats what broke it for me since that was what I was working on. But it was the UPS name. I was probably using the default cfg when testing and it worked but when I changed the name of the UPS it stopped working. I don't know if you hard coded it to "/usr/bin/upsc [email protected]" but it could be any name or ip "/usr/bin/upsc $NAME@$IPADDR".

 

I figured that's what the log entry was from. I don't have the system temp plugin installed. I use my own IPMI plugin.

Link to comment
20 minutes ago, dmacias said:

but it could be any name or ip "/usr/bin/upsc $NAME@$IPADDR"

 

No, I didn't hardcode [email protected], I read both variables from nut.cfg.

 

But I do so only on plugin startup, I don't monitor the config file for changes.

 

If you restart the plugin, does it work ?

 

26 minutes ago, dmacias said:

I figured that's what the log entry was from. I don't have the system temp plugin installed. I use my own IPMI plugin.

 

Got it. I'll improve that.

 

Didn't know about your IPMI plugin. I'll check it out.

Link to comment
17 minutes ago, jbrodriguez said:

 

Was going to say that :)

 

Can you send me the output of


ps aux | grep controlr

?

root@Brunnhilde:~# ps aux | grep controlr
root      6874  0.0  0.0  10264  6488 ?        Sl   13:03   0:00 /usr/local/emhttp/plugins/controlr/controlr -port 2378 -certdir /boot/config/ssl/certs -showups false
root     16829  0.0  0.0   9640  1840 pts/0    S+   14:00   0:00 grep controlr
root@Brunnhilde:~# 

 

Link to comment
  • 2 weeks later...
 
It happens on my servers too, but I'm not sure why.
 
Seems like unRAID is trying to execute the plugin (stop/start?), as part of the startup process?, but the files are still not available.
You could move the stop and start after the bundle remove and install commands.

Method 2 is you could add the emhttp path to the bundle then change the get controlr bundle to this.



This will install it as a Slackware package. It will remove the old and install the new. This will give a warning about makepkg but should work. Then remove these lines

# Remove emhttp files so we can re-install.rm -rf /usr/local/emhttp/plugins/&name;/* 2>/dev/null# Install the 'bundle'.tar -xf /boot/config/plugins/&name;/&bundle; -C /usr/local/emhttp/plugins



Method 3 is you could leave the bundle File section as is, still include the path in the bundle but manually upgradepkg --install-new.

With both methods you can use removepkg to remove the bundle on plugin uninstall.

Also you could use makepkg to create the bundle. This allows you to add install script and package description. If you look at my IPMI-unRAID repo I explain how I make Slackware packages on my laptop. And under Source you can see the layout and the script I use.

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.