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: 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
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: 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: 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 /) 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: 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
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: Re: init system policy
Eric Valette 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
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
> 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
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
