Upgrading to 7.0 - stupid requirements

Chris H. chris# at 1command.com
Mon Mar 24 23:01:33 PDT 2008


Quoting Michael Gratton <michael at quuxo.com>:

> On Sat, 2008-03-22 at 20:59 -0700, Freddie Cash wrote:
>> On Sat, Mar 22, 2008 at 5:07 PM, Anders Nordby <anders at freebsd.org> wrote:
>> >  conf.d (custom configuration)
>> >  sites-available (virtualhost configuration)
>> >  sites-enabled (symlinks for enabled virtualhosts)
>> >  mods-available (available Apache modles)
>> >  mods-enabled (symlinks for enabled Apache modules)
>>
>> Oh, gods, please, no!  That is one of the things I absolutely hate
>> about Debian (and its derivatives).  There are some packages on Debian
>> where they use separate text files for each configuration option
>> (ProFTPd, for examples).  It is a huge mess of directories and files
>> that makes it a *royal* PITA to edit at the CLI.
>
> Actually, it makes two things really easy:
>
> 1. Automated installation of configuration required by other packages,
> without them all munging and potentially breaking a single, central
> config file. For example, you have Apache installed, and you want to
> install PHP, the PHP port/package drops a file with the needed config
> files into /etc/apache2/conf.d. No ad-hoc editing of httpd.conf
> required, no loss of the work you did to customise it in the first
> place.
/etc/make.conf will easily allow you to make "boilerplate" install/make
schemes already.
http[s]d.conf can always remain exactly the same. For any desired (custom)
changes, simply add
include conf/custom1.conf
include conf/custom2.conf
include conf/custom... etc... to the http[s]d.conf, and the custom
changes/additions are sucked in "magically". Apache has been like that
since the very beginning. I don't see where Linux has improved on this
at all.
>
> 2. As someone else pointed out, managing large numbers of vhosts (which
> is really just a special case of #1.
use the following line in your http[s]d.conf file
include vhost/*
and your done. Linux had nothing to do with this. You can thank NCSA
for this scheme. :)

>
>> Yes, a scheme like that is better for GUI tools, but it really makes
>> things more difficult for non-GUI users/uses (like headless servers
>> managed via SSH).
>
> It has nothing to do with GUI tools.
>
>> One of the things I *really* like about FreeBSD is that it has the
>> "one config file per app/system" setup.
>
> Until you install that one last port that breaks the config file you
> spent hours tweaking.
Again - YOU, the SA are given the control with FBSD. Simply create an
/etc/make.conf with options that will be used with ALL your boxen. Then
simply add any host specific options as required/desired. Leaving you
less to keep track of, and less opportunity for errors to creep in. :)

--Chris H

>
> /Mike
>
> --
> Michael Gratton <michael at quuxo.com>
> Quuxo Software <http://web.quuxo.com/>
>



-- 
panic: kernel trap (ignored)





More information about the freebsd-stable mailing list