Virtualmin Professional, by default, configures all scripts, including PHP, to execute as the owner of the virtual server account via the usage of suexec. This precludes the use of mod_php, and takes the place of hacks like suphp. Because execution of PHP as a CGI script can be slower than mod_php, Virtualmin makes use of mod_fcgid which allows PHP scripts to exist as long-running processes. This leads to PHP execution speed on par with running under mod_php while still providing a level of security only available to scripts running under suexec.

One pleasant feature of executing PHP scripts under mod_fcgid is that each user has their own private php.ini, which can be configured in any way that makes sense for the scripts the user is executing. Given that many scripts have requirements that can adversely effect security, it is of great value in a virtual hosting environment, but it also imposes additional complexity on the system and administrator. In general, Virtualmin maintains the php.ini files and the administrator need never think of them, but there are instances where manual configuration is required.

Individual php.ini files are stored in $HOME/etc/php4/php.ini and $HOME/etc/php5/php.ini, and can be administered using the PHP Configuration module found under the Services menu under each domain within Virtualmin. As with all configuration files under Virtualmin, it is also safe to modify the files directly using your favorite text editor.

Note: Changing /etc/php.ini will not effect changes in the php.ini of individual virtual servers, e.g. /home/mydomain.com/etc/php.ini. The php.ini of individual virtual servers have to be modified by hand, or via sed or similar command line editing tools, if required. There is no safe way of implementing global changes to all php.ini files. On some systems, there is an /etc/php.d directory, where files that are automatically included by the default php.ini. Thus, you may be able to make system-wide changes by creating a new ini file in this directory containing your directives.

As mentioned, since the php.ini files are all independently maintained when using mod_fcgid, updating the whole system to use some new php.ini directive can be a time-consuming process. sed and other command line tools can make that process painless.

A common change is to increase the memory_limit from the default 8M to something a bit more reasonable like 32M. To do that with sed, for all virtual servers, you could execute:

find /home -name php.ini | xargs sed -i 's/memory_limit =.*/memory_limit = 32M/'

This find command will find all php.ini files in all subdirectories of /home, and sed will modify them. If for some reason you have other php.ini files located in those directories, you might add a grep after the pipe to refine the list a bit. Of, if you only want to edit php4 configuration and not php5, you could do the following:

find /home -name php.ini | grep php4 | xargs sed -i 's/memory_limit =.*/memory_limit = 32M/'

It is possible to refine with infinite precision through additional options to find (such as file age) or via one or more regular expressions using grep.

You can also append whole sections to php.ini, similarly to the examples above, using the cat command and what is known as a here document.

For example, to append a Zend section to all top-level (e.g. /home/domain/etc/php*/php.ini) php.ini files, one could execute something like the follow:

cat <<EOF >> /home/*/etc/php*/php.ini
[Zend]
zend_extension_manager.optimizer=/usr/local/Zend/lib/Optimizer-3.2.6
zend_extension_manager.optimizer_ts=/usr/local/Zend/lib/Optimizer_TS-3.2.6
zend_optimizer.version=3.2.6
zend_extension=/usr/local/Zend/lib/ZendExtensionManager.so
zend_extension_ts=/usr/local/Zend/lib/ZendExtensionManager_TS.so
 

Note: The Zend section is very specific to your environment and version. Do not copy this verbatim, as it will be wrong for your system and Zend!

Virtualmin, Inc. maintains an unsupported repository of bleeding edge versions of some software that is occasionally version dependent, PHP among them. If you'd like to use the latest released version of PHP, on your system, and understand the risks involved in running software that is dramatically less well-tested and vetted (for security, stability, and performance) than the version provided by your OS, and a repository for your OS is available, it can be used to get the latest features of PHP.

We do not recommend use of the Virtualmin bleeding edge repository, for PHP or otherwise. But, if you need the latest version of anything, we recommend you get it from our repository rather than building from source or obtaining it from other sources (which are likely to be even less well-tested, compatible, and concerned with security).

Read more about the Virtualmin Bleeding Edge Packages.

Ruby on Rails is an open-source web development framework that is optimized for programmer productivity and rapid development. If you are not already familiar with it, check out its website at http://www.rubyonrails.org/ .

Virtualmin includes support for setting up Ruby on Rails in a virtual server, either to run applications developed in Ruby by the server's owner, or for running freely available application like Blogs and Wikis. Because Rails is typically run using a separate server process the setup can be quite complex, but almost all of it is automated by Virtualmin.

These instructions related to Virtualmin versions 3.48 and above. If you have an older version, we recommend upgrading first before continuing.

Most web applications are written in PHP or Perl, which are run either within the Apache webserver process, or as CGI scripts started by Apache. Ruby on Rails apps instead almost always use a separate webserver called Mongrel, which must run on a different TCP port. In order to make the application visible as part of a virtual server's website running on the standard web port 80, Apache must be configured to forward requests to the Mongrel webserver. Fortunately, Virtualmin can take care of this for you.

Because there is a limit on the number of concurrent requests a single Mongrel can handle, for high-load applications the solution is often to run multiple instances of Mongrel, and balance requests to a single URL path between them. As long as they all talk to the same database or files, there will be no problem of data consistency between the instances.

However, only Apache versions 2.2 and above with the mod_proxy_balancer module support this configuration. But if you do have that Apache version and module installed, Virtualmin can setup the Mongrel instances and web server configuration for you automatically.

Because installing Rails applications involves the installation of Ruby packages (called Gems) containing database drivers and libraries, several dependencies must be installed on your system before using it. Many Gems compile code that links against libraries like MySQL, SQLite and glibc, which requires that a C compiler and headers for those libraries be installed. This section explains the steps you need to take on CentOS and Debian-based systems.

To install required packages on CentOS (and Fedora Linux), the command to run is :

yum install ruby ruby-devel gcc make mysql-devel sqlite sqlite-devel

Assuming that your YUM repository is set up correctly, this will download and install all needed packages that are not already on the system.

On Debian and Ubuntu systems, the command to install dependencies is :

apt-get install ruby1.8 ruby1.8-dev gcc make rake libc6-dev libmysqlclient15-dev libsqlite3-0

Because Debian-based systems do not have all required Apache modules enabled by default, you need to enable them by following these steps :

1. Login to Virtualmin, and select Webmin on the left menu.
2. Open the Servers category and click on the Apache Webserver module.
3. Click on the Global configuration tab, then on the Configure Apache Modules icon.
4. Make sure proxy, proxy_balancer and proxy_http are selected, and click Save. If your system doesn't include the proxy_balancer module, don't worry.

Ruby on Rails applications are installed in Virtualmin using the Script Installers page, just as you would install PHP-based applications such as WordPress and SugarCRM. As with other scripts, they require a virtual server with a website and in most cases a MySQL database.

To install the Rails framework so that you can develop your own applications in Ruby, follow these steps :

1. Select the domain on Virtualmin's left menu, then click on Install Scripts.
2. In the Available scripts tab, select Ruby on Rails, then scroll down to the bottom and click Show Install Options.
3. If your entire website should be served by Rails, change the Install sub-directory option to At top level. Otherwise, leave it set to the second option, and change the sub-directory path as you wish.
4. If you want your Rails applications to use a database (highly recommended), select it from the Configure Rails to use database menu.
5. To run the initial Rails servers in development mode, change Use development mode? to Yes. This mode runs the applications slower, but makes it easier to make changes and debug problems.
6. If Apache on your system supports proxy balancing, the Number of Rails server processes field can be used to increase the number of Mongrel instances to run by default. One is enough for a basic application, but you may need five or more for one that is taking heavier load.
7. Finally, click Install Now.

If this is the first install of Rails on this system, the install process may take several minutes due to the need to download, compile and install several Ruby libraries. If anything goes wrong, an error message from the Ruby program that triggered it will be displayed - most are due to missing dependencies, so check the list above to make sure they are all installed.

Assuming all goes well, you will now be able to access Rails via the URL path you selected at install time (which will also be displayed by Virtualmin). Actual development of your own Ruby application that uses this environment is beyond the scope of this documentation.

Virtualmin also includes installers for several other Blogging, Wiki and CMS applications based on Ruby on Rails. The procedure for adding these is identical to other scripts, with the exception of the Number of Rails server processes field on the installation form, on systems where Apache supports it.

Some Rails applications are installed by download and extracting a source file (as is the case with most PHP scripts), while others are done using Ruby's Gems system, which can perform the required downloads itself.

For all Rails scripts, Virtualmin will setup an Apache proxy that forwards requests from the domain's website to the Mongrel server(s) that actually run the application. You can see this proxy in the Proxy Paths page - but don't delete or change it though, as doing so will stop the script from working.

All Ruby on Rails scripts installed by Virtualmin can be removed or upgraded in the same way as other scripts. Deleting a Rails application will also stop its Mongrel server processes and remove the Apache proxy configuration.

You can also stop, start and restart the Mongrel processes for a Ruby script from within Virtualmin. This can be done by going to the Script Installers page, clicking on the script name, and using the buttons at the bottom of the form (which also shows the status of the servers and the port(s) they use). When developing your own Rails applications, it may be necessary to restart the Mongrel servers to pick up changes you have made to the code, which can be done easily with the Restart Rails Server button.