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 j...@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 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140818104413.ga15...@afflict.kos.to
Re: systemd service and /etc/default/
On 08/18/2014 01:36 AM, Russ Allbery wrote: The upstream source *can* be changed and improved for everyone. Truth, but not always practical. If I was going to fix all the defects of software I package, I don't think I'd have enough time to sleep even one hour per night. Thomas Goirand (zigo) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/53f212fe.9080...@debian.org
Re: systemd service and /etc/default/
Thomas Goirand z...@debian.org writes: On 08/18/2014 01:36 AM, Russ Allbery wrote: The upstream source *can* be changed and improved for everyone. Truth, but not always practical. If I was going to fix all the defects of software I package, I don't think I'd have enough time to sleep even one hour per night. I don't think anyone is advocating that it's always practical. In fact, I believe I implied that it wasn't always practical in the part of the message you were replying to that you deleted. :) More generally (and this part is not pointed at Thomas), I realize it's become de rigueur in any thread about systemd to reply to hm, you could consider getting a dog with WHY DO YOU WANT TO KILL MY KITTENS?!?!?, but seriously folks, could we tone down the assumption that people with differing preferences want to break everything you do? It's just a few additional options. If you don't think they're good options, don't follow them! It doesn't have to turn into a huge argument. People make suggestions to me all the time that I don't follow, for reasons of time, simple disagreement, or because I'm still thinking about the problem. Everyone understands this. It's not a big deal unless we go out of our way to make it one. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/87k365zrme@hope.eyrie.org
Re: systemd service and /etc/default/
On Sun, 17 Aug 2014, Marc Haber wrote: 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? Using my sysvinit hat, I've always recommended people to actually fix daemons so that they detach properly from stdin/stdout/stderr, do a proper setsid(), implement proper pidfile support... I don't see much difference, there ;-) -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140818173947.gc27...@khazad-dum.debian.net
Re: systemd service and /etc/default/
On Mon, Aug 18, 2014 at 09:31:37AM -0700, Russ Allbery wrote: More generally (and this part is not pointed at Thomas), I realize it's become de rigueur in any thread about systemd to reply to hm, you could consider getting a dog with WHY DO YOU WANT TO KILL MY KITTENS?!?!?, but seriously folks, could we tone down the assumption that people with differing preferences want to break everything you do? It's just a few additional options. If you don't think they're good options, don't follow them! It doesn't have to turn into a huge argument. People make suggestions to me all the time that I don't follow, for reasons of time, simple disagreement, or because I'm still thinking about the problem. Everyone understands this. It's not a big deal unless we go out of our way to make it one. Hear, hear! +1. Give the man a medal! -- http://www.cafepress.com/trunktees -- geeky funny T-shirts http://gtdfh.branchable.com/ -- GTD for hackers -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140818183548.go7...@exolobe1.liw.fi
Re: systemd service and /etc/default/
On Mon, 18 Aug 2014 09:31:37 -0700, Russ Allbery r...@debian.org wrote: could we tone down the assumption that people with differing preferences want to break everything you do? It's just a few additional options. And others removed. Or do you actually claims that the systemd migration didn't actually break things? Not all of them, but a noticeable number. Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber |Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom | http://www.zugschlus.de/ Nordisch by Nature | Lt. Worf, TNG Rightful Heir | Fon: *49 621 72739834 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/e1xjt9v-0005ih...@swivel.zugschlus.de
Re: systemd service and /etc/default/
Marc Haber mh+debian-de...@zugschlus.de (2014-08-18): And others removed. Or do you actually claims that the systemd migration didn't actually break things? Not all of them, but a noticeable number. (I don't think Russ claimed anything along those lines, no.) Anyway: things get broken, bugs get reported, bugs get fixed, things get usable again; sometimes they get even better than they were. But look, that's the whole point of having an unstable distribution, and a staging area to get the next stable prepared: we can iterate until stuff gets into shape. I'm not sure I see a problem here, except for the temporary inconvenience in unstable which sometimes also affects testing. Happy unstable/testing users are expected to handle such an issue though. :) Mraw, KiBi. signature.asc Description: Digital signature
Re: systemd service and /etc/default/
Marc Haber wrote: On Sun, 17 Aug 2014 23:14:33 -0500, Josh Triplett j...@joshtriplett.org wrote: Why a requirement to not improve upstream? Ideally, the Debian patches for a piece of software should trend to zero over time, as fixes make their way upstream. Imagine an upstream author having the cooperation level of the systemd team. Highly cooperative, responsive, understanding of distribution issues, and willing to work with multiple distributions to come up with a good cross-distro solution that works everywhere? This will put the Debian maintainer between a rock and a hard place. When dealing with an upstream that *isn't* cooperative or helpful, sure, you might end up effectively creating a downstream fork. It's unfortunate when that happens in the Debian packages rather than in a separate repository that then gets packaged, but *shrug*. However, the original mail that started this thread didn't suggest that the upstream in this case was uncooperative or unreceptive to patches. - Josh Triplett -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140819044821.GA1345@thin
Re: systemd service and /etc/default/
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. - Josh Triplett -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140817084024.GA28990@thin
Re: systemd service and /etc/default/
On 08/17/2014 11:51 AM, Ludovico Cavedon wrote: Hi, 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. Thanks, Ludovico Hi, I had the same problem as you describe above, even a bit more complicated because, in what we did, /etc/default/file sometimes doesn't exist (it's not mandatory in what we did). We finally ended-up using a wrapper script, and I'm not satisfied by the current implementation (which re-use the sysv-rc forking script, which is IMO ugly). Folks from the systemd list have been helpful and provided advices, but it doesn't address the problem in the way I wished. 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. - Josh Triplett How about teaching systemd that script is sometimes necessary? It's annoying to write a wrapper, because then, it does a fork to start the daemon, so the PID changes. Has this been reported upstream? If yes, what's upstream opinion about it? I think this would be a really good improvement to systemd. Cheers, Thomas Goirand (zigo) P.S: This is *not* the start of a troll thread, please stay on-topic, and discuss *only* the technical issue about using default file in .service files, otherwise go open a *new* yet-another-systemd-troll-thread. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/53f07808.90...@debian.org
Re: systemd service and /etc/default/
Am 17.08.2014 11:38, schrieb Thomas Goirand: How about teaching systemd that script is sometimes necessary? It's annoying to write a wrapper, because then, it does a fork to start the daemon, so the PID changes. Has this been reported upstream? If yes, what's upstream opinion about it? I don't get your point. You can start a wrapper script and as a last step use exec $mydaemon That just works. If not, can you elaborate what your problem is? But yeah, such wrapper scripts should be avoided if possible and native mechanisms used. -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Re: systemd service and /etc/default/
Am 17.08.2014 05:51, schrieb Ludovico Cavedon: Hi, 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. 2) instead of doing Exec=ntopng, Exec a script that does the mangling and then execs ntopng. This changes the format, complicated upgrades, and is more error prone. 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. If you go with any of these options, I think 1) would be the better approach since this would be a one-time migration. I see that you also have a HTTP_PORT=3000 parameter in /etc/default/ntopng and a ADD_ARGS= I'd rewrite your default file and simply pass the -w and -i parameters directly via ADD_ARGS=. Doing that as part of the postinst doesn't seem that complicated or error prone. I also happen to notice, that you use a ENABLED=1 flag. It would be a good idea to deprecate that as well and remove that. We have better mechanisms nowadays to enable/disable SysV init scripts (and systemd service files). -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Re: systemd service and /etc/default/
On Sun, 17 Aug 2014 01:40:27 -0700, Josh Triplett j...@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? Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber |Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom | http://www.zugschlus.de/ Nordisch by Nature | Lt. Worf, TNG Rightful Heir | Fon: *49 621 72739834 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/e1xiyp2-0002mu...@swivel.zugschlus.de
Re: systemd service and /etc/default/
On Sun, 17 Aug 2014 12:05:13 +0200, Michael Biebl bi...@debian.org wrote: But yeah, such wrapper scripts should be avoided if possible and native mechanisms used. Having read quite of system docs in the last weeks to find a way to key /etc/crypttab keyscript functionality back, I have found that using the native mechanism in systemd lingo usually means modify the upstream software, usually to do things that used to be done by a handful of additional lines in an init script previously. Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber |Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom | http://www.zugschlus.de/ Nordisch by Nature | Lt. Worf, TNG Rightful Heir | Fon: *49 621 72739834 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/e1xiyrb-0002mk...@swivel.zugschlus.de
Re: systemd service and /etc/default/
On 17/08/14 10:38, Thomas Goirand wrote: I had the same problem as you describe above, even a bit more complicated because, in what we did, /etc/default/file sometimes doesn't exist (it's not mandatory in what we did). EnvironmentFile takes precedence over Environment, and EnvironmentFile starting with - means do not fail if it is missing (syntax inspired by -include more-rules.mk in GNU make, I think), so you can do something like: Environment=FOO_VERBOSE=-v # yes this is really the syntax if it contains spaces, see the man page Environment=FOO_PLUGINS=foo bar misc other # override FOO_VERBOSE, FOO_PLUGINS if present EnvironmentFile=-/etc/default/foo Exec=/usr/lib/foo/foo-daemon $FOO_VERBOSE Regards, S -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/53f08f54.6010...@debian.org
Re: systemd service and /etc/default/
On Sun, 17 Aug 2014 12:17:21 +0200, Michael Biebl bi...@debian.org wrote: I also happen to notice, that you use a ENABLED=1 flag. It would be a good idea to deprecate that as well and remove that. We have better mechanisms nowadays to enable/disable SysV init scripts (and systemd service files). In my packages, I have usually not bothered with an ENABLED flag in /etc/default for a number of years, but I have not removed any ENABLED flags to keep backwards compatibility. Does Debian no longer care about easy updates, or have we accepted that updating to jessie will be a nightmare anyway and recommend reinstallation instead? Quite a number of packages also refrain from starting the daemon on an unconfigured newly installed package until the user has configured it. I guess that this needs to be replaced by native mechanisms (i.e. implemented as a patch to the upstream software) as well? It is not always possible to come with a working default configuration or to build one in postinst. Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber |Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom | http://www.zugschlus.de/ Nordisch by Nature | Lt. Worf, TNG Rightful Heir | Fon: *49 621 72739834 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/e1xiyvu-0002nm...@swivel.zugschlus.de
Re: systemd service and /etc/default/
On Aug 17, Ludovico Cavedon cave...@debian.org wrote: 2) instead of doing Exec=ntopng, Exec a script that does the mangling and then execs ntopng. If you cannot improve the software enough then this is the best choice. -- ciao, Marco signature.asc Description: Digital signature
Re: systemd service and /etc/default/
On Aug 17, Marc Haber mh+debian-de...@zugschlus.de wrote: Does Debian no longer care about easy updates, or have we accepted that updating to jessie will be a nightmare anyway and recommend reinstallation instead? Yes, I hate users and I want them to suffer. Quite a number of packages also refrain from starting the daemon on an unconfigured newly installed package until the user has configured it. We call these packages buggy: every package should have a sensible default configuration. I guess that this needs to be replaced by native mechanisms (i.e. implemented as a patch to the upstream software) as well? It is not always possible to come with a working default configuration or to build one in postinst. If unconfigured software really cannot fail cleanly then the package can install it without enabling the service. Or systemd can notice that there is no config file and hence not try to start the daemon. Or possibly other things more intelligent than checking for ENABLED=1 in something that may or may not be a shell script fragment. -- ciao, Marco signature.asc Description: Digital signature
Re: systemd service and /etc/default/
On Aug 17, Marc Haber mh+debian-de...@zugschlus.de wrote: 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? Maybe because the others do not care enough about improving software quality. -- ciao, Marco signature.asc Description: Digital signature
Re: systemd service and /etc/default/
Marc Haber mh+debian-de...@zugschlus.de writes: Quite a number of packages also refrain from starting the daemon on an unconfigured newly installed package until the user has configured it. I guess that this needs to be replaced by native mechanisms (i.e. implemented as a patch to the upstream software) as well? It is not always possible to come with a working default configuration or to build one in postinst. Then don't enable the service by default and leave it to the administrator to enable it via systemctl enable foo or update-rc.d foo enable. Ansgar -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/87wqa7tjx3@deep-thought.43-1.org
Re: systemd service and /etc/default/
Hi, 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? It seems the upstream package lacks basic means of configuration (like, parsing a list of interface identifiers) and is not able to cope with network interfaces that come or go at run-time. Of course every distribution can re-create their own (and probably differing) solutions to this problem - but fixing the issue upstream should really be preferred. Kind regards Ralf -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/53f09739.9000...@ralfj.de
Re: systemd service and /etc/default/
On 17/08/14 12:48, Marco d'Itri wrote: On Aug 17, Marc Haber mh+debian-de...@zugschlus.de wrote: It is not always possible to come with a working default configuration or to build one in postinst. If unconfigured software really cannot fail cleanly then the package can install it without enabling the service. Or systemd can notice that there is no config file and hence not try to start the daemon. FYI: systemd: [Unit] ConditionPathExists=/etc/foo.conf or sysvinit: if ! [ -e /etc/foo.conf ] then echo -n (not starting, you need to create /etc/foo.conf) return 0 fi This seems better than the ENABLED=1 anti-pattern: start the service if and only if it has been configured. S -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/53f09ca3.8080...@debian.org
Re: systemd service and /etc/default/
On Sun, 17 Aug 2014 13:48:44 +0200, m...@linux.it (Marco d'Itri) wrote: On Aug 17, Marc Haber mh+debian-de...@zugschlus.de wrote: Does Debian no longer care about easy updates, or have we accepted that updating to jessie will be a nightmare anyway and recommend reinstallation instead? Yes, I hate users and I want them to suffer. That explains big parts of your behavior. No, no smiley. I am dead serious. Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber |Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom | http://www.zugschlus.de/ Nordisch by Nature | Lt. Worf, TNG Rightful Heir | Fon: *49 621 72739834 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/e1xj2ft-0004t8...@swivel.zugschlus.de
Re: systemd service and /etc/default/
On Sun, 17 Aug 2014 13:14:27 +0100, Simon McVittie s...@debian.org if ! [ -e /etc/foo.conf ] then echo -n (not starting, you need to create /etc/foo.conf) return 0 fi if ! grep '^important-option' foo.conf; looks like a rather common idiom. Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber |Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom | http://www.zugschlus.de/ Nordisch by Nature | Lt. Worf, TNG Rightful Heir | Fon: *49 621 72739834 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/e1xj2gg-0004tn...@swivel.zugschlus.de
Re: systemd service and /etc/default/
Marco wrote: On Aug 17, Marc Haber mh+debian-de...@zugschlus.de wrote: 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? Maybe because the others do not care enough about improving software quality. Marco, *You* may think your retorts like this are clever, but they're really not helpful. Instead, they make you look like a dick. Please stop. -- Steve McIntyre, Cambridge, UK.st...@einval.com You raise the blade, you make the change... You re-arrange me 'til I'm sane... -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/e1xj2px-0003em...@mail.einval.com
Re: systemd service and /etc/default/
Marc Haber mh+debian-de...@zugschlus.de writes: Josh Triplett j...@joshtriplett.org wrote: 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? No one is *requiring* anything. I'm not sure where you got that impression. As you can see from the numbering, Josh just presented a couple of additional options. It's good to be aware of the option to improve the upstream source so that packaging it is easier and so that it works better for everyone with less configuration. I find that it's easy, when packaging software for Debian, to fall into the mindset that I'm only doing packaging and that the upstream source is what it is and can't be changed. But, of course, the whole reason why we work on open source software is that this is not true. The upstream source *can* be changed and improved for everyone. Obviously, that's more work! And it isn't always appropriate. But it's worth remembering that it's an option. In this particular case, dynamically discovering the network interfaces by default (while still allowing the list of interfaces to be overridden from the command line) gets the software closer to working with zero configuration on *all* platforms, and we know that our users much prefer zero configuration setups (as long as there's still an option to override for local needs). So while more work that option makes the software better for everyone in the long run. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/87fvgvxbl5@hope.eyrie.org
Re: systemd service and /etc/default/
On Sun, 17 Aug 2014 10:36:22 -0700, Russ Allbery r...@debian.org wrote: It's good to be aware of the option to improve the upstream source so that packaging it is easier and so that it works better for everyone with less configuration. I find packaging easier when I work around a limitation in the upstream software by dropping a handful of lines in a shell script instead of letting the upstream software grow additional command line options, probably extensive changes in the code with the potential of introducing more vulnerability _and_ making work harder for the security team. I find that it's easy, when packaging software for Debian, to fall into the mindset that I'm only doing packaging and that the upstream source is what it is and can't be changed. But, of course, the whole reason why we work on open source software is that this is not true. The upstream source *can* be changed and improved for everyone. I usually refrain from changing upstream source when I can work around a limitation in _my_ code. Of course, I file bug/wishlist reports upstream and in many cases the workaround could be removed from the package in a later release. In this particular case, dynamically discovering the network interfaces by default (while still allowing the list of interfaces to be overridden from the command line) gets the software closer to working with zero configuration on *all* platforms, and we know that our users much prefer zero configuration setups (as long as there's still an option to override for local needs). So while more work that option makes the software better for everyone in the long run. Changes of this order of magnitude is way beyond my capabilities, both regarding time and skill. Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber |Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom | http://www.zugschlus.de/ Nordisch by Nature | Lt. Worf, TNG Rightful Heir | Fon: *49 621 72739834 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/e1xj5dw-0005gk...@swivel.zugschlus.de
Re: systemd service and /etc/default/
On Sun, Aug 17, 2014 at 01:44:15PM +0200, Marco d'Itri wrote: On Aug 17, Marc Haber mh+debian-de...@zugschlus.de wrote: 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? Maybe because the others do not care enough about improving software quality. Contrary to the views of the systemd authors, software quality is not some abstract ideal that exists in a vacuum. Software's quality is judged by how well it meets the needs of users, which absolutely includes the requirement that it *work smoothly across upgrades*. It's one thing to discourage the use of /etc/default files, which I agree are a lousy convention that should be deprecated. It's quite another to completely drop admins' settings on the floor on upgrade, or to regard the upgrade issues as somebody else's problem (more specifically, downstreams'). -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Re: systemd service and /etc/default/
Josh, On Sun, Aug 17, 2014 at 1:40 AM, Josh Triplett j...@joshtriplett.org wrote: 3) Teach ntopng to understand /etc/ntopng.conf natively and migrate the settings there. yes, that would be an option. I forgot to add the requirement without patching upstream code :) 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. ntopng already does this (except the dynamically part). However -i do not take only network interfaces, but zeromq sockets too. Thanks, Ludovico -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/CAEK95GFfWNNTSSQEGAQosgAt8nzJyg3YHL51m=yz_orcwd6...@mail.gmail.com
Re: systemd service and /etc/default/
On Sun, Aug 17, 2014 at 4:20 AM, Marc Haber mh+debian-de...@zugschlus.de wrote: On Sun, 17 Aug 2014 12:17:21 +0200, Michael Biebl bi...@debian.org wrote: I also happen to notice, that you use a ENABLED=1 flag. It would be a good idea to deprecate that as well and remove that. We have better mechanisms nowadays to enable/disable SysV init scripts (and systemd service files). In my packages, I have usually not bothered with an ENABLED flag in /etc/default for a number of years, but I have not removed any ENABLED flags to keep backwards compatibility. Yes, adding the ENABLED was a bad idea. I was debating whether to drop it and a notice in the NEWS.Debian, or try to transition to the new mechanisms. However, give that the package entered Debian for the first time one month ago, I am planning on the first option. Thanks, Ludovico -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/CAEK95GFDDV3B_TE3yo000qBQWvHbBW-=kw9p113-5bmyhxo...@mail.gmail.com
Re: systemd service and /etc/default/
On Sun, Aug 17, 2014 at 08:48:40PM -0700, Ludovico Cavedon wrote: On Sun, Aug 17, 2014 at 1:40 AM, Josh Triplett j...@joshtriplett.org wrote: 3) Teach ntopng to understand /etc/ntopng.conf natively and migrate the settings there. yes, that would be an option. I forgot to add the requirement without patching upstream code :) Debian is not the only distribution that will ever encounter this problem. Rather than hacking around it downstream, why not fix it the right way upstream? /etc/default almost always represents a Debian-specific hack. Why a requirement to not improve upstream? Ideally, the Debian patches for a piece of software should trend to zero over time, as fixes make their way upstream. (Though, as noted above, and migrate the settings. :) ) 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. ntopng already does this (except the dynamically part). However -i do not take only network interfaces, but zeromq sockets too. Fair enough. Still seems likely to help it work without configuration for common use cases, though. - Josh Triplett -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140818041430.GA1686@thin
Re: systemd service and /etc/default/
On Sun, Aug 17, 2014 at 9:14 PM, Josh Triplett j...@joshtriplett.org wrote: On Sun, Aug 17, 2014 at 08:48:40PM -0700, Ludovico Cavedon wrote: On Sun, Aug 17, 2014 at 1:40 AM, Josh Triplett j...@joshtriplett.org wrote: 3) Teach ntopng to understand /etc/ntopng.conf natively and migrate the settings there. yes, that would be an option. I forgot to add the requirement without patching upstream code :) Debian is not the only distribution that will ever encounter this problem. Rather than hacking around it downstream, why not fix it the right way upstream? /etc/default almost always represents a Debian-specific hack. Well, I do not see this as an upstream bug that needs to be fixed. If no interface is given, ntopng will autodetect the network interfaces. If you want to use a different set, you pass them to it on the command line. I agree it could be improved by adding support for a separate configuration file, but upstream does not have any incentive right now in doing it, and I do not have the time/interest in working in a possible large patch to add support for new config file to ntopng. Thanks, Ludovico -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/CAEK95GGUJNif+vTA1uyauYUp=+nisvgtueoupbhffxgju0a...@mail.gmail.com
Re: systemd service and /etc/default/
On Sun, Aug 17, 2014 at 09:24:33PM -0700, Ludovico Cavedon wrote: On Sun, Aug 17, 2014 at 9:14 PM, Josh Triplett j...@joshtriplett.org wrote: On Sun, Aug 17, 2014 at 08:48:40PM -0700, Ludovico Cavedon wrote: On Sun, Aug 17, 2014 at 1:40 AM, Josh Triplett j...@joshtriplett.org wrote: 3) Teach ntopng to understand /etc/ntopng.conf natively and migrate the settings there. yes, that would be an option. I forgot to add the requirement without patching upstream code :) Debian is not the only distribution that will ever encounter this problem. Rather than hacking around it downstream, why not fix it the right way upstream? /etc/default almost always represents a Debian-specific hack. Well, I do not see this as an upstream bug that needs to be fixed. If no interface is given, ntopng will autodetect the network interfaces. If you want to use a different set, you pass them to it on the command line. I agree it could be improved by adding support for a separate configuration file, but upstream does not have any incentive right now in doing it, and I do not have the time/interest in working in a possible large patch to add support for new config file to ntopng. Then, for now, I'd suggest migrating the settings in /etc/default/ntopng to have a -i in front of each interface, and referencing that from the .service file via EnvironmentFile=-/etc/default/ntopng . - Josh Triplett -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140818043700.GA1964@thin
Re: systemd service and /etc/default/
On Sun, 17 Aug 2014 23:14:33 -0500, Josh Triplett j...@joshtriplett.org wrote: Why a requirement to not improve upstream? Ideally, the Debian patches for a piece of software should trend to zero over time, as fixes make their way upstream. Imagine an upstream author having the cooperation level of the systemd team. This will put the Debian maintainer between a rock and a hard place. (Though, as noted above, and migrate the settings. :) ) Additional work for the Debian maintainer. Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber |Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom | http://www.zugschlus.de/ Nordisch by Nature | Lt. Worf, TNG Rightful Heir | Fon: *49 621 72739834 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/e1xjfvy-0008qo...@swivel.zugschlus.de
