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'
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
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
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 ;-) )
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
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
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
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
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
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
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,
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
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
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,
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
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 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
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
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
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
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
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
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
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
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]
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,
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
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
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
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
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
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
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
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,
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
❦ 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
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 :-)
--
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
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
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
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
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
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.
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
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
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 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:
+---
|
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.
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
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
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
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'
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?
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
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
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
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
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
58 matches
Mail list logo
