September 10, 20205 yr Author Pentium-D !! Wow !! that's really a testament to how flexible/permissive Unraid (linux) is, I'm not sure that Windows will run on that But yes, the plugin uses system temp, it has no provision for coretemp. That should be the issue.
September 12, 20205 yr The old Pentium D ran Windows 7 just fine. It was blazing fast when I bought it just FIFTEEN years ago! lol! 'course Windows 10 on that system was another story! When I decided to add some shared drives to the family network, figured since I had that old beast laying around, why not use it as an unRAID server. Works FAIRly well, but as I said I hope to upgrade it early next year. thanks for your assistance - I'm guessing the upgrade will resolve my ControlR issues.
September 16, 20205 yr I'm having a similar issue to Cilusse I think. My output is Quote /usr/local/emhttp/plugins/controlr/controlr -port 2378 -certdir '/boot/config/ssl/certs' I: 2020/09/16 18:28:32 app.go:58: controlr v2020.05.09|2.19.0 starting ... I: 2020/09/16 18:28:32 app.go:66: No config file specified. Using app defaults ... I: 2020/09/16 18:28:32 app.go:290: cert: generating self certs F: 2020/09/16 18:28:33 app.go:73: Unable to retrieve unRAID info (key.WriteFile: open /boot/config/ssl/certs/controlr_key.pem: no such file or directory). Exiting now ... and output from ls -l is Quote ls -l /boot/config/ssl/certs total 4 -rw------- 1 root root 2868 Sep 16 15:04 unraid_unraid_bundle.pem I have tried to delete the files I had in certs, and then go from yes on ssl to no, and then back. even rebooted. but I still only get the one file. As you can see from the first qoute I get the error that my controlr_key.pem is missing, but I can't seem to re-create it.
September 18, 20205 yr Author Yes, that issue was about the name of the server ... is your server name unraid ? If you look in /var/local/emhttp/var.ini, what's the name of the server there (entry "NAME") ?
September 18, 20205 yr 5 hours ago, jbrodriguez said: Yes, that issue was about the name of the server ... is your server name unraid ? If you look in /var/local/emhttp/var.ini, what's the name of the server there (entry "NAME") ? Yes I did check that also, forgot to mention it. Quote cat /var/local/emhttp/var.ini | grep -i name NAME="unraid" shareAvahiSMBName="%h" shareAvahiAFPName="%h-AFP" sbName="/boot/config/super.dat" I wonder why I won't get that file which is missing...what is it for?
September 19, 20205 yr Author I have the feeling it's a permissions issue. When testing are you issuing the command as root or you have another user in the system ?
September 19, 20205 yr 2 hours ago, jbrodriguez said: I have the feeling it's a permissions issue. When testing are you issuing the command as root or you have another user in the system ? I am root, but I have another user setup for smb-shares. Quote root@unraid:~# whoami root root@unraid:~# /usr/local/emhttp/plugins/controlr/controlr -port 2378 -certdir '/boot/config/ssl/certs' I: 2020/09/19 19:34:18 app.go:58: controlr v2020.05.09|2.19.0 starting ... I: 2020/09/19 19:34:18 app.go:66: No config file specified. Using app defaults ... I: 2020/09/19 19:34:18 app.go:266: cert: found unraid_unraid_bundle.pem I: 2020/09/19 19:34:18 app.go:171: host(https://192.168.1.5:443) I: 2020/09/19 19:34:18 core.go:81: starting service Core ... I: 2020/09/19 19:34:18 core.go:304: Created system sensor ... I: 2020/09/19 19:34:18 core.go:334: No ups detected ... 2020/09/19 19:34:18 Unable to wait for process to finish: exit status 1
September 19, 20205 yr Author 18 minutes ago, Nischi said: I: 2020/09/19 19:34:18 app.go:66: No config file specified. Using app defaults ... I: 2020/09/19 19:34:18 app.go:266: cert: found unraid_unraid_bundle.pem Hey ! It's working ! 19 minutes ago, Nischi said: I: 2020/09/19 19:34:18 core.go:334: No ups detected ... 2020/09/19 19:34:18 Unable to wait for process to finish: exit status 1 The other issue you're having is related to the system sensor The output of /usr/bin/sensors -A should be some error. Can you check and post here ?
September 19, 20205 yr 1 hour ago, jbrodriguez said: Hey ! It's working ! The other issue you're having is related to the system sensor The output of /usr/bin/sensors -A should be some error. Can you check and post here ? Quote /usr/bin/sensors -A No sensors found! Make sure you loaded all the kernel drivers you need. Try sensors-detect to find out which these are. ah, I think it's related to me having a ryzen 3800x. Thanks
September 23, 20205 yr Hi, apologies if this is answered elsewhere. - I have installed the plugin - I have created a new user on unraid - I enable the ControlR server - I open the webUI - I try to log in as the new user and root - I cannot log in it says Unable to connect to server (401) - Unauthorized Any ideas Edited September 23, 20205 yr by simplygk Added more info
September 23, 20205 yr 6 hours ago, simplygk said: Hi, apologies if this is answered elsewhere. - I have installed the plugin - I have created a new user on unraid - I enable the ControlR server - I open the webUI - I try to log in as the new user and root - I cannot log in it says Unable to connect to server (401) - Unauthorized Any ideas There is something a bit off from your described steps. You should not need to create a new user on Unraid - the plugin wants you to use the same user as used for the Unraid GUI (user=root, password=whatever-you-set).
September 24, 20205 yr 19 hours ago, itimpi said: There is something a bit off from your described steps. You should not need to create a new user on Unraid - the plugin wants you to use the same user as used for the Unraid GUI (user=root, password=whatever-you-set). 11 hours ago, jbrodriguez said: That's right you need to login as root Thanks alot - So got it working on the web and via the app when I log in on the same network I have set up OpenVPN and confirmed that works as when that it enabled I can access the unraid webui from my phone. However, I cannot use the ControlR app and access it when I am on OpenVPN - Any ideas?
September 25, 20205 yr Author If you're inside the openvpn tunnel, it behaves the same as if you were locally in your network. What is the app showing ? If you refresh the server on the app it's listed as offline (even if it is online) ?
September 25, 20205 yr 5 hours ago, jbrodriguez said: If you're inside the openvpn tunnel, it behaves the same as if you were locally in your network. What is the app showing ? If you refresh the server on the app it's listed as offline (even if it is online) ? I don’t know if it fixes itself everytime I post on the forum but it has 😂 thanks
November 6, 20205 yr I have this working over OpenVPN but cannot get it working on NGINX Proxy Manager. Is there a configuration guide as to what port should be forwarded from controlr? Inside my network server:80 works currently to access it.
December 21, 20205 yr I recently noticed that the Controlr plugin is stopped. Disabling and enabling it will set the status to Running for a short while, but then it will switch back to stopped after a few seconds. The controlr.log is: I: 2020/12/20 15:52:51 app.go:58: controlr v2020.05.09|2.19.0 starting ... I: 2020/12/20 15:52:51 app.go:66: No config file specified. Using app defaults ... I: 2020/12/20 15:52:51 app.go:171: host(https://192.168.2.250:443) I: 2020/12/20 15:52:51 core.go:81: starting service Core ... I: 2020/12/20 15:52:51 core.go:307: Created ipmi sensor ... I: 2020/12/20 15:52:51 core.go:334: No ups detected ... I have gone through the topic and tried various suggested troubleshooting steps. If I run /usr/local/emhttp/plugins/controlr/controlr -port 2378 -showups (same results if I include the certs argument), I get: I: 2020/12/20 15:54:30 app.go:58: controlr v2020.05.09|2.19.0 starting ... I: 2020/12/20 15:54:30 app.go:66: No config file specified. Using app defaults ... I: 2020/12/20 15:54:30 app.go:266: cert: found Tower_unraid_bundle.pem I: 2020/12/20 15:54:30 app.go:171: host(https://192.168.2.250:443) I: 2020/12/20 15:54:30 core.go:81: starting service Core ... I: 2020/12/20 15:54:30 core.go:307: Created ipmi sensor ... I: 2020/12/20 15:54:30 core.go:325: Created apc ups ... 2020/12/20 15:54:50 Unable to wait for process to finish: exit status 1 /usr/bin/sensors -A is detecting sensors and providing data. /sbin/apcaccess pulls up my UPS info. However, I think there is an issue with creating the ipmi sensors. I do have a /boot/config/plugins/ipmi/ipmi.cfg. When I run /usr/sbin/ipmisensors --comma-separated-output --output-sensor-state --no-header-output --interpret-oem-data I get base64: invalid input /usr/sbin/ipmi-sensors: connection timeout However, if I run /usr/sbin/ipmi-sensors --comma-separated-output --output-sensor-state --no-header-output --interpret-oem-data It pulls all my info as expected 4,CPU Temp,Temperature,Nominal,53.00,C,'OK' 71,System Temp,Temperature,Nominal,32.00,C,'OK' 138,Peripheral Temp,Temperature,Nominal,0.00,C,'OK' 205,PCH Temp,Temperature,Nominal,48.00,C,'OK' 272,P1-DIMMA1 TEMP,Temperature,Nominal,42.00,C,'OK' 339,P1-DIMMA2 TEMP,Temperature,N/A,N/A,C,N/A 406,P1-DIMMB1 TEMP,Temperature,Nominal,41.00,C,'OK' 473,P1-DIMMB2 TEMP,Temperature,N/A,N/A,C,N/A 540,P1-DIMMC1 TEMP,Temperature,Nominal,45.00,C,'OK' 607,P1-DIMMC2 TEMP,Temperature,N/A,N/A,C,N/A 674,P1-DIMMD1 TEMP,Temperature,Nominal,45.00,C,'OK' 741,P1-DIMMD2 TEMP,Temperature,N/A,N/A,C,N/A 808,FAN 1,Fan,Nominal,375.00,RPM,'OK' 875,FAN 2,Fan,N/A,N/A,RPM,N/A 942,FAN 3,Fan,N/A,N/A,RPM,N/A 1009,FAN 4,Fan,N/A,N/A,RPM,N/A 1076,FAN A,Fan,N/A,N/A,RPM,N/A 1143,Vcore,Voltage,Nominal,1.00,V,'OK' 1210,3.3VCC,Voltage,Nominal,3.30,V,'OK' 1277,12V,Voltage,Nominal,11.98,V,'OK' 1344,VDIMM,Voltage,Nominal,1.35,V,'OK' 1411,5VCC,Voltage,Nominal,5.12,V,'OK' 1478,CPU VTT,Voltage,Nominal,1.06,V,'OK' 1545,VBAT,Voltage,Nominal,3.46,V,'OK' 1612,VSB,Voltage,Nominal,3.55,V,'OK' 1679,AVCC,Voltage,Nominal,3.31,V,'OK' 1746,Chassis Intru,Physical Security,Nominal,N/A,N/A,'OK' Any insight is appreciated!
December 21, 20205 yr Author HI, yes that's strange, looks like ipmisensors is just a wrapper over ipmi-sensors ? Maybe there was a change with binary I didn't notice. Can you check what /usr/sbin/ipmisensors is ? As a workaround you could probably just convert it to a shell script invoking /usr/sbin/ipmi-sensors In any case, I'll take a look during the holidays
December 21, 20205 yr 1 hour ago, jbrodriguez said: HI, yes that's strange, looks like ipmisensors is just a wrapper over ipmi-sensors ? Maybe there was a change with binary I didn't notice. Can you check what /usr/sbin/ipmisensors is ? As a workaround you could probably just convert it to a shell script invoking /usr/sbin/ipmi-sensors In any case, I'll take a look during the holidays Likewise just throws that base64 error. root@Tower:~# /usr/sbin/ipmisensors base64: invalid input /usr/sbin/ipmi-sensors: connection timeout Much appreciated, I will try and figure out how to convert it to the shell script as well.
December 22, 20205 yr I did a little bit of troubleshooting in the meantime. I noticed that ipmisensors just pulls info from the ipmi.cfg file and passes it to /usr/sbin/ipmisensors via: [ $NETWORK == "enable" ] && OPTIONS=" -h $IPADDR -u $USER -p $(echo $PASSWORD | base64 --decode)" That is when I noticed it is expecting the password to be coded as base64. If I code my PW as base64 it prevents the "base64: invalid input" error I saw earlier. However, I still get the "/usr/sbin/ipmi-sensors: connection timeout" error. If I call /usr/sbin/ipmi-sensors directly I see all the correct info, but for some reason calling it from the script results in a timeout. The only for me to get around this was to comment out the network parsing from ipmi.cfg #!/bin/bash CONFIG="/boot/config/plugins/ipmi/ipmi.cfg" OPTIONS="" IGNORED="" # read our configuration [ -e "$CONFIG" ] && source "$CONFIG" #[ $NETWORK == "enable" ] && OPTIONS=" -h $IPADDR -u $USER -p $(echo $PASSWORD | base64 --decode)" [[ $IGNORE != "" ]] && IGNORED=" -R $IGNORE " /usr/sbin/ipmi-sensors $OPTIONS $IGNORED $@ I have confirmed the IPADDR, USER, and PASSWORD (as base64 or not) are correct in the ipmi.cfg, but something about calling it from the script results in the timeout. Using "whoami" from within the script or the command line shows both are being run as root. Edited December 22, 20205 yr by imthekuni
December 22, 20205 yr Author 5 hours ago, imthekuni said: I have confirmed the IPADDR, USER, and PASSWORD (as base64 or not) are correct in the ipmi.cfg Not exactly sure how ipmi works, but tt looks like ipmi-sensors works without those variables. You could try commenting these variables in ipmi.cfg
March 20, 20215 yr It doesn't seem to work with the unRAID remote beta Once I updated my DNS it was super unwilling to connect. Which... beta, but still, fyi. I'll upload some logs and jazz later, for now, it's time for some Snyder Cut and, I imagine, a brief morning period for what's left of my childhood. (ok, ok, judgement reserved... for now)
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.