Problems with websites, shows error SORRY, changed ip

[Cloudcity]

Good afternoon, it turns out that I made an IMA of my amazon ec2 instance, and set up a new machine based on that IMA, I pointed out the same elastic IP that I had in the beginning, I managed to enter the WHM panel and each of the cpanels of each domain, the downside is that it shows me the SORRY message, and it doesn't show me the files that I have in the account associated with that domain.

 

[cPRex]

Hey there! In your case, the sorry page means one of two things:

-the IP in the DNS for the domain doesn't match the public IP address
or, possibly more likely with what you've described,
-the private IP no longer matches the configuration

Can you confirm the NAT is using the wrong internal IP address? You can check that with this command:

cat /var/cpanel/cpnat

and that should match the private IP listed in the output of "ip a" on your machine.

 

[Cloudcity]

Hey there! In your case, the sorry page means one of two things:

-the IP in the DNS for the domain doesn't match the public IP address
or, possibly more likely with what you've described,
-the private IP no longer matches the configuration

Can you confirm the NAT is using the wrong internal IP address? You can check that with this command:

cat /var/cpanel/cpnat

and that should match the private IP listed in the output of "ip a" on your machine.

If it is different, how could I change that private IP address?

 

[cPRex]

There isn't an official way to do this, but the following workaround works well. Be careful and perform the steps exactly as outlined, or you can accidentally overwrite your DNS entries.

These steps will let you use the IP Migration Wizard to update all domains on a server to use the correct internal IP for Apache while keeping the correct external IP in the DNS to allow domains to function as expected.

1. Run IP Migration Wizard
2. Use the internal IP in the "new IPs" box
3. Click Continue
4. Confirm that "Old IP" is the incorrect external IP that Apache is configured for, and that "New IP" is the correct internal one it should be using
5. Click Continue
6. Click Continue on the "modify your servers’ configuration files" page
7. The wizard should now have output that the Apache and cPanel config files were updated correctly, however DO NOT click continue on this page as it will modify the DNS if you do.
8. Since the cPanel configuration is now correct, we can rebuild Apache with /scripts/rebuildhttpdconf to use the internal IP in Apache
9. Now we need to abort the IP Migration Wizard as it will otherwise try to continue from where you left off
10. To fully abort, ensure the following files are removed from the system (they may not all be present, which is fine):

• /var/cpanel/ipmigrate
• /var/cpanel/useripmigratemap
• /var/cpanel/ipmigscript
• /var/cpanel/ipmigratelock
• /var/cpanel/postipmigrate
  

 

[Cloudcity]

Hey there! In your case, the sorry page means one of two things:

-the IP in the DNS for the domain doesn't match the public IP address
or, possibly more likely with what you've described,
-the private IP no longer matches the configuration

Can you confirm the NAT is using the wrong internal IP address? You can check that with this command:

cat /var/cpanel/cpnat

and that should match the private IP listed in the output of "ip a" on your machine.

There isn't an official way to do this, but the following workaround works well. Be careful and perform the steps exactly as outlined, or you can accidentally overwrite your DNS entries.

These steps will let you use the IP Migration Wizard to update all domains on a server to use the correct internal IP for Apache while keeping the correct external IP in the DNS to allow domains to function as expected.

1. Run IP Migration Wizard
2. Use the internal IP in the "new IPs" box
3. Click Continue
4. Confirm that "Old IP" is the incorrect external IP that Apache is configured for, and that "New IP" is the correct internal one it should be using
5. Click Continue
6. Click Continue on the "modify your servers’ configuration files" page
7. The wizard should now have output that the Apache and cPanel config files were updated correctly, however DO NOT click continue on this page as it will modify the DNS if you do.
8. Since the cPanel configuration is now correct, we can rebuild Apache with /scripts/rebuildhttpdconf to use the internal IP in Apache
9. Now we need to abort the IP Migration Wizard as it will otherwise try to continue from where you left off
10. To fully abort, ensure the following files are removed from the system (they may not all be present, which is fine):

• /var/cpanel/ipmigrate
• /var/cpanel/useripmigratemap
• /var/cpanel/ipmigscript
• /var/cpanel/ipmigratelock
• /var/cpanel/postipmigrate
  

I finish making the change of the private ip with the following command "/scripts/build_cpnat" and it worked, but now I try to access the whm port and it tells me that the host is not getting it turns out that the host changed.

 

[cPRex]

I'm not sure I understand the last reply about the host part. Can you let me know what problem you're seeing with the WHM access now?

 

[Cloudcity]

I'm not sure I understand the last reply about the host part. Can you let me know what problem you're seeing with the WHM access now?

I can already log in, but I still can't access the accounts for their domains, however I can't access their cpanel.

 

[Cloudcity]

I'm not sure I understand the last reply about the host part. Can you let me know what problem you're seeing with the WHM access now?

Also apply the solution you mentioned above, but the domains still do not work

 

[cPRex]

As long as the private IP is still configured wrong, which it likely is based on how you described the server, I wouldn't expect the sites to work properly even if the build_cpnat script worked.

If you've tried the work I posted above and things are still not working well, could you submit a ticket to our team so we can check the system? Just make sure to share the ticket number here so I can follow along.

 

[Cloudcity]

Hello, I was able to solve with your previous contribution, it turned out that I had to wait a bit and the domains began to work, but only one was the one that did not want to work and is throwing me the following message: took too long to respond .

Could you guide me please.

 

[cPRex]

I see a page on my end for that site, so I'm wondering if you're just getting the old DNS information at your location still. You can test this with a proxy browser here:

The Fastest Free Proxy

Easily access blocked content and websites with our FREE web proxy. Hide your real IP address and encrypt your internet connection to protect your privacy.

hide.me

 

[Cloudcity]

Hello, I was able to solve with your previous contribution, it turned out that I had to wait a bit and the domains began to work, but only one was the one that did not want to work and is throwing me the following message: took too long to respond .

Could you guide me please.

I already tried deleting the website and creating it again, with a single index.html file but still showing the same message

 

[Cloudcity]

I see a page on my end for that site, so I'm wondering if you're just getting the old DNS information at your location still. You can test this with a proxy browser here:

The Fastest Free Proxy

Easily access blocked content and websites with our FREE web proxy. Hide your real IP address and encrypt your internet connection to protect your privacy.

hide.me

I understand ... is it cache? or that it has not spread, right?

 

[Cloudcity]

It seems strange to me since the names server are still the same.

 

[cPRex]

If the IP address changed it would still need to go through DNS propagation, which can take some time. Typically this is less than 24 hours, but since you are seeing this working through the proxy browser that would indicate things are working well both in the DNS configuration and the server, but the DNS update just hasn't reached your particular location yet.

 

[Cloudcity]

If the IP address changed it would still need to go through DNS propagation, which can take some time. Typically this is less than 24 hours, but since you are seeing this working through the proxy browser that would indicate things are working well both in the DNS configuration and the server, but the DNS update just hasn't reached your particular location yet.

Hello again, I appreciate your attention, I understand if the IP changes, we have to wait, but the IP does not change, let me explain, the server's IP is an Amazon ec2 IP, it is an elastic IP, it never changes, is that the same ip, or do you mean to change the private ip?

 

[cPRex]

If the public IP on the internet for the domain did not change, I wouldn't expect there to be a propagation period.

I'm wondering if there is just bad data on your local network. Could you try a different device from the same location like a phone or tablet to see if that also experiences the same issue?

 

[Cloudcity]

If the public IP on the internet for the domain did not change, I wouldn't expect there to be a propagation period.

I'm wondering if there is just bad data on your local network. Could you try a different device from the same location like a phone or tablet to see if that also experiences the same issue?

If the same problems arise from other devices, even on devices outside the work network.

 

[Cloudcity]

Can I pass the credentials through the ticket? so that they can enter the whm panel and collaborate with me.

 

[cPRex]

It might be best to submit a ticket so we can examine the server settings on our end directly. If you do that, please post the ticket number here so I can keep this page updated with our findings.