[Plugin] ControlR

[jbrodriguez]

16 hours ago, popwebz said:

I am not able to see logs in the ControlR app. I have set the server to use https and reconnected the app to use https as well. I suspect this may be the issue but I am not sure. I am running 6.4.0_rc10b.

 

Thank you

 

Hi, just a quick check, did you restart the plugin on the server ? Try that if you haven't.

 

If it still doesn't work, try the following:

$ cd /usr/local/emhttp/plugins/controlr
$ killall controlr
$ ./controlr

Try to get the logs in the app and then send me the output of the command (pm if you prefer).

 

 

[jbrodriguez]

9 hours ago, dmacias said:

You could move the stop and start after the bundle remove and install commands.

....

 

Thanks dmacias !

 

I'll check out your suggestions .

[dsmith44]

Hi, I'm having a bit of trouble getting started with the plugin, I think I'm just missing something obvious as I've tried all the none obvious things and got nowhere.

 

The plugin is installed and working, I can navigate to the interface and set permissions on docker/VMs for a none admin account I've created.

 

My plan is to allow my kids to turn two VMs on and off as the screen for this is in their room. One PC VM, one mac VM.

 

Whilst I'm able to login to the IOS app using the root account I cannot for the life of me find a combination of ports and SSL that work for their account.

 

My Unraid is AD joined if that makes a difference.

 

What am I supposed to be putting into the login screen to connect to the plugin?

 

Thanks

 

[jbrodriguez]

14 hours ago, dsmith44 said:

What am I supposed to be putting into the login screen to connect to the plugin?

 

Hi dsmith44, a couple of thoughts:

 

- You need to use the "root" password for the "none" account.

- The ssl port is where the webGUI runs (443 generally), not the plugin's port

- Not sure about AD, but shouldn't make a difference

 

[wgstarks]

This plugin doesn’t seem to be working with 6.4.0.

 

 

Controlr plugin is installed on the server.

[jbrodriguez]

6 hours ago, wgstarks said:

This plugin doesn’t seem to be working with 6.4.0.

Certainly strange.

 

Do the plugin logs show anything unusual ?

Did you switch between https/http ? Have self-signed certs ?

 

Let me know to further troubleshoot.

[wgstarks]

2 hours ago, jbrodriguez said:

Certainly strange.

 

Do the plugin logs show anything unusual ?

Did you switch between https/http ? Have self-signed certs ?

 

Let me know to further troubleshoot.

The server is using https (self-signed) but controlr log shows http. Not sure how to change this?

 

[jbrodriguez]

Thanks for the report wgstarks.

 

The plugin looks for 'certificate_bundle.pem' in /boot/config/ssl/certs (the folder can be customized as per above screenshot).

 

I'm guessing your self-signed cert is either named or located differently, so the plugin defaults to listening on http.

 

The solution is to make the the certificate name configurable. I'll do that.

 

The quick fix in your case, is to have your self-signed cert live as /boot/config/ssl/certs/certificate_bundle.pem or <custom dir>/certificate_bundle.pem, if you wish to do so.

 

 

[wgstarks]

4 minutes ago, jbrodriguez said:

The quick fix in your case, is to have your self-signed cert live as /boot/config/ssl/certs/certificate_bundle.pem or <custom dir>/certificate_bundle.pem, if you wish to do so.

You’re correct, unRAID self-signed certs are named <server name>_certificate_bundle.pem.

 

How do I configure a custom certificate name in unraid?

[jbrodriguez]

Oh ok, you're using a certificate that was self-signed by unRAID itself right ?

 

Now that there's a stable release, I'll revisit the ssl operation in unRAID and adjust accordingly.

 

I think it changed slightly in later RCs.

[wgstarks]

24 minutes ago, jbrodriguez said:

ok, you're using a certificate that was self-signed by unRAID itself right ?

Yes. If you set ssl=yes unRAID will either generate a self-signed cert or use whatever cert it finds in the folder.

[jbrodriguez]

v2018.01.19 (2.7.0) is out !

 

This release adds support for the sleep feature in the ControlR app.
It also adds ipmi-sensors support for system status.

 

Additional changes:
- Fix plugin install script (remove extraneous message on server boot)
- Adjust ssl handling for 6.4.0 stable unRAID release
- Use date based version
- Other bug fixes and performance improvements

 

Sleep will be available in an upcoming ControlR app release.

 

For ipmi, you need to install 

 

 

Finally, this release should properly work under the various 6.4.0 https variants.

[jbrodriguez]

Published v2018.01.19a as a small update to restart the plugin upon installation (if it's running), so it runs the latest version.

[wgstarks]

Updated the plugin and now can't get it to start-

 

 

Also, can't delete the cert dir.

 

Clip from sys log-

Jan 19 20:19:09 Brunnhilde ool www[22902]: /usr/local/emhttp/plugins/controlr/scripts/start
Jan 19 20:19:09 Brunnhilde sudo: root : TTY=unknown ; PWD=/usr/local/emhttp ; USER=root ; COMMAND=/usr/bin/bash -c /usr/local/emhttp/plugins/controlr/controlr -port 2378 -certdir '' 

 

[JM2005]

Same thing here.

[jbrodriguez]

MM that certdir doesn't look good

 

Shortest time solution: stop the plugin on the web gui then on a terminal, do:

 

cd /usr/local/emhttp/plugins/controlr
./controlr -certdir /boot/config/ssl/certs

 

[jbrodriguez]

can't look into this until next week, sorry for the inconvenience

[dmacias]

MM that certdir doesn't look good

 

Shortest time solution: stop the plugin on the web gui then on a terminal, do:

 

cd /usr/local/emhttp/plugins/controlr./controlr -certdir /boot/config/ssl/certs

 

 

I tried that before. This is the output:

 

[email protected]:~# /usr/bin/bash -c /usr/local/emhttp/plugins/controlr/controlr -port 2378 -certdir '/boot/config/ssl/certs' -showups

I: 2018/01/20 06:23:14 app.go:55: controlr v2.7.1-313-0b63a2b-v2018.01.19a starting ...

I: 2018/01/20 06:23:14 app.go:63: No config file specified. Using app defaults ...

I: 2018/01/20 06:23:14 core.go:73: starting service Core ...

2018/01/20 06:23:14 Unable to wait for process to finish: exit status 1

[email protected]:~#

 

It's the same with your shortened command also

[wgstarks]

11 minutes ago, dmacias said:

I tried that before. This is the output:

 

[email protected]:~# /usr/bin/bash -c /usr/local/emhttp/plugins/controlr/controlr -port 2378 -certdir '/boot/config/ssl/certs' -showups

I: 2018/01/20 06:23:14 app.go:55: controlr v2.7.1-313-0b63a2b-v2018.01.19a starting ...

I: 2018/01/20 06:23:14 app.go:63: No config file specified. Using app defaults ...

I: 2018/01/20 06:23:14 core.go:73: starting service Core ...

2018/01/20 06:23:14 Unable to wait for process to finish: exit status 1

[email protected]:~#

 

It's the same with your shortened command also

I got the same with CLI. Used the webGUI and just manually entered the cert dir path and I think that part is fixed.

Jan 20 08:36:48 Brunnhilde ool www[1414]: /usr/local/emhttp/plugins/controlr/scripts/stop
Jan 20 08:36:55 Brunnhilde ool www[27202]: /usr/local/emhttp/plugins/controlr/scripts/start
Jan 20 08:36:55 Brunnhilde sudo: root : TTY=unknown ; PWD=/usr/local/emhttp ; USER=root ; COMMAND=/usr/bin/bash -c /usr/local/emhttp/plugins/controlr/controlr -port 2378 -certdir '/boot/config/ssl/certs' 

Plugin still doesn't start though.

[jbrodriguez]

Hi dmacias/wgstarks, it's very odd.

 

It's working for me on 6.3.5 and a 6.4.0

 

I tried with/without ipmi, with/without dynamix.system.temp

 

I'm not really sure what the issue is.

 

I'll try adding some logs / removing some features next to check what's the issue you're getting.

[dmacias]

Hi dmacias/wgstarks, it's very odd.

 

It's working for me on 6.3.5 and a 6.4.0

 

I tried with/without ipmi, with/without dynamix.system.temp

 

I'm not really sure what the issue is.

 

I'll try adding some logs / removing some features next to check what's the issue you're getting.

I removed freeipmi package. Still have this error

Unable to wait for process to finish: exit status 1

Removed ipmi plugin and was able to start.

 

Edit: It's probably because I use a network ipmi connection and not the local kernel mods.

[jbrodriguez]

Yes, I think I know what the issue is.

 

I've released v2.7.2 mostly as a test.

 

dmacias/wgstarks, hopefully it should start now with the ipmi plugin installed, but it will be sending empty sensor data at the moment.

 

Can you check your logs for an "ipmi:args:" line ?

 

The idea is to then invoke ipmi-sensors manually with those arguments and check what's the error.

[wgstarks]

9 minutes ago, jbrodriguez said:

Yes, I think I know what the issue is.

 

I've released v2.7.2 mostly as a test.

 

dmacias/wgstarks, hopefully it should start now with the ipmi plugin installed, but it will be sending empty sensor data at the moment.

 

Can you check your logs for an "ipmi:args:" line ?

 

The idea is to then invoke ipmi-sensors manually with those arguments and check what's the error.

Plugin started. Don’t see any ipmi:args in system log. Or is there a seperate log for ControlR?

[wgstarks]

Nevermind. I should have just looked for myself. I’m getting lazy in my old age.

 

W: 2018/01/22 10:28:16 ipmi.go:97: ipmi:args:([--comma-separated-output --output-sensor-state --no-header-output --interpret-oem-data --always-prefix -h 10.0.1.22 -u wgstarks -p redacted --session-timeout=5000 --retransmission-timeout=1000])
	

[jbrodriguez]

Thanks for the reply !

 

Could you try the following from the command line (edit your pwd as needed)

/usr/sbin/ipmi-sensors --comma-separated-output --output-sensor-state --no-header-output --interpret-oem-data --always-prefix -h 10.0.1.22 -u wgstarks -p redacted --session-timeout=5000 --retransmission-timeout=1000

It seems it doesn't like some parameter