Home Accessibility Courses Twitter The Mouth Facebook Resources Site Map About Us Contact
 
For 2023 (and 2024 ...) - we are now fully retired from IT training.
We have made many, many friends over 25 years of teaching about Python, Tcl, Perl, PHP, Lua, Java, C and C++ - and MySQL, Linux and Solaris/SunOS too. Our training notes are now very much out of date, but due to upward compatability most of our examples remain operational and even relevant ad you are welcome to make us if them "as seen" and at your own risk.

Lisa and I (Graham) now live in what was our training centre in Melksham - happy to meet with former delegates here - but do check ahead before coming round. We are far from inactive - rather, enjoying the times that we are retired but still healthy enough in mind and body to be active!

I am also active in many other area and still look after a lot of web sites - you can find an index ((here))
Linux Web Server - User Roles, User Accounts, and shared administration

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 tarired 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:
  su -
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:
  exit
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 or apache 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
AllowOverrides None
or
AllowOverrides All
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.

If 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 articles
A161 - Web Application Deployment - Users and Groups
  [409] Functions and commands with dangerous names - (2005-08-11)
  [431] File permissions of Linux and Unix systems - (2005-08-31)
  [683] Supporting users on Linux and Unix - (2006-04-13)
  [1592] Setting up a new user - Linux or Unix - (2008-03-26)
  [1619] User and Group settings for Apache httpd web server - (2008-04-22)
  [1650] Looking for files with certain characteristics (Linux / Unix) - (2008-05-22)
  [1773] The Longest Possible Day - (2008-08-26)
  [1902] sstrwxrwxrwx - Unix and Linux file permissions - (2008-11-23)
  [1904] Ruby, Perl, Linux, MySQL - some training notes - (2008-11-23)
  [2103] Ask the Tutor - Open Source forum - (2009-03-25)
  [2117] Choosing a railway station fairly in PHP - (2009-04-04)
  [2203] Always use su with minus. And where do programs come from? - (2009-05-27)
  [2301] Mistaken identity? - (2009-07-22)
  [2491] Root is root for a reason! - (2009-11-03)
  [2639] su or su - ... what is the difference? - (2010-02-17)


Back to
What to do on a wet weekend in Melksham?
Previous and next
or
Horse's mouth home
Forward to
Over a hundred welcoming businesses - Melksham Town Centre
Some other Articles
Business meetings in Melksham - Well House Manor
Art, Catering, Transport - Melksham Campus Elements - reaching local experts
Looking for Creative Design, Catering and Transport inputs to help with Melksham Campus
Over a hundred welcoming businesses - Melksham Town Centre
Linux Web Server - User Roles, User Accounts, and shared administration
What to do on a wet weekend in Melksham?
Bus stop audit - what is missing?
Bright Spring Morning
Report on the last year - Melksham Chamber of Commerce and Industry for Melksham Without Parish Council
Report on the last year - Melksham Railway Developement Group for Melksham Without Parish Council
4759 posts, page by page
Link to page ... 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31, 32, 33, 34, 35, 36, 37, 38, 39, 40, 41, 42, 43, 44, 45, 46, 47, 48, 49, 50, 51, 52, 53, 54, 55, 56, 57, 58, 59, 60, 61, 62, 63, 64, 65, 66, 67, 68, 69, 70, 71, 72, 73, 74, 75, 76, 77, 78, 79, 80, 81, 82, 83, 84, 85, 86, 87, 88, 89, 90, 91, 92, 93, 94, 95, 96 at 50 posts per page


This is a page archived from The Horse's Mouth at http://www.wellho.net/horse/ - the diary and writings of Graham Ellis. Every attempt was made to provide current information at the time the page was written, but things do move forward in our business - new software releases, price changes, new techniques. Please check back via our main site for current courses, prices, versions, etc - any mention of a price in "The Horse's Mouth" cannot be taken as an offer to supply at that price.

Link to Ezine home page (for reading).
Link to Blogging home page (to add comments).

You can Add a comment or ranking to this page

© WELL HOUSE CONSULTANTS LTD., 2024: 48 Spa Road • Melksham, Wiltshire • United Kingdom • SN12 7NY
PH: 01144 1225 708225 • EMAIL: info@wellho.net • WEB: http://www.wellho.net • SKYPE: wellho

PAGE: http://www.wellho.net/mouth/4045_Lin ... ation.html • PAGE BUILT: Sun Oct 11 16:07:41 2020 • BUILD SYSTEM: JelliaJamb