Virtualmin Pro Module and WHMCS Out of Sync Causing Incorrect Overuse Billing

[eugenevdm]

We use Virtualmin Pro to keep track of shared hosting bandwidth and disk space usage. We are encounter a problem whereby WHMCS is not reading the Virtualmin data correctly and things appear out of sync. This is so for multiple servers. It's affecting overuse as clients are being billed for the wrong client's overuse.

To demonstrate I paste two tables below.

Table one is WHMCS data for usage, calculated by the overuse CRON. I've ordered the data according to usage in descending order. Everywhere there is a 0 is incorrect - those packages exist in Virtualmin with the correct limits.

The query for this table is:

select domain, tblproducts.name, bwlimit, bwusage, lastupdate from tblhosting join tblproducts on tblproducts.id = tblhosting.packageid where domainstatus='Active' order by bwusage desc;

+----------------------------------+------------------------+---------+---------+---------------------+
| domain                           | name                   | bwlimit | bwusage | lastupdate          |
+----------------------------------+------------------------+---------+---------+---------------------+
| domain1.com                      | WordPress Hosting      |    5120 |    1657 | 2019-03-29 07:00:57 |
| domain2.com                      | Micro Website Hosting  |    5120 |     139 | 2019-03-29 07:00:57 |
| domain3.com                      | Basic Website Hosting  |    1024 |      17 | 2019-03-29 07:00:57 |
| domain4.com                      | Basic Website Hosting  |    1024 |       0 | 2019-03-29 07:00:57 |
| domain5.com                      | Basic Website Hosting  |       0 |       0 | 2019-03-29 07:00:57 |
| domain6.com                      | Basic Website Hosting  |       0 |       0 | 2019-03-29 07:00:57 |
| domain7.com                      | Basic Website Hosting  |    5120 |       0 | 2019-03-29 07:00:57 |
| domain8.com                      | Micro Website Hosting  |       0 |       0 | 2019-03-29 07:00:57 |
| domain9.com                      | Basic Website Hosting  |       0 |       0 | 2019-03-29 07:00:57 |
| domain10.com                     | Basic Website Hosting  |       0 |       0 | 2019-03-29 07:00:57 |
+----------------------------------+------------------------+---------+---------+---------------------+

Table 2 below is data from Virtualmin Pro. To protect my client's identities I had to blur the website names, but the packages and limits are all jumbled up. The first one on the list, that have used 1.6 GB, is not the first one on the WHMCS list. The limits are also wrong especially the zero, there is no package with a zero limit. This goes on.

It seems WHMCS doesn't use the domain name to match the data, but some other arbitrary identification that is not correlating with the Virtualmin data. We thought this couldn't be possible so set up a fresh test environment with a new WHMCS and a new Virtualmin server. Same results, some domains match up and limits are correct, others are simply not read. We also turned on module logging - module is returning the correct data.

 

 

 

[brian!]

your best bet for fixing something like this might be to file a Bug Report (if you get your license from WHMCS) or open a ticket with Support...

• if you get your license directly from WHMCS - https://www.whmcs.com/support/
• if you get your license from a reseller / host - https://www.whmcs.com/reseller-support/

with this being their module, and it being encrypted, I think there's probably limited help available from other users (who might not even be aware of the issue you've highlighted)... I wouldn't expect a maintenance release until next month, but if there is an issue with this module, it's likely hotfixable (if they choose to do it).

I know there was a bug fix for the usage stats in v7.2.2, but nothing since then that i'm aware of - I assume that you're using a later version than that (your site looks v7.6+ to me)...

[eugenevdm]

Thanks I have submitted a bug report. The behaviour is on our test server and in our live environment.