Problem: snmp-ups can't be launch with bios user

[barraudl]

Signed-off-by: barraudl lilianbarraud@eaton.com

[jimklimov]

LGTM for a stop-gap solution, but I think a proper one lies on the NUT side - in dump mode with a finite amount of loops (perhaps with 1?) it just should not require the statepath, IMHO. Or could use a dummy one like /tmp...

[jimklimov]

Oh, there already is support for a NUT_STATEPATH envvar in place. So this PR granting extra rights elevation could be avoided, instead setting an accessible working directory for the called subprocess :)

Shell example:

jim@jimoi:~/nut-DMF$ NUT_STATEPATH=/tmp ./drivers/snmp-ups-dmf -s testsnmp -x port=10.10.10.10 -x dmfdir=`pwd`/scripts/DMF/dmfsnmp.d/ -d 1
Network UPS Tools - Generic SNMP UPS driver (DMF) 1.02 (2.7.4-1672-gf1b4343c)
writepid: fopen /var/state/ups/snmp-ups-dmf-testsnmp.pid: Permission denied
Detected Eaton 9PX on host 10.10.10.10 (mib: mge 0.51)

ambient.humidity: 0
ambient.temperature: 0.0
battery.charge: 100
battery.charge.low: 20
battery.runtime: 2820
battery.runtime.low: 180
battery.voltage: 198.00
device.mfr: Eaton
device.model: Eaton 9PX
device.serial: G202E02032
device.type: ups
driver.name: snmp-ups-dmf
driver.parameter.dmfdir: /home/jim/nut-DMF/scripts/DMF/dmfsnmp.d/
driver.parameter.pollinterval: 2
driver.parameter.port: 10.10.10.10
driver.parameter.synchronous: no
driver.version: 2.7.4-1672-gf1b4343c
driver.version.data: mge MIB 0.51
driver.version.internal: 1.02
input.phases: 1
input.transfer.reason: 
outlet.desc: Main Outlet
outlet.id: 0
output.current: 3.00
output.frequency: 49.00
output.phases: 1
output.voltage: 229.00
ups.beeper.status: enabled
ups.delay.shutdown: 20
ups.delay.start: 30
ups.firmware: 01.10.0032
ups.firmware.aux: HF
ups.load: 16
ups.mfr: Eaton
ups.model: Eaton 9PX
ups.serial: G202E02032
ups.start.auto: yes
ups.status: OL
ups.test.result: done and passed
ups.timer.reboot: -1
ups.timer.shutdown: -1
ups.timer.start: -1

[jimklimov]

"Great"... in NUT there is also an ALTPIDPATH that is hardcoded in one compilation branch, and expands the NUT_STATEPATH envvar or uses the hardcoded STATEPATH in another, and also a PIDPATH that is also used in some places - mostly init-scripts but at least twice in common.c. I wonder if there's still a rationale for that, or they should be collapsed somehow for consistent behavior (e.g. altpidpath() used everywhere in C code and honoring an envvar over hardcoded values, if provided). Aaaarnoooo? @aquette ? :)

UPDATE: Ok, so there's not so much mixup as I claimed/feared initially: the PIDPATH as used in common.c::writepid() is default for programs running as root, like upsmon, which do not pass the full filename argument to the routine. Non-root programs like drivers and upsd pass the full path they get from altpidpath(). In this regard, the code matches the docs. The somewhat-inconsistency is with altpidpath() returning only the macro value predefined during configure script phase, if defined - but which is always defined (to value provided by user or to default/requested STATEPATH). So no fallbacks to any envvars. That's the buggy difference.

[jimklimov]

Posted the NUT-side solution at networkupstools/nut#473