How to Enable Awstats on Migrated cPanel Subdomains

[RJM_Web_Design]

SYSTEM INFORMATION
OS type and version	Rocky 8.7
Webmin version	2.001
Virtualmin version	7.3 Pro
Related packages	Awstats

The title. The subdomains migrated okay, but I can’t find a way to enable Awstats for them. The migration was about two weeks ago, but I didn’t notice that the subdomains / subservers lacked Awstats until this morning.

Thanks,

Richard

[tpnsolutions]

@RJM_Web_Design,

Is AWstats enabled on the “top-level” domain?

If not, you’ll need to enable there first, then you should be able to enable on the “sub-domain”.

[RJM_Web_Design]

Thanks.

It is enabled (and working) on the top-level domain, but I cannot enable it on the subs. The option doesn’t appear anywhere that I’ve been able to find.

That’s not to say that it doesn’t exist, mind you, just that I’ve been unable to find it.

The sub.domain.tld_access_log files don’t exist in /var/log/virtualmin for the subs without Awstats. The ones without Awstats are all migrated cPanel subdomains. The ones I created manually post-migration do work.

Richard

[RJM_Web_Design]

Might “Convert to Sub-Server” be the fix?

That seems like something I might rather try at night…

Richard

[RJM_Web_Design]

Just for the record, I’m not in the habit of talking to myself. But I figure I may as well keep a running log for the benefit of any other poor bastard with the same problem.

I did finally get AWstats enabled for the migrated subdomain turned subserver. In addition to having to correct the httpd.conf file after the conversion as described in my other post, I also had to do the following:

• Deleted the awstats.domain.tld.conf file for the parent domain in /etc/awstats, as well as the awstats.sub.domain.tld.conf file created by the failed attempt to enable it for the sub.
• Disabled the AWstats feature system-wide.
• Maybe not strictly necessary, but I uninstalled and reinstalled AWstats in Webmin.
• Re-enabled the AWstats feature system-wide.
• Re-enabled AWstats for the sub.

But wait, there’s more!

Re-enabling AWstats for the sub resulted in a awstats.sub.domain.tld.conffile with errors:

SiteDomain = "localhost.localdomain"
HostAliases="localhost 127.0.0.1"

That was also true before I did the above steps, and those entries in the config file for the parent domain may well be what caused enabling AWstats on the sub to fail.

I corrected those two settings and went to Webmin > Servers AWstats Reporting, where I noticed that the path was wrong and and the job wasn’t scheduled. I corrected the path and manually executed the job, and voila, it worked.

At that point I scheduled the cron job to run daily.

Richard

[RJM_Web_Design]

SUMMARY

Okay, they’re all done.

Some observations, some (or all) of which may be specific to my case. My case is:

• The site was converted from a static HTML site to a PHP site in 2005.
• It’s had relatively few updates to the core code except for those needed for MySQL compatibility.
• The site had been on cPanel servers since its inception.
• cPanel changed things around multiple times during that period, implementing kludges galore to hold things together.

What I observed:

• AWstats couldn’t be enabled on the subdomains until they were converted to subservers. More about that will be forthcoming in a related thread.
• After conversion to subservers, Awstats failed on every initial attempt to enable, on every subserver and the parent server.
• The problems were that the LogFile path, SiteDomain, and HostAliases entries were incorrectly generated.
• Actually, the LogFile path probably would have worked, but have been much slower because it would have had to parse the log for the entire domain. On the other hand, it would have generated historical data for as far back as the logs went. Everything is a trade-off.
• The correct path entry should be LogFile=/var/log/virtualmin/sub.domain.tld_access_log
• Correcting those three entries, enabling the cron job, and manually generating the first report fixed the problems.

Richard