When deploying web applications on Ubuntu servers, we often encounter permission challenges with service management. Here's a typical scenario:

$ ssh mainuser@production
mainuser@production:~$ stop webapp
-bash: stop: command not found

The fundamental issue stems from Upstart's design - its control commands (start, stop, status) are typically only available to root users. This creates deployment headaches when automated processes need to restart services.

Instead of granting full sudo access, consider these targeted approaches:

1. Custom Init Script Wrapper

Create a dedicated script in /usr/local/bin/webapp-ctl:

#!/bin/bash
case "$1" in
    start|stop|restart|status)
        sudo /sbin/$1 webapp
        ;;
    *)
        echo "Usage: $0 {start|stop|restart|status}"
        exit 1
        ;;
esac

Then configure sudoers (visudo) to allow limited access:

mainuser ALL=(root) NOPASSWD: /sbin/start webapp, /sbin/stop webapp, /sbin/status webapp

2. Upstart's Built-in Alternative

Upstart actually provides a way to allow user control through its initctl command. First check if it's available:

which initctl

Then create a custom policy file at /etc/init/webapp.override:

author mainuser

3. Deployment Process Integration

For automated deployments, consider modifying your deployment script to use SSH with command restriction:

# In ~/.ssh/authorized_keys
command="/usr/local/bin/webapp-deploy-helper" ssh-rsa AAAAB3... mainuser@ci-server

With the helper script containing:

#!/bin/bash
case "$SSH_ORIGINAL_COMMAND" in
    "deploy")
        cd /home/mainuser/app && git pull && sudo /sbin/restart webapp
        ;;
    *)
        echo "Access denied"
        exit 1
        ;;
esac

When implementing any of these solutions:

• Always test in staging first
• Monitor /var/log/auth.log for unauthorized attempts
• Consider using pam_limits to further restrict resources
• Document the setup in your operations manual

For production-critical systems, you might want to implement additional safeguards like:

# In the upstart config
post-stop script
    if [ -f /tmp/maintenance.flag ]; then
        logger "Webapp stopped for maintenance"
    else
        logger "Webapp stopped unexpectedly"
        # Auto-restart or alert logic here
    fi
end script

---

When deploying applications via Upstart on Ubuntu systems, we often encounter permission hurdles when non-privileged users need to restart services. The standard approach of using sudo stop|start service_name breaks deployment automation flows when the executing user isn't a sudoer.

# Typical Upstart config (webapp.conf)
description "web application"
start on started mongodb
stop on runlevel [06]
respawn
respawn limit 10 100
env NODE_ENV=production
exec start-stop-daemon --start -c mainuser --exec /usr/bin/make -- -C /home/mainuser/app start-prod

The most secure approach involves modifying sudoers to grant specific command permissions:

# Add to /etc/sudoers via visudo
mainuser ALL=(root) NOPASSWD: /usr/sbin/service webapp start, /usr/sbin/service webapp stop

Now mainuser can execute:

sudo service webapp start
sudo service webapp stop

For environments where modifying sudoers isn't preferred, create executable wrappers in /usr/local/bin:

#!/bin/bash
# /usr/local/bin/webapp-control
case "$1" in
  start|stop|restart) sudo /usr/sbin/service webapp $1 ;;
  *) echo "Usage: $0 {start|stop|restart}"; exit 1 ;;
esac

Then set appropriate permissions:

sudo chown root:mainuser /usr/local/bin/webapp-control
sudo chmod 750 /usr/local/bin/webapp-control

For systems using PolicyKit (Ubuntu 16.04 and later), create a policy file:

// /etc/polkit-1/localauthority/50-local.d/webapp.pkla
[mainuser webapp permissions]
Identity=unix-user:mainuser
Action=org.freedesktop.systemd1.manage-units
ResultAny=yes
ResultInactive=yes
ResultActive=yes

After implementing any solution, verify with:

su - mainuser
webapp-control restart
# Or with sudoers approach:
sudo service webapp status

Remember to test deployment scripts in a staging environment before production rollout.

When granting service control permissions:

• Limit to specific services only
• Use NOPASSWD judiciously
• Prefer wrapper scripts over direct sudo access
• Regularly audit permissions