running on alternate/privileged ports, prometheus::manage_service: false doesn't let go of service management

[slvr32]

Affected Puppet, Ruby, OS and module versions/distributions

• Puppet: 6.19.0
• Ruby: 2.5.5p157
• Distribution: Oracle Linux Server release 8.4
• Module version: 11.2.0

How to reproduce (e.g Puppet code you use)

(yaml details...)

---

prometheus::version: 2.28.0

prometheus::download_url: 'http://example.com/prometheus-2.28.0.linux-amd64.tar.gz'

prometheus::manage_prometheus_server: true
prometheus::manage_config: true
prometheus::manage_service: false
prometheus::web_listen_address: "0.0.0.0:80"
prometheus::web_enable_lifecycle: true

and with/without the following to run as prometheus:prometheus or root:root

prometheus::manage_user: false
prometheus::manage_group: false
prometheus::user: root
prometheus::group: root

What are you seeing

1. If running as root:root, prometheus unit file option CapabilityBoundingSet= keeps prometheus from starting via systemd

2. If running as prometheus:prometheus, the following options need to be commented out for prometheus to start successfully...

#NoNewPrivileges=true
#LockPersonality=true
#RestrictRealtime=yes
#RestrictNamespaces=yes
#MemoryDenyWriteExecute=yes
#CapabilityBoundingSet=

(also used setcap to allow privileged port binding as prometheus:prometheus user)

$ sudo setcap 'cap_net_bind_service=+ep' /opt/prometheus-2.28.0.linux-amd64/prometheus

3. Attempting to take over service management with 'manage_service: false' leads to a duplicate declaration complaint for /etc/systemd/system/prometheus.service, suggesting that manage_service: false doesn't really cause the prometheus module to let go of the service management.

What behaviour did you expect instead

Systemd options that allow prometheus to start, even with alternative user/group, binding to privileged port, etc..

manage_service: false should release management of /etc/systemd/system/prometheus.service

Output log

Error: Could not retrieve catalog from remote server: Error 500 on SERVER: Server Error: Evaluation Error: Error while evaluating a Resource Statement, Evaluation Error: Error while evaluating a Resource Statement, Duplicate declaration: File[/etc/systemd/system/prometheus.service] is already declared at (file: /etc/puppetlabs/code/environments/site-modules/profile/manifests/prometheus/base.pp, line: 23); cannot redeclare (file: /etc/puppetlabs/code/environments/modules/systemd/manifests/unit_file.pp, line: 79) (file: /etc/puppetlabs/code/environments/modules/systemd/manifests/unit_file.pp, line: 79, column: 3) (file: /etc/puppetlabs/code/environments/modules/prometheus/manifests/config.pp, line: 191) on node example.com

Any additional information you'd like to impart

All of the above is related to an interest/need to run prometheus on a privileged port, via the available configuration, settings, implementation, etc... in the forge prometheus module

[AnandDevan]

underlying issue is we are unable to run prometheus on port 80 on a sever using systemd (the user will need to be root since this is a privileged port)

[slvr32]

underlying issue is we are unable to run prometheus on port 80 on a sever using systemd (the user will need to be root since this is a privileged port)

I should've also mentioned that alertmanager will start and listen on port 80 with --web-listen-address=0.0.0.0:80 added to prometheus::alertmanager::extra_options with either a privileged user override or with the default unprivileged alertmanager user and a similar setcap tweak as above for the alertmanager binary (I opted for the latter).

The alertmanager systemd unit template/file doesn't currently contain the same strict security options as the prometheus systemd unit file, so I didn't happen to notice if prometheus::alertmanager::manage_service: false effectively releases management of the alertmanager.service file or if it has issues similar to prometheus::manage_service: false