The plugin Analytics Tracking cannot be used : Apache's mod_perl version 2 must be installed

Fresh install Ubuntu. All repository files updates. Freshly downloaded Went to start restoring domains from old 6.06.1 LTS server. Anayytics complains that it is not installed. I go to Virtualmin Software Packages and install that and some others that aren't installed by default that I notice are installed on the old server.

I'm guessing this is the result of a missing dependency and I thought you guys should know about it. Please advise as to the correct apt-get I should use for installation of this dependency.


Closed (fixed)


Howdy -- it sounds like you did the right thing to install Google Analytics. But are you saying installing that didn't work properly for you?

If you wanted to install that from the command line, you can install Google Analytics by running this command as root:

apt-get install webmin-virtualmin-google-analytics

No sorry. I guess I forgot to include a message that I'm getting now which is this.

when I try to enable analytics, it says the apache mod-perl version 2 needs to be installed.

Oh I see, the error you got is in your Support Ticket subject, I missed that :-)

Try running this command:

apt-get install libapache2-mod-perl2

That should resolve the mod_perl dependency.

No joy with that. It installed fine but did not clear the issue. I still get the same thing when I try to enable the analyitics module. What has prompted this is it is installed and enabled on the server I am migrating from and it clearly states that if I restore that back up to this system without it enabled, I will break the configuration of the target system.

Let me know what to try next.. or if you wanna dig into it, let me know and I'll open er up to ya.


Well, one other thing to check -- if you look in System Settings -> Feature and Plugins, is the Analytics Tracking feature enabled?

If not -- can you paste in the specific error you get when trying to import your backup? Thanks!

It is not enabled. The error I get when trying to enable it and save that configuration is exactly this:

Ok... when I went to another menu and then back to Features and Plugins, Analytics is enabled now!

I'll now try the restore again...

Well I got a little further before failure. The pjpalmer reseller account is in the other server and was selected to be backed up as per the server migration link sent to me in the last ticket... I made sure and tried to follow that to the letter. I also just checked and verified that those accounts did in fact get restored as well.

Here's the log:

Starting restore of 8 domains from local file /home/administrator/6 ..

Extracting backup archive files .. .. done

Restoring Virtualmin settings .. Restoring Virtualmin configuration .. .. done Restoring templates and plans .. .. done

Restoring resellers .. .. done

Restoring email templates .. .. done

Restoring custom fields, links, categories and shells .. .. done

Restoring custom script installers .. .. done

Restoring scheduled backups .. .. done

Restoring FTP directory restrictions .. .. done

Restoring DKIM settings .. .. not installed

Restoring greylisting settings .. .. not installed

Restoring mail server configuration .. .. done

.. done Re-creating virtual server .. .. the reseller pjpalmer specified in the backup does not exist

Re-loading Webmin .. .. done

Applying FTP server configuration .. .. done

.. failed! See the progress output above for the reason why.

Next step? =)

On a hunch, I thought that maybe the other data hadn't quite had time to get activated yet and tried a restore of those 8 without again restoring the Virtualmin data... thinking that I really only need to restore that once during migration. Is this correct?

Put another way, If I decide to migrate the domains in groups of domains instead of all of them at once, do I need to backup and restore the Vittualmin settings section at the bottom of the items list more than just in one of the groups?

It sounds like the problem you're having is that the reseller account that owns one or more of your domains isn't there.

That should be part of the virtualmin.tar.gz file.

Although Virtualmin should be handling data from the virtualmin.tar.gz first -- what you could do is first restore the virtualmin.tar.gz, which should import your reseller accounts -- and then you can restore your various Virtual Server backups.

If you opt to restore Virtual Servers in groups, you would only need to restore the virtualmin.tar.gz file once (and I'd recommend doing it first).

Yes I thought so. It did in fact restore the VIrtualmin.tar.gz first but for some reason, by the short time after it took to get to that part of the first domain restore, it didn't think that the reseller account was there. A bit later, I checked to see if the account was there and it was. I restored the same file again, this second time uncheciing the Virtualmin.tar.gz items from the list and it worked perfectly. I"m continuing with the next two biggies with a couple of databases. Those should restore and work from the backup on the new server without having to manually dump, transfer and restore the database to the new server separately correct? I actually have yet to have that experience with Virtualmin in a migration... so I do have a current manual dump just in case this time. =)

I've made a note to talk to Jamie about the reseller issue you ran into -- that really should run smoothly during a migration.

Those should restore and work from the backup on the new server without having to manually dump, transfer and restore the database to the new server separately correct?


You shouldn't need to manually dump or restore databases.

While it's great to have backups like that, if you end up needing to use them, that suggests a rather large bug in the restore procedure :-)

Yes. THat did not go well. and both servers that I tried to move are down. is giving a 503 and is giving the default apache website. I think I'll need to open it up for you on this one.

The backups of those domains from the other server at located in /home/administrator/7

The database dumps are in /home/administrator with various names which do not match. I"m pretty sure if I need to use them again I'll figure out which ones are what.

It's normal to have to do a little tweaking for some sites on a new server. It's okay, those issues can all be resolved!

Taking a look at the two sites you mentioned --


I looked in $HOME/logs/error_log for this domain, and saw that it was having problems reading files in the website cache directory, /home/semogrotto/public_html/cache. What I did is set the files there to "755" permissions, which allowed them to be properly read. Your site is no longer showing that 503 error.


With this site -- it looks like the DNS servers for it are pointed to a third party DNS service, NS19.DOMAINCONTROL.COM and NS20.DOMAINCONTROL.COM.

You may just need to visit the control panel for that service, and make sure the DNS for that domain is pointing to your new server. It appears to be returning an IP that points elsewhere,

OK checking on DNS for I guess I cannot save a configuration file in phpbb3. I get a 500 when trying to re-enable the board.

Yeah my bad on DNS. I still have it at the registrar. THat should be fixed now so I can see that site in a bit... see if it restored ok. site is now fine. and I was able to enable the phpbb3 forum there without issue. SHould I maybe just remove the virtual server for and try to restore it again?

Your site is looking good now!

Regarding --

The problem there isn't related to the restore process, it's related to little changes in how the new distribution functions. In theory, anyhow :-)

The key is to troubleshoot as errors occur -- looking in the error logs for the errors, and then tweaking settings to fix them.

Are you still having that same problem? If you try to enable your site, it can't save the configuration file?

What should the PHP Execution Mode be for this particular Virtual Server?

Should it be using mod_php? Or should it be using CGI/FCGID?

If it should be using mod_php, we may need to tweak the permissions of /home/semogrotto/public_html/cache/data_global.php so that the application can write to it. isn't working at all now. I'm going to remove it and start again fresh with the restore and then try it again.

It appears my hunch was right on I restored it, it was broken like before. This time I just simply went in and set the PHP execution mode to FCGI from Apache and it is all working great. I think I had that server running under apache mode with php4 on the old server.

I'm going to close this ticket ... partly because it is becoming long, partly because we aren't even talking about what it started out with. LOL I'll open another ticket if I have any other issues. The rest of the migrations if I recall correctly when I did this the first time went fine. There's about 30 more to move. If I have a problem. I'll holler atcha..

Thanks again!


I'm glad your domain is working now!

We're happy to help, and if you run into any other issues with your other domains, feel free to let us know.

Using a new request like you mentioned would be great.

Good luck with the rest of your migrations!