How to Install Backintime Backup Software on CentOS/RHEL/Scientific Linux 7


Hopefully the title of this post is explanation enough.

Backintime is a neat backup solution that mimics in some ways, the abilities of OSX’ Timemachine backup system.  At predetermined time intervals, Backintime will sweep configured directories on your computer, and only backup the differences since the last sweep.  It results in an efficient use of storage resources on your backup destination drive by hard linking identical files.  Unlike the OSX Timemachine solution, it does not hard link directories, as only Apple’s HFS+ filesystem supports hard-linked directories.  This makes Backintime portable to Unix-based Operating Systems using a variety of filesystems.

The reason for this post is to document some trickery necessary to make Backintime work on our favourite North American Linux vendor’s enterprise operating system, the derivative on which that I use being CentOS 7.  CentOS 7 like its other cousins in the Red Hat family only includes Python interpreter version 2.  While Backintime is written in Python 3.  I have had only a little experience with Python, and it does have some great features (built in multi-threading), however making the two versions incompatible is such a nuisance.  Whinge over, the trick to allowing Backintime to work on CentOS 7 is to install a 3rd party Python 3 interpreter.  The following instructions achieve this end.


Download Backintime from their website, and follow the installation instructions from the README file.

Next, you will need to install a 3rd-party YUM Repository called

yum localinstall
yum install python33

Then create a script file to execute the python3 interpreter with the command python3 by creating the following shell script as the file /usr/local/bin/python3

scl enable python33 -- python $@

Then compile and install Backintime from the downloaded

./configure --python3 && make && make install

Installing DBD::Oracle on RHEL6 with Oracle Instant Client 11.2 rpm

To install the Perl DBD::Oracle module on RHEL6, with the oracle instant client rpms installed, you need to type the following sequence of commands. Keep in mind that 11.2 can be exchanged for your version of Oracle, and that client64 can be exchanged for just client if you are using 32bit linux. From a shell prompt as root (or using sudo):

install DBD::Oracle

This will likely fail but leave you with a cpan prompt.  When it does, type:

look DBD::Oracle

export ORACLE_HOME=/usr/lib/oracle/11.2/client64/lib

The above will drop you at a shell prompt at the directory where the DBD::Oracle source code has been extracted, and configures the environment for the compile/install. Now you can do the compile and install process with:

perl Makefile.PL -V 11.2

If all is good, then you can go ahead and do the install:

sudo make install

The LD_LIBRARY_PATH environment variable must be set as given above for any user who will be using DBD::Oracle, so be sure to set the path permanently through a simple script added to the /etc/profile.d directory.

The Mac OS X Terminal – My keyboard mappings

I made the switch from Windows to Mac OS as my chosen desktop operating system nearly 4 years ago, and I’ve never looked back.  I continue to use Linux as my preferred server operating system. Of a handful of frustrations from my switch to Mac OS, one I have solved today.  The Mac OS Terminal application has always seemed quite limp as compared to the various terminals offered by Linux distributions such as those from KDE and Gnome.  Even terminals from Windows such as PuTTY seemed more capable.

However after spending a little time to get to know my Mac OS Terminal, I have come to realise that it isn’t quite as limp as I thought.  Either through the Leopard or Snow Leopard updates, Tabs were introduced (I don’t recall seeing them in Tiger which was when I last paid any attention to Terminal).  Neat!

So I starting looking at the biggest annoyance with Terminal, the inability to navigate the Bash shell command line with the keyboard.  With other terminals I have used on both Windows and Linux, it was possible to press Home to go to the start of the shell command, End to go to the end, and use Ctrl-Left and Ctrl-Right to move the cursor word by word through a command line.  This might seem trivial but I’m quite proficient with the UNIX shell (from my days as a UNIX Sys-admin) and tend to write reasonably complex shell commands.  There is nothing more frustrating than realising you omitted a switch to one of the first commands in a pipeline.  There was no choice but to hold down the left arrow cursor key and wait for the cursor to gingerly wander back to the start of the command where it can be positioned to insert or correct a switch. This has always given me the shits!!

So after some investigation and reading a couple of blog posts on this issue, I found an article: The complete keyboard mapping for Leopard’s by Henrique Bastos which provides instructions on how to configure these keys.

Remote Debugging via proxy with PHP, XDebug, and Komodo IDE

So I am experimenting with remote debugging using Komodo IDE, PHP and Linux.  Following instructions from the xdebug website, I typed:

sudo pecl install xdebug

Then I added the file /etc/php.d/xdebug.ini with the lines:

Running php -i, yields amongst others, the following message:

xdebug support => enabled
Version => 2.1.1


Supported protocols => Revision
DBGp - Common DeBuGger Protocol => $Revision: 1.145 $

All good so far. Now I need to set up the debugging proxy server on the webserver host so that multiple developers can debug scripts from the same dev webserver.

To do this, I followed the instructions provided by Komodo using their python-based proxy server:

export PYTHONPATH=/lib/support/dbgp/pythonlib;$PYTHONPATH
cd /lib/support/dbgp/bin
python pydbgpproxy -i -d localhost:9000 -l DEBUG

So now I have configured Komodo to use the proxy server for debugging.

Komodo debugger options

Now to initiate a debugging session with a website script, I followed the instructions provided by Komodo:

Click Debug | Listen for Debugger Connections

Then in the browser, enter the URL of the script and append: ?XDEBUG_SESSION_START=damo

Now Komodo asks to start a debug session where I click Yes, and …. The script completes and no debugging occurs. 😦

Seems more investigation is required here.

I am wondering whether the ajax calls in the script I am attempting to debug are confusing the proxy and or Komodo? Each ajax call will also have the cookie set for debugging and so there are multiple requests do debug with the same Komod instance. Perhaps this is why the debugger is not working.

I am hopeful I can get this working. Will save alot of time trying to find those nasty bugs.


Installing netatalk 2.1.1 on CentOS 5.4

I had the need to install netatalk on CentOS 5.4.  Sadly there were no easily found precompiled packages of netatalk, so I googled to find some guidance on the best way to do this.

I found a great article on which gave plenty of hints as to what was required, and to compile from source wasn’t going to be too arduous.

So here is what I did…

Downloaded and installed Oracle (is there anything they don’t yet own?) Berkeley DB

You can find Oracle Berkeley DB through a simple google search.  I used version 4.8.30.NC.  I found that 5.x didn’t work.

After downloading and extracting Berkeley DB, I compiled with command:

cd db-4.8.30.NC/build_unix

../dist/configure –prefix=/usr/local/db-4.8.30 && make -j 2 && make install

Then downloaded netatalk 2.1.1 and compiled and installed with command:

cd netatalk-2.1.1

./configure –enable-redhat –with-bdb=/usr/local/db-4.8.30 –prefix=/usr/local/netatalk-2.1.1 –with-mutex=x86/gcc-assembly && make -j 2 && make install

Then configured the software from /usr/local/netatalk-2.1.1/etc/netatalk and started the server

chkconfig atalk on

service atalk start

Hope someone finds this useful.