legupcomputingHi,We're having some issues with TA_ExtendTrial() with a client.Here is what happens:1) We gave them a trial extension code. In our software we call TA_UseTrial() and get the expected TA_E_TRIAL_EXPIRED error code. Then we call TA_ExtendTrial() and we see a message indicating TA_OK was returned.2) Now they run our software again and TA_UseTrial() is still returning TA_E_TRIAL_EXPIRED
What could be causing this? Normally this works fine. Is there a debugging mode to determine why the software thinks that the trial is still expired.
Also another thing to note, this same person used a trial extension a few weeks ago for 30 days. That worked fine at first but then suddenly the trial expired (after only 2 weeks). Then we have the issue above when we try to extend their trial. They are using CentOS if that matters.
If theyre using a VM and theyre using unusual behavior (suspending / resuming) and their VM software is not properly written (the majority of VM software) then they will trigger our fraud detection.
Or if theyre on a real machine and theyre messing with date, time, or time zone then theyll also be trigger the fraud detection.
legupcomputingThey are not using a VM, this is a real CentOS server used by many people at the corporation. They don't have root access on the machine so I doubt that the date/time is being changed. If the fraud detection is triggered, is there a debugging message to determine this is what is going on?
legupcomputingWe managed to fix the issue this morning by using an offline trial extension.Seems like the server lost connection to the internet (IT must have disabled internet access). I think the error message should be made more clear so we know when this is happening.
legupcomputingThis morning the client had the exact same issue. The trial is showing as expired despite working yesterday after the offline activation (said 50 days remaining).Any ideas what is going on?
It's hard to know without more information. All we can do is speculate. To figure out exactly what is wrong we need more information:
https://wyday.com/limelm/help/faq/#useful-reports
Version numbers, trial extensions, etc., etc.
legupcomputingWe found out some more information that might indicate what's happening.Turns out that the client setup involves a script that runs our licensed software. Normally the script runs on CentOS server A, but very occasionally the script will invoke our licensed software on another Ubuntu server B. Both server A and server B share the same filesystem with each other. After running on server B, the license server probably detects a change and the trial license expires. From that point forward the trial license also no longer works on server A.Is this expected behaviour? Is there an assumption that there won't be multiple servers accessing the same file system? We aren't using the floating server.Also, if server B invalidates the trial license, does that mean server A can now no longer use the trial license? I would have expected the trial would still work on server A, but perhaps the TurboActivate.dat shared file permanently disables the license?
>> "Is there an assumption that there won't be multiple servers accessing the same file system?"
Computers / servers / devices can access the same filesystems, just so long as they're not doing something very odd (like sharing the same base filesystem across multiple devices). I.e. hard drive cloning. If they do that the trial will be set to 0 because TA will correctly detect fraud.
So, make sure your software is installed correctly on the device and you're using TA_SYSTEM to save the activation details on the system (and not TA_USER which might store the activation data transiently).
legupcomputingThis is just a standard shared network drive accessed by many linux servers, there is no cloned hard drive or anything unusual.
We are using TA_USER to avoid root access during installation. Our software is being installed on a server where our client doesn't have root permission without having to escalate this to their IT department. Could TA_USER be causing the issue I described above?
Yeah, it could. Or it couldnt. Hard to know without a reproducible example. Its hard to solve murder-mystery style bug reports.
Best type of bug report: https://wyday.com/limelm/help/faq/#useful-reports
legupcomputingWhat more information do you need? I've provided all the information from that link. We are using the latest version of your software. The license is on CentOS 6. I've provided a very detailed account of the problems above.
A reproducible example is what is needed. There is a vague mention of a shared filesystem. Is the base-system shared among multiple devices? Or just a plain-old shared NFS? It sounds like it's some hybrid.
So, easy solution: use TA_SYSTEM.
Longer solution: try to reproduce their setup, then reproduce their problem, then convey those steps to us. And if it's a reasonable use-case we'll provide a solution. If it's some frankenstein's-monster abomination we'll probably just recommend you use TA_SYSTEM.
