Different PHP Versions
From Liway Wiki
We at Liway aim to bring you the best web host experience, for web development, script use, general testing and whatever else you can think of. To ensure that remains true, it has become necessary to run multiple versions of PHP, to provide the necessary range of services.
Explaining the need for multiple versions
Liway is all about bringing developers the latest and greatest in PHP technologies. Historically, we have prided ourselves with running the latest version of PHP with all the extensions anyone could ever want, as well as using settings which allow users enough freedom to do whatever they want - within reason. This is in stark contrast to other hosts, most of which always run outdated versions of PHP, with overly restricting settings, and more often than not as cgi modules (this is evidently slower than running php as an apache module - which is what we do).
Unfortunately, PHP development moves fast, and often major scripts such as Wordpress, Joomla and Drupal can't keep up with the changes and refinements. In particular PHP 5.3 contained some major changes, as a preview to PHP 6, to make developers aware of what major features have been depreciated or changed. Unfortunately, many script developers don't take the future of PHP into account when they write their code (and in many circumstances it is indeed too much to ask of them), and thus there will be a period of time, after some particular newer versions of PHP are released, until developers catch up and make the necessary changes to their scripts.
Taking that into consideration, we would really like to provide our users with legacy versions of PHP, to ensure they can still run whatever script they wish, at the same time as providing the latest and greatest versions of PHP to other developers. The conclusion reached, was that it is necessary to run multiple versions of PHP to achieve this.
Rest assured however, unlike many other hosts, this does not mean we will have obsolete or even outdated versions of PHP. We will only run versions of PHP which are officially maintained by the PHP development team, and we will always update them as soon as newer versions are released.
Which versions of PHP are available and which to use
We currently run 3 different versions of PHP, and outlined below in is all the relevant information about them. Note that we move very quickly to complement the PHP team, so if we are running a version line of PHP that become no longer supported it will be removed quickly, and on the converse new version lines of PHP will be made available quickly too. The way in which different versions are ran (more on this later on) will also change. To make sure that you keep up-to-date with affairs, please subscribe to our announcement forum.
Latest and Greatest Version
This line represents the very latest and best version of PHP. More often than not, it will simply be the latest stable release from the PHP group. Sometimes we will run a CVS of the latest stable line, in the event that there are important bugs which we feel warrant us running a CVS version.
This version of PHP will always be ran as an apache module for optimal speed, and it will always be ran with Advanced PHP Cache for maximum speed. It will have generous php.ini settings.
Currently this version is the latest from the 5.3.x line. phpinfo
Legacy Version
This line represents a slightly older, but still maintained version of PHP. It is best used with common scripts (ie. Joomla), which are not yet fully compatible with the latest stable release of PHP. Again, this will be the latest release of this particular version line.
This version of PHP will be ran through the suPHP apache module, and hence is not as fast as the latest version. It currently uses the same settings as the latest version.
Currently this version is the latest from the 5.2.x line. phpinfo
Development Version
This line represents the development PHP version 6.0.0-dev. It will be recompiled roughly on a weekly basis, to ensure the very latest bugfixes and features are available. Do not run any scripts such as blogging/content management/forum software on this version. It is extremely unlikely that any of them are compatible with PHP 6, and it is quite possible that it is not secure. Instead, this is available for your own testing and development work. PHP programmers are encouraged to test their software here, to ensure it is compatible with future PHP versions.
This version of PHP will be ran through the suPHP apache module, and hence is not as fast as the latest version. It will use specialized settings, which are only slightly more tight than for the above two versions. Also note that certain extensions may be disabled on this version because of bugs or incompatibility with PHP 6. Currently the following extensions are disabled:
- PDO library for MySQL
- PDO library for PostgreSQL
- Imagick for Imageshack
How to use a the different versions of PHP
By default, the latest version of PHP will be used. If you would like to use one of the other versions, this is quite easy. All you have to do is add the following line to the .htaccess file for the directory where you want to use this version of PHP.
For the Upcoming Release
AddType php54-script .php
For the legacy version ( 5.2.x)
AddType php52-script .php
For the development version ( 6.0.0-dev)
AddType php6-script .php
Notes
Keep in mind that .htaccess settings flow down to all sub-directories, so you only have to do this for the top-level directory in any script.
Also keep in mind that you can add an arbitrary number of extensions at the end, separated by spaces. Also note that you can mix the two if you like. For example:
AddType php52-script .php php5 AddType php6-script .php6
Important Information & FAQs
Understanding suPHP
If you are going to use the versions of PHP running under suPHP - then it is crucial that you understand how suPHP changes things. Don't be afraid.
Unix Files & Permissions
First, it's important to explain a little bit about the way unix file permissions and ownership works. Refer to the below image of a directory listing.
File Ownership
On unix file systems (such as the one we use), files and directories have an owner and belong to a group. The owner of the file is typically it's creator, as is it's group - unless changed. Consequently, all files and directories have three sets of permissions which are always written from left to right.
- Owner permission: Dictate what the owner of a file can do with it.
- Group Permission: Dictate what users belonging to the group of the file can do with it.
- Public Permission: Dictate what all other users (not belonging to the above 2 categories) can do with it.
File Permissions
There are three distinct types permissions which behave differently for files and directories.
For Files
- Read (+r): Ability to read the contents of the file.
- Execute (+x): Ability to execute (ie. run) a binary file or a script.
- Write (+w): ability to change the contents of the file.
For Directories
- Read (+r): Ability to list the names of the files in the directory.
- Execute (+x): Ability to traverse the tree of a directory in order to access it's files and subdirectories.
- Write (+w): Ability to create, delete and rename files in the directory.
Each file and directory has these permissions. They are also often expressed in octal notation (numbers 0-7), where-by each number from left to right represents the permission level for each of the; owner, group and public. Each number is a simple permutation of the above read/execute/write permissions.
0 --- no permission 1 --x execute 2 -w- write 3 -wx write and execute 4 r-- read 5 r-x read and execute 6 rw- read and write 7 rwx read, write and execute
Common Permission Requirements
The user who is using a file or directory needs to have appropriate permissions to use it. In particular, the following can be said;
- PHP files do not require execute permission, since they are not ran by the user from the command line - but rather read by apache and passed to the PHP engine. (However you can execute them from the command line on your own computer if you wish!). PHP files only require read permission, but for simplicity's sake, it's not a problem to give them read+execute (ie. 5) permission.
- .htaccess files do require execute permission as well as read permission, because the apache server needs to execute them. This means they should be set to 5.
- Directories in general only require read and execute permission, and can hence be set to 5.
- However, special directories used for uploading files and other images require write permission - which means, they should be set to 7.
- Images, HTML, CSS, etc files in general only require read permissions, but again can be set to 5 for simplicity.
For security reasons, you should NEVER give anything write permissions - unless absolutely necessary!
So now that you know what types of files and directories require what permissions, it's important to understand whether the owner, group or public need to have these permissions.
What Happens Normally
Under normal circumstances (ie. running PHP as an apache module), PHP scripts are ran under the apache user, which is different in various environments - but sufficed to say it is not the owner of the file nor does it belong to the usergroup of the file. In other words, when someone is running a php file through the web-browser, that script will be considered as a public user, and it's access to the directories and other files under your account will be as a public user. This means that as far as accessing content using the web-server is concerned, only the last permission (ie. public permission) is relevant, and dictates what can be done with the file.
How suPHP Changes Matters
With suPHP, PHP scripts are now ran under your user - that is, the user to which your account belongs to (it's name is the same as your cPanel username). In other words, php files accessed through the web-browser no longer run under apache's user, and because they are ran under your user and you are the owner of the files in your account, they will now be subject to owner as opposed to public permissions. This means that only the owner permission is now relevant to what can be done with the file.
It is important to understand, that the level of permissions (described above) required for the files and directories does not change - but rather which permission is considered is changed. Under normal circumstances only the public permission is considered and under suPHP only the owner permission is considered.
Note also, that suPHP only changes the execution of PHP scripts. That means that other files such as images, html, css, etc still require public read permissions.
PHP Values
With suPHP, it is also no longer possible to use 'php_value' in .htaccess files to override PHP directives and settings. Instead, you can put your own php.ini file in the required directory, and specify the settings you would like to change. For example:
; Note that in php.ini, settings are given as 'name = value' pairs expose_php = Off
This method however is not recursive to subdirectories like .htaccess is, so you will need to put your custom settings in every directory you want them in.
Also note, this does not affect your ability to set apache directives in .htaccess files (ie. for mod_rewrite rules).
Public Write Permissions
Take special note that suPHP will explicitly prevent users from running scripts which have public write permissions or which are in directories that have public write permissions. It does this, because having public write permissions in secure - and under suPHP, it is always unnecessary, as at most you need owner write permissions to achieve the equivalent effect of having public write permissions when running php as an apache module.
Strengths
- suPHP is good because it gives users greater control over their scripts and files, being able to run them under their own system user account.
- It is also more secure, because it is no longer necessary to give any files or directories public write permissions, and hence the severity of any potential exploits in a range of software and scripts are drastically minimised.
- Most importantly, it allows multiple PHP versions to be ran
Weaknesses
- suPHP, like other CGI technologies adds another layer through which requests need to pass, and is overall slower than running PHP as an apache module.
- Furthermore, it is impossible to use PHP acceleration and caching software, unless PHP is ran as an apache module, resulting in further loss of performance.
Conclusion
suPHP provides a means to run alternative PHP versions for those who require them, and it allows us to let users play around with the latest development version of PHP in a secure environment. However ultimately, suPHP cannot deliver optimal speed, and thus users are encouraged to use the default version of PHP if possible.
Frequently Asked Questions
Why do I get internal server errors after enabling an alternative version of PHP?
Probably because you have something with public write permissions - read here.
Is it not possible to run different versions of PHP as apache modules?
Unfortunately not, the different php modules would conflict.
Just how much slower is running scripts under suPHP?
The difference is not significant, however it may be slightly noticeable especially with complex scripts - mostly because the caching done by APC increases the execution of scripts a lot and makes several key optimisations.
Aren't there any better alternatives to suPHP?
suPHP is the most secure and actively-maintained CGI technology which supports PHP. Overtime there have been several similar projects, but we feel that suPHP is definitely the best.
If suPHP is more secure, does that mean that running PHP as an apache module isn't?
Not really. Running PHP as an apache module is still very secure, if it is set up and configured correctly. There is the potential for minor security problems which would not exist on suPHP, however if PHP is updated regularly and is ran with secure settings and in a secure environment, it will not pose any serious threat - and even minor threats are extremely unlikely.
How is Liway different to the rest
We are developers just like you. We know and understand you needs. We put a lot of work and effort into everything we do for our users - and this is no exception. We have achieved a very nifty setup, which took a lot of manual work, but we believe it to be vastly superior to the large majority of other hosts.
Historically, hosts have used apache mods like suPHP for two reasons;
- Run PHP 4 and PHP 5 simultaneously
- Make their PHP installation more secure
This has especially become more common, as various server scripts are now available to generate this kind of setup automatically.
There are problems with this however;
- This leads to webhosts running obsolete versions of PHP, ie. PHP 4, PHP 5.1.x, and outdated versions of the supported lines 5.2.x & 5.3.x.
- Many hosts don't even run more than one version of PHP - yet still insist on using suPHP, because they are not competent enough to secure their server to a degree of certain confidence or they feel that even near nonexistent threats warrant significant limitations on users.
- This goes hand in hand with running updated versions of PHP. If sysadmins are not willing put in the work to keep their software up-to-date and running on secure settings, it is easy to create security using suPHP.
Of course none of this applies to us. We have a very unique setup whereby we run the very best version of PHP as an apache module for the best possible speed, but also provide a legacy - yet still supported version for those who require it through the suPHP module. Along with PHP 6 for all the hard-core developers, that makes three different versions of PHP available for use. And isn't that great?
