Re: systemd .service file conversion
On Thu, May 23, 2013 at 07:16:18AM +0200, Zbigniew J??drzejewski-Szmek wrote:
> Providing a conversion script which recreates all of systemd
> functionality would basically mean reimplemting a big part of
> systemd in shell. Providing an interpeter would man reimplementing
> a big part of systemd in whatever the interpreter is written in.
> Both options seem infeasible, unless only partial functionality is
> supported. [1] lists e.g. SystemCallFilter=, PrivateTmp=, PrivateNetwork=,
> CapabilityBoundingSet=, SecuritBits= which have security and
> correctness implications, and are IMHO pretty hard to recreate.
I partly disagree here. A good reason to reimplement part of systemd is
to have a portable subset of its functionality. This could be part of
the answer to the question of what to do about kfreebsd.
All the examples you give are Linux-specific, but at least
SystemCallFilter[1] and CapabilityBoundingSet[2] are not that hard to
reimplement, if you can change the process invoking the daemon (what
start-stop-daemon is being now). But those examples are also the ones
that I consider non-essential, because they are more of a hardening
aspect.
Also note that upstart has shown a similar integration to work and we
shipped it in wheezy. It is called /lib/init/upstart-job. You can link
that binary to /etc/init.d/$service to tell insserv that this service is
provided by an upstart job. Instead of reading LSB headers from the
wrapper, insserv will execute it with a lsb-headers parameter and read
the output. The other runtime component is startpar-upstart-inject,
which tells startpar about the completion of a job. As can be seen the
upstart people have already done the heavy lifting here.
Helmut
[1] http://outflux.net/teach-seccomp/
[2] libcap-dev or libcap-ng-dev
Reply to: