Archive for the ‘Linux’ 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.

SuperMicro ipmicfg utility on Linux

Sunday, December 15th, 2013

SuperMicro have a nice little utility called ipmicfg, which can be used to interact with the IPMI BMC from within your operating system. This can do all sorts of things with the IPMI BMC, however it’s really useful if you want to change the IP address details on the IPMI card without rebooting your system and going into the BIOS setup.

To get started, download the latest version of ipmicfg from the SuperMicro FTP site (currently it’s ftp://ftp.supermicro.com/utility/IPMICFG/ipmicfg_1.14.3_20130725.zip).

Unzip this and you will find DOS, Linux and Windows versions of the ipmicfg tool, as well as a bit of documentation. I’m only really interested in the Linux version, so lets go into that folder, where you will find 32-bit and 64-bit versions.

There are two binary files included – “ipmicfg-linux.x86_64” which is dynamically linked and “ipmicfg-linux.x86_64.static” which is statically linked. The dynamically linked version normally works fine for me.

As a quick example of how to use ipmicfg, lets change the IPMI BMC IP address from being assigned via DHCP to being statically configured to 192.168.1.2 with a subnet mask of 255.255.255.0 and the default gateway set to 192.168.1.1:

./ipmicfg-linux.x86_64 -dhcp off
./ipmicfg-linux.x86_64 -m 192.168.1.2
./ipmicfg-linux.x86_64 -k 255.255.255.0
./ipmicfg-linux.x86_64 -g 192.168.1.1

When you run ipmicfg, you may see errors along the lines of:

[kcs] kcs_error_exit:

[kcs] kcs_error_exit:

[kcs] kcs_error:

[kcs] kcs_error_exit:

This essentially means that ipmicfg is having problems communicating with the IPMI BMC, and can normally be resolved by installing the IPMI drivers and loading into the kernel. On CentOS you can do this with the following commands:

yum -y install OpenIPMI
service ipmi start
chkconfig ipmi on

Building httpd 2.4.6

Sunday, July 28th, 2013

When trying to build an RPM from the Apache source tarball, rpmbuild bails with:

RPM build errors:
Installed (but unpackaged) file(s) found:
/usr/lib64/httpd/modules/mod_proxy_wstunnel.so

The problem is that the mod_proxy_wstunnel.so file has been omitted from the httpd.spec file used to build the RPM.

Extract the tarball, open up httpd.spec in your favourite text editor and scroll down until you find a section that looks like:

%dir %{_libdir}/httpd
%dir %{_libdir}/httpd/modules
%{_libdir}/httpd/modules/mod_access_compat.so
%{_libdir}/httpd/modules/mod_actions.so

%{_libdir}/httpd/modules/mod_vhost_alias.so
%{_libdir}/httpd/modules/mod_watchdog.so

%dir %{contentdir}

This should start at line 308. Add in the following line:

%{_libdir}/httpd/modules/mod_proxy_wstunnel.so

You can now run rpmbuild again. You will either need to rebuild the tarball or change to using “rpmbuild -bb httpd.spec” instead of “rpmbuild -tb httpd-2.4.6.tar.bz2”.

Regenerate statistics in Parallels Plesk for Linux

Monday, February 6th, 2012

Every night Parallels Plesk for Linux servers run a cron job to process various log files and generate statistics. This includes generating the HTML for the AWStats or Webalizer log analysis packages used for the Plesk “web statistics” features as well as updating the disk usage and bandwidth usage for each domain.

Sometimes you need to re-run this task, such as if it failed or if you need to process a particular domain name again. One common reason for this is to correct the disk and/or bandwidth usage figures for a domain.

You can either regenerate the statistics for all domain names (the equivalent of the daily cron job) using:

/usr/local/psa/admin/sbin/statistics –calculate-all

Or you can re-generate the statistics for a single domain name (“example.com” in this case) using:

/usr/local/psa/admin/sbin/statistics –calculate-one –domain-name=example.com

There is a similar tool in Parallels Plesk for Windows under C:\Program Files (x86)\Parallels\Plesk\admin\bin\statistics.exe, however this requires different arguments.

EPEL NSD RPM and the missing PID file directory

Sunday, June 26th, 2011

NSD is a fantastic authoritative nameserver from NLnet Labs which was developed in conjunction with the RIPE NCC to be a highly scalable, secure authoritative nameserver which has no recursive features by design. In fact, it is such as good nameserver that it is used on three of the root namesevers (k.root-servers.net, h.root-servers.net and l.root-servers.net).

Thanks to the EPEL project run by the Fedora guys, you can quickly and easily install an up to date copy of NSD on CentOS/RHEL systems. The only problem that I have found so far is that the RPM doesn’t seem to create directory for the PID file specified in the /etc/nsd/nsd.conf and so the daemon won’t start out of the box.

Obviously it is easy enough to create the /var/run/nsd directory with mkdir, but remember to chown/chgrp this directory to the nsd user and group, otherwise and “nsdc restart” will fail with errors in /var/log/messages along the lines of “failed to unlink pidfile /var/run/nsd/nsd.pid: Permission denied

Recovering Logical Volumes deleted with lvremove

Sunday, March 20th, 2011

Need to recover an LVM Logical Volume that you deleted by mistake? No problem, luckily LVM archives all of the old Logical Volume and Volume Group metadata in /etc/lvm/archive/ whenever you use something like lvremove to make adjustments to the Logical Volumes.

Before you start, remember that any kind of operation like this is potentially dangerous and so backup anything of importance on the intact Logical Volumes. Also, as a safety net, backup the contents of /etc/lvm just in case and then run “vgcfgbackup” to put an up to date copy of the metadata in /etc/lvm/backup.

Now look for the appropriate file in /etc/lvm/archive. Each LVM operation will create a file in here with the name of the affected Volume Group and an incrementing number. By default on RHEL/CentOS this will be “VolGroup00”, so you will be looking for /etc/lvm/archive/VolGroup00_xxx.vg where xxx is the appropriate increment.

If you open up your chosen file in your favourite text editor you should see a line that starts “description” and has something like “Created *before* executing ‘lvremove -f /dev/VolGroup00/xxx'” on it. You can use this to verify that you have the right file.

The next thing that you need to do is verify that this file has valid metadata and thus will be useable. To do this, you can use the vgcfgrestore command in a test mode that will perform a dry run. Assuming you are trying to restore Volume Group VolGroup00 from VolGroup00_00161.vg, this would look like:

vgcfgrestore VolGroup00 –test -f /etc/lvm/archive/VolGroup00_00161.vg

Which will return something along the lines of:

Test mode: Metadata will NOT be updated.
Restored volume group VolGroup00

Assuming this all went well, you can now re-run the same command but without the “–test” option:

# vgcfgrestore VolGroup00 –test -f /etc/lvm/archive/VolGroup00_00161.vg
Restored volume group VolGroup00

Now run an “lvscan” and you should see your missing Logical Volume(s) have returned, but are inactive. Re-activate them with “lvchange” and you are back in business, just be more careful next time 😉

lvchange -a y /dev/VolGroup00/xxx

Using kill to display dd progress

Tuesday, November 9th, 2010

How long has that dd process been running for now? Is it even doing anything? How long is it going to take?

If you want dd to give you a progress update, then find out the process ID (PID) and then send the USR1 signal to it with

kill -USR1

And dd will then print out the same records in/out, bytes copied, time taken and overall speed to STDERR as it would when it finishes.

It doesn’t matter if you are re-directing STDOUT (such as to pipe the data stream to another machine via netcat or even compressing it with gzip) but make sure that you aren’t sending STDERR anywhere such as /dev/null

Make sure you specify the “-USR1” argument to kill as you don’t want to send SIGTERM to dd by mistake!
By default, kill will send SIGTERM (or SIGKILL if you use kill -9) to the specified process, but using “-USR1” you are telling kill to send a different signal, in this case one that causes dd to print the progress summary and so you aren’t actually going to “kill” the process.

You can even use have the progress refresh every few seconds with a command such as

watch -n 10 kill -USR1 $PID

Just replace $PID with the PID of the running dd process (or set the PID environment variable to the process ID).
If dd was the last command you ran, then you can get the PID with the special $! variable, otherwise you’ll have to use ps to find the PID.

The dreaded scrolling GRUB GRUB GRUB on startup

Thursday, September 16th, 2010

Rebooting a server is always stressful, particularly when you don’t have immediate physical access to it. Of course, when the server inevitably doesn’t come back up you need to either get directly on the local console or connect in via KVMoIP and one of the worst things you can see is “GRUB GRUB GRUB” scrolling past endlessly.

This is a sign that stage 1 of the GRUB bootloader which is stored in the Master Boot Record (MBR) has somehow become corrupted and do GRUB can’t start. There is no way to even get into the GRUB command line and boot the system manually or even troubleshoot further as the problem is with stage 1 and not stage 2.

As I ran into this on a CentOS machine, I used a netinstall CD with the virtual media feature on an IP KVM attached to the server to boot into rescue mode and chroot into the operating system installed on the drive in question. I could then identify the /boot hard drive number and partition from /boot/grub/menu.lst ready to re-install GRUB and point it at the stage 2 files.

Simply run /sbin/grub to get to a version of the GRUB command prompt and then (assuming /boot/grub/menu.lst references root {hd0,0) for each of the menu options) just run:

root (hd0,0)
setup (hd0)

You should see a series of messages about looking for stage 1.5 and 2 files and then that it has successfully embedded. Congratulations, GRUB has now been re-installed and simply rebooting your machine should take you straight into your operating system as normal.

Python setuptools and get_python_version is not defined

Sunday, September 12th, 2010

If you run into the below error when using setuptools (setup.py), then it’s quite possible that you’re using an outdated version of Python’s setuptools. In particular, the python-setuptools package in the CentOS yum repository is too old.

Traceback (most recent call last):
File “setup.py”, line 19, in ?
setup(**metadata)
File “/usr/lib64/python2.4/distutils/core.py”, line 149, in setup
dist.run_commands()
File “/usr/lib64/python2.4/distutils/dist.py”, line 946, in run_commands
self.run_command(cmd)
File “/usr/lib64/python2.4/distutils/dist.py”, line 966, in run_command
cmd_obj.run()
File “/usr/lib/python2.4/site-packages/setuptools/command/bdist_rpm.py”, line 28, in run
_bdist_rpm.run(self)
File “/usr/lib64/python2.4/distutils/command/bdist_rpm.py”, line 377, in run
self.move_file(rpm, self.dist_dir)
File “/usr/lib/python2.4/site-packages/setuptools/command/bdist_rpm.py”, line 20, in move_file
getattr(self.distribution,’dist_files’,[]).append(
NameError: global name ‘get_python_version’ is not defined

Luckily, this is quite easy to fix; simply remove the RPM and download the latest version from http://pypi.python.org/pypi/setuptools then just run it with “sh” as if it was a normal shell script.