There are many different roles associated with setting up and running a web site and it's unlikely that they'll all be undertaken by the same person.
• Server administrator
• Web site developer
• Web site administrator
• Web site user
And each of them has their own areas of authority, areas when they can just read data, areas where they should not (or cannot) go. It's all controlled by accounts and accesses ...
On a Linux or Unix system, the server administrator
should have his/her own set of directories and user account in which to store, analyse and do most of his/her work. For example, building new versions of Apache and PHP, and holding an inventory of standard packages used, isn't something that requires a godlike access. Indeed it's a good idea not to have godlike access for these tasks, simply because any errors made will be constrained to this user's backroom directories.
The web site administrator
will also have his/her own user account, again with a set of directories in which to store, analyse and work on data files, logs, web site updates and backup copies and so on. The web site user's account will probably (but there are alternatives) also own the various web site directories - the "htdocs" and "cgi-bin", probably a data directory that's a sibling of them, and possibly a log file directory (the who and where of this latter will vary depending on the organisation's division of roles and trust).
The Web site developer
may... or may not... have an account on the live server. If (s)he has an account, it's very likely to be similar to the web site administrator's, except that it will be for a web site of a different name - a different virtual host
on which development and testing take place. Updates to the live server will probably be done by the web site administrator, with the developer passing over a series of fully tested files, probably tari
red or packaged to ensure that they go in cleanly and all within a few seconds.
Web site users
don't have their own accounts on the server computer (at an operating system level). They may very well have user accounts within the software that's running within the Apache web server but that's a different matter.
There are two further accounts you should be aware of if you're responsible for a web server.
Firstly, the "godlike" account I referred to that the server admin needs when he's playing God
. It's known as "root" and the substitute user command is used to access it:
and that requires the root password. Cautions - (a) minimal work should be done as root - only go there is needed, (b) always use the "-" option; without out it, you become root but without
the protection of root's environment settings, and (c) always exit
from root when you're done:
If you keep using su
, which stands for substitute user, without exiting, you'll build up a whole pile of shells that you're working through all the time. Messy and potentially slowing if you do it a lot one day!
Secondly, the running web server itself will have a user account (called a daemon
account) under which it provides the web service, and runs any programs that the web site user calls up. On a defaut Apache httpd install, this account is actually called "daemon", but one of the early exercises we do on our Linux Wer Server Course
is to change that into its own separate account - we typically use www-data
as that account's usually set up already. By running the web server in its own separate account, we're restricting the areas of damage if something goes dramatically wrong, and reducing the chance of security leakage between accounts. [[ "Daemons" are explained [here]
Something has to be done to enable the web server daemon account to be able to read the files it has to serve. You could rely on setting "other" permissions to read, but that would mean that anyone logged in to the server with a user account could read those files directly, so it's weak security wise. What's usually done instead is to put the web server dameon and the web site administrator into the same group
, and provide access to the web server via group permissions. Again, the group defaults to daemon
, but we change it during the course to www-data
or something similar such as apache
. Then web document files may look like this:
-rw-r----- 1 wellho apache 46553 2013-03-07 09:23 rl.html
-rw-rw---- 1 wellho apache 111818 2013-03-16 10:15 rlfull.txt
With the first of those files being readable and writable by the web site administrator, but being read-only as far as the wed server is concerned. That's much the most common file setting for web site files! The second example is a web site file which the server is allowed to write back to; developers and web site admins should think very carefully before doing this to any file in the web server's document tree - it's much better to use the sibling data directory I referred to earlier on as this avoids the changeable file having its own web URL.
How is the Web Server configured?
System Admin and Web Site Admin Configuration files
There's a file called httpd.conf
which may be found in the conf/
subdirectory of the web server program / setup (that's its default place), and that file includes all the setups that are made and looked after by the server administrator. That file commonly contains Include
directives to bring in separate configuration bundles for features such as virtual hosts, server status monitoring, and PHP.
At times, the server administrator may be happy to delegate some configuration matters to the web site administrator and (s)he can do this by switching on overrides for part (or all) of the site (or sites) hosted. The command in the httpd.conf file that you're looking for is
There may be several such commands - they'll be within a <Directory> to </Directory> pair to say where they apply, and there are intermediate alteratives between "None" and "All" too - described in comments in the configuration file. When the server administrator changes the httpd.conf file or its children, the web server daemon must be stopped and restarted for the changes to take effect.
the server administrator has given delegated powers to the web site administrator, those powers may be used to add configuration directives in a file called .htaccess
in the document root directory of the web site (if the overrides are to cover the whole site) or in subdirectories thereof if there are to be configuration changes that apply only to certain subtrees. The .htaccess files are read each time a page is served
, so there is no need for the web site admin to ask the server admin to restart the server when a change is made.
This lot's all very neat, works well, divvies out the tasks nicely - which is probably one of the reasons that Apache httpd serves some 70% of the domains worldwide. When you set it up for the first time, this account business is just one of a lot of things you'll need to learn about - please take a look at our Deploying LAMP (Linux, Apache, MySQL and PHP) course
as that will help you get up and running very quickly, and will ensure that you're trained to set up a robust and easily maintained web server configuration. (written 2013-03-16, updated 2013-03-31)
Associated topics are indexed as below, or enter http://melksh.am/nnnn for individual articlesA161 - Web Application Deployment - Users and Groups 
su or su - ... what is the difference? - (2010-02-17) 
Root is root for a reason! - (2009-11-03) 
Mistaken identity? - (2009-07-22) 
Always use su with minus. And where do programs come from? - (2009-05-27) 
Choosing a railway station fairly in PHP - (2009-04-04) 
Ask the Tutor - Open Source forum - (2009-03-25) 
Ruby, Perl, Linux, MySQL - some training notes - (2008-11-23) 
sstrwxrwxrwx - Unix and Linux file permissions - (2008-11-23) 
The Longest Possible Day - (2008-08-26) 
Looking for files with certain characteristics (Linux / Unix) - (2008-05-22) 
User and Group settings for Apache httpd web server - (2008-04-22) 
Setting up a new user - Linux or Unix - (2008-03-26) 
Supporting users on Linux and Unix - (2006-04-13) 
File permissions of Linux and Unix systems - (2005-08-31) 
Functions and commands with dangerous names - (2005-08-11)
Some other Articles
Business meetings in Melksham - Well House ManorArt, Catering, Transport - Melksham Campus Elements - reaching local expertsLooking for Creative Design, Catering and Transport inputs to help with Melksham CampusOver a hundred welcoming businesses - Melksham Town CentreLinux Web Server - User Roles, User Accounts, and shared administrationWhat to do on a wet weekend in Melksham?Bus stop audit - what is missing?Bright Spring MorningReport on the last year - Melksham Chamber of Commerce and Industry for Melksham Without Parish CouncilReport on the last year - Melksham Railway Developement Group for Melksham Without Parish Council