SYSTEM WARNING: 'date_default_timezone_get(): It is not safe to rely on the system's timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected the timezone 'UTC' for now, but please set date.timezone to select your timezone.' in '/usr/share/mantis/www/core.php' line 264
|Anonymous | Login||2020-02-23 22:14 UTC|
|Main | My View | View Issues | Change Log | Roadmap|
|View Issue Details|
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0003311||Endian Firewall||Migration||public||2010-11-18 23:08||2012-03-02 08:33|
|Target Version||Fixed in Version|
|Summary||0003311: Restore backup on different hardware leaves the firewall unusable|
|Description||When 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 Information||I 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
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:
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.
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.
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.
3com nic --> eth0
Intel nic --> eth1
3com nic --> eth2
Intel nic --> eth0
When restoring a 2.4 backup to 2.4.1 the result is :
3com nic --> eth3
Intel nic --> eth2
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 ?
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:
# Generated by ethconfig
# Generated by ethconfig
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.
from my experience not only +1, but + n, where n is the number of the interfaces defined -1 .
Hope it helps :)
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)
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.
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 :)
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.
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.
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.
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.
|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.|
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.
Tried and tested gmar_87's solution and it was straightforward.
Probably easiest to exclude the businfotab file from backup.
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.
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
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...
|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|
|Copyright © 2000 - 2012 MantisBT Group|