How to grant openhabian user permission to run systemctl restart

[BigGeorgeTx (George M Hyde)]

I’m trying to implement a fix for a problem I encounter using NUT. From time to time, the Thing goes off line and when I check the status on my Pi, the driver isn’t working. I can resolve it 100% of the time by restarting the driver with systemctl restart nut-driver.

I tried setting up an Exec Binding Thing with this command. I added the command to the whitelist. But I get a permission error when I try to run it.

3-06 12:08:56.960 [INFO ] [openhab.event.ItemCommandEvent      ] - Item 'Restart_NUTdriver_Running' received command ON
2024-03-06 12:08:56.970 [INFO ] [penhab.event.ItemStatePredictedEvent] - Item 'Restart_NUTdriver_Running' predicted to become ON
2024-03-06 12:08:56.971 [INFO ] [openhab.event.ItemStateUpdatedEvent ] - Item 'Restart_NUTdriver_Running' updated to ON
2024-03-06 12:08:56.971 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'Restart_NUTdriver_Running' changed from OFF to ON
2024-03-06 12:08:56.981 [INFO ] [openhab.event.ItemStateUpdatedEvent ] - Item 'Restart_NUTdriver_Running' updated to ON
2024-03-06 12:08:57.019 [INFO ] [openhab.event.ItemStateUpdatedEvent ] - Item 'Restart_NUTdriver_Running' updated to OFF
2024-03-06 12:08:57.020 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'Restart_NUTdriver_Running' changed from ON to OFF
2024-03-06 12:08:57.021 [INFO ] [openhab.event.ItemStateUpdatedEvent ] - Item 'Restart_NUTdriver_Exit_Value' updated to 1
2024-03-06 12:08:57.022 [INFO ] [openhab.event.ItemStateUpdatedEvent ] - Item 'Restart_NUTdriver_Output' updated to Failed to restart nut-driver.service: Interactive authentication required.
See system logs and 'systemctl status nut-driver.service' for details.
Failed to restart nut-driver.service: Interactive authentication required.
See system logs and 'systemctl status nut-driver.service' for details.

I am running openHAB 4.1.1-1 using openhabian (bullseye) on a Pi 4B. I did some internet searches about how to grant permission for a user (in my case openhabian) to execute a command without having to provide an authentication password, but feared I would either create an unintended security vulnerability or mess things up if I experimented with ways to do this.

(I know that the better answer is to figure out why my NUT driver fails. I have spent time researching that and have fiddled with some settings, but don’t see a clear path to resolution, so I’m going with what I hoped would be an easier bandaid solution.)

[Wolfgang_S]

I don’t see any question but …
You wrote:

@BigGeorgeTx

I did some internet searches about how to grant permission for a user (in my case openhabian) to execute a command without having to provide an authentication password

Running the command from within OH would require the sudo command to be executed by user openhab not openhabian. openhabian is used on the commandline.

[Oliver2 (Oliver)]

You could add the command to the sudoers

visudo -f /etc/sudoers.d/myoverride
#then add:
openhab,openhabian ALL= NOPASSWD: /bin/systemctl

[rpwong (Russ)]

What they said, but in tutorial format:

Beginner's guide to an openHABian reboot/shutdown switch

UPDATE, February 2, 2021: I’ve made a few edits to this tutorial so that it works for OH2 and OH3. It’s still written with text-based items and DSL rules that work in both versions. If you prefer to build your system in OH3’s UI, it should be pretty easy to convert the items and rules. As I get deeper into openHAB, I’m finding that I have to reboot or shutdown my Raspberry Pi reasonably often. It seemed like a good idea to set up a switch on my sitemap for that purpose, but was not nearly as e…

As @Wolfgang_S notes, you only need to grant permissions for the openhab user.

@BigGeorgeTx

(I know that the better answer is to figure out why my NUT driver fails. I have spent time researching that and have fiddled with some settings, but don’t see a clear path to resolution, so I’m going with what I hoped would be an easier bandaid solution.)

Is this still the same issue you mentioned last year, with the same UPS?

Beginner's Guide to Network UPS Tools (NUT) on a Raspberry Pi

I noticed last week the my UPS Binding thing was offline. When I check the Pi4B running openHABian which runs openHAB and NUT, there was an error that the various nut services had failed due to a file in /etc/nut/ not existing. (Unfortunately, by the time I got around to troubleshooting today the journalctl and other log files had rotated and I can’t find the actual error on the system. I tried rebooting the Pi. Still NUT services didn’t work. I next tried removing and reinstalling (sudo ap…

FYI, openHABian now has the ability to install NUT, but I haven’t tried it yet.

[BigGeorgeTx (George M Hyde)]

@Oliver2

You could add the command to the sudoers

Thanks. I think that is exactly what I was looking for. I had seen that suggestion with my internet search, but wasn’t sure how risky it might be.

@rpwong

Is this still the same issue you mentioned last year, with the same UPS?

I don’t think it is the same issue, as it works (until it doesn’t).
I discussed this problem in this thread: NUT-Driver Stale Data

It is on a new SD card

@rpwong

FYI, openHABian now has the ability to install NUT, but I haven’t tried it yet.

I installed NUT using openHABian. When I migrated to openHAB 4.1, I decided to clean up this install. After running the upgrade, I backed up the openHAB files (using openHABian) and created a clean SD with a fresh download of the latest openHABian. That is when I used openHABian to install NUT, and other than the intermittent failures, it works (and as I said, I can fix it 100% of the time by restarting nut-driver.)

@Wolfgang_S

Running the command from within OH would require the sudo command to be executed by user openhab not openhabian.

Thank you.

[rpwong (Russ)]

@BigGeorgeTx

I don’t think it is the same issue, as it works (until it doesn’t).
I discussed this problem in this thread: NUT-Driver Stale Data

I see that you’re now using a CyberPower UPS, in which case this may be the solution:

4. If you’re using a CyberPower UPS, I also recommend looking at this post to avoid the “Error: Data Stale” issue: NUT & CyberPower UPS | /dev/urandom

[BigGeorgeTx (George M Hyde)]

@rpwong

I see that you’re now using a CyberPower UPS, in which case this may be the solution:

Yes, I replaced the UPS some time last year (I always swap them out when their Connected Equipment guarantee expires.).

I will try the settings suggested in the link you provided. Better to solve the problem than use a work around.

I had in my own research played with the MAXAGE parameter. It was not in the /etc/nut/upsmon.conf file as a default or in the commented sections. (Doesn’t mean it wouldn’t work, just not as obvious). I did change MAXAGE to 25 in the upsd.conf file where it is included in the defaults and comments, but it didn’t seem to make any difference.

I think I will first trying changing the DEADTIME parameter from 15 to 25 in the upsmon.conf file and see if that helps.