0003311: Restore backup on different hardware leaves the firewall unusable

Notes
(0005186) peter-endian (administrator) 2010-11-23 13:53	we added a fix for this on 2.4.1 did you try it with a 2.4.1? on 2.4 try removing these files: rm /usr/lib/write_net_rules rm /etc/udev/rules.d/70-persistent-net.rules which are udev rules which bind the mac addresses of your interfaces to an interface name. if you restore on a different hardware, there are different mac addresses so the interface names will be renamed.

(0005188) baldy (reporter) 2010-11-23 17:32	Hi Peter, Backup was created on 2.4 and restored on clean install of 2.4.1. Will try to test this later on with two 2.4.1 machines. The amavis issue is not related to the restore. I have already opened another bug for that.

(0005213) baldy (reporter) 2010-11-25 22:19	hi Peter, Just tested the following : Installed a 2.4 test system, configured it and upgraded via efw-upgrade to 2.4.1. Got a backup from another upgraded 2.4.1 machine and restored it on the test system. It did somewhat work, but not as expected. After restore only eth0 was available, and it was using the interface that was eth1 before the restore. eth1 no longer exists, eth2 however does. So there is still something wrong with the restore. To clarify, Before install 3com nic --> eth0 Intel nic --> eth1 After restore 3com nic --> eth2 Intel nic --> eth0 When restoring a 2.4 backup to 2.4.1 the result is : After restore 3com nic --> eth3 Intel nic --> eth2

(0005457) baldy (reporter) 2011-01-07 23:15	Hi Peter, Did some thinking on the issue. Backup should, imho, not include any hardware information on the network adapters. It should be enough just to know how each device is configured. What i mean is that when creating a backup it should include info such as the IP config of eth1 for example, but not the hardware info like mac address and such. When restoring on new hardware the base setup has already configured the hardware for eth1 so only the IP config should be restored. In that way it should be possible to create a backup that will always work on new hardware. What do you think of this approach ? Regards, Baldy

(0005535) ardit-endian (developer) 2011-01-27 15:32 edited on: 2011-01-27 15:36	I had a similar issue in a system and the problem is that the file /etc/businfotab is changed for some reason and the settings becomes +1 like: before restore: ------------------ # Generated by ethconfig eth0 01:04.0 eth1 01:05.0 eth2 01:06.0 eth3 01:07.0 after restore ------------------- # Generated by ethconfig eth1 01:04.0 eth2 01:05.0 eth3 01:06.0 eth4 01:07.0 Normally an ethconfig -a should apply the right configuration after we edit manually the file but the cause to this is still unknown to me. The file bussinfotab-appliance.default is ignored after the backup restore. If in the restore script we would include a simple cat bussinfotab-appliance.default > bussinfotab I think shit would get this issue solved.

(0005536) lorenzo-endian (manager) 2011-01-27 15:35	Hi ardit, from my experience not only +1, but + n, where n is the number of the interfaces defined -1 . Hope it helps :) Lo

(0005538) ardit-endian (developer) 2011-01-27 15:38	I found this only in one mini, maybe it is related to the appliance. I edited my previous comment , maybe the last lines would be the solution to it. Maybe it is the solution :/ (hope so)

(0005541) lorenzo-endian (manager) 2011-01-27 15:50	I think this is not a good solution because in this way the configuration is set as default, and this can be a problem... BTW, I have to check if some problems arises using this solution.

(0005543) ardit-endian (developer) 2011-01-27 16:02	Normally the user doesn't tend to modify the name of the interfaces, if we check a number of firewalls in this moment they all have their interfaces beginning from eth0 , and this have no impact in the network configuration, because eth0 will be always associated to br0 , if the user change his mind and change the association on /efw/ than associates eth0 with br1, eth0 will be always there ready to serve :) Thank you, Ardit.

(0005544) baldy (reporter) 2011-01-27 18:38	Hi Ardit, Why does the businfo need to be restored ? Especially on the CE version busses may be different with new hardware. As this file is created with any new install, the file could be left alone and not be backupped/restored. Regards, baldy

(0005562) peter-endian (administrator) 2011-01-31 15:33	Hi baldy Immagine a custom hardware where you remove a pci card and add another one on another slot. Then you don't want the interfaces to be changed according order of precedence, you want to have the names stick and the removed nic to be inexistent and the added one with a new unused name. If you have such a situation, you want this on the backup and to reappear so after restore. Software editions should memorise the nic-name 2 pci association after 1st boot, while hardware editions have this association packaged. Something is going wrong here, since nic names should not be recalculated if all the pci id's exist in system and also in businfo tab file.

(0005640) peter-endian (administrator) 2011-02-08 12:23	ok, it is more clear now. it is not enough that pci-ids exist in the system, they also need to have the same order of precedence and thus the same pci-id <-> nicname association in order not to be recalculated. a backup which holds a businfotab file, which has a pci-id<->nicname association which is not the same as in the hardware where we restore causes a recalculation. it is unlikely that 2 different hardware have the same pci-id in the same order of precedence, so this is kind of normal, that recalculation takes place. best would be not to restore the businfotab file when hardware changes. i think we should provide a checkbox for this event.

(0006153) baldy (reporter) 2011-04-27 14:19	Hi Peter, Regarding changing NIC's, pfSense has a mechanism which, during startup, checks NIC's and if anything has changed a wizard starts to configure the NIC's. Might be worth to look at. Regards, Baldy.

(0007181) gmar_87 (reporter) 2011-07-30 06:18	A simple work around for this is to add etc/businfotab to /var/efw/backup/exclude.system before making a backup. I did this on 2.4.1 production server and restored config to a VMware virtual machine and it worked.

(0007630) yokomaka (reporter) 2012-01-16 16:02	The workaround from gmar_87 also worked for moving an endian 2.4.1 installation to new hardware on endian 2.5. Instead of adding etc/businfotab to the exclude.system file one of course might also just delete the file etc/businfotab from the backup....tar.gz file.

(0007631) baldy (reporter) 2012-01-16 16:22	Tried and tested gmar_87's solution and it was straightforward. Probably easiest to exclude the businfotab file from backup. Regards, Baldy

(0007739) fqureshi (reporter) 2012-03-02 08:33 edited on: 2012-03-02 08:41	I have followed the instructions by gmar_87 and yokomaka. I tried to untar the backup file, done the modification that is deleting the etc/businfotab and re-tar it. But when I tried to import the modified backup file, the firewall rejected the file. I then used the unmodified tar file. Restored on the new machine but as mentioned earlier I lost the access to the firewall. I then access the firewall through shell and deleted the etc/businfotab and rebooted the firewall. on shell: press "0" to access shell type login and hit enter You will be asked to provide password if you have setup one or the password of your old firewall from which you have acquired the backup tar file Remove the businfotab under etc directory cd /etc rm businfotab shutdown -r now and hit enter (will reboot the firewall) After a reboot, it has taken the correct interfaces and now I am able to access the firewall. All configuration is there. I haven't tested the system yet in running environment but thoroughly examined the config and it seems as the replica of the current firewall. Hope this is helpful to some other users who are trying to modify the tar file...

Issue History
Date Modified	Username	Field	Change
2010-11-18 23:08	baldy	New Issue
2010-11-22 10:02	lorenzo-endian	Assigned To	=> lorenzo-endian
2010-11-22 10:02	lorenzo-endian	Status	new => acknowledged
2010-11-23 06:37	lorenzo-endian	Status	acknowledged => new
2010-11-23 06:37	lorenzo-endian	Assigned To	lorenzo-endian => peter-endian
2010-11-23 13:41	peter-endian	Status	new => acknowledged
2010-11-23 13:53	peter-endian	Note Added: 0005186
2010-11-23 13:54	peter-endian	Status	acknowledged => feedback
2010-11-23 17:32	baldy	Note Added: 0005188
2010-11-25 22:19	baldy	Note Added: 0005213
2011-01-03 09:58	lorenzo-endian	Relationship added	has duplicate 0003359
2011-01-07 23:15	baldy	Note Added: 0005457
2011-01-25 17:43	ra-endian	Status	feedback => new
2011-01-25 17:43	ra-endian	Assigned To	peter-endian => lorenzo-endian
2011-01-25 17:44	ra-endian	Customer Occurencies	=> 0
2011-01-25 17:44	ra-endian	Status	new => acknowledged
2011-01-26 16:43	lorenzo-endian	Assigned To	lorenzo-endian => peter-endian
2011-01-26 16:43	lorenzo-endian	Status	acknowledged => confirmed
2011-01-27 15:32	ardit-endian	Note Added: 0005535
2011-01-27 15:33	ardit-endian	Customer Occurencies	0 => 1
2011-01-27 15:33	ardit-endian	Tag Attached: purple
2011-01-27 15:35	lorenzo-endian	Note Added: 0005536
2011-01-27 15:36	ardit-endian	Note Edited: 0005535
2011-01-27 15:38	ardit-endian	Note Added: 0005538
2011-01-27 15:50	lorenzo-endian	Note Added: 0005541
2011-01-27 16:02	ardit-endian	Note Added: 0005543
2011-01-27 18:38	baldy	Note Added: 0005544
2011-01-31 15:33	peter-endian	Note Added: 0005562
2011-02-08 12:23	peter-endian	Note Added: 0005640
2011-04-27 14:19	baldy	Note Added: 0006153
2011-07-30 06:18	gmar_87	Note Added: 0007181
2012-01-16 16:02	yokomaka	Note Added: 0007630
2012-01-16 16:22	baldy	Note Added: 0007631
2012-03-02 08:33	fqureshi	Note Added: 0007739
2012-03-02 08:41	fqureshi	Note Edited: 0007739

Please see now our new Bugtracker system: JIRA