Support: 1-800-961-4454
Sales Chat
1-800-961-2888

Dangers of Installing WordPress from an OS Software Repository

1

This is one topic that really gets me fired up. There are so many reasons why you should not install WordPress from an Operating System’s software repository, yet thousands of people do it every day. We will discuss reasons why you should consider installing WordPress from the package available on the official site instead of from the software repository provided by your Operating System.

Packaging, Releases and Versioning

The version of WordPress installed from your Operating Systems software repository is very likely not up to date. Most OS distributions are going to include the stable version of WordPress from the time that the OS goes into beta. Let’s imagine that our fictional Linux distribution, My Cool Distro, releases a beta or release candidate today with the latest stable release of WordPress, which we will call 4.9.3. In this scenario let’s pretend that WordPress 5.0 is 14 days away from being released. My Cool Distro is going to still ship with WordPress 4.9.3 even though it shipped after 5.0 was officially released.  This is due to the rules and regulations of how the OS handles testing and package verification once it nears it’s release date.

Learn more about the good news of installing WordPress on Cloud Sites with just one click through the Rackspace control panel.

With WordPress, the X.Y releases are the major releases and the X.Y.Z releases are the minor releases that contain security and bug fixes for the X.Y major release. Just as 4.9 is a major release, 5.0 is also a major release, and 4.9.3 is the minor security and bug fix release. Most Operating Systems, will never upgrade a software package to another major release within the Operating Systems major release lifetime. In the majority of cases this is OK, as the developers and maintainers for My Cool Distro will backport important security fixes into the major version they initially shipped with. In some cases the developers of the original software package will do this themselves.

WordPress, however, does not participate in such a practice of keeping previous major releases up to date with new security fixes once a new major version is released. The WordPress project decided to do this for WordPress 2.0, largely to support the requirements of Debian Etch. However, in the end it didn’t work well and the idea was eventually abandoned. Additionally, in the case of WordPress, the developers and maintainers for My Cool Distro aren’t likely to have the skills or familiarity with WordPress to backport fixes, and will almost certainly never attempt it.

So let’s say that you install version 4.9.3 from My Cool Distro, and you notice that 5.0.2 is released. You go through the manual or automatic update process to upgrade to 5.0.2. Now, for the sake of argument, let’s say that WordPress starts backporting security fixes into previous major versions, and the WordPress 4.9 point release gets bumped to 4.9.4. The developers for My Cool Distro decide to update the package in their repository, you run an ‘apt-get upgrade’. You have potentially just blown away your 5.0.2 install with 4.9.4.

File Locations

The WordPress package from your Operating Systems repository is probably going to put files in really strange places, and likely reference it by use of symlinks from multiple other locations. For example, My Cool Distro puts WordPress in /usr/share/wordpress and symlinks portions from /etc/wordpress.

First, who would want web content in /etc? It is also generally bad practice to have your web content in a place like /usr/share/wordpress as it is not really a web directory. My Cool Distro will also create an Apache configuration file for you that will add an alias for to /usr/share/wordpress. Then you may want it to be accessible from directly from mycoolwpsite.com and the simple solution will be to set the DocumentRoot for mycoolwpsite.com to /usr/share/wordpress, or you are going to symlink /usr/share/wordpress to yet another place such as /var/www/vhosts/mycoolwpsite.com/. By the way, WordPress and WordPress plugins don’t really play that well with symlinks (but I won’t go into that now).

Now that you have a site using /usr/share/wordpress, you will probably want to install a new theme or plugin (I mean, how many people want to have a cookie cutter WordPress site, running the default theme?). You try to install from the WordPress admin and you find it is asking you for FTP credentials because PHP/Apache does not have appropriate access needed to perform the file system operations on the WordPress files and directories. At this point you install a FTP server, and have to screw around with it to allow your user to FTP to /usr/share/wordpress. You can also configure the FTP server to allow root logins, while deliberately slamming your head in a door. Or you just chown -R www-data:www-data /usr/share/wordpress so it stops asking for FTP connection information. ACK!

You will also want to upload images and such for inclusion in your posts. Do you really want to allow the web server user to upload content in /usr/share/wordpress/wp-content/uploads? You shouldn’t be uploading content like this to /usr/share/ at all. You will have to go through the process of moving your uploads directory, which can be difficult, because WordPress expects the uploads directory to be relative to the WordPress installation directory.

Later you decide that you want to create another WordPress site, so you make another symlink from /usr/share/wordpress, but with the symlink issues and the fact that you want completely different plugins and themes (not to mention that you don’t want to use WordPress Multisite or may not even know what it is), you download WordPress from the official site, or copy the original files to somewhere else. Now you are pretty much going through the manual install process — why didn’t you just do this to begin with?

You may decide that you want to run lighttpd, nginx or cherokee instead of Apache. You cannot use the configuration file that My Cool Distro provided for Apache, and you have to make modifications to the new web servers configuration file. In the process you find that aliasing doesn’t work the same as it did in Apache, so you symlink, point directly to /usr/share/wordpress, download WordPress or copy the files from /usr/share/wordpress to some place else. You are again going through the manual install process — so why didn’t you just do this to begin with?

I could go on…

Easy Button?

You have been taught by modern Linux distributions that installing software from your Operating Systems software repository is the only way to go. I will admit that I am one of the people who push this idea. But all ideas and best practices have their use cases and limitations. While it does make it easier, it was solving for a problem that WordPress doesn’t have. You don’t need to know what compile flags to use, you don’t have to worry with dependencies (other than of course the obvious applications needed to run a website), and you don’t have to put it in some pre defined location so that other software can find it to use it as a dependency.

Your Operating Systems software repository was designed to help make it easier for users to install software and help you stay secure. We have covered why using such a method is not helping you keep secure, so why is it not easier?

When you download WordPress from the official site you immediately have access to the installation instructions promising the famous 5 minute install. With some practice, you can install Apache, PHP, MySQL and WordPress within 5 minutes and have time left to go grab a coffee.

What do you get when you install from a software repository? You get some files dropped in an obscure directory, you get a small Apache configuration file that isn’t going to get you what you want, and you are going to get a readme.txt that the average person isn’t going to know where to find. This is supposed to be easy right?

Then you are going to be surprised that the installer doesn’t create a database for you, a database username, password or even tell you that you what to do next. That readme.txt is likely to be in some place like /usr/share/doc/wordpress-4.9.3/readme.txt. You find this file and it really tells you nothing. You go to WordPress Download website and find the install instructions and go from there. Now why didn’t you just do this to begin with? This is supposed to be easy right?

You get things installed and you go to upload media items and you don’t have the flash uploader, which means you cannot upload multiple files at once. What!? You hit the WordPress support forums, someone reads the readme.txt file that is bundled with the package from the software repository and finds that, My Cool Distro stripped the required files. You now need to download that file from the WordPress website. Now you are back to downloading something else from the WordPress website — again, why didn’t you just do this to begin with? To be fair, in it’s current form, WordPress 3.3, does not use the SWFUpload flash uploader any longer, but plugins may require it. This still gives you an idea of some of the problems that you can run into.

Support

If you have an issue, you will need support. At this point you are running an old, possibly insecure version of WordPress, your files are in strange places, you aren’t sure which place has the real files and have probably been hacked. On top of that, the support forums and IRC channel for My Cool Distro are of no help with WordPress. The support forums and IRC channel for WordPress have no familiarity with the way you installed it, and are recommending you upgrade to the newest version before they can really provide help, because they can’t remember if the year old version you are using supports the functionality you are looking for.

You eventually find out that you have been hacked because you didn’t stay up to date, and now there is concern about the integrity of your entire OS install and Google thinks you are running a bogus pharmacy website.

At this point, I hope that I have convinced you that installing WordPress from your Operating Systems software repository is bad practice and that you should never do it. By the way, for all you folks who installed WordPress from your Operating Systems software repository, I was just asked to buy some pharmaceutical products from your site and got a popup offering a free pirated film available for immediate download from an anonymous FTP site running on your server.

Check out Matt’s next post for three tips on selecting a WordPress plugin. Learn more about how Rackspace can help you with hosting your WordPress site.

Tags:

About the Author

This is a post written and contributed by Matt Martz.

Matt Martz is a Senior Linux Systems Engineer working in Rackspace Enterprise, specializing in high performance web serving. Matt is also a Contributing Developer on the WordPress project.

Follow Matt on Twitter at @sivel or on his blog.


More
1 Comment

Great explanation, Matt. Nice to hear this opinion directly from you. Easy to convince someone else now. :)

avatar Pothi Kalimuthu on April 2, 2012 | Reply

Leave a New Comment

(Required)


Racker Powered
©2014 Rackspace, US Inc.