whmapi1 setsiteip overwrites custom A records
whmapi1 setsiteip overwrites all A records, including the external ones with the new ip.
No clue why Change Site’s IP Address / Change Multiple Sites’ IP Addresses / whmapi1 setsiteip are intended to overwrite everything with the new ip, are there any plans to change this?
Transferring hundreds of cpanel accounts between servers in the same DNS cluster makes whmapi1 setsiteip unusable and there is no alternative provided by cpanel. We either need to fix what whmapi1 setsiteip breaks or set the ip directly in /etc/userdatadomains, /var/cpanel/userdata, /var/cpanel/users, rebuild/restart httpd and run userdata_update, none of this options are scalable.
Is there a way to change/set a dedicated ip for hundreds of cpanel accounts without overwriting custom dns settings? Or even not update the DNS at all? Transfer Tool already has something similar implemented.
-
Hey there! Let me do some testing on this and I'll get back to you!
1 -
I wasn't able to produce this on my end. I created the domain customrecords.com and created 2 A records on the account. I then ran the API to change the IP and the A records were not touched:
[root@hostname ~]# whmapi1 setsiteip domain=customrecords.com ip=1.2.3.4
---
metadata:
command: setsiteip
reason: OK
result: 1
version: 1
[root@hostname ~]# grep random /var/named/customrecords.com.db
random1 14400 IN A 12.34.56.78
random2 14400 IN A 12.34.56.55I did confirm all the default entries were changed from the main shared IP:
# grep 1.2.3.4 /var/named/customrecords.com.db
customrecords.com. 14400 IN A 1.2.3.4
ftp 14400 IN A 1.2.3.4
customrecords.com. 14400 IN TXT "v=spf1 +a +mx +ip4:195.214.233.8 +ip4:1.2.3.4 ~all"
cpcontacts 14400 IN A 1.2.3.4
webdisk 14400 IN A 1.2.3.4
autodiscover 14400 IN A 1.2.3.4
cpcalendars 14400 IN A 1.2.3.4
autoconfig 14400 IN A 1.2.3.4
cpanel 14400 IN A 1.2.3.4
webmail 14400 IN A 1.2.3.4
whm 14400 IN A 1.2.3.4Are there any specific steps I need to take in order to see this issue?
0 -
Here is a more detailed example:
server1.exemple.tld and server2.exemple.tld are in the same DNS cluster.
Domain: shopify-site.tld
Dedicated IP: 33.33.33.33
User: shopifysiteAuthentication Method: SSH Public Key
Source: “server1.exemple.tld” version “110.0.91” …
Target: “server2.exemple.tld” version “134.0.11” …
Live Transfer - Off
Dedicated IP - OffI transfer the account, remove the ip 33.33.33.33 from server1.exemple.tld, add 33.33.33.33 to server2.exemple.tld then i set the ip on the account:
whmapi1 setsiteip ip=33.33.33.33 user=shopifysite11.11.11.11 is a shared ip that is set by the Transfer Tool during the transfer.
22.22.22.22 is the custom ip used for shopify-site.tld A record.
33.33.33.33 is the dedicated ip used by this account shopifysite.
If we use Change Site’s IP Address:
The remote dns zone is not consistent with the httpd.conf.
The current ip in httpd.conf is: 11.11.11.11.
The current ip in the dns zone is: 22.22.22.22!22.22.22.22 will be switched to the new ip as well!The local dns zone is not consistent with the httpd.conf.
The current ip in httpd.conf is: 11.11.11.11.
The current ip in the dns zone is: 22.22.22.22!22.22.22.22 will be switched to the new ip as well!Warning, serious database inconsistency. httpd.conf, local dns, and remote dns all
have different ideas about what the ip address of this site really is. They will now all be changed
to the new ip: 33.33.33.33!Changed all instances of [22.22.22.22,11.11.11.11] -> [33.33.33.33] in shopify-site.tld
The system updated “8” entries.
Updating httpd.conf....Done
System has 0 free ips.0 -
Thanks for the additional details about this issue. This output indicates other issues on the machine as it's odd that all different zones (httpd, local, and remote) would have different IP addresses.
I would recommend creating a ticket so this can be investigated directly in your environment as I'm not able to reproduce the issue on a test server.
0 -
For reference, the case number is CPANEL-43305.
0 -
Were you able to submit a ticket? That case confirms that the DNS record has to specifically point to an external IP address, so my testing may not have caught this specific issue.
0 -
Yes, i did, that is where i got the case number from.
So at least for now there is no resolution.
I hope CPANEL-43305 will be addressed soon.0
Please sign in to leave a comment.
Comments
7 comments