Added .htaccess files for shadow/, data/, and /.

I added related information to the Bugzilla Guide, and
tacked in a couple of last-minute additions.  Also fixed the
annoying "Tip: HINT:" thing.

4 files changed, 162 insertions, 11 deletions

diff --git a/docs/sgml/Bugzilla-Guide.sgml b/docs/sgml/Bugzilla-Guide.sgml
index 9334472af..88daac2bb 100644
--- a/docs/sgml/Bugzilla-Guide.sgml
+++ b/docs/sgml/Bugzilla-Guide.sgml
@@ -59,7 +59,7 @@ http://www.linuxdoc.org/LDP/LDP-Author-Guide/tools-hints.html
 
   <BOOKINFO>
     <TITLE>The Bugzilla Guide</TITLE>
-    <PUBDATE>v2.12.0, 24 April 2001</PUBDATE>
+    <PUBDATE>2001-04-25</PUBDATE>
     <AUTHOR>
       <FIRSTNAME>Matthew</FIRSTNAME>
       <OTHERNAME>P.</OTHERNAME>
diff --git a/docs/sgml/administration.sgml b/docs/sgml/administration.sgml
index a35ba047d..8ca600c54 100644
--- a/docs/sgml/administration.sgml
+++ b/docs/sgml/administration.sgml
@@ -1049,14 +1049,38 @@ operating parameters for bugzilla.</PARA>
 	<LISTITEM>
 	  <PARA>
 	    Ensure you have adequate access controls for the $BUGZILLA_HOME/data/ and
-	    $BUGZILLA_HOME/shadow/ directories, as well as the $BUGZILLA_HOME/localconfig file.
+	    $BUGZILLA_HOME/shadow/ directories, as well as the $BUGZILLA_HOME/localconfig and
+	    $BUGZILLA_HOME/globals.pl files.
 	    The localconfig file stores your "bugs" user password,
 	    which would be terrible to have in the hands
-	    of a criminal.  Also some files under $BUGZILLA_HOME/data/ store sensitive information, and
+	    of a criminal, while the "globals.pl" stores some default information regarding your
+	    installation which could aid a system cracker.
+	    In addition, some files under $BUGZILLA_HOME/data/ store sensitive information, and
 	    $BUGZILLA_HOME/shadow/ stores bug information for faster retrieval.  If you fail to secure
 	    these directories and this file, you will expose bug information to those who may not
 	    be allowed to see it.
 	  </PARA>
+	  <NOTE>
+	    <PARA>
+	      Bugzilla provides default .htaccess files to protect the most common Apache
+	      installations.  However, you should verify these are adequate according to the site-wide
+	      security policy of your web server, and ensure that the .htaccess files are
+	      allowed to "override" default permissions set in your Apache configuration files.
+	      Covering Apache security is beyond the scope of this Guide; please consult the Apache
+	      documentation for details.
+	    </PARA>
+	    <PARA>
+	      If you are using a web server that does not support the .htaccess control method,
+	      <EMPHASIS>you are at risk!</EMPHASIS>  After installing, check to see if you can
+	      view the file "localconfig" in your web browser (ergo: 
+	      <ULINK URL="http://bugzilla.mozilla.org/localconfig">
+	      http://bugzilla.mozilla.org/localconfig</ULINK>.  If you can read the contents of this
+	      file, your web server has not secured your bugzilla directory properly and you
+	      must fix this problem before deploying Bugzilla.  If, however, it gives you a
+	      "Forbidden" error, then it probably respects the .htaccess conventions and you
+	      are good to go.
+	    </PARA>
+	  </NOTE>
 	  <PARA>
 	    On Apache, you can use .htaccess files to protect access to these directories, as outlined
 	    in <ULINK URL="http://bugzilla.mozilla.org/show_bug.cgi?id=57161">Bug 57161</ULINK> for the
diff --git a/docs/sgml/faq.sgml b/docs/sgml/faq.sgml
index b7ca03201..2b67890a9 100644
--- a/docs/sgml/faq.sgml
+++ b/docs/sgml/faq.sgml
@@ -680,6 +680,54 @@
 	</answer>
       </qandaentry>
 
+
+      <qandaentry>
+	<question>
+	  <para>
+	    The index.html page doesn't show the footer.  It's really annoying to have
+	    to go to the querypage just to check my "my bugs" link.  How do I get a footer
+	    on static HTML pages?
+	  </para>
+	</question>
+	<answer>
+	  <para>
+	    This was a late-breaking question for the Guide, so I just have to
+	    quote the relevant newsgroup thread on it.
+	  </para>
+	  <literallayout>
+> AFAIK, most sites (even if they have SSI enabled) won't have #exec cmd
+> enabled.  Perhaps what would be better is a #include virtual and a
+> footer.cgi the basically has the "require 'CGI.pl' and PutFooter command.
+>
+> Please note that under most configurations, this also requires naming
+> the file from index.html to index.shtml (and making sure that it will
+> still be reconized as an index).  Personally, I think this is better on
+> a per-installation basis (perhaps add something to the FAQ that says how
+> to do this).
+
+Good point.  Yeah, easy enough to do, that it shouldn't be a big deal for
+someone to take it on if they want it.  FAQ is a good place for it.
+
+> Dave Miller wrote:
+>
+>> I did a little experimenting with getting the command menu and footer on
+>> the end of the index page while leaving it as an HTML file...
+>>
+>> I was successful. :)
+>>
+>> I added this line:
+>>
+>> <!--#exec cmd="/usr/bin/perl -e &quot;require 'CGI.pl';
+>>PutFooter();&quot;" -->
+>>
+>> Just before the &lt;/BODY&gt; &lt;/HTML&gt; at the end of the file.  And it worked.
+>>
+>> Thought I'd toss that out there.  Should I check this in?  For those that
+>> have SSI disabled, it'll act like a comment, so I wouldn't think it would
+>> break anything.
+	  </literallayout>
+	</answer>
+      </qandaentry>
       <qandaentry>
 	<question>
 	  <para>
diff --git a/docs/sgml/installation.sgml b/docs/sgml/installation.sgml
index 03ff0bd8d..8165afd6d 100644
--- a/docs/sgml/installation.sgml
+++ b/docs/sgml/installation.sgml
@@ -479,7 +479,7 @@
 	</PARA>
 	<TIP>
 	  <PARA>
-	    HINT:  If you symlink the bugzilla directory into your Apache's
+	    If you symlink the bugzilla directory into your Apache's
 	    HTML heirarchy, you may receive "Forbidden" errors unless you
 	    add the "FollowSymLinks" directive to the &lt;Directory&gt; entry
 	    for the HTML root.
@@ -493,11 +493,25 @@
 	  installation.
 	</PARA>
 	<PARA>
-	  Lastly, you'll need to set up a symbolic link from /usr/bonsaitools/bin
-	  to the correct location of your perl executable (probably /usr/bin/perl).
+	  Lastly, you'll need to set up a symbolic link to /usr/bonsaitools/bin/perl
+	  for the correct location of your perl executable (probably /usr/bin/perl).
 	  Otherwise you must hack all the .cgi files to change where they look
 	  for perl.  To make future upgrades easier, you should use the symlink
 	  approach.
+	  <EXAMPLE>
+	    <TITLE>Setting up bonsaitools symlink</TITLE>
+	    <PARA>
+	      Here's how you set up the Perl symlink on Linux to make Bugzilla work.
+	      Your mileage may vary; if you are running on Solaris, you probably need to subsitute
+	      "/usr/local/bin/perl" for "/usr/bin/perl" below; if on certain other UNIX systems,
+	      Perl may live in weird places like "/opt/perl".  As root, run these commands:
+	      <PROGRAMLISTING>
+bash# mkdir /usr/bonsaitools
+bash# mkdir /usr/bonsaitools/bin
+bash# ln -s /usr/bin/perl /usr/bosaitools/bin/perl
+	      </PROGRAMLISTING>
+	    </PARA>
+	  </EXAMPLE>
 	  <TIP>
 	    <PARA>
 	      If you don't have root access to set this symlink up, check out the
@@ -663,11 +677,26 @@
 	  <ERRORCODE>Now regenerating the shadow database for all bugs.</ERRORCODE>
 	  <NOTE>
 	    <PARA>
-	      The second time you run checksetup.pl, it is recommended you be the same
-	      user as your web server runs under, and that you be sure you have set the
+	      The second time you run checksetup.pl, you should become the
+	      user your web server runs as, and that you ensure you have set the
 	      "webservergroup" parameter in localconfig to match the web server's group
-	      name, if any.  Under some systems, otherwise, checksetup.pl will goof up
-	      your file permissions and make them unreadable to your web server.
+	      name, if any.  I believe, for the next release of Bugzilla, this will
+	      be fixed so that Bugzilla supports a "webserveruser" parameter in localconfig
+	      as well.
+	      <EXAMPLE>
+		<TITLE>Running checksetup.pl as the web user</TITLE>
+		<PARA>
+		  Assuming your web server runs as user "apache", and Bugzilla is installed in
+		  "/usr/local/bugzilla", here's one way to run checksetup.pl as the web server user.
+		  As root, for the <EMPHASIS>second run</EMPHASIS> of checksetup.pl, do this:
+		  <PROGRAMLISTING>
+bash# chown -R apache:apache /usr/local/bugzilla
+bash# su - apache
+bash# cd /usr/local/bugzilla
+bash# ./checksetup.pl
+		  </PROGRAMLISTING>
+		</PARA>
+	      </EXAMPLE>
 	    </PARA>
 	  </NOTE>
 	</PARA>
@@ -680,7 +709,7 @@
       </SECTION>
 
       <SECTION>
-	<TITLE>Setting Up Maintainers Manuall (Optional)</TITLE>
+	<TITLE>Setting Up Maintainers Manually (Optional)</TITLE>
 	<PARA>
 	  If you want to add someone else to every group by hand, you can do it
 	  by typing the appropriate MySQL commands.  Run '<COMPUTEROUTPUT>
@@ -1295,6 +1324,56 @@ open SENDMAIL, "|\"C:/General/Web/tools/Windmail 4.0 Beta/windmail\" -t > mail.l
 	  </PROCEDURE>
 	</BLOCKQUOTE>
       </TIP>
+      <TIP>
+	<PARA>
+	  This was some late breaking information from Jan Evert.  Sorry for the lack of formatting.
+	</PARA>
+	<LITERALLAYOUT>
+I'm busy installing bugzilla on a WinNT machine and I thought I'd notify you
+at this moment of the commments I have to section 2.2.1 of the bugzilla
+guide (at http://www.trilobyte.net/barnsons/html/).
+
+Step 1:
+I've used apache, installation is really straightforward.
+After reading the Unix installation instructions, I found that it is
+necessary to add the ExecCGI option to the bugzilla directory. Also the
+'AddHandler' line for .cgi is by default commented out.
+
+Step 3: although just a detail, 'ppm install &lt;module%gt;' will also work
+(wihtout .ppd). And, it can also download these automatically from
+ActiveState.
+
+Step 4: although I have cygwin installed, it seems that it is not necessary.
+On my machine cygwin is not in the PATH and everything seems to work as
+expected.
+However, I've not used everything yet.
+
+Step 6: the 'bugs_password' given in SQL command d needs to be edited into
+localconfig later on (Step 7) if the password is not empty. I've also edited
+it into globals.pl, but I'm not sure that is needed. In both places, the
+variable is named db_pass.
+
+Step 8: all the sendmail replacements mentioned are not as simple as
+described there. Since I am not familiar (yet) with perl, I don't have any
+mail working yet.
+
+Step 9: in globals.pl the encrypt() call can be replaced by just the
+unencrypted password. In CGI.pl, the complete SQL command can be removed.
+
+Step 11: I've only changed the #! lines in *.cgi. I haven't noticed problems
+with the system() call yet.
+There seem to be only four system() called programs: processmail.pl (handled
+by step 10), syncshadowdb (which should probably get the same treatment as
+processmail.pl), diff and mysqldump. The last one is only needed with the
+shadowdb feature (which I don't use).
+
+There seems to be one step missing: copying the bugzilla files somehwere
+that apache can serve them.
+
+Just noticed the updated guide... Brian's comment is new. His first comment
+will work, but opens up a huge security hole.
+	</LITERALLAYOUT>
+      </TIP>
     </SECTION>
   </SECTION>
 </CHAPTER>