Learning to hate cpanel (or, getting subversion HTTP interface working with cpanel)
At least a couple of readers have emailed me to point out my SVN repository has been down for a number of weeks. It’s not that I haven’t been trying to get it back up, but it’s been a struggle. As of this morning, it’s finally back online. If you care what the trouble was, read on.
I recently had to move one of my VPS instances from an Ubuntu box with no fancy pointy-clicky web admin interface to a CentOS box running cPanel. I’d heard lots of people raving about cPanel, so I figured it’d be a nice to have. Little did I know.
cPanel works by creating a web interface for nigh on every aspect of running a web host. With cPanel, chances are if you do anything the way you would a vanilla Linux box, you’re doing it wrong. This goes double for anything pertaining to Apache configuration.
I’ve installed SVN and its corresponding Apache module probably at least a dozen times on a blend of Linux and FreeBSD boxes over the years. Every time it’s been among the easiest, most brainless installs I’ve had to do. I stupidly thought cPanel wouldn’t change that. But of course it did.
First off, you can’t just recompile apache from source the way you normally would. cPanel uses what they jokingly call ‘EasyApache’, where ‘easy’ here means ‘opposite of the Apache you’re used to, and way less flexible’. To their credit, things that the cPanel guys thought of are pretty easy with EasyApache. There’s both a web and console GUI for rebuilding Apache that lets you pick what modules to compile in, what version of Apache and PHP to build, and what MPM you want to use. No problem there, once I figured out I needed to use the script.
But then the trouble started. I downloaded SVN, and ran configure on it:
sudo ./configure --with-apxs=/usr/local/apache/bin/apxs --with-apr=/usr/local/apache/bin/apr-1-config --with-apr-util=/home/cpeasyapache/src/httpd-2.2.11/srclib/apr-util
Note I had to run this as root because some of the source I needed was in the home directory of another user, cpeasyapache. Nice.
configure noted that I was missing neon and sqlite, so I downloaded the source tarballs referenced in configure‘s output, and away we went. It built fine, and sudo make install was uneventful.
At this point I’d already noticed that editing the httpd.conf file directly was Not Cool with cPanel. I noticed this because there’s a massive warning comment block at the top of the file. Instead you use the web interface to edit various include files pulled in by the main conf file. LoadModule calls belong in the ‘Pre Main’ include, which you can edit from the WHM control panel. (Side note: cPanel has two web interfaces on two different ports: 2086 is the WHM interface for configuring the whole box as root; port 2082 is for non-privileged users to configure domains and databases and stuff).
Here’s what I put in the Pre Main include for Apache 2.2.11:
<IfModule mod_dav.c>
LoadModule dav_svn_module modules/mod_dav_svn.so
LoadModule authz_svn_module modules/mod_authz_svn.so
</IfModule>
Since the SVN make install already put the relevant modules in the modules directory, saving this include file and automatically restarting the Apache service worked in as much as apachectl -d DUMP_MODULES listed the two SVN modules as loaded.
Next, I had to figure out where to put the Location entry for my svn.apocryph.org virtual host. I found this article which explained how global and vhost-specific custom directives can be added. In my case my SVN domain was an add-on domain for my existing user account, so I created a svn.conf file at /usr/local/apache/conf/userdata/std/2/anelson/svn.anelson.bulshytt.com that went a little something like this:
# Configure subversion to handle the /svn stuff
<Location /svn>
DAV svn
SVNPath /var/svn/repos
# how to authenticate a user
AuthType Basic
AuthName "Subversion repository"
AuthUserFile /etc/svn-auth-file
# For any operations other than these, require an authenticated user.
<LimitExcept GET PROPFIND OPTIONS REPORT>
Require valid-user
</LimitExcept>
</Location>
Obviously I used htpasswd to create the /etc/svn-auth-file file.
This all seemed straightforward, then I ran /scripts/verify_vhost_includes as per the above article, and I got this:
Testing /usr/local/apache/conf/userdata/std/2/anelson/svn.anelson.bulshytt.com/svn.conf...FAILED
No changes made without --commit flag
I then tried it with the --show-test-output switch:
Testing /usr/local/apache/conf/userdata/std/2/anelson/svn.anelson.bulshytt.com/svn.conf...FAILED
No changes made without --commit flag
[TEST RESULTS]
Syntax error on line 3 of /usr/local/apache/conf/userdata/std/2/anelson/svn.anelson.bulshytt.com/svn.conf:
Unknown DAV provider: svn
[/TEST RESULTS]
‘Unknown DAV provider’? But I verified the SVN modules are loaded! Tons of googling mostly yields assclowns who forgot the LoadModule directive, but that’s not me. Finally I ran across this guy bitching in the cpanel forums. He’s having the exact same problem. The responses from the cPanel guys are telling. Basically since the SVN module isn’t one they thought of, that makes this a ‘custom’ configuration that would require an EasyApache Custom Module to make work right. Fuck that. What happened to ‘Easy’?
The good news is this excerpt:
If we only use /scripts/ensure_vhost_includes –user=domain and restart apache, subversion works perfectly, but wonder why the “DAV svn” is not recognize as valid?
Interesting. So the change will fail to verify, but if you force the include anyway, everything works? Let’s try it:
/scripts/ensure_vhost_includes --user=username
/scripts/rebuildhttpdconf
/scripts/restartsrv_httpd
Voila! svn.apocryph.org/svn now shows the SVN repository. But there are downsides:
- The EasyApache builder doesn’t know about the SVN modules, so whenever I rebuild Apache the two modules will be clobbered, which will cause my Pre Main include modifications to fail to load the SVN modules. So to rebuild I’ll have to comment out those LoadModule lines, rebuild, repeat the ‘make install’ command for SVN, then restore the LoadModule lines.
- the verify_vhost_includes script will always complain about the change I made for my svn.apocryph.org vhost. If I forget I did this, I might make some other vhost change down the road and scratch my head wondering why this SVN stuff that’s worked forever isn’t working now
- It took fucking hours to get going, with absolutely zero official documentation from cPanel
At this point, if I had the ability to move my VPS instance again, to a host without cPanel, I absolutely would. It gets in my way at every step of the way, and the pointy-clicky GUI bullshit is nearly worthless to me as it either automates things I already can do comfortably with the command line, or makes simplifying assumptions that don’t meet my requirements.
UPDATE: After I posted this I tried to commit to the repository, only to discover I could not. Any attempts to commit first prompted me for my credentials, as expected, but when creds were provided I got this failure:
Commit failed (details follow):
Server sent unexpected return value (403 Forbidden)
in response to PUT request for
'/svn/!svn/wrk/d3def008-ccd0-11dd-88ba-e715122b690d/test.txt'
This despite having correct file system permissions. I Googled around and found another guy, also on a VPS as it happens, who solved this by adding
Order allow,deny
Allow from all
I tried adding that to the Location block in my svn.conf file, and sure enough that did the trick. But why? My sense is there’s some module or security setting that’s blocking PUT requests, but I can’t imagine what it would be. Remind me again why this managed VPS thing is better than building my own VPS from scratch?
Moving to Future Hosting, Part III
In this episode of Moving to FutureHosting, I’ll be installing and configuring Apache2, the mpm-worker multiprocessing module, passenger (aka mod_rails), Ruby, Ruby on Rails, and all associated cruft. I’ve done this before on Ubuntu using aptitude, but since FutureHosting runs CentOS, which uses the yum package manager, this will be a new experience for me.
Apache2
My FutureHosting box came with Apache2. /usr/sbin/httpd -v reports Server version: Apache/2.2.9 (Unix), which seems fine.
Which MPM?
Apache2 supports multiple concurrency models for handling more than one connection at once. Each model is implemented in a Multi-Processing Model (MPM). prefork-mpm causes Apache to fork off a number of processes on startup, each of which will process some requests. worker-mpm creates multiple worker threads within a process to handle requests. I’ve read that the latest versions of Passenger work well with worker-mpm, which has the added advantage of being less memory-hungry than a bunch of forked processes.
I don’t know how to tell what MPM the existing install is using. I grep‘d all the LoadModule directives in the HTTP configuration files in /etc/httpd/conf/ but I don’t see anything pertaining to an mpm. /usr/sbin/httpd -l lists prefork.c but no worker.c. This tells me the version of Apache that comes with CentOS 5 is built without support for worker-mpm. Ubuntu has handy aptitude packages for both MPMs, so you install the one you want and it configures Apache accordingly. CentOS seems to be missing that. I’ll go with prefork for now until I can figure out how to change it.
Ruby
The latest version of Ruby available as a yum package is 1.8.5-5. Um, no. That’s ancient. That means I have to build from source. Out-fucking-standing. Why does anyone run CentOS anyway?
No matter, the forum thread here pointed me to a custom repository some guy is running, with the latest Ruby 1.8.6 bits. Pathetic that it came to that. I installed ruby, ruby-devel, ruby-irb, ruby-mysql, and ruby-rdoc.
Ruby Gems
I installed Ruby Gems from the same source as above, which then pulled in a dizzying dependency chain of additional packages, nearly 60 (!!) in all. The installation seemed to work, though, so I can’t complain.
Ruby on Rails
Rails is easy. sudo gem install rails. QED.
Passenger
Phusion Passenger runs Rails apps in Apache fast and reliably. What more is there to say?
It’s distributed as a Ruby gem, so
sudo gem install passenger
And Passenger is installed. But it needs to be configured as a module in Apache2. For that there’s
sudo passenger-install-apache2-module
Which builds the Apache module from source, and spits out the appropriate verbiage for httpd.conf. The httpd configuration stuff is in /etc/httpd/conf, which includes files in /etc/httpd/conf/extras. In keeping with this idiom, I created a new file, /etc/httpd/conf/httpd-passenger.conf, to contain the Passenger-related configuration:
LoadModule passenger_module /usr/lib/ruby/gems/1.8/gems/passenger-2.0.3/ext/apache2/mod_passenger.so
PassengerRoot /usr/lib/ruby/gems/1.8/gems/passenger-2.0.3
PassengerRuby /usr/bin/ruby
which I include in /etc/httpd/conf/httpd.conf using an Include directive.
After that, sudo apachectl restart and the module was loaded.
Ruby Enterprise Edition
Phusion (makers of Passenger) offer an ‘enterprise’ edition of the Ruby interpreter that works with Passenger to reduce memory load and increase performance. I’ve never used it before, but I’d like to give it a try.
After downloading and extracting the source tarball, there’s no familiar configure/make/make install cycle. Instead there’s an installer script that takes you through the installation.
I accepted the default install directory (/opt/ruby-enterprise-1.8.6-20080810), and off it went building from source. I don’t have any Postgres components installed, so it choked trying to install Postgres support, which I don’t give a shit about. I can always install it later with /opt/ruby-enterprise-1.8.6-20080810/bin/ruby /opt/ruby-enterprise-1.8.6-20080810/bin/gem install postgres.
And that was it. To cause Passenger to use Ruby EE, I changed the PassengerRuby line in the httpd-passenger.conf file to:
PassengerRuby /opt/ruby-enterprise-1.8.6-20080810/bin/ruby
Too easy!
Testing
To verify Passenger and Ruby EE are working, I need a Rails app to serve. I’ll create one in my home directory and make Apache use that as the root for the default VirtualHost:
rails passtest
to create the project.
script/generate controller itworked
failed with:
Rails requires RubyGems >= 1.1.1 (you have 0.9.4). Please `gem update --system` and try again.
Yikes! I had no idea I was running ancient gems. sudo gem update --system made quick work of that problem.
Now, as I was saying,
script/generate controller itworked
It spit out an annoying error:
/usr/lib/ruby/gems/1.8/gems/rails-2.1.1/lib/rails_generator/lookup.rb:211:in 'each' is outdated
but otherwise seemed to work.
Now ~anelson/passtest/public is the public root for my rails app, which I need to point Passenger to.
For now I’ll just use one of the VirtualHost entries in /etc/httpd/conf/extras/httpd-vhost.conf, since I’m just testing.
And…it worked! I pointed DocumentRoot to the public folder in my Rails project, and got the default Rails screen. It seems to be working. Yay.
Added a self-signed cert
I added a self-signed cert to apocryph.org, to protect passwords and sensitive content from nosy corporate networks. You can now browse apocryph.org via the https:// prefix.
I used a self-signed certificate, which isn’t as secure as a cert you’d buy from VeriSign or Thawte or whatever, but it’s also free. For thwarting casual eavesdropping attacks (and, for saavy users at least, MiTM attacks too), it gets the job done.
I followed this great tutorial. The only thing it didn’t cover is setting up SSL under Apache 2.2 on FreeBSD. But it couldn’t be simpler; in my /usr/local/etc/apache22/httpd.conf, I uncommented the Include directive to include extras/httpd-ssl.conf, then edited that file to fix up a couple paths, and I was set. Too easy.
Added a virtual host to Apache and installing WordPress on FreeBSD
Recently I had cause to set up a WordPress blog engine on a virtual host on bonzo. My experience follows:
First I need to set up DNS for the domain. The owner of the domain used the registrar’s control panel to set the authoritative nameservers to ns1.afraid.org through ns4.afraid.org, which are the nameservers provided by FreeDNS.
Next, I log into my FreeDNS account, add the new domain to my domains, and point the domain and www. to bonzo’s IP address. I don’t have mail setup yet, so I’ll ignore the MX record for now.
Now, querying the domain in a web browser should bring me to my site on bonzo…sure enough, it does.
The next step isto set up virtual hosting on bonzo, which I’ve not yet had a need to do. The Apache docs on virtual hosting refer to virtual hosting by host name ‘name-based virtual hosting’.
It’s pretty straightforward; you define what IP addresses and host names you want to associate with what server roots. There is one huge gotcha:
(From the name-based virtual hosting docs 
Now when a request arrives, the server will first check if it is using an IP address that matches the
NameVirtualHost. If it is, then it will look at each<VirtualHost>section with a matching IP address and try to find one where theServerNameorServerAliasmatches the requested hostname. If it finds one, then it uses the configuration for that server. If no matching virtual host is found, then the first listed virtual host that matches the IP address will be used.As a consequence, the first listed virtual host is the default virtual host. The
DocumentRootfrom the main server will never be used when an IP address matches theNameVirtualHostdirective. If you would like to have a special configuration for requests that do not match any particular virtual host, simply put that configuration in a<VirtualHost>container and list it first in the configuration file.
This is definitely not what I would expect. It means I have to make sure that the current server root is present as the first <VirtualHost> element, else my existing site will break.
So, first I’ll create the <VirtualHost> in /usr/local/etc/apache22/httpd.conf entry for my existing doc root and make sure that works:
# Apply virtual hosts to all requests
NameVirtualHost *:80
# The 'default' virtual host, used when the host doesn't match one of the others
<VirtualHost *:80>
DocumentRoot /usr/local/www/drupal
</VirtualHost>
Next, an apachectl graceful to restart with the new config, and all is well. Requests to apocryph.org and bonzo.celatrix.com are still handled by my Drupal install as before.
Now I can create a separate doc root for the new domain, and point queries to it there. I’ll use /usr/local/www/craeton.com/:
bonzo# mkdir /usr/local/www/craeton.com
bonzo# chown www /usr/local/www/craeton.com/
bonzo# chgrp www /usr/local/www/craeton.com/
And another <VirtualHost> in httpd.conf accordingly:
<VirtualHost *:80>
ServerName craeton.com
ServerAlias *.craeton.com
DocumentRoot /usr/local/www/craeton.com
</VirtualHost>
Then a <Directory> entry to define the behavior of the /usr/local/www/craeton.com directory when exposed by Apache:
# DocRoot for the craeton.com virtual host
<Directory "/usr/local/www/craeton.com">
Options Indexes FollowSymLinks
AllowOverride None
Order allow,deny
Allow from all
</Directory>
I basically just copied the settings from the <Directory> entry for my default doc root.
So now, requests to craeton.com should resolve to this new folder. I’ll drop a simple index.html file and see what happens…it works.
Next I’ll need to create a MySQL database, user, and password for WordPress to use. First, the database:
$ mysqladmin -u root create wp_craeton -p
Enter password:
$
Now the user and password:
mysql -u root -p
Enter password:
Welcome to the MySQL monitor. Commands end with ; or \g.
Your MySQL connection id is 16893 to server version: 5.0.9-beta
Type 'help;' or '\h' for help. Type '\c' to clear the buffer.
mysql> grant all privileges on wp_craeton.* to 'wp_craeton'@'localhost' identified by '[secret]';
Query OK, 0 rows affected (0.06 sec)
mysql> flush privileges;
Query OK, 0 rows affected (0.03 sec)
Too easy.
Now I’m ready to install WordPress into this folder. There’s a port in /usr/ports/www/wordpress, but PHP apps like WordPress are so easy to get running I’d rather grab the latest bits from wordpress.org so I have control over the install.
I’ll download the latest directly on bonzo via my trusty SSH session.
$ wget http://wordpress.org/latest.tar.gz
$ tar xzf latest.tar.gz
$ ls
index.html latest.tar.gz wordpress
So, it extracted into a ‘wordpress’ folder. I don’t want that; I want the WordPress stuff immediately under the creaton.com/ folder. Easy enough:
mv wordpress/* .
Looking at the readme.html included in the tarball, there is a ‘Famous Five-minute Install’:
- Unzip the package in an empty directory
- Open up
wp-config-sample.phpwith a text editor like WordPad or similar and fill in your database connection details- Save the file as
wp-config.php- Upload everything.
- Open
/wp-admin/install.phpin your browser. This should setup the tables needed for your blog. If there is an error, double check yourwp-config.phpfile, and try again. If it fails again, please go to the support forums with as much data as you can gather.- Note the password given to you.
- The install script should then send you to the login page. Sign in with the username admin and the password generated during the installation. You can then click on ‘Profile’ to change the password.
Ok, item 1 is done. I’ll copy wp-config-sample.php to wp-config.php and put the DB connection info in it.
It was pretty easy; I just edited the DB info as it said:
<?php
// ** MySQL settings ** //
define('DB_NAME', 'wp_craeton'); // The name of the database
define('DB_USER', 'wp_craeton'); // Your MySQL username
define('DB_PASSWORD', '[secret]'); // ...and password
define('DB_HOST', 'localhost'); // 99% chance you won't need to change this value
// You can have multiple installations in one database if you give each a unique prefix
$table_prefix = 'wp_'; // Only numbers, letters, and underscores please!
// Change this to localize WordPress. A corresponding MO file for the
// chosen language must be installed to wp-includes/languages.
// For example, install de.mo to wp-includes/languages and set WPLANG to 'de'
// to enable German language support.
define ('WPLANG', '');
/* That's all, stop editing! Happy blogging. */
define('ABSPATH', dirname(__FILE__).'/');
require_once(ABSPATH.'wp-settings.php');
?>
Step 3 is equivalent to the copy to wp-config.php and thus doesn’t apply.
Step 4 is not applicable either, since I’m doing all this directly on bonzo via SSH.
In step 5, I navigate to the craeton.com/wp-admin/install.php. I get a splash screen and a ‘First Step’ link, which I click.
The first step in this install process prompts for a blog title and an email address. I’ll provide it and move on.
In the next screen it pauses to create the database tables, then generates a temporary password for the admin user. I’m admonished to not forget it, and given a link to the login page. I’ll go there now.
Logging in w/ the admin account and random password, I get a clean, simple admin GUI. I’ll change the password to something memorable, and declare victory. Too easy!
User directories not included in default Apache 2.2 config?
I just recently upgraded bonzo to Apache 2.2. I noticed that user directories, (eg, apocryph.org/~anelson mapping to /home/anelson/public_html/ don’t work anymore. What gives?
The httpd.conf entry in question is:
#
# UserDir: The name of the directory that is appended onto a user's home
# directory if a ~user request is received.
#
<IfModule mod_userdir.c>
UserDir public_html
UserDir disabled root toor daemon operator bin tty kmem games news man sshd bind proxy _pflogd uucp pop www nobody mailnull smmsp
#
# Control access to UserDir directories. The following is an example
# for a site where these directories are restricted to read-only.
#
<Directory /home/*/public_html>
AllowOverride Options FileInfo AuthConfig Limit Indexes
Options MultiViews Indexes SymLinksIfOwnerMatch IncludesNoExec
<Limit GET POST OPTIONS PROPFIND>
Order allow,deny
Allow from all
</Limit>
<LimitExcept GET POST OPTIONS PROPFIND>
Order deny,allow
Deny from all
</LimitExcept>
</Directory>
</IfModule>
This isn’t in the default config for Apache 2.2. Too bad. The userdir module is loaded; they’re just not enabled. I added the above and did an apachectl graceful and voila.
Upgrading bonzo to Apache 2.2
Today I went to slightly change my Apache 2.0 config on bonzo, when was greeted with a nasty error when trying to restart the process:
bonzo# apachectl restart
/libexec/ld-elf.so.1: Shared object "libexpat.so.5" not found, required by "httpd"
I suspect this is due to some of the upgrading it with with the ports tree recently. Obviously something needed a new version of libexpat, which broke my older build of Apache. I put a band-aid on the problem with:
ln -s libexpat.so.6 libexpat.so.5
in /usr/local/lib, but I don’t like running older versions of software. I noticed that Apache 2.2 is now out and in the ports tree under www/apache22. The upgrade instructions seem fairly straightforward, so I’m going to go for it.
A quick cd into /usr/ports/www/apache22, and a make show-options yield:
bonzo# make show-options
Available knobs:
By default, modules are compiled as dynamically loadable (DSO) modules.
Modules knobs philosophy:
Modules are split in categories, "make show-categories" shows you
which modules they contain. You can enable/disable/customize a category:
- To enable a category: WITH_<CATEGORY>_MODULES=yes
[WITH_PROXY_MODULES=yes]
- To disable a category: WITHOUT_<CATEGORY>_MODULES=yes
[WITHOUT_DAV_MODULES=yes]
- To customize a category: WITH_CUSTOM_<CATEGORY>
[WITH_CUSTOM_PROXY="proxy proxy_http"]
Apache-related
WITH_MPM: prefork (default)
worker
perchild (deprecated)
threadpool (testing purpose only)
WITH_HTTP_PORT: default: 80
WITH_LDAP: Enable LDAP support (mod_auth_ldap) (implies WITH_LDAP_MODULES)
WITH_(MYSQL|PGSQL|SQLITE): Enable SQL backend *dbd
WITHOUT_V4MAPPED
WITH_IPV6_V6ONLY: Don't allow IPv6 sockets to handle IPv4
connections
WITHOUT_SSL: Disable SSL support
WITH_THREADS: Enable threads support !! USE IT WITH CARE !!
WITH_DBM: Choose your DBM: bdb (Berkeley DB), gdbm or
ndbm (default)
WITH_BERKELEYDB: Choose your BerkeleyDB version: db2, db3,
db4, db41, db42 or FreeBSD (1.85)(default)
WITH_STATIC_SUPPORT: Build statically linked support binaries
WITH_STATIC_APACHE: Build a static version of httpd (implies
WITH_STATIC_MODULES)
WITH_ALL_STATIC_MODULES: All modules will be statically linked.
WITH_STATIC_MODULES: List of modules to build modules statics
(usefull for slave ports)
(They must be already enabled (i.e.
WITH_MODULES or with default configuration
use 'make show-modules', to check if they are
enabled)
WITH_MODULES: List of modules you choose
WITHOUT_MODULES: Disable selected modules
WITH_SUEXEC: Enable suExec support
SUEXEC_DOCROOT: SuExec root directory
SUEXEC_USERDIR: User subdirectory (default public_html)
SUEXEC_SAFEPATH: Set the safepath
SUEXEC_LOGFILE: Set log file for suexec (default: /var/log/httpd-suexec.log)
SUEXEC_UIDMIN: Minimal allowed UID (default 1000)
SUEXEC_GIDMIN: Minimal allowed GID (default 1000)
SUEXEC_CALLER: User allowed to call SuExec (default
${WWWOWN} (www))
SUEXEC_UMASK: Defines umask for suexec'd process(default:
unset)
WITH_DEBUG: Build a debug versoin of apache (set CFLAGS
to "-O0 -g -ggdb3" or ${DEBUG_FLAGS} and
defines WITH_EXCEPTION_HOOK too)
WITH_EXCEPTION_HOOK: Enable fatal exception hook
Optionnal patches:
WITH_EXPERIMENTAL_PATCHES Add performance patches (generally backported
from apr/httpd CVS)
Available make targets:
show-options: prints this message
show-modules: prints list of available modules
show-categories: prints list of modules sorted by category
Examples:
make WITH_STATIC_MODULES="ssl rewrite include" WITH_EXPERIMENTAL_MODULES=yes \
WITH_CUSTOM_AUTH="auth auth_dbm"
make WITHOUT_MODULES="access speling status" WITH_PROXY_MODULES=yes
make WITH_MODULES="include rewrite auth"
Note: If you define your custom options in /etc/make.conf, don't forget
to do not use quotes.
From make show-categories I get:
bonzo# make show-categories
AUTH contains these modules:
auth_basic auth_digest
AUTHN contains these modules:
authn_file authn_dbd authn_dbm authn_anon authn_default
AUTHZ contains these modules:
authz_host authz_groupfile authz_user authz_dbm authz_owner authz_default
CACHE contains these modules:
cache disk_cache file_cache mem_cache
DAV contains these modules:
dav dav_fs
EXPERIMENTAL contains these modules:
bucketeer case_filter case_filter_in ext_filter charset_lite log_forensic optional_hook_export optional_hook_import optional_fn_import optional_fn_export
LDAP contains these modules:
ldap authnz_ldap
MISC contains these modules:
actions alias asis autoindex cern_meta cgi charset_lite dbd deflate dir env expires headers imagemap include info log_config logio mime mime_magic negotiation rewrite setenvif speling status unique_id userdir usertrack vhost_alias filter version
PROXY contains these modules:
proxy proxy_connect proxy_ftp proxy_http proxy_ajp proxy_balancer
SSL contains these modules:
ssl
SUEXEC contains these modules:
suexec
THREADS contains these modules:
cgid
From make I see the defaults are:
Per default categories are:
AUTH AUTHN AUTHZ DAV CACHE MISC
Categories available:
AUTH AUTHN AUTHZ CACHE DAV EXPERIMENTAL LDAP MISC PROXY SSL SUEXEC THREADS
I also want SSL; the rest are fine. So, that’s make WITH_SSL_MODULES=yes
That seemed to work. Now the really risky move: make uninstall apache20, and make install apache22. If this goes badly, I’ll be left without a working web server.
It seemed to go okay; the make deinstall complained about a littany of stuff dependent upon apache2, and I had to change /etc/rc.conf to add apache22_enable="YES".
The configuration file httpd.conf is in /usr/local/etc/apache22, while my old was in /usr/local/etc/apache2. The Apache docs say the new config file is much simpler, so I’ll just migrate my old settings over.
I had to copy:
- the
DirectoryIndexentryindex.php - the
Aliasentries forgallery2,bytehoard, andmail - the
AddTypedirectives for PHP files LoadModuledirectives fordav_svn,authz_svn, andphp5
The first problem with these changes is:
httpd: Syntax error on line 103 of /usr/local/etc/apache22/httpd.conf: Cannot load /usr/local/libexec/apache2/mod_dav_svn.so into server: Shared object "libaprutil-0.so.9" not found, required by "libsvn_repos-1.so.0"
This is a pretty old version of the dav_svn module; I’ll disable it for now until I can build the updated version
Another problem:
httpd: Syntax error on line 105 of /usr/local/etc/apache22/httpd.conf: API module structure `php5_module' in file /usr/local/libexec/apache2/libphp5.so is garbled - perhaps this is not an Apache module DSO?
So, I’ll have to rebuild the PHP5 module as well. Awesome.
Argh, I keep running into shit along the dependency chain that I have to upgrade to build the php5-extensions. So far, pecl-magick and mysql50-client. Also have to (re)build www/mod_php5. Oddly, when I make search name=php5 I see the mod_php5 port listed as /usr/ports/www/mod_php5, but there’s no such folder in my ports tree. I’m cvsuping my ports tree just in case, but I’m not holding out hope.
Hmm, turns out the mod_php port has been removed and integrated into the PHP build process. Lame. I did a make config, checked the Apache box (and the multibyte box while I was at it), then did a make clean and a make reinstall. I’ll have to do the same thing on php5-extensions.
Ok, it looks good. Drupal is working, but Gallery is broken (requests for /gallery2 return Forbidden).
It seems the reason is that uninstalling Apache 2.0 removed the /usr/local/www/data symlink to /usr/local/www/data-dist. How lame. All my paths will change now.
Ok, all seems well. There’s only one little thing bugging me now:
bonzo# apachectl stop
bonzo# apachectl start
[Mon Jun 19 07:48:24 2006] [warn] (2)No such file or directory: Failed to enable the 'httpready' Accept Filter
I’ve done a bit of reading on the subject. Apparently, the accept filters are an optimization within Apache that takes advantage of an optimization in various OS kernels in which the accept() socket function doesn’t return until a particular filter condition is met; in the case of HTTP, that complete HTTP headers have been received from the client. I don’t really understand why this is a major performance enhancement, but I trust Apache and the FreeBSD kernel team to do the right thing.
At any rate, from this Google Groups conversation, it seems I can enable the relevant accept filters in the kernel by adding a apache22_http_accept_enable="YES" line in /etc/rc.conf. I’ll try that.
Yup, that takes care of it. Sweet.
mod_php on Apache 2, FreeBSD 6.0 doesn't automatically process .php files
I just installed the apache2 and php5 ports on aenea, and found that accessing .php files via Apache returned the PHP source code, instead of running the PHP server-side.
I had to add the following entries into /usr/local/etc/apache2/httpd.conf in order to get mod_php to pick up the files:
#Register PHP mime types
AddType application/x-httpd-php .php
AddType application/x-httpd-php-source .phps
That worked, but index.php wasn’t run automatically if I navigate to a directory. For that I added index.php to the end of the DirectoryIndex directive:
DirectoryIndex index.html index.html.var index.php
One apachectl restart later, and all was well.