Plesk WordPress Toolkit is useful to clone, sync, update, and carry out complex tasks in a simple straight-forward manner. It permits users to test plugins and themes without developing them on a live site. Furthermore, the Plesk WordPress Toolkit can help ensure your site’s security.

Plesk WordPress Toolkit offers Smart Updates

Plesk WordPress toolkit provides one dashboard to mass-manage updates for your WordPress websites. WordPress updates can impact your website’s security, so your WordPress themes and plugins must stay updated at all times. Smart Updates measures the impact an update might have on your website and advises whether you should proceed.

Smart Updates includes the following features:

1. Availability on a per-site basis.
2. Manual and automatic updates.
3. Site cloning to test updates without touching the production site.
4. Automatically determines if you should perform the update on the production site.
5. No impact updates: Until the user verifies the update, the production site remains unaffected.
6. Automatic updates: The production site remains unaffected until there are no issues found.
7. Available for WordPress core updates, plugins, and themes.

Benefits of Smart Updates: 

1. Automated updates: Smart Updates searches for new updates. It checks the update results on a clone of your website. It will then update your website, plugins, and themes.
2. Automated testing: It runs the update on a website clone. Smart Updates tests the website for bugs and errors.
3. You are always in charge: You will get an alert about the test results. Updates will not sync if the automated regression testing tool finds a broken site after the test run.

Staging Sites in the Plesk WordPress Toolkit

Website updates mean taking the website offline and activating maintenance mode, resulting in lost business, weak customer experiences, and time wasted. You can leverage website staging to test your website, or changes to it, before publishing. Plesk provides a testing environment for websites.

To update a production website, you need a staging environment. This permits website owners to get a complete copy of the production website and experiment on the staging site without breaking the production website.

Creating a staging environment and syncing it with the production site is a complex process. The WordPress Toolkit includes single-click cloning so that you can attain this with little hassle. You can protect the staging environment with a password to limit access to new content and settings.

You can use the clone features to:

1. Create a staging environment to update your production site.
2. Publish a website that you were developing after achieving a milestone.
3. Allow the client to choose from many versions of the same website.
4. Clone an existing website to use as a template for future projects.

Once the changes are complete, you can sync to production. In WordPress Toolkit, this only takes one click.

Backup and restore with the Plesk WordPress Toolkit

Here is what you can achieve with the Plesk WordPress Toolkit:

• Create a restore point before updating.
• Restore your WordPress site from the restore point.
• Download the restore point.

Plesk supports two types of backups:

1. Plesk Backup: Full subscription backup.
2. WordPress Backup via Toolkit: This backup contains data on just your WordPress backup.

Auto restore point created when using Smart Update.

You can store backups in: 

1. Your hosting storage.
2. External File Transfer Protocol (FTP) storage.

Customers may differentiate between backups created by them and technical backups included in their subscription. If any backup task is incomplete, Plesk displays the detailed error in a separate field. Additionally, sensitive data in your backups will be safe with password protection.

You can set up a backup password from:

• Your remote storage settings.
• While downloading a backup file from Plesk to another external location.

Plugin management in the Plesk WordPress Toolkit

WordPress plugins are pre-coded apps that merge with your WordPress website to deliver extra functionality. With WordPress Toolkit, you can install, manage, and update plugins.

You can install free and paid plugins from the WordPress repository. If you are unable to find a suitable plugin, you can upload custom plugins. You can install, activate or deactivate plugins for WordPress installations hosted on the server.

You can update plugins for as many installations or set up auto-updates for plugins. You can also remove plugins from one or all installations hosted on the server.

Theme management in the Plesk WordPress Toolkit

WordPress themes are a set of files that change the website’s appearance. Themes control the site’s layout and hyperlink colours. A WordPress theme changes the website design, such as colours, fonts, and layout.

By choosing a different theme, you can change the look and feel of your website. WordPress Toolkit allows users to install, manage, and update WordPress themes. 

You can install free and paid themes from the WordPress repository. You can also upload custom themes if you cannot find a suitable theme. But, a WordPress installation can have only one active theme.

Users can update free and paid themes through the WordPress admin dashboard and update themes or set up auto-updates. You can also remove themes from specific or all installations hosted on the server. 

Plesk WordPress Toolkit security measures

Plesk WordPress Toolkit can improve WordPress installation security. Individual improvements made to the installation’s security are ‘measures’. Specific measures are crucial. Plesk WordPress Toolkit applies critical measures to newly generated installations.

These security messages may appear on the installation card:

• ‘Fix security’: You are not using all the recommended and crucial security measures.
• ‘Check security’: You are using all the crucial security measures. But, you are not using some recommended measures.
• ‘View settings’: You are using all the security measures.

Some security measures can break your site. If this occurs, you can simply revert some of the security measures. However, some security measures cannot be reverted, so you should backup your site before securing it.

Leverage the Plesk WordPress Toolkit with Conetix

We believe that developers and businesses alike can greatly benefit from the features in Plesk’s WordPress Toolkit. Our WordPress hosting plans include the Plesk WordPress Toolkit right out of the box. 

Learn more about the Plesk WordPress Toolkit and how you can leverage it with Conetix.

Plesk have been busy taking the base of their Onyx platform (see our previous article covering the new features) and putting a lot of development time into this latest release.

Known as Obsidian, this release extends the focus on the modern web stack and brings in a number of key features which will be important for hosting providers, agencies, developers and end users.

Having tested the release during it’s development cycle, Conetix has already begun the roll-out across all of our servers.

In this post, we’ll cover a number of our top features we’ve been looking forward to.

New Look and Feel

The new Obsidian interface is familiar for those who have used Onyx, yet many areas have received a refreshed look to be simpler and easier to navigate.

While the changes appear subtle at first, this is also a sign of great design. It also means that there’s no additional user training required, anyone already familiar with Plesk can jump straight back in without any retraining required.

Improved PHP Composer Support

No longer just a basic add-on, the Composer system within Plesk is now a first class citizen. Composer has evolved to be the dependency manager of choice for PHP and used by popular frameworks such as Laravel.

With complete dependency and package management built in, the Composer UI can automatically handle your deployments without ever having to go near a command line.

The new 2.0 Composer automatically reads your composer.json file to find the dependencies and can therefore install them all automatically for you.

All of the modern development requirements such as choosing between dev and production as well as setting environment variables is completely handled by the Plesk UI too.

SNI for Email

The push for SSL encryption for all mail services has been a good thing from a security perspective, but has lead to a lot of confusion and change for end users. Known as Server Name Indication or SNI for short, this feature means that your Plesk server can now use more than one SSL certificate for email.

Instead of customers connecting to the name of their server, with a valid SSL certificate they can use the root of their domain or even mail.<theirdomain>.com.au as their nameserver and the certificate will be valid. This is especially handy on all Apple devices and newer copies of Microsoft Outlook, where the valid SSL certificate is enforced.

Autodiscover for Email

Again taking from the SNI enhancements, Obsidian makes it easier again for users to configure their mail clients. The Autodiscover will work for all Outlook versions as well as Mozilla Thunderbird. Instead of users having to remember what name to enter for their mail client and what ports, SSL settings and so forth to set the autodisovery within their mail client will automatically retrieve these settings from the server.

The end result is easier setup for the client, which in turn leads to happier clients and less support requests. It’s a win-win!

The latest micro-update (18.0.23) also adds easy configuration for Apple devices as well, easing the support burden of clients adding new email boxes.

Advanced Monitoring

As long term users of Grafana for our internal metrics platform, this gets a big thumbs up from us. The previous Server Health Monitor while helpful, it simply didn’t have the ease of use nor the fidelity that Grafana provides for metrics.

Plesk have not only integrated it within the main admin UI (ie, with the same look and feel as the rest of the Plesk Admin) but also allow it to be accessed directly. Again, this comes down to the level of polish and enhancement that Plesk have put into Obsidian.

Even the notifications for any server health issues have been updated, which is (again!) a very welcome change. Our prediction is that Plesk will continue to enhance the monitoring here and we can’t wait to see how it evolves over the next 12 months.

Backup Optimisation

In previous editions, if you ran server wide backups then the server needed at least the same amount of space required spare as it did files for the temporary archive.

For example, if you had 30GB of files, databases and email then to run a server wide backup you required 30GB of free space. This was quite inefficient, especially at a hosting level where you have hundreds of servers running.

With the latest Obsidian release, this additional space requirement is simply as two subscriptions worth not an entire server’s worth. In addition to this, many aspects of the backup functionality has had significant performance enhancements. Browsing backups stored on FTP or other remote systems is back down to seconds instead of minutes.

There’s more to come…

These are just our highlights, in amongst the updates are hundreds of other improvements as well. What’s more, we know that there’s still plenty of changes and enhancements yet to be rolled out as well.

Full release notes: https://docs.plesk.com/release-notes/obsidian/whats-new/

With almost 80% of new sites being developed being WordPress its no wonder a lot of focus has been placed on tools which help WordPress users.

"The ultimate tool to build, manage and secure your Website in one place!"

Some key features in the new WordPress Toolkit 2.0 include:

• Faster and Simpler Deployment
• Clone
• Sync
• WordPress Debug Management
• Better Auto Update Control
• Migration of Remote  Single WordPress instance
• Site Indexing
• Plesk Resellers
• WP-CLI
• API RPC + CLI Support

Faster and Simpler Deployment

The one-click installer makes installing WordPress simpler than ever before, Plesk now uses the WordPress.org repo and always downloads the latest version of WordPress. This means that you're always guaranteed to be installing the latest version. The installer does everything from start to finish including, creating a DB with a DB user, creates an admin account in WordPress and initialises WordPress so that it’s fully ready for use out of the box.

Clone a WordPress instance

Cloning an existing WordPress instance is time consuming and not a easy task with a lot of manual copying of files, creating of new databases and then manual command line actions to change site urls in database. With WordPress Toolkit 2.0 you can now create a clone of any WordPress instance to any domain or any subscription in Plesk.

The WordPress files and database are both cloned and the site URLs in the database are changed automatically. You have the same admin access credentials just accessing a different DB and new DB user, all automatically changed in wp-config.php. If you are cloning to a subdomain and it doesn’t exist in Plesk yet, it will be created with all correct DNS records. Multisite instances can also be quickly cloned, but there are some limitations on subdomains located on Windows hosting.

The WordPress Clone feature in the new Toolkit is the single biggest time saving addition in this update, using the clone feature with the new sync feature rapid development and debug on a WordPress site has become simpler and quicker. 

Data Synchronisation – Sync

In the development lifecycle process, it can be a challenging exercise to synchronise changes from your dev site to production. Within WordPress Toolkit 2.0 you have the ability to synchronise modified data between two WordPress instances. If you have several WordPress instances on your server, you can copy the modified data between these instances.

Not only can you chose what domains or sub domains you wish to sync changes to you can also select the sync options, either Files only, Files and Database or Database only. You also have options with your database sync to choose which database tables to copy. Options include Full database sync which is all tables or only selected tables or new tables.  Files that are present on target but missing on source are not removed by default and as a safe guard the target instance is put into maintenance mode during the sync.

WordPress Debug Management

Debugging Websites can be time consuming and tricky, from the initial cloning of your production site to creating your dev environment and then manually changing the right WordPress files to display the right debug information. You also need to manually edit wp-config.php and remember what to edit. WordPress Toolkit 2.0 solves this problem by allowing you to manage all important debug options on a per instance basis from the GUI.

Debugging a WordPress site is as simple as cloning your production site and create a dev environment and turn on debugging from within Plesk Toolkit. The options below allow you to manage the native WordPress debugging tools, enabling and disabling these tools in the wp-config.php file:

• WP_DEBUG – Enable the main debug mode in WordPress
• WP_DEBUG_LOG – Save all errors to the debug.log file inside the wp-content directory.
• WP_DEBUG_DISPLAY – Show debug messages inside the HTML pages
• SCRIPT_DEBUG – Force WordPress to use the non-minified versions of core CSS and JavaScript files. This is useful when you are testing changes made to .js and .css files.
• SAVEQUERIES – Save database queries to an array that can be displayed to help analyse them. Note: that this will have a noticeable impact on the performance of your site, so it is not recommended to leave this option enabled when you are not debugging.

You can also activate and deactivate each option individually as well. For more detail on Debugging_in_WordPress, click on the link to WordPress.org article to for more information on these options.

Work better, faster and safer!

WordPress AutoUpdates

There has been a lot of confusion around the way WordPress Toolkit set its auto updates, in the past if you enabled auto updates in WordPress Toolkit, major and minor updates would be installed automatically, If you disabled auto updates in WordPress Toolkit only minor WordPress updates will be installed automatically which is the default WordPress behaviour.

In WordPress Toolkit 2.0 this is solved by the introduction of a clearer auto update settings for major and minor WordPress releases using the native WordPress commands like wp_auto_update_core.

So now you can choose to do major and minor updates or just minor updates or disable all automatic updates if you have an external update management system.

Migration of Remote Single WordPress instance

Migrating clients from other providers can be reasonably tricky with the latest update to Migration Manager your customers WordPress website can be migrated to your infrastructure or server with only FTP login. All the WordPress files and database are migrated and the site is automatically added to WordPress Toolkit. To migrate you simply click on Website Importing Option and then add FTP credentials.

Site Indexing

When developing a new site and your Website isn't yet ready for public viewing, or simply creating a clone site for debug purposes, you do not want Google or other web crawlers to find it and index it in their search results. Plesk now allows you to index or not index your site by adding the "noindex, nofollow" tags to your website's header and adds the Disallow directive to the virtual robots.txt file.

Password Protection 

Enable password protection to your staging site, allowing your team to develop and review your site before going live.

"We want to handle the stuff that we know so that people who want to use WordPress could focus on their actual end-goal: making the Website and creating content."
          – Plesk Development Team

Plesk Resellers

Plesk Resellers now have the ability to manage all their clients WordPress instances from their single reseller login. This eliminates the reseller having to login to each of their clients WordPress instances to manage them and can be done from their WordPress Toolkit access.

WP-CLI

The previous version of the WordPress toolkit used a patched version of the WP-CLI which mean for the more advanced user you had little to no access directly to the WP-CLI commands. Now with WordPress Toolkit 2.0 this problem is solved with direct access to WP-CLI. You can run any available WP-CLI command for any given WordPress instance from a shell terminal.

What's next?

Like everyone we are always eager to see what's next, never satisfied we are always wanting more. Talking to the Plesk team about their vision and future plans I am here to tell you there are some exciting things on the cards.
Backup is going to be a big focus which should assist in workflow for updates and management of WordPress sites and this is just one of the amazing features they are working on.  There's also the ability for other extensions to talk directly with the WordPress Toolkit via the included API, so that third parties can extend the functionality even further. We look forward to seeing what's possible.

Plesk 12 was the new benchmark in hosting panels, with the introduction of 4 new Plesk versions all targeted at specific segments of the Web Professional market space, we saw great opportunities in the market that were now accessible to us as a hosting provider.  With new feature rich add-ons, such as a new security core, including Fail2ban and ModSecurity additional outgoing email control and more integration with ServerShield by CloudFlare. Plesk 12 also introduced a new WordPress management toolset, designed to help the Web Professional manage multiple WordPress instances including installations and security updates. In case you missed the Plesk 12 release, a full breakdown of the new features can be found in our previous article What’s New in Parallels Plesk 12. 

With a solid foundation of Plesk 12, Odin has just announced the release their latest version 12.5. Plesk 12.5 was to be released as 12.1 however given the major improvements and revamp of the look and feel of Plesk Odin decided to release Plesk as 12.5. The exciting bit with Plesk 12.5 is that it is packed with features that have been requested and voted on by the Web Professional community. In essence, Plesk 12.5 is the Web Professionals own creation.

Here are some of the major feature improvements and additions to Plesk 12.5.

New look and feel

The first thing you will notice is the new look and feel with a more modern slicker colour scheme plus the new Odin branding. The interface is more intuitive with this change  which is surprising considering that the layout remains the same the only real change is Plesk 12.5 now has some real style.

New Home View

New Domain View

Support for Multiple PHP Versions

The single biggest feature request for Plesk has been the ability to run multiple PHP versions that can be managed by Plesk itself. You now no longer need to compile and modify your Plesk server via command line. Plesk 12.5 now comes with support for multiple versions of PHP out of the box. This new feature is available for both Windows and Linux. We did see an early release of this feature in Plesk 12 however 12.5 adds more refinement and options.

Plesk 12.5 ships with the following PHP versions:

5.2,  5.3 , 5.4,  5.5,  5.6

With this new multiple PHP support as standard in Plesk 12.5 as soon as PHP 7 is released Plesk 12.5 will support it. For more details on PHP 7 here is an article: PHP 7 – A Sneak Peek by Matthew Setter

To access your server wide PHP Settings, Plesk now has a new tab under Tools & Settings – General Settings – PHP Settings. You can view each PHP handler and how many domains are running that version of PHP. You can also install additional handlers using the Plesk Installer link.

You also have the ability to drill into individual PHP Settings and manage what PHP modules you wish to use, independently for every PHP version and handler type.

You can also modify the php.ini file for any PHP handler, you just need to be careful as this can affect all domains using that specific handler.

Improved PHP Support

PHP support was improved in a number of ways in Plesk 12.5 to better suit PHP developers and their development practices. Administrators can choose the list of PHP modules to use for every combination of PHP version and handler type.
With this improvement, Administrators and resellers can also define whether their customers will be able to select PHP versions and PHP handlers for their sites. The corresponding permission is available in service plans and subscription settings. It can be managed from Plesk, as well as by means of command-line tools and XML-API requests. 

The following features and improvements were introduced:

Opcode cache modules support was added.

opcode cache is a system to cache the result of the PHP code compilation to bytecode. The system then can use the bytecode instead of compiling on every request. Different opcode cache systems are available, mostly depending on used PHP version. The support for  APC (Alternative PHP Cache) and Zend OPcache modules, as well as WinCache was added in Plesk 12.5. PHP accelerators substantially increase the speed of PHP applications. Improvements of web page generation throughput by factors of two to seven have been observed.

php-fpm support for Apache 2.4 was added.

According to the official Apache documentation, using PHP-FPM is the recommended way to run PHP under Apache 2.4. PHP-FPM is now set to be the default PHP handler when Apache 2.4 is installed on the server. Now it is also available for selection in the PHP handler list in individual domains’ web hosting settings, as well as in the service plan settings.

Domain Level PHP Support

With server wide improvements your clients and you now can control individual domains and what PHP versions you wish to run, via Website & Domains > PHP Settings in your domain webspace.

You can also choose what you wish PHP to run as.

Improved Database Management

Database management in Plesk 12.5 has been improved considerably, you can now completely manage your databases from the Plesk GUI giving users easy self-management capability. Some Database management improvements are below the surface, Plesk 12.5 now includes new command line tools to check database connectivity over the network plus a new Plesk repair tool to resolve inconsistencies between Plesk and MySQL or Microsoft SQL server databases. Using the new Plesk repair tool you can restore databases, database users and database user credentials. You can also check disk space usage of remote databases.

The User Interface (UI) of the Databases tab was re-worked to make it more intuitive, and make it easier for users to manage databases.

Users can now download and upload database dumps in native format using the Plesk interface. This is a marked improvement compared to the previous mechanism which involved the use of phpMyAdmin or myLittleAdmin, these options are still available via direct link in Plesk 12.5 UI.

The list of databases belonging to a subscription now includes short summaries for each database, including the database server, names of the assigned database users, the number of tables, and the size of the database. This provides the users with information at a glance, without the need to click on the database or drill down into menus.

A mechanism allowing users to check the integrity of database tables and resolve some issues automatically was implemented. It enables users to troubleshoot issues with databases faster and possibly resolve them without manual intervention.

The ability to move databases between subscriptions was added in Plesk 12.5. Customers can reassign databases they own between their subscriptions, while the Plesk administrator can reassign databases between all subscriptions on the server.

Scheduled Tasks

Task scheduler user interface was re-worked to make it more intuitive. Configuring the time and date at which a task is to run is much more straightforward, and notifications can now be configured on a per-task level.

Scheduled tasks are now divided into three broad categories:

• Run a command
• Fetch a URL
• Run a PHP script

This helps users to more easily configure a task of the desired type.

Improved Site Preview

The default site preview mechanism was reworked. Users now face far fewer restrictions on the type of content that can be viewed in the preview mode. In addition, the preview link now works outside of Plesk by default.

Log Browser

Users can now troubleshoot issues with their websites by parsing web server logs and displaying error messages and warnings. This saves the user the trouble of manually searching through the web server logs for error messages.  This feature would be one of the most useful additions for developers and web hosts, you can not only easily search on specific errors, times, IP’s and days, you can see logs in real time, using the real time updates button.

Incremental Backups Support

Another much-requested feature implemented in Plesk 12.5 is the support for incremental backups. An incremental backup, as compared to a full one, both takes up much less disk space and finishes much faster. This functionality enables the Plesk administrator to both drastically save on disk space used for customer backups and significantly reduce the server load. The backup operation is fairly resource-consuming, so making a full backup of every domain on the server can noticeably increase the load on the server for a few hours. Creating incremental backups instead solves this issue.

Additional Backup Security Options

With more focus on incremental backups and improvements all round with Plesk 12.5 backup system there is a real need to secure your backup. Plesk 12.5 now gives you the ability to protect your data contained in backups. You have two options, one is to use Plesk own encryption key which limits recovery only to the Plesk server where the backup was originally created, or specify your own password. It is recommended to specify your own password so you can recover your backup on any Plesk 12.5 installation.

Additional Security Add On Packs

With the release of Plesk 12.5 we are going to see more security add-on packs available. These add-ons will be bundled services like ServerShield by CloudFlare, ModSecurity and Plesk AntiVirus to name a few.

In my next article I will go into more detail around additional Security Add On packs and outline some of the new key features and benefits.

Other improvements worth a mention

There are a lot of new improvements that are worth a mention below is just a few for a complete list of improvements and changes see the Odin Plesk Change Log.

• Cloudlinux 7 Support
• Composer PHP Dependency Manager Support
• Additional command line Plesk repair tools
   

What’s next?

Odins next major release of Plesk is slated for 2016 should bring a bunch of new features and core performance improvements, with the main focus on the Plesk App Edition. With this focus Odin plans to build a platform allowing more flexibility for the App developer.

If you have a feature you want to see in the future releases of Plesk you can submit your idea direct with Odin or leave your comments below and we will pass them onto Odin Plesk Developers.

You can see full release notes on latest Plesk 12.5 on the Odin Website. If you just want to have a play you can download Plesk 12.5 and install on your own server and if required purchase a key from Odin at Plesk.com or Conetix.
 
Update: 31/10/2024 Full release notes of latest version of Plesk.  https://docs.plesk.com/release-notes/obsidian/change-log/  

Plesk 12.5 Whats New? https://t.co/wuZtBmoM0S @PleskbyOdin pic.twitter.com/yMpORpEgFQ

— Conetix (@conetix) October 6, 2015

Java is usually associated with big iron servers in stock exchanges, intensive mathematical calculations, or frontend GUI applications, which try to offer the same user interface experience across all platforms; though usually never quite making it.

Java is considered “enterprise software”, software which is typically complicated to develop, setup, test, and deploy. Recently, however, I came across a Java-based framework, one inspired by Sinatra, which just may change that impression. It’s called Spark.

In today’s post, I’m going to step you through setting it up on a Plesk 12 server, and show you how to create and deploy a basic web application.

What Is Spark

To keep it simple, here’s what the website has to say:

Spark is a simple and lightweight Java web framework built for rapid development. Spark’s intention isn’t to compete with Sinatra, or the dozen of similar web frameworks in different languages, but to provide a pure Java alternative for developers that want to, or are required to, develop in Java.

Spark focuses on being as simple and straight-forward as possible, without the need for cumbersome (XML) configuration, to enable very fast web application development in pure Java with minimal effort. It’s a totally different paradigm when compared to the overuse of annotations for accomplishing pretty trivial stuff seen in other web frameworks, for example, JAX-RS implementations.

Plesk Web Hosting Setup and Database Creation

The first thing we need to do is setup a new domain, or sub-domain. If you’re not familiar with how to do this, check out the quick guide here on the Conetix blog. This will step you through everything.

It makes reference to creating a database. But in this tutorial, we don’t need to worry about that. The guide needs you to supply a set of values as you step through; here’s a handy set to help you out.

Quick Note

I’ll assume, for the rest of this tutorial, that you’re using the following values for your account; though please change them to suit your setup.

Installing Java 1.8

To get everything setup, you need to be running, at least, Java 1.8. If you’re not sure what version you’re running, from the command line, or terminal, run the command java -version. This should output something similar to the following:

bash java version "1.8.0_31" Java(TM) SE Runtime Environment (build 1.8.0_31-b13)
Java HotSpot(TM) 64-Bit Server VM (build 25.31-b07, mixed mode)

If you have an installed version less than 1.8, you need to install it, and the best way is via the package manager. Assuming that the base operating system is Centos/RedHat, then you can install Java using the following command:

bash sudo yum install java-1.8.0-openjdk-devel.x86_64

After that’s done, you’ll also have to create a new environment variable, JAVA_HOME, as it’s required by Maven, which we’ll install next, and not automatically created by the package manager. To do so, I suggest you update /etc/profile, so that the change is universal, and add the following, at the bottom of the file:

bash export JAVA_HOME=/usr/lib/jvm/jre-1.8.0-openjdk-1.8.0.31-1.b13.el6_6.x86_64

 Installing Maven

With Java installed or upgraded to at least version 1.8, we next need to install Maven. If you’re not familiar with Maven, that’s OK, but over the longer term, you’re going to need to become familiar with it, if you want to develop more than hello world style applications using Spark.

But what is Maven? Paraphrasing the Maven website slightly:

Maven was originally started as an attempt to simplify the build processes in the Jakarta Turbine project. There was a desire to have a standard way to build projects, a clear definition of what the project consisted of, an easy way to publish project information, and a way to share JARs across several projects. The result is a tool that can now be used for building and managing any Java-based project.

Maven does the following five tasks for any Java project:

• Makes the build process easy
• Provides a uniform build system
• Provides quality project information
• Provides guidelines for best practices development
• Allows transparent migration to new features

If you’d like to become more familiar with Maven, there’s an excellent 5 minute tutorial, which will bring you up to speed on it. Otherwise download Maven, the latest version at the time of writing, is 3.2.5, and uncompress it. To save time, you can do this with the following command:

bash curl https://mirror.arcor-online.net/www.apache.org/maven/
maven-3/3.2.5/binaries/apache-maven-3.2.5-bin.tar.gz | tar zxv

This will result in the directory, apache-maven-3.2.5, being created. With that done, move the uncompressed directory to /opt/maven. You can use the following command to save time:

bash sudo mv apache-maven-3.2.5 /opt/ && cd /opt && sudo 
ln -s apache-maven-3.2.5 apache-maven

Then you need to update your environment to include the apache-maven/bin directory in your path. If you’re using Unix or Linux, then update your path similar to the below:

bash MAVEN_HOME=/usr/local/apache-maven; export PATH=$PATH":$MAVEN_HOME/bin";

Now we need to test that Maven’s available; which we can do by running the command below:

bash mvn -version

This should give you output to that below:

bash Apache Maven 3.2.5 (12a6b3acb947671f09b81f49094c53f426d8cea1; 
2014-12-14T18:29:23+01:00)
Maven home: /usr/local/apache-maven Java version: 1.8.0_31 Java home:
/System/Library/Java/JavaVirtualMachines/1.8.0.jdk/Contents/Home 
Default locale: en_US, platform encoding: MacRoman OS name: "mac os x", 
version: "10.10.2", arch: "x86_64", family: "mac"

If you see the output above, then we’re ready to get started creating the application.

Creating An Application

We now have the infrastructure we need ready to go, so it’s time to start creating an application. You can save time by cloning the SparkServletExample repository from Simon Rice. Run git clone https://github.com/simonrice/SparkServletExample.git in the subdomain directory to do so. This will form the basis of the code which will be reference throughout the remainder of the tutorial.

Where you do so doesn’t really matter, so long as it’s somewhere logical; though I suggest you clone it in your domain/sub-domain directory, which was created earlier when you setup a new sub-domain. I’ll assume that you’ve cloned it in the sub-domain directory. Given that, there’ll be a new directory there, called SparkServletExample.

Go in to that directory and have a look around. There’s not a lot to the repository, which you need to be concerned about, save for two files. These are:

• src/main/java/com/simonrice/sparkservletexample/HelloWorld.java
• pom.xml

HelloWorld.java, which you can see below, follows the Sinatra style. It declares three routes, '/', '/hello', and '/hello/:name', supplying Lamda functions as the second parameter, which will respond when any of the routes are requested. The first route, '/' will redirect to '/hello', which just outputs the string “Hello World”.

The third route, '/hello/:name' takes a named parameter, ‘:name’, which will be assigned to a variable in the Request object. Assuming that the user requested '/hello/matthew', then the route will output 'Hello, matthew!'.

package com.simonrice.sparkservletexample;

import spark.Request;
import spark.Response;
import spark.Route;
import spark.Spark;
import spark.servlet.SparkApplication;

public class HelloWorld implements SparkApplication {
  @Override
  public void init() {
    Spark.get(new Route("/") {
      @Override
      public Object handle(Request request, Response response) {
        response.redirect("/hello");
        return null;
      }
    });

    Spark.get(new Route("/hello") {
      @Override
      public Object handle(Request request, Response response) {
        return "Hello World!";
      }
    });

    Spark.get(new Route("/hello/:name") {
      @Override
      public Object handle(Request request, Response response) {
        return  String.format("Hello, %s!", request.params(":name"));
      }
    });
  }
}

The POM.xml Configuration File

Now let’s look at pom.xml. This file is the Maven project configuration file, providing everything Maven needs to know to be able to manage the project. Let’s look over the key sections. There’s the initial configuration, down to repositories; this sets out the name of the project, the type of package to build (war).

Then we have the build information, which lists the plugins required to build and deploy the project. In our case, we have the maven-compiler-plugin, which is responsible for compiling the code, org.mortbay.jetty which is responsible for running the project, and org.apache.maven.plugins which gets the project ready to run.

Finally we have the dependencies. These are all the libraries which the code makes reference to. In this case, there’s only one, Spark. This references the Maven repository. So if you need to add further dependencies, you need to search for the package, then copy the dependency XML from the package page.

Here’s an example of searching for logging.

Deploying The Application

With that done, we now need to launch the deployment process, which will compile the source files, packaging them up in to a Jar file, and launch the Apache Jetty server, which will listens for requests on port 8080. If you’re not familiar with Apache Jetty, it’s a Java HTTP (Web) server and Java Servlet container.

To get it started, run the following command in the root of the project directory:

bash mvn jetty:run

You’ll likely see a lot of output, similar to that below, which I’ve truncated for sakes of space.

bash [INFO] <<< jetty-maven-plugin:8.1.5.v20120716:run (default-cli) 
< test-compile @ sparkServletExample <<<
[INFO] [INFO] --- jetty-maven-plugin:8.1.5.v20120716:run (default-cli) 
@ sparkServletExample --- [INFO]
Configuring Jetty for project: Sample Spark Servlet Webapp 
[INFO] webAppSourceDirectory
/Users/mattsetter/Workspace/settermjd/Java/Maven/SparkServletExample/src/main/webapp
?does not exist.
Defaulting to /Users/mattsetter/Workspace/settermjd/Java/Maven/SparkServletExample/
src/main/webapp 
[INFO] Started Jetty Server

If that’s what you see, then Jetty is ready and listening for requests, so open up your browser to https://spark.conetix.com:8080 where you can test that everything is working.

Setting Up Apache as a Reverse Proxy

Assuming that everything went well, let’s now setup Apache as a reverse proxy to the Jetty server so that requests can be made without specifying the port.

This will have Apache pass all requests to the Spark sub-domain to our Spark application. Secondly, we need to create an initialisation shell script, to make sure that our Spark application is started when the server boots.

Thanks to the smooth Plesk 12 interface, configuring Apache as a reverse proxy is quite straight-forward. Under the hosting settings for the sub-domain, click Show More at the bottom.

Then click the second option, in the middle column, labeled Web Server Settings, which you see in the screenshot below.

Then, when the page’s loaded, under Additional directives for HTTP, add the following configuration directives:

ProxyRequests Off

<Proxy *>
Order deny,allow
Allow from all
</Proxy>

ProxyPass / https://localhost:8080/
ProxyPreserveHost On

Service Initialisation Script

To keep this as simple as possible, use a script I created, available in this Gist. This will allow for the server to be both started and stopped as needed. Save that file in /etc/init.d as spark-service.

We now need to enable the script to be called at the correct runlevel. To do so, run the following commands:

chkconfig --level 345 spark-service on chkconfig --list | grep spark-service

This will setup the script as required and do a quick validation that it was done successfully. You should see the following output:

spark-service 0:off 1:off 2:off 3:on 4:on 5:on 6:off

 Wrapping Up

OK, that’s a little bit of work, at least for the initial setup. But when it’s complete, you’ll have a setup in which you can deploy a large number of Spark/Java applications quite quickly, and reliably.

One which provides a standardised, effective, and efficient environment, supported and maintained by a large number of people. I hope you’ll consider using the Spark Framework for your next application.

I’m keen to give you a range of options so that when things go wrong, as they invariably do, you can quickly ascertain what happened, and mitigate the issue.

We started off with the cloud-based service Loggly, one which I use and highly recommend. But whilst good, Loggly’s not the only option available. There are others, one of which I’m going to show you today. It’s called logentries.

What Is logentries

Logentries, like Loggly, is a cloud-based Logging service, one which you only need to configure your existing servers to send their logs to, then periodically, or as needed, use the UI to search through the recorded data for the information you need.

It provides a range of features to let you do this quickly and intelligently, including:

• Real-time monitoring
• Real-time alerting
• Notifications to a range of existing services, such as PagerDuty, HipChat, and New Relic

Getting Started

Getting started is a lot like Loggly, though requires a number of steps to be performed, whereas Loggly provides a one-step configuration script. With logentries, you have to add a host, which will contain a log configuration, to which logs will be sent.

But before we begin, if you don’t already have an account, first sign up for one. Then, after you’ve done that, login, and in the right hand column, click + Add New to start the process off, which you can see in the screenshot below.

Next, you’ll be presented with the initial configuration screen. As I’m assuming that your Plesk server’s running on Linux, click the Linux option in the first row under “Operating Systems”.

Then, in the next screen, under “What Type Of Log Do You Want To Configure?”, click Syslog. You’ll then be taken to the third screen, which allows you to specify the Syslog daemon you have running.

For the sakes of simplicity, I’ve chosen Rsyslog, which is the current default on Centos/RedHat and Debian/Ubuntu installations. But if you have Syslogd or Syslog-ng, then choose those instead. Next, you have to do two things; firstly, you have to click “Click here to add your new log to an existing host.”.

This will then present you with a list of hosts, of which there should only be one. Click that, then click the large grey button at the bottom, labelled “Configure my Syslog”. This will give you the settings you need to configure Syslog to start sending it’s log information to your logentries account.

The configuration does say “Place the following at the bottom of your rsyslog config file at /etc/rsyslog.conf”. But I suggest instead ignoring this and creating a new file under /etc/rsyslog.d, called logentries.conf, and instead adding the configuration there.

This way it’s easier to find and to manage. Once done, you then need to restart Rsyslog, which you can do by running sudo service rsyslog restart. That’s the configuration take care of. Now it’s time to get some logs in to your account.

If your Plesk server has a number of services and daemons already running, then you can likely just wait a minute or two. However, if you’d like to rush, then you can run the following command, which will add an entry for you:

bash logger -t test Hello there logentries it's Plesk 12 calling

Searching For Data

Now that data’s being sent to logentries, it’s time to get familiar with the UI so you know how to find what you’re after. As I mentioned at the start of the article, the UIs of Loggly and logentries are reasonably similar.

So this should be quite familiar if you’ve read the previous article. If not, you should find your way around well enough. From your dashboard, you’ll see the host you added on the left hand side.

Clicking it, you’ll see in the right hand side, details for it, and at the bottom the log you created. Click the name of the log, and you’ll step down in to the log information display.

Starting from the top, you’ll have a search bar, and time period filter; you’ll then have an entries graph, and at the bottom, a textual list of the log entry data. There’s quite a bit to it, which, unfortunately I’m not able to cover insufficient depth in this post. But I encourage you to explore, as time permits.

You can see in the screenshot above, that a number of services, including kernel, rsyslogd, and postfix have been sending log data. Let’s say that we just want to filter down on kernel and rsyslogd. To do that, we’ll use the following search expression: kernel OR rsyslogd.

This will filter the results down to what you see in the screenshot below. Unlike Loggly, the search results aren’t highlighted in this case. However, if we just used one search term, such as kernel, then they would be.

Another way to search would be to instead click on a term that you’re interested in. Logentries does a good job of highlighting key terms. So have a look over the results you have and see what options are available to filter on.

If you’d like more information on the search options available, be sure to check out the search documentation. It’s quite thorough and definitely helpful. You can search using aggregate expressions, free text, keyword expressions, logical expressions, regular expressions, and more.

Wrapping Up

And that’s how to configure your Plesk server to send it’s syslog data to the cloud-based logging service, logentries. Whilst there is a bit of manual work required to get your account setup, and the configuration ready to go, both in your account and on your server, the process is quite straight-forward.

However whilst the process is, on the whole, quite logical, it could do with an automation script to streamline the process. That said, I hope you see that there’s yet another option for sending, storing, and searching your server’s log data, one which makes it easy to stay on top of what’s happening and to respond as needed.

Logging, whether it’s a part of a DevOps or software development, is an essential ingredient. Why? Because when things start going wrong, as they invariably do from time to time, you need to have information at hand which allows you to get to the root cause of the issue.

Getting in depth about what you should and shouldn’t log is beyond the scope of this post. Instead today, I’m going to show you how to integrate your Plesk 12 server setup with one of the best Logging services around, Loggly.

What Is Loggly?

To keep it concise, Loggly is:

An agent-less, pay-as-you-go, cloud-based logging service; one which allows you to store an enormous amount of log data along with a simple and intuitive interface to find the information you need

In the screenshot below, you can see a sample dashboard, one which, if you follow this tutorial, will become quite familiar to you. It sports an easy search interface at the top, allowing for setting the start and end dates, shows a graph of the number of events within the date range, along with a snapshot of the event information.

There’s much more to it than I can cover here; suffice to say, it’s a nice setup.

Getting Started

Before we go any further, you need to have an account with Loggly. If you don’t, you need to sign up for one. After that, you need to run the commands below, from the command line, once logged in to your Plesk 12 server. These will download and run the Loggly configuration script.

curl -O https://www.loggly.com/install/configure-linux.sh
sudo bash configure-linux.sh -a SUBDOMAIN -t TOKEN -u USERNAME -p PASSWORD

You can see a number of parameters specified above, these are as follows:

• SUBDOMAIN: your account subdomain that you created when you signed up for Loggly
• TOKEN (optional): your customer token from the source setup page
• USERNAME: your Loggly username
• PASSWORD: (optional): your Loggly password. This argument is optional and it will prompt you if you don’t supply it.

What Does The Script Do?

I’m sure you’re likely not really comfortable running an unknown script on your server. So here’s what the script documentation says:

The script will perform over 10 system checks below to make sure your system is compatible with Loggly and that it can successfully send logs to Loggly. To configure the system, it executes the same instructions in rsyslog manual configuration by writing a configuration file named /etc/rsyslog.d/22-loggly.conf which will send the system logs to Loggly. It then restarts the rsyslog service so the changes take effect. The verification step sends a test log message with a UUID, and then retrieves it back through Loggly’s search API. If it is able to retrieve the log, then the configuration is successful. It also logs the status of your setup experience to Loggly which you can use to trouble-shoot if you experience difficulty during setup. 

As you run the script, you’ll likely see the following output in your terminal, which I’ve truncated for sakes of readability.

INFO: Initiating Configure Loggly for Linux.
INFO: Operating system is CentOS. 
INFO: Checking if logs-01.loggly.com is reachable. 
INFO: Restarting the rsyslog service. 
Shutting down system logger: [ OK ] 
Starting system logger: [ OK ] 
INFO: Creating directory 
mkdir: created directory `/var/spool/rsyslog' 
INFO: Sending test message to Loggly. 
SUCCESS: Verification logs successfully transferred to Loggly!
You are now sending Linux system logs to Loggly.

What Changes Does It Make?

If you now look in /etc/rsyslog.d/22-loggly.conf, you’ll see that the following configuration has been added to it. This will send any log record, which is sent to the system Syslog daemon, to your account on Loggly, using their standard log format.

# Define the template used for sending logs to Loggly. Do not change this format.
$template LogglyFormat,"<%pri%>%protocol-version% %timestamp:::date-rfc3339%
%HOSTNAME% %app-name% %procid% %msgid% [8fbf831a-c1c9-4763-a3fe-efcae5c8273c@41058]
%msg%n"

# Send messages to Loggly over TCP using the template.
*.*             @@logs-01.loggly.com:514;LogglyFormat

Searching For Data

Now that you’ve got data being sent to your account, it’s time to learn the basics of the Loggly interface, so you can search it. From the Loggly home page, login to your account, where you’ll be greeted with the default dashboard.

This shows all entries for the last 24 hours, any alerts, along with a set of 4 saved searches. If you’ve got even a moderately busy server, you’ll already have a good number of records which you can search from.

In the top navigation bar, click on Search which will open a new dashboard tab. You can see mine is showing all records for the last seven days.

By default, no search query will be entered. Under the main search box, click the double-down arrow, to see the basic examples of how to search.

For more information, click ‘Advanced’. You can see there are a 7 core search types: Full Text, Ordered Tokens, Wildcards, Boolean, Field Value, Numeric Range, and Regular Expression.

What we’re going to search for is a combination of Ordered Tokens and Boolean. I’ve used the search term www-data AND "processing" OR "read". You can see that once the search has completed, the results are filtered, and the matching records have also been highlighted.

This helps you know why the result was returned, and how it matched your search criteria. Picking the second record, you can then step in to it and inspect it further, seeing when it arrived, what the message, tag and other information contained in it is.

There’s a lot to the interface, the rest of which is beyond the scope of this post. So I encourage you to take the time to explore it, and see what kinds of searches you can run, and data you can uncover.

 Wrapping Up

And that’s all you have to do to send your Syslog messages to Loggly. Over the last several months I’ve researched and reviewed a number of logging services, and Loggly, amongst one or two others, is definitely a favourite of mine.

If you have any questions about what’s been covered here, make sure you check out the online documentation. As well as that, make sure you have a play around with the Loggly interface. There’s a lot to it, so becoming familiar will take some time.

This is a little unfortunate, but it’s no deal breaker; and to be fair, as they’re frameworks, not complete applications, it makes sense. Given the flexibility of Plesk 12, as administrators, developers and devops, we’re able to do take care of all the necessary steps manually.

In today’s tutorial, I’m taking you through how to set up and deploy a basic Laravel 4 application on Plesk 12. By the time we’re done, you’ll see the site, as in the screenshot below.

Before we get started though, I should say that it won’t be a shining example of a world-beating application, but it will have the core Laravel 4 framework installed, ready and configured with a connection to a MySQL backend database. So if you’re keen to step further, you’re in the best position to do so.

What Is Laravel

Before we dive in to the setup, what is Laravel? Laravel is one of the newer PHP frameworks, dubbed as “The PHP Framework For Web Artisans.”

First released by Taylor Otwell on the 22nd February, 2012, it’s risen rapidly to become the most popular open-source, PHP, project on GitHub.

Dubbed as being great for both beginners and more experienced developers, Laravel comes packed with features, including RESTful routing, fast and efficient templating, a feature-rich ORM layer andmigrations support.

What’s more, the community is extremely active and has created a number of tools, such as Laravel Homestead and Laravel Forge which make going from development to production almost trivial.

Prerequisites

To complete today’s tutorial, you’re only going to need one prerequisite, which is:

• Admin access to Plesk
• Plesk System User with ssh access (if not, we create one in this article)
• The server must have mcrypt installed

Getting Setup

Right, so what do we need to do to set it up? Thanks to the modern UI, and intelligent layout available in Plesk 12, it’s a real no brainer, requiring only a few steps to have it live; which are as follows:

• Create a Sub-Domain
• Setup SSH Access
• Create The Database
• Install Composer
• Install Laravel
• Configure Laravel
• View The Application

Let’s work through the process now.

Create a Sub-Domain

When you first login to your account, click the Domains in the left-hand side navigation bar, under Hosting Services. To keep this simple, we’re going to create a new sub-domain, specifically under conetix.com.

On the far right of that domain’s row in the table, click “Manage Hosting“. This will display the domain and sub-domain entries, which you can see in the screenshot below.

Above the first entry, you’ll see three buttons: “Add New Domain“, “Add New Subdomain” and “Add New Domain Alias“. Click “Add New Subdomain”, and on the form which appears, enter “laravel” for the subdomain name. The Document root field will be pre-populated, based on the Subdomain name you entered. But at the end, add in “/laravel/public”.

The reason for this is that the command we’ll run to install Laravel creates a sub-directory, called laravel, and the application’s bootstrap file is located in the public directory beneath that. 

When it’s finished you’ll be back on the domains page you started at, with your new domain available at the bottom of the list. In the entry, you’ll see all the pertinent details, along with links to more, as well as to make changes.

Setup SSH Access

Now we need to check that SSH access is setup properly, so that we can login and run a few command line scripts. If you’re not too familiar with command line scripts, that’s ok. The one’s I’ve listed here are quite simple and have sufficient documentation, should it be needed.

At the bottom of the subdomain’s entry, click the tab titled “Show More“, then click the first entry in the exposed list, titled “Web Hosting Access“. On the page that appears, you’ll see four sections.

In the second section, titled “System user“, make sure that the last option, “Access to the server over SSH“, is set to /bin/bash or /bin/sh and click OK at the bottom.

The reason for this is because these scripts need that environment to run in. sh may work, but bash works best for this example. Now you’re ready to login and begin installing the application.

Note: if you’re not sure of the user’s password, either regenerate it or check with your systems administrator.

Create The Database

Now we have one last pre-install step to do, create a database. Back in the sub-domain settings, above the “Show Less” tab, on the right you’ll see a Databases option.

Next to it, click “Add New Database“, where you’ll be directed to create new database form, as in the screenshot below.

On that page, set “Database name” to “admin_laravel“, leave “Create a new database user” checked and set “Database user name“ to “laravel_user“. Set a secure password under "New Password/Confirm Password". Make a note of these details as you will need them later in the article. For “Access control“, choose the first option, “Allow local connections only“, then click OK.

You’ll then be redirected to the databases list, where you’ll see the new database last in the list (or the only one if this is the first). Feel free to inspect it if you like, but there’s no need to to complete this tutorial.

Install Composer

Now we’re ready to begin installation of Laravel. To do so, we’re going to use Composer. If you’re not familiar with Composer, it’s a dependency manager for PHP.

In years gone by, many projects implemented common functionality, such as routing, database layers, caching interaction and logging on their own, making it difficult to port applications to newer or different frameworks, or for them to be maintained in a cost and time-effective.

Composer makes it almost painless for best of breed libraries for any specific purpose to be created, voted on, discovered and most importantly used in applications.

To find out more about it, I encourage you to read this introduction to it or a walk through of the Composer Cheatsheet I made for Sitepoint. You’ll be up and running with it in no time.

To install composer, login as the Plesk System User we created earlier and cd to ‘/var/www/vhosts/conetix.com/laravel.conetix.com’ substituting ‘conetix.com’ based on your domain setup; then run the command below:

curl -s https://getcomposer.org/installer | php --

This downloads Composer, piping it through to PHP, in the process creating a self-contained file we can use, called composer.phar.

Install Laravel

Now we need to install Laravel. From your current directory, run the command below:

php ./composer.phar create-project laravel/laravel --prefer-dist

This will install Laravel in the directory structure we covered earlier, displaying output similar to that below.

Installing laravel/laravel (v4.2.0)
   - Installing laravel/laravel (v4.2.0)
     Loading from cache 
     
Created project in
/var/www/vhosts/conetix.com/laravel.conetix.com/laravel
Loading composer repositories with package information
Installing dependencies (including require-dev)
   - Installing symfony/debug (v2.5.2)
   Downloading: 100% 
   
   - Installing symfony/http-foundation (v2.5.2)
   Downloading: 100% 
   
   - Installing swiftmailer/swiftmailer (v5.2.1)
   Downloading: 100% 
   
   - Installing laravel/framework (v4.2.7)
   Downloading: 100%

Configure Laravel

Assuming that there are no errors, timeouts or permission issues, now we need to configure the setup. So cd to laravel the new directory and using vim or your editor of choice edit app/config/app.php. In the file, set the following options:

Save the changes, then edit app/config/database.php and find the section marked ‘connections’ and make sure the settings are as below for the mysql sub-option (these are the same details used when setting up the database earlier):

For the password, insert your generated password. Saving that, you’re now ready to run the default, Laravel, application.

4. View The Application

Let’s have a look at the running app. It’s not special, as there’s no new controllers or actions beyond the default; it’s just a one page application, but it works.

Wrapping Up

In just a few minutes, we’ve stepped through creating and configuring a sub-domain, to installing a sample application, based on the Laravel framework.

Now it’d be great if it was simpler, such as having an installer for Drupal, Joomla and WordPress. But it’s a bit hard to compare off the shelf applications, such as these, to frameworks which allow for creating nearly any kind of application.

What I’m hoping for is to have an installer which lays the foundation for this process, which may just be available in the future.

Till then, share your thoughts in the comments. Has this made it simpler for you to start creating applications with Laravel on Plesk? I hope so. I’d love to hear how you feel.

This is a little unfortunate, but it’s no deal breaker; and to be fair, as they’re frameworks, not complete applications, it makes sense. Given the flexibility of Plesk 12, as administrators, developers and devops, we’re still able to do quite a bit manually.

In today’s tutorial, we’re going to guide you through the process of setting up and deploying a basic Ruby on Rails 4 application on Plesk 12. By the time we’re done, you’ll see the site as in the screenshot below.

Before we get started, I should say that it won’t be a shining example of world-beating application, but it will have the core Ruby on Rails 4 framework installed, ready and configured with a connection to a MySQL backend database.

What is Ruby on Rails (RoR)

In a nutshell, according to David Heinemeier Hansson, the creator and lead developer of Ruby on Rails:

Most frameworks and languages were focused on neither fun nor productivity. The forging ground was quick ‘n’ dirty with PHP or slow ‘n’ clean with Java. There was room for something quick ‘n’ clean in the middle.

So with that in mind, Ruby on Rails is an open source, web application framework, that’s “optimized for programmer happiness and sustainable productivity. It let’s you write beautiful code by favouring convention over configuration“.

Like Zend Framework 2, Laravel and FuelPHP, it’s a full stack framework which allows creating pages and applications which talk to or query the database, and render templates out of the box.

Prerequisites

To complete today’s tutorial, you’re only going to need a few prerequisites. These are:

• Curl
• Linux build tools (such as make and configure)
• Root access (or user with sufficient privileges or who’s in the sudoers list)

Getting Setup

Right, so what do we need to do to set it up? Thanks to the modern UI, and intelligent layout available in Plesk 12, it’s a real no brainer, requiring only a few steps to have it live, which are as follows:

• Create a Sub-Domain
• Setup SSH Access
• Install Ruby on Rails
• Configure Ruby on Rails
• View The Application

Let’s work through the process now.

Create a Sub-Domain

When you first login to your account, click the Domains in the left-hand side navigation bar, under Hosting Services. This will then show you the list of your websites & domains. To keep this simple, we’re going to create a new sub-domain, specifically under conetix.com.

On the far right of that domain’s row in the table, click Manage Hosting. This will display the domain and sub-domain entries, which you can see in the screenshot below.

Above the first entry, you’ll see three buttons:

• “Add New Domain”
• “Add new Subdomain”
• “Add New Domain Alias”

Click “Add New Subdomain”, and on the form which appears, enter “ror” for the subdomain name. The Document root field will be pre-populated, based on the Subdomain name you entered. At the end, add in “/ror/public”.

The reason for this is that the command we’ll run to install Ruby on Rails creates a sub-directory called Ruby on Rails and the application’s bootstrap file is located in the public directory, inside it.

It may take a minute or two for the subdomain to be created, based on your server’s specifications. But it shouldn’t take too long.

When it is, you’ll be back on the domains page you started at, with your new domain listed at the bottom of the list. In the entry, you’ll see all the pertinent details, along with links to more, as well as to make changes.

Setup SSH Access

Now we need to check that SSH access is setup properly, so that we can login and run a few command line scripts. If you’re not too familiar with command line scripts, that’s ok.

The one’s I’ve listed here are quite simple and have sufficient documentation, should it be needed.

At the bottom of the subdomain’s entry, click the tab titled “Show More”, then click the first entry in the exposed list, titled “Web Hosting Access”. On the page that appears, you’ll see four sections.

In the second section, titled “System user”, make sure that the last option, “Access to the server over SSH”, is set to /bin/bash or /bin/sh and click OK at the bottom.

The reason for this is because these scripts need that environment to run in. sh may work, but bash works best for this example. Now you’re ready to login and begin installing the application.

Note: if you’re not sure of the user’s password, either regenerate it or check with your systems administrator.

Installing Rubygems

Now that the database is installed, we need to install all Ruby on Rails along with all the required dependencies; we’ll start with the first dependency, Rubygems. To do so, use the following command which suits your platform:

Installing Rails

Now that the Rubygems is installed, it’s time to install Rails. To do so, from the command line run the following command:

gem install rails

Potential Errors

Missing Development Packages

You may encounter errors attempting to install it; one of the main ones is not having the necessary development packages or libraries. If so, you’ll likely see an error like this one:

Building native extensions.  This could take a while...
ERROR:  Error installing rails:
    ERROR: Failed to build gem native extension.

/usr/bin/ruby extconf.rb
mkmf.rb can't find header files for ruby at /usr/lib/ruby/ruby.h

If you see this error, first make sure you have both gcc and ruby-devel installed. You can do that use one of the following commands, which best suits your platform:

Incorrect Version of Ruby

The next error you may encounter, is the following, which indicates you need a higher version of Ruby than what’s installed.

ERROR:  Error installing rails:
    activesupport requires Ruby version >= 1.9.3.

If that’s the case, you may find that your distribution’s package manager is already at the latest version. This can be done by running yum info ruby.

If so, don’t worry, you don’t need to install a version of Ruby from source; though you can if you want to. Instead, install the Ruby Version Manager (RVM) which handles the installation, uninstallation and configuration of multiple versions of Ruby on your system for you.

To do so, run the following commands in your terminal or console:

yum groupinstall -y development
gpg2 --keyserver hkp://keys.gnupg.net --recv-keys D39DC0E3
curl -sSL https://get.rvm.io | bash -s stable
source /etc/profile.d/rvm.sh
rvm reload
rvm install 2.1.0

What these commands do is first to ensure that you have all the development packages required to compile the code, then RVM is downloaded and the shell environment is updated to support the package. Finally version 2.1.0 of Ruby is installed.

When that’s done, if you’d like to verify the installation, run the following two commands:

ruby --version
rvm list rubies

After all this prep work, you shouldn’t encounter any further errors. So run gem install rails again, where you should see output like the following, (truncated for readability):

Installing ri documentation for treetop-1.4.15
Parsing documentation for tzinfo-1.2.1
Installing ri documentation for tzinfo-1.2.1
Done installing documentation for actionmailer, actionpack, 
actionview, activemodel, activerecord, activesupport, arel, 
builder, erubis, hike, i18n, mail, mime-types, minitest, multi_json,
polyglot, rack, rack-test, rails, railties, sprockets, sprockets-rails,
thor, thread_safe, tilt, treetop, tzinfo after 479 seconds

Installing Additional Libraries

Now that Rails is installed, we need to install some additional libraries which it will need (just to be sure that they’re available on your system), which they aren’t by default. What we’ll need is a JSON gem and a JavaScript runtime, provided by Node.js. To get them installed, from your terminal, run the following commands:

gem install json -v '1.8.1'
curl -sL https://rpm.nodesource.com/setup | bash -
yum install -y nodejs

That will take just a little while to complete, but will be the last Rails dependency you’ll need to be up and running.

Creating the Ruby on Rails Application

Now that we’ve gotten all the Ruby on Rails dependencies out of the way, let’s create a basic, template, application. Gladly, there’s not a lot to do, just two steps. From the RoR directory, run the following commands. What these do are to firstly generate a stub application, then to precompile the static asset files, such as CSS, JavaScript.

rails new .
bundle exec rake assets:precompile RAILS_ENV=development

If however you’re deploying to production, change development above to production.

Install Unicorn with Apache

Now that we have all of the Ruby-based components installed and ready to go, and our basic Ruby on Rails application created, we need to connect it to the Apache Webserver. To do so, we’re going to configure Apache as a reverse proxy. This will have Apache pass all requests to the rails sub-domain to the Ruby server, Unicorn (which we’ll also setup).

What is Unicorn?

According to the official website, Unicorn is:

an HTTP server for Rack applications designed to only serve fast clients on low-latency, high-bandwidth connections and take advantage of features in Unix/Unix-like kernels. Slow clients should only be served by placing a reverse proxy capable of fully buffering both the the request and response in between Unicorn and slow clients.

To install it, from your terminal, run the following command:

gem install unicorn

Configuring Apache as a Reverse Proxy

Thanks to the smooth Plesk 12 interface, configuring Apache as a reverse proxy is quite straight-forward. Under the hosting settings for the sub-domain, click Show More at the bottom.

Then click the second option, in the middle column, labeled Web Server Settings, which you see in the screenshot below.

Then, when the page’s loaded, under Additional directives for HTTP, add the following configuration directives:

<Proxy balancer://unicornservers>
    BalancerMember https://127.0.0.1:5001
</Proxy>

RewriteCond %{DOCUMENT_ROOT}/%{REQUEST_FILENAME} !-f
RewriteRule ^/(.*)$ balancer://unicornservers%{REQUEST_URI} [P,QSA,L]

ProxyPass / balancer://unicornservers/
ProxyPassReverse / balancer://unicornservers/
ProxyPreserveHost on

<Proxy *>
    Order deny,allow
    Allow from all
</Proxy>

What this does is to pass all traffic through to the Unicorn server listening on port 5001, for requests to the sub-domain.

As Plesk restarts Apache when you make any configuration changes, there’s no need to seek out a restart option or to do it from the command line.

Start Unicorn

To start Unicorn, go to the project directory, which you’ll find at/var/www/vhosts/conetix.com/ror.conetix.com/rails.app and run the following command:

unicorn_rails -p 5001 -E development -D

This will start the server in development mode. If you want to run it in production, change development to production and set the secret_key_base for the production configuration in config/secrets.yml.

Set Unicorn to Reload if Terminated

Finally, there’s one last step. Sometimes Unicorn may crash, which can occur for a variety of reasons; it also may just need to be restarted.

So we need to ensure that it will automatically be restarted. To do that, open `/etc/rc.local in your editor of choice and add in the following code snippet:

ROR_MODE=development
ROR_DIR=/var/www/vhosts/conetix.com/ror.conetix.com/
cd $ROR_DIR && unicorn_rails -p 5001 -E $ROR_MODE -D

I’ve already added some documentation, but to reiterate, I’ve set to shell variables, one for the runtime mode and the other for the application directory. Change these as suits your configuration.

Then I’ve added the boot script, passing in the configuration variables. Now, if the daemon crashes, Linux will restart it automatically for us.

View the Application

Right, now that it’s installed, let’s have a look at the running app. It’s not special, as there’s no database, logging, or caching server connections. It’s just a one page application, but it works.

Wrapping up

So there you go. In just a few minutes, we’ve stepped through creating and configuring a sub-domain, to installing a basic Ruby on Rails application, served via a combination of Unicorn and Apache acting as a reverse proxy.

Now it’d be great if it was simpler, such as having an installer for Drupal, Joomla and WordPress. But it’s a bit hard to compare off the shelf applications, such as these, to frameworks which allow for creating nearly any kind of application.

What I’m hoping for is to have an installer which lays the foundation for this process, which may just be available in the future.

Till then, share your thoughts in the comments. Has this made it simpler for you to start creating applications with Ruby on Rails (ROR) on Plesk? I hope so. I’d love to hear how you feel.

Links

• https://robmclarty.com/blog/how-to-setup-a-production-server-for-rails-4
• https://www.digitalocean.com/community/tutorials/how-to-install-ruby-2-1-0-on-centos-6-5-using-rvm
• https://www.javaworld.com/article/2459944/scripting-jvm-languages/happy-10th-anniversary-ruby-on-rails-but-watch-your-back.html
• https://www.infoworld.com/d/security/ruby-rails-security-updates-patch-xss-dos-vulnerabilities-232092
• https://blog.bensigelman.org/post/57543889435/why-nobody-should-use-rails-for-anything-ever
• https://github.com/teambox/teambox/wiki/Installing-on-Ubuntu-using-Apache-and-Unicorn

This is a little unfortunate, but it’s no deal breaker; and to be fair, as they’re frameworks, not complete applications, it makes sense. Given the flexibility of Plesk 12, as administrators, developers and dev ops, we’re able to do take care of all the necessary steps manually.

In today’s tutorial, we’ll step through the process of setting up and deploying a basic FuelPHP 4 application on Plesk 12. By the time we’re done, you’ll see the site as in the screenshot below.

Before we get started, I should say that it won’t be a shining example, world-beating, application but it will have the core FuelPHP 4 framework installed, ready to use.

What Is FuelPHP

Started in October 2010 by Harro Verton, Jelmer Schreuder, Dan Horrigan, Philip Sturgeon and Frank de Jonge, FuelPHP,

is a simple, flexible, community driven PHP 5 web framework. It was born out of the frustrations people have with the current available frameworks and developed with support from a community of developers. FuelPHP is extremely portable, works on almost any server and prides itself on clean syntax.

I chose this one because it combines power with simplicity. So it’s a good package to use, whether you’re a beginner or more experienced developer.

Similar to Laravel, Ruby on Rails and Zend Framework 2, FuelPHP comes complete with a URL routing system, RESTful and HMVC implementation, support for multiple template engines, including Mustache, Markdown, Smarty, Twig and Haml, an ORM, Auth package and caching system.

To know more about it, check out the FuelPHP website or the Wikipedia documentation.

Prerequisites

To complete today’s tutorial, you’re only going to need a few prerequisites. These are:

• Git
• Awk
• Root access (or user with sufficient privileges or who’s in the sudoers list)

Getting Setup

Right, so what do we need to do to set it up? Thanks to the modern UI, and intelligent layout available in Plesk 12, it’s a real no brainer, requiring only a few steps to have it live, which are as follows:

1. Create a Sub-Domain
2. Setup SSH Access
3. Install FuelPHP
4. Install Composer
5. Configure FuelPHP
6. View The Application

Let’s work through the process now.

Create a Sub-Domain

When you first login to your account, click the Domains in the left-hand side navigation bar, under Hosting Services. This will then show you the list of your websites & domains.

In our example, we have a few existing ones; but to keep this simple, we’re going to create a new sub-domain, specifically under huffyscrew.com. On the far right of that domain’s row in the table, click “Manage Hosting“. This will display the domain and sub-domain entries, which you can see in the screenshot below.

Above the first entry, you’ll see three buttons: “Add New Domain“, “Add New Subdomain” and “Add New Domain Alias“. Click “Add New Subdomain”, and on the form which appears, enter “fuelphp” for the subdomain name. The Document root field will be pre-populated, based on the Subdomain name you entered. 

The reason for this is that the command we’ll run to install FuelPHP creates a sub-directory, called fuel, and the application’s bootstrap file is located in the public directory beneath that. It may take a minute or two for the subdomain to be created, based on your server’s specifications. But it shouldn’t take too long.

When it’s finished you’ll be back on the domains page you started at, with your new domain available at the bottom of the list. In the entry, you’ll see all the pertinent details, along with links to more, as well as to make changes.

Setup SSH Access

Now we need to check that SSH access is setup properly, so that we can login and run a few command line scripts. If you’re not too familiar with command line scripts, that’s ok. The one’s I’ve listed here are quite simple and have sufficient documentation, should it be needed.

At the bottom of the subdomain’s entry, click the tab titled “Show More“, then click the first entry in the exposed list, titled “Web Hosting Access“. On the page that appears, you’ll see four sections.

In the second section, titled “System user“, make sure that the last option, “Access to the server over SSH“, is set to /bin/bash or /bin/sh and click OK at the bottom.

The reason for this is because these scripts need that environment to run in. sh may work, but bash works best for this example. Now you’re ready to login and begin installing the application.

Installing FuelPHP

Now let’s get cracking and create our first FuelPHP application. Like many things in life, there’s a few ways to do it. You can use the scaffolding tool, called Oil or you can manually install it by cloning the Github repository and carrying out all the configuration by hand. As the latter is a bit error-prone and Oil is the preferred way to do it, we’ll be using Oil.

Oil is a utility which facilitates quick development, testing applications and running tasks, such as building MVC components, migrations, scaffolding, installing updating and removing packages and running PHPUnit tests.

Install Oil

So first, run the command below, which will install the oil binary in /usr/bin/oil. So make sure your user has sufficient permissions or is in the shudders list before continuing.

curl get.fuelphp.com/oil | sh && which oil

This command should print out /usr/bin/oil as the last part of the output, verifying that oil’s installed.

Create a FuelPHP Project

With oil installed, we can now use it to create a new project, which we’ll call fuel. To do so, first cd to the virtual host directory, then run the command below:

oil create fuel

As it’s executing, you should see output such as that below, which has been truncated for readability:

Initialized empty Git repository in
 /var/www/vhosts/conetixtest.com/fuelphp.conetixtest.com/fuel/.git/
remote: Counting objects: 15218, done.
remote: Total 15218 (delta 0), reused 0 (delta 0)
Receiving objects: 100% (15218/15218), 5.11 MiB | 890 KiB/s, done.
Resolving deltas: 100% (6115/6115), done.
Already on '1.7/master'
Updating to version 4ecdbf89c4a3d1e5dfe73c57e3202a5e2a18c87e.
    Downloading: 100%         
Use composer self-update --rollback to return to version
 e77435cd0c984e2031d915a6b42648e7b284dd5c
Loading composer repositories with package information
Updating dependencies (including require-dev)
  - Installing composer/installers (dev-master 41cf781)
    Cloning 41cf781ed1271e25bf31b715416a349996aa2527

  - Installing fuel/docs (1.7.2)
    Downloading: 100%         

  - Installing fuel/core (1.7.2)
    Downloading: 100%         

  - Installing fuel/auth (1.7.2)
    Downloading: 100% 

Writing lock file
Generating autoload files

Satisfy All External Dependencies

FuelPHP uses PHP’s dependency manager, Composer, to manage all it’s dependencies. If you’re not familiar with Composer, in years gone by, many projects implemented common functionality, such as routing, database layers, caching interaction and logging on their own.

This made it difficult to port applications to newer or different frameworks, or for them to be maintained in a cost and time-effective. Composer makes it almost painless for best of breed libraries for any specific purpose to be created, voted on, discovered and most importantly used in applications.

If you don’t have Composer installed, run the following command to do so:

curl -s https://getcomposer.org/installer | php --

This will download Composer, piping it through to PHP, creating a self-contained phar file we can use from the command line. With that done run the following command, inside the new fuel project directory, to download all the dependencies:

php composer.phar self-update && php composer.phar update;

Verify Directory Permissions

Now that that’s done, there’s one last step to go, which is to verify directory permissions. This is required as FuelPHP makes use of several directories for caching, configuration and logging amongst other things.

We can verify the directory permissions are correctly set by again using oil, as in the command below:

php oil refine install
    Made writable: APPPATH/cache
    Made writable: APPPATH/logs
    Made writable: APPPATH/tmp
    Made writable: APPPATH/config

Potential Errors

With that done, the project’s created and ready to go. However, during the course of running the above commands, you may have come across the error below:

Error - date_default_timezone_get(): It is not safe to rely on the system's
timezone settings. You are *required* to use the date.timezone setting or the
date_default_timezone_set() function. 

In case you used any of those methods and you are still getting this warning,
you most likely misspelled the timezone identifier. We selected the timezone
'UTC' for now, but please set date.timezone to select your timezone. in
COREPATH/classes/fuel.php on line 167

If you do, it’s a simple one to fix and sometimes common in PHP installations. To fix it, edit thedate.timezone setting in your PHP’s main configuration file. If you’re not sure where it’s located, run the following command:

vim $(php -i | grep 'Loaded Configuration File' | awk -F ' => ' '{print $2}')

This will print out the full path to the file. Once you’re in the file, locate the section headed[Date], then ensure that the setting for date.timezone is both uncommented and has a valid value.

If you’re not sure of the required setting for your area, consult PHP’s list of supported timezones.

View The Application

Right, now that it’s installed, let’s have a look at the running app. It’s not special, as there’s no database, logging, or caching server connections. It’s just a one page application, but it works and looks like the screenshot below:

Wrapping Up

So there you go. In just a few minutes, we’ve stepped through creating and configuring a sub-domain, to installing a basic FuelPHP application.

Now it’d be great if it was simpler, such as having an installer for Drupal, Joomla and WordPress. But it’s a bit hard to compare off the shelf applications, such as these, to frameworks which allow for creating nearly any kind of application.

What I’m hoping for is to have an installer which lays the foundation for this process, which may just be available in the future.

Till then, share your thoughts in the comments. Has this made it simpler for you to start creating FuelPHP applications on Plesk? I hope so. I’d love to hear how you feel.