Upstart helpers (abstract jobs and event aliases) for Oneiric

[Kees Cook]

Hi James,

On Tue, Jun 07, 2011 at 03:00:03PM +0100, James Hunt wrote:
> == Proposal 2: Provide Abstract Jobs for Common Services ==
> [...]
> ==== Option 1 ====
> [...]
> For example, each display manager package would be updated such that its
> .conf file specified:
> 
>   env    DISPLAY_MANAGER=y
>   export DISPLAY_MANAGER
> 
> Then, any job that requires a display manager could say:
> 
>   start on starting DISPLAY_MANAGER=y
> [...]
> ==== Option 2 ====
> Create a Job Configuration File that hard-codes the list of known
> service providers. For example for "display-manger", we could have:
> 
>   start on (starting gdm
>         or (starting kdm
>         or (starting lightdm
>         or (starting lxdm
>         or (starting slim
>         or (starting wdm
>         or  starting xdm))))))
> 
>   stop on (stopping gdm
>         or (stopping kdm
>         or (stopping lightdm
>         or (stopping lxdm
>         or (stopping slim
>         or (stopping wdm
>         or  stopping xdm))))))
> 
>   env    ABSTRACT_JOB=y
>   export ABSTRACT_JOB
> [...]
> 
> - We appear to have simply "moved the problem" since although we are no
>   longer hard-coding the list of display managers in "plymouth.conf", we
>   are hard-coding the list now in "display-manager.conf". However, we
>   have gained by doing this since:
> 
>   - We have still created the level of abstraction desired.
>   - We have contained the problem into a single file: we define the list
>     of display managers *once*.
>   - We don't need to update every Ubuntu (and potentially every Debian)
>     package as would be required for "Option 1".
>   - We *could* conceivably auto-generate "display-manager.conf" from the
>     archive with a simple script which munged the output of:
> 
>     apt-cache search x-display-manager|awk '{print $1}'|sort
> 
> - The "ABSTRACT_JOB" variable would allow other jobs to detect that a
>   job was abstract (they shouldn't need to care, but just in case...)
>   This also avoids the unwieldliness of "abstract-display-manager" (or
>   even "abstract/display-manager" (were we to put the abstract jobs in
>   /etc/init/abstract/ say).

What about merging the two options? I think it's a mistake to have
hardcoded lists; this is like having /etc/service.conf instead of
/etc/service.d/ for things to easily insert themselves into the system.

Imagine, instead:

   start on (starting DISPLAY_MANAGER=y
         or (starting gdm
         or (starting kdm
         or (starting lightdm
         or (starting lxdm
         or (starting slim
         or (starting wdm
         or  starting xdm)))))))

Then anything not in the hardcoded list can just define itself as a
DISPLAY_MANAGER to be included, and everything else can still start on the
abstract job names too.

-Kees

-- 
Kees Cook
Ubuntu Security Team