On 07/10/2011 05:35 PM, Matthew Garrett wrote:
On Sun, Jul 10, 2011 at 03:56:25PM -0500, Chris Adams wrote:
Once upon a time, Matthew Garrett<mj...@srcf.ucam.org> said:
The suggestion isn't that having the options is wrong
Well, that's what you said before (conveniently snipped from your
reply). You compared CLI args/env vars to the BKL as something to be
eliminated; specifically, you said (and I quoted):
In this case there are sound
technical arguments against configuration by command line argument or
environment variable
You have still failed to enumerate even one of the "sound technical
arguments".
"Configuration by", not overriding configuration. It's a mistake to have
Says you. It has seemed to work OK for the last 25+ years. I don't ever
remember having a problem
in my 25+ years of working with UNIX/LINUX with the existing initscripts. Where
are the BZ reports
that we are fixing with systemd?
your daemon's configuration be handled by a shell script that's sourced
into existing environment. It's reasonable for an admin to override
configuration on an as-needed basis.
it's that having
them as the primary means of configuration is poor design. If your
entire configuration takes the form of a shell script that constructs a
set of command line options then you've increased fragility for no
benefit. Having a proper configuration file and allowing admins to
override specific aspects of that from the command line isn't a problem.
You are moving the target (to a worst-case example) and still not
winning your argument.
The discussion was about having significant quantities of configuration
in /etc/sysconf in the form of shell fragments.
This is more than theoretical to me; a small package I maintain is one
example of a command-line configured daemon. The shmpps daemon is a
tiny little daemon that reads a timing pulse-per-second and updates a
shared memory segment. It uses a few command line arguments to set the
source port/type and shared memory segment destination; right now, that
is done for the init script by a file in /etc/sysconfig.
And that's a bad thing to do. You're sourcing your configuration in an
unsanitised environment. There's a huge number of ways that this can go
wrong depending on the admin's local configuration, which is clearly
undesirable.
This is a small, light-weight daemon, and doesn't need a configuration
file parser. This is a valid way that Unix daemons have run for
decades, and you are saying that should be removed. I guess every small
daemon now needs to include its own config file parser, replacing the
already-existing getopt() call? How is this "better"?
Nobody's said it should be removed. Lennart's said that it sucks, and I
agree. But all of this would still be better with a simple config parser
that's shared between any daemons that want it.
--
Stephen Clark
*NetWolves*
Sr. Software Engineer III
Phone: 813-579-3200
Fax: 813-882-0209
Email: steve.cl...@netwolves.com
http://www.netwolves.com
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
