Archive for the ‘Backups’ Category

Building Bareos RPMs on Ubuntu 16.04

Friday, March 16th, 2018

Following on from my previous post on how to build Bareos (Backup Archiving Recovery Open Sourced) RPM packages on CentOS 6 & 7 (https://www.spheron1.uk/2018/03/14/building-bareos-rpms-on-centos-6-7/), the following instructions will show you how to build .deb versions of the packages on Ubuntu 16.04.

Again, these instructions are based on Bareos version 17.2.5, so would need to be adjusted appropriately for other versions and I’m working exclusively with 64-bit (amd64) versions.

Before we start, lets make sure that everything is up to date:

apt-get update
apt-get upgrade

Before we start building anything, we’ll need to install all of the dependencies which are required in order to build the .deb packages. We’ll use the libfastlz and libfastlz-dev packages from the Bareos repositories:

apt-get install build-essential acl-dev autotools-dev bc chrpath debhelper libacl1-dev libcap-dev libjansson-dev liblzo2-dev libqt4-dev libreadline-dev libssl-dev libwrap0-dev libx11-dev libsqlite3-dev libmysqlclient-dev libpq-dev mtx ncurses-dev pkg-config po-debconf python-dev zlib1g-dev glusterfs-common librados-dev libcephfs-dev apache2-dev apache2 autoconf automake python-all python-setuptools
wget http://download.bareos.org/bareos/release/17.2/xUbuntu_16.04/amd64/libfastlz_0.1-7.2_amd64.deb
wget http://download.bareos.org/bareos/release/17.2/xUbuntu_16.04/amd64/libfastlz-dev_0.1-7.2_amd64.deb
dpkg -i libfastlz_0.1-7.2_amd64.deb libfastlz-dev_0.1-7.2_amd64.deb

Now let’s download the Bareos source code the various repositories on GitHub and extract it ready for building:

wget https://github.com/bareos/bareos/archive/Release/17.2.5.tar.gz -qO – | tar zx
wget https://github.com/bareos/bareos-webui/archive/Release/17.2.5.tar.gz -qO – | tar zx
wget https://github.com/bareos/python-bareos/archive/Release/17.2.5.tar.gz -qO – | tar zx

Before starting the build, we need to create a changelog file which contains information used by the build process. Use your favourite text editor to put the below into ~/bareos-Release-17.2.5/debian/changelog:

bareos (17.2.5-0) stable; urgency=low

* Bareos 17.2.5 release; https://www.bareos.org/en/news/bareos-17-2-5-maintenance-version-released.html

— Your Name <your@email.address> Thu, 16 Mar 2018 10:58:00 +0000

Once that’s done, you can start the build process:

cd ~/bareos-Release-17.2.5/
fakeroot debian/rules binary

Now we just need to repeat this process for the bareos-webui package. Use your favourite text editor to create the ~/bareos-webui-Release-17.2.5/debian/changelog file containing the below:

bareos-webui (17.2.5-0) stable; urgency=low

* Bareos 17.2.5 release; https://www.bareos.org/en/news/bareos-17-2-5-maintenance-version-released.html

— Your Name <your@email.address> Thu, 16 Mar 2018 10:58:00 +0000

Unlike the main bareos repository, the debian/rules file isn’t executable by default in the code from bareos-webui repository, so we need to set that before we can start the build process:

cd ~/bareos-webui-Release-17.2.5/
chmod +x debian/rules
fakeroot debian/rules binary

Finally we need to build the python-bareos package. Use your favourite text editor to create the ~/python-bareos-Release-17.2.5/debian/changelog file containing the below:

python-bareos (17.2.5-0) stable; urgency=low

* Bareos 17.2.5 release; https://www.bareos.org/en/news/bareos-17-2-5-maintenance-version-released.html

— Your Name <your@email.address> Thu, 16 Mar 2018 10:58:00 +0000

Then it’s just the usual commands to start the build process:

cd ~/python-bareos-Release-17.2.5/
fakeroot debian/rules binary

You should now have all of the .deb package files in your home directory which you can install locally or host in your own APT repository.

Building Bareos RPMs on CentOS 6 & 7

Wednesday, March 14th, 2018

Bareos (Backup Archiving Recovery Open Sourced) is a popular open source backup system originally forked from the Bacula project, but they only publicly publish packages for the first release of each major version; updates are reserved for paying customers. The source code is available on GitHub however, so you can pretty easily build your own packages, even if exactly how to do it doesn’t seem to be documented.

These instructions are based on Bareos version 17.2.5, so would need to be adjusted appropriately for other versions. I’m also working exclusively with 64-bit (x86_64) versions.

Before we start, lets make sure that everything is up to date:

yum -y update

If you don’t already have the EPEL repository installed, then install it as we’ll need it for the jansson-devel and libcmocka-devel build dependancies:

yum -y install  epel-release

Now install everything needed to build the RPMs. We’ll use the libdroplet, libdroplet-devel, libfastlz and libfastlz-devel packages from the Bareos repositories.

On CentOS 6:

yum -y install rpm-build wget autoconf automake httpd httpd-devel glusterfs-devel glusterfs-api-devel git-core gcc gcc-c++ glibc-devel ncurses-devel readline-devel libstdc++-devel zlib-devel openssl-devel libacl-devel lzo-devel sqlite-devel mysql-devel postgresql-devel libcap-devel mtx qt-devel libcmocka-devel python-devel python-setuptools libtermcap-devel tcp_wrappers redhat-lsb jansson-devel tcp_wrappers-devel http://download.bareos.org/bareos/release/17.2/CentOS_6/x86_64/libdroplet-3.0.git.1510141874.bc2a9a0-41.1.el6.x86_64.rpm http://download.bareos.org/bareos/release/17.2/CentOS_6/x86_64/libdroplet-devel-3.0.git.1510141874.bc2a9a0-41.1.el6.x86_64.rpm http://download.bareos.org/bareos/release/17.2/CentOS_6/x86_64/libfastlz-0.1-7.3.el6.x86_64.rpm http://download.bareos.org/bareos/release/17.2/CentOS_6/x86_64/libfastlz-devel-0.1-7.3.el6.x86_64.rpm

On CentOS 7:

yum -y install rpm-build wget autoconf automake httpd httpd-devel glusterfs-devel glusterfs-api-devel git-core gcc gcc-c++ glibc-devel ncurses-devel readline-devel libstdc++-devel zlib-devel openssl-devel libacl-devel lzo-devel sqlite-devel mysql-devel postgresql-devel libcap-devel mtx qt-devel libcmocka-devel python-devel python-setuptools libtermcap-devel tcp_wrappers redhat-lsb jansson-devel tcp_wrappers-devel http://download.bareos.org/bareos/release/17.2/CentOS_6/x86_64/libdroplet-3.0.git.1510141874.bc2a9a0-41.1.el6.x86_64.rpm http://download.bareos.org/bareos/release/17.2/CentOS_7/x86_64/libdroplet-devel-3.0.git.1510141874.bc2a9a0-41.1.el7.x86_64.rpm http://download.bareos.org/bareos/release/17.2/CentOS_7/x86_64/libfastlz-0.1-7.3.el7.x86_64.rpm http://download.bareos.org/bareos/release/17.2/CentOS_7/x86_64/libfastlz-devel-0.1-7.3.el7.x86_64.rpm

It’s a good idea to run the build under an unprivileged user. I’ve set up a dedicated user called “build” for this, but any normal user account will do.
Let’s set up the build environment and download the Bareos source code from the various repositories on GitHub:

useradd build
su – build
mkdir -p ~/rpmbuild/{BUILD,RPMS,SOURCES,SPECS,SRPMS}
echo ‘%_topdir %(echo $HOME)/rpmbuild’ > ~/.rpmmacros
wget https://github.com/bareos/bareos/archive/Release/17.2.5.tar.gz -O bareos-17.2.5.tar.gz
tar xf bareos-17.2.5.tar.gz
mv bareos-Release-17.2.5/ bareos-17.2.5
tar zcf bareos-17.2.5.tar.gz bareos-17.2.5
mv bareos-17.2.5/platforms/packaging/bareos.spec ~/rpmbuild/SPECS/
rm -rf bareos-17.2.5
mv bareos-17.2.5.tar.gz ~/rpmbuild/SOURCES/
wget https://github.com/bareos/bareos-webui/archive/Release/17.2.5.tar.gz -O bareos-webui-17.2.5.tar.gz
mv 17.2.5.tar.gz bareos-webui-17.2.5.tar.gz
tar xf bareos-webui-17.2.5.tar.gz
mv bareos-webui-Release-17.2.5/ bareos-webui-17.2.5
tar zcf bareos-webui-17.2.5.tar.gz bareos-webui-17.2.5
mv bareos-webui-17.2.5/packaging/obs/bareos-webui.spec ~/rpmbuild/SPECS/
rm -rf bareos-webui-17.2.5
mv bareos-webui-17.2.5.tar.gz ~/rpmbuild/SOURCES/
wget https://github.com/bareos/python-bareos/archive/Release/17.2.5.tar.gz -O python-bareos-17.2.5.tar.gz
tar xf python-bareos-17.2.5.tar.gz
mv python-bareos-Release-17.2.5/ python-bareos-17.2.5
tar zcf python-bareos-17.2.5.tar.gz python-bareos-17.2.5
mv python-bareos-17.2.5/packaging/python-bareos.spec ~/rpmbuild/SPECS/
rm -rf python-bareos-17.2.5
mv python-bareos-17.2.5.tar.gz ~/rpmbuild/SOURCES/

Edit the ~/rpmbuild/SPECS/bareos.spec file in your favourite text editor and set “Version” (line 8) to “17.2.5” as well as “Release” (line 9) to “0%{?dist}”.
You also need to search for “BuildRequires: libqt4-devel” (line 186) and replace it with “BuildRequires: qt-devel”.

By default, GlusterFS and Droplet support isn’t built on CentOS 6 for some reason, so if you want them then you need to edit “%define glusterfs 0” and “%define objectstorage 0” (lines 45 and 46) and set them to 1.

Now you’d ready to run the build itself. On CentOS 6:

rpmbuild -ba ~/rpmbuild/SPECS/bareos.spec –define “centos_version 600”

And on CentOS 7:

rpmbuild -ba ~/rpmbuild/SPECS/bareos.spec –define “centos_version 700”

Once this finishes, you should find a collection of several Bareos RPMs in ~/rpmbuild/RPMS/x86_64/. We need the bareos-common package installed for build the Web UI, so become root and install it.

On CentOS 6:

yum -y install /home/build/rpmbuild/RPMS/x86_64/bareos-common-17.2.5-0.el6.x86_64.rpm

On CentOS 7:

yum -y install /home/build/rpmbuild/RPMS/x86_64/bareos-common-17.2.5-0.el7.centos.x86_64.rpm

Next, edit the ~/rpmbuild/SPECS/bareos-webui.spec file in your favourite text editor and set “Version” (line 4) to “17.2.5”.

Now you’d ready to build the Web UI package:

rpmbuild -ba ~/rpmbuild/SPECS/bareos-webui.spec

Finally, edit ~/rpmbuild/SPECS/python-bareos.spec in your favourite text editor and set “Version” (line 21) to “17.2.5” as well as “Release” (line 22) to “0%{?dist}” and build the final package:

rpmbuild -ba ~/rpmbuild/SPECS/python-bareos.spec

You should now have the full compliment of RPMs in ~/rpmbuild/RPMS/x86_64/ and ~/rpmbuild/RPMS/noarch/.

If you need to rebuild the RPMs for the same version of Bareos for any reason, then you should increment the value of Release in the relevant .spec file by 1 each time (e.g. “1%{?dist}”, “2%{?dist}” etc.).

You can now GPG sign your RPMs if you want and then add them to your own central yum repository with createrepo or just directly install them locally with rpm.

Remove CDP 2.0 cPanel integration

Sunday, June 19th, 2011

A handy feature of R1Soft CDP Server 2.0 (now known as Enterprise Edition) is that it can integrate with cPanel so that your users can restore their own files from your backups using a self service interface. If you want to remove this integration for any reason, then R1Soft provide a BASH shell script to do this for you:

/usr/lib/buagent/control-panels/cpanel/remove-cpanel-integration.sh

This script doesn’t always work for one reason or another, so the other way of doing this is to manually call the cPanel plugin uninstaller:

/usr/local/cpanel/bin/unregister_cpanelplugin /var/cpanel/registered_cpanelplugins/righteousbackup

This is particularly helpful if you forgot to uninstall the cPanel integration before upgrading to R1Soft CDP 3.0 or thought that the r1soft-uninstall-buagent utility would do it for you when removing the R1Soft CDP 2.0 agent (unfortunately it doesn’t, but it does helpfully remove the remove-cpanel-integration.sh script).

Unfortunately the cPanel integration in R1Soft CDP 3.0 is severely lacking compared to R1Soft CDP 2.0 and in my opinion is virtually useless in it’s current form.

As the control panel integration system is a pretty new feature in R1Soft CDP 3.0 (it was missing entirely from the initial release), hopefully it will be bolstered in subsequent R1Soft CDP 3.0 releases to restore it to the same level of functionality as was formerly available in R1Soft CDP 2.0.

R1Soft CDP 3.0 and commercial SSL certificates

Sunday, June 12th, 2011

Chances are that you will want to protect the web interface for your R1Soft CDP 3.0 server with a commercial SSL certificate issued by a known, trusted certificate authority. After all, you are sending some pretty sensitive data between your browser the and the R1Soft CDP 3.0 web interface and you want to know not only that it is encrypted but that you are able to ensure the identity of the R1Soft CDP 3.0 server so that you aren’t susceptible to man-in-the-middle attacks.

This post assumes that you have generated a CSR and sent it to your chosen certificate authority to be signed. We use /root/example.key as the private key and /root/example.crt as the PEM certificate that you received back from the certificate authority. The certificate authority’s intermediate certificate is in /root/example_intermediate.crt. Obviously substitute these file names for whatever you have actually used.

In order to use the ImportKey utility to import your private key and certificate into the Java keystore file you will need to convert both the private key and certificate from the PEM format into DER using the openssl tool.

openssl pkcs8 -topk8 -nocrypt -in /root/example.key -inform PEM -out /root/example.key.der -outform DER
openssl x509 -in /root/example.crt -inform PEM -out /root/example.crt.der -outform DER

For some reason the java and keytool binaries provided by R1Soft aren’t executable by default, so lets fix this and download the ImportKey utility

cd /usr/sbin/r1soft/jre/bin
chmod +x java
chmod +x keytool
wget http://community.igniterealtime.org/servlet/JiveServlet/download/196707-4718/importkey.zip
unzip ImportKey.zip

Now lets use ImportKey to create a Java keystore with your private key and newly issued certificate.

./java ImportKey /root/example.key.der /root/example.crt.der

The ImportKey utility sets a password on both the keystore itself and the private key inside the keystore. For the R1Soft CDP 3.0 web server to be able to decrypt the keystore and private key it needs to know what the password is. Unfortunately there is no way to specify the password to use, the R1Soft CDP 3.0 embedded tomcat web server just assumes that both passwords are set to “password”, so we had better change the password from the default which is “importkey”.

./keytool -storepasswd -keystore /root/keystore.ImportKey
./keytool -keypasswd -alias importkey -keystore /root/keystore.ImportKey

Most SSL certificates aren’t signed directly from the root certificate authority these days, but instead are signed via an intermediate certificate. In order for the certificate to be useable, the entire certificate chain needs to be available in the keystore for the R1Soft CDP 3.0 web server, so we will import the intermediate certificate. Remember to use your newly set keystore password.

./keytool -import -alias intermed -file /root/example_intermediate.crt -keystore /root/keystore.ImportKey -trustcacerts

Now to start using your new keystore, just move the old one out of the way (better keep it around for now, just in case!) and replace it with your newly generated keystore then restart the service for the R1Soft CDP 3.0 server.

mv /usr/sbin/r1soft/conf/keystore /usr/sbin/r1soft/conf/keystore.old
mv /root/keystore.ImportKey /usr/sbin/r1soft/conf/keystore
/etc/init.d/cdp-server restart

R1Soft CDP 3.0 with Atomic Secured Linux and PAX

Sunday, June 12th, 2011

If you want to run R1Soft CDP 3.0 on a system protected by Atomic Secured Linux and the ASL enhanced kernel with PaX/grsecurity then you need to disable memory protection for the CDP 3.0 binary. You do this by using paxctl to set the NOMPROTECT flag for the CDP 3.0 binary.

/sbin/paxctl -m /usr/sbin/r1soft/bin/2-6/cdp-2-6

Unfortunately the CDP 3.0 binary lacks the PT_PAX_FLAGS header, so you will receive an error message along the lines of:

file /usr/sbin/r1soft/bin/2-6/cdp-2-6 does not have a PT_PAX_FLAGS program header, try conversion

The solution to this is to first use paxctl to run a conversion on the CDP 3.0 binary which should change the PT_GNU_STACK header to PT_PAX_FLAGS

/sbin/paxctl -c /usr/sbin/r1soft/bin/2-6/cdp-2-6

If this has worked then you should see a message along the lines of

file /usr/sbin/r1soft/bin/2-6/cdp-2-6 had a PT_GNU_STACK program header, converted

Now you should be able to use paxctl to set the NOMPROTECT flag on the CDP 3.0 binary without any errors. Now restart the R1Soft CDP 3.0 agent service and have fun backing up all your previous data 🙂

R1Soft CDP 3.0 – java.net.InetAddress.getLocalHost UnknownHostException

Sunday, May 29th, 2011

When you launch the CDP 3.0 web interface for the first time, you are prompted to activate your license, or at least you should be. If instead you get a Java error then take a look in /usr/sbin/r1soft/log/monitor.log and you will probably see something like this:

INFO | buserver | 2011/05/29 16:21:59 | May 29, 2011 4:21:59 PM org.zkoss.zk.ui.impl.UiEngineImpl handleError:1253
INFO | buserver | 2011/05/29 16:21:59 | SEVERE: >>java.lang.RuntimeException: java.net.UnknownHostException: cdp.example.com: cdp.example.com
INFO | buserver | 2011/05/29 16:21:59 | >>java.net.UnknownHostException: cdp.example.com: cdp.example.com
INFO | buserver | 2011/05/29 16:21:59 | >> at java.net.InetAddress.getLocalHost(Unknown Source)
INFO | buserver | 2011/05/29 16:21:59 | >> at com.r1soft.backup.server.facade.ServerFacade.getLocalHostIP(ServerFacade.java:537)
INFO | buserver | 2011/05/29 16:21:59 | >> at com.r1soft.backup.server.web.configuration.ActivationWizardWindow.afterCompose(ActivationWizardWindow.java:212)
INFO | buserver | 2011/05/29 16:21:59 | >> at org.zkoss.zk.ui.impl.UiEngineImpl.execCreateChild0(UiEngineImpl.java:736)
INFO | buserver | 2011/05/29 16:21:59 | >> at org.zkoss.zk.ui.impl.UiEngineImpl.execCreateChild(UiEngineImpl.java:685)
INFO | buserver | 2011/05/29 16:21:59 | >> at org.zkoss.zk.ui.impl.UiEngineImpl.execCreate0(UiEngineImpl.java:629)
INFO | buserver | 2011/05/29 16:21:59 | >> at org.zkoss.zk.ui.impl.UiEngineImpl.execCreateChild(UiEngineImpl.java:661)
INFO | buserver | 2011/05/29 16:21:59 | >>…

R1Soft CDP is trying to determine your server’s IP address from it’s hostname, so you need to make sure that your hostname exists in DNS or is at least present in the /etc/hosts file. As soon as Java is able to determine the server’s IP address from it’s hostname then this error message will be replaced with the license activation window that you were expecting to see.

R1Soft CDP scheduler issues

Thursday, April 28th, 2011

After spending quite some time with R1Soft support investigating some bizarre issues where the CDP 2.0 scheduler was skipping over some tasks seemingly at random, we eventually discovered that the issue was caused by setting the e-mail reporting task to run every minute. Decreasing the frequency of this task allowed all scheduled CDP tasks to run as normal.

R1Soft are now investigating what causes these issues with the CDP 2.0 scheduler when tasks are set to run every minute. The option of running every minute is available through the CDP interface and R1Soft were unable to explain why setting the e-mail notifications to run every minute would intermittently break the scheduling of both the e-mail notifications and other scheduled tasks such as the all important backup processes!

DomU kernel panic under Xen with R1Soft CDP agent

Sunday, March 28th, 2010

I ran into a weird problem on a freshly installed server today where one of the DomU virtual machines kept locking up with a kernel panic message:

BUG: soft lockup – CPU#1 stuck for 10s!

All of the other Xen DomU virtual machines running on the box were fine, so I was pretty sure it wasn’t a hardware bug. The only possible solutions that I could come up with were

  1. My somewhat aggressive stripping down of the Dom0 host
  2. Zimbra (as the Java process was always the one referenced as being stuck
  3. The kernel module for the R1Soft CDP backup agent that I had installed a few hours ago.

I’ve run Zimbra on a CentOS 5 Xen VM before (although not 5.4 admittedly), so didn’t think that would be the problem (anyway, user land software should never be able to cause a kernel panic – in theory at least ;-))
Again, the other Xen DomU virtual machines were fine, so hopefully the configuration on the Xen Dom0 host machine itself shouldn’t be causing the problem.

Just to be safe, I updated the kernel-xen package from the default 2.6.18-164.el5 to the latest 2.6.18-164.15.1 which was only released a few days ago and doesn’t appear to be on all of the mirrors yet!
With this done and the virtual machine restarted I had to run r1soft-cki to load an updated kernel module for the R1Soft CDP backup agent and the virtual machine has been stable for several hours now. Fingers crossed it stays that way!