OpenX Tips

If you are running OpenX 2.8.0 or greater, and you upgrade, you will now be asked for the path to the old OpenX ad server installation directory. This is so that OpenX can copy over the files from the plugins that you had installed in your previous installation¹.

This means there are two things you must now remember to do when upgrading your OpenX ad server:

1. You must remember to keep a copy of your old OpenX ad server installation code on your server, so that you can specify its location when upgrading; and
2. You must know how to specify the location of your old OpenX ad server installation, when performing the upgrade.

The correct format for the path to your old OpenX ad server installation is to use the full directory path. For example, if you were upgrading to OpenX 2.8.3 from OpenX 2.8.2, and you have your previous OpenX 2.8.2 code directory in “/var/www/html/openx-2.8.2/”, then this would be the full directory path that you specify during the upgrade.

Specifying the full path to the previous OpenX installation.

1. For example, you may have the excellent OpenX Statistics as Graphs plugin installed [↩]

OpenX have announced a security vulnerability in version 2.8.2 of the OpenX ad server.

If you are running OpenX 2.8.2, you should immediately update to OpenX 2.8.3, or follow the instructions from OpenX, to remove the vulnerable files from your OpenX ad server installation.

OpenX 2.8.2 was released a while ago now, and the release notes stated that:

We have completed a number of critical security updates to the ad server in OpenX 2.8.2 to reduce any potential vulnerabilities in the software.

However, it seems that the situation is more serious that this – in the past week, an actual remote code execution vulnerability has been announced as being in OpenX 2.8.1 and earlier.

Admittedly, based on the vulnerability report, it would appear that this remote code execution can only be executed if you (or someone with access to your OpenX installation) upload an image banner with a .php file name extension that contains embedded PHP code. If you are careful about what you upload as banners into your OpenX installation, it seems unlikely that you would be vulnerable.

Still, if you have not yet upgraded to the latest version of OpenX, you would be wise to consider doing so!

So, business is booming, and you are approaching your OpenX installation’s maximum capacity — you know this, because you measured your system capacity. You know that it’s time to scale your OpenX installation.

Or, perhaps you have no idea what you system’s maximum capacity is, but you have noticed that your system is a little bit slower than it used to be, and you think that scaling your OpenX installation might be a good idea¹.

How do you go about scaling an existing OpenX installation?

There are essentially two different options for doing this simply.

Vertical scaling

Vertical scaling is the easiest way of scaling your OpenX installation — simply upgrade your existing server (perhaps by adding more RAM or changing the hard drives so that they have faster I/O) or move your OpenX installation onto a larger, faster server.

Certainly, this will not be a hassle-free process — performing hardware upgrades or migrating services from one server to another are never going to The Guru’s idea of a fun day’s work — but if you currently run OpenX on a single server, then it can be comforting to know that, after you have completed a vertical upgrade, you will still have a familiar, single server setup.

Unfortunately, the main drawback with vertical scaling is that sooner or later, depending on your budget, it will simply become too expensive to perform a vertical upgrade².

Simple horizontal scaling

Simple horizontal scaling as an approach where OpenX is scaled horizontally (that is, over multiple servers) at the delivery/UI server level, but where there is still only one database.

Using this approach, there are only four things that are different from a single-server installation of OpenX that you need to worry about:

1. Database access: In a single server installation, ensuring that OpenX can access the database is generally trivial, as all that is needed is a username/password. However, now that your delivery/UI servers are separate from the server that is running the database, you may need to update your database server’s accounts and/or permissions, to ensure that the OpenX code on the remote delivery/UI servers can connect to the database.
2. Load balancing: To distribute the task of banner delivery and OpenX UI access across all of your delivery/UI servers, you will need some form of load balancing solution.
3. Code synchronization: As OpenX is now installed on more than one server, you need to ensure that all servers remain synchronized with each other, so that when you make configuration changes, or perform an upgrade, you don’t end up with one (or more) of the servers in a different state from the others. This is relatively easy to achieve by using rsync, or a similar code synchronization system³.
4. Running maintenance: When OpenX is installed on more than one server, but you have a single, central database, it is important to ensure that only one server runs maintenance⁴. Pick one of your delivery/UI servers, and set up maintenance to run on just that server. Disable maintenance from running on all the other servers. It’s even more important to run maintenance manually in this kind of setup, otherwise the issues of not doing so will be increased, as a result of having more delivery/UI servers!

Of course, with this form of simple horizontal scaling, the central database server can become a bottleneck. If this happens, you can either scale your database server vertically, or you will need to consider using OpenX’s “distributed statistics” mode for horizontal scaling, which allows the database load to be (partially) distributed across multiple servers — however, scaling OpenX in this was is most certainly not a simple means of scaling, and is a topic for another day…

1. Assuming that you have at least tried basic performance tuning first! [↩]
2. Let’s face it, there are not many OpenX users that can afford to go and drop $50k or even more on a top-of-the-line server. [↩]
3. It is often easier to manage this process if you distribute banner delivery across all of the servers, while limiting UI access to one server, as this means there is only one UI server where changes can be made, and upgrades can be run. However, this of course also limits the level scaling you can apply to your OpenX UI service. [↩]
4. If all of your servers ran maintenance, and they all ran maintenance at the same time, this should not be an issue, as OpenX does have code in place to try and ensure that if you run more than one instance of maintenance at a time, it won’t matter; but it’s better not to do this, if you can avoid it [↩]

It might seem strange to you that The Guru would write a tip for OpenX that is as seemingly simple as “backup your database, code and banner files.”

However, you would not believe the number of times The Guru has been contacted by a client, asking for help with their ad server installation, because something has gone wrong with their server hardware, or because an upgrade failed, and then, on investigation, has found that there’s been no effort made at all to ensure that the OpenX database, OpenX code base (including the configuration files) and banner files, if they have been stored externally to OpenX, are all safely backed up.

In these situations, there is little than can be done if the disaster is catastrophic enough, other than to get a new installation of OpenX up and running, and for the client to start putting in all of their websites, zones, advertisers, campaigns, banners and channels from scratch…

If you rely on OpenX to manage your banners, and you can think of more productive things to do with your time than race against the clock to get OpenX set up from scratch before your advertisers take their money elsewhere, then please, heed the warning: Make regular backups of your OpenX database, OpenX code base and, if necessary, your banner files – especially before attempting an upgrade!