Every now and then my Apache webserver becomes un-responsive, and attempting to restart it with apachectl graceful gives me the following error:

Address already in use: make_sock: could not bind to address 0.0.0.0:80

This error means that there is already a process running that is using port 80, so Apache is unable to start up and use it. To solve this problem, we need to figure out what process is currently using the port in question and kill it so that Apache can start. Use lsof to find out what is using our port:

shell> lsof -i :80
COMMAND PID USER FD TYPE DEVICE SIZE NODE NAME
httpd 23506 apache 3u IPv6 1206927465 TCP *:http (LISTEN)

You can see from the output of lsof that an httpd process already exists under PID 23506. This is simple enough to get rid of:

shell> kill -9 23506
shell> lsof -i :80
shell> apachectl start

I run lsof again after issuing the kill command to make sure that whatever was using port 80 is gone.

I received the following in my Apache error_log when attempting to load the ionCube loader in my php.ini file:

PHP Fatal error: [ionCube Loader] The Loader must appear as the first entry in the php.ini file in Unknown on line 0

This is because ionCube must be loaded before any of the Zend extensions are. So if you have the Zend extension/optimizer loaded, your php.ini should look like this to get ionCube to work:

[Zend]
zend_extension=/usr/local/ioncube/ioncube_loader_lin_5.1.so
zen_extension_ts=/usr/local/ioncube/ioncube_loader_lin_5.1_ts.so
zend_extension_manager.optimizer=/usr/local/Zend/lib/Optimizer-3.3.0
zend_extension_manager.optimizer_ts=/usr/local/Zend/lib/Optimizer_TS-3.3.0
zend_optimizer.version=3.3.0a
zend_extension=/usr/local/Zend/lib/ZendExtensionManager.so
zend_extension_ts=/usr/local/Zend/lib/ZendExtensionManager_TS.so

----------------
Now playing: Tommy McCook & The Aggrovators - A Loving Melody
via FoxyTunes

I ran into trouble when trying to pass a urlencode()'ed plus sign into a web address being processed by mod_rewrite.

$url = 'http://www.server.com/browsealpha/name+has+plus+in+it/';
$url = urlencode($url); // http://www.server.com/browsealpha/name%2Bhas%2Bplus%2Bin%2Bit/

This $url variable gets echo()'d as a link in a page, so once it's clicked and loaded in the browser, I then needed mod_rewrite to translate that to the actual URL, which is:

http://www.server.com/browsealpha.php?name=name%2Bhas%2Bplus%2Bin%2Bit

Here is the RewriteRule I was using to match:

# match any name containing any combination of letters, numbers, and the % sign (to match urlencoded URLs)
RewriteRule ^browsealpha/([%\w]*)/?$ /browsealpha.php?name=$1 [QSA,L]

This rule should match http://www.server.com/browsealpha/name%2Bhas%2Bplus%2Bin%2Bit/ but for some reason it wouldn't work. After hours of frustration, I found a few threads mentioning the need to urlencode() the string twice, like so:

urlencode(urlencode($variable));

IT WORKS!!! Apparently this is because mod_rewrite automatically decodes the urlencoded URL, so if you pass in %2B, PHP sees it as %2B0. If you double encode, mod_rewrite decodes the first one, and PHP receives the second one (which is now %2B, which is what we want).

----------------
Now playing: Autechre - 444
via FoxyTunes

Here's a quickie tutorial on how to add Virtual Hosts to Apache on Ubuntu. This tutorial assumes that you have a basic understanding of Apache configuration and that your Apache is installed and able to serve websites.

1. cd /etc/apache2/sites-available
2. sudo vim yourdomain.com.conf and enter your VirtualHost directive. Below I've put the most basic example, see Apache docs for details and additional features:
   <VirtualHost *>
  ServerName yourdomain.com
  DocumentRoot /home/youruser/public_html
</VirtualHost>
   Save & exit.
3. sudo vim /etc/hosts and add your new domain to the 127.0.0.1 localhost line so it looks like this:
   127.0.0.1 localhost yourdomain.com
   Save & exit.
4. Enable your new virtualhost:
   sudo a2ensite yourdomain.com.conf
5. Reload the Apache configuration:
   sudo /etc/init.d/apache2 reload

That's it! Repeat for each of your VirtualHosts.

----------------
Now playing: Alèmayèhu Eshèté - Tchero Adari Nègn
via FoxyTunes

We have an account with a VERY large inbox (over 80,000 emails), and when logging into Squirrelmail the main pane would not load. Instead we'd be prompted by the browser to download a right_main.php file. Accounts with smaller inboxes would load fine, so I figured it had something to do with system resources. This is an easy fix. Open up your php.ini file, and increase the memory_limit value to something larger than the default 8M. Restart Apache and try opening your big-ass inbox again. If it still doesn't work, increase memory_limit again. Repeat until your inbox will load, but be careful if you have little RAM. I was able to load my 80,000+ inbox by setting memory_limit = 32M.

In my prior post I ran into a problem with FCKeditor on Apache having to do with serving JavaScript files as the proper MIME type. I ran into a similar problem with XML files when trying to load multiple instances of FCK textareas:
Error: this.DOMDocument has no properties
Source File: http://www.mysite.com/FCKeditor/editor/js/fckeditorcode_gecko.js
Line: 43
This is easily fixed in the same way, by telling Apache how to properly serve XML files. Put this in your httpd.conf or an .htaccess file:
AddType text/xml .xml

For some reason, FCKeditor would not load in Firefox 2.0 even though it loaded in IE just fine. Turns out Apache was serving up the javascript files as the wrong FileType, so Firefox would choke on some jibberish characters:
Error: illegal character
Source File: http://www.myserver.com/FCKeditor/editor/js/fckeditorcode_gecko.js
Line: 1, Column: 1
Source Code: /*
The fix is easy enough, simply add an .htaccess file to your dir containing the following:
AddType application/x-javascript .js
Now FCKeditor should work fine in Firefox.

When trying to serve up a Windows Media Video file from my Apache webserver, I ran into the problem of Firefox being unable to handle the file properly. It would simply load it as a plain text file, resulting in a bunch of jibberish representing the machine code of the video (as if you had opened the video with Notepad). It turns out that with a stock install, Apache does not know how to serve this type of file, so it serves it as the default, which is plain text. It's an easy fix, you simply have to tell Apache how to serve these types of files. Open up /etc/mime.types and add the following line:
video/x-ms-wmv wmv
You will also need to add the following to your httpd.conf file:
AddType video/x-ms-wmv .wmv
Save and exit, restart Apache, and your browser should now prompt you for how you want to handle the file (Open/Save).

While updating OpenSSL & Apache on a Linux machine (2.4.7-10smp), I came across an error when running 'make' for Apache:
/usr/local/src/httpd-2.0.55/srclib/apr/libtool --silent --mode=link gcc -g -O2 -pthread -DLINUX=2 -D_REENTRANT -D_XOPEN_SOURCE=500 -D_BSD_SOURCE -D_SVID_SOURCE -D_GNU_SOURCE -DAP_HAVE_DESIGNATED_INITIALIZER -I/usr/local/src/httpd-2.0.55/srclib/apr/include -I/usr/local/src/httpd-2.0.55/srclib/apr-util/include -I. -I/usr/local/src/httpd-2.0.55/os/unix -I/usr/local/src/httpd-2.0.55/server/mpm/prefork -I/usr/local/src/httpd-2.0.55/modules/http -I/usr/local/src/httpd-2.0.55/modules/filters -I/usr/local/src/httpd-2.0.55/modules/proxy -I/usr/local/src/httpd-2.0.55/include -I/usr/local/src/httpd-2.0.55/modules/generators -I/usr/local/ssl/include/openssl -I/usr/local/ssl/include -I/usr/local/src/httpd-2.0.55/modules/dav/main -export-dynamic -L/usr/local/ssl/lib -o dftables -L/usr/local/ssl/lib dftables.lo -lssl -lcrypto
./dftables > /usr/local/src/httpd-2.0.55/srclib/pcre/chartables.c
./dftables: error while loading shared libraries: libssl.so.0.9.8: cannot open shared object file: No such file or directory
make[3]: *** [/usr/local/src/httpd-2.0.55/srclib/pcre/chartables.c] Error 127
make[3]: Leaving directory `/usr/local/src/httpd-2.0.55/srclib/pcre'
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory `/usr/local/src/httpd-2.0.55/srclib/pcre'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/usr/local/src/httpd-2.0.55/srclib'
make: *** [all-recursive] Error 1
I figured this was because of an inconsistency between the two versions of OpenSSL I had on my system. The system came with the SSL libraries installed in /usr/lib, which I had updated as symlinks to my newly & manually installed directory /usr/local/ssl/lib. That wasn't enough. Apache (dftables specifically) needs to know where the new libraries are, so we must tell it where to look. Do this by adding our new lib dir to /etc/ld.so.conf. Open it up in your favorite editor and add the following line:
/usr/local/ssl/lib
Save & Exit, then run:
/sbin/ldconfig
Now re-run make in your Apache dir and everything should go smoothly. Note that you may want to run make distclean first just to be sure you start with a clean slate.

If you want to force all connections to your Apache web server to use SSL (https), you can do so with a simple .htaccess file inside the directory you want to protect:
# Force SSL connections
RewriteEngine On
RewriteCond %{SERVER_PORT} !^443$
RewriteRule ^.*$ https://%{SERVER_NAME}%{REQUEST_URI} [L,R]

Make sure you get all the proper spacing in there, or else it won't work! I spent quite a bit of time pulling my hair out trying to get this to work, only to find out I was missing a space somewhere.