Archive for the ‘Operating Systems’ Category

Changing the locale in Ubuntu Server

Wednesday, April 3rd, 2019

When logging into any cPanel server via SSH from an Ubuntu jump server I was seeing some strange warnings from Perl which I didn’t see when logging in from my laptop running macOS:

perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
LANGUAGE = (unset),
LC_ALL = (unset),
LANG = “C.UTF-8”
are supported and installed on your system.
perl: warning: Falling back to the standard locale (“C”).
perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
LANGUAGE = (unset),
LC_ALL = (unset),
LANG = “C.UTF-8”
are supported and installed on your system.
perl: warning: Falling back to the standard locale (“C”).
perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
LANGUAGE = (unset),
LC_ALL = (unset),
LANG = “C.UTF-8”
are supported and installed on your system.
perl: warning: Falling back to the standard locale (“C”).

After a quick rummage, I found that the reason was that the “LANG” environment variable on my laptop was defaulting to “en_GB.UTF-8”, whilst on the Ubuntu jump server it was “C.UTF-8”.

The cPanel server runs some Perl stuff when bash starts and if it doesn’t like your locale settings, then it spits out these warnings.

The “LANG” environment variable is part of the locale system and so the best way to fix this is to update the locale settings configured on the Ubuntu jump server.

By default, SSH on both macOS and Ubuntu is configured to send the local “LANG” and “LC_*” environment variables used for locale settings to the remote system.

You can use the “locale” command to see your current locale settings as well as “locale -a” to see installed locales.

$ locale

$ locale -a

In my case I wanted to use en_GB.utf8, which wasn’t installed. You can use the “locale-gen” command to generate locales, but they are also provided in official Ubuntu packages , so I installed the “language-pack-en” package from the Ubuntu repositories using APT.
This added several English locales and then I could reconfigure Ubuntu to use the one that I needed.

$ apt-get install language-pack-en
Reading package lists… Done
Building dependency tree
Reading state information… Done
The following additional packages will be installed:
The following NEW packages will be installed:
language-pack-en language-pack-en-base
0 upgraded, 2 newly installed, 0 to remove and 3 not upgraded.
Need to get 420 kB of archives.
After this operation, 3756 kB of additional disk space will be used.
Do you want to continue? [Y/n] y
Get:1 bionic-updates/main amd64 language-pack-en-base all 1:18.04+20180712 [419 kB]
Get:2 bionic-updates/main amd64 language-pack-en all 1:18.04+20180712 [1904 B]
Fetched 420 kB in 0s (3606 kB/s)
Selecting previously unselected package language-pack-en-base.
(Reading database … 50814 files and directories currently installed.)
Preparing to unpack …/language-pack-en-base_1%3a18.04+20180712_all.deb …
Unpacking language-pack-en-base (1:18.04+20180712) …
Selecting previously unselected package language-pack-en.
Preparing to unpack …/language-pack-en_1%3a18.04+20180712_all.deb …
Unpacking language-pack-en (1:18.04+20180712) …
Setting up language-pack-en (1:18.04+20180712) …
Setting up language-pack-en-base (1:18.04+20180712) …
Generating locales (this might take a while)…
en_AG.UTF-8… done
en_AU.UTF-8… done
en_BW.UTF-8… done
en_CA.UTF-8… done
en_DK.UTF-8… done
en_GB.UTF-8… done
en_HK.UTF-8… done
en_IE.UTF-8… done
en_IL.UTF-8… done
en_IN.UTF-8… done
en_NG.UTF-8… done
en_NZ.UTF-8… done
en_PH.UTF-8… done
en_SG.UTF-8… done
en_ZA.UTF-8… done
en_ZM.UTF-8… done
en_ZW.UTF-8… done
Generation complete.

$ locale -a
$ update-locale LANG=en_GB.utf8

The locale settings are stored in “/etc/default/locale“, so you can either edit this file manually or use the handy “update-locale” utility to do it for you.
Either way, once you start a new session, you are using the new locale settings and Perl no longer complains when you SSH to a cPanel server.


Monday, August 6th, 2018

I recently found myself trying to upgrade an old SQL Server 2008 R2 instance to SP3 so that it could in turn be upgraded to SQL Server 2014, but quickly ran into problems with the following error message:

The INSTALLSHAREDWOWDIR command line value is not valid. Please ensure the specified path is valid and different than the INSTALLSHAREDDIR path.

At first I thought this would be pretty simple – fire up setup.exe from the command line and manually specify the INSTALLSHAREDWOWDIR and/or INSTALLSHAREDDIR options, but that would have been far too easy and unfortunately it seems that for whatever reason you can’t specify these options when the action is “patch” (update/upgrade) or “repair” – they only work for “install”, which wasn’t going to help me.

Much Googling later I had found plenty of people with similar issues, but most were struggling with initial installation (it seems that the SQL Server 2008 R2 installer was very buggy at first) rather than upgrading/updating or repairing an existing installation and so none of the fixes provided worked for me.

Eventually, after poking around the registry, I discovered that the installer is looking in the HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Installer\UserData\S-1-518\Components\0D1F366D0FE0E404F8C15EE4F1C15094 key for the INSTALLSHAREDDIR path as well as the HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Installer\UserData\S-1-5-18\ Components\C90BFAC020D87EA46811C836AD3C507F key for the INSTALLSHAREDWOWDIR path.

All of the values in the HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Installer\UserData\S-1-5-18\ Components\C90BFAC020D87EA46811C836AD3C507F key (INSTALLSHAREDWOWDIR) were fine (“C:\Program Files (x86)\Microsoft SQL Server\”), but one of the values (91D3749D1F6219B4BBCA0498BC14CB84) in the HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Installer\UserData\S-1-518\Components\0D1F366D0FE0E404F8C15EE4F1C15094 key (INSTALLSHAREDDIR) was set to “C:\Program Files (x86)\Microsoft SQL Server\” instead of “C:\Program Files\Microsoft SQL Server\” and so the INSTALLSHAREDDIR path was conflicting with the INSTALLSHAREDWOWDIR path.

Updating the 91D3749D1F6219B4BBCA0498BC14CB84 value from “C:\Program Files (x86)\Microsoft SQL Server\” to “C:\Program Files\Microsoft SQL Server\” allowed the SP3 update to complete successfully with no reboot require for the change to take effect and I was then able to complete the upgrade to SQL Server 2014 successfully.

Decrypting an APFS volume from the Terminal

Monday, July 2nd, 2018

I’ve been playing about with a Hackintosh desktop running High Sierra, but run into an interesting problem – the FileVault Preboot loader which asks you for the password to decrypt the APFS volume doesn’t recognise the USB keyboard by default.

Apparently there are ways to fix this by building the necessary drivers and inserting them into the Preboot volume, but as the drive in question is an m.2 NVMe disk, I didn’t have an easy way to put it into another computer which could mount APFS volumes.

I therefore decided that the quickest and simplest way to recover a working system was to temporarily decrypt the volume.
To do this, I booted the macOS installer from my UniBeast USB stick and launched the Terminal from Utilities->Terminal in the menu bar.

I found plenty of articles suggesting to use “fdesetup” to manage FileVault, however this utility doesn’t seem to be included in the macOS installer, so instead I had to work out how to accomplish this with the “diskutil” utility.

As I’m using APFS, everything takes place using the commands under “diskutil apfs”, however for older HFS+ formatted disks, the same thing should still be possible using the equivalent CoreStorage commands under “diskutil cs” (although I haven’t tested this, so the steps may be a little bit different).

Now lets take a look at the disks and volumes in this system:

diskutil apfs list

This gives you an ASCII tree view of your disks and their volumes along with various information about each of them.

Find the UUID (the 5 groups of letters and numbers separated by hyphens) for the volume  that you want to decrypt – it will say “Encrypted: Yes (Locked)”.

Before we can decrypt the volume, first we need to unlock it:

diskutil apfs unlockVolume <UUID>

Enter your passphrase and the volume will be unlocked so that it can be accessed. This only unlocks the Volume whilst the computer is running however and won’t persist after a reboot.

To permanently decrypt the volume, run:

diskutil apfs decryptVolume <UUID>

This will start the decryption of the volume in the background.

You can run “diskutil apfs list” again to see the progress. Instead of the previous “Encrypted:” line, you should now see “Decryption Process: 1.0% (Unlocked)”.
Depending on the size of the volume in question, it could take quite some time to complete the decryption.

Once completed, the progress line in the output of “diskutil apfs list” will have been replaced with “Encrypted: no”. At this point it’s safe to boot back into normal macOS.

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 (, 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
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 -qO – | tar zx
wget -qO – | tar zx
wget -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;

— 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;

— 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;

— 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

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

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 -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 -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 -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.

Missing Junk mailbox in Apple Mail

Tuesday, August 19th, 2014

When setting up a new MacBook Pro recently, I was impressed that all of my mail account settings were synced over via iCloud, but somewhat surprised and confused to find that the “Junk” mailbox for all accounts was missing.

I couldn’t find the “Junk” mailbox anywhere – it wasn’t in the list of special folders (Drafts, Sent, Trash etc.) with the Inbox and it wasn’t in the list of general mailboxes – it had seemingly just vanished.

This is particularly annoying for me as I used Zimbra for my mail server and can train the server side junk mail filters by moving messages in and out of the special “Junk” mailbox.

All of the junk mail settings in Apple Mail were enabled and seemed to match those in the same version of Apple Mail on my old laptop, so what was happening?

It seems that when you have the junk mail setting in Apple mail set to “Mark as junk mail, but leave it in my Inbox”, Apple hides the “Junk” mailbox to start with whilst it trains its filters and then only shows it once they have sufficient data built up to start identifying spam.

A quick work around to get the “Junk” mailbox to show up straight away is to change the junk mail setting in Apple Mail from “Mark as junk mail, but leave it in my Inbox” to “Move it to the Junk mailbox” and back again.

Changing this setting causes the “Junk” mailbox to be shown and the mailbox doesn’t get hidden again when you change it back.

Parallels Plesk hanging on login

Friday, June 27th, 2014

I recently came across a strange problem when setting up a new Windows Server running Parallels Plesk 12.

Everything was working fine to being with, and then suddenly Parallels Plesk started behaving strangely. I would select some items in a list and press remove and they would be greyed out as if the AJAX had fired in the background, but they wouldn’t be removed from the list until refreshing the page.

Wondering if this was some kind of browser problem as I was using Apple’s Safari, I fired up Mozilla’s Firefox but was somewhat surprised that I couldn’t get past the login screen.

The login page loads, but once I’d entered the username and password and pressed “Log In”, the page would just hang, loading indefinitely until it eventually times out.

The CPU and memory usage on the server were fine. The services were all running correctly. What’s going on?

After a quick look in “C:\Program Files (x86)\Parallels\Plesk\admin\logs\php_error”, it was pretty obvious that the recently installed Parallels Panel Mobile Center extension wasn’t working properly, as there were lots of errors about being unable to access files in “C:\Program Files (x86)\Parallels\Plesk\var\modules\plesk-mobile”.

Deleting the “C:\Program Files (x86)\Parallels\Plesk\var\modules\plesk-mobile” folder at least allowed me to log back in to the Parallels Plesk control panel, however the Parallels Panel Mobile Center extension couldn’t be removed.

After a bit of digging, it seems that the permissions on “C:\Program Files (x86)\Parallels\Plesk\var\modules\” aren’t set correctly out of the box and the “psaadm” user needed to be given write access to this folder in order to create or remove the files and folders for extensions when they are installed/uninstalled.

Once the permissions had been corrected, I was able to remove and then reinstall the Parallels Panel Mobile Center extension successfully.

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

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 with a subnet mask of and the default gateway set to

./ipmicfg-linux.x86_64 -dhcp off
./ipmicfg-linux.x86_64 -m
./ipmicfg-linux.x86_64 -k
./ipmicfg-linux.x86_64 -g

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:

The problem is that the 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


%dir %{contentdir}

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


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”.

Not able to unsuspend a domain in Parallels Plesk

Saturday, May 25th, 2013

If you are seeing the following unhelpful message when trying to unsuspend a domain in Parallels Plesk running on Windows Server:

Warning: The domain is still suspended for the following reason: This user account and user’s domain were suspended

Then you will need to use the command line domain.exe tool to manually unsuspend the domain:

“C:\Program Files (x86)\Parallels\Plesk\admin\bin\domain.exe” –on

I’ve not seen the same behaviour on a Linux based Parallels Plesk server, but that’s not to say that it doesn’t also suffer from the same problem.