Re: systemd service and /etc/default/
On Sun, Aug 17, 2014 at 01:13:36PM +0200, Marc Haber wrote:
> On Sun, 17 Aug 2014 01:40:27 -0700, Josh Triplett
> <josh@joshtriplett.org> wrote:
> >Ludovico Cavedon wrote:
> >> I am writing a systemd service file for a daemon (ntopng) and I would
> >> like to know what you think is the best way to load some
> >> configuration.
> >>
> >> The ntopng daemon takes multiple interfaces in the format of multiple
> >> -i command-line options. For example.
> >> ntopng -i eth0 -i wlan0
> >>
> >> Currently the interfaces are stored in /etc/default/ntopng
> >> INTERFACES="eth0 wlan0"
> >>
> >> and the sysv init script takes care of adding "-i" for each one of them.
> >>
> >> I would like to keep the sysv compatibility and do the same in systemd.
> >>
> >> I tried in various ways, but the two solution I could think of are:
> >> 1) change the format of INTERFACES to require inclusion of -i.
> >> I.e
> >> INTERFACES="-i eth0 -i wlan0"
> >> and use EnvironmentFIle=/etc/default/ntopng. This changes the format,
> >> complicated upgrades, and is more error prone.
> >> 2) instead of doing Exec=ntopng, Exec a script that does the mangling
> >> and then execs ntopng.
> >>
> >> Because both solutions do not look great to me, and I could not find
> >> an example, I am asking your opinion.
> >>
> >> After writing this email, I start to believe 2) is the right way, but
> >> I would appreciate anybody's input.
> >
> >3) Teach ntopng to understand /etc/ntopng.conf natively and migrate the
> >settings there.
> >4) Teach ntopng to automatically detect the available network devices on
> >the system (including new ones that show up dynamically) and
> >automatically handle all of them unless configured to do otherwise,
> >making configuration usually unnecessary.
> Please. The attitute of requiring Debian maintainers to modify
> upstream software instead of having simple two-line extension to an
> init script is really unfriendly. Why do only systemd friends keep
> recommending this?
Once upon time, every distribution carried scripts to autodetect and
build a XF86Config for end users. Every distribution duplicated the
effort for their own scripts, each had different bugs and limitations.
Some even made a selling point of having better autodetection than
other distributions.
Then upstream added autodection.. ..and pretty much all that duplicated
work became wasted.
Making upstream software better is for the benefit of all users. Making
debian specific scripts (and patches) are only the benefit of debian users.
Doing a few lines in initscript/postinst saves the Debian maintainer time,
but only in the short term - If the upstream changes cli options,
configuration files etc - the debian maintainer will have to spend
time adapting. Worse, the maintainer may have to write new scripts to
migrate setting from old format to new. The more scripts you wrap around
the upstream codebase, the maintaince burden you have in future.
This is the position where the ntop maintainer has found himself in
(except it is not upstream, but another tool that has changed).
Riku
Reply to: