When you're installing a software package
you have the install script writer has
a choice - whether to put it all in one place so that you can easily remove it again if it doesn't work for you, or whether to spread the elements far and wide so that each element is on an area of the disc which has an appropriate backup strategy and ownership. And the choice isn't a clear one - neither way of doing it is right or wrong - both are imperfect.
Most of us install much more software than we end up actually using, and the ability to try something out with the knowledge that we can remove it very easily if it doesn't work out is attractive - and that "install in one place" philosophy is the approach taken by the Open Source community. If something that you've put into /usr/local works out for you, it's not a big deal to move the start-up script into /etc/init.d and add a couple of links from /etc/rc3.d or /etc/rc5.d, nor to move the dynamic data area to some other area of the file system where it will be regularly backed up.
But even that moving of a few elements around may be more than the home user, wanting a minimal of computer knowledge, is prepared (or indeed able) to do, and that's where the Microsoft / packaged and with install wizzards to wave a wand and throw things into lots of places comes in - and is perhaps well suited for that market.
Here's a top level directory listing of a recently installed Apache httpd; the subdirectories will be similar for other open source installs, and if you're making your install permanent, this is the area where you'll want to (a) move a few things around and (b) change your configuration files so that the software 'knows' you have done so.
What have we in this directory?
bin, build, lib, include
should be left where they are - they are the programs associated with the installation, and all the extra bits of rarely-changing stuff that is brought in at run time. If you add modules such as jk
(yes, PHP loads as a module), they will be in the modules
subdirectory, for example.
You probably don't want to move conf
although logically it might go into the /etc directory; it contains the configuration information for the software installed, and should be changed only rarely and only by the administrator - so having it in this well protected, read mostly, rarely backed up area is sensible.
This example is a web server - and so the data at the initial install is the data for the web site that its supports. And the default location is htdocs
, with standard icons for automatic indexes in icons
and the httpd manual in manual
. The htdocs should - for sure - be moved (or, better a new one created elsewhere) and the config file /usr/local/apache2/conf/httpd.conf [default] changed to reflect the change at two places in the file, please note!
should be left where they are, as you'll surely not be changing the icons nor altering the Apache manual, will you?
Programs that the web server can run (if and only if the facility has been switched on -
- off by default) are in the cgi-bin
directory, and you really should create a new one of those, and point your configuration file at it, if you're using the facility. It's usual to place the new cgi-bin directory as a sibling of the new htdocs, so that the changing web site (as looked after by a web site developer) is all in one neat bundle for backups / copies / looking after.
Finally, logging is to the logs
directory. It's possible for you to choose to leave this where it is (but please add a crontab job to move the log file to an archive and start a new one every so often). You could also move it to a separate log are - /var/logs or /var/spool seem sensible places. And the third popular choice is to move the logs to another sibling of the new cgi-bin and htdocs, allowing the developer / web site maintainer direct access to them. On a major productions system, /var/summat is probably favoured; for something not quite so major, the sibling approach would be preferred. But it's very much a decision you should make based on the balance and use of the web server.
This subject is covered in some detail on our Linux Web Server
course, and at a lesser level on our Deploying Apache httpd and Tomcat
course, where the main topic is Tomcat which almost always sits behind a relatively lightly configured httpd. (written 2009-03-22)
Associated topics are indexed as below, or enter http://melksh.am/nnnn for individual articlesA602 - Web Application Deployment - Apache httpd - Sourcing, Installation, Testing 
Apache httpd release 2.2 - (2005-12-10) 
Apache httpd - serving web documents from different directories - (2005-12-12) 
2006 - Making business a pleasure - (2006-01-01) 
Stopping and restarting Apache httpd cleanly - (2006-03-29) 
Browser -> httpd -> Tomcat -> MySQL. Restarting. - (2006-10-28) 
Notes from the white board - (2006-12-14) 
Apache httpd , browser, MySQL and MySQL client downloads - (2007-02-28) 
DHCP automatic IP address v Static IP - (2007-08-06) 
Upgrade Mac OSX to Leopard, Web Server Apache httpd config lost - (2007-11-29) 
Connecting to MySQL 5 from PHP on Mac OSX Leopard - (2007-12-03) 
Configuring Apache httpd - (2008-07-12) 
Apache httpd, MySQL, PHP - installation procedure - (2008-08-01) 
What is built in to this httpd and PHP? - (2008-08-23) 
Summary - Apache httpd build on Linux - (2008-12-14) 
Using ApacheBench and jconsole to test and monitor Tomcat - (2009-03-14) 
Choosing the right version of Java and Tomcat - (2009-05-16) 
Global and Enable - two misused words! - (2009-11-30) 
Automed web site testing scripted in Ruby using watir-webdriver - (2011-09-09) 
Adding a PHP build option, rotating an image based on camera data, and a new look at thumbnails in PHP - (2015-02-22)
Some other Articles