Plugin is not persisting between container recreations

[radokristof]

Support guidelines

• I've read the support guidelines

I've found a bug and checked that ...

• ... the documentation does not mention anything about my problem
• ... there are no open or closed issues that are related to my problem

Description

If there is any added plugin added via lnms plugin:add, these will not persist between container recreations.

Expected behaviour

All plugins should be available even after recreation

Actual behaviour

Plugins are missing, need to manually install them.

Steps to reproduce

1. Install a plugin, like: lnms plugin:add socialiteproviders/saml2
2. Trigger a container recreation, eg.: add a new env variable in docker-compose
3. Check installed plugins

Docker info

Client: Docker Engine - Community
 Version:    25.0.4
 Context:    default
 Debug Mode: false
 Plugins:
  buildx: Docker Buildx (Docker Inc.)
    Version:  v0.13.0
    Path:     /usr/libexec/docker/cli-plugins/docker-buildx
  compose: Docker Compose (Docker Inc.)
    Version:  v2.24.7
    Path:     /usr/libexec/docker/cli-plugins/docker-compose

Server:
 Containers: 22
  Running: 21
  Paused: 0
  Stopped: 1
 Images: 21
 Server Version: 25.0.4
 Storage Driver: overlay2
  Backing Filesystem: extfs
  Supports d_type: true
  Using metacopy: false
  Native Overlay Diff: true
  userxattr: false
 Logging Driver: json-file
 Cgroup Driver: systemd
 Cgroup Version: 2
 Plugins:
  Volume: local
  Network: bridge host ipvlan macvlan null overlay
  Log: awslogs fluentd gcplogs gelf journald json-file local splunk syslog
 Swarm: inactive
 Runtimes: io.containerd.runc.v2 runc
 Default Runtime: runc
 Init Binary: docker-init
 containerd version: ae07eda36dd25f8a1b98dfbf587313b99c0190bb
 runc version: v1.1.12-0-g51d5e94
 init version: de40ad0
 Security Options:
  apparmor
  seccomp
   Profile: builtin
  cgroupns
 Kernel Version: 6.1.0-18-amd64
 Operating System: Debian GNU/Linux 12 (bookworm)
 OSType: linux
 Architecture: x86_64
 CPUs: 4
 Total Memory: 7.755GiB
 Name: marinero-xs01
 ID: 6cb1359a-8602-4713-bbc0-d6fb2acd851d
 Docker Root Dir: /var/lib/docker
 Debug Mode: false
 Experimental: false
 Insecure Registries:
  127.0.0.0/8
 Live Restore Enabled: false
 Default Address Pools:
   Base: 192.168.0.0/16, Size: 24

WARNING: API is accessible on http://0.0.0.0:2376 without encryption.
         Access to the remote API is equivalent to root access on the host. Refer
         to the 'Docker daemon attack surface' section in the documentation for
         more information: https://docs.docker.com/go/attack-surface/

Docker Compose config

No response

Logs

Logs not relevant

Additional info

No response

[murrant]

Hmm, plugins are stored in composer.plugins.json

As a work around, you could map that file into your container.

I agree, would be good to support this. It might make sense to generate composer.plugins.json from an env variable.

[radokristof]

Yes, it would be great.
However, I don't think if just persisting composer.json is usually enough.
Right now, for me socialiteproviders/saml2 requires additional commands to run inside the container:

docker exec librenms apk add php-xmlwriter
docker exec librenms chown librenms:librenms -R *
docker exec librenms lnms plugin:add socialiteproviders/saml2
docker exec librenms echo "SESSION_SECURE_COOKIE=true" >> .env
docker exec librenms echo "SESSION_SAME_SITE_COOKIE=none" >> .env

Add php-xmlwriter package, as it is needed by saml2, change file ownership, as lnms command will say that composer.json is not writable, add plugin and then modify the .env.

I could also build a custom image, but usually I don't like that approach for such small changes like this. For the .env file, I did not find a solution how to make it persistent, and the docker envs does not allow to override all env variables.

[murrant]

Remember it is not composer.json, but composer.plugins.json ;)

[radokristof]

Hmm, lnms command just always says that the file ./composer.json is not writable :)
Maybe it is just some ownership inconsistency problem with my install?

[murrant]

Hmm, maybe composer checks that it can write to composer.json even though it doesn't need to write to it in this case.