 |
Configure and Run a Commercial Mod Perl Apache Web Server on Fedora Core - Tutorial
[UNDER DEVELOPMENT - ROUGH DRAFT - please excuse]
Starting with the Mod Perl Apache Web Server included in a full Fedora Core 3 installation.
This guide will cover some initial steps to configure and run the Mod Perl Apache web server included with the Fedora Core Linux operating system,
for commercial/production use. This tutorial uses Fedora Core 3 and the bundled Apache 2.0.53, mod_perl 1.99_16 setup. The approach is to
make the least amount of change to this Fedora configuration. The benefit being, to make it easier to upgrade Fedora versions and maintain Fedora
independently of your web operations. This will help to make Mod Perl Apache use on Fedora as simple and clean as possible.
There will be another tutorial on converting any Linux Operating System over to use a 'Classic' Apache Installation instead of it's own implementation.
Under certain criteria, this would be the preferred approach. What we refer to when we say a 'Classic Apache Installation' is the traditional
one you might find on a Solaris (UNIX) or FreeBSD web server in which almost everything for
Apache, modules, configuration, content and code is located within a directory structure rooted at /usr/local/apache.
As you will find in a lot of Linux distributions, there are some disadvantages to deviating from the classic Apache file locations - but as you can see
in the current tutorial, they are workable and you do end up with the OS/package maintenence benefit of working with the bundled setup.
Although a full server installation with nearly all packages was used for this tutorial, a true production configuration would only have the minimum
of required packages and the minimum of required dependencies installed.
Minimizing and optimizing the entire system for a production server is a substantial process, one deserving of it's own set of tutorials.
For the time being, just using the Fedora Core 3 Full Installation and starting out with all packages, helps one learn about the latest technologies on
Linux and also, you are less likely to run into any dependency problems. Most people are going to have the disk space, and until
you are ready for a lean, mean performance configuration, there is no significant downside to simply installing everything in this Linux distribution.
Specific Platform/Software Versions Used for the Writing of this Tutorial
- Fedora Core 3 - Full server installation with all packages.
- Linux Version/Kernel: 2.6.12-1.1381_FC3 (gcc version 3.4.4 20050721 (Red Hat 3.4.4-2))
- Apache 2.0.53 (Fedora) - Fedora file locations preserved in this tutorial.
- mod_perl/1.99_16 (Embedded Perl Version 5.8.5)
Default Configuration of the Apache Installation Included in Fedora Core
Before changing too many things let's go over how Apache is initally set up in an out of the box Fedora configuration.
Locations of Key Files
The Fedora Core Apache file locations are very similar to past Red Hat Linux Apache locations, however these are quite different from the locations
seen in a 'classic' Apache installation. The Fedora scheme puts Apache conf under /etc where most linux and application configuration files live and
Apache logs under /var/log where most linux and application logs reside.
Configuration Files under /etc/httpd
Apache configuration files in the apache conf directory are located here. Also note 2 symlinks, one redirecting a logs directory to /var/log/httpd and
another redirecting a modules directory to /usr/lib/httpd/modules.
|
/etc/httpd
/etc/httpd/conf
/etc/httpd/conf.d
/etc/httpd/logs -> ../../var/log/httpd
/etc/httpd/modules -> ../../usr/lib/httpd/modules
|
Configuring the Linux Environment for Effective Production Use of Apache
Create a 'web' group and 'webadmin' user for dedicated access to Apache areas and to control Apache - Replacing root owner and group
Create a 'web' group to which we will add our primary web user 'webadmin' for convenience and security. This group and thus a member like
'webadmin' will have access to some of the areas like the HTML folder structure and configuration directory of Apache. The default
Apache installation which comes with Fedora has root as the owner and group for all of the Apache directories. This is not very convenient
and it is insecure to use the root account for the regular operation of the web server. Also, in a production environment you will often
have different people responsible for the operating system and root access than the people responsible for running and configuring apache.
Now add the new web group, and then add our first and principal web administrative user, 'webadmin' to the new web group. The webadmin user
will be the owner of all files and directories in the Apache, content and other web production areas for consistency. As we mentioned, we don't want the
out of the box configuration which has root as the owner the Apache directories. You will later add the logins of your web team members and it is
up to you whether or not they share the same permissions as the principal webadmin user. In a later tutorial we will discuss in greater detail, a more diverse web
group and permissions scheme for a larger production environment as you might see in a major dot com, but this initial setup with a single web group
is quit sufficient for even large operations as well.
|
[root@seven webadmin]groupadd web
[root@seven webadmin]vi /etc/group
The last line which will be the new web group
with the webadmin user added should look like this:
web:x:501:webadmin
Variations are possible. If other groups
have already been created, then you will see a different number than 501.
Later with many human and perhaps automated users in the group
it could look like this:
web:x:508:webadmin,jennyc,mikek,autowebcontentpush,webcontractor
|
Relevant entries from the Group file: /etc/group
The complete /etc/group file has some 47 entries/groups on a fresh Fedora Core 3 server installation.
What is shown at right are just the groups relevant to web development and managing this web server.
At least one user account's group is shown, 'webadmin' - the first, and in this example, only
user account's group created on this machine. The last line shows the new web group we have just added.
|
root:x:0:root
apache:x:48:
nobody:x:99:
webadmin:x:500:
web:x:501:webadmin
|
-= CONTENT UNDER DEVELOPENT =-
CAUSE THE CORRECT GROUP OWNERSHIP TO BE SET UPON NEWLY CREATED FILES AND DIRECTORIES (BY THE WEB USERS)
Make WEB the default/primary group for your primary web user, webadmin.
Repeat this for all user members of the web group so no one web user ends up creating
files or directories which other people cannot modify or move.
Do this with a user utility or by editing /etc/passwd and changing the 3rd field,
which is the second mumber, commonly 500, to the group number for the new web group,
under common circumstances this might mean changing the second 500 to 501.
/etc/passwd default entry for user webadmin:
webadmin:x:500:500:WebAdmin:/home/webadmin:/bin/bash
after changing the default group from webadmin user's group to web:
webadmin:x:500:501:WebAdmin:/home/webadmin:/bin/bash
REMEBER: The first number (3rd field) in /etc/passwd is the user's id,
and the second mumber (4th field) is the user's default/primary group.
CAUSE THE CORRECT PERMISSIONS TO BE SET UPON NEWLY CREATED FILES AND DIRECTORYS (BY THE WEB USERS)
Edit .bashrc adding:
umask 002
This sets a default permission so that files created via a shell will have permissions as thus:
files: -rw-rw-r-- (664) and
directories: drwxrwxr-x (775)
WARNING: The default .bashrc with Fedora Core 3 also sources (executes) the global /etc/.bashrc
which sets a umask of either 002 or 022 depending on whether or not the shell is interactive.
(** CLARIFY THE PREVIOUS STATEMENT)
MAKE SURE to place your umask 002 AFTER the sourcing of /etc/.bashrc so that your
002 is invoked last and thus overrides anything else coming from the global .bashrc.
GET A BASIC (albeit insecure) FTP SERVER UP QUICKLY ANS CONFIGURED FOR WEB TEAM USE
Edit /etc/xinetd.d/gssftp and add the server arg option of -u 002
This is the most important step since this affects the default permissions of all
files and directories which users will transfer via ftp (gssftp).
ON A SIDE NOTE - you probably did not want the kerberos (default) authentication
of gssftp as it is bundled in FC3, and to use standard ftp clients you will need to
have removed the server argument -a to get back to 'normal' ftp authentication,
as insecure as that may be - it's probably all you need to get running for now.
In a production or secure environment you should not be using 'regular' ftp
with it's passwords exposed in plain text. For security us scftp or get an ftp client
which can use the kerberos authentication invoked with gssftp's -a option.
COMING SOON - IMPLEMENTING SECURE FILE TRANSFERS - ELIMINATE INSECURE FTP SERVICE
Of course, the web team members are alreading using SSH for terminal access as plain
old telnet is just like plain old ftp in that it transmits usernames and passwords across
the network in easily-sniffable plain text during the authentication phase.
(** HOW WAS SSH SERVER OUT OF THE BOX? Review what config was necessary on this FC3)
|
 |
