[Bug 278426] deskutils/py-paperless-ngx: RC scripts don't respect /etc/rc.conf configuration

From: <bugzilla-noreply_at_freebsd.org>
Date: Thu, 18 Apr 2024 07:57:23 UTC
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=278426

            Bug ID: 278426
           Summary: deskutils/py-paperless-ngx: RC scripts don't respect
                    /etc/rc.conf configuration
           Product: Ports & Packages
           Version: Latest
          Hardware: Any
                OS: Any
            Status: New
          Severity: Affects Only Me
          Priority: ---
         Component: Individual Port(s)
          Assignee: grembo@FreeBSD.org
          Reporter: freebsd.bugzilla@mail.tinsuke.com
          Assignee: grembo@FreeBSD.org
             Flags: maintainer-feedback?(grembo@FreeBSD.org)

TL;DR: The RC scripts (paperless-[beat|consumer|flower|migrate|webui|worker])
all have the 'load_rc_config' call after the rc.conf variables are accessed. As
a result, they always use the default values.

Long version:
I wanted to use gunicorn directly to access the service on my local network,
instead of using nginx.

So I made the static dir change that the man page suggests for that and started
the 'paperless-webui' service. It wasn't accessible from other machines.

Inspecting '/var/log/daemon.log' showed that the webui was:
> Listening at: http://127.0.0.1:8000

I checked the 'paperless-webui' RC script and found it used a
'paperless_webui_listen_address' variable with a default value of '127.0.0.1',
so I set that to 'paperless_webui_listen_address="0.0.0.0"' on my /etc/rc.conf
file and restarted the webui service.

It still didn't work, and I could see that it was still listening on
'127.0.0.1'.

By checking the RC scripting docs, I saw:
https://docs.freebsd.org/en/articles/rc-scripting/#rcng-confdummy
> ➋ Now load_rc_config is invoked earlier in the script, before any rc.conf(5) variables are accessed.

I checked the RC script and verified that this was not the case, for any of
them. Moving 'load_rc_config' to before the variables are accessed fixed it for
me, now my setting to listen on '0.0.0.0' is being respected.

-- 
You are receiving this mail because:
You are the assignee for the bug.