asg02.htm

apache技术手册

<BR>

<PRE>

<FONT COLOR="#000080">cd /usr/local/etc/httpd/conf

cp httpd.conf-dist httpd.conf

cp access.conf-dist access.conf

cp srm.conf-dist srm.conf</FONT></PRE>

<P>After you've made your local copies, you are ready to configure a basic server.

<BR>

<P>Runtime configuration of your server is done by way of <I>configuration </I><I>directives</I>. Directives are commands that set some option; use them to tell the server about various options that you want to enable, such as the location of files important to the server configuration and operation. Configuration directives follow this syntax:

<BR>

<BR>

<PRE>

<FONT COLOR="#000080"><I>Directive option option</I>&#133;</FONT></PRE>

<P><A NAME="I2"></A><A NAME="I3"></A><A NAME="I4"></A><A NAME="I5"></A><A NAME="I6"></A><A NAME="I7"></A>Directives are specified one per line. Some directives only set a value such as a filename; others let you specify various options. There are special directives, called <I>sections</I>, that look like HTML tags. Section directives are surrounded by angle brackets, such as &lt;<I>directive</I>&gt;. Sections usually enclose a group of directives that apply only to the directory specified in the section:

<BR>

<PRE>

<FONT COLOR="#000080">&lt;Directory somedir/in/your/tree&gt;

 Directive option option

 Directive option option

&lt;/Directive&gt;</FONT></PRE>

<P>All sections are closed with a matching section tag that looks like &lt;/<I>directive</I>&gt;. You will see some of these constructs in the conf/access.conf and in your conf/httpd.conf files. Note that section tags, like any other directive, are specified one per line.

<BR>

<BR>

<A NAME="E69E4"></A>

<H4 ALIGN=CENTER>

<CENTER>

<FONT SIZE=4 COLOR="#FF0000"><B>Editing </B><B>httpd.conf</B></FONT></CENTER></H4>

<BR>

<P>httpd.conf contains configuration directives that control how the server runs, where its logfiles are found, the user ID (UID) it runs under, the port that it listens to, and so on. You will need to edit some of the default configuration values to settings that make sense in your site. I kept most of the defaults found on my httpd.conf, with the exception of the following:

<BR>

<P><B><A HREF="javascript:if(confirm('http://docs.rinet.ru:8080/Apachu/02asg01.gif  \n\nThis file was not retrieved by Teleport Pro, because it was redirected to an invalid location.  You should report this problem to the site\'s webmaster.  \n\nDo you want to open it from the server?'))window.location='http://docs.rinet.ru:8080/Apachu/02asg01.gif'" tppabs="http://docs.rinet.ru:8080/Apachu/02asg01.gif">Figure 2.2. One of the error messages the server </B><B>returns if there's an error. Note that the </B><B>ServerAdmin</B><B> was set to </B><B>[e-mail]</B><B>.</A></B>

<BR>



<TABLE  BORDERCOLOR=#000040 BORDER=1 CELLSPACING=2 WIDTH="80%" CELLPADDING=2 >

<TR>

<TD VALIGN=top  BGCOLOR=#80FFFF ><FONT COLOR=#000080>

ServerAdmim

</FONT>

<TD VALIGN=top  BGCOLOR=#80FFFF ><FONT COLOR=#000080>

The ServerAdmin directive should be set to the address of the webmaster managing the server. It should be a valid e-mail address or alias, such as <I>[e-mail]</I>. Setting this to a valid address is important because this address will be returned to a visitor when there's a problem.</FONT>

<TR>

<TD VALIGN=top  BGCOLOR=#80FFFF ><FONT COLOR=#000080>

User and Group

</FONT>

<TD VALIGN=top  BGCOLOR=#80FFFF ><FONT COLOR=#000080>

The User and Group directives set the UID and group ID (GID) that the server will use to process requests. I kept these to the defaults: nobody and nogroup. Please verify that the names nobody and nogroup exist in your <I>/etc/passwd</I> and <I>/etc/group</I><I> </I>files, respectively. If you want to use a different UID or GID, go ahead; however, be aware that the server will run with the permissions you define here. The permissions for the specified UID and GID should be very low because, in case of a security hole, whether on the server or (more likely) on your own CGI programs, those programs will run with the assigned UID. If the server runs as root or some other privileged user, someone may exploit the security holes and do nasty things to your site. Instead of specifying the User and Group directives using a name, you can specify them by using the UID and GID numbers. If you use numbers, be sure that the numbers you specify correspond to the user and group you want, and that they are preceded by the pound (#) symbol.</FONT>

</TABLE><P>Here's how these directives would look if specified by name:

<BR>

<UL>

<UL>

<PRE>

<FONT COLOR="#000080">User nobody

Group nogroup</FONT></PRE></UL></UL>

<P>Here's the same specification, but by UID and GID:

<BR>

<UL>

<UL>

<PRE>

<FONT COLOR="#000080">User #-1

Group #-1</FONT></PRE>

<BR>

<TABLE  BORDERCOLOR=#000040 BORDER=1 CELLSPACING=2 WIDTH="80%" CELLPADDING=2 >

<TR>

<TD VALIGN=top  BGCOLOR=#80FFFF ><FONT COLOR=#000080>

ServerName

</FONT>

<TD VALIGN=top  BGCOLOR=#80FFFF ><FONT COLOR=#000080>

The ServerName directive sets the hostname the server will return. Set it to a fully qualified domain name (fqdn). If not set, the server will try figure it out by itself and set to its canonical name. However, you may want the server to return a friendlier address such as <I>www.your.domain</I>. Whatever you do, ServerName should be a real Domain Name System (DNS) name for your network. If you are administering your own DNS, remember to add a CNAME alias for your host. If someone else manages the DNS for you, ask her to do this for you. Your ServerName entry should look like this: ServerName <I>www.your.domain</I></FONT>

</TABLE>

<BLOCKQUOTE>

<BLOCKQUOTE>

<HR ALIGN=CENTER>

<BR>

<NOTE>If you would like to install a Web server for test purposes on a standalone machine, you can do so by specifying a ServerName of localhost. You can then access the server as http://www.localhost from within the standalone machine. This may be a useful thing to do for trying out new configurations or Internet Web servers.</NOTE>

<BR>

<HR ALIGN=CENTER>

</BLOCKQUOTE></BLOCKQUOTE>

<TABLE  BORDERCOLOR=#000040 BORDER=1 CELLSPACING=2 WIDTH="80%" CELLPADDING=2 >

<TR>

<TD VALIGN=top  BGCOLOR=#80FFFF ><FONT COLOR=#000080>

ServerRoot

</FONT>

<TD VALIGN=top  BGCOLOR=#80FFFF ><FONT COLOR=#000080>

This directive sets the absolute path to your server directory (where your httpd binary is located). This directive tells the server where to find all the resources and configuration files. Many of these resources are specified in the configuration files relative of the ServerRoot directory. If you installed your server using my examples, your ServerRoot directive will read: ServerRoot /usr/local/etc/httpd</FONT>

</TABLE>

<BR>

<A NAME="E69E5"></A>

<H4 ALIGN=CENTER>

<CENTER>

<FONT SIZE=4 COLOR="#FF0000"><B>Editing </B><B>srm.conf</B></FONT></CENTER></H4>

<BR>

<P>The srm.conf file is the resource configuration file. It controls settings related to the location of your Web document tree, the CGI program directories, and other resource configuration issues that affect your Web site. I kept most of the defaults found on my srm.conf. The most important directives on this configuration file are

<BR>



<TABLE  BORDERCOLOR=#000040 BORDER=1 CELLSPACING=2 WIDTH="80%" CELLPADDING=2 >

<TR>

<TD VALIGN=top  BGCOLOR=#80FFFF ><FONT COLOR=#000080>

DocumentRoot

</FONT>

<TD VALIGN=top  BGCOLOR=#80FFFF ><FONT COLOR=#000080>

Set this directive to the absolute path of your document tree. Your <I>document tree</I> is the top directory from which Apache will serve files. By default it is set to <I>/usr/local/etc/httpd/htdocs</I>.</FONT>

</TABLE><P>You may also want to set the UserDir directive to disabled. The UserDir directive defines the directory relative of a local user's home directory where they will put public HTML documents. It's relative because each user will have a public_HTML directory. Although this may give users at your site the freedom to create and maintain their own home pages, many users may not be aware of this fact, resulting in the possibility of their creating a public_html directory that contains private files. Additionally, depending on the kind of users in your system and the server configuration, this may create potential security problems. It would make it possible for a user to publish your entire filesystem by creating a symbolic link to a directory outside of a Web document tree. By doing this, anyone would be able to read and navigate your filesystem freely.

<BR>

<P><A HREF="asg16.htm" tppabs="http://docs.rinet.ru:8080/Apachu/asg16.htm">Chapter 16</A>, &quot;Web Server Security Issues,&quot; discusses alternatives for providing this functionality that I feel are better from a security and maintenance standpoint.

<BR>

<P>A copy of the boilerplate conf/srm.conf file has been included at the end of this chapter.

<BR>

<BR>

<A NAME="E69E6"></A>

<H4 ALIGN=CENTER>

<CENTER>

<FONT SIZE=4 COLOR="#FF0000"><B>Editing </B><B>access.conf</B></FONT></CENTER></H4>

<BR>

<P>I kept all the defaults found in my access.conf file. access.conf is the global <I>access control file</I>; it configures the type of access users have to your site and the documents you make available, as well as security issues defining the extent to which users may alter the security settings you may have defined. The default configuration provides unrestricted access to documents in your DocumentRoot.

<BR>

<P>If you want to provide a more restrictive site, you may want to verify that all &lt;Directory <I>path</I>&gt; sections match the directories they list in your installation. The Directory sections specify a set of options, usually involving security issues, on a per-directory basis. In particular, you may want to remove the Indexes option that follows the Options directive on the section that looks like this:

<BR>

<PRE>

<FONT COLOR="#000080">&lt;Directory /usr/local/etc/httpd/cgi-bin&gt;

Options Indexes FollowSymLinks

&lt;/Directory&gt;</FONT></PRE>

<P>The Indexes option allows for server-generated directory listings. You probably don't want anyone peeking at the contents of your cgi-bin directories.

<BR>

<P>Options that you implement on your global ACT can be overridden by the use of an .htaccess file. You can disable all .htaccess overrides by setting the directive AllowOverride to None, which is by default set to allow all overrides:

<BR>

<BR>

<PRE>

<FONT COLOR="#000080">AllowOverride None</FONT></PRE>

<P>I discuss access control and security in <A HREF="asg15.htm" tppabs="http://docs.rinet.ru:8080/Apachu/asg15.htm">Chapter 15</A>, &quot;Access Control and User Authentication.&quot;

<BR>

<BR>

<A NAME="E68E18"></A>

<H3 ALIGN=CENTER>

<CENTER>

<FONT SIZE=5 COLOR="#FF0000"><B>Configuring an </B><B>inetd</B><B> Server</B></FONT></CENTER></H3>

<BR>

<P>Normally, Apache runs in standalone mode or daemon mode. How it is run by the system depends on how it is configured by the ServerType directive in conf/httpd.conf.

<BR>

<P>A <I>standalone server</I> offers superior performance over inetd-run servers because usually there will be a server process ready to serve a request. When run under inetd (the Internet daemon), a new server is started every time a request is received on the HTTP port. There is a considerable amount of overhead in starting a new server process with each new request.

<BR>

<P>The default setting for ServerType is standalone; unless you have an extremely light traffic site, you should stick with this setting. inetd servers are good for information you want available, but to which you don't want to dedicate a computer.

<BR>

<BLOCKQUOTE>

<BLOCKQUOTE>

<HR ALIGN=CENTER>

<BR>

<NOTE>inetd servers are great for testing configuration settings because the server rereads all its settings every time there's a request. On standalone servers, you need to manually restart the server before it sees any changes you made to the configuration files.</NOTE>

<BR>

<HR ALIGN=CENTER>

</BLOCKQUOTE></BLOCKQUOTE>

<P>To run a server from inetd, you'll need to modify conf/httpd.conf once more and change the ServerType directive from standalone to inetd:

<BR>

<BR>

<PRE>

<FONT COLOR="#000080">ServerType inetd</FONT></PRE>

<P>The Port directive has no effect on an inetd server. A standalone server uses this configuration information to learn which port it should be listening to. Because inetd does the binding between the port and the software, this setting has no effect on an inetd configuration.

<BR>

<BR>

<A NAME="E69E7"></A>

<H4 ALIGN=CENTER>

<CENTER>

<FONT SIZE=4 COLOR="#FF0000"><B>Configuring </B><B>inetd</B></FONT></CENTER></H4>

<BR>

<P>inetd is the &quot;Internet superserver.&quot; It gets started when the machines boots by /etc/rc. Once launched, inetd listens for connections on Internet socket ports. When it finds a connection, it starts up the program responsible for managing that port. When the request is served and the program exits, inetd continues to listen for additional requests on that port.

<BR>

<P>To make Apache work from inetd, you need to edit /etc/inetd.conf and /etc/services. Configuring an inetd server requires a bit more system configuration than a standalone server.

<BR>

<P>First, you need to edit your /etc/services file. The /etc/services database contains information about all known services available on the Internet. Each service is represented by single line listing the following information:

<BR>

<UL>

<UL>

<P>Official service name

</UL></UL>

<UL>

<UL>

<P>Port number

</UL></UL>

<UL>

<UL>

<P>Protocol name

</UL></UL>

<UL>

<UL>

<P>Aliases by which the service is known

<BR>

</UL></UL>

<P>Each entry is separated by a tab or spaces. An entry describing httpd will look like this:

<BR>

<BR>

<PRE>

<FONT COLOR="#000080">http <I>portnumber</I>/tcp httpd httpd</FONT></PRE>

<BLOCKQUOTE>

<BLOCKQUOTE>

<HR ALIGN=CENTER>

<BR>

<NOTE><A NAME="I8"></A>UNIX ports range from 0 to 65,535; however, the first 1,024 ports are reserved. A <I>reserved port</I> means that only processes owned by the superuser will be able to bind to them; if you want to run the server at port 80 (the default for httpd), httpd will need to be started by the superuser.</NOTE>

<BR>

<HR ALIGN=CENTER>

</BLOCKQUOTE></BLOCKQUOTE>

<P>Set <I>portnumber</I> to the port number on which you want to run the server. Typically this will be port 80 for a standalone server. inetd servers run better at port 8080, so your entry will look like this:

<BR>

<BR>

<PRE>

<FONT COLOR="#000080">http 8080/tcp httpd httpd</FONT></PRE>

<P>If you are running NetInfo, you can type this line into a temporary file, such as /tmp/services, and then run

<BR>

<BR>

<PRE>

<FONT COLOR="#000080">niload services . &lt; /tmp/services</FONT></PRE>

<P>Next, you need to edit /etc/inetd.conf to configure inetd to listen for httpd requests. Each line in inetd.conf contains the following information:

<BR>

<UL>

<UL>

<P>Service name

</UL></UL>

<UL>

<UL>

<P>Socket type

</UL></UL>

<UL>

<UL>

<P>Protocol

</UL></UL>

<UL>

<UL>

<P>Wait/no wait

</UL></UL>