On Mon, 2008-01-07 at 11:49 -0600, Les Mikesell wrote:
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 (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.
Nils
--
Nils Philippsen / Red Hat / nphilipp(a)redhat.com
"Those who would give up Essential Liberty to purchase a little Temporary
Safety, deserve neither Liberty nor Safety." -- B. Franklin, 1759
PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011