Hi, Yesterday, we had whmcs disabling 2 domains automatically, using the API.
Both domains have been disabled, and virtualmin logs for both domains look identical, except for one thing (changed their names to domain1 and domain2 below for customers privacy reasons):
First domain1.com ran:
Changed file /etc/dkim-domains.txt
13d12
< domain1.com
Then domain2.com ran:
Changed file /etc/dkim-domains.txt
12a13
> domain1.com
43d43
< domain2.com
(so it looks the 2 requests ran almost simultaneously (at least from Date and time 11/Dec/2013 02:00 both are same, no seconds there to compare exact times).
Both domain1.com and domain2.com have sub-domains which do not appear disabled in DNS servers while main domains are).
But now domain1.com appears as disabled in virtualmin, but domain2.com does not appear as disabled (and thus cannot be re-enabled which is annoying).
Trying to run command-line API gives following result:
# virtualmin enable-domain --domain domain2.com
Virtual server domain2.com is not disabled
Enables all disabled features in the specified virtual server.
virtualmin enable-domain --domain domain.name
[--subservers]
Now, independantly that this seems to be a concurrency bug, I'm flagging this as Virtualmin Pro custmoer support: We need to re-enable domain2, and not sure if doing everything that got logged in the corresponding log manually will be enough to re-enable them, we would prefer to set the domain as disabled manually, then let virtualmin enable them.
In which file and how is the Virtualmin status for a disabled virtualmin-domain stored so i can manually change it so that i can run the command to re-enabled it ?
Comments
Submitted by beat on Wed, 12/11/2013 - 20:22 Comment #1
i found the domains in /etc/webmin/virtualmin-server/domains/NUMBERSHERE :
The disabled domain1.com has at end:
backup_encpass=$6$REMOVED.old_dns_slave=ns2.ourdnses.com ns3.ourdnses.com
disabled_oldpass=$6$REMOVED
disabled_why=
disabled_oldmysql=*REMOVED
disabled=unix,dns,mail,web,mysql
while domain2.com doesn't have this.
Should we add those lines, finding the missing values from the virtualmin logs and would that be enough to make it appear as disabled in virtualmin ?
Submitted by JamieCameron on Wed, 12/11/2013 - 21:14 Comment #2
Yes, just adding the disabled= and disabled_oldpass= lines should do what you want.
The underlying issue is that the DKIM config file isn't properly locked to prevent concurrent updates. I'll fix that in the next Webmin release.
Submitted by beat on Fri, 12/13/2013 - 08:05 Comment #3
Okay, yes that worked.
The strange things that the changes (that should have been) made to the /etc/webmin/virtualmin-server/domains/NUMBERSHERE file were perfectly logged in the change log, but not done in that file.
Would that different bug be related with the DKIM no-lock-DKIM-changes bug you found ?
Finding it strange that it's logged but not made (at least thanks to beeing logged, I could just redo the change manually, then successfully unsuspend the virtual server.
Submitted by JamieCameron on Fri, 12/13/2013 - 10:52 Comment #4
That sounds like a related bug - it implies that two different scripts were modifying the same domain at the same time, but didn't lock its file under /etc/webmin/virtual-server/domains correctly.
However, if your case did you mean that WHMCS was disabling two different domains at the same time?
Submitted by beat on Fri, 12/13/2013 - 16:16 Comment #5
That's strang as there were 2 requests for disabling 2 different domains at same time (or almost same time). So not same domain. Maybe there is a non-waiting lock on all virtual-server-files instead of only one ?
Also if the file update would have failed, i would expect the log to still log the wanted change (so it's saved somewhere) and to log the failure.
Thanks a lot for your dedication on making VirtualMin rock-solid and on the support! Really appreciated. Two thumbs up!
Submitted by JamieCameron on Sat, 12/14/2013 - 01:07 Comment #6
The only other case I can think of is if the script that was updating that domain was killed before it could complete, but after it logged the file changes.
Submitted by beat on Sat, 12/14/2013 - 06:33 Comment #7
Wierd, I don't see what could have killed that script (except if there was a timeout or too long request, but then I wouldn't have had a "successful suspension of domain" email sent by whmcs).