After migration, DNS server does not get pri.* files

Discussion in 'ISPConfig 3 Priority Support' started by Taleman, Apr 7, 2018.

  1. Taleman

    Taleman Well-Known Member HowtoForge Supporter

    Running migration tool 2.0.5, source is multiserver setup Debian Wheezy, Target is multiserver setup Debian Stretch. Both have ISPConfig 3.1.11.
    I have previously run migrate, and am now doing it again and changed name servers to the new ones. But the new name service does not work, since there are no pri.* files in /etc/bind/.
    I figured doing Tools | Resync would solve this, but the Resync tab does not have "DNS records:". I checked from another multiserver ISPConfig 3.1.11 setup, there the Resync does have "DNS records:".
    I have checked the TARGET ISPConfig does have DNS Server ticked in "Server services" for the new name server. Monitor shows all services are running, including DNS server.
    I installed the multiserver setup following ISPConfig 3.1 manual, according to that bind9 is installed only on name server hosts, and not on the web server.
    The new ISPConfig does not show any zones in the DNS tab.
    I have now run the migration tool even on old NS1 name server, but still on TARGET, dbispconfig database contains no rows in dns* tables.

    I read my old question from a previous migration, https://www.howtoforge.com/community/threads/zones-not-transferred-to-ns-servers.77697/#post-367603, but this time I have not transferred the name server data to the wrong server. And the missing DNS Server in Tools | Resync is new this time.
     
  2. Taleman

    Taleman Well-Known Member HowtoForge Supporter

    This is from SOURCE ns1 name server migrate.log:
    Code:
    root@ns1:~/migration# egrep -i "(dns|bind)" migrate.log
    2018-04-07 17:40:29 - [INFO] Found 188 DNS Zone entries.
    2018-04-07 17:40:29 - [INFO] Found 1389 DNS Record entries.
    2018-04-07 17:40:34 - [INFO] After dependency check: 0 DNS Zone entries.
    2018-04-07 17:40:34 - [INFO] After dependency check: 0 DNS Record entries.
    root@ns1:~/migration#
    
     
  3. Taleman

    Taleman Well-Known Member HowtoForge Supporter

    Having experimented somewhat and digging about, I believe the core problem is:
    1. DNS entries are not migrated to TARGET database. The dns* tables in dbipsconfig have no rows, except those that came when I created a test zone on the TARGET.

    I do not know why dns does not get migrated. I tried migrating only that from SOURCE master:
    Code:
    Do you want to migrate only some services or everything?                      
    Valid services are: client, web, mail, ftp, database, cronjob, dns, billing
    Do you want to change the service selection (dns,  billing)? (y, n):
    Should I try to keep the existing IDs for clients, webs etc. (IDs will still change if old ID is taken already)? (y, n):
    Calculating dependencies ...                                                  
    [ERROR] You have provided --exclude or --only options that lead to nothing being migrated.
    
    Same thing happens when run on SOURCE names server ns1. I tried this, but I believe it should not be needed to run migration tool on host that does only name service, the database is on master.
    I have not tested completely the TARGET system, but it does look like all other data is migrated. ISPConfig panel shows websites, FTP-users, e-mail boxes etc..
    I did make some progress, namely now the TARGET Tools Resync does show the "DNS records:" item to resync.
     
  4. till

    till Super Moderator Staff Member ISPConfig Developer

    The migration tool needs to be run on the server that shall be migrated, even if this is just a DNS server. To migrate the DNS records, run the tool on the DNS server too.
     
  5. Taleman

    Taleman Well-Known Member HowtoForge Supporter

    Message #2 is from running on the name server. It looks to me it sent nothing.
     
  6. till

    till Super Moderator Staff Member ISPConfig Developer

    Ahh yes, sorry I missed that bit :) @Croydon is just checking the issue, there might be a problem in the dependency check of the DNS records.
     

Share This Page