Migration Notes

[johnjore]

Some notes regarding my migration from eFa 4 to 5

My old eFa:

rpm -q eFa
eFa-4.0.3-11.eFa.el8.noarch

SQL:
mailscanner mtalog was missing the to_address column after restore. Suspect some eFa upgrade added it at some point?
creates.sql in eFa5 does not appear to have to_address defined, so not sure where it came from, as there are multiple config/init scripts. The missing column causes postfix_relay to crash.

v4 Prep:
eFa-Backup -backup should be eFa-Backup-Cron (or maybe my eFa4 is old?)
systemctl disable postfix does not work, so be careful as a reboot will cause postfix to start running again

MailScanner.conf:
As I didnt use /etc/MailScanner/conf.d/, I ended up manually copying over my custom settings from MailScanner.conf

virus.scanners.conf:
clamav should be clamd in line 22?
MailScanner[52133]: Virus scanner "clamd" not found in virus.scanners.conf file. Please check your spelling in "Virus Scanners =" line of MailScanner.conf

Missing as I was restoring from eFa 4.0.3:

# Add DB_PORT to conf.php
if [[ -z $(grep DB_PORT /var/www/html/mailscanner/conf.php) ]]; then
  sed -i "/^define('DB_NAME'/ a\define('DB_PORT', '3306');" /var/www/html/mailscanner/conf.php
  sed -i "/^define('DB_DSN'/ c\define('DB_DSN', DB_TYPE . '://' . DB_USER . ':' . DB_PASS . '@' . DB_HOST . ':' . DB_PORT . '/' . DB_NAME);" /var/www/html/mailscanner/conf.php
fi

During restore:

/bin/cp: cannot stat '/var/eFa/backup/backup/etc/opendmarc.conf': No such file or directory
/bin/cp: cannot stat '/var/eFa/backup/backup/etc/opendmarc/*': No such file or directory

Not sure what this is is an error during backup, restore or normal

There is something odd with MailScanner as the restore does not appear to take something into account, causing php crashes/issues?!?. Creating new issue for that

Happy Migrations! I'll update as/when needed, but maybe close this if its not really adding anything of value, or update FAQ/Migration doc with anything worthwhile.

[shawniverson]

A majority of these issues I came from updating from an outdated v4 appliance. I have made corrections to the documentation to include updates to the applicance. I also corrected eFa-Backup with eFa-Backup-cron.

[johnjore]

Upgraded my old appliance to 4.0.4-43 and did a new backup / restore.

Looks like it was more successful this time as it blew away my shiny new fstab file with the source one! 😭
The UUID's and LVM names did not match up as its a new install of RHEL 😁. Take a backup of the fstab file on the target computer before the restore begins and restore it, before rebooting. Maybe take a snapshot / backup of the VM itself, just in-case there are other files needed if its fresh install.

The missing column in the database is not on the source device, but appears to be created during restore, think I saw a line item while it was doing its thing, so anyone upgrading and not finding it on the old V4, this might be normal.

My guess is that the restore from 4.0.3 crashed with a partial restore, which is why my fstab was not overwritten, but a bunch of other settings did come across and my 2nd attempt at a restore from a 4.0.4 backup was much more successful.

[shawniverson]

@johnjore When you ran your second backup/restore, did you reuse the same v5 appliance? If so, that is why your /etc/fstab was overwritten as the restore didn't detect that the backup was from the other appliance. I'll see if I can improve this logic.

[johnjore]

Yes, same appliance as before. Some extra logic would probably be good as there are no warnings etc, and the restore happily goes ahead.