[CPANEL-29524] Change Site IP overwrites externally pointed records in zone files
It looks like there has been a change to the way the "Change Site's IP Address" works. This causes the IP's of domains to be changed when they have been previously set to an IP external to the server. This is completely illogical.
What makes this worse is that the domains within an account that are set externally are not listed in the output of this script so you can't identify them to change them back again!
I've just set an account's IP back to the server's main IP when it was previously set to a dedicated IP. The account had 47 addon domains.
When you run the script, it says the following...
[quote]
The remote dns zone is not consistent with the httpd.conf.
The current ip in httpd.conf is: "server IP".
The current ip in the dns zone is: "external IP"!
"external IP" 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: "server IP".
The current ip in the dns zone is: "external IP"!
"external IP" 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: "main server IP!
This is really stupid! Firstly, It doesn't specify which domains it has identified this "inconsistency" for. So out of 47 domains, I have no idea which one was set to an external IP. Totally dumb. More importantly, there is no prompt to ask if I want to make this change, or keep the external IP set. It stands to reason, that you would generally only want to change the IP in zones from one server IP to another server IP - not from an external IP to a server IP. If the client has changed the IP on a domain to one outside the server, the default behaviour should be to IGNORE it - not to change it anyway! The logic of this script is backwards. At the very least, the domain name in question should be identified and displayed when the script informs you of the "inconsistency" - so it can be changed back. The current behaviour makes it impossible to identify which domains may need attention. Ideally, in the event of an inconsistency, you should be prompted with an option to change it or not - but logically, the default behaviour should be to NOT change the IP on a domain that has an A record external to the server rather than to force it to the new server IP. Now I have to contact this client to apologise, after at least one of his websites that I can't identify, now has an incorrectly set IP.
This is really stupid! Firstly, It doesn't specify which domains it has identified this "inconsistency" for. So out of 47 domains, I have no idea which one was set to an external IP. Totally dumb. More importantly, there is no prompt to ask if I want to make this change, or keep the external IP set. It stands to reason, that you would generally only want to change the IP in zones from one server IP to another server IP - not from an external IP to a server IP. If the client has changed the IP on a domain to one outside the server, the default behaviour should be to IGNORE it - not to change it anyway! The logic of this script is backwards. At the very least, the domain name in question should be identified and displayed when the script informs you of the "inconsistency" - so it can be changed back. The current behaviour makes it impossible to identify which domains may need attention. Ideally, in the event of an inconsistency, you should be prompted with an option to change it or not - but logically, the default behaviour should be to NOT change the IP on a domain that has an A record external to the server rather than to force it to the new server IP. Now I have to contact this client to apologise, after at least one of his websites that I can't identify, now has an incorrectly set IP.
-
Hi, Which version of cPanel & WHM did you observe this behavior in? 0 -
Hi, the sever is running v68.0.30 0 -
Hi @4u123, This is partly related to the internal case referenced on the following post: In that thread, similar behavior is noted when using the "Express Transfer" feature with "WHM >> Transfer Tool". There's also a feature request open for the ability to retain custom DNS records during account transfers: As far as the "Change A Site's IP Address" feature, you noted this is a change to how it worked in the past. Do you happen to know the last version where this worked as intended? Thank you. 0 -
Hi @4u123, This is partly related to the internal case referenced on the following post: > Transfer Tool". There's also a feature request open for the ability to retain custom DNS records during account transfers:
I'd say in the past, if the IP address was not the same as an IP on the server, this tool would ignore it. The idea of it has always been to change instances of the old server IP to the new server IP, without affecting any other records. We don't have cause to use this tool very often, so I don't know how long this new functionality has been in place, but it's most definitely the incorrect way to go about it and the problem is made much worse by the fact that any domains that show an "inconsistency" are not listed, so it's impossible to rectify any issues afterwards. It's a double f*ck up! Whoever re-wrote this script is making the incorrect assumption that you want to change the IP of every site in an account to the IP you select. That is not the purpose of this tool. Obviously a client might have multiple domains added as addons and aliases and they might wish to use the cpanel server for Email, but set the A records on any of their domains external IP's, or for any reason. They might simply want to add the domain to cpanel just so they can manage the DNS records and never have the intention of setting the A records on a domain to any IP on that server. That's completely reasonable. Unfortunately, this tool wipes out all those changes in one go. These are not "custom" DNS records and you need to get away from considering them as such. Every DNS record is editable and there should be no assumption that such records should conform to any structure at all. These are not customisations. A user can set any IP they want on a domain. The Change Site's IP address tool is meant to be used to change instances of server IP1 to server IP2 and nothing in between. That's why it was set up originally, but at some point you've modified this functionality deliberately and inappropriately to consider any IP that is the main A record for a domain, that differs from that in the Apache configuration, needs changing to the new IP. So the consideration of the httpd.conf would seem to be the new factor here. The logic is totally wrong.0 -
Hello @4u123, We do offer the "IP Migration Wizard" feature in WHM as an alternative method to change the account's IP address. Upon testing, it appears this feature includes the functionality you are seeking, as it only updates the DNS entries that utilize the original IP address. IP Migration Wizard - Version 70 Documentation - cPanel Documentation Additionally, I do understand your concern with the "Change Site's IP Address" functionality. However, it looks like this behavior dates back to at least cPanel version 11.38. I've opened a feature request on your behalf to see if we can get the functionality updated: Ability to preserve DNS records when changing an account's IP address Thank you. 0 -
The IP migration wizard is used to introduce new IP's to a server. Can you explain how it would be possible to switch an account to use the main server IP using that tool, when the main server IP is already in use on the server?
Hello, 1. Open "WHM >> IP Migration Wizard". 2. Under "Enter the new IPs one per line", enter the main shared IP address, and click "Continue". 3. The next page should present you with a column named "Old IP Address" with a list of other IP addresses currently added to the server as dedicated IP addresses. The "New IP" column is available for you to enter the main shared IP address. Once you do this, the rest of the process is all confirmation pages. The primary issue you might encounter with this method is that it's designed to transfer all domain names associated with one IP address to another. Thus, if you have configured multiple shared IP addresses (e.g. you have more than one account assigned to a dedicated IP address), then it would change all of those accounts to the main shared IP address of the server. If that's the case, then the additional functionality for the "Change Site's IP Address" noted in the feature request would be required. Thank you.0 -
Hello, 1. Open "WHM >> IP Migration Wizard". 2. Under "Enter the new IPs one per line", enter the main shared IP address, and click "Continue". 3. The next page should present you with a column named "Old IP Address" with a list of other IP addresses currently added to the server as dedicated IP addresses. The "New IP" column is available for you to enter the main shared IP address. Once you do this, the rest of the process is all confirmation pages. The primary issue you might encounter with this method is that it's designed to transfer all domain names associated with one IP address to another. Thus, if you have configured multiple shared IP addresses (e.g. you have more than one account assigned to a dedicated IP address), then it would change all of those accounts to the main shared IP address of the server. If that's the case, then the additional functionality for the "Change Site's IP Address" noted in the feature request would be required. Thank you.
I'm not even going to attempt to use that option. That's not what it's for. I see potential issues in adding an IP that is already on the system and I'm not prepared to trust your instructions with a couple of hundred active domains. Fact is, the "change site's IP address" tool was specifically designed for switching accounts between IP's on the server - but it no longer works the way it should. Most hosts charge extra for a dedicated IP on shared hosting servers. Also, historically, accounts with SSL certs previously needed a dedicated IP. Now IP4 addresses are more scarce and we have SNI functionality, it stands to reason that we will want to free up IP's and switch them back to the server's main IP - and of course any client who is paying for a dedicated IP could cancel that at any time. So this tool has always been used for that purpose. To give an account a dedicated IP, or to switch back to the main shared IP. In the past we would use the "change site's IP address" tool to change the dedicated IP back to the main shared IP, or to set up an account with one. When this tool was originally written, a developer with at least half a brain worked out that the client might change the main A records of their domains to external IP's which must not be affected by an account's overall IP change. The requirement is to change instances of the system IP's where they are in use. So changing any other records is strictly out of bounds here. So it is clearly a very specific requirement of this tool - that only instances of the "system" IP's be changed and not any other "external" records that the clients may have set up. This is exactly what the tool is for and it used to work fine before. What it actually does right now, is look at the main A record for any addon domain or parked domain on the account and change that IP to the IP you choose from the list, regardless of whether it is external to the server or not. There is no logic at all to the above behaviour, absolutely none. The chances of a server admin wanting to change every domain's A record within a particular account to a selected system IP on mass, is far far outweighed by the chances of them NOT wanting to do that and instead ONLY wanting to change records containing the IP in question, leaving the external IP's alone. I can only speculate what's happened here is that at some point, a developer has been given the responsibility for maintaining that process but has completely misunderstood it's purpose entirely and they have broken it by making changes based on their own incorrect view of how it should work. If whoever at cpanel responsible for that script doesn't have a clue about how the tool should really work (which would seem to be the case) and if you guys don't think the current functionality is completely flawed, then I'd say there's been a zombie virus outbreak in Houston. FYI I have no interest in your feature request system - it's a complete waste of time. Please don't create feature requests on my behalf, or if you insist on doing that - I don't want to know about it. Thanks.0 -
Hello @4u123, I've also opened a new internal case, CPANEL-19311, to note your concerns about the functionality of this feature. I'll update you with more information on the status of this case as soon as it's available. Thank you. 04-02-2019 Update: CPANEL-19311 was closed due to a lack of new support requests. Please feel free to reply to this thread if this issue continues to present a problem. 0
Please sign in to leave a comment.
Comments
10 comments