Re: init system policy
Philip Hands p...@hands.com wrote: Not if you take into account the fact that someone will have had to do something like :wq! to get past the read-only state of the file. vim put's a [RO] after the filename when you open it, and says this when you try to write it: E45: 'readonly' option is set (add ! to override) in emacs, you get %% in the status line, and it tells you the file's read-only when you start trying to edit it, and refuses to do so until you type C-x C-q to flip it's read-only status. nano sadly doesn't seem to notice :-/ I just tried this, when you open a read-only file as a normal user it gives you a warning. edward@x230:~$ touch test edward@x230:~$ chmod 400 test edward@x230:~$ nano test Nano says: [ Read 0 line ( Warning: No write permission) ] It won't let me save the file with the same name, I get this error: [ Error writing test: Permission denied ] When running as root the warning and error disappear, there is no indication that the file is read-only. -- Edward. -- 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/20141123092558.GA12017@x230
Re: init system policy
Hi Simon, Thanks for the explanation -- all makes a lot more sense now. I'm much less tempted to rant about how large chunks of /lib should be moved to /etc (which is very good, because I don't suppose I'd be the first to suggest it ;-) ) Simon McVittie s...@debian.org writes: On 21/11/14 17:07, Philip Hands wrote: Is there any way this isn't going to be an enormous surprise to people that are used to the way that Debian usually treats /etc? I do get your point; editing the (underlying file for the) .service is unnecessary and undesirable for systemd, and if you blindly do vi /etc/.../thing.service and don't realise you're following a symlink, that would be a bad idea. Given that, it occurs to me that it might be wise to make these files in /lib read-only. If, when attempting to save the .service file, I'd been presented with a warning about it being read-only I think it would have been enough of a nudge to make me look a bit more closely at what was going on with the files (or not) under /etc. I think I'd have realised that I needed to do a bit more research at that point, since it was when I later noticed the symlinks that the fog lifted. Would there be any down-side to having these files read-only? (I presume that dpkg copes nicely with upgrading files even if read-only, and I don't really see why systemd should care). Even if it didn't actually save the stumbling user from falling over, at least when they start shouting about it the bugs can be closed with Well, we did try to stop you, but you ignored the read-only safety catch, and shot your foot anyway. Cheers, Phil. -- |)| Philip Hands [+44 (0)20 8530 9560] HANDS.COM Ltd. |-| http://www.hands.com/http://ftp.uk.debian.org/ |(| Hugo-Klemm-Strasse 34, 21075 Hamburg,GERMANY pgp_MgUZGyNL4.pgp Description: PGP signature
Re: init system policy
Matthias Urlichs matth...@urlichs.de writes: Hi, Philip Hands: Is there any way this isn't going to be an enormous surprise to people that are used to the way that Debian usually treats /etc? Well, instead of edit /etc/default/FOO and search for the flag to disable the daemon or the programmatic equivalent of add a bunch of symlinks named K* to /etc/rc* you run systemd mask SERVICE, which translates to add one symlink to /dev/null at /etc/systemd/system/SERVICE. Fair enough -- mask is not the first thing I though of as it happens :-) I'll see if there's some way of making the manual a bit more helpful, by for instance mentioning in the disable description that the reader might actually be looking for mask instead. Cheers, Phil. -- |)| Philip Hands [+44 (0)20 8530 9560] HANDS.COM Ltd. |-| http://www.hands.com/http://ftp.uk.debian.org/ |(| Hugo-Klemm-Strasse 34, 21075 Hamburg,GERMANY pgp5m5m3i3pwb.pgp Description: PGP signature
Re: init system policy
On 11/22/2014 at 03:44 AM, Philip Hands wrote: Hi Simon, Thanks for the explanation -- all makes a lot more sense now. I'm much less tempted to rant about how large chunks of /lib should be moved to /etc (which is very good, because I don't suppose I'd be the first to suggest it ;-) ) Simon McVittie s...@debian.org writes: On 21/11/14 17:07, Philip Hands wrote: Is there any way this isn't going to be an enormous surprise to people that are used to the way that Debian usually treats /etc? I do get your point; editing the (underlying file for the) .service is unnecessary and undesirable for systemd, and if you blindly do vi /etc/.../thing.service and don't realise you're following a symlink, that would be a bad idea. Given that, it occurs to me that it might be wise to make these files in /lib read-only. If, when attempting to save the .service file, I'd been presented with a warning about it being read-only I think it would have been enough of a nudge to make me look a bit more closely at what was going on with the files (or not) under /etc. It wouldn't have been enough for me; I would have just tried again as root, on the assumption that it was a simple user-permissions issue, and that would have succeeded since of course root can write data to a-w files. That's assuming I hadn't been trying the edit as root to begin with - which is more likely in any case, since I know quite well that most files under /etc aren't ordinary-user-writable. Even if it didn't actually save the stumbling user from falling over, at least when they start shouting about it the bugs can be closed with Well, we did try to stop you, but you ignored the read-only safety catch, and shot your foot anyway. That sounds like an unfriendly approach, to say the least. -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
Re: init system policy
The Wanderer wande...@fastmail.fm writes: On 11/22/2014 at 03:44 AM, Philip Hands wrote: Hi Simon, Thanks for the explanation -- all makes a lot more sense now. I'm much less tempted to rant about how large chunks of /lib should be moved to /etc (which is very good, because I don't suppose I'd be the first to suggest it ;-) ) Simon McVittie s...@debian.org writes: On 21/11/14 17:07, Philip Hands wrote: Is there any way this isn't going to be an enormous surprise to people that are used to the way that Debian usually treats /etc? I do get your point; editing the (underlying file for the) .service is unnecessary and undesirable for systemd, and if you blindly do vi /etc/.../thing.service and don't realise you're following a symlink, that would be a bad idea. Given that, it occurs to me that it might be wise to make these files in /lib read-only. If, when attempting to save the .service file, I'd been presented with a warning about it being read-only I think it would have been enough of a nudge to make me look a bit more closely at what was going on with the files (or not) under /etc. It wouldn't have been enough for me; I would have just tried again as root, on the assumption that it was a simple user-permissions issue, and that would have succeeded since of course root can write data to a-w files. Root can, but vim and emacs both tell you that you're writing to a read-only file, and you have to force it -- if you walk past that warnings without pausing for thought, well that's up to you. That's assuming I hadn't been trying the edit as root to begin with - which is more likely in any case, since I know quite well that most files under /etc aren't ordinary-user-writable. Even if it didn't actually save the stumbling user from falling over, at least when they start shouting about it the bugs can be closed with Well, we did try to stop you, but you ignored the read-only safety catch, and shot your foot anyway. That sounds like an unfriendly approach, to say the least. Not if you take into account the fact that someone will have had to do something like :wq! to get past the read-only state of the file. vim put's a [RO] after the filename when you open it, and says this when you try to write it: E45: 'readonly' option is set (add ! to override) in emacs, you get %% in the status line, and it tells you the file's read-only when you start trying to edit it, and refuses to do so until you type C-x C-q to flip it's read-only status. nano sadly doesn't seem to notice :-/ no idea about other editors. I guess that given the fact that nano doesn't protect users, one doesn't get to be rude to them -- oh well ;-) That's probably a bug in nano. I think that for the people that will use an editor that will mention that you're trying to fiddle with a read-only file, it would be helpful, and we could always fix editors that fail to mention that. Cheers, Phil. -- |)| Philip Hands [+44 (0)20 8530 9560] HANDS.COM Ltd. |-| http://www.hands.com/http://ftp.uk.debian.org/ |(| Hugo-Klemm-Strasse 34, 21075 Hamburg,GERMANY pgpljdjPRnhn8.pgp Description: PGP signature
Re: init system policy
Hi, Jonas Smedegaard d...@jones.dk writes: Thanks. Sounds like only a diff between system-provided and sysadmin-overrided config, however: That might help for the latter part of the question - notify only when system service file is overridden locally (by suppressing notification if systemd-deta is empty). How to do first part of the question - be notified with a diff between old versus new _effective_ config when a package update changes a system service file? One could probably write a tool that compares files before and after an update, but I don't think its really useful. Most software with configuration files has built-in default for many settings. You don't get a notification when these change, but the effective configuration might change, that is there is no real difference between changing ExecStart=/usr/bin/some-daemon --some-flag to ExecStart=/usr/bin/some-daemon --some-other-flag or a built-in default in some-daemon changing with the same effect. 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/877fypylms@deep-thought.43-1.org
Re: init system policy
There was some discussion about this a while back, and I vaguely remember that systemd comes with a tool that will tell you exactly what you're overriding. I'm not sure if that work got all the way to producing a nice Debian-aware tool or not. Sounds interesting. If anyone recall that discussion and can share a pointer, I would appreciate it. systemd-delta -- 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/cadstwjkya5uc2hoj+tntagrgsewss9gbsrx13vudgjmphvq...@mail.gmail.com
Re: init system policy
Quoting Ansgar Burchardt (2014-11-21 09:59:39) Jonas Smedegaard d...@jones.dk writes: Thanks. Sounds like only a diff between system-provided and sysadmin-overrided config, however: That might help for the latter part of the question - notify only when system service file is overridden locally (by suppressing notification if systemd-deta is empty). How to do first part of the question - be notified with a diff between old versus new _effective_ config when a package update changes a system service file? One could probably write a tool that compares files before and after an update, but I don't think its really useful. Most software with configuration files has built-in default for many settings. You don't get a notification when these change, but the effective configuration might change, that is there is no real difference between changing ExecStart=/usr/bin/some-daemon --some-flag to ExecStart=/usr/bin/some-daemon --some-other-flag or a built-in default in some-daemon changing with the same effect. I agree that solving *only* first part of the question is useless, as is solving only second part of question. If your point here is another, then I missed it - please elaborate. Reason I asked for first part was that those responding apparently only covered second part - which really means they were not really covering the issue raised, which is to get notified when _overridden_ configs have changed. We have that today, so arguably it is a regression to loose that ability (albeit a minor one, I do *not* say this is a reason to avoid systemd). Sure it would be even better to only get notified on _semantic_ changes rather than line-based ones, but that's a dream, not a regression. - Jonas -- * Jonas Smedegaard - idealist Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Re: init system policy
Hi, Jonas Smedegaard: Sure it would be even better to only get notified on _semantic_ changes rather than line-based ones, but that's a dream, not a regression. Given Python .ini script parser and some directory scanning, an initial program which does this shouldn't be too hard to do. Any takers? systemd-delta only accesses the running systemd's configuration, hence is useless for this. -- -- Matthias Urlichs signature.asc Description: Digital signature
Re: init system policy
Philip Hands writes (Re: init system policy): Would it perhaps make sense to have etckeeper additionally keep track of files in /lib directories for packages that have this /etc overrides /lib scheme? Such packages could add their config-outside-etc directories to a list somewhere, perhaps, which packages like etckeeper could then pick up on. I don't know how much etckeeper users use modifying (rather than recording) git operations, but I can imagine that this approach might easily result in etckeeper's git fighting with dpkg. Ian. -- 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/21615.13402.314746.761...@chiark.greenend.org.uk
Re: init system policy
On Thu, Nov 20, 2014 at 09:16:46PM +, Philip Hands wrote: Would it perhaps make sense to have etckeeper additionally keep track of files in /lib directories for packages that have this /etc overrides /lib scheme? Such packages could add their config-outside-etc I don’t think so, especially since those kind of files are scattered over the fs (other files are in /usr/share). We can discuss what those files should be: - configuration files that were not put in /etc because of shortcomings in the rpm conffile handling - „outsourced” defaults of the application In the first case the files should be moved backed to /etc. In the second case changed defaults should be documented in the changelog or readme. Shade and sweet water! Stephan -- | Stephan Seitz E-Mail: s...@fsing.rootsland.net | | Public Keys: http://fsing.rootsland.net/~stse/keys.html | signature.asc Description: Digital signature
Re: init system policy
Ian Jackson ijack...@chiark.greenend.org.uk writes: Philip Hands writes (Re: init system policy): Would it perhaps make sense to have etckeeper additionally keep track of files in /lib directories for packages that have this /etc overrides /lib scheme? Such packages could add their config-outside-etc directories to a list somewhere, perhaps, which packages like etckeeper could then pick up on. I don't know how much etckeeper users use modifying (rather than recording) git operations, but I can imagine that this approach might easily result in etckeeper's git fighting with dpkg. How so? I don't know about others, but I use etckeeper to track changes that I make to config files (when I remember) and am very happy for it to do its daily autocommit of changes (when I forget). I also occasionally fetch the etckeeper repo from what's supposed to be a similar machine, and then can do git diffs between the local files and the ones from a working server (yes I know there are security implications), and where it's obvious that I just want the config from the other one I can then just checkout that file (which strikes me as no different than if I'd just edited it by hand). If the thing that broke my server was either an unintentional edit of a /lib file, or the fact that a default that I had been relying upon just changed on upgrade, then being able to say what changed since last week is really helpful. Having stuff hidden from etckeeper means that the answer goes from being a definitive here's everything that's changed since things were working to being well there's this lot that changed, plus there may be other things, but I wasn't paying attention, sorry That seems like a rather serious regression to me (at least for my use cases). Cheers, Phil. -- |)| Philip Hands [+44 (0)20 8530 9560] HANDS.COM Ltd. |-| http://www.hands.com/http://ftp.uk.debian.org/ |(| Hugo-Klemm-Strasse 34, 21075 Hamburg,GERMANY pgp2ezDRZdqHE.pgp Description: PGP signature
Re: init system policy
Stephan Seitz stse+deb...@fsing.rootsland.net writes: On Thu, Nov 20, 2014 at 09:16:46PM +, Philip Hands wrote: Would it perhaps make sense to have etckeeper additionally keep track of files in /lib directories for packages that have this /etc overrides /lib scheme? Such packages could add their config-outside-etc I don’t think so, especially since those kind of files are scattered over the fs (other files are in /usr/share). We can discuss what those files should be: - configuration files that were not put in /etc because of shortcomings in the rpm conffile handling - „outsourced” defaults of the application In the first case the files should be moved backed to /etc. In the second case changed defaults should be documented in the changelog or readme. Moving the ones that really are config files back to /etc would certainly be my preference, but that's not what seems to be happening currently. I noticed this when trying to diagnose what turned out to be a stick lid switch on a laptop that I'd just upgraded to jessie, and had allowed systemd to become the init. In the mean time, I've de-installed gdm3 because gnome was unusable on the old hardware, so cannot provide an appropriately detailed bug report, but I notice that the same seems to hold for other things too, so I imagine that it's a bug (or feature) of systemd or policy rather than being package specific. Anyway, the laptop was suspending every 30 seconds, and I wanted to eliminate the possibility that it was gnome that was causing it, so wanted to prevent gdm starting at boot. I imagine there's a proper way to make this happen, but my flailing attempts to do so mostly failed, in part because of symlinks that strike me as wrong -- perhaps someone can explain why things are setup like this. So, I've been vaguely paying attention. I've heard of systemctl, I know there's this etc-overrides-lib thing going on, and I know that there are things called .service files. A quick glance at the manual leads me to try: systemctl disable gdm3 (and ... gdm, and a few other things) -- none of which work. So, then I try editing /etc/systemd/system/gdm3.service to tell it not to go, which means that I start seeing syntax errors (not really reading manuals much here -- I'm doing this in 30 second chunks remember ;-) ) So instead I remove the file and create an empty file. No effect. Later I realise that this is because there are more than one symlink From etc to lib for this file, and it's cross-linked inside lib as well, and my first edit was not on a file under /etc, but actually the one that's pointed at under /lib. In the end, replacing all the symlinks (including one called something verbose like desktop-environment) with empty files stopped gdm from being started, and then soon after I realised what the real problem was (the lid switch) and all was well. It seems quite dangerous to me to have these symlinks pointing out of /etc, just waiting for unsuspecting sysadmins to start editing files that are going to be quietly overwritten when the next upgrade happens. Given the fact that it's supposed to be etc overrides-lib I don't really see why they're there. Perhaps someone can explain the thinking behind this. If not, perhaps we need some policy to stop more of this sort of thing (looking in /etc/systemd on this machine I see that I have similar symlinks for rsyslog and ssh and probably others). I know this should perhaps be a bug report, but the laptop in question is to old to get anything good to happen with Gnome (particularly since the 3d effects provoke the glyphs to rot and be replaced by noise) so it's running LXDE now, so gdm3 would need to be re-installed before I could start with that, and when I did start looking into it again, I notice that ssh is doing the same thing anyway by the looks of it, so it's a more generic issue anyway, and perhaps not a bug at all -- hence this mail. Cheers, Phil. -- |)| Philip Hands [+44 (0)20 8530 9560] HANDS.COM Ltd. |-| http://www.hands.com/http://ftp.uk.debian.org/ |(| Hugo-Klemm-Strasse 34, 21075 Hamburg,GERMANY pgpyGrXZbynIl.pgp Description: PGP signature
Re: Re: init system policy
Vincent Bernat: There is chpst for this kind of task. Unfortunately, being part of runit, it may not be suitable for a dependency. * http://superuser.com/a/72 Actually, there are chpst, s6-setuidgid, daemontools-encore setuidgid, daemontools setuidgid, freedt setuidgid, nosh setuidgid, and runuid for this kind of task. (-: -- 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/546f46f3.2020...@ntlworld.com
Re: init system policy
On 21/11/14 14:04, Philip Hands wrote: A quick glance at the manual leads me to try: systemctl disable gdm3 (and ... gdm, and a few other things) -- none of which work. Display managers are unusual here; they're an exception to the usual enabledness stuff. Normally, a service is enabled by adding symlinks so that an appropriate target, like multi-user.target, wants the service. systemctl enable/disable (and Debian layers like the systemd support in update-rc.d) just adds/removes that symlink. However, systemd starts the (single) selected display manager via the alias display-manager.service, which is meant to point to whichever display manager is required; it is display-manager.service, not gdm3.service, that is configured to be wanted by multi-user.target. This is analogous to /etc/X11/default-display-manager, and display managers' maintainer scripts use that file to decide where display-manager.service should point. Display managers that participate in this mechanism do not need to be wanted under their own names (although if the selected one is, systemd will realise it's just an alias, and won't start it twice). FYI, you can prevent gdm3 from being started by systemd under any circumstances by applying a bigger hammer: systemctl mask. This is syntactic sugar for making a symlink gdm3.service - /dev/null. 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/546f4b0d.8010...@debian.org
Re: Re: init system policy
Russ Allbery: Yeah, this seems like the right solution to me too. Drop a configuration fragment in /etc/systemd that overrides the user and group and then don't touch it again. I refer you to footnote #85 in that patched document that I just sent to you. (-: -- 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/546f49f5.3030...@ntlworld.com
Re: init system policy
On 11/21/2014 03:26 PM, Jonathan de Boyne Pollard wrote: Eric Valette: There has been a good and valuable effort trying to split original upstream packages provided init system scripts by debian developers into /etc/default/X and /etc/init.d/X file and storing most commonly changed sysv init options in the default file part (including start or not). Wasting this work due to systemd transition would be a bad idea IMHO. It's actually thinking that /etc/default is the right place for service enable/disable information that has traditionally been seen as the bad idea. See Debian bug #522163 for starters. Never said that. I know the master of the universe said /etc/default must dispappear but his arguments are more than weak IMHO... I said separating complex config file into elements that should be modifiable by almost anyone without noticeable impacts and change that may lead to more complex situations is good for the novice. I do not assume everyone has been using Unix since its birdth... -- eric -- 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/546f4e98.2020...@free.fr
Re: Re: Re: init system policy
Eric Valette: There has been a good and valuable effort trying to split original upstream packages provided init system scripts by debian developers into /etc/default/X and /etc/init.d/X file and storing most commonly changed sysv init options in the default file part (including start or not). Wasting this work due to systemd transition would be a bad idea IMHO. It's actually thinking that /etc/default is the right place for service enable/disable information that has traditionally been seen as the bad idea. See Debian bug #522163 for starters. -- 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/546f4baa.4070...@ntlworld.com
Re: Re: init system policy
Eric Valette:
I just mentioned that naively combining User=$TOTO or ${TOTO} TOTO
being defined in an default/package file parsed by EnvironmentFile=
does not seem to work as documented in man pages (seen the very same
question being asked on various distro mailing list without
definitive answer).
It's working exactly as documented. The man pages don't say that any
such feature is available; and it isn't. (-:
Eric Valette:
systemd for servers systems may still have some way to go
for converting complex init scripts for firewall,openssh,VM's IMHO.
On the contrary, SSH service is one of the things that it is easy to set
up service and socket units for, with two different choices of
organization dependent from what program has the responsibility for
doing the accept()s. init.d scripts for this aren't exactly terribly
complex to start with, in the general spectrum of complexity across the
board. In FreeBSD, for example, the rc.d script is yet another ordinary
command=/usr/sbin/${name} script:
https://gitorious.org/freebsd/freebsd/source/f1d6f4778d2044502209708bc167c05f9aa48615:etc/rc.d/sshd
. It has some non-trivial precmd tasks, but that's nowhere near as
complex as some scripts.
--
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/546f50ad.3040...@ntlworld.com
Re: init system policy
Philip Hands writes (Re: init system policy):
Ian Jackson ijack...@chiark.greenend.org.uk writes:
I don't know how much etckeeper users use modifying (rather than
recording) git operations, but I can imagine that this approach might
easily result in etckeeper's git fighting with dpkg.
How so?
I mean, if you were to say something like
git checkout /lib/something
git revert [some commit that touches /lib/something]
git reset --hard @{yesterday}
You would be modifying, via git, files in /lib. The interaction
between dpkg and git would probably be ... exciting.
Ian.
--
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/21615.27956.922907.332...@chiark.greenend.org.uk
Re: init system policy
Simon McVittie s...@debian.org writes: On 21/11/14 14:04, Philip Hands wrote: A quick glance at the manual leads me to try: systemctl disable gdm3 (and ... gdm, and a few other things) -- none of which work. Display managers are unusual here; they're an exception to the usual enabledness stuff. Normally, a service is enabled by adding symlinks so that an appropriate target, like multi-user.target, wants the service. systemctl enable/disable (and Debian layers like the systemd support in update-rc.d) just adds/removes that symlink. However, systemd starts the (single) selected display manager via the alias display-manager.service, which is meant to point to whichever display manager is required; it is display-manager.service, not gdm3.service, that is configured to be wanted by multi-user.target. This is analogous to /etc/X11/default-display-manager, and display managers' maintainer scripts use that file to decide where display-manager.service should point. Display managers that participate in this mechanism do not need to be wanted under their own names (although if the selected one is, systemd will realise it's just an alias, and won't start it twice). FYI, you can prevent gdm3 from being started by systemd under any circumstances by applying a bigger hammer: systemctl mask. This is syntactic sugar for making a symlink gdm3.service - /dev/null. OK, that all makes sense, I think. Is there any way this isn't going to be an enormous surprise to people that are used to the way that Debian usually treats /etc? It seems that you're saying that throwing links in and out of /etc is the way one turns things on and off, and that to actually disable them one needs to symlink them to /dev/null. I seem to have achieved the same effect by replacing all the symlinks I could find with empty files -- I guess symlinks are preferred because you don't need to try to open one that's pointing to /dev/null, is that right? I must say, I was pretty surprised when it dawned on me what was actually going on, and I've been vaguely paying attention -- we're just about to make this the way people's machines work without much warning during upgrades, are we not (note that I think we shouldn't). I suppose we can hope that most of them never start an xterm let alone look at their init, but I'd expect some people to be pretty upset by this, which is going to result in another round of, erm, fun. Cheers, Phil. -- |)| Philip Hands [+44 (0)20 8530 9560] HANDS.COM Ltd. |-| http://www.hands.com/http://ftp.uk.debian.org/ |(| Hugo-Klemm-Strasse 34, 21075 Hamburg,GERMANY pgp6XygzXI02T.pgp Description: PGP signature
Re: init system policy
Ian Jackson ijack...@chiark.greenend.org.uk writes:
Philip Hands writes (Re: init system policy):
Ian Jackson ijack...@chiark.greenend.org.uk writes:
I don't know how much etckeeper users use modifying (rather than
recording) git operations, but I can imagine that this approach might
easily result in etckeeper's git fighting with dpkg.
How so?
I mean, if you were to say something like
git checkout /lib/something
git revert [some commit that touches /lib/something]
git reset --hard @{yesterday}
You would be modifying, via git, files in /lib. The interaction
between dpkg and git would probably be ... exciting.
Well, yes. I think you've got to have a very clear idea what's going to
happen if you do a reset --hard @{yesterday} in /etc as it is, and it's
going to be about as bad an idea if you've upgraded packages in the
interim doing that in /etc as in /lib (well, at least if you do that
without a careful look at the diff first, which would probably deal with
the /lib/something case too).
Cheers, Phil.
--
|)| Philip Hands [+44 (0)20 8530 9560] HANDS.COM Ltd.
|-| http://www.hands.com/http://ftp.uk.debian.org/
|(| Hugo-Klemm-Strasse 34, 21075 Hamburg,GERMANY
pgp1WiwuAPs3P.pgp
Description: PGP signature
Re: init system policy
On 21/11/14 17:07, Philip Hands wrote: Is there any way this isn't going to be an enormous surprise to people that are used to the way that Debian usually treats /etc? I do get your point; editing the (underlying file for the) .service is unnecessary and undesirable for systemd, and if you blindly do vi /etc/.../thing.service and don't realise you're following a symlink, that would be a bad idea. There are two slightly separate things going on here: the contents of each unit, and the units that are wanted by each target. If the units' contents are like /etc/init.d/whatever, then the targets (multi-user.target and so on) are like runlevels, and the symlinks in *.target.wants to units that are wanted by each target are like the symlinks in rc?.d to scripts that are wanted by each runlevel. For the contents, there are ways to override it that do not involve editing the shipped file: the preferred way is to add drop-ins in /etc/systemd/system/whatever.service.d/*.conf which can override individual lines. You can also copy the file from /lib/systemd/system/whatever.service to /etc/systemd/system/whatever.service and edit that, which is the closest equivalent to editing /etc/init.d/whatever in sysvinit. If I remember correctly, the maintainers of systemd in Debian considered the idea of moving or copying each file from /lib/systemd/system into /etc/systemd/system (to make them into dpkg- or ucf-controlled conffiles), and specifically decided not to do it. It seems that you're saying that throwing links in and out of /etc is the way one turns things on and off Normally, manipulating symlinks in /etc/systemd/system/*.target.wants is sufficient, and preferred. Removing those symlinks is not 100% equivalent to rc?.d, strictly speaking: it means starting this during boot is not required, unless you find some other reason why it should be. The unit remains in the dependency graph but is excluded from the set of explicit goals. The display manager is an exception to the normally... because there is another reason for it to be required: the display-manager.service alias is wanted by graphical.target, using a line in the file rather than a symlink (because the definition of graphical.target is exactly multi-user mode and also start *dm). The way to not start any display manager under systemd, even if one is installed, is to make /etc/systemd/system/default.target a symlink to /lib/systemd/system/multi-user.target, overriding the existing symlink /lib/systemd/system/default.target - graphical.target. and that to actually disable them one needs to symlink them to /dev/null A symlink to /dev/null in /etc/systemd/system means forget you ever knew about a unit with this name. It masks the corresponding file in /lib/systemd/system and causes it not to be loaded, as if it wasn't installed at all; anything with a soft dependency on it (Wants) will carry on without it, and anything with a hard dependency on it (Requires) will just not start. I seem to have achieved the same effect by replacing all the symlinks I could find with empty files -- I guess symlinks are preferred because you don't need to try to open one that's pointing to /dev/null, is that right? An empty file in /etc/systemd/system also counts as masking the service. A link to /dev/null is conventional, and I think systemd might have a minor optimization for it as you say, but the practical effect is the same. I'm not sure whether a regular file in /etc/systemd/system/*.wants.d/ has well-defined semantics, any more than a regular file in /etc/rc2.d/ would: *.wants.d is documented to contain symlinks to units, as opposed to units themselves. 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/546f7f8f.2050...@debian.org
Re: init system policy
Hi, Philip Hands: Is there any way this isn't going to be an enormous surprise to people that are used to the way that Debian usually treats /etc? Well, instead of edit /etc/default/FOO and search for the flag to disable the daemon or the programmatic equivalent of add a bunch of symlinks named K* to /etc/rc* you run systemd mask SERVICE, which translates to add one symlink to /dev/null at /etc/systemd/system/SERVICE. This is discoverable if you read the systemctl manpage. Granted, that page is somewhat longer than the one for invoke- and update-rc.d, but OTOH systemctl can do a bit more than these. I do wonder, reading these manpages, whether the enable/disable/mask subcommands could do with somewhat clearer text in that manpage, but I'm the wrong person to work on that – at least if the goal is to actually _improve_ their clarity. :-/ It seems that you're saying that throwing links in and out of /etc is the way one turns things on and off, and that to actually disable them one needs to symlink them to /dev/null. That's what systemctl ends up doing, not what you should do manually. I suppose we can hope that most of them never start an xterm let alone look at their init, but I'd expect some people to be pretty upset by this, which is going to result in another round of, erm, fun. Personally I'm much more upset when I tell the init system that starting my app servers should depend on a running postgres which in turn should only start when the database disks get mounted, and that doesn't happen. -- -- Matthias Urlichs -- 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/20141121183453.gf15...@smurf.noris.de
Re: init system policy
Hi, On 18/11/2014 18:36, Ansgar Burchardt wrote: With systemd you can ship a default configuration in /lib/systemd/system and administrators can override specific options, for example: +--- | [Unit] | Description=Some Helpful Description | Documentation=man:minidlda(1) | | [Service] | User=minidlda | ExecStart=/usr/sbin/minidldad -S +---[ /lib/systemd/system/minidlda.service ] Then an admin can override the entire file by writing his own /etc/systemd/system/minidlda.service or only override specific settings: +--- | [Service] | User=some-other-user +---[ /etc/systemd/system/miniblda.service.d/user.conf ] I did not know that. It is very interesting. But, is there a way to be notified at upgrade time that the system service file has been modified when there is local (partial or full) changes ? As a small workaround, I think I will put symlinks such as /lib/systemd/[perhaps sub-directory, to check] - /etc/systemd/lib/[...] This way, systemd config files and their changes will be, at least, recorded by etckeeper. Regards, Vincent Ansgar -- Vincent Danjean GPG key ID 0xD17897FA vdanj...@debian.org GPG key fingerprint: 621E 3509 654D D77C 43F5 CA4A F6AE F2AF D178 97FA Unofficial pkgs: http://moais.imag.fr/membres/vincent.danjean/deb.html APT repo: deb http://people.debian.org/~vdanjean/debian unstable main -- 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/546debe7.7060...@free.fr
Re: Re: init system policy
I did not know that. It is very interesting. But, is there a way to be notified at upgrade time that the system service file has been modified when there is local (partial or full) changes ? As a small workaround, I think I will put symlinks such as /lib/systemd/[perhaps sub-directory, to check] - /etc/systemd/lib/[...] This way, systemd config files and their changes will be, at least, recorded by etckeeper. Non sure you want to automate that. For minidlna, there are several conf files that can be edited. more minidlna.conffiles /etc/minidlna.conf /etc/init.d/minidlna /etc/default/minidlna Some are mostly relevant to the init system itself (default one), some to minidlna daemon itself. When you start modifying the daemon config you may modify all the files and some have a syntax that cannot be changed. If your restart the daemon after modifying the unit config file and later modify its own managed config file, unless the daemon monitors the config file chnages itself, you wil have to restart. -- eric -- 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/546df440.9010...@free.fr
Re: Re: init system policy
On Wed, Nov 19, 2014 at 02:51:57PM +, Ian Jackson wrote: Laurent Bigonville writes (Re: Re: init system policy): Matthias Urlichs wrote: See man 5 sudoers for details. You probably want to use runuser that has been introduced recently in utils-linux Or `really' from chiark-really (from chiark-utils). Considering that util-linux is Priority: required while chiark-really is Priority: extra I'd suggest that runuser would be a more sensible recommendation. Still, I love the package description for really :) Kind regards, David -- /) David Weinehall t...@debian.org /) Rime on my window (\ // ~ // Diamond-white roses of fire // \) http://www.acc.umu.se/~tao/(/ Beautiful hoar-frost (/ -- 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/20141120142109.gh8...@hirohito.acc.umu.se
Re: init system policy
Quoting Vincent Danjean (2014-11-20 14:25:59) Hi, On 18/11/2014 18:36, Ansgar Burchardt wrote: With systemd you can ship a default configuration in /lib/systemd/system and administrators can override specific options, for example: +--- | [Unit] | Description=Some Helpful Description | Documentation=man:minidlda(1) | | [Service] | User=minidlda | ExecStart=/usr/sbin/minidldad -S +---[ /lib/systemd/system/minidlda.service ] Then an admin can override the entire file by writing his own /etc/systemd/system/minidlda.service or only override specific settings: +--- | [Service] | User=some-other-user +---[ /etc/systemd/system/miniblda.service.d/user.conf ] I did not know that. It is very interesting. But, is there a way to be notified at upgrade time that the system service file has been modified when there is local (partial or full) changes ? I was wondering the same. Seems to me this is a similar limitation as for config.d structures - as an example apache2 is now far more modular than in the past but I no longer as sysadmin get notified what exactly has changed when I upgrade a system with customizations, as I did in the past thanks to the monolithic configfile being a conffile. As a small workaround, I think I will put symlinks such as /lib/systemd/[perhaps sub-directory, to check] - /etc/systemd/lib/[...] This way, systemd config files and their changes will be, at least, recorded by etckeeper. If you mean a symlink, then I suspect etckeeper will only track it as such - i.e. only really track the existence, not its content. If you mean a hardlink, then I suspect it won't be preserved as such on package updates. - Jonas -- * Jonas Smedegaard - idealist Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Re: init system policy
2014-11-20 16:12 GMT+01:00 Jonas Smedegaard d...@jones.dk: Quoting Vincent Danjean (2014-11-20 14:25:59) Hi, On 18/11/2014 18:36, Ansgar Burchardt wrote: With systemd you can ship a default configuration in /lib/systemd/system and administrators can override specific options, for example: +--- | [Unit] | Description=Some Helpful Description | Documentation=man:minidlda(1) | | [Service] | User=minidlda | ExecStart=/usr/sbin/minidldad -S +---[ /lib/systemd/system/minidlda.service ] Then an admin can override the entire file by writing his own /etc/systemd/system/minidlda.service or only override specific settings: +--- | [Service] | User=some-other-user +---[ /etc/systemd/system/miniblda.service.d/user.conf ] I did not know that. It is very interesting. But, is there a way to be notified at upgrade time that the system service file has been modified when there is local (partial or full) changes ? I was wondering the same. At least for the systemd-case, you can easily notice changes using the systemd-delta command: $ systemd-delta --diff This will list all overrides and the differences in case something has changed. Cheers, Matthias -- Debian Developer | Freedesktop-Developer I welcome VSRE emails. See http://vsre.info/ -- 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/CAKNHny_YoFgcKTOY1d0BqobqoG8cG0XXw9nBj-B56efwCDR=a...@mail.gmail.com
Re: init system policy
Jonas Smedegaard d...@jones.dk writes: Seems to me this is a similar limitation as for config.d structures - as an example apache2 is now far more modular than in the past but I no longer as sysadmin get notified what exactly has changed when I upgrade a system with customizations, as I did in the past thanks to the monolithic configfile being a conffile. There was some discussion about this a while back, and I vaguely remember that systemd comes with a tool that will tell you exactly what you're overriding. I'm not sure if that work got all the way to producing a nice Debian-aware tool or not. Personally (and this is just a wishlist), I'd love to have functionality similar to apt-listchanges that would (optionally) show me a report of every change to any unit file that I've overridden on each upgrade. -- 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/87tx1tet03@hope.eyrie.org
Re: init system policy
Quoting Matthias Klumpp (2014-11-20 17:15:50) 2014-11-20 16:12 GMT+01:00 Jonas Smedegaard d...@jones.dk: Quoting Vincent Danjean (2014-11-20 14:25:59) Hi, On 18/11/2014 18:36, Ansgar Burchardt wrote: With systemd you can ship a default configuration in /lib/systemd/system and administrators can override specific options, for example: +--- | [Unit] | Description=Some Helpful Description | Documentation=man:minidlda(1) | | [Service] | User=minidlda | ExecStart=/usr/sbin/minidldad -S +---[ /lib/systemd/system/minidlda.service ] Then an admin can override the entire file by writing his own /etc/systemd/system/minidlda.service or only override specific settings: +--- | [Service] | User=some-other-user +---[ /etc/systemd/system/miniblda.service.d/user.conf ] I did not know that. It is very interesting. But, is there a way to be notified at upgrade time that the system service file has been modified when there is local (partial or full) changes ? I was wondering the same. At least for the systemd-case, you can easily notice changes using the systemd-delta command: $ systemd-delta --diff This will list all overrides and the differences in case something has changed. Thanks. Sounds like only a diff between system-provided and sysadmin-overrided config, however: That might help for the latter part of the question - notify only when system service file is overridden locally (by suppressing notification if systemd-deta is empty). How to do first part of the question - be notified with a diff between old versus new _effective_ config when a package update changes a system service file? With conffiles, sysadmin can be notified on changes by simply changing whitespace to the conffile (as that invalidates md5sum). - Jonas -- * Jonas Smedegaard - idealist Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Re: init system policy
Quoting Russ Allbery (2014-11-20 17:28:28) Jonas Smedegaard d...@jones.dk writes: Seems to me this is a similar limitation as for config.d structures - as an example apache2 is now far more modular than in the past but I no longer as sysadmin get notified what exactly has changed when I upgrade a system with customizations, as I did in the past thanks to the monolithic configfile being a conffile. There was some discussion about this a while back, and I vaguely remember that systemd comes with a tool that will tell you exactly what you're overriding. I'm not sure if that work got all the way to producing a nice Debian-aware tool or not. Sounds interesting. If anyone recall that discussion and can share a pointer, I would appreciate it. Personally (and this is just a wishlist), I'd love to have functionality similar to apt-listchanges that would (optionally) show me a report of every change to any unit file that I've overridden on each upgrade. I have tinkered with some tools related to that. Far from reliable yet, but knowing I am not alone with that wishlist might push me enough to polish those tools adequately... So thank you for the encouragement :-) - Jonas -- * Jonas Smedegaard - idealist Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Re: init system policy
2014-11-20 17:44 GMT+01:00 Jonas Smedegaard d...@jones.dk: Quoting Matthias Klumpp (2014-11-20 17:15:50) 2014-11-20 16:12 GMT+01:00 Jonas Smedegaard d...@jones.dk: Quoting Vincent Danjean (2014-11-20 14:25:59) Hi, On 18/11/2014 18:36, Ansgar Burchardt wrote: With systemd you can ship a default configuration in /lib/systemd/system and administrators can override specific options, for example: +--- | [Unit] | Description=Some Helpful Description | Documentation=man:minidlda(1) | | [Service] | User=minidlda | ExecStart=/usr/sbin/minidldad -S +---[ /lib/systemd/system/minidlda.service ] Then an admin can override the entire file by writing his own /etc/systemd/system/minidlda.service or only override specific settings: +--- | [Service] | User=some-other-user +---[ /etc/systemd/system/miniblda.service.d/user.conf ] I did not know that. It is very interesting. But, is there a way to be notified at upgrade time that the system service file has been modified when there is local (partial or full) changes ? I was wondering the same. At least for the systemd-case, you can easily notice changes using the systemd-delta command: $ systemd-delta --diff This will list all overrides and the differences in case something has changed. Thanks. Sounds like only a diff between system-provided and sysadmin-overrided config, however: That might help for the latter part of the question - notify only when system service file is overridden locally (by suppressing notification if systemd-deta is empty). How to do first part of the question - be notified with a diff between old versus new _effective_ config when a package update changes a system service file? I don't now of any tool which does that yet - but it shouldn't be hard to write one that does it (maybe we could even run that by default if a package touches a vendor-supplied configuration in /lib). It would just be comparing checksums before and after installation of a package, and then point the sysadmin at the changed file. -- Debian Developer | Freedesktop-Developer I welcome VSRE emails. See http://vsre.info/ -- 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/caknhny_n20kjy4rmk3ekkjrr8nz2qnxekki3grfcldcotx9...@mail.gmail.com
Re: init system policy
Matthias Klumpp matth...@tenstral.net writes: 2014-11-20 17:44 GMT+01:00 Jonas Smedegaard d...@jones.dk: Quoting Matthias Klumpp (2014-11-20 17:15:50) 2014-11-20 16:12 GMT+01:00 Jonas Smedegaard d...@jones.dk: Quoting Vincent Danjean (2014-11-20 14:25:59) Hi, On 18/11/2014 18:36, Ansgar Burchardt wrote: With systemd you can ship a default configuration in /lib/systemd/system and administrators can override specific options, for example: +--- | [Unit] | Description=Some Helpful Description | Documentation=man:minidlda(1) | | [Service] | User=minidlda | ExecStart=/usr/sbin/minidldad -S +---[ /lib/systemd/system/minidlda.service ] Then an admin can override the entire file by writing his own /etc/systemd/system/minidlda.service or only override specific settings: +--- | [Service] | User=some-other-user +---[ /etc/systemd/system/miniblda.service.d/user.conf ] I did not know that. It is very interesting. But, is there a way to be notified at upgrade time that the system service file has been modified when there is local (partial or full) changes ? I was wondering the same. At least for the systemd-case, you can easily notice changes using the systemd-delta command: $ systemd-delta --diff This will list all overrides and the differences in case something has changed. Thanks. Sounds like only a diff between system-provided and sysadmin-overrided config, however: That might help for the latter part of the question - notify only when system service file is overridden locally (by suppressing notification if systemd-deta is empty). How to do first part of the question - be notified with a diff between old versus new _effective_ config when a package update changes a system service file? I don't now of any tool which does that yet - but it shouldn't be hard to write one that does it (maybe we could even run that by default if a package touches a vendor-supplied configuration in /lib). It would just be comparing checksums before and after installation of a package, and then point the sysadmin at the changed file. Would it perhaps make sense to have etckeeper additionally keep track of files in /lib directories for packages that have this /etc overrides /lib scheme? Such packages could add their config-outside-etc directories to a list somewhere, perhaps, which packages like etckeeper could then pick up on. Cheers, Phil. -- |)| Philip Hands [+44 (0)20 8530 9560] HANDS.COM Ltd. |-| http://www.hands.com/http://ftp.uk.debian.org/ |(| Hugo-Klemm-Strasse 34, 21075 Hamburg,GERMANY pgpgMkmtJ9CJy.pgp Description: PGP signature
Re: init system policy
On Thu, Nov 20, 2014 at 8:28 AM, Russ Allbery r...@debian.org wrote: Jonas Smedegaard d...@jones.dk writes: Seems to me this is a similar limitation as for config.d structures - as an example apache2 is now far more modular than in the past but I no longer as sysadmin get notified what exactly has changed when I upgrade a system with customizations, as I did in the past thanks to the monolithic configfile being a conffile. There was some discussion about this a while back, and I vaguely remember that systemd comes with a tool that will tell you exactly what you're overriding. I'm not sure if that work got all the way to producing a nice Debian-aware tool or not. Personally (and this is just a wishlist), I'd love to have functionality similar to apt-listchanges that would (optionally) show me a report of every change to any unit file that I've overridden on each upgrade. But systemd is not the only package to provide a vendor config in /lib (or /usr/share or /usr/lib) and allow it to be overridden by a file in /etc. One example is mountall, which provides a base fstab in /lib/init/ that is overridden by entries in /etc/fstab. networkd and many other systemd components are similar in this as well. I think debian conffiles need a generic mechanism that allows packages to associate files in /etc with files in the vendor directories like /lib so that the admin is notified when the vendor supplied configuration is changed. Maybe it could look like this, in `debian/package.conffiles` : # traditional conffiles entries /etc/package/main.conf # new entries # admin-supplied vendor-supplied /etc/package/other.conf /usr/share/package/other.conf /etc/systemd/system/package.service /lib/systemd/system/package.service /etc/systemd/system/package.service.d/* /lib/systemd/system/package.service Seeing as systemd upstream is pushing the stateless systems idea, and there is definitely merit to it, I think this is the best way to tackle the issue. Best wishes, -- Cameron Norman -- 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/calzwfr+iosvcpxucmttt_1ck7c1jxrupgss_qbnacfwuplc...@mail.gmail.com
Re: init system policy
❦ 19 novembre 2014 08:45 +0100, Matthias Urlichs matth...@urlichs.de : The disadvantage of the sudo method is that you are spawning a PAM session, which is not desirable for any service. Ah. Thanks for the reminder; mentioning the session issue completely slipped my mind. :-/ If one does need to use a sudo intermediate to start services, the 'pam_session', 'pam_setcred', and 'use_pty' flags should be turned off, as well as sudo's internal logging. This will cause sudo to not create a PAM session, and directly exec() the daemon instead of running an intermediate fork. There is chpst for this kind of task. Unfortunately, being part of runit, it may not be suitable for a dependency. -- /* Thanks to Rob `CmdrTaco' Malda for not influencing this code in any * way. */ 2.4.3 linux/net/core/netfilter.c signature.asc Description: PGP signature
Re: Re: init system policy
well, debconf seems like a win here. There's no reasonable default so it's desirable to make it easy for the admin to specify and so you'd probably want to use normal best practice for debconf updates. I agree with this but unfortunately original minidlna package as no debconf setup :-) -- eric -- 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/546c6051.2040...@free.fr
Re: Re: init system policy
Matthias Urlichs wrote: Hi, Steve Langasek: The disadvantage of the sudo method is that you are spawning a PAM session, which is not desirable for any service. Ah. Thanks for the reminder; mentioning the session issue completely slipped my mind. :-/ If one does need to use a sudo intermediate to start services, the 'pam_session', 'pam_setcred', and 'use_pty' flags should be turned off, as well as sudo's internal logging. This will cause sudo to not create a PAM session, and directly exec() the daemon instead of running an intermediate fork. See man 5 sudoers for details. You probably want to use runuser that has been introduced recently in utils-linux Cheers, Laurent Bigonville -- 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/20141119112407.70d93...@soldur.bigon.be
Re: Re: init system policy
Eric Valette eric.vale...@free.fr wrote: well, debconf seems like a win here. There's no reasonable default so it's desirable to make it easy for the admin to specify and so you'd probably want to use normal best practice for debconf updates. I agree with this but unfortunately original minidlna package as no debconf setup :-) No problem. Since debconf is not a registry™, you can parse the current values in /etc/default to fill in debconf, then generate both /etc/default and the systemd unit. For further updates, you can use the systemd unit as the primary configuration source. -- Joss -- 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/1416397906.8947.148.camel@dsp0698014
Re: Re: init system policy
Laurent Bigonville writes (Re: Re: init system policy): Matthias Urlichs wrote: See man 5 sudoers for details. You probably want to use runuser that has been introduced recently in utils-linux Or `really' from chiark-really (from chiark-utils). Ian. -- 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/21612.44685.790974.845...@chiark.greenend.org.uk
Re: init system policy
Am Dienstag, 18. November 2014, 23:31:53 schrieb Steve Langasek: On Tue, Nov 18, 2014 at 07:47:59PM +0100, Matthias Urlichs wrote: Your specific package may well have different and non-general requirements, in which case ExecStart=sudo -u $USER_MINIDLNA -g GROUP_MINIDLNA /usr/sbin/minidlnad -S is an adequate and perfectly serviceable answer to your question. init script has the ability to change the user and this is really useful because the multimedia file are likely owned by you and in your home directory by daemon and not minidlna and why should you belong to minidlna group?... Maybe because Debian is a multiuser system AIUI, so running the daemon as a specific normal user didn't even occur to me. Sorry! But again this does not really slpit the script to configurable option that will not be overwritten when upgrading... The idea is for the package to ship a /lib/systemd/system/PACKAGE.service file which uses a generic user+group. You can then add a file /etc/systemd/system/PACKAGE.service which merely overwrites user+group settings and does not contain any other entries, in which case they'll be inherited from the file in /lib. No overwriting on update will happen. If you already do have an /etc/default/PACKAGE file, the sudo method's advantage is that you can just use an EnvironmentFile= stanza, and thus don't need to keep that and /etc/systemd/system/PACKAGE.service in sync somehow. The disadvantage of the sudo method is that you are spawning a PAM session, which is not desirable for any service. Preferable would be to parse any existing config file for non-default user settings as part of the package upgrade and write out /etc/systemd/system/PACKAGE.service with only these non-default values, avoiding any variable substitution or sudo invocation entirely. This may break hibernation and probably suspend to disk unless dbus policy for it is changed. I reported a bug about it sometime ago. -- Martin 'Helios' Steigerwald - http://www.Lichtvoll.de GPG: 03B0 0D6C 0040 0710 4AFA B82F 991B EAAC A599 84C7 signature.asc Description: This is a digitally signed message part.
Re: init system policy
Hi, [ redirecting to debian-devel, as -policy isn't the correct list for this IMHO ] Eric Valette: html Text emails, please. I've been fighting with some script conversion to systemd and I think a reasonnably complex exemple should be of great help. I've been What's reasonably complex to you is absurdly simple to one reader and needlessly arcane to somebody else. :-/ trying to convert minidlna sysv init file to systemd, managed to have a working unit file but failed to split the configuration mimicing the ../default/minidlna content with the hability to make USER and GROUP configurable. You _can_ do ExecStart=sudo -u $USER_MINIDLNA -g GROUP_MINIDLNA /usr/sbin/minidlnad -S but that's not the optimal solution here. It's better IMHO to use a fixed user in your packaging -- why should that user be configurable in the first place? If the sysadmin _really_ needs to use a different user+group, they can add an overriding unit file to /etc/systemd/system/ (files get merged, so no need to copy the whole thing). ExecStartPre=/bin/mkdir -p /var/run/minidlna You might want to use this opportunity to replace /var/run with /run. ExecStartPre=/bin/chown $USER /var/run/minidlna You should use %u; see systemd.unit(5). Also, one ExecStartPre stanza is sufficient: ExecStartPre=/usr/bin/install -o %u -g %g -m 0750 -d /run/minidlna (or whichever mode is appropriate) -- -- Matthias Urlichs signature.asc Description: Digital signature
Re: init system policy
Hi, On 11/18/2014 05:39 PM, Matthias Urlichs wrote: trying to convert minidlna sysv init file to systemd, managed to have a working unit file but failed to split the configuration mimicing the ../default/minidlna content with the hability to make USER and GROUP configurable. You _can_ do ExecStart=sudo -u $USER_MINIDLNA -g GROUP_MINIDLNA /usr/sbin/minidlnad -S but that's not the optimal solution here. It's better IMHO to use a fixed user in your packaging -- why should that user be configurable in the first place? If the sysadmin _really_ needs to use a different user+group, they can add an overriding unit file to /etc/systemd/system/ (files get merged, so no need to copy the whole thing). Ack. ExecStartPre=/bin/mkdir -p /var/run/minidlna You might want to use this opportunity to replace /var/run with /run. ExecStartPre=/bin/chown $USER /var/run/minidlna Both of these can be replaced with RuntimeDirectory=minidlda which will create /run/minidlna, chown it to the user given in User= and even remove it again once the service is stopped. There's RuntimeDirectoryMode= if you need different permissions. All of this is documented in systemd.exec(5) if you want more information. 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/546b77dd.1090...@43-1.org
Re: init system policy
On 18/11/2014 17:39, Matthias Urlichs wrote: Text emails, please. I alway forget that in my company my mailer is configured for html as outlook discussion cut is absurd... You _can_ do ExecStart=sudo -u $USER_MINIDLNA -g GROUP_MINIDLNA /usr/sbin/minidlnad -S but that's not the optimal solution here. Yes not really. And given the number of damons that chnage the uid/gid, it would rather be good to define a best practice!!! It's better IMHO to use a fixed user in your packaging -- why should that user be configurable in the first place? If the sysadmin _really_ needs to use a different user+group, they can add an overriding unit file to /etc/systemd/system/ (files get merged, so no need to copy the whole thing). That's typical: instead of answering the question, you try to say the actual packaging is absurd. Its current debian packaging for systemv! The system V init script has the ability to change the user and this is really useful because the multimedia file are likely owned by you and in your home directory by daemon and not minidlna and why should you belong to minidlna group?... And running anything that use upnp as root I suggest to not do for security reasons... ExecStartPre=/bin/mkdir -p /var/run/minidlna You might want to use this opportunity to replace /var/run with /run. Sure. Also, one ExecStartPre stanza is sufficient: ExecStartPre=/usr/bin/install -o %u -g %g -m 0750 -d /run/minidlna But again this does not really slpit the script to configurable option that will not be overwritten when upgrading... -- 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/546b8049.3030...@free.fr
Re: init system policy
On 18/11/2014 17:46, Ansgar Burchardt wrote: Hi, On 11/18/2014 05:39 PM, Matthias Urlichs wrote: trying to convert minidlna sysv init file to systemd, managed to have a working unit file but failed to split the configuration mimicing the ../default/minidlna content with the hability to make USER and GROUP configurable. You _can_ do ExecStart=sudo -u $USER_MINIDLNA -g GROUP_MINIDLNA /usr/sbin/minidlnad -S but that's not the optimal solution here. It's better IMHO to use a fixed user in your packaging -- why should that user be configurable in the first place? If the sysadmin _really_ needs to use a different user+group, they can add an overriding unit file to /etc/systemd/system/ (files get merged, so no need to copy the whole thing). Ack. In the file they just need to set User and Group then? Both of these can be replaced with RuntimeDirectory=minidlda which will create /run/minidlna, chown it to the user given in User= and even remove it again once the service is stopped. There's RuntimeDirectoryMode= if you need different permissions. All of this is documented in systemd.exec(5) if you want more information. Thanks. I read them for trying to fix the User= dynamic problem but did not found this. -- eric -- 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/546b8114.7050...@free.fr
Re: init system policy
Hi, On 11/18/2014 06:25 PM, Eric Valette wrote: In the file they just need to set User and Group then? With systemd you can ship a default configuration in /lib/systemd/system and administrators can override specific options, for example: +--- | [Unit] | Description=Some Helpful Description | Documentation=man:minidlda(1) | | [Service] | User=minidlda | ExecStart=/usr/sbin/minidldad -S +---[ /lib/systemd/system/minidlda.service ] Then an admin can override the entire file by writing his own /etc/systemd/system/minidlda.service or only override specific settings: +--- | [Service] | User=some-other-user +---[ /etc/systemd/system/miniblda.service.d/user.conf ] 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/546b83b2.3010...@43-1.org
Re: init system policy
On 18/11/2014 18:36, Ansgar Burchardt wrote: Hi, On 11/18/2014 06:25 PM, Eric Valette wrote: In the file they just need to set User and Group then? With systemd you can ship a default configuration in /lib/systemd/system and administrators can override specific options, for example: +--- | [Unit] | Description=Some Helpful Description | Documentation=man:minidlda(1) | | [Service] | User=minidlda | ExecStart=/usr/sbin/minidldad -S +---[ /lib/systemd/system/minidlda.service ] Then an admin can override the entire file by writing his own /etc/systemd/system/minidlda.service or only override specific settings: +--- | [Service] | User=some-other-user +---[ /etc/systemd/system/miniblda.service.d/user.conf ] That's crystal clear and solves my problem (cannot reuse the system v default config file but that's a minor and expected problem) Thanks for your time --eric -- 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/546b8997.2030...@free.fr
Re: init system policy
On Tue, 18 Nov 2014, Matthias Urlichs wrote: trying to convert minidlna sysv init file to systemd, managed to have a working unit file but failed to split the configuration mimicing the ../default/minidlna content with the hability to make USER and GROUP configurable. You _can_ do ExecStart=sudo -u $USER_MINIDLNA -g GROUP_MINIDLNA /usr/sbin/minidlnad -S but that's not the optimal solution here. It's better IMHO to use a fixed user in your packaging -- why should that user be configurable in the first place? If the sysadmin _really_ needs to use a different user+group, they can add an overriding unit file to /etc/systemd/system/ (files get merged, so no need to copy the whole thing). Failing to address this would be a severe regression, of the kind that introduces a security hole. You'd need to abort package configuration on upgrades if you cannot handle it automatically. Several packages will need to address this same issue. We should try to find a really good answer for this scenario. A first option would be a way to load config data from a VAR=VALUE text file in systemd units, and pass some of those vars as the value for User= / Group= (from systemd.exec(5)). Is that possible in jessie's systemd ? A second option is to migrate on upgrade the uid/gid information into an override in /etc/systemd/system. Requires dealing with a dynamically generated config file in preinst/postinst, though, which means the tools that help proper config file handling in maintainer scripts (ucf, and sometimes dpkg-maintscript-helper) will be of limited help. There's also the sudo solution described above, which has its own problems, but which is likely to be workable in most of the cases. Any other ideas? -- 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/20141118182722.gc2...@khazad-dum.debian.net
Re: init system policy
Hi, Eric Valette: It's better IMHO to use a fixed user in your packaging -- why should that user be configurable in the first place? If the sysadmin _really_ needs to use a different user+group, they can add an overriding unit file to /etc/systemd/system/ (files get merged, so no need to copy the whole thing). That's typical: instead of answering the question, you try to say the actual packaging is absurd. I didn't say it's absurd. I merely doubted that doing this is a good idea in general. Your specific package may well have different and non-general requirements, in which case ExecStart=sudo -u $USER_MINIDLNA -g GROUP_MINIDLNA /usr/sbin/minidlnad -S is an adequate and perfectly serviceable answer to your question. init script has the ability to change the user and this is really useful because the multimedia file are likely owned by you and in your home directory by daemon and not minidlna and why should you belong to minidlna group?... Maybe because Debian is a multiuser system AIUI, so running the daemon as a specific normal user didn't even occur to me. Sorry! But again this does not really slpit the script to configurable option that will not be overwritten when upgrading... The idea is for the package to ship a /lib/systemd/system/PACKAGE.service file which uses a generic user+group. You can then add a file /etc/systemd/system/PACKAGE.service which merely overwrites user+group settings and does not contain any other entries, in which case they'll be inherited from the file in /lib. No overwriting on update will happen. If you already do have an /etc/default/PACKAGE file, the sudo method's advantage is that you can just use an EnvironmentFile= stanza, and thus don't need to keep that and /etc/systemd/system/PACKAGE.service in sync somehow. -- -- Matthias Urlichs signature.asc Description: Digital signature
Re: init system policy
On 18/11/14 18:27, Henrique de Moraes Holschuh wrote: Failing to address this would be a severe regression, of the kind that introduces a security hole. I can see the functional regression (minidlna is running as a totally unprivileged user now, and can't read my music any more!) but not the security hole: its default user presumably has as little access as nobody, so I don't see how that's insecure? I suppose if the default configuration is more permissive than what the user has configured for a different uid to use, going back to the default configuration might be a security regression. A first option would be a way to load config data from a VAR=VALUE text file in systemd units This already exists (and I think Eric is already using it for something else), look for EnvironmentFile in systemd.exec(5)... and pass some of those vars as the value for User= / Group= ... but as far as I know, this is not implemented: the assumption is that a system service uses a fixed system user, typically either root, a well-known uid like www-data, or an unprivileged user specifically created for that service (e.g. messagebus for D-Bus). A second option is to migrate on upgrade the uid/gid information into an override in /etc/systemd/system. Requires dealing with a dynamically generated config file in preinst/postinst, though, which means the tools that help proper config file handling in maintainer scripts (ucf, and sometimes dpkg-maintscript-helper) will be of limited help. I think I'd be inclined to do this, as a one-time migration, and perhaps also document it as deprecated/discouraged: running minidlna under its own dedicated uid, and giving it read access to the media it should be allowed to read (and only those files) via setfacl or whatever, seems considerably safer than running a network-facing service under the uid of a real user who might also own private documents. 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/546b95ab.7040...@debian.org
Re: init system policy
On 18/11/2014 19:47, Matthias Urlichs wrote:
ExecStart=sudo -u $USER_MINIDLNA -g GROUP_MINIDLNA /usr/sbin/minidlnad -S
is an adequate and perfectly serviceable answer to your question.
On the other hand, the documented way to do this in systemd man pages is
to use User and Group. If the User and Group variables have been added
to unit files I naively think it was for a reason but I may be wrong.
I just mentioned that naively combining User=$TOTO or ${TOTO} TOTO being
defined in an default/package file parsed by EnvironmentFile= does not
seem to work as documented in man pages (seen the very same question
being asked on various distro mailing list without definitive answer).
Maybe because Debian is a multiuser system AIUI, so running the daemon as a
specific normal user didn't even occur to me. Sorry!
Sure but what percentage is used by a single user? And for multiple
users, to index multimedia files, you should either define a single
location and a import script or play with groups and permission..
systemd for servers systems may still have some way to go for converting
complex init scripts for firewall,openssh,VM's IMHO.
If you already do have an /etc/default/PACKAGE file, the sudo method's
advantage is that you can just use an EnvironmentFile= stanza, and thus
don't need to keep that and /etc/systemd/system/PACKAGE.service in sync
somehow.
The syntax may not always been compatible as it may use shell tricks to
define variables. I do not mind duplicating the file as only one init
system will be used at a time and transition should be the job of
package setup when default init system changes (I know some backward
compatibility is planned).
Thanks for your time.
-- eric
--
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/546b9c43.4050...@free.fr
Re: init system policy
On 18/11/14 19:21, Eric Valette wrote:
I just mentioned that naively combining User=$TOTO or ${TOTO} TOTO being
defined in an default/package file parsed by EnvironmentFile= does not
seem to work as documented in man pages
To be clear, the environment variable substitution in systemd units'
field values is not general: it only works in the fields where it is
specifically implemented, which I think is only the ExecWhatever family
of fields. That's why it's documented in the descriptions of those
fields in systemd.service(5), and not in the general information about
units, systemd.unit(5). I think the intention might be to avoid ever
getting into recursive expansion.
The %x specifiers (%u, etc.) are interpreted in rather more places than
environment variables are.
Parsing User=$TOTO as the User is the value of the environment variable
TOTO as given by Environment or EnvironmentFile might be a reasonable
feature request, but it is not currently an implemented feature.
systemd for servers systems may still have some way to go for converting
complex init scripts for firewall,openssh,VM's IMHO.
If you do need the full power of shell script, you can always keep the
LSB init script, or have a native systemd unit where the ExecWhatever
lines execute shell scripts.
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/546ba107.2010...@debian.org
Re: init system policy
Simon McVittie s...@debian.org writes: I can see the functional regression (minidlna is running as a totally unprivileged user now, and can't read my music any more!) but not the security hole: its default user presumably has as little access as nobody, so I don't see how that's insecure? The scenario I'd be concerned about is if the init script were modified to run the program as a different user that was subject to, say, a SELinux policy. Changing users back might escape additional security measures like that. Another scenario is if the default Debian user conflicted with some user on the local system that was already being used to do something else. In general, I would treat anything involving running daemons as users other than the intended user as a potential security vulnerability unless proven otherwise, given how fundamental user and group are to the entire UNIX security model. A second option is to migrate on upgrade the uid/gid information into an override in /etc/systemd/system. Requires dealing with a dynamically generated config file in preinst/postinst, though, which means the tools that help proper config file handling in maintainer scripts (ucf, and sometimes dpkg-maintscript-helper) will be of limited help. I think I'd be inclined to do this, as a one-time migration, Yeah, this seems like the right solution to me too. Drop a configuration fragment in /etc/systemd that overrides the user and group and then don't touch it again. -- 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/877fys6wqz@hope.eyrie.org
Re: Re: init system policy
Parsing User=$TOTO as the User is the value of the environment variable TOTO as given by Environment or EnvironmentFile might be a reasonable feature request, but it is not currently an implemented feature. I think anything that simplify transitioning from an init system to another new one is valuable as long as it does not breaks the original new design intention. There has been a good and valuable effort trying to split original upstream packages provided init system scripts by debian developers into /etc/default/X and /etc/init.d/X file and storing most commonly changed sysv init options in the default file part (including start or not). Wasting this work due to systemd transition would be a bad idea IMHO. Being able to reuse the sysv default config file or automate its back and forth conversion (like passwd and shadow or group and gshadow with grpck and pwck) would be helping both init system transition for debian devs and administrators that have been developing their own sysv scripts. Looking at ways to replace start-stop-daemon various parameters by corresponding unit file sequences/file layout would probably help (-g and -c are just examples for their User and Group systemd counterpart) --eric -- 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/546bb622.5000...@free.fr
Re: init system policy
Russ == Russ Allbery r...@debian.org writes: A second option is to migrate on upgrade the uid/gid information into an override in /etc/systemd/system. Requires dealing with a dynamically generated config file in preinst/postinst, though, which means the tools that help proper config file handling in maintainer scripts (ucf, and sometimes dpkg-maintscript-helper) will be of limited help. I think I'd be inclined to do this, as a one-time migration, Russ Yeah, this seems like the right solution to me too. Drop a Russ configuration fragment in /etc/systemd that overrides the user Russ and group and then don't touch it again. well, debconf seems like a win here. There's no reasonable default so it's desirable to make it easy for the admin to specify and so you'd probably want to use normal best practice for debconf updates. -- 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/0149c5dd1eb8-694ee9c8-e191-4683-8ced-987af790a4bf-000...@email.amazonses.com
Re: init system policy
Sam Hartman hartm...@debian.org writes: Russ == Russ Allbery r...@debian.org writes: Russ Yeah, this seems like the right solution to me too. Drop a Russ configuration fragment in /etc/systemd that overrides the user Russ and group and then don't touch it again. well, debconf seems like a win here. There's no reasonable default so it's desirable to make it easy for the admin to specify and so you'd probably want to use normal best practice for debconf updates. Ah, sorry, I mixed two threads. Yes, for the original author's problem, where the user should configure the user/group for the daemon, debconf makes sense. I had mixed that up with cases where people modified init scripts to run things under a different user than the default, which is a somewhat harder problem. -- 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/87d28jvr2h@hope.eyrie.org
Re: init system policy
On Tue, Nov 18, 2014 at 07:47:59PM +0100, Matthias Urlichs wrote: Your specific package may well have different and non-general requirements, in which case ExecStart=sudo -u $USER_MINIDLNA -g GROUP_MINIDLNA /usr/sbin/minidlnad -S is an adequate and perfectly serviceable answer to your question. init script has the ability to change the user and this is really useful because the multimedia file are likely owned by you and in your home directory by daemon and not minidlna and why should you belong to minidlna group?... Maybe because Debian is a multiuser system AIUI, so running the daemon as a specific normal user didn't even occur to me. Sorry! But again this does not really slpit the script to configurable option that will not be overwritten when upgrading... The idea is for the package to ship a /lib/systemd/system/PACKAGE.service file which uses a generic user+group. You can then add a file /etc/systemd/system/PACKAGE.service which merely overwrites user+group settings and does not contain any other entries, in which case they'll be inherited from the file in /lib. No overwriting on update will happen. If you already do have an /etc/default/PACKAGE file, the sudo method's advantage is that you can just use an EnvironmentFile= stanza, and thus don't need to keep that and /etc/systemd/system/PACKAGE.service in sync somehow. The disadvantage of the sudo method is that you are spawning a PAM session, which is not desirable for any service. Preferable would be to parse any existing config file for non-default user settings as part of the package upgrade and write out /etc/systemd/system/PACKAGE.service with only these non-default values, avoiding any variable substitution or sudo invocation entirely. -- 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: init system policy
Hi, Steve Langasek: The disadvantage of the sudo method is that you are spawning a PAM session, which is not desirable for any service. Ah. Thanks for the reminder; mentioning the session issue completely slipped my mind. :-/ If one does need to use a sudo intermediate to start services, the 'pam_session', 'pam_setcred', and 'use_pty' flags should be turned off, as well as sudo's internal logging. This will cause sudo to not create a PAM session, and directly exec() the daemon instead of running an intermediate fork. See man 5 sudoers for details. -- -- Matthias Urlichs signature.asc Description: Digital signature
