evolix/ansible-roles
22
2
Fork 2
Code Issues 61 Pull requests 18 Releases 32 Wiki Activity

nginx: Do not use spawn-fcgi for munin-graph #139

Open
mtrossevin wants to merge 1 commit from mtrossevin/ansible-roles:nginx-munin-no-spawn-fcgi into unstable
pull from: mtrossevin/ansible-roles:nginx-munin-no-spawn-fcgi
merge into: evolix:unstable
Conversation 1 Commits 1 Files changed 5 +36 -13
mtrossevin commented 2021-11-17 13:46:48 +01:00
Owner
Copy link

systemd provides already provides all the fonctionnalities of spawn-fcgi
with the exception of the possibility to spawn multiple process to a
single socket (it can be done using multiwatch though). So we might as
well use the fonctions provided by systemd instead of needing to install
a new package and add a layer of indirection in how the fastcgi service
is managed.

This make for a somewhat simpler service that can be started as an
unprivileged user.

systemd provides already provides all the fonctionnalities of spawn-fcgi with the exception of the possibility to spawn multiple process to a single socket (it can be done using multiwatch though). So we might as well use the fonctions provided by systemd instead of needing to install a new package and add a layer of indirection in how the fastcgi service is managed. This make for a somewhat simpler service that can be started as an unprivileged user.
mtrossevin reviewed 2021-11-17 13:50:10 +01:00
nginx/tasks/munin_vhost.yml Outdated
@ -36,3 +41,3 @@
- name: Systemd unit for Munin-fcgi is started
systemd:
name: spawn-fcgi-munin-graph
name: fcgi-munin-graph.socket
mtrossevin commented 2021-11-17 13:50:10 +01:00
Author
Owner
Copy link

Enabling only the socket mean that the service will be started on the first connexion on said socket instead of being started on boot. That increase the latency for the very first connexion (+ the first after a crash of the service) in exchange of not blocking boot until the service is started.

Enabling only the socket mean that the service will be started on the first connexion on said socket instead of being started on boot. That increase the latency for the very first connexion (+ the first after a crash of the service) in exchange of not blocking boot until the service is started.
mtrossevin force-pushed nginx-munin-no-spawn-fcgi from 0b3a7cbc8f to 93084d6ce8 2021-11-17 13:52:33 +01:00 Compare
mtrossevin reviewed 2021-11-17 13:53:15 +01:00
mtrossevin reviewed 2021-11-17 13:54:51 +01:00
nginx/files/systemd/fcgi-munin-graph.service
@ -0,0 +12,4 @@
StandardError=journal
[Install]
WantedBy=multi-user.target
mtrossevin commented 2021-11-17 13:54:51 +01:00
Author
Owner
Copy link

This allow the service to be started on boot instead of waiting for the first connexion on the socket if wanted.

This allow the service to be started on boot instead of waiting for the first connexion on the socket if wanted.
mtrossevin changed title from nginx: Do not use spawn-fcgi for munin-graph to WIP: nginx: Do not use spawn-fcgi for munin-graph 2021-11-17 13:56:15 +01:00
mtrossevin changed title from WIP: nginx: Do not use spawn-fcgi for munin-graph to nginx: Do not use spawn-fcgi for munin-graph 2021-11-17 13:56:24 +01:00
mtrossevin requested review from jlecour 2021-11-17 13:56:33 +01:00
mtrossevin commented 2021-11-22 09:53:22 +01:00
Author
Owner
Copy link

I temporarily enabled this change on selks-dev (units in /run/systemd/system instead of /etc and spawn-fcgi-munin-graph stopped but not disabled so it will completely rollback with a reboot).

That seems to work without any problem.

In fact it works without any problem with this exact service unit:

# /run/systemd/system/fcgi-munin-graph.service
[Unit]
Description=Munin zoom for nginx.
After=network.target
Requires=fcgi-munin-graph.socket

[Service]
User=munin
Group=munin
ExecStart=/usr/lib/munin/cgi/munin-cgi-graph
StandardInput=socket
StandardOutput=null
StandardError=journal

# /var/log/munin and /var/lib/munin need to be RW for the service to work
ReadWritePaths=-/var/log/munin
ReadWritePaths=-/var/lib/munin
# Not certain if it really need to be RW but since it appears in the logs I put it there anyway
ReadWritePaths=-/var/cache/munin/

# Sandboxing options
# Full system RO except /dev, /proc, /sys and /home
ProtectSystem=strict
PrivateTmp=yes
# Minimal set of device visible
PrivateDevices=yes
# No need of network connectivity
PrivateNetwork=yes
# No need to see other users
PrivateUsers=yes
# No need to see /home, if it does need to see it, put `read-only` instead, if it need to be able to write on it put `no`
ProtectHome=yes
# /proc/sys/, /sys/ and /proc/sysrq-trigger RO
ProtectKernelTunables=yes
# /sys/fs/cgroup/ RO
ProtectControlGroups=yes
NoNewPrivileges=yes
RestrictAddressFamilies=AF_UNIX
# No access to namespacing for the service
RestrictNamespaces=yes
# Cannot load new modules
ProtectKernelModules=yes
MemoryDenyWriteExecute=yes
RestrictRealtime=yes

# This service doesn't need any capability with the current user
CapabilityBoundingSet=

# Don't allow these syscall (give an EPERM if they are called), they shouldn't be used by this service anyway.
SystemCallFilter=~@clock @debug @module @mount @raw-io @reboot @swap @privileged @resources @cpu-emulation @obsolete
SystemCallErrorNumber=EPERM
# Needed by RestrictAddressFamilies= and SystemCallFilter
SystemCallArchitectures=native

[Install]
WantedBy=multi-user.target

(mostly checked the sandboxing options to know what exactly it need access to in order to works normally)

I temporarily enabled this change on selks-dev (units in /run/systemd/system instead of /etc and spawn-fcgi-munin-graph stopped but not disabled so it will completely rollback with a reboot). That seems to work without any problem. In fact it works without any problem with this exact service unit: ```.ini # /run/systemd/system/fcgi-munin-graph.service [Unit] Description=Munin zoom for nginx. After=network.target Requires=fcgi-munin-graph.socket [Service] User=munin Group=munin ExecStart=/usr/lib/munin/cgi/munin-cgi-graph StandardInput=socket StandardOutput=null StandardError=journal # /var/log/munin and /var/lib/munin need to be RW for the service to work ReadWritePaths=-/var/log/munin ReadWritePaths=-/var/lib/munin # Not certain if it really need to be RW but since it appears in the logs I put it there anyway ReadWritePaths=-/var/cache/munin/ # Sandboxing options # Full system RO except /dev, /proc, /sys and /home ProtectSystem=strict PrivateTmp=yes # Minimal set of device visible PrivateDevices=yes # No need of network connectivity PrivateNetwork=yes # No need to see other users PrivateUsers=yes # No need to see /home, if it does need to see it, put `read-only` instead, if it need to be able to write on it put `no` ProtectHome=yes # /proc/sys/, /sys/ and /proc/sysrq-trigger RO ProtectKernelTunables=yes # /sys/fs/cgroup/ RO ProtectControlGroups=yes NoNewPrivileges=yes RestrictAddressFamilies=AF_UNIX # No access to namespacing for the service RestrictNamespaces=yes # Cannot load new modules ProtectKernelModules=yes MemoryDenyWriteExecute=yes RestrictRealtime=yes # This service doesn't need any capability with the current user CapabilityBoundingSet= # Don't allow these syscall (give an EPERM if they are called), they shouldn't be used by this service anyway. SystemCallFilter=~@clock @debug @module @mount @raw-io @reboot @swap @privileged @resources @cpu-emulation @obsolete SystemCallErrorNumber=EPERM # Needed by RestrictAddressFamilies= and SystemCallFilter SystemCallArchitectures=native [Install] WantedBy=multi-user.target ``` (mostly checked the sandboxing options to know what exactly it need access to in order to works normally)
jlecour reviewed 2022-06-06 18:22:45 +02:00
nginx/tasks/munin_vhost.yml
@ -35,2 +38,4 @@
src: systemd/fcgi-munin-graph.service
dest: /etc/systemd/system/fcgi-munin-graph.service
- name: Systemd unit for Munin-fcgi is started
jlecour commented 2022-06-06 18:22:45 +02:00
Owner
Copy link

I guess we should change the name to Systemd socket for Munin-fcgi is installed to mention the socket instead of the service.

I guess we should change the name to `Systemd socket for Munin-fcgi is installed` to mention the socket instead of the service.
Some checks failed
continuous-integration/drone/pr Build is failing
Details
This pull request has changes conflicting with the target branch.
  • CHANGELOG.md
  • nginx/tasks/munin_vhost.yml
View command line instructions.

Checkout

From your project repository, check out a new branch and test the changes.
git fetch -u nginx-munin-no-spawn-fcgi:mtrossevin-nginx-munin-no-spawn-fcgi
git checkout mtrossevin-nginx-munin-no-spawn-fcgi

Merge

Merge the changes and update on Forgejo.
git checkout unstable
git merge --no-ff mtrossevin-nginx-munin-no-spawn-fcgi
git checkout unstable
git merge --ff-only mtrossevin-nginx-munin-no-spawn-fcgi
git checkout mtrossevin-nginx-munin-no-spawn-fcgi
git rebase unstable
git checkout unstable
git merge --no-ff mtrossevin-nginx-munin-no-spawn-fcgi
git checkout unstable
git merge --squash mtrossevin-nginx-munin-no-spawn-fcgi
git checkout unstable
git merge --ff-only mtrossevin-nginx-munin-no-spawn-fcgi
git checkout unstable
git merge mtrossevin-nginx-munin-no-spawn-fcgi
git push origin unstable
Sign in to join this conversation.
Reviewers
No reviewers
jlecour
Labels
Clear labels   
bug

Something is not working

  
duplicate

This issue or pull request already exists

  
enhancement

New feature

  
help wanted

Need some help

  
invalid

Something is wrong

  
question

More information is needed

  
security

Concern a security issue

  
wontfix

This won't be fixed

No labels
bug
duplicate
enhancement
help wanted
invalid
question
security
wontfix
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
2 participants
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference: evolix/ansible-roles#139
No description provided.
Delete branch "mtrossevin/ansible-roles:nginx-munin-no-spawn-fcgi"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?