Category Archives: *NIX

Stuff relating to the only real OS currently kicking around out there :)

Courier IMAP problems with STARTTLS (Checking mail server capabilities)

I have recently upgraded my mail server from Debian Wheezy to Debian Jessie, which along with it brings new versions of software, including Courier. For the most part this hasn’t been an issue except when it came to the IMAP service. On Thunderbird clients you would see “Checking mail server capabilities” and nothing more when connecting to the server, other clients I assume would have differing error messages, or just flat fail to connect. A quick fix was to switch the clients to SSL, BUT this I don’t think is a good fix as it requires your users to have to make a change. I have thankfully after much googling discovered what seems to be a fix (works for me ™ ).

Courier now uses dhparams.pem (Generate Diffie-Hellman Parameters – OpenSSL Wiki article). Now my fresh new courier install already had one of these present, but I suspect this may be too small. Regenerating this with a nice big 2048bit version rectified my STARTTLS issues instantly (well I did restart courier-imap and courier-imap-ssl too 🙂 )

The command I used is :

openssl dhparam -out dhparams.pem 2048

(This WILL take a fair amount of time, don’t worry it does finish 🙂 )
whilst within the /etc/courier path, followed by a restart of the imap services. My original dhparams.pem file was 201 bytes, after generating a new one it is 424 bytes 🙂

Hopefully this will help save someone’s hair 🙂

GRUB physical volume pv0 not found – one fix

I have had one of those days today…

One of the mount points on my server had gotten a little tight for space, so I decided to grow it before it became a problem. Naturally I use LVM so that’s not an issue.. well assuming you have free space on the LVM physical volume that is.. Thankfully this is a server running under virtualisation, so adding an additional physical volume was a simple task and the expansion went as you would expect, flawlessly.

Whilst I was at it, I thought I’d upgrade this box from Debian Squeeze to Wheezy too. Already running Wheezy elsewhere and an upgrade I have done plenty of times to trust (mostly 😉 ). That went well, but there were a few little grumbles around grub complaining about a missing PV that worried me. So I took a snapshot (including VMs memory) before running the magical restart. I am VERY glad I did!

Alas it seems there is a bug in GRUB 1.99 that from my Googling seems to have been around a while! It seems as though it isn’t too happy with an LVM configuration with multiple PVs. Reverting my non-booting box back to it’s running snapshot I was able to attempt ‘update-grub’ and be greeted with a long list of errors regards PV0 not being found.

Thankfully, I think I have found a work around! Although it’s not pretty and a bit time consuming. Essentially present a new PV to the box that is large enough to accommodate all existing PVs data (and probably a little extra growth room), then move your data to this new PV from all the original PVs with pvmove. This will take some time, running pvmove -v in another session/terminal you can at least see progress of the migration.

Once all the data is in your new PV, remove the old PVs from the active VG, then remove them from the system with pvremove. (They can still be connected and show as disks, just not PVs). With that done, run update-grub again, and fingers crossed you should have a bootable system once more.

I would certainly recommend you fire off a new snapshot including memory before rebooting, it’s an excellent safety net to get you back on the box.

Hopefully this will help someone else get out of this situation if they are unlucky to find themselves in it.

Curse you CPAN! (LIBXML2_2.6.0 not defined)

If you have seen the following error, possibly starting up Apache2 on your Linux box and you can’t for the life of you figure out why.. it MIGHT just be CPAN as the ultimate culprit. There is a good chance you may have a conflicting version of libxml2 in /usr/local/lib probably with a bunch of other libs too. As I didn’t install these myself, the only tool I can think of that will have done will be CPAN when a package has been installed via it.

Thankfully the fix is simple, remove the libs from /usr/local/lib that are conflicting, and don’t use CPAN 🙂

This may break your Perl module it installed, but hopefully will restore the usability of your system. My recommendation would be to only use packaged versions of your Perl modules to ensure system integrity, save you some headaches later in life.

Debian and VMware server “The path /usr/src/linux/include is a kernel header file directory, but it is not part of kernel source tree.”

Yeah a long name I know, but trying to get it stuck in Google so it will be most helpful.

I hit this snag and did a lot of trawling with little luck. Previously had no issues installing VMWare server, upgrade to Lenny, swap some hardware, decide to get it up and running and POOF! no dice!

Anyway I have solved it (huzzah!) and can finally goto bed 🙂

It seems that the error message is related to the lack of .config and or Makefile in the headers. So a .config or Makefile in /usr/src/linux/.

if you have installed your headers :

apt-get install linux-headers-$(uname -r)

have build-essential installed have set CC to be gcc-4.1 yet still you get grief, heres what I found.

If you look in the headers path, you will see .config and Makefile. Yet no joy!, look closer, the Makefile is a damn pesky SymLink!!! this goes for most if not all of the buggers. What you need along with the headers is:


which should reside in the same directory as your headers:


The SymLinks point into files in there, for some reason (possibly my own stupidity) I didn’t have it, possibly deleted it in a fit of disk space recovery before starting the build.

Hopefully that will be of use for someone out there, if not, I am sure I will find it useful when I next cause myself grief 🙂