556 lines
31 KiB
HTML
556 lines
31 KiB
HTML
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
|
|
<HTML>
|
|
<HEAD>
|
|
<META NAME="GENERATOR" CONTENT="SGML-Tools 1.0.9">
|
|
<TITLE>Linux WWW HOWTO : Apache</TITLE>
|
|
<LINK HREF="WWW-HOWTO-8.html" REL=next>
|
|
<LINK HREF="WWW-HOWTO-6.html" REL=previous>
|
|
<LINK HREF="WWW-HOWTO.html#toc7" REL=contents>
|
|
</HEAD>
|
|
<BODY>
|
|
<A HREF="WWW-HOWTO-8.html">Next</A>
|
|
<A HREF="WWW-HOWTO-6.html">Previous</A>
|
|
<A HREF="WWW-HOWTO.html#toc7">Contents</A>
|
|
<HR>
|
|
<H2><A NAME="apache"></A> <A NAME="s7">7. Apache</A></H2>
|
|
|
|
<P>The current version of Apache is 1.2.4. Version 1.3 is in beta testing.
|
|
The main Apache site is at
|
|
<A HREF="http://www.apache.org/">http://www.apache.org/</A>. Another good source of information is
|
|
Apacheweek at
|
|
<A HREF="http://www.apacheweek.com/">http://www.apacheweek.com/</A>.
|
|
The Apache documentation is ok, so I'm not going to go into detail in setting
|
|
up apache. The documentation is on the website and is
|
|
included with the source (in HTML format). There are also text files
|
|
included with the source, but the HTML version is better. The documentation
|
|
should get a whole lot better once the Apache Documentation Project gets
|
|
under way. Right now most of the documents are written by the developers.
|
|
Not to discredit the developers, but they are a little hard to understand
|
|
if you don't know the terminology.
|
|
<P>
|
|
<H2><A NAME="ss7.1">7.1 Where to get</A>
|
|
</H2>
|
|
|
|
<P>Apache is included in the Red Hat, Slackware, and OpenLinux distributions.
|
|
Although they may not be the latest version, they are very reliable
|
|
binaries. The bad news is you will have to live with their directory
|
|
choices (which are totally different from each other and the Apache defaults).
|
|
<P>The source is available from the Apache web site at
|
|
<A HREF="http://www.apache.org/dist/">http://www.apache.org/dist/</A>
|
|
Binaries are are also available at apache at the same place.
|
|
You can also get binaries from sunsite at
|
|
<A HREF="ftp://sunsite.unc.edu/pub/Linux/apps/www/servers/">ftp://sunsite.unc.edu/pub/Linux/apps/www/servers/</A>.
|
|
And for those of us running Red Hat the latest binary RPM file can usually
|
|
be found in the contrib directory at
|
|
<A HREF="ftp://ftp.redhat.com/pub/contrib/i386/">ftp://ftp.redhat.com/pub/contrib/i386/</A><P>If your server is going to be used for commercial purposes, it is highly
|
|
recommended that you get the source from the Apache website and compile it
|
|
yourself. The other option is to use a binary that comes with a major
|
|
distribution. For example Slackware, Red Hat, or OpenLinux distributions. The
|
|
main reason for this is security. An unknown binary could have a back door for
|
|
hackers, or an unstable patch that could crash your system. This also gives
|
|
you more control over what modules are compiled in, and allows you to set
|
|
the default directories. It's not that difficult to compile Apache, and
|
|
besides you not a real Linux user until you compile your own programs ;)
|
|
<P>
|
|
<P>
|
|
<H2><A NAME="ss7.2">7.2 Compiling and Installing</A>
|
|
</H2>
|
|
|
|
<P>First untar the archive to a temporary directory. Next change to the src
|
|
directory. Then edit the Configuration file if you want to include any special
|
|
modules. The most
|
|
commonly used modules are already included. There is no need to change the
|
|
rules or makefile stuff for Linux. Next run the Configure shell script
|
|
(<CODE>./Configure</CODE>). Make sure it says Linux platform and gcc as the compiler.
|
|
Next you may want to edit the httpd.h file to change the default directories.
|
|
The server home (where the config files are kept) default is
|
|
<CODE>/usr/local/etc/httpd/</CODE>, but you may want to change
|
|
it to just <CODE>/etc/httpd/</CODE>. And the server root (where the HTML pages are
|
|
served from) default is
|
|
<CODE>/usr/local/etc/httpd/htdocs/</CODE>, but I like the directory
|
|
<CODE>/home/httpd/html</CODE> (the
|
|
Red Hat default for Apache). If you are going to be using su-exec (see
|
|
special features below) you
|
|
may want to change that directory too. The server root can also be changed from the
|
|
config files too. But it is also good to compile it in, just encase Apache
|
|
can't find or read the config file. Everything else should be changed
|
|
from the config files.
|
|
Finally run make to compile Apache.
|
|
<P>If you run in to problems with include files missing, check the following
|
|
things. Make sure you have the kernel headers (include files) installed for
|
|
your kernel version. Also make sure you have these symbolic links in place:
|
|
<BLOCKQUOTE><CODE>
|
|
<PRE>
|
|
/usr/include/linux should be a link to /usr/src/linux/include/linux
|
|
/usr/include/asm should be a link to /usr/src/linux/include/asm
|
|
/usr/src/linux should be a link to the Linux source directory (ex.linux-2.0.30)
|
|
</PRE>
|
|
</CODE></BLOCKQUOTE>
|
|
|
|
Links can be made with <CODE>ln -s</CODE>, it works just like the cp command except it
|
|
makes a link (<CODE>ln -s source-dir destination-link</CODE>)
|
|
<P>When make is finished there should be an executable named httpd in the
|
|
directory. This needs to be moved in to a bin directory.
|
|
<CODE>/usr/sbin</CODE> or
|
|
<CODE>/usr/local/sbin</CODE> would be good choices.
|
|
<P>Copy the conf, logs, and icons sub-directories from the source to the server
|
|
home directory. Next rename 3 of the files files in the conf sub-directory
|
|
to get rid of the <CODE>-dist</CODE> extension (ex. <CODE>httpd.conf-dist</CODE> becomes
|
|
<CODE>httpd.conf</CODE>)
|
|
<P>There are also several support programs that are included with Apache. They
|
|
are in the <CODE>support</CODE> directory and must be compiled and installed separately.
|
|
Most of them can be make by using the makefile in that directory (which is
|
|
made when you run the main <CODE>Configure</CODE> script). You don't need any of them to
|
|
run Apache, but some of them make the administrators job easier.
|
|
<P>
|
|
<H2><A NAME="ss7.3">7.3 Configuring</A>
|
|
</H2>
|
|
|
|
<P>Now you should have four files in your <CODE>conf</CODE> sub-directory (under
|
|
your server home directory). The <CODE>httpd.conf</CODE> sets up the server daemon (port
|
|
number, user, etc). The <CODE>srm.conf</CODE> sets the root document tree, special
|
|
handlers, etc. The <CODE>access.conf</CODE> sets the base case for access. Finally
|
|
<CODE>mime.types</CODE> tells the server what mime type to send to the browser for each
|
|
extension.
|
|
<P>The configuration files are pretty much self-documented (plenty of
|
|
comments), as long as you understand the lingo. You should read through
|
|
them thoroughly before putting your server to work. Each configuration
|
|
item is covered in the Apache documentation.
|
|
<P>The <CODE>mime.types</CODE> file is not really a configuration file. It is used by the
|
|
server to translate file extensions into mime-types to send to the browser.
|
|
Most of the common mime-types are already in the file. Most people should
|
|
not need to edit this file. As time goes on, more mime types will be added
|
|
to support new programs. The best thing to do is get a new mime-types file
|
|
(and maybe a new version of the server) at that time.
|
|
<P>Always remember when you change the configuration files you need to restart
|
|
Apache or send it the SIGHUP signal with <CODE>kill</CODE> for the changes to take
|
|
effect. Make sure you send the signal to the parent process and not any of
|
|
the child processes. The parent usually has the lowest process id number. The
|
|
process id of the parent is also in the <CODE>httpd.pid</CODE> file in the log
|
|
directory. If you accidently send it to one of the child processes the
|
|
child will die and the parent will restart it.
|
|
<P>I will not be walking you through the steps of configuring Apache. Instead
|
|
I will deal with specific issues, choices to be made, and special features.
|
|
<P>I highly recommend that all users read through the security tips in the
|
|
Apache documentation. It is also available from the Apache website at
|
|
<A HREF="http://www.apache.org/docs/mics/security_tips.html">http://www.apache.org/docs/mics/security_tips.html</A>.
|
|
<P>
|
|
<H2><A NAME="ss7.4">7.4 Hosting virtual websites</A>
|
|
</H2>
|
|
|
|
<P>Virtual Hosting is when one computer has more than one domain name. The old
|
|
way was to have each virtual host have its own IP address. The new way uses
|
|
only one IP address, but it doesn't work correctly with browsers that don't
|
|
support HTTP 1.1.
|
|
<P>My recommendation for businesses is to go with the IP based virtual
|
|
hosting until most people have browsers that support HTTP 1.1 (give it a year
|
|
or two). This also gives you a more complete illusion of virtual
|
|
hosting. While both methods can give you virtual mail capabilities (can
|
|
someone confirm this?), only IP
|
|
based virtual hosting can also give you virtual FTP as well.
|
|
<P>If it is for a club or personal page, you may want to consider
|
|
shared IP virtual hosting.
|
|
It should be cheaper than IP based hosting and you will be saving
|
|
precious IP addresses.
|
|
<P>You can also mix and match IP and shared IP virtual hosts on the same
|
|
server. For more information on virtual hosting visit Apacheweek at
|
|
<A HREF="http://www.apacheweek.com/features/vhost">http://www.apacheweek.com/features/vhost</A>.
|
|
<P>
|
|
<H3>IP based virtual hosting</H3>
|
|
|
|
<P>In this method each virtual host has its own IP address. By determining the
|
|
IP address that the request was sent to, Apache and other programs can tell
|
|
what domain to serve. This is an incredible waste of IP space. Take for
|
|
example the servers where my virtual domain is kept. They have over 35,000
|
|
virtual accounts, that means 35,000 IP addresses. Yet I believe at last
|
|
count they had less than 50 servers running.
|
|
<P>Setting this up is a two part process. The first is getting Linux setup
|
|
to accept more than one IP address. The second is setting up apache to serve
|
|
the virtual hosts.
|
|
<P>The first step in setting up Linux to accept multiple IP addresses is to
|
|
make a new kernel. This works best with a 2.0 series kernel (or higher).
|
|
You need to include IP networking and IP aliasing
|
|
support. If you need help with compiling the kernel see the
|
|
<A HREF="http://sunsite.unc.edu/LDP/HOWTO/Kernel-HOWTO.html">kernel howto</A>.
|
|
<P>Next you need to setup each interface at boot. If you are using the Red Hat
|
|
Distribution then
|
|
this can be done from the control panel. Start X-windows as root, you
|
|
should see a control panel. Then double click on network configuration.
|
|
Next goto the interfaces panel and select your network card. Then click
|
|
alias at the bottom of the screen. Fill in the information and click done.
|
|
This will need to be done for each virtual host/IP address.
|
|
<P>If you are using other distributions you may have to do it manually.
|
|
You can just put the commands in the <CODE>rc.local</CODE> file in
|
|
<CODE>/etc/rc.d</CODE> (really they should go in with the networking
|
|
stuff). You need to have a <CODE>ifconfig</CODE> and <CODE>route</CODE> command for each device. The
|
|
aliased addresses are given a sub device of the main one. For example eth0
|
|
would have aliases eth0:0, eth0:1, eth0:2, etc. Here is an example of
|
|
configuring a aliased device:
|
|
<BLOCKQUOTE><CODE>
|
|
<PRE>
|
|
ifconfig eth0:0 192.168.1.57
|
|
route add -host 192.168.1.57 dev eth0:0
|
|
</PRE>
|
|
</CODE></BLOCKQUOTE>
|
|
|
|
You can also add a broadcast address and a netmask to the ifconfig command.
|
|
If you have alot of aliases you may want to make a for loop to make it
|
|
easier. For more information see the
|
|
<A HREF="http://sunsite.unc.edu/LDP/HOWTO/mini/IP-Alias.html">IP alias mini howto</A>.
|
|
<P>Then you need to setup your domain name server (DNS) to serve these new
|
|
domains. And if you don't already own the domain names, you need to
|
|
contact the
|
|
<A HREF="http://www.internic.net">Internic</A> to register
|
|
the domain names. See the DNS-howto for information on setting up your DNS.
|
|
<P>Finally you need to setup Apache to server the virtual domain correctly.
|
|
This is in the <CODE>httpd.conf</CODE> configuration file near the end. They give you an
|
|
example to go by. All commands specific to that virtual host are put in
|
|
between the <CODE>virtualhost</CODE> directive tags. You can put almost any command in there.
|
|
Usually you set up a different document root, script directory, and log
|
|
files. You can have almost unlimited number of virtual hosts by adding
|
|
more <CODE>virtualhost</CODE> directive tags.
|
|
<P>In rare cases you may need to run separate servers if a directive is needed
|
|
for a virtual host,
|
|
but is not allowed in the virtual host tags. This is done using the
|
|
bindaddress directive. Each server will have a different name and setup
|
|
files. Each server only responds to one IP address, specified by the
|
|
bindaddress directive. This is an incredible waste of system resources.
|
|
<P>
|
|
<H3>Shared IP virtual hosting</H3>
|
|
|
|
<P>This is a new way to do virtual hosting. It uses a single IP address,
|
|
thus conserving IP addresses for real machines (not virtual ones). In the
|
|
same example used above those 30,000 virtual hosts would only take 50 IP
|
|
addresses (one for each machine).
|
|
This is done by using the new HTTP 1.1 protocol. The browser tells the server which
|
|
site it wants when it sends the request. The problem is browsers that don't
|
|
support HTTP 1.1 will get the servers main page, which could be setup to
|
|
provide a menu of virtual hosts available. That
|
|
ruins the whole illusion of virtual hosting. The illusion that you have
|
|
your own server.
|
|
<P>The setup is much simpler than the IP based virtual hosting. You still need
|
|
to get your domain from the Internic and setup your DNS. This time the DNS
|
|
points to the same IP address as the original domain. Then Apache is setup
|
|
the same as before. Since you are using the same IP address in the
|
|
virtualhost tags, it knows you want Shared IP virtual hosting.
|
|
<P>There are several work arounds for older browsers. I'll explain the best
|
|
one. First you need to make your main pages a virtual host (either IP based
|
|
or shared IP). This
|
|
frees up the main page for a link list to all your virtual hosts. Next you
|
|
need to make a back door for the old browsers to get in. This is done using
|
|
the <CODE>ServerPath</CODE> directive for each virtual host inside the
|
|
<CODE>virtualhost</CODE>
|
|
directive. For example by adding <CODE>ServerPath /mysite/</CODE> to www.mysite.com old
|
|
browsers would be able to access the site by www.mysite.com/mysite/. Then
|
|
you put the default page on the main server that politely tells them to get
|
|
a new browser, and lists links to all the back doors of all the sites you
|
|
host on that machine. When an old browser accesses the site they will be
|
|
sent to the main page, and get a link to the correct page. New browsers
|
|
will never see the main page and will go directly to the virtual hosts. You
|
|
must remember to keep all of your links relative within the web sites,
|
|
because the pages will be accessed from two different URL's (www.mysite.com
|
|
and www.mysite.com/mysite/).
|
|
<P>I hope I didn't lose you there, but its not an easy workaround. Maybe you
|
|
should consider IP based hosting after all. A very similar workaround is
|
|
also explained on the apache website at
|
|
<A HREF="http://www.apache.org/manual/host.html">http://www.apache.org/manual/host.html</A>.
|
|
<P>If anyone has a great resource
|
|
for Shared IP hosting, I would like to know about it. It would be nice to
|
|
know what percent of browsers out there support HTTP 1.1, and to have a
|
|
list of which browsers and versions support HTTP 1.1.
|
|
<P>
|
|
<H2><A NAME="ss7.5">7.5 CGI scripts</A>
|
|
</H2>
|
|
|
|
<P>There are two different ways to give your users CGI script capability. The
|
|
first is make everything ending in <CODE>.cgi</CODE> a CGI script. The second is to make
|
|
script directories (usually named <CODE>cgi-bin</CODE>). You
|
|
could also use both methods. For either method to work the scripts must be
|
|
world executable (<CODE>chmod 711</CODE>). By giving your users script
|
|
access you are creating a big security risk. Be sure to do your homework to
|
|
minimize the security risk.
|
|
<P>I prefer the first method, especially for complex scripting. It allows you
|
|
to put scripts in any directory. I like to put my scripts with the web pages
|
|
they work with. For sites with allot of scripts it looks much better than
|
|
having a directory full
|
|
of scripts. This is simple to setup. First uncomment the <CODE>.cgi</CODE> handler
|
|
at the end of the <CODE>srm.conf</CODE> file. Then make sure all your directories have
|
|
the <CODE>option ExecCGI</CODE> or <CODE>All</CODE> in the <CODE>access.conf</CODE> file.
|
|
<P>Making script directories is considered more secure.
|
|
To make a script directory you use the ScriptAlias directive in the
|
|
<CODE>srm.conf</CODE> file. The first argument is the Alias the second is the actual
|
|
directory. For example <CODE>ScriptAlias /cgi-bin/ /usr/httpd/cgi-bin/</CODE> would make
|
|
<CODE>/usr/httpd/cgi-bin</CODE> able to execute scripts. That directory would be used
|
|
whenever someone asked for the directory <CODE>/cgi-bin/</CODE>. For security reasons
|
|
you should also change
|
|
the properties of the directory to <CODE>Options none, AllowOveride none</CODE> in the
|
|
<CODE>access.conf</CODE> (just uncomment the example that is there). Also do not make
|
|
your script directories subdirectories of your web page directories.
|
|
For example if you are serving pages from <CODE>/home/httpd/html/</CODE>, don't make the
|
|
script directory <CODE>/home/httpd/html/cgi-bin</CODE>; Instead make it
|
|
<CODE>/home/httpd/cgi-bin</CODE>.
|
|
<P>If you want your users to have there own script directories you can use
|
|
multiple <CODE>ScriptAlias</CODE> commands. Virtual hosts should have there
|
|
<CODE>ScriptAlias</CODE> command inside the <CODE>virtualhost</CODE> directive tags.
|
|
Does anyone know a simple way to allow
|
|
all users to have a cgi-bin directory without individual ScriptAlias
|
|
commands?
|
|
<P>
|
|
<P>
|
|
<H2><A NAME="ss7.6">7.6 Users Web Directories</A>
|
|
</H2>
|
|
|
|
<P>There are two different ways to handle user web directories. The first is to
|
|
have a subdirectory under the users home directory (usually <CODE>public_html</CODE>).
|
|
The second is to have an entirely different directory tree for web directories.
|
|
With both methods make sure set the access options for these directories
|
|
in the <CODE>access.conf</CODE> file.
|
|
<P>The first method is already setup in apache by default. Whenever a request
|
|
for <CODE>/~bob/</CODE> comes in it looks for the <CODE>public_html</CODE> directory in bob's
|
|
home directory. You can change the directory with the <CODE>UserDir</CODE> directive in
|
|
the <CODE>srm.conf</CODE> file. This directory must be world readable and executable.
|
|
This method creates a security risk because for Apache to
|
|
access the directory the users home directory must be world executable.
|
|
<P>The second method is easy to setup. You just need to change the
|
|
<CODE>UserDir</CODE> directive in the <CODE>srm.conf</CODE> file. It has many
|
|
different formats; you may want
|
|
to consult the Apache documentation for clarification. If you want each
|
|
user to have their own directory under <CODE>/home/httpd/</CODE>, you would use
|
|
<CODE>UserDir /home/httpd</CODE>. Then when the request <CODE>/~bob/</CODE> comes in it would translate to
|
|
<CODE>/home/httpd/bob/</CODE>. Or if you want to have a subdirectory under bob's
|
|
directory you would use <CODE>UserDir /home/httpd/*/html</CODE>. This would translate to
|
|
<CODE>/home/httpd/bob/html/</CODE> and would allow you to have a script directory
|
|
too (for example <CODE>/home/httpd/bob/cgi-bin/</CODE>).
|
|
<P>
|
|
<H2><A NAME="ss7.7">7.7 Daemon mode vs. Inetd mode</A>
|
|
</H2>
|
|
|
|
<P>There are two ways that apache can be run. One is as a daemon that is
|
|
always running (Apache calls this standalone). The second is from the
|
|
inetd super-server.
|
|
<P>Daemon mode is far superior to inetd mode. Apache is setup for daemon mode
|
|
by default. The only reason to use the inetd mode is for very
|
|
low use applications. Such as internal testing of scripts,
|
|
small company Intranet, etc. Inetd mode will save memory because apache
|
|
will be loaded as needed. Only the inetd daemon will remain in memory.
|
|
<P>If you don't use apache that often you may just want to keep it in daemon
|
|
mode and just start it when you need it. Then you can kill it when you are
|
|
done (be sure to kill the parent and not one of the child processes).
|
|
<P>To setup inetd mode you need to edit a few files. First in
|
|
<CODE>/etc/services</CODE>
|
|
see if http is already in there. If its not then add it:
|
|
<BLOCKQUOTE><CODE>
|
|
<PRE>
|
|
http 80/tcp
|
|
</PRE>
|
|
</CODE></BLOCKQUOTE>
|
|
|
|
Right after 79 (finger) would be a good place. Then you need to edit the
|
|
<CODE>/etc/inetd.conf</CODE> file and add the line for Apache:
|
|
<BLOCKQUOTE><CODE>
|
|
<PRE>
|
|
http stream tcp nowait root /usr/sbin/httpd httpd
|
|
</PRE>
|
|
</CODE></BLOCKQUOTE>
|
|
|
|
Be sure to change the path if you have Apache in a different location. And
|
|
the second httpd is not a typo; the inet daemon requires that. If you are
|
|
not currently using the inet daemon, you may want to comment out the rest of
|
|
the lines in the file so you don't activate other services as well (FTP,
|
|
finger, telnet, and many other things are usually run from this daemon).
|
|
<P>If you are already running the inet deamon (<CODE>inetd</CODE>), then you only need to
|
|
send it the SIGHUP signal (via kill; see kill's man page for more info) or
|
|
reboot the computer for changes to take effect. If you are not running
|
|
<CODE>inetd</CODE> then you can start it manually. You should also add it to your
|
|
init files so it is loaded at boot (the <CODE>rc.local</CODE> file may be a good
|
|
choice).
|
|
<P>
|
|
<H2><A NAME="ss7.8">7.8 Allowing put and delete commands</A>
|
|
</H2>
|
|
|
|
<P>The newer web publishing tools support this new method of uploading web
|
|
pages by http (instead of FTP). Some of these products don't even support
|
|
FTP anymore! Apache does support this, but it is lacking a script to handle
|
|
the requests. This script could be a big security hole, be sure you know
|
|
what you are doing before attempting to write or install one.
|
|
<P>If anyone knows of a script that works let me know and I'll include the
|
|
address to it here.
|
|
<P>For more information goto Apacheweek's article at
|
|
<A HREF="http://www.apacheweek.com/features/put">http://www.apacheweek.com/features/put</A>.
|
|
<P>
|
|
<H2><A NAME="ss7.9">7.9 User Authentication/Access Control</A>
|
|
</H2>
|
|
|
|
<P>
|
|
This is one of my favorite features. It allows you to password protect a
|
|
directory or a file without using CGI scripts. It also allows you to deny
|
|
or grant access based on the IP address or domain name of the client. That
|
|
is a great feature for keeping jerks out of your message boards and
|
|
guest books (you get the IP or domain name from the log files).
|
|
<P>To allow user authentication the directory must have <CODE>AllowOverrides
|
|
AuthConfig</CODE> set in the <CODE>access.conf</CODE> file. To allow access control (by domain
|
|
or IP address) AllowOverrides Limit must be set for that directory.
|
|
<P>Setting up the directory involves putting an <CODE>.htaccess</CODE> file in the
|
|
directory. For user authentication it is usually used with
|
|
an <CODE>.htpasswd</CODE> and optionally a <CODE>.htgroup</CODE> file. Those files can be shared among
|
|
multiple <CODE>.htaccess</CODE> files if you wish.
|
|
<P>For security reasons I recommend that everyone use these directives in there
|
|
access.conf file:
|
|
<P>
|
|
<BLOCKQUOTE><CODE>
|
|
<PRE>
|
|
<files ~ "/\.ht">
|
|
order deny,allow
|
|
deny from all
|
|
</files>
|
|
</PRE>
|
|
</CODE></BLOCKQUOTE>
|
|
<P>If you are not the administrator of the system you can also put it in your
|
|
.htaccess file if AllowOverride Limit is set for your directory.
|
|
This directive will prevent people from looking into your access control files
|
|
(.htaccess, .htpasswd, etc).
|
|
<P>There are many different options and file types that can be used with access
|
|
control. Therefore it is beyond the scope of this document to describe the
|
|
files. For information on how to setup User Authentication see the Apacheweek
|
|
feature at
|
|
<A HREF="http://www.apacheweek.com/features/userauth">http://www.apacheweek.com/features/userauth</A> or the NCSA pages
|
|
at
|
|
<A HREF="http://hoohoo.ncsa.uiuc.edu/docs-1.5/tutorials/user.html">http://hoohoo.ncsa.uiuc.edu/docs-1.5/tutorials/user.html</A>.
|
|
<P>
|
|
<H2><A NAME="ss7.10">7.10 su-exec</A>
|
|
</H2>
|
|
|
|
<P>The su-exec feature runs CGI scripts as the user of the owner. Normally it
|
|
is run as the user of the web server (usually nobody). This allows users to
|
|
access there own files in CGI scripts without making them world
|
|
writable (a security hole). But if you are not careful you can create a
|
|
bigger security hole by using the su-exec code. The su-exec code does
|
|
security checks before executing the scripts, but if you set it up wrong you
|
|
will have a security hole.
|
|
<P>The su-exec code is not for amateurs. Don't use it if you don't know what
|
|
you are doing. You could end up with a gaping security hole where your
|
|
users can gain root access to your system. Do not modify the code for any
|
|
reason. Be sure to read all the documentation carefully. The su-exec code
|
|
is hard to setup on purpose, to keep the amateurs out (everything must be
|
|
done manually, no make file no install scripts).
|
|
<P>The su-exec code resides in the <CODE>support</CODE> directory of the source. First you
|
|
need to edit the <CODE>suexec.h</CODE> file for your system. Then you need to compile
|
|
the su-exec code with this command:
|
|
<BLOCKQUOTE><CODE>
|
|
<PRE>
|
|
gcc suexec.c -o suexec
|
|
</PRE>
|
|
</CODE></BLOCKQUOTE>
|
|
|
|
Then copy the suexec executable to the proper directory. The Apache default is
|
|
<CODE>/usr/local/etc/httpd/sbin/</CODE>. This can be changed by editing
|
|
<CODE>httpd.h</CODE> in the
|
|
Apache source and recompiling Apache. Apache will only look in this directory,
|
|
it will not search the path. Next the file needs to be changed to user root
|
|
(<CODE>chown root suexec</CODE>) and the suid bit needs to be set
|
|
(<CODE>chmod 4711 suexec</CODE>).
|
|
Finally restart Apache, it should display a message on the console that
|
|
su-exec is being used.
|
|
<P>CGI scripts should be set world executable like normal. They will
|
|
automaticaly be run as the owner of the CGI script. If you set the SUID (set user id) bit on the
|
|
CGI scripts they will not run. If the directory or file is world or group
|
|
writable the script will not run. Scripts owned by system users will not be
|
|
run (root, bin, etc.). For other security conditions that must
|
|
be met see the su-exec documentation. If you are having problems see the
|
|
su-exec log file named <CODE>cgi.log</CODE>.
|
|
<P>Su-exec does not work if you are running Apache from inetd, it only
|
|
works in daemon mode. It will be fixed in the next version because there
|
|
will be no inetd mode. If you
|
|
like playing around in source code, you can edit the http_main.c. You want
|
|
to get rid of the line where Apache announces that it is using the su-exec
|
|
wrapper (It wrongly prints this in front of the output of everything).
|
|
<P>Be sure and read the Apache documentation on su-exec. It is included with
|
|
the source and is available on the Apache web site at
|
|
<A HREF="http://www.apache.org/docs/suexec.html">http://www.apache.org/docs/suexec.html</A><P>
|
|
<H2><A NAME="ss7.11">7.11 Imagemaps</A>
|
|
</H2>
|
|
|
|
<P>Apache has the ability to handle server side imagemaps. Imagemaps are
|
|
images on webpages that take users to different locations depending on
|
|
where they click. To enable imagemaps first make sure the imagemap module
|
|
is installed (its one of the default modules). Next you need to uncomment
|
|
the <CODE>.map</CODE> handler at the end of the <CODE>srm.conf</CODE> file. Now all files ending in
|
|
<CODE>.map</CODE> will be imagemap files. Imagemap files map different areas on the
|
|
image to separate links. Apache uses map files in the standard NCSA
|
|
format. Here is an example of using a map file in a web page:
|
|
<BLOCKQUOTE><CODE>
|
|
<PRE>
|
|
<a href="/map/mapfile.map">
|
|
<img src="picture.gif" ISMAP>
|
|
</a>
|
|
</PRE>
|
|
</CODE></BLOCKQUOTE>
|
|
|
|
In this example <CODE>mapfile.map</CODE> is the mapfile, and <CODE>picture.gif</CODE> is the image to
|
|
click on.
|
|
<P>There are many programs that can generate NCSA compatible map files or you
|
|
can create them yourself. For a more detailed discussion of imagemaps and
|
|
map files see the Apacheweek feature at
|
|
<A HREF="http://www.apacheweek.com/features/imagemaps">http://www.apacheweek.com/features/imagemaps</A>.
|
|
<P>
|
|
<H2><A NAME="ss7.12">7.12 SSI/XSSI</A>
|
|
</H2>
|
|
|
|
<P>Server Side Includes (SSI) adds dynamic content to otherwise static web
|
|
pages. The includes are embedded in the web page as comments. The web
|
|
server then parses these includes and passes the results to the web
|
|
server. SSI can add headers and footers to documents, add date the
|
|
document was last updated, execute a system command or a CGI script. With
|
|
the new eXtended Server Side Includes (XSSI) you can do a whole lot more.
|
|
XSSI adds variables and flow control statements (if, else, etc).
|
|
Its almost like having an programming language to work with.
|
|
<P>Parsing all HTML files for SSI commands would waste allot of system
|
|
resources. Therefore you need to distinguish normal HTML files from those
|
|
that contain SSI commands. This is usually done by changing the extension
|
|
of the SSI enhanced HTML files. Usually the <CODE>.shtml</CODE> extension is used.
|
|
<P>To enable SSI/XSSI first make sure that the includes module is installed.
|
|
Then edit <CODE>srm.conf</CODE> and uncomment the <CODE>AddType</CODE> and <CODE>AddHandler</CODE> directives for
|
|
<CODE>.shtml</CODE> files. Finally you must set <CODE>Options Includes</CODE> for all directories where
|
|
you want to run SSI/XSSI files. This is done in the <CODE>access.conf</CODE> file. Now
|
|
all files with the extension <CODE>.shtml</CODE> will be parsed for SSI/XSSI commands.
|
|
<P>Another way of enabling includes is to use the <CODE>XBitHack</CODE> directive. If you
|
|
turn this on it looks to see if the file is executable by user. If it is
|
|
and <CODE>Options Includes</CODE> is on for that directory, then
|
|
it is treated as an SSI file. This only works for files with the mime type
|
|
text/html (<CODE>.html .htm</CODE> files). This is not the preferred method.
|
|
<P>There is a security risk in allowing SSI to execute system commands and CGI
|
|
scripts. Therefore it is possible to lock that feature out with the
|
|
<CODE>Option IncludesNOEXEC</CODE> instead of Option Includes in the
|
|
<CODE>access.conf</CODE> file. All the
|
|
other SSI commands will still work.
|
|
<P>For more information see the Apache mod_includes documentation that comes
|
|
with the source. It is also available on the website at
|
|
<A HREF="http://www.apache.org/docs/mod/mod_include.html">http://www.apache.org/docs/mod/mod_include.html</A>.
|
|
<P>For a more detailed discussion of SSI/XSSI implementation see the Apacheweek
|
|
feature at
|
|
<A HREF="http://www.apacheweek.com/features/ssi">http://www.apacheweek.com/features/ssi</A>.
|
|
<P>For more information on SSI commands see the NCSA documentation at
|
|
<A HREF="http://hoohoo.ncsa.uiuc.edu/docs/tutorials/includes.html">http://hoohoo.ncsa.uiuc.edu/docs/tutorials/includes.html</A>.
|
|
<P>For more information on XSSI commands goto
|
|
<A HREF="ftp://pageplus.com/pub/hsf/xssi/xssi-1.1.html">ftp://pageplus.com/pub/hsf/xssi/xssi-1.1.html</A>.
|
|
<P>
|
|
<H2><A NAME="ss7.13">7.13 Module system</A>
|
|
</H2>
|
|
|
|
<P>Apache can be extended to support almost anything with modules.
|
|
There are allot of modules already in existence. Only the general interest
|
|
modules are included with Apache. For links to existing modules goto the
|
|
<P>Apache Module Registry at
|
|
<A HREF="http://www.zyzzyva.com/module_registry/">http://www.zyzzyva.com/module_registry/</A>.
|
|
<P>For module programming information goto
|
|
<A HREF="http://www.zyzzyva.com/module_registry/reference/">http://www.zyzzyva.com/module_registry/reference/</A><P>
|
|
<P>
|
|
<P>
|
|
<P>
|
|
<HR>
|
|
<A HREF="WWW-HOWTO-8.html">Next</A>
|
|
<A HREF="WWW-HOWTO-6.html">Previous</A>
|
|
<A HREF="WWW-HOWTO.html#toc7">Contents</A>
|
|
</BODY>
|
|
</HTML>
|