etcnet-0.9.7-alt0.M41.1

I suggest a mechanism that could be described as iftab.d/.

Each iftab.d/ (for each "network profile") would contain files whose name would correspond to the target name of the iface and whose content would be the description of the device according to iftab's syntax.

Using the target names as the filenames would save us from name clashes.

Why this can be useful?

The problem:

One has a certain number of physical network devices (say, DEV1, DEV2). And one would use them with different configurations in different situations, say, Conf1_for_DEV1, Conf2_for_DEV1, Conf1_for_DEV2, Conf2_for_DEV2 (these are notation for the abstract notions of 4 different configurations; in etcnet they can be implemented by different means).

And then one would want to combine the configurations of the devices into network "profiles" (in the terminology of etcnet).

Say, Profile1 is Conf1_for_DEV1+Conf1_for_DEV2, and Profile2 is Conf2_for_DEV1+Conf1_for_DEV2.

Possible solutions:

There are several ways to implement this in etcnet.

One way is to define
ifaces/DEV1#Profile1/ to represent  Conf1_for_DEV1,
ifaces/DEV2#Profile1/ to represent  Conf1_for_DEV2;
ifaces/DEV1#Profile2/ to represent  Conf2_for_DEV1,
ifaces/DEV2#Profile2/ to represent  Conf1_for_DEV2;
and so on for more profiles if needed.

I abandoned this approach in favor of another, because in that second approach the contents of ifaces/ looked cleaner, and each configuration had its own iface name, which might look nicer (various network tools would understand which configuration is actives: ifconfig, routing/firewall configuration, etc.)

The second approach:

to define the configurations under their logical names (not physical interface names):
ifaces/Conf1_for_DEV1
ifaces/Conf2_for_DEV1
ifaces/Conf1_for_DEV2
(then the contents of ifaces/ is cleaner: there are less elements)
and to define the wanted combinations of configurations by means of iftab: say, iftab#Profile1 renames DEV1 (described by means of descriptors) to Conf1_for_DEV1 and DEV2 to Conf1_for_DEV2, and iftab#Profile2 renames DEV1 to Conf2_for_DEV1 and DEV2 to Conf1_for_DEV2.

The use of iftab.d/:

Managing such iftabs would be even easier, if there was something like iftab.d. Then there would simply be a base directory of available physical devices:

available-devices/DEV1 would match DEV1 according to iftab's descriptor rules,
available-devices/DEV2 would match DEV2 according to iftab's descriptor rules;

and then one would simply create iftab.d#Profile{1,2}/ with the wanted names and symlinks:

iftab.d#Profile1/Conf1_for_DEV1 -> ../available-devices/DEV1
iftab.d#Profile1/Conf1_for_DEV2 -> ../available-devices/DEV2

iftab.d#Profile2/Conf2_for_DEV1 -> ../available-devices/DEV1
iftab.d#Profile2/Conf1_for_DEV2 -> ../available-devices/DEV2
.

(A third approach could be to get rid of profiles represented by files at all, and to use a VCS like Git to manage the profiles: a profile would be represented by a branch. Then managing profiles would even be cleaner, but this requires patching etcnet to interpret profiles through Git.)