#3 Issue closed: Rewrite network configuration abstraction

dagwieers opened issue at 2012-03-21 12:25:

As discussed in rear-users at: http://sourceforge.net/mailarchive/message.php?msg_id=28515321

it would be nice if the network configuration can be instructed at boot-time.

Options could be to:

  • skip network configuration
  • use DHCP
  • use the original configuration.

There's also the possibility:

  • to force network configurations on different hardware (addresses)
  • to detect if any of the given network configurations in fact work on a certain interface (e.g. do an arping to the gateway)
  • to expect the same hardware to be available

As much as possible should work out of the box...

schlomo commented at 2012-03-21 12:32:

+1

Is there any boot command line syntax we should mimic? E.g. from anaconda or other OS installers?

gdha commented at 2012-03-21 13:48:

+1
The "dhcp" and "noip" are already in-place. Partial the code for this is already written and lives at
/usr/share/rear/skel/default/etc/scripts/system-setup.d/20-check-boot-options.sh

However, the script to actually activate the device with this IP address has not yet be written.
Currently, debugging Fedora 17 lvm locking issues ...

dagwieers commented at 2012-03-30 07:25:

The TODO file contained the following related information:

Wait for feedback

  • Write network migration code for all other distributions
    • some work has been done in the meantime, but not sure if it is
      sufficient enough to cover all
    • waiting on customer feedback
  • Support dhcp for network migration
    • has been added in 1.9.0
    • waiting on customer feedback

dagwieers commented at 2012-04-12 13:17:

Implementation needs to address bonding (LACP) and vlan tagging support !

Obviously if it detects known MAC addresses it can assume that it is a restore to the same system and can continue with configuring the network setup exactly as it was. But in case this is not the case, there are a few things it could do (which we can do identically for VLAN tagging). After configuring an interface it could test whether the configuration in fact works (e.g. arping the gateway) if that does not work we have to ask the user to what interface to map.

Obviously with LACP this is not going to be easy, since doing a bruteforce on every combination of interfaces might be problematic (but we could opt to only test/run with a single interface for LACP. But during recovery we don't need HA.

What is needed is similar to what we implemented for the storage layout, i.e. writing out an abstraction of the configuration that is active on the system and then restoring the configuration from that abstract network configuration file. And that network configuration file should have dependencies between "interfaces" as well as support for bonding (LACP or other), VLAN tagging and possible other stuff...

gdha commented at 2014-10-23 06:58:

VLAN tagging has been added in the meantime. The abstraction layer of network interfaces: I'm not convinced it is worth the time spending on it as from experience moving to another HW type will cause many issues anyway...
Changing milestone move from 1.17 to future...

gdha commented at 2015-01-07 12:09:

will close this one and if required (on demand) a new issue can be openend

[Export of Github issue for rear/rear.]