Disable Console Power Save on Ubuntu

By default Ubuntu console turns off after about 15 minutes of no keyboard commands, regardless of what may be, being displayed at the time. Often it is useful to disable this ‘feature’ on production servers to better monitor the activities being sent to the console, such as errors and logs.

There are two methods of doing this, either per session, or for the whole system.

To disable it for only the current session log in as root run the following command:

setterm -powersave off -blank 0

To disable console blacking for all session on this server and to retain this change after reboot, you will need to start by installing the console-tools packet:

apt-get install console-tools

After you have the console-tools packet installed. To stop the screen blanking both the screen saver (BLANK_TIME) and the power management standby (POWERDOWN_TIME) settings need to be disabled. If these two settings are set to zero (0) in the file /etc/console-tools/config the features will be completely disabled.

Alternatively a local settings file called /etc/console-tools/config.d/disable-blank-console can be created containing the following two lines to achieve the same affect.


Actually you can name the file anything you want so long as the name consists of only upper/lower case letters, numbers, underscores, and hyphens.

pingdom site status

Today I signed up for pingdom.com. Pingdom.com will continuously ping your site to confirm your site is up and will notify you when there is an outage.  They also give nice status of current speed and other useful information.

They also provide a public status page, see mine at status.mattrude.com for this site.

Response time Report for Website - technology.mattrude.com: Last 30 days
Uptime Report for Website - technology.mattrude.com: Last 30 days

Git: Add all remote branches

Adding each remote branch to a local git repository sometimes can be a pain. IF there are many, you have to repeat your self over and over. Here is a quick, copy and past drop into you console, way to add all the remote branches to your local repository.

for b in `git remote show origin |grep tracked |awk '{print $1}'`
    LOCALBRANCH=`git branch |sed 's/* //g' |sed 's/  //g' |grep $b`
    if [ "$LOCALBRANCH" != "$b" ]; then
        git branch -t $b origin/$b

Once your done, you should still be in your original branch were you started. You will still need to update each branch by it self. You may also use something like git-up to update all the branches at once.

RoundCube: Error No [604]

I recently had a client who moved RoundCube to a new server. Since the move they are receiving the below error when they go to their webmail site.

Error No. [604]

After much digging and searching, I wasn’t coming up with much. I finely started walking threw the config file seeing what was enabled and were the different config options were pointing. After some digging I found they had memcache configured for session data. The php-pecl-memcache module wasn’t installed. I installed the module via yum, as it was a Fedora system using the below command.

yum install php-pecl-memcache

Since the config was still pointing at the running memcache server, the site came back up and is now working well again.

Custom WordPress Cron Intervals

Here’s how to have WordPress code execute on a different schedule than the default intervals of hourly, twicedaily, and daily. This specific example is for weekly execution.


// Add a new interval of a week
// See http://codex.wordpress.org/Plugin_API/Filter_Reference/cron_schedules
add_filter( 'cron_schedules', 'myprefix_add_weekly_cron_schedule' );
function myprefix_add_weekly_cron_schedule( $schedules ) {
	$schedules['weekly'] = array(
		'interval' => 604800, // 1 week in seconds
		'display'  => __( 'Once Weekly' ),

	return $schedules;

// Schedule an action if it's not already scheduled
if ( ! wp_next_scheduled( 'myprefix_my_cron_action' ) ) {
	wp_schedule_event( time(), 'weekly', 'myprefix_my_cron_action' );

// Hook into that action that'll fire weekly
add_action( 'myprefix_my_cron_action', 'myprefix_function_to_run' );
function myprefix_function_to_run() {
	// Add some code here


Taken from Viper007Bond‘s post on How To Create Custom WordPress Cron Intervals.

Building a WordPress Cloud, Cluster Setup

This how-to will explain how to build a WordPress site on 2, 3, or more Rackspace cloud servers, with full load-balancing and redundancy.

To accomplish this, you will setup multiple web-servers and one or more mySQL servers, behind two Rackspace cloud load-balancers. One load-balancer will server all you normal user internet traffic from all the web-servers.  The other load-balancer will server only your secured traffic to your admin sites (Dashboard) from a single, master, server.  You will then set WordPress to only server the admins sites threw a secure connections, this way all uploads will be saved to a single server and may be distributed from there. This also insures that you will be able to see the newly uploaded file, even before it has a chance to propagate to the other servers. The flaw with this configuration is that if the Master server goes down, no posts may be created until the issue is resolved.

The Setup

There are meny different ways we can accomplish this.  Here I am going to show a two server setup, but you can easily expand this into as many servers as you wish.

  • Server1 – Master Database Server, Master Web Server
  • Server2 – Slave Database Server, Slave Web Server or only Slave Web Server

Building Server1

Server1 is our main server, if Server2+went down, the site would still be fully up, just slower.

This How-To assumes your using Fedora hosts for these setup’s.  To start out, we need Apache, php, mySQL installed on the server.