I finally found this post which presented a solution:

“Turn off MultiViews. It seems when MultiViews is enabled there is confusion between MultiViews and the RewriteRules. So if you go to /user there will be no problem, MultiViews will translate it to /user.php. However when you go to /user/blah/login/blah or one of the other more complex clean URLs it gets confused.”

Adding “Options -Multiviews” to my .htaccess file fixed the problem. Not sure why this only happens on my GoDaddy account and not locally or at our other hosting accounts. Is this the one and only error that results from Multiviews and ModRewrite colliding, or are there others? If so, maybe I’ll shut off Multiviews on all my web sites until I need to add multiple language support.

Using Apache’s Rewrite Engine to Force the use of one Server Name

We can consolidate all visitors to a single, canonical form of the server name portion of our URL using the Apache rewrite engine. The Apache documentation’s Rewriting Guide presents example code related to this case:

   RewriteCond %{HTTP_HOST}   !^www\\.domain\\.name [NC]
   RewriteCond %{HTTP_HOST}   !^$
   RewriteRule ^/(.*)         http://www.domain.name/$1 [L,R]

I tried this code on two different ISP accounts and could not get it to work. After checking all sorts of blind alleys, I realized that none of my other rewriting rules started with a slash, so I took it (shown in red) out and the rule started working. Either the example in the Apache manual is wrong, or some server installations pass the opening slash to the engine and others (like my two ISPs) do not.

Although the example now worked, it required hand-editing for each new site. So I wrote the following rule set which can be inserted into any root .htaccess file:

   # Force top-level "domain.com" requests to "www.domain.com":
   RewriteCond %{HTTP_HOST}   !^www\\. [NC]
   RewriteCond %{HTTP_HOST}   ^[^.]+\\.(com|edu|net|org)$ [NC]
   RewriteRule (.*)           http://www.%{HTTP_HOST}/$1 [R=permanent,L]
   # NOTE: Other rules must follow the www rule:
   RewriteRule ^sitemap.xml   sitemap.php [NC]

The second rewrite condition restricts the rule to primary domain requests, preventing intranet, subdomain, and/or localhost accesses from being rewritten. I also set the force redirect (R) flag code to permanent (301). The last rule (L) flag instructs the engine to stop rewriting and return the redirect at this point. The browser receives the 301 message and re-requests the page using the canonical form. Canonical page requests are scanned by any other rewriting rules, which should always follow the renaming rules.

To Prefix or Not to Prefix, That is the Question

My final rule set above chooses the “www” variant as the canonical form. However, the WWW is Deprecated folks advocate choosing the non-prefixed form — “use of the www subdomain is redundant and time consuming to communicate. The internet, media, and society are all better off without it.”

Excellent point, but small sites must follow the real-world trendsetters in matters like this. A quick survey shows that yahoo.com, google.com, and msn.com all choose “www” as their canonical URL format.

openSUSE 10.2

• Apache2, PHP 5.2, mod_php, mod_rewrite.
• PHP magic_quotes_gpc is set to off in openSUSE (the proper choice, but not the PHP default as I painfully learned when installing at the ISPs).
• PEAR supported in the Apache PHP include path.
• Subdirectories written into by the application (e.g. Smarty template compilation area) need world-write privilege.

GoDaddy Hosting

• Apache1.3, PHP4 (5.1.4 optional), CGI/fastCGI, mod_rewrite.
• Cannot use php_flag because using CGI, must use php5.ini instead.
• Switch from PHP 4 to 5 in .htaccess:
  AddHandler x-httpd-php5 .php
  AddHandler x-httpd-php .php4
• PHP magic_quotes_gpc on by default, turn off with local php5.ini file.
• AllowOverride Options disabled, can’t use in .htaccess.
• Files created by web site users (i.e. by the httpd user) have the same uid/gid as my ftp login user. An excellent configuration approach, as I don’t need to give world write privileges to local data subdirectories.
• ini_set(’session.cache_limiter’, ‘private’) causes server 500 error.

A2 Hosting

• Apache 1.x (server_signature empty), PHP 5.2, mod_php, mod_rewrite.
• PHP magic_quotes_gpc is on by default, turn off using php_flag (here is the Running PHP as an Apache Module PHP man page describing how to use php.ini directives within .htaccess).
• Subdirectories written to by the application need world-write privilege. My ftp area is a public_html directory, so A2 uses mod_userdir. The home directory looks similar to my local workstation.
• ini_set(’session.cache_limiter’, ‘private’) works fine. Moved this parameter to a php_flag directive.
• A2 mentions PEAR support on their web page, but they don’t add the directory to the PHP include path and only offer a handful of modules. Will add modules per customer request, but what will happen if they move my account to a different server?

Web Hosting Requirements

• PHP Extensions: CURL, XMLWriter.
• Apache Modules: rewrite.

YaST isn’t good at all facets of Apache configuration so some editing of conf files may eventually be needed. If manual editing is required, why not use it exclusively? Because once you go manual, you can’t switch back to YaST when major changes are needed. I like the fact that if I install a new web application that needs several additional Apache modules, I can use YaST to enable them in a couple of minutes, often without having to learn anything about them.

I also like the fact that using YaST to configure Apache will give me a configuration closely matched to thousands of other openSUSE Apache servers. This makes it likely that I will get a functional, robust httpd set up at the start. Then I can incrementally add modules and customizations as needed, testing as I go.

Following is a YaST-based recipe to install a straightforward httpd configuration with Perl, PHP, and mod_userdir enabled. Subversion, WebDAV, and virtual host support are also added (using some conf file editing). Finally, the added bookkeeping steps that allow YaST and hand-edited conf files to co-exist are presented.

Part I: Content-Independent Configuration

Part 1 installs a functional (but empty) httpd server with all modules and parameters properly configured. Connections to the site-specific content are discussed in Part 2.

1. OpenSUSE scatters Apache conf files among /etc/apache2 and its conf.d, sysconfig.d and vhosts.d sub-directories. Keep a copy of the original conf files to determine what YaST has done and add source code control repositories to manage manually edited files:
   • cd /etc/apache2
   • mkdir ORIG; cp -p *.conf ORIG
   • mkdir RCS
   • Repeat for the three “.d” subdirectories.
2. Start YaST/ Network Services/ HTTP Server:
   • Turn on php, perl, python and/or ruby in a special configuration page that only appears once (one can still turn these on/off later, but it’s easier to do here).
   • Accept defaults in the Server Wizard (5 pages), except choose Start When Booting on page 5.
   • Click Advanced Configuration.
   • In the Server Modules tab, enable dav, dav_fs, info, rewrite and status.
   • Needed to Add Module for dav_svn but the YaST screen would not accept input, so I hit Finish (will add in Step 3).
     
   • The server starts. http://localhost just says “It works!” instead of the normal Apache welcome page. Didn’t like this so I copied index.html from an old SUSE 10.0 installation.
   • Read the comments in all of the /etc/apache2/conf.d/*.conf files, some of which are controlled by IfDefine blocks. For my installation, I learned I needed to add the SVN_DOC and SVN_VIEWCVS flags (next step).
3. Start YaST/ System/ sysconfig Editor:
   • Select Network, WWW, Apache2.
   • Highlight APACHE_MODULES. Add dav_svn into the Modules line. Note: Don’t hand-edit dav_svn into /etc/apache2/sysconfig.d/loadmodule.conf, as YaST will just remove it next time it runs.
   • Highlight APACHE_SERVER_FLAGS. Type “SVN_DOC SVN_VIEWCVS” into the text field.
   • Finish.
4. A diff of ORIG/default-server.conf with the one YaST created shows that YaST removed the mod_userdir section, changed indents, and added ServerName and ServerAdmin. Thus I chose the original distribution .conf as my starting point:
   • mv default-server.conf{,.YAST}
   • cp ORIG/default-server.conf .

   • ci -l default-server.conf
   • Edit with a text editor and copy the ServerName and ServerAdmin directives from the YaST version into default-server.conf.
   • ci -l default-server.conf
5. Restart YaST/ Network Services/ HTTP Server:
   • Select the Server Modules tab and verify that the dav_svn module appears.
   • Exit or Abort.
   • Note: from this point forward, if YaST/HTTP Server is re-run and Finish is clicked, default-server.conf and /etc/sysconfig/apache2 will be overwritten. Capture a snapshot before running or retrieve original from RCS archive afterward.
6. Check the syntax of all configuration files and reload httpd:
   rcapache2 restart-hup
7. Browse http://localhost/server-info and server-status. Verify all desired modules are present and running.
8. Browse //localhost/manual and localhost/svn-manual to see documentation.

The content-independent phase of installation is complete.

Part II: Serving Local Site Content

To prepare for Part 2, load all content files that are outside of the server document root (e.g. Subversion repositories, WebDAV directories, and user public_html areas). I keep my Subversion repositories under /home/wwwrun/svn, giving them the same owner and group as the httpd process.

1. Verify that browsing a http://localhost/~<username> directory works.
2. Subversion repository configuration goes in the /etc/apache2/conf.d/subversion.conf file. I piggybacked the WebDAV configuration into this file rather than creating a separate file: subversion.conf. Also, I add Basic Auth to ViewVC in subversion.viewvc.conf (see earlier blog entry for an explanation).
3. Use htpasswd2 to create the basic authentication password file.
4. Create a /var/lock/apache2 directory (user wwwrun, group www).
5. rcapache2 configtest
6. rcapache2 restart-hup
7. Browse http://localhost/svn/<reponame>. Username and password are requested and the repository appears. Run RapidSVN from a Windows machine to verify connectivity.
8. Edit /srv/viewvc/viewvc.conf to add root or root_parents, default root, and mailto.
9. Browse http://localhost/viewvc , username and password are requested, then the ViewVC page appears. Click on the “ViewVC Help” hyperlink and the documentation appears.
10. Using Konqueror, browse webdav://localhost/fs and a folder view of the WebDAV folder appears.
11. See this blog entry for details of connecting to WebDAV via WindowsXP.

All of my local Subversion, WebDAV, and web page content is now available via Apache.

Part III: Virtual Hosts

Finally I’ll add virtual hosts for my various development, prototype, and staging areas. The YaST HTTP Server GUI offers a screen to do this, but I chose to start with the as-delivered file just as with default-server.conf.

1. Create a new conf file in /etc/apache2/vhosts.d (e.g. LLvhost.conf in my case). I copied the vhost.template as the starting point.
2. I defined four virtual servers:
   • localhost – contains only a ServerName statement to serve as the default server.
   • llxxx – three name-based servers that have document roots in various code development sub-directories. Each of these gets a separate set of error and access log files.
3. Uncomment the NameVirtualHost *:80 line in /etc/apache2/listen.conf.
4. Add the three name-based server names to /etc/hosts as synonyms for localhost.
5. rcapache2 configtest
6. rcapache2 restart-hup
7. Browse http://llxxx and the virtual host content appears. Verify that log information appears in the correct file pair in /var/log/apache2.

Part IV: Configuration Control and Maintenance

The Apache server installation is now complete. But adding source code control is necessary to safely re-run YaST/ Network Services/ HTTP Server Configuration in the future. Whenever HTTP Server Configuration is ended with Save or Finish, any of the conf files may be overwritten, obliterating prior manual edits. Source code control allows us to manage and resolve this conflict.

Using the unaltered conf files in the ORIG directories as references, perform a diff of all of the conf files to learn which have been customized. Any altered conf files that were hand-edited should be placed under configuration control (e.g. CVS, Subversion, RCS). Consider controlling the YaST-altered files as well.

I maintain five files in RCS: default-server.conf, mod_userdir.conf, subversion.conf, subversion.viewvc.conf, LLvhost.conf. After saving any new HTTP Server Configuration session, I use rcsdiff to learn what changes have been made to these files. Review the changes and either restore the last version from RCS or check in a new revision as appropriate.

Comments:

• I’m using AuthType Basic for svn, viewcvs, and filesystem DAV access. It provides some security, and is also necessary for WindowsXP, which apparently will not connect to a Web Folder with no authentication.
• The viewCVS location needs its own authentication, since this tool accesses the SVN repository directly using the file: protocol. In doing so, it bypasses the http server /svn location and its associated authentication.
• The SVNParentPath is convenient because new SVN repositories can be added without editing the conf file. The downside is that different users can’t be restricted to particular repositories or given different access privileges.
• ViewCVS has an additional configuration file /srv/viewcvs/viewcvs.conf that must contain the roots of all repositories, plus a few other items.

Add Network Place failed as described in a Caltech web page found with Google(Windows XP WebDAV folder apache). I will leave this until a WinXP process actually needs to connect.

As detailed on 14 Nov, the lack of httpd authentication prevents svn updates from getting an author assigned. So now I’m installing authentication per the Subversion instructions:

• htpasswd2 -cm /etc/apache2/basicHTTPpasswd bozzie
• Cut & pasted the Auth{Type,Name,User} directives from the instructions into the <Location> /svn section of my default-server.conf file. Cut & pasted the Require valid-user only for write actions, also from the instructions.

Re-created the repository and imported. The import challenged for a password and the newly checked-in revision finally has an author.

SVN is ready for use, I think.

ViewCVS (ViewVC)

SuSE installs this package in /srv/viewcvs. Finally found some installation instructions by downloading the current version from the Tigris web site and ad-libbing from the viewVC instructions.

Summary of mods to default-server.conf:

• Alias /viewcvs-docroot /srv/viewcvs/templates/docroot
• ScriptAlias /viewcvs /srv/viewcvs/www/cgi/viewcvs.cgi
• Plus viewcvs.conf must be edited.

ViewCVS presents a serviceable graphic interface to SVN, which I imagine is even better in the current viewVC version. There is also a graphing interface of some sort that I haven’t looked into yet.

Apache Modifications:

• Added mod_dav & mod_dav_syn using the SuSE Yast, Network Services, HTTPD screen. This GUI stores data in /etc/sysconfig/apache2, which is then transferred into /etc/apache2/sysconfig.d/loadmodule.conf, where we are warned not to edit this file. SuSE states that the purpose of this is to allow easy updating of Apache without having to re-edit all of the conf files. I’m not convinced.

• Added <Location /svn> directive to Apache default-server.conf

Subversion Setup:

• Create Subversion repository (as user that runs httpd):
  svnadmin create --fs-type fsfs ~/webdav/svn/llacct
• Import trunk/branches/tags into ll as a one-project repository: svn import ~/tmp/IMPORT http://localhost/svn/ll -m "Leads Lander Client Account"
• View project: svn checkout http://localhost/svn/ll/trunk
• Am struggling with my config file and $Id$ keywords.