Keys and settings not migrated during server migration

Hi — I recently performed a migration to a new server where I followed your support document at https://www.virtualmin.com/documentation/system/migrate

I migrated from a Debian 8 to Ubuntu 16.04.1 LTS system, which from what I tell, shouldn't be a problem as they're both 'Grade A' supported systems.

I uncovered a few problems during the migration, and perhaps a few suggestions:

  1. In the bind9 settings, allow-transfer and also-notify directives for my domains were not copied to the new server.
  2. dnssec keys from "/var/lib/bind/" were not copied to the new server.
  3. The DKIM selector in "/etc/dkim-keytable" was not updated when generating a new key. (I was trying to troubleshoot the dnssec key problem, and ended up trying to generate new DKIM keys)
  4. fail2ban gives errors for missing log files when activating jails.

client[713]: ERROR No file(s) found for glob /var/log/nginx/access.log
client[713]: ERROR No file(s) found for glob /var/log/roundcube/errors
client[713]: ERROR Failed during configuration: Have not found any log file for roundcube-auth jail

The nginx error is from a filter that attempts to check both the default apache and nginx logs regardless of whether nginx has been installed. The roundcube log file should probably be selected based on where the script installers have installed the webmail system?

  1. When activating fail2ban jails, the filter-dropdown has the "3proxy" filter as the default filter no matter which jail I select. Would it be possible to have the corresponding filter as the default dropdown-selection? It took me a while to troubleshoot this before I realized my error.
  2. The GnuPG key used for encrypted backups was not transferred to the new server. The backup item along with the key continued to be listed in the system on the new server, but the backup would fail on every run due to the missing key. So I'm thinking either Virtualmin should handle copying the key, or should be more informative to the user that scheduled encrypted backup jobs cannot be migrated?

So all in all, the new server is setup and functioning now, but maybe fixes/changes for the above items may help reduce friction for another user.

A final request: Would you consider adding BackBlaze B2 at a cloud backup target? I've found it to be quite reliable and a lot cheaper than Amazon S3.

Best wishes

Status: 
Active

Comments

How did you do the migration - was it by using the Virtualmin domain-level backup and restore feature?

I used the command line examples from the migrations documentation page:

virtualmin backup-domain --dest /root/backups/ --all-domains --all-features --newformat --all-virtualmin
virtualmin restore-domain --source /root/backups/virtualmin.tar.gz --all-virtualmin
virtualmin restore-domain --source /root/backups/ --all-domains --all-features

Ok, it looks like we are missing a few things from the Virtualmin backup.

The next release will include DNSSEC keys, as that bug was reported by another user recently. Regarding allow-transfer and also-notify directives, do you have entries that were manually added outside of Virtualmin?

Nope. Only through the web interface.

(As an aside it seems like you can only add those directives on a domain by domain basis? Or in the new server template. Is there a way (CLI fx) to set them for all current servers? The use case would be a new IP handling AXFR for a hidden primary DNS setup.

The best place to add extra nameservers is at System Settings -> Server Templates -> Default Settings -> BIND DNS Domain -> Additional manually configured nameservers. Any hostnames entered here will get NS records in the domain, and IPs in the allow-transfer / also-notify blocks.

Thanks. Although as I understand it, these settings will only apply to future created domains? I was thinking of a batch edit/add for current servers like when lowering the DNS TTL for all domains in one command.

Yes, they will only apply to future domains - there is no support yet for batch updating existing domains. However, you can safely edit the BIND config file manually, and Virtualmin won't override your changes.