search

gpdm / nut

Network UPS Tools in Docker
Other
31 stars 9 forks source link

Permission error in docker #1

Open rt400 opened 2 years ago

rt400 commented 2 years ago

Hi, i work with your README and i get error 

        ERROR: '/etc/nut/ups.conf' mode is too permissive.

            recommended permissions: 0440

            recommended owner:uid=100(nut) gid=101(nut) groups=101(nut),14(uucp),101(nut)

        current permissions:

          File: /etc/nut/upsd.users

          Size: 118         Blocks: 8          IO Block: 4096   regular file

        Device: 10302h/66306d   Inode: 10889818    Links: 1

        Access: (0440/-r--r-----)  Uid: ( 1000/ UNKNOWN)   Gid: ( 1000/ UNKNOWN)

        Access: 2021-11-18 14:55:24.000000000

        Modify: 2021-11-18 14:43:18.000000000

any idea how to fix it ?

gpdm commented 2 years ago

Hi,

Did you create your own set of config files and mount them to the Docker container, i.e. by passing the 

  -v /path/to/nut-config:/etc/nut

argument to Docker?

If yes, then easiest fix to do on your host, i.e. the /path/to/nut-configfile location, do something like:

cd /path/to/nut-config
chmod 0440 ups.conf upsd.conf upsd.users
chown 100:101 ups.conf upsd.conf upsd.users

Replace /path/to/nut-config by the actual path location, where you stored your config files.

Let me now if this helps.

-GP

gpdm commented 2 years ago

README updates, fixed in

rt400 commented 2 years ago

thanks for your reply. i did that but still same error. why you have to check it ? can your remove this checking ? also do you have a docker-compose version ?

rt400 commented 2 years ago

if i run with 100:100 its work but the driver failed to load

gpdm commented 2 years ago

why you have to check it ? can your remove this checking ?

Well, that's a security thing, permisions should never be too permissive as a general rule.

And AFAIK, the NUT upsd daemon will fail to start if permissions are incorrect.

So the pre-check is there as a safety net for both situation, making sure the permissions are right, and preventing obsure startup errors.

also do you have a docker-compose version ?

Not currently, but it would propably look something like this:

version: "3.7"

services:
  upsd:
    image: gpdm/nut-upsd:latest
    # privileged: true
    volumes:
      - vol.nut-upsd.upsd.nut:/etc/nut
    ports:
      - "3493:3493"
    networks:
      - default

volumes:
  vol.nut-upsd.upsd.nut:

That's missing the entire privileged and cgroup stuff though, I would need to investigate this first.

if i run with 100:100 its work but the driver failed to load

That's possibly because of missing access to the device tree. As noted, either run in priviliged mode (lesser secure), or do the device mapping route (better security).

The container must have access to /dev/bus/usb/ in one way or the other to load the driver and gain exclusive control for the UPS.

rt400 commented 2 years ago

i set like this:

    image: gpdm/nut-upsd:latest
    container_name: Nut-Ups
    restart: always
    ports:
      - 3493:3493
    devices:
      - /dev/bus/usb/001/005
    restart: always
    volumes:
      - ./config/:/etc/nut/
      - /dev/bus/usb:/dev/bus/usb
      - /etc/localtime:/etc/localtime
    # privileged: true
    network_mode: bridge

but still get error : 


*** NUT upsd startup ***

Starting up the UPS drivers ...

Network UPS Tools - UPS driver controller 3.8.0-3220-g866b921892

Network UPS Tools - Megatec/Q1 protocol USB driver 0.12 (3.8.0-3220-g866b921892)

No supported devices found. Please check your device availability with 'lsusb'

and make sure you have an up-to-date version of NUT. If this does not help,

try running the driver with at least 'subdriver', 'vendorid' and 'productid'

options specified. Please refer to the man page for details about these options

(man 8 blazer_usb).

Driver failed to start (exit status=1)

ERROR on driver startup.
jimklimov commented 2 years ago

Cheers, I wonder if the problem is with permissions for the USB device (normally the OS would have a handler to grab everything-USB, and then udev/devfs/upower/... rule sets to assign the device node owner and permissions so the NUT driver run-time account may use that - 100:101 in this case if the host-container IDs are mapped the same way). "Traditional" NUT packages include the rule files for several frameworks, maybe you'd have to apply those on the host.

Also wondering if you can start the driver with more debugging in the container (pass several -D options to its binary like blazer_usb in this case) to learn what it reports as seen or forbidden to see. For "Qx" protocol devices, try also nutdrv_qx (especially if trying NUT builds from source) as the newer effort which combines older related drivers into sub-drivers under a common framework. And specifying subdriver may be needed if guesswork does not work, as well as vendorid, productid, bus, maybe even string vendor/product values, can help the driver identify the device it has to handle (more so for systems with several USB UPSes, but may also be needed to help pick the subdriver right).

Finally, the version there looks weird - NUT is not up to "3.8.0" yet ;) Wondering if it is possible to twist this project into building containers along with builds of NUT from source, to test the latest abilities...

gpdm commented 2 years ago

@jimklimov

Finally, the version there looks weird - NUT is not up to "3.8.0" yet ;) Wondering if it is possible to twist this project into building containers along with builds of NUT from source, to test the latest abilities...

The second version referenced is the OS build release, originating from Alpine linux, which serves as the basis to build this container.

I.e. on a a current 3.15 Alpine container build, you'd get to see something like this, i.e. 3.15.0_alpha...

*** NUT upsd startup ***
Starting up the UPS drivers ...
Network UPS Tools - UPS driver controller 3.15.0_alpha20210804-3402-gced1683082
Network UPS Tools - Generic HID driver 0.41 (3.15.0_alpha20210804-3402-gced1683082)

This has nothing to do with the upstream release of NUT, which is currently 2.7.4.

gpdm commented 2 years ago

@jimklimov

Also wondering if you can start the driver with more debugging in the container (pass several -D options to its binary like blazer_usb in this case) to learn what it reports as seen or forbidden to see. For "Qx" protocol devices, try also nutdrv_qx (especially if trying NUT builds from source) as the newer effort which combines older related drivers into sub-drivers under a common framework. And specifying subdriver may be needed if guesswork does not work, as well as vendorid, productid, bus, maybe even string vendor/product values, can help the driver identify the device it has to handle (more so for systems with several USB UPSes, but may also be needed to help pick the subdriver right).

I didn't build that functionality in to support dynamic startup options. The startup script https://github.com/gpdm/nut/blob/master/nut-upsd/files/startup.sh though has already a -D in there by default:

#65 exec /usr/sbin/upsd -D || { printf "ERROR on daemon startup.\n"; exit; }

I believe this could be easily enhanced to accept dynamic arguments as well.

gpdm commented 2 years ago

@jimklimov

as per 11b240a

implement dynamic arguments passed to upsd, to allow increasing verbosity, i.e. by executing something like

docker run -it --rm -v `pwd`/files/etc/nut:/etc/nut nutupsd -D -D -D
jimklimov commented 2 years ago

Nice! Also note that in current NUT master branch there is now support for debug_min config file settings for daemons (drivers, upsd, upsmon) to bolt and change debugging that way instead of hacking start-up method scripts.

But that is not part of a release yet, so not packaged...