Philip Hands 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
The Wanderer 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
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 ;-
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 writes:
> On 21/11/14 17:07, Philip Hand
Matthias Urlichs 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 programmati
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 symlink
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 bli
Ian Jackson writes:
> Philip Hands writes ("Re: init system policy"):
>> Ian Jackson writes:
>> > I don't know how much etckeeper users use modifying (rather than
>> > recording) git operations, but I can imagine that this approach might
>> >
Simon McVittie 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
> "enabledn
Philip Hands writes ("Re: init system policy"):
> Ian Jackson 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 fig
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
> definitiv
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
> o
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 s
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
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 e
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,
Stephan Seitz 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
Ian Jackson 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 cou
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
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
> directori
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
Quoting Ansgar Burchardt (2014-11-21 09:59:39)
> Jonas Smedegaard 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
>> 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 t
Hi,
Jonas Smedegaard 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
On Thu, Nov 20, 2014 at 8:28 AM, Russ Allbery wrote:
> Jonas Smedegaard 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
Matthias Klumpp writes:
> 2014-11-20 17:44 GMT+01:00 Jonas Smedegaard :
>> Quoting Matthias Klumpp (2014-11-20 17:15:50)
>>> 2014-11-20 16:12 GMT+01:00 Jonas Smedegaard :
>>> > Quoting Vincent Danjean (2014-11-20 14:25:59)
>>> >> Hi,
>>> >>
>>> >> On 18/11/2014 18:36, Ansgar Burchardt wrote:
>>
2014-11-20 17:44 GMT+01:00 Jonas Smedegaard :
> Quoting Matthias Klumpp (2014-11-20 17:15:50)
>> 2014-11-20 16:12 GMT+01:00 Jonas Smedegaard :
>> > 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
Quoting Russ Allbery (2014-11-20 17:28:28)
> Jonas Smedegaard 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
>>
Quoting Matthias Klumpp (2014-11-20 17:15:50)
> 2014-11-20 16:12 GMT+01:00 Jonas Smedegaard :
> > 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 an
Jonas Smedegaard 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
2014-11-20 16:12 GMT+01:00 Jonas Smedegaard :
> 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 exa
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=So
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"
> 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-direc
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)
> |
> | [
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_MINI
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 (
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 unf
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
> 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 :-)
--
❦ 19 novembre 2014 08:45 +0100, Matthias Urlichs :
>> 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 u
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, t
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 a
Sam Hartman writes:
>> "Russ" == Russ Allbery 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
> "Russ" == Russ Allbery 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 pr
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
Simon McVittie 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 scenar
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'
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 th
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
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
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
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:
+---
| [
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
|
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 habil
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 o
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 configur
Hi,
[ redirecting to debian-devel, as -policy isn't the correct list for this IMHO ]
Eric Valette:
>
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 compl
58 matches
Mail list logo
