Nils Philippsen wrote:
I think, when somebody wants to run a server, he has to understand how
it works and how to configure it. When admin can not figure out correct
cmdline options, how can he configure the server in a secure manner?
Along that line, everybody should be able to run configure && make &&
make install and wrap their own packages, so why should we bother ;-)?
Seriously, I can cope with command line arguments and still like
sysconfig files that are more understandable than just plain
"OPTS='--foo -x=y -a'". I'm happy if I get things done without having to
read the documentation for the common case. I'm not saying admins
shouldn't be able to influence the cmd line options directly if they
wish.
If you change that to some abstraction that you think is easier to
understand, how do you propose (a) that sysadmins that already knew the
real options should deal with the now confusing abstraction
E.g. like with the old /etc/sysconfig/hdparm, you could use "speaking
options" but have an "HDPARM_OPTS" variable (or some name like that)
which would just passed on the command line.
And how is someone supposed to know that?
and (b) that
the abstraction (and its documentation) always stays in sync with
upstream changes/additions to the underlying program's options? It is
already fairly messy trying to track what options have been moved to new
locations under /etc/sysconfig in fedora/RH boxes and which are still in
their normal locations.
That's the job of the maintainer of the concerned package: to ensure
that sysconfig options he introduced get mapped to the correct set of
command line arguments. If those change, the mapping has to change.
I think you are missing my point. I run an operating system in order to
run programs I add myself, some of which supply init scripts which I
expect to continue to run from one version to the next with no or minor
changes. Changing the way a sysv-like init service runs would be sort
of like the C language changing its keywords. Changing the
system-supplied scripts to do things more efficiently is one thing;
breaking expected system behavior is something else.
--
Les Mikesell
lesmikesell@xxxxxxxxx
--
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list
