Local expression in Rule does not evaluate as they used to do

[vezinpi]

Not a big issue simply a request if easily doable.

The MSR logs files inside the container are owned by root witch is fine however, the permissions are very restrictive. I do not know if there is something wrong with my installation but the logs permission are set to 222 (write only). Even if the docker volume is set for Read/Write the log files are retaining these values.

I go around the problem by doing a chmod 777 on all reactor logs but every time there is an MSR log rotation the permissions are set back to 222. So unless the permission are implemented in the container there is no permanent solution to this (that I know of).

I do not know much about Docker container so I do not know what is involved here.

Can the logfiles permission be simply chaged in the container to at least allow "other" read permission?

Could the MSR log rotation routine implement a chmod to set the permission?

Just a small anoyance

Thanks

[toggledbits]

There should not be any log files inside the container. You should not have any reason to access anything inside the container.

[vezinpi]

Ok, I guess that I did not put enough information to be clear. I skipped the intro and went directely into what I beleive to be the issue. I should stick with the issue not the solution. My bad.

I do not go in the container to access the logs or change permissions but I did looked at them, trying understand how that works. Docker volumes, map the /var/reactor of the container to a directory on the host with read/write premissions. From the host it is then, via samba, shared to my PC where I would like to access the logs.

Because of the permissions of the files, I cannot access the files directely from my PC. I have to change the permissions on the Host before I can access them (It can however, be access from the hosts by using "sudo" ).

What I was trying to say in my initial post is that the permission are set to 222 in the container that get mapped to the the hosts and eventually to my PC. Changing the permissions on the host is only temporary until Reactor do a log rotation where the files changed back to 222. If the logfiles in the container were created with something like 226 the "read" permission for "other" would ripple all the way to the hosts a then to the PC.

Like I said in my first post, I am not a Docker specialist but I thought that the only way to permanentely change the logs permissions would be by the application at the container level where they are created.

That being said, I have been wrong before!

Again, not a big deal just convenience.

[toggledbits]

Please do an ls -l (on the docker host system) of the directory that's mapped to /var/reactor, and an ls -l of your logs directory. And, please post the contents of your config/logging.yaml file.

There's something definitely not right with your setup. Files produced by my containers are owned by root, that's normal, but that 222 permission is not something I've ever seen.

[vezinpi]

All my docker applications, including reactor, have a volume in my "automation" folder on the host.

vezinpi@RPI8G:~/automation $ ls -l
total 32
drwxr-xr-x  2 vezinpi vezinpi 4096 May 28  2023 docker-compose
drwxrwxrwx  4 vezinpi vezinpi 4096 Jan 14 13:41 esphome
drwxrwxrwx  8     472     472 4096 Feb  8 07:45 grafana
drwxrwxrwx 12 vezinpi vezinpi 4096 Feb  6 15:25 homeassistant
drwx------  3 vezinpi root    4096 Feb 22  2023 influxdb2
drwxrwxrwx  6 vezinpi vezinpi 4096 Jun 20  2024 reactor
drwxr-xr-x  9 vezinpi root    4096 Feb  8 03:28 ssl
drwxrwxrwx 11 vezinpi vezinpi 4096 Feb  8 07:52 zwave-js-ui

Here is the reactor folder:

vezinpi@RPI8G:~/automation $ ls -l reactor
total 64
drwxrwxrwx 2 vezinpi vezinpi  4096 Feb  5 21:38 config
drwxrwxr-x 2 root    root     4096 Feb  6 14:07 dist-config
drwxrwxrwx 2 vezinpi vezinpi  4096 Feb  8 06:23 logs
-rwxrw-rw- 1 vezinpi vezinpi 45473 Jan  3  2022 reactor-config-backup.json
drwxrwxrwx 7 vezinpi vezinpi  4096 Jun 20  2024 storage
vezinpi@RPI8G:~/automation $

Here is the log folder. Please note that some files still have read/write permissions for "other" . This is me changing the permission on the host to grant me access from my PC. The most recent one are back to write only (222). As the log rotation progresses they will all become 222.

vezinpi@RPI8G:~/automation/reactor $ ls -l logs
total 44688
-rwxrw-rw- 1 vezinpi vezinpi    6572 Feb  6 14:07 hass_config.json
-rwxrw-rw- 1 vezinpi vezinpi  288139 Feb  6 14:07 hass_services.json
-rwxrw-rw- 1 vezinpi vezinpi  308677 Feb  6 14:07 hass_states.json
--w--w--w- 1 root    root    1802037 Feb  8 08:02 reactor.log
--w--w--w- 1 root    root    4194194 Feb  8 06:23 reactor.log.1
--w--w-rw- 1 root    root    4194347 Feb  7 06:16 reactor.log.10
--w--w-rw- 1 root    root    4194366 Feb  8 02:48 reactor.log.2
--w--w-rw- 1 root    root    4193980 Feb  7 21:59 reactor.log.3
--w--w-rw- 1 root    root    4194236 Feb  7 19:04 reactor.log.4
--w--w-rw- 1 root    root    4194260 Feb  7 17:18 reactor.log.5
--w--w-rw- 1 root    root    4194318 Feb  7 15:13 reactor.log.6
--w--w-rw- 1 root    root    4194256 Feb  7 12:39 reactor.log.7
--w--w-rw- 1 root    root    4193917 Feb  7 10:39 reactor.log.8
--w--w-rw- 1 root    root    4194228 Feb  7 09:10 reactor.log.9
-rw-r--r-- 1 root    root      11755 Feb  5 19:45 unhandled.json
-rwxrw-rw- 1 vezinpi vezinpi   24164 Feb 28  2022 vera-status-initial.json
-rwxrw-rw- 1 vezinpi vezinpi   48401 Feb 28  2022 vera-user_data-initial.json
-rwxrw-rw- 1 vezinpi vezinpi 1263301 Nov  6  2022 zwavejs_devices_initial.json
vezinpi@RPI8G:~/automation/reactor $

config/logging.yaml

vezinpi@RPI8G:~/automation/reactor/config $ more logging.yaml
---
logging:
  default:
    level: 4
    streams:
      - type: console
        level: 0
      - type: file
        name: "reactor.log"
        mode: 0666
        maxsize: 4  # megabytes max size
        keep: 10     # copies of old logs
        #
        # capture_console: if true, (most) console output will be captured to
        #                  this stream (if you have multiple streams, this
        #                  feature can only be used by ONE of them). If you
        #                  turn this on (true), set the "console" type stream
        #                  (above) log level to 0 to avoid duplicate logging
        #                  entries. The default is false, console not captured.
        #capture_console: true
  app:
    level: 4
  httpapi:
    level: 4
  httpproxy:
    level: 4
  wsapi:
    level: 4
  Structure:
    level: 4
  Controller:
    level: 4
  OWMWeatherController:
    level: 4
  VeraController:
    level: 4
  HubitatController:
    level: 4
  HassController:
    level: 4
  Rule:
    level: 5
  Engine:
    level: 5
(END)

Hope this help

[toggledbits]

The YAML parser doesn't like the octal value in mode: 0666. The parser library changed standard a while back, and I guess there's so little use of octal in Reactor that yours is the first report that points back to it.

Change your mode: 0666 to mode: 0o666.

Additional note/edit here: Use of 0o as a prefix for octal is the YAML 1.2 (2009) standard. Many web-based YAML editors don't support this standard, and will parse that form incorrectly. For example, the YAML editor at codebeautify.org currently parses 0o644 as 0. The YAML checker at yamllint.com works correctly with 0o prefixing (fortunately). Be careful what tools you're using out there, and be suspicious around octal values until you know they are parsed correctly.

[vezinpi]

Super, it worked as expected.

My MSR installation date from all the way back at the begining of this treck. I do recollect adjusting the # of logs and size but not adding the "mode". In any case, I see from the dist-config/logging.yaml that the default is 0644 (which would work just fine) and that it is commented out. That is probably what everybody have and the reason why I was the lone woolf out there. I think I will follow the pack and comment it out.

EDIT: I did add the "mode" back in dec 2021 to fix a similar issue. Things have changed/evolved since causing the issue to show up again.

Many thanks

[toggledbits]

@vezinpi said in [SOLVED]Logs permissions for Docker Install:

from the dist-config/logging.yaml that the default is 0644 (which would work just fine)

Yes, and that needs to read 0o644 now -- I've fixed that for the next build. The default is actually 0o640 in the code, so I've fixed the distribution template for that as well.