However, when I tried to install such an event handler beast via Plesk | Server | Event Handler | Add New Event Handler I ended up in an error message like Error: Some fields are empty or contain an improper value for which add did not have any explanation. Much, very much later, I discovered that I had copied the path of my script to be executed via copy-n-paste into that Plesk command field. That copy contained whitespace at the end of the command, i.e. something like

/path/to/handler.sh\n

which is enough to make Please grumpy. What’s more, it’s all about whitespace (blanks, tabs, newline etc) at the end of a command while whitespace within the command is accept without any rumble:

echo > /dev/null

That works fine.

Summary:

When entering an event handler command, make sure that there is no whitespace at the end of the command.

I install those two web applications myself rather than using MacPorts to do so. The installation is basically nothing more than unzipping the distribution package and to modify the configuration files to make sure they connect to my MySQL database on my localhost. However, while installing Wordpress went smooth, I run into database connection failures when installing Mediawiki. It took me some time to figure out what is going on here.

If you have weird connection problems using PHP and MySQL then try one or both of the following solutions:

• Solution: Use 127.0.0.1 instead of localhost as host of your MySQL database server. This has a rather surprising effect, see below.
• Solution: Change your PHP’s configuration file, which is /opt/local/etc/php5/php.ini, to contain the following two lines:
  1. Tell PHP about the Unix domain socket to use

        mysql.default_socket = /opt/local/var/run/mysql5/mysqld.sock
     

  2. In addtion make sure that PHP’s save mode is off (notice that this feature has been deprecated and removed in PHP 6), otherwise your previous modification will be gracefully ignored:

         safe_mode = Off
     

  Notice that in addition you need to restart your Apache web server so that your changes are taken into account. You can do that with apachectl restart.

Background Information

Neither Mediawiki nor Wordpress (nor most other PHP based web application accessing MySQL) implement the gory details how to connect to a database. Usually they just delegate this to mysql_connect();, a API function provided by PHP.

PHP in turn uses the functionality of a (shared) library provided by MySQL, i.e. the MySQL driver. MySQL allows you to connect to the database via two routes:

1. via Internet sockets (TCP/IP); and via
2. UNIX domain sockets

So, how does one choose between this two routes? The answer is rather surprising. MySQL decided to give localhost a new meaning. If you specify localhost, then the UNIX domain socket route is chosen. If you say 127.0.0.1 instead, then you connect via an Internet socket. While this is probably the most natural thing for those MySQL folks, it’s a rather confusing fact for all other humans. It is rather carved deep in our brain for years now that 127.0.0.1 and localhost is the same thing.

After I have changed both Mediawiki and Wordpress to use localhost I had for the first time a situation where both web applications behaved in the very same way. They both did not work. Then, when I changed to 127.0.0.1, both worked fine. Btw, notice that localhost is the default hostname used by Mediawiki while 127.0.0.1 is the default host suggested by Wordpress.

Using 127.0.0.1 is usually fine, however I do want to use the UNIX socket and I was wondering what went wrong.

The problem is that MacPorts MySQL port patches the original MySQL sources to use socket /opt/local/var/run/mysql5/mysqld.sock instead /tmp/mysql.sock. This change is not particular well documented. One would assume that this kind of change goes into an appropriate my.conf configuration file. That’s actually not the case. Even worse, MacPorts MySQL port does not even ship with such a configuration file.

Changing the default socket location is one thing, not telling us and the PHP5 maintainer this is another sin. So, while MySQL happily uses that weird socket location, PHP5 still expects /tmp/mysql.sock. In other words, PHP and MySQL are not working out of the box when using MacPorts. At least not when relying on Unix domain sockets. It does work when using Internet domain sockets cause that default port, being 3306, has not changed. Btw, the MacPorts maintainer of PHP and MySQL is one and the same person. Sounds familiar? Yes, I also have been thinking about Dr. Jekyll and Mr. Hyde. No serious. I assume that there is a serious reason why this does not work out of the box as we all wish. I just don’t get it.

So just assume that you have create a new subdomain and you want to make your CSS files available via /css instead of going via some hardwired domain URL. So all you want to have is an alias like

Alias /css "/path/to/my/css/folder"

Ok, but where to enter? When you look at the folder structure and files created by Plesk it is by no means clear what to do. But hey, what are manuals good for anyway? What you discover is that Plesk created a folder like

  /path/to/domain/subdomains/subdomain/conf

for your subdomain. The folder is empty. It would be really great if Plesk would in addition create a README file in that folder. That file would then state something like this:

To configure your subdomain, add herein a file name vhost.conf. Put any Apache configurations in this file you like but be aware that this file is being included in a virtual host definition.

 $ /usr/local/psa/admin/sbin/websrvmng --reconfigure-all

Good luck and have a nice day.

Unfortunately, that README file is missing. Unfortunately.

The hidden gotcha is speed. Where would speed matter you may asking? Well, after having typed in and executed some command, the next command is most often just a minor variation of the previous one. Instead of retyping almost everything again, I let readline’s previous-history function repeat the last (or an earlier) command, move the cursor char-by-char to the desired position where I dare to change something, do the change and eventually execute the command by pushing the RETURN key.

At this point I would like to add a not on the notion used in this small survey about to denote a particular key. Obviously if I mean the key “a” then it’s the small tile on your keyboard with that engraved letter “a”. “A” is bit more complicated cause it is a combination of two “tiles”, namely the “SHIFT” tile and the “a” tile. What you need to do to get the “A” is to hold down tile SHIFT, followed by “a” without releasing SHIFT. So how does the SHIFT key looks like on your keyboard? I have no clue. On my keyboard it’s a tile with a upword-pointing non-filled arrow character. Other keyboard keys of particular importance are the (carriage) RETURN key (originally to move the typewrite’s write position to the line’s beginning), the CONTROL key, the ESCAPE key and usually four navigation keys (usually right and left, up and down).

There must be some convention how to write down a sequence of keystrokes. The one readline uses and which is also being used in this survey is the following: \C means the control key and \e is the escape key. \M is the meta key. I don’t have one on my keyboard, so \e is taking over automatically. Furthermore there are the left and right navigation keys which I’m denoting with <- and ->. Notice that readline does not have a notation for this keys. Instead such a key is represented a key sequence starting with the escape key (\e).

This all works fine except that moving the cursor char-by-char is awfully slow, even in those days with a small super computer right in front of me. It would be really great if I could move forward/backward word-by-word as well. This is of course possible using readline. The function names to do so are forward-word and backword-word.

All fine and well except the default key bindings used for forward/backward word. The standard key binding is \M-f and \M-b. The idea is good. Use \C-f to move forward a char and just switch to the meta key to move forward a word instead. My problem is that I have to press key \e once, then release that key and the press the f key to get the desired effect. That’s much slower than pressing the \C key followed the f key while still holding the \C key. In fact is so much slower that I almost never used the forward move feature. But as I said, forward by char is anoyingly slow.

What I want to do is to assing forward-word with \C--> and backward-word with \C-<-, i.e. I would like to invoke forward-word by holding down the \C key followed by pressing the right arrow (and left arrow for moving backward). This would suite me quite well cause the standard action when pressing the right and left arrow is moving forward or backward a char and this are the keys I’m actually using when moving the cursor (for completness: the up and down arrow move forward and backward in the history).

At this point I had to dig into the documentation to be able to continue:

1. How to configure readline?
2. How force bash to re-read the configuration?
3. How can I see the active bindings?
4. How can I see the escape characters generated by a key?

The first question is easy. Add or change a (hidden) file named .inputrc right in your home folder. This file is taken into consideration if existing. You can change that setting an environment variable named INPUTRC if you are not happy with the name or the location. In any case, readline will also read the system wide configuration file /etc/inputrc if existing.

Having changed .inputrc, how do I make my terminal application (which runs bash as interactive shell) aware of any changes? You can start a new terminal application (tab or window) or you can type \C-x \C-r in your current one as cheap alternative.

Ok by now, but how can I check the current bindings? When running the bash, use bash’s builtin command bind. For example, you may want to run

% bind -P

to get a relation between readline functions and keys bound to that function. Or you may use bind -p to get a key : function mapping for each function (the output of bind -p would be a valid .inputrc file; it also shows unbound functions – quite useful actually).

Jolly good by now. Except that I have no clue what kind of character sequence is generated by pressing down the right or left arrow key or even what might be generated by additionally holding down the control key (\C). Here another useful readline function, named quoted-insert, comes to rescue. By default, this function gets invoked by \C-v and what it does is, that it inserts the next character you type right there at the cursor’s position.

So you are curious what might be generated by \C followed by holding down the right arrow (->) key? Go ahead and type \C-v \C--> in your terminal and the result on my terminal looks like

$ ^[[5C

Great, now we are almost there. The very last hurdle to overcome is to understand that ^[ is actually the escape key. You can verify this easily using the quoted-insert method explained previously. So what’s left is to add something like this to your local .inputrc and make readline reload that file:

# Make CONTROL - (left arrow) move cursor backward
# one word resp. forward one word
"\e[5D": backward-word
"\e[5C": forward-word

Happy hacking.

So far so good except that the default presentation generated by mod_autoindex is rather boring. We want to have it a bit more spicy. Therefore mod_autoindex has a lot of applicable options which are crying to be used.

Apache’s webserver has got a reputation of being difficult to configure and mod_autoindex is actually a perfect example for this claim. I don’t judge the software here as such, in my opinion, it’s rather about the documentation. As a teaser, you might wonder what mod_autoindex generates by default? This is what get generated for a folder containg just a file and just a subfolder:

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
<html>
 <head><title>Index of /js</title></head>
 <body>
<h1>Index of /js</h1>
<ul><li><a href="/"> Parent Directory</a></li>
<li><a href="file"> file</a></li>
<li><a href="folder"> folder</a></li>
</ul>
</body>
</html>

Let’s go one step further and take how to apply index options as an example. Index options can be used on a server config level or within a directory tag. In other words, you may have an httpd.conf file looking partially like

IndexOptions XHTML
IndexOptions HTMLTable
<directory />
 IndexOptions HTMLTable
</directory>

The overall question is: what do we get by this?. Obviously we try to enable XHTML and we try to enable the generation of a table instead of the unordered list (<ul>). But that’s not what we get. What we get is the html table rendered in plain HTML 3.2. How does this come?

It appears, and the documentation really needs to be more explicit on this, that index options are handled quite differently if they are encountered within a directory tag (<directory />) or on the top level. When processing the configuration, Apache first calculates the value on the server config level. This is simply done by accumulating all index options into a list. For example, if there is IndexOptions X and somewhere later a IndexOptions Y, then we end up in a list like {X, Y}.. This is probably what you expect.

The server config value calculated is then applied to the root directory (/). If no directory tags are present, this is then the value applied.

If a directory tag for path /foo/bar is present, the value is calculated in two steps. In step one, the value is inherited from directory /foo which in turn will get its value from /. In step two, index options found within the directory tag are applied in an incremental fashion.

Incremental index options are applied like this: if the options starts with a plus sign, the option’s value gets added to the list value. If it starts with a dash, the option’s value will be removed from the list. If neither plus not dash, the current list value is erased and the new list value will be the value of index option under investigation.

So, let’s have again a look at our configuration:

IndexOptions XHTML
IndexOptions HTMLTable
<directory />
 IndexOptions HTMLTable
</directory>

The calculated index option valaue after having processed the server config level before digging into the directory tag is {XHTML, HTMLTable}. Then directory / is processed by inheriting {XHTML, HTMLTable} followed by applying incremental rules. Therefore the final value is cleared and replaced by {HTMLTable}.

Notice on the other hand that incremental options on top level do not work at all:

IndexOptions +XHTML
IndexOptions +HTMLTable

This has just no effect. Incremental options on top level are silently ignored.

In summary it’s mainly Apache’s documentation doing a bad job here:

• The documentation does not state what we have to expect if no options are applied
• It is not clear at all how options are processed. Lots of other weired behaviours could have been implemented.
• It is rather bad to use the same identifier (IndexOptions) for a different behaviour. If so this should be clearly documented

I like to dwell in a bit on the last point. From a legacy point of view, older version of Apache supported non-incremental index options. Starting with Apache 1.3, incremental index options were added. So suddenly we can have index options that start with a plus character, or a dash or with extra character. Then someone decided that the absence of a character means erase. That conflicts of course with the legacy meaning where the absence of a character means actually +.

It would have been much better to define the absence of a character as use the default character and to use a third character for replacing. Such a character could have been =. Then we would end up in those rules, regardless whether on a server config level or within a directory:

• If an index options starts with + then it’s value is added.
• If an index options starts with - then it’s value is removed.
• If an index options starts with = then it’s value replaces the calculated value so far
• Otherwise: treat the option as if the value starts with +.

/opt/local/var/run/mysql5/mysqld.sock

Even worse, the file’s name, usually mysql.sock, has now changed into mysqld.sock. So it comes to no surprise that applications like PHP, Mediawiki and oh-you-name-it simply choke. Except if you also install those via MacPorts. Then you may have a chance that it works.

Personnally however I don’t like this all-or-nothing approach. Ideally I would like to have a system where MacPorts lives in a friendly coexistence with tools not provided by MacPorts. Wouldn’t it be good if there were a kind of registry knowing about locations? Unfortunatly, such a registry beast is still missing on UNIX based platforms. As much as I like the UNIX approach, all those config file locations and dialects drives me crazy.

So how would Mediawiki know that my MySQL’s configuration file is burried deep in /opt/local/etc and that furthermore, MySQL got pached to use that fancy location mentioned above?

Well, it simply can’t figure it out.

Now, you may think that’s no problem then. We just tell Mediawiki where it is. That’s not going to work either as long as you are unwilling to wrestle with Mediawikis PHP code: joy-oh-joy, it’s just hardwired to /tmp/mysql.sock. Period. So, what you need to do is to ask good old ln -s for rescue:

% sudo ln -s /opt/local/var/run/mysql5/mysqld.sock /tmp/mysql.sock

This works eventually but it’s really ugly cause the problem with links is that after a while no one knows why this link was created in the first place.

Happy Hacking.