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(a)gmail.com