When automating deployments through remote scripts, requiring sudo privileges to control SupervisorD creates security and automation hurdles. Many DevOps engineers need to manage supervised processes without root access while maintaining system security.
Here are tested methods to achieve non-root SupervisorD control:
1. Configure User-Level SupervisorD
Install SupervisorD for the specific user account:
# Install locally for user pip install --user supervisor # Generate sample config echo_supervisord_conf > ~/supervisord.conf # Example minimal config [unix_http_server] file=/tmp/supervisor.sock ; path to socket file [supervisord] logfile=/tmp/supervisord.log pidfile=/tmp/supervisord.pid [rpcinterface:supervisor] supervisor.rpcinterface_factory = supervisor.rpcinterface:make_main_rpcinterface [supervisorctl] serverurl=unix:///tmp/supervisor.sock
2. Modify System-Wide Permissions
For existing system installations, adjust socket permissions:
# /etc/supervisor/supervisord.conf modification [unix_http_server] file=/var/run/supervisor.sock chmod=0770 chown=nobody:deployers # Your deployment group # Then run: sudo chgrp deployers /var/run/supervisor.sock sudo service supervisor restart
3. API-Based Control
Use Supervisor's XML-RPC interface with proper authentication:
import xmlrpc.client server = xmlrpc.client.ServerProxy('http://localhost:9001/RPC2') server.supervisor.stopProcess('myapp')
Configure HTTP authentication in supervisord.conf:
[inet_http_server] port = 127.0.0.1:9001 username = deployer password = yoursecurepassword
When implementing non-root control:
- Always restrict access to specific users/groups
- Never expose Supervisor API to public networks
- Use separate credentials for each environment
- Consider process isolation with containers if applicable
Verify non-root access works:
# As deployment user supervisorctl -c ~/supervisord.conf status # Should return process list without sudo
When automating deployments, we often encounter permission issues with process managers like Supervisord. The default installation typically requires root privileges to control the supervisor daemon, which creates security concerns and deployment complexities.
The most maintainable solution is to configure Supervisord's UNIX HTTP server to allow specific non-root users to send commands:
[unix_http_server] file=/var/run/supervisor.sock chmod=0770 chown=nobody:deployers # Group containing your deployment user
Here's how to set up the environment and test the configuration:
# Create dedicated group for supervisor control sudo groupadd deployers # Add deployment user to group sudo usermod -a -G deployers deployuser # Configure supervisor main config echo "[include] files = /etc/supervisor/conf.d/*.conf" | sudo tee /etc/supervisor/supervisord.conf # Set proper permissions sudo chown -R root:deployers /etc/supervisor sudo chmod -R 775 /etc/supervisor/ # Restart supervisor sudo service supervisor restart
For more granular control, you can enable the XML-RPC interface with authentication:
[inet_http_server] port = 127.0.0.1:9001 username = deployuser password = securepassword
Then control supervisor via curl:
curl --user deployuser:securepassword \ http://localhost:9001/RPC2 \ -d "" supervisor.stopProcess your_process_name false
Create a Python wrapper using supervisor's XML-RPC API:
from supervisor.xmlrpc import SupervisorTransport from xmlrpc.client import ServerProxy class SupervisorClient: def __init__(self, user, password): self.transport = SupervisorTransport(user, password, 'unix:///var/run/supervisor.sock') self.server = ServerProxy('http://localhost', transport=self.transport) def stop_process(self, name): return self.server.supervisor.stopProcess(name) # Usage client = SupervisorClient('deployuser', 'securepassword') client.stop_process('worker_process')
When implementing this solution:
- Never expose supervisor interface to public networks
- Use strong passwords for RPC authentication
- Consider IP whitelisting if using network interface
- Regularly audit supervisor access logs