Jump to content

websavers

Member
  • Content Count

    261
  • Joined

  • Last visited

Community Reputation

6 Neutral

About websavers

  • Rank
    Level 2 Member

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. They did address them in tickets to those users. The gist is that the license cache would normally work great to prevent WHMCS outages when their license servers are down, however the cache is erased any time a WHMCS instance is accessed using a different URL, which could include an alternate domain, or an IP address if your web server is configured to access the WHMCS instance by IP. (Note that it doesn't need to be an actual admin of your WHMCS install accessing it via the alternate domain or IP -- it could just be bots pinging the site using that incorrect URL that cause the license cache to be erased, and so the actual WHMCS admin would never know its happening). And so John's list above is a list of possible solutions to prevent the URL being used to check in with the licensing server from changing, thus ensuring the integrity of the license cache.
  2. Hey John, this seems mostly reasonable to me, however I would say that in terms of the system URL redirect, many web apps do this, like WordPress. You simply add documentation indicating how to change the URL after a relocation. You could even supply a PHP CLI script to help make it happen. If this is reasonable for other web apps, I see no reason it's not reasonable for WHMCS. As for your selected solution: would that alert show to all admins no matter which URL they've logged in with, and only after someone (but not necessarily that admin) has attempted to access WHMCS from a URL other than the system URL? The reason I'm asking is that whomever logs in using the wrong URL (domain/IP) may not be the one who needs to see the alert to correct it. Further the WHMCS instance may be accessed by someone not even logging in at all, which apparently clears that license cache as well.
  3. I seem to be able to connect to all but g.licensing.whmcs.com without any troubles.
  4. Alrighty so obviously it's not great that the licensing servers went down, though service outages are ultimately expected at some point or another; it happens to everyone. There's plenty of options for how to handle paid software and WHMCS has chosen an option that requires that we use their licensing system to ensure the software works. We don't explicitly want to have to license the software purely to keep it alive: but that's what WHMCS requires of us. (As a comparison, think of GPL software, like most of the WordPress ecosystem. We pay for licenses to get updates, not to be able to continue using the software at all). And so, since this is WHMCS's requirement (and not one we specifically *want*), the bare minimum they could do for us is ensure that their licensing system works flawlessly. Clearly this incident brought into question two key issues: That their servers weren't able to handle the problem gracefully despite seemingly having multiple fallback licensing servers (though again, I'm not overly annoyed about this part), and That the software does not handle things in an acceptable manner when the licensing servers are not available In my opinion that second issue is the true problem here. As WHMCS staff have stated both in tickets and I believe here in this thread, WHMCS *is* programmed to keep a license cache and keep the software going in the event of licensing server failures. However the bug that created all of these issues is that the license cache only works if the domain for which you access WHMCS remains 100% consistent. So if you access WHMCS (or bots do) occasionally through an alternate URL, or the server's IP address, that triggers a clearing of the license cache, forcing WHMCS to check in with the licensing servers again. In our case, it was IP address access that was clearing the license cache. In another user's case further back in this thread, it was slight variations on their domain -- seemingly a domain alias that didn't 301 to the primary TLD. This meant a simple fix to prevent the license cache clearing going forward: no longer allow access from the server's IP. However the reality is since this is WHMCS's software and WHMCS's licensing system and servers, it's up to WHMCS to ensure that this bug is fixed in the software and not something end-users have to deal with. I have suggested that they simply add some code that runs prior to any licensing checks that ensures WHMCS redirects to the System URL configured in WHMCS, therefore making all license checks occur against the correct URL. WHMCS staff have indicated the following in response: If you also believe this should be fixed in the WHMCS code and that it's not something we should be required to repair for WHMCS (even though we *can* do so, and have done so), please like this post and let them know in a support ticket that you'd like to have a pre-license-check redirect added to their codebase.
  5. Yep, def do that, and if you still have our suggested workaround above in place, make sure to remove it from /etc/hosts (or comment it out) as that'll continue to get you errors, though I believe you'd be getting a different error from the HOSTS override. Haha, tried that with other support requests in the past... they just ignore it like you never asked!
  6. The issue with their licensing servers is now fixed indeed. Meanwhile their support staff have told me that the reason this was a problem for us in particular is because our system is checking for licensing more frequently than it should be. They then suggested I check my PHP environment to ensure it's working properly... yet *all* of this code that controls the frequency of their licensing checks is within their encoded PHP that I have no access to. Can't say I'm surprised that even during a systemwide licensing server outage they're happy to put at least partial blame on their customers for something that clearly has to be a problem with their own code.
  7. Don't go near the license check button (if it exists?) and with any luck they'll have their servers fixed before you ever see a problem.
  8. Please don't tell me that having working licensing servers should be a feature request? 🤭
  9. Their servers appear to be down. To bring back our WHMCS system, we had to add this to /etc/hosts: 127.0.0.1 f.licensing.whmcs.com a.licensing.whmcs.com b.licensing.whmcs.com c.licensing.whmcs.com d.licensing.whmcs.com e.licensing.whmcs.com g.licensing.whmcs.com h.licensing.whmcs.com But admin is still down of course because now it just says our license is invalid. But at least the front-end is up. Including this here for anyone else experiencing licensing issues. Note that not everyone will because the software doesn't always check in with the licensing server. Don't trigger it manually today, whatever you do!
  10. Confirmed as Case #MODULE-7660 -- WHMCS devs are working on it, no timeline to repair.
  11. Having worked with the Plesk API and PHP SDK before, I suppose an alternative explanation could be that the session created by the connection to the first server isn't being invalidated and is being passed on to the next connection attempt, despite the difference in connection info (ie: new server hostname, username, password)
  12. If you're not using Plesk and you are using well supported/updated 3rd party modules, it should be a smooth upgrade 🙂
  13. We're seeing the same issue here. Furthermore it appears to interrupt the ability to update hosting usage stats. When I go to the Disk Usage Summary report and click "Update Now" at the bottom, the module log shows plesk_usageupdate on all servers result in something like this (I've trimmed it down and replaced the actual domains): Array ( [@attributes] => Array ( [version] => 1.6.4.0 ) [webspace] => SimpleXMLElement Object ( [get] => SimpleXMLElement Object ( [result] => Array ( [0] => SimpleXMLElement Object ( [status] => error [errcode] => 1013 [errtext] => domain does not exist [filter-id] => domain1 ) [1] => SimpleXMLElement Object ( [status] => error [errcode] => 1013 [errtext] => domain does not exist [filter-id] => domain2 ) [2] => SimpleXMLElement Object ( [status] => error [errcode] => 1013 [errtext] => domain does not exist [filter-id] => domain3 ) ) ) ) ) Prior to the 8.2 update, usage stats updates were working fine. All resource usages show last update was roughly a week ago. It looks like it's attempting to load stats from all servers by sending each API query (for all the servers) to just the first server. It successfully obtains usage stats from our first server in the list for both resellers and customer objects in Plesk. But then it sends the API query for subsequent servers through to that first servers as well, resulting in the 'domain does not exist' errors -- which is correct as WHMCS is querying the wrong server. We've already applied these hotfixes: - CORE-16812 - Plesk Login to Panel SSO IP - CORE-16765 - TypeError provisioning Plesk services - CORE-16844 - Add zero price recurring products to cart Which apparently don't help with this particular issue. More details: Our cron is set to run every 10 minutes and shows successful on the Automation Status page It even says: Server Usage Stats -- Task completed successfully. (which can't be true, so whatever it's using to judge that seems to be failing as well). Activity log shows the following during daily cron: Server Usage Update Failed: Error code: 1013. Error message: Reseller does not exist - Server ID: XX (this is because of the reasoning above -- it's looking for a reseller on the wrong server). I think it's pretty clear that something in the servers loop is preventing iteration and only returning the first server in the list.
  14. Thanks @WHMCS ChrisD! Yes, that's a more complete solution to my submitted/accepted pull request 🙂 Great to see a quick turnaround time on it.
  15. WHMCS staff said this on the topic: The Type Error hotfix must be applied With the 8.2 version of the Plesk module, they now send the server IP to authenticate with Plesk, which does not match the client IP and so Plesk invalidates the session To work around this, you must have the option in each of your Plesk server's enabled to not validate user IPs: 'On your Plesk server, please enable "Allow IP address changes during a single session" under Plesk > Tools & Settings > Active Plesk Sessions > Session Settings'. [The Plesk dev team told them this session setting was enabled by default, yet none of our servers had it enabled, so perhaps only with the most recent versions of Plesk is it enabled on fresh install?] We do have an open case for that so that the Plesk module can be updated to send the client IP (case CORE-16812) and our development team is working on that. Unfortunately, I cannot provide an estimated time for completion for this. However, once we resolve cases and push features they are available at our change log. I asked "Since the 8.1.3 version of the Plesk module works fine, shouldn't this be priority since this bug is a regression?" to which they said: "As for the prioritization, what I said could change if our development team determines that a hotfix is necessary or if any conditions surrounding it change (for example: if they determine that the impact on our users, despite the workaround, merits it). I've already tagged this ticket to case CORE-16812, so if a hotfix is released, we will be in touch and provide it to you." And so unless you only have one or two Plesk servers where you can easily apply the workaround, I think the best option -- until they either release a hotfix or an update to WHMCS that includes the fix -- is to simply roll back the module to the version from 8.1.3. Correction, it seems they did release a hotfix after all. I have applied the hotfix and can confirm it resolves the problem.
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use & Guidelines and understand your posts will initially be pre-moderated