Endian Bugtracker
Endian Issue Tracker





Please see now our new Bugtracker system: JIRA








View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0003311Endian FirewallMigrationpublic2010-11-19 00:082012-03-02 09:33
Reporterbaldy 
Assigned Topeter-endian 
PrioritynormalSeverityblockReproducibilityalways
StatusconfirmedResolutionopen 
PlatformOSOS Version
Product Version2.4 
Target VersionFixed in Version 
Summary0003311: Restore backup on different hardware leaves the firewall unusable
DescriptionWhen restoring a backup on different hardware (new machine) the firewall becomes unreachable after reboot. The restore removes the configuration of eth0 and eth1 and creates eth2 and eth3. Due to this the br0 config is messed up as this is normally using eth0, but this can be fixed relatively easy by editing the br0 file in /var/efw/ethernet. In the uplink editor GUI the correct config for the uplink is shown, but not applied to the system. GUI showed the correct networkcard (eth3) and its settings. Using ifconfig eth3 from SSH did not show the ipv4 address as shown in the GUI. I had to use the Network Configuration wizard to re-apply the uplink settings. After that the dashboard stopped working, both IE and Firefox only showed Loading Dashboard, the rest of the GUI did work.
Additional InformationI also noticed that on the GUI status screen the Spam filter for SMTP (amavis) showed stopped. Using the restartsmtpscan.py script and dis/enabling the SMTP proxy form the GUI had no effect. Restartsmtpscan.py did show that amavis was running.

Have not fully tested the system I restored the backup on, so there may be a few other things that do not work properly.

The issue also exists in older versions of EFW Community, but due to the increased configurations of the systems I am only now creating a bug report.
In the past I just manually reconfigured the necessary items.

When restoring a backup from another system it would be preferable to have the configuration for eth0/br0 and eth1 left intact
Tagspurple
Attached Files

- Relationships
has duplicate 0003359closedpeter-endian Cannot restotre backup configuration to new hardware 

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

Copyright © 2005-2008 Endian, SRL. All rights reserved.


Copyright © 2000 - 2012 MantisBT Group
Powered by Mantis Bugtracker