Transfers failing for DNS issue

This is happening for most accounts, It’s stage 0, I reset the DNS zone to default and it still fails.
Why does it fail doing a replace when nothing is changing?

NOTICE: dns_modify_record failed... retrying...
NOTICE: dns_modify_record failed... retrying...
NOTICE: dns_modify_record failed... retrying...
NOTICE: dns_modify_record failed... retrying...
FAILURE: dns_modify_record
Failed to update record 'mail' on zone 'customerdomain.com' (old - rr: 'A', param: '158.69.155.0'; new - name: 'mail' rr: 'A', param: '158.69.155.0'): Duplicate RRset mail.customerdomain.com. IN A with changetype: REPLACE 
Line 71 
#0 /usr/local/apnscp/lib/Util/API.php(71): SoapClient->__call('dns_modify_reco...', Array)
#1 /usr/local/apnscp/lib/CLI/Transfer.php(243): Util_API->__call('dns_modify_reco...', Array)
#2 /usr/local/apnscp/lib/CLI/Transfer.php(1915): CLI_Transfer->_sync('remote', 'dns_modify_reco...', 'customerdomain.com', 'mail', 'A', '158.69.155.0', Array)
#3 /usr/local/apnscp/lib/CLI/Transfer.php(1850): CLI_Transfer->alter_ip('customerdomain.com', '158.69.155.0', '158.69.155.0', 5)
#4 /usr/local/apnscp/lib/CLI/Transfer.php(200): CLI_Transfer->_sync_update_stage()
#5 /usr/local/apnscp/bin/scripts/transfersite.php(231): CLI_Transfer->process()
#6 {main}
ERROR  : unknown(): migration failed - unhandled exception
         0. Error_Reporter::add_error("migration failed - unhandled exception", )
            [/usr/local/apnscp/lib/log_wrapper.php:72]
         1. error("migration failed - unhandled exception")
            [/usr/local/apnscp/bin/scripts/transfersite.php:245]
unknown(): migration failed - unhandled exception```

Also, why is it trying to alter the IP from the source IP to the source IP in Stage 0?

1 Like

Even better, reloading the zone and it shows this. Apparently it’s changing the IP in Stage 0 to the new IP but it’s not replacing, it’s creating a new record altogether.

I’m not able to reproduce this issue.

Server A:

  • Default DNS provider, powerdns.
  • PowerDNS API refers to self.
  • Source IP: 192.168.0.147 (ipinfo,nbaddrs)

Server B:

  • Default DNS provider, powerdns.
  • PowerDNS API refers to server A (config/auth.yaml)
  • Source IP: 192.168.0.26 (ipinfo,nbaddrs)

Migration invoked as: ./transfersite.php -s 192.168.0.26 -c siteinfo,plan=None dns-test1.com

see migration-log.zip (2.3 KB)

After initial stage completes, a subsequent migration job is backgrounded to start 24 hours after this. Once this is done, the DNS is updated to the new server.

$ at -l
25216   Wed Jul 10 15:04:00 2024 a root

$ at -c 25216
#!/bin/sh
**snip**

/usr/local/apnscp/bin/php-bins/apnscp_php ./transfersite.php site2

If transfersite.php is re-run with --force or within ~23 hours of initial completion, without setting --stage=0, then it’s assumed to begin on stage 1. Stage 0 is initial creation/migration DNS priming. Stage 1 is follow-up migration, which updates DNS. Stage 2 is completed.

Likewise DNS for both the primary domain and addon domain look as expected. It’s important to note [dns] => uuid must be unique between servers. This is used to determine where a domain is presently located. It can be verified with cpcmd scope:get cp.config dns uuid.

Further, finalizing migration with ./transfersite.php site2 --force updates the IP addresses correctly without adding duplicate records. Make sure you’re using the latest PowerDNS driver and not a fork.


1 Like

It happened on two servers, not saying I didn’t screw something up but seems odd since I’ve done this a dozen times before.

Let’s say I start a migration and things start going wrong, how can I reset things like I never started it?

Delete the domain on the target server. Re-run ./transfersite.php -s NEW-SERVER-NAME --stage=0 DOMAIN .

Before you do this, regenerate the UUID value on target server; this is used to determine which server is active for a given domain.

cpcmd scope:set cp.config dns uuid null
upcp -sb apnscp/bootstrap

I believe you copied config/custom/config.ini to the new server to preserve customizations, which includes the UUID. Transfer replays all API calls during both stages, so this includes deleting then recreating the domain. If the UUID value matches the target server, then DNS is removed for this domain upon deletion.

I don’t copy the config file, all customizations are done via commands and the UUID on both servers is for sure different. Even that one account, when deleted from the new server preserves the DNS because the UUID matches the old server.

change_dns.php will reset all records to the old IP. Run this on source. Additionally, there’s a no-op check with DNS updates in edge now that will prevent attempting to update an IP if old is new.

Hop on edge until the next release on the source server:

cpcmd scope:set cp.update-policy edge-major
upcp
1 Like

That may have fixed it, I was able to success a stage 0 migration.

Just FYI, this did come up in case you want to fix it.

DEPRECATED: Implicit conversion from float 2.3121861179669696 to int loses precision 
[/usr/local/apnscp/lib/CLI/Transfer.php:226]

And on line 231.

/usr/local/apnscp/bin/scripts/transfersite.php --all --stage=0 --server=NEW_SERVER isn’t respecting the stage. Any account that has been deleted on the new server is still trying to do Stage 1. Is this a conflict with --all and --stage=0? do I need to do a loop instead?

Confirmed, if I rerun and specify the domain / site instead of using --all, it respects the stage and starts at 0.

Thanks for the report. Fixed in edge. :+1:

1 Like

One last thing… When doing --all, when it sends a failure email, it appends the previous failure and doesn’t reset and only send the failure for the relevant domain.

#1de3718 clears log buffer between runs now.