VestaCP and Centos 7 Issues

I’ve been using VestaCP for about a year now ever since I switched from Hostgator to a VPS with OVH.

Today I upgraded the VPS OS to Centos 7 as VestaCP now supports that version as of v0.9.8 release 15.

Two problems became apparent immediately, one of which caused the CPU load to be consistently more than 1. Both are simple configuration errors to fix.


ClamAV caused the CPU to run amok. The error logs showed that it could not control /var/run/clamav/clamd.sock and checking this showed that the file and the directory (/var/run/clamav) had the wrong owner.

Stop the service from trying to start from the VestaCP control panel and then log into your server via ssh. Now set the ownership of both the directory and the file to clam:clam – if the socket file doesn’t exist you can create it with touch and then set the ownership.

Upon restarting the service you should see the CPU load drop dramatically.


For some reason VestaCP’s installer puts a link to a configuration file for Apache in the nginx config. This stops the service from starting which is why no websites are served!

Edit /etc/nginx/conf.d/vesta.conf and comment out the line ending in /httpd.conf (there are only 5 lines in the file so it won’t take long).

The service should now start.


Centos –
VestaCP –

Twitter Activity for Week ending 2015-05-10

  • Wondering if the unexpected result of election is due to dissatisfaction with the whole concept of coalition government #GE2015 ->
  • RT @PaulOBrien: When do we get to see Alastair Campbell and Paddy Ashdown eat a kilt / hat respectively then as pledged? Now THAT'S enterta… ->
  • RT @markaustinitv: I feel for Ed Balls and Vince Cable. Both good men and a loss to Commons. #ge15 ->

Twitter Activity for Week ending 2015-05-03

Twitter Activity for Week ending 2015-04-05

Removing album art from MP3s isn’t easy

Over several years, I’ve been slowly converting my music collection to MP3’s using Lame.

One of the things that bugged me was all the extra space taken up by embedded album/cover art. Given the size of my collection, I need the files to be as small as possible so I can pack as much as I can onto my MP3 players and mobile phone.

Looking around the web, I found that most Linux users recommended using eye3D (this is a cross platform app written in Python). I used this for a long time, but today I discovered that eye3D just removes the ID3 tag and leaves the binary art file still embedded which was not what I’d expected.

I then spent a fruitless few hours searching for a command line tool which would actually strip this data, as I’m not prepared to load hundreds of albums into a GUI program to do this as it would take ages and I’d die of boredom – and some well known ones actually make the file size bigger not smaller! So thinking laterally I looked at Lame’s switches and discovered that “–ti” embeds a graphic in the MP3 file. Yes, I know I said I wanted to remove the binary but my thinking was that if this was proving difficult (as it was), why not embed a small graphic instead? I found a tiny, 26 byte GIF file online here.Unfortunately it is a “non-standard” GIF so not all tag readers can cope (Lame can) so then I ran eye3D to remove the ID3 tag so everyone is happy.

It works really well – on a 2.5Gb test of 289 songs, it saved over 35Mb which is not to be sniffed at.

However …

Having uploaded some albums to my phone, I discovered that the –ti switch in Lame deletes all the other tags so I had no information about artists, albums, songs etc. So it was back to the drawing board …

I ended up hacking together some Perl code (see below) which passes through a directory working on any MP3 files it finds. If you pass a second parameter, it saves the ID3 tags to memory then deletes the complete set from the file including the album art – result! It then calls Lame. I’m sure this code could be optimised as my coding is very rusty, but it does the job.

All in all this took a lot longer to resolve that I expected. In total I’ve probably spend about 12 hours on it – most of which was research and the testing and re-testing various code fragments as I began to understand how the Perl module MP3::Tag worked – the examples on CPAN are not as comprehensive as they might be. Still I got the result I was after so it was time well spent.



use File::Find::Rule;
use MP3::Tag;

local $cmd;
local $f, $image, $Art;
local $mp3, $title, $track, $artist, $album, $comment, $year, $genre;

if ( $ARGV[0] eq "" ) {
print "\nFormat is MP3Compress <file/directory> []\n\n";

if ( $ARGV[1] eq "" ) { $Art = 0 }
else { $Art = 1; }

my $rule = File::Find::Rule->file->name("*.mp3")->start($ARGV[0]);
while ( my $image = $rule->match ) {
  if ( $Art ) {
    $mp3 = MP3::Tag->new("$image");
    ($title, $track, $artist, $album, $comment, $year, $genre) = $mp3->autoinfo();

    # delete tag completely from MP3 file to remove album art then create new one
      title => $title,
      track => $track,
      artist => $artist,
      album => $album,
      comment => $comment,
      year => $year,
      genre => $genre}
    ); # Updates tags

$f = "\"$image.mp3\"";

$cmd = "mv \"$image\" $f;lame -V5 $f \"$image\";rm $f";