httpd-cvs mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From dgau...@hyperreal.org
Subject cvs commit: apache-1.2/htdocs/manual/misc FAQ.html
Date Wed, 18 Feb 1998 21:11:04 GMT
dgaudet     98/02/18 13:11:04

  Modified:    htdocs/manual/misc FAQ.html
  Log:
  I know most of the rest of the 1.2 docs are out of date... but I want this
  in here.  If only because I think it would be humourous for RedHat to
  make a package with it including all the RedHat q&a ;)
  
  Revision  Changes    Path
  1.65      +273 -57   apache-1.2/htdocs/manual/misc/FAQ.html
  
  Index: FAQ.html
  ===================================================================
  RCS file: /export/home/cvs/apache-1.2/htdocs/manual/misc/FAQ.html,v
  retrieving revision 1.64
  retrieving revision 1.65
  diff -u -r1.64 -r1.65
  --- FAQ.html	1998/01/30 09:13:06	1.64
  +++ FAQ.html	1998/02/18 21:11:03	1.65
  @@ -15,24 +15,22 @@
     <!--#include virtual="header.html" -->
     <H1 ALIGN="CENTER">Apache Server Frequently Asked Questions</H1>
     <P>
  -  $Revision: 1.64 $ ($Date: 1998/01/30 09:13:06 $)
  +  $Revision: 1.65 $ ($Date: 1998/02/18 21:11:03 $)
     </P>
     <P>
     The latest version of this FAQ is always available from the main
     Apache web site, at
     &lt;<A
  -       HREF="http://www.apache.org/docs/misc/FAQ"
  +       HREF="http://www.apache.org/docs/misc/FAQ.html"
          REL="Help"
  -      ><SAMP>http://www.apache.org/docs/misc/FAQ</SAMP></A>&gt;.
  +      ><SAMP>http://www.apache.org/docs/misc/FAQ.html</SAMP></A>&gt;.
     </P>
   <!-- Notes about changes:                                           -->
   <!--  - If adding a relative link to another part of the            -->
   <!--    documentation, *do* include the ".html" portion.  There's a -->
   <!--    good chance that the user will be reading the documentation -->
   <!--    on his own system, which may not be configured for          -->
  -<!--    multiviews.   Leave off the ".html" extension for absolute  -->
  -<!--    links to sites which are known to run multiviews (e.g.,     -->
  -<!--    apache.org or apacheweek.com).                              -->
  +<!--    multiviews.                                                 -->
   <!--  - When adding items, make sure they're put in the right place -->
   <!--    - verify that the numbering matches up.                     -->
   <!--  - *Don't* use <PRE></PRE> blocks - they don't appear          -->
  @@ -144,6 +142,9 @@
      <LI><A HREF="#errordoc401">Why doesn't my <CODE>ErrorDocument
       401</CODE> work?</A>
      </LI>
  +   <LI><A HREF="#errordocssi">How can I use <CODE>ErrorDocument</CODE>
  +   and SSI to simplify customized error messages?</A>
  +   </LI>
      <LI><A HREF="#setgid">Why do I get &quot;<SAMP>setgid: Invalid
       argument</SAMP>&quot; at startup?</A>
      </LI>
  @@ -168,7 +169,7 @@
       reset by peer</SAMP>&quot; in my error log?</A>
      </LI>
      <LI><A HREF="#nph-scripts">How can I get my script's output without
  -    Apache buffering it?</A>
  +    Apache buffering it?  Why doesn't my server push work?</A>
      </LI>
      <LI><A HREF="#linuxiovec">Why do I get complaints about redefinition
       of &quot;<CODE>struct iovec</CODE>&quot; when compiling under Linux?</A>
  @@ -252,6 +253,25 @@
      <LI><A HREF="#cgi-spec">Where can I find the &quot;CGI
       specification&quot;?</A>
      </LI>
  +   <LI><A HREF="#year2000">Is Apache Year 2000 compliant?</A>
  +   </LI>
  +   <LI><A HREF="#namevhost">I upgraded to Apache 1.3b and now my
  +    virtual hosts don't work!</A>
  +   </LI>
  +   <LI><A HREF="#redhat">I'm using RedHat Linux and I have problems with httpd
  +    dying randomly or not restarting properly</A>
  +   </LI>
  +   <li><a href="#stopping">I upgraded from an Apache version earlier
  +    than 1.2.0 and suddenly I have problems with Apache dying randomly
  +    or not restarting properly</a>
  +   </li>
  +   <li><a href="#redhat-htm">I'm using RedHat Linux and my .htm files are showing
  +    up as html source rather than being formatted!</a>
  +   </li>
  +   <li><a href="#glibc-crypt">I'm using RedHat Linux 5.0, or some other glibc
  +     based Linux system, and I get errors with the <code>crypt</code> function
when
  +     I attempt to build Apache 1.2.</a>
  +    </li>
     </OL>
    </LI>
   </UL>
  @@ -322,7 +342,7 @@
     <P>
     For an independent assessment, see
     <A
  -   HREF="http://webcompare.iworld.com/compare/chart.html"
  +   HREF="http://webcompare.internet.com/chart.html"
     >Web Compare</A>'s
     comparison chart.
     </P>
  @@ -352,7 +372,7 @@
     <P>
     The Apache project's web site includes a page with a partial list of
     <A
  -   HREF="http://www.apache.org/info/apache_users"
  +   HREF="http://www.apache.org/info/apache_users.html"
     >sites running Apache</A>.
     </P>
     <HR>
  @@ -384,7 +404,7 @@
     be swamped by a flood of trivial questions that can be resolved elsewhere.
     Bug reports and suggestions should be sent <EM>via</EM>
     <A
  -   HREF="http://www.apache.org/bug_report"
  +   HREF="http://www.apache.org/bug_report.html"
     >the bug report page</A>.
     Other questions should be directed to the
     <A
  @@ -415,7 +435,10 @@
      REL="Help"
     ><CITE>Apache Week</CITE></A>
     available.  Links to relevant <CITE>Apache Week</CITE> articles are
  -  included below where appropriate.
  +  included below where appropriate. There are also some 
  +  <A
  +   HREF="http://www.apache.org/info/apache_books.html"
  +  >Apache-specific books</A> available.
     </P>
     <HR>
    </LI>
  @@ -452,7 +475,7 @@
       the server error log.  Sometimes this is enough for you to diagnose
       &amp; fix the problem yourself (such as file permissions or the like).
       The default location of the error log is
  -    <SAMP>/usr/local/etc/httpd/logs/error_log</SAMP>, but see the
  +    <SAMP>/usr/local/apache/logs/error_log</SAMP>, but see the
       <A
        HREF="../mod/core.html#errorlog"
       ><SAMP>ErrorLog</SAMP></A>
  @@ -473,7 +496,7 @@
       Most problems that get reported to The Apache Group are recorded in
       the
       <A
  -     HREF="http://www.apache.org/bugdb.cgi"
  +     HREF="http://bugs.apache.org/"
       >bug database</A>.
       <EM><STRONG>Please</STRONG> check the existing reports, open
       <STRONG>and</STRONG> closed, before adding one.</EM>  If you find
  @@ -507,7 +530,7 @@
       have obtained no relief, then please <EM>do</EM> let The Apache
       Group know about the problem by
       <A
  -     HREF="http://www.apache.org/bugdb.cgi"
  +     HREF="http://www.apache.org/bug_report.html"
       >logging a bug report</A>.
       </P>
       <P>
  @@ -609,7 +632,7 @@
     allow all files named &quot;<SAMP>*.cgi</SAMP>&quot; to be executable.
     Perhaps all you want is to enable a particular file in a normal directory to
     be executable. This can be alternatively accomplished 
  -  via 
  +  <EM>via</EM>
     <A
      HREF="../mod/mod_rewrite.html"
     ><SAMP>mod_rewrite</SAMP></A> 
  @@ -818,7 +841,7 @@
     </P>
     <P>
     This is a feature The Apache Group hopes to add in the next major
  -  release after 1.2.
  +  release after 1.3.
     </P>
     <HR>
    </LI>
  @@ -995,13 +1018,19 @@
     </P>
     <P>
     <DL>
  -   <DD><CODE>&lt;Limit GET&gt;<BR>&nbsp;&nbsp;&nbsp;&nbsp;:</CODE>
  +   <DD><CODE>&lt;Limit GET&gt;
  +    <BR>&nbsp;&nbsp;&nbsp;&nbsp;:</CODE>
      </DD>
     </DL>
     </P>
     <P>
  -  Change that to <CODE>&lt;Limit GET POST&gt;</CODE> and the problem
  -  will probably go away.
  +  Change that to <CODE>&lt;Limit&nbsp;GET&nbsp;POST&gt;</CODE>
and the problem
  +  will probably go away.  Better yet, remove the
  +  <CODE>&lt;Limit&gt;</CODE> and <CODE>&lt;/Limit&gt;</CODE>
lines
  +  altogether unless you're <EM>specifically</EM> trying to limit by
  +  method (<SAMP>GET</SAMP>, <SAMP>PUT</SAMP>, <EM>et cetera</EM>).
 If
  +  you don't have a <CODE>&lt;Limit&gt;</CODE> container, the
  +  restrictions apply equally to <EM>all</EM> methods.
     </P>
     <HR>
    </LI>
  @@ -1073,6 +1102,19 @@
     </P>
     <HR>
    </LI>
  + <LI><A NAME="errordocssi">
  +      <STRONG>How can I use <CODE>ErrorDocument</CODE>
  +   and SSI to simplify customized error messages?</STRONG>
  +     </A>
  +  <P>
  +  Have a look at <A HREF="custom_errordocs.html">this document</A>.
  +  It shows in example form how you can a combination of XSSI and
  +  negotiation to tailor a set of <CODE>ErrorDocument</CODE>s to your
  +  personal taste, and returning different internationalized error
  +  responses based on the client's native language.
  +  </P>
  +  <HR>
  + </LI>
    <LI><A NAME="setgid">
         <STRONG>Why do I get &quot;<SAMP>setgid: Invalid
         argument</SAMP>&quot; at startup?</STRONG>
  @@ -1180,7 +1222,7 @@
     <P>
     More information about this issue can be found in the
     <A
  -   HREF="http://www.apache.org/info/jdk-102"
  +   HREF="http://www.apache.org/info/jdk-102.html"
     ><CITE>Java and HTTP/1.1</CITE></A>
     page at the Apache web site.
     </P>
  @@ -1248,14 +1290,14 @@
    </LI>
    <LI><A NAME="nph-scripts">
         <STRONG>How can I get my script's output without Apache buffering
  -      it?</STRONG>
  +      it?  Why doesn't my server push work?</STRONG>
        </A>
     <P>
     In order to improve network performance, Apache buffers script output
     into relatively large chunks.  If you have a script that sends
  -  information in bursts (such as partial-done messages in a multi-commit
  -  database transaction, perhaps), the client will not necessarily get
  -  the output as the script is generating it.
  +  information in bursts (eg. as partial-done messages in a multi-commit
  +  database transaction or any type of server push), the client will 
  +  not necessarily get the output as the script is generating it.
     </P>
     <P>
     To avoid this, Apache recognizes scripts whose names begin with
  @@ -1302,6 +1344,10 @@
     <P>
     and then follow with your normal non-<SAMP>nph</SAMP> headers.
     </P>
  +  <P>Note that in version 1.3, all CGI scripts will be unbuffered
  +  so the only difference between nph scripts and normal scripts is
  +  that nph scripts require the full HTTP headers to be sent.
  +  </P>
     <HR>
    </LI>
    <LI><A NAME="linuxiovec">
  @@ -1351,10 +1397,15 @@
     </P>
     <P>
     The canonical location for Apache's core-dump files is the
  +  <A HREF="../mod/core.html#serverroot">ServerRoot</A>
  +  directory. As of Apache version 1.3, the location can be set <EM>via</EM>
  +  the
     <A
  -   HREF="../mod/core.html#serverroot"
  -  >ServerRoot</A>
  -  directory.
  +   HREF="../mod/core.html#coredumpdirectory"
  +  ><SAMP>CoreDumpDirectory</SAMP></A>
  +  directive to a different directory. Make sure that this directory is
  +  writable by the user the server runs as (as opposed to the user the server
  +  is <EM>started</EM> as).
     </P>
     <HR>
    </LI>
  @@ -1420,7 +1471,7 @@
     <P>
     Some SSL implementations of Apache are available, however; see the
     &quot;<A
  -         HREF="http://www.apache.org/related_projects"
  +         HREF="http://www.apache.org/related_projects.html"
           >related projects</A>&quot;
     page at the main Apache web site.
     </P>
  @@ -1527,7 +1578,7 @@
     issues is the cause of your problem, and it hasn't been reported
     before, please submit a
     <A
  -   HREF="http://www.apache.org/bugdb.cgi"
  +   HREF="http://www.apache.org/bug_report.html"
     >problem report</A>.
     Be sure to include <EM>complete</EM> details, such as the compiler
     &amp; OS versions and exact error messages.
  @@ -1721,7 +1772,7 @@
       <BR>
       AuthType Basic
       <BR>
  -    AuthUserFile /usr/local/etc/httpd/conf/htpasswd.users
  +    AuthUserFile /usr/local/apache/conf/htpasswd.users
       <BR>
       AuthName special directory
       <BR>
  @@ -1780,10 +1831,12 @@
     <A HREF="http://www.linuxhq.com/HOWTO/META-FAQ.html"
     >Linux newsgroup/mailing list</A>.
     As a last-resort workaround, you can
  -  comment out the <CODE>#define HAVE_SHMGET</CODE> definition in the
  +  comment out the <CODE>#define&nbsp;USE_SHMGET_SCOREBOARD</CODE>
  +  definition in the
     <SAMP>LINUX</SAMP> section of
  -  <SAMP>src/conf.h</SAMP> and rebuild the server.  This will produce
  -  a server which is slower and less reliable.
  +  <SAMP>src/conf.h</SAMP> and rebuild the server (prior to 1.3b4, simply
  +  removing <CODE>#define&nbsp;HAVE_SHMGET</CODE> would have sufficed).
  +  This will produce a server which is slower and less reliable.
     </P>
     <HR>
    </LI>
  @@ -1868,8 +1921,8 @@
        </A>
     <P>
     You have probably configured the Host by specifying a FQHN,
  -  and thus the libmsql will use a full blown tcp/ip socket to talk to
  -  the database, rather than a fast internal device.  The
  +  and thus the <SAMP>libmsql</SAMP> will use a full blown TCP/IP socket
  +  to talk to the database, rather than a fast internal device.  The
     <SAMP>libmsql</SAMP>, the mSQL FAQ, and the <SAMP>mod_auth_msql</SAMP>
     documentation warn you about this.  If you have to use different
     hosts, check out the <SAMP>mod_auth_msql</SAMP> code for
  @@ -1884,7 +1937,7 @@
     <P>
     There is a collection of 
     <A
  -      HREF="http://www.engelschall.com/sw/mod_rewrite/docs/mod_rewrite/solutions.html#Solutions"
  +      HREF="http://www.engelschall.com/pw/apache/rewriteguide/"
     >Practical Solutions for URL-Manipulation</A>
     where you can
     find all typical solutions the author of 
  @@ -1934,7 +1987,7 @@
        </A>
     <P>
     Hmmm... there are a lot of reasons. First, mod_rewrite itself is a powerful
  -  module which can help you in really <b>all</b> aspects of URL rewriting,
so
  +  module which can help you in really <STRONG>all</STRONG> aspects of URL rewriting,
so
     it can be no trivial module per definition. To accomplish its hard job it
     uses software leverage and makes use of a powerful regular expression
     library by Henry Spencer which is an integral part of Apache since its
  @@ -1944,7 +1997,7 @@
     <P>
     On the other hand mod_rewrite has to work inside the Apache API environment
     and needs to do some tricks to fit there. For instance the Apache API as of
  -  1.x really was not designed for URL rewriting at the <tt>.htaccess</tt>
  +  1.x really was not designed for URL rewriting at the <TT>.htaccess</TT>
     level of processing. Or the problem of multiple rewrites in sequence, which
     is also not handled by the API per design. To provide this features
     mod_rewrite has to do some special (but API compliant!) handling which leads
  @@ -1986,8 +2039,10 @@
        </A>
     <P>
     You can't! The reason is: First, case translations for arbitrary length URLs
  -  cannot be done via regex patterns and corresponding substitutions. One need
  -  a per-character pattern like sed/Perl <SAMP>tr|..|..|</SAMP> feature.  Second,
just
  +  cannot be done <EM>via</EM> regex patterns and corresponding substitutions.
  +  One need
  +  a per-character pattern like sed/Perl <SAMP>tr|..|..|</SAMP> feature. 
  +  Second, just
     making URLs always upper or lower case will not resolve the complete problem
     of case-INSENSITIVE URLs, because actually the URLs had to be rewritten to
     the correct case-variant residing on the filesystem because in later
  @@ -2027,28 +2082,189 @@
    <LI><A NAME="cgi-spec"><STRONG>Where can I find the &quot;CGI
         specification&quot;?</STRONG></A>
     <P>
  -  The Common Gateway Interface (CGI) specification currently lives in at
  -  least two versions:
  +  The Common Gateway Interface (CGI) specification can be found at
  +  the original NCSA site 
  +  &lt;<A HREF="http://hoohoo.ncsa.uiuc.edu/cgi/interface.html">
  +  <SAMP>http://hoohoo.ncsa.uiuc.edu/cgi/interface.html</SAMP></A>&gt;.
  +  This version hasn't been updated since 1995, and there have been
  +  some efforts to update it.  
     </P>
  +  <HR>
  + </LI>
  + <LI><A NAME="year2000">
  +      <STRONG>Is Apache Year 2000 compliant?</STRONG>
  +     </A>
     <P>
  -  <OL>
  -   <LI>At the original NCSA site
  -    &lt;<A
  -         HREF="http://hoohoo.ncsa.uiuc.edu/cgi/interface.html"
  -        ><SAMP>http://hoohoo.ncsa.uiuc.edu/cgi/interface.html</SAMP></A>&gt;.
  -    This version hasn't been updated since 1995, and there have been
  -    some efforts to update it and replace it with
  -   </LI>
  -   <LI>The most current version, which is struggling to become an
  -    Internet RFC, found at
  -    &lt;<A
  -         HREF="http://www.ast.cam.ac.uk/~drtr/cgi-spec.html"
  -        ><SAMP>http://www.ast.cam.ac.uk/~drtr/cgi-spec.html</SAMP></A>&gt;.
  -   </LI>
  -  </OL>
  +  Yes, Apache is Year 2000 compliant.
  +  </P>
  +  <P>
  +  Apache internally never stores years as two digits.
  +  On the HTTP protocol level RFC1123-style addresses are generated
  +  which is the only format a HTTP/1.1-compliant server should
  +  generate. To be compatible with older applications Apache
  +  recognizes ANSI C's <CODE>asctime()</CODE> and
  +  RFC850-/RFC1036-style date formats, too.
  +  The <CODE>asctime()</CODE> format uses four-digit years,
  +  but the RFC850 and RFC1036 date formats only define a two-digit year.
  +  If Apache sees such a date with a value less than 70 it assumes that
  +  the century is <SAMP>20</SAMP> rather than <SAMP>19</SAMP>.
  +  </P>
  +  <P>
  +  Some aspects of Apache's output may use two-digit years, such as the
  +  automatic listing of directory contents provided by
  +  <A
  +   HREF="../mod/mod_autoindex.html"
  +  ><SAMP>mod_autoindex</SAMP></A>
  +  with the
  +  <A
  +   HREF="../mod/mod_autoindex.html#indexoptions"
  +  ><SAMP>FancyIndexing</SAMP></A>
  +  option enabled, but it is improper to depend upon such displays for
  +  specific syntax.  And even that issue is being addressed by the
  +  developers; a future version of Apache should allow you to format that
  +  display as you like.
  +  </P>
  +  <P>
  +  Although Apache is Year 2000 compliant, you may still get problems
  +  if the underlying OS has problems with dates past year 2000
  +  (<EM>e.g.</EM>, OS calls which accept or return year numbers).
  +  Most (UNIX) systems store dates internally as signed 32-bit integers
  +  which contain the number of seconds since 1<SUP>st</SUP> January 1970, so
  +  the magic boundary to worry about is the year 2038 and not 2000.
  +  But modern operating systems shouldn't cause any trouble
  +  at all.
  +  </P>
  +  <HR>
  + </LI>
  + <LI><A NAME="namevhost">
  +      <STRONG>I upgraded to Apache 1.3b and now my virtual hosts don't
  +      work!</STRONG>
  +     </A>
  +  <P>
  +  In versions of Apache prior to 1.3b2, there was a lot of confusion
  +  regarding address-based virtual hosts and (HTTP/1.1) name-based
  +  virtual hosts, and the rules concerning how the server processed
  +  <SAMP>&lt;VirtualHost&gt;</SAMP> definitions were very complex and
not
  +  well documented.
  +  </P>
  +  <P>
  +  Apache 1.3b2 introduced a new directive,
  +  <A
  +   HREF="http://www.apache.org/docs/mod/core.html#namevirtualhost"
  +  ><SAMP>NameVirtualHost</SAMP></A>,
  +  which simplifies the rules quite a bit.  However, changing the rules
  +  like this means that your existing name-based
  +  <SAMP>&lt;VirtualHost&gt;</SAMP> containers probably won't work
  +  correctly immediately following the upgrade.
  +  </P>
  +  <P>
  +  To correct this problem, add the following line to the beginning of
  +  your server configuration file, before defining any virtual hosts:
  +  </P>
  +  <DL>
  +   <DD><CODE>NameVirtualHost <EM>n.n.n.n</EM></CODE>
  +   </DD>
  +  </DL>
  +  <P>
  +  Replace the &quot;<SAMP>n.n.n.n</SAMP>&quot; with the IP address
to
  +  which the name-based virtual host names resolve; if you have multiple
  +  name-based hosts on multiple addresses, repeat the directive for each
  +  address.
  +  </P>
  +  <P>
  +  Make sure that your name-based <SAMP>&lt;VirtualHost&gt;</SAMP> blocks
  +  contain <SAMP>ServerName</SAMP> and possibly <SAMP>ServerAlias</SAMP>
  +  directives so Apache can be sure to tell them apart correctly.
  +  </P>
  +  <P>
  +  Please see the
  +  <A HREF="http://www.apache.org/docs/vhosts/">Apache
  +  Virtual Host documentation</A> for further details about configuration.
     </P>
     <HR>
    </LI>
  +
  + <li><a name="redhat"><strong>I'm using RedHat Linux and I have problems
with httpd
  +    dying randomly or not restarting properly</strong></a>
  +
  +    <p>RedHat Linux versions 4.x (and possibly earlier) rpms contain
  +    various nasty scripts which do not stop or restart Apache properly.
  +    These can affect you even if you're not running the RedHat supplied
  +    rpms.
  +
  +    <p> If you're using the default install then you're probably running
  +    Apache 1.1.3, which is outdated.  From RedHat's ftp site you can
  +    pick up a more recent RPM for Apache 1.2.x.  This will solve one of
  +    the problems.
  +
  +    <p> If you're using a custom built Apache rather than the RedHat rpms
  +    then you should <code>rpm -e apache</code>.  In particular you want
  +    the mildly broken <code>/etc/logrotate.d/apache</code> script to be
  +    removed, and you want the broken <code>/etc/rc.d/init.d/httpd</code>
  +    (or <code>httpd.init</code>) script to be removed.  The latter is
  +    actually fixed by the apache-1.2.5 rpms but if you're building your
  +    own Apache then you probably don't want the RedHat files.
  +
  +    <p>We can't stress enough how important it is for folks, <i>especially
  +    vendors</i> to follow the <a href="../stopping.html">stopping Apache
  +    directions</a> given in our documentation.  In RedHat's defense,
  +    the broken scripts were necessary with Apache 1.1.x because the
  +    Linux support in 1.1.x was very poor, and there were various race
  +    conditions on all platforms.  None of this should be necessary with
  +    Apache 1.2 and later.
  +    </p>
  +    <hr>
  +  </li>
  +
  +  <li><a name="stopping"><strong>I upgraded from an Apache version earlier
  +    than 1.2.0 and suddenly I have problems with Apache dying randomly
  +    or not restarting properly</strong></a>
  +
  +    <p>You should read <a href="#redhat">the previous note</a> about
  +    problems with RedHat installations.  It is entirely likely that your
  +    installation has start/stop/restart scripts which were built for
  +    an earlier version of Apache.  Versions earlier than 1.2.0 had
  +    various race conditions that made it necessary to use
  +    <code>kill -9</code> at times to take out all the httpd servers.
  +    But that should not be necessary any longer.  You should follow
  +    the <a href="../stopping.html">directions on how to stop
  +    and restart Apache</a>.
  +
  +    <p>As of Apache 1.3 there is a script
  +    <code>src/support/apachectl</code> which, after a bit of
  +    customization, is suitable for starting, stopping, and restarting
  +    your server.
  +    </p>
  +    <hr>
  +
  +  </li>
  +
  +  <li><a name="redhat-htm"><strong>I'm using RedHat Linux and my .htm
files are showing
  +    up as html source rather than being formatted!</strong></a>
  +
  +    <p>RedHat messed up and forgot to put a content type for <code>.htm</code>
  +    files into <code>/etc/mime.types</code>.  Edit <code>/etc/mime.types</code>,
  +    find the line containing <code>html</code> and add <code>htm</code>
to it.
  +    Then restart your httpd server:
  +    <pre>
  +	kill -HUP `cat /var/run/httpd.pid`
  +    </pre>
  +    Then <b>clear your browsers' caches</b>.  (Many browsers won't re-examine
  +    the content type after they've reloaded a page.)
  +    </p>
  +    <hr>
  +
  +  <li><a name="glibc-crypt"><strong>I'm using RedHat Linux 5.0, or some
other glibc
  +    based Linux system, and I get errors with the <code>crypt</code> function
when
  +    I attempt to build Apache 1.2.</strong></a>
  +
  +    <p>glibc puts the crypt function into a separate library.  Edit your
  +    <code>src/Configuration</code> file and set this:
  +    <pre>
  +	EXTRA_LIBS=-lcrypt
  +    </pre>
  +    </p>
  +    <hr>
   
     <!-- Don't forget to add HR tags at the end of each list item.. -->
   
  
  
  

Mime
View raw message