[olug] linux web server management ?

[William E. Kempf]

Sam Tetherow said:
> William E. Kempf wrote:
>> Eric Penne said:
>>
>>>Debian is very easy.  All of the problems I've ever had with a debian
>>> install were because I didn't have any good floppy disks.
>>>
>>>Apt has front ends like ncurses based aptitude and GUI "forgot the
>>> name but I used it last night".  Software install could not be any
>>> easier.
>>>
>>>Here is what I do now.  I install a base debian system.  then from the
>>> command line I type in the program I want to install.  I run a static
>>> webserver on one so the first command I run from the base system is:
>>>
>>>apt-get install apache
>>>
>>>This grabs all dependencies and installs them.  Have you tried to do
>>> something similar with one command from the command line in any other
>>> distro?  It brings on fits of rage.
>>
>>
>> With out getting into religious distro wars, I do the same on Mandrake
>> with URPMI... and mostly do the same on RedHat with apt-rpm (though
>> finding a repository is difficult).  My understanding is that you do
>> the same with portage on Gentoo as well (though that system actually
>> compiles from source during installs).  But there are still issues,
>> ranging from "does this arcane tool I need have a package for my
>> distro" to "how the @$@%#@ do I configure this beast once it's
>> installed".
>
> If the package was done properly under debian, this is handled with
> debconf which will prompt you for values you must supply and give
> defaults where appropriate.

I'm not familiar with Debian or debconf in particular.  Does debconf
provide a full interface for managing configuration information?  In other
words, can I use it over and over to tweak an application's configuration,
with full access to all configurable options?  If so, that's the sort of
solution I think is necessary, but it has to be portable (i.e. I should be
able to _easily_ use it on my Mandrake box) and should be based on
standard interfaces, rather than hacked code for every package.  With a
good set of standards you could provide a generic utility for configuring
packages that don't supply a more robust utility.

>>>Another machine is a fileserver with samba.  From the base system:
>>>
>>>apt-get install samba
>>>
>>>That's it!!!!  Instant dedicated system!  So wonderfully easy I could
>>> almost wet myself.
>>>
>>>Debian is not hard to install it is just intimidating to think about.
>>> In reality though, debian is easy.
>>>
>>>Debian also comes with Webmin.
>>>
>>>apt-get install webmin
>>>
>>>Dude, Dell's are even this easy.
>>>
>>>A graphical installer would be nicer yet.  Just to reduce the
>>>intimidation factor.
>>
>>
>> Actually, to allow easier use of "non-vanilla" installs.  For things
>> like, say, installing to a non-standard location because I either
>> don't have rights to install to the standard location or I want to
>> have multiple versions installed at the same time.  Some package
>> management systems allow you to do this, some don't, but it's not
>> "intuitive" even for those that do.
>
> Well, you can always take the Windows way of doing things and either
> hope it works or bomb if you don't have the permission ;)

Excuse me?!?  The "Windows way" is to ask the user, providing standard
defaults, and if the user specifies something for which he doesn't have
permissions there's absolutely nothing wrong with bombing out (and in
fact, that's the only thing you can do).  What the heck else would you
suggest get done?  This is precisely what Linux packages do today... other
than the user friendly prompting.

> In all honesty this would require some changes both in the distro and in
>  the software itself.  Most things check in $HOME/.{pkg} for a user
> level  configuration file, but moving the 'system' configuration file
> means you  need to be able to write to some system wide directory so the
> application knows where to look to figure out where it's REAL config
> file is (at which point why not just put the config file there) or the
> binary would need to be modified at install to know where to look for
> the configuration file which would imply a recompile.

One file, living side by side with the installed executable, that pointed
towards the configuration area being used, would be all that would be
required.  Trivial to implement, and non-intrusive to the end user or the
environment.

Or you can even limit the "registry areas" to known locations. 
/etc/config for applications installed on a system wide basis, and
$HOME/config for applications installed on a user only basis (possibly
throwing in /usr/config for non-system, but globally available
installations).  Then the software has known locations to search for the
config files, and can do so in a standard order.

Better yet, with standards established you can present APIs for accessing
configuration information, removing this burden entirely from individual
applications.  In other words, from a developer's stand point the Win32
Registry API is a god send, even if the monolothic binary registry file is
obviously a mistake that Linux wouldn't need to repeat to get the benefits
of a standard configuration mechanism.

William E. Kempf