# Network configuraiton management with eselect

## reith

Recently I realized I'm spending unnecessary time to find correct configuration to change wireless mode or chat scripts for different mobile networks and since I really don't know netifrc, It was horrible for me to correct things fast.  I tried to put all configurations commented out in conf.d/net and switch between them easily.  Then I thought It would be nice to have these configurations stored somewhere and make interface to use target configuration when needed.  Fortunately there is eselect tool in Gentoo making this task easy and familiar to Gentoo user.

So, eselect-net is an eselect module to switch between different configurations.  There is a readme (copied bellow) in source control repo explaining all the commands.  You can drop net.eselect to /usr/share/eselect/modules and make /etc/eselect/net/conf.d and /etc/eselect/net/devs to start playing with it.

eselect-net

eselect-net helps to define configuration profiles for netifrc and switch between interface configurations.

Usage

To define a new configuration use make command:

```

   root # eselect net make eth-dhcpcd

```

One can make several configurations.  Let list defined configurations:

```
   root # eselect net list

   Available network configurations:

     [1]   wireless-wpa-supplicant

     [2]   3g-dongle-at

     [3]   3g-dongle-comcast

     [4]   eth-static-ip

     [5]   eth-dhcpcd

     [6]   wireless-ap

```

These configurations are stored in /etc/eselect/net/conf.d.  Let edit eth-dhcpcd configurations:

```

   root # $EDITOR /etc/eselect/net/conf.d/eth-dhcpcd

   # -*- gentoo-conf-d -*- vim: ft=gentoo-conf-d

   #

   # This is a netifrc network configuration.  It will be processed to make config

   # file.  _iface_ in labels is a placeholder for interface, so modules__iface_

   # will be modules_eth0 in produced config file.

   config__iface_="dhcpcd"

   dhcpcd__iface_=( "-S domain_name_servers='8.8.8.8 8.8.4.4'" )

```

Now to configure eth0 by eth-dhcpcd use set command:

```

   root # eselect net set eth0 5

```

It's done by making link /etc/conf.d/net.eth0 to /etc/eselect/net/devs/net.eth0. Current interface configurations can be queried by show command:

```

   root # eselect net show

   Network devices configurations:

     eth0                      eth-dhcpcd

     lo                        not configured by eselect

     ppp0                      3g-dongle-at

```

Notice: eselect-net is not aware of configurations in /etc/conf.d/net and will show not configured for those interfaces.  Also if /etc/conf.d/net.iface exist but not linked to eselect-net managed configurations, It will be shown as not configured by eselect.

Now let change eth-dhcpcd to ask dhcpcd do its job in background:

```

   root # $EDITOR /etc/eselect/net/conf.d/eth-dhcpcd

   # -*- gentoo-conf-d -*- vim: ft=gentoo-conf-d

   #

   # This is a netifrc network configuration.  It will be processed to make config

   # file.  _iface_ in labels is a placeholder for interface, so modules__iface_

   # will be modules_eth0 in produced config file.

   config__iface_="dhcpcd"

   dhcpcd__iface_=( "-S domain_name_servers='8.8.8.8 8.8.4.4' -b" )

```

check command will show which interface is using current profile configuration

and which one is not:

```

   root # eselect net check

   Network configurations status:

     eth0                      outdated

     ppp0                      ok

```

To apply latest dhcpcd-eth0 change to eth0 configuration, use update:

```

   root # eselect net update eth1

```

To make eth0 don't use [code single]dhcpcd-eth0[/code], use unset command:

```

   root # eselect net unset eth0

```

----------

## mv

Nice!

If you would tag a release, it would be simpler to put an ebuild to the mv overlay (if you do not protest, of course). Also necessary for an ebuild: What is the license? GPL-2?

----------

## reith

I was thinking of other features, like configuring network services to multiple profiles but now I have doubt about usefulness of those.  And doing those things properly and still not break nice features like dedicated hook functions in profiles, needs some care.  I just made a release and (un)licensed work as public domain.

Thanks

----------

## Hu

Some jurisdictions are weird about public domain.  If you want the work to be usable with no restrictions, I suggest explicitly licensing it under the MIT license, which is extremely permissive for recipients.  You can see a copy of the MIT license at ${PORTDIR:-/usr/portage}/licenses/MIT.  As part of licensing it under MIT (or some other license, if you choose), it would be helpful to include in the repository, either as a banner comment on existing documentation or as a separate obviously-named file, a reference to the license covering the work.  Even if you want to declare it public domain, having that declaration in the work itself will make some users more comfortable with it.

----------

## reith

 *Hu wrote:*   

> Some jurisdictions are weird about public domain.  If you want the work to be usable with no restrictions, I suggest explicitly licensing it under the MIT license, which is extremely permissive for recipients.  You can see a copy of the MIT license at ${PORTDIR:-/usr/portage}/licenses/MIT.  As part of licensing it under MIT (or some other license, if you choose), it would be helpful to include in the repository, either as a banner comment on existing documentation or as a separate obviously-named file, a reference to the license covering the work.  Even if you want to declare it public domain, having that declaration in the work itself will make some users more comfortable with it.

 

I myself don't care that much about licences, they hardly apply to country I live in and won't affect my life really.  For the software we make at company and sell It's a real issue but here I'm more happy with public-domain because of Its uniquely simple definition and having a more common and general meaning outside software domain.  I believe this tiny tool won't be abused and I prefer keep those formal writings simple.

Thanks for caring and helps! Much appreciated.

----------

## khayyam

 *reith wrote:*   

> Recently I realized I'm spending unnecessary time to find correct configuration to change wireless mode or chat scripts for different mobile networks and since I really don't know netifrc, It was horrible for me to correct things fast. I tried to put all configurations commented out in conf.d/net and switch between them easily. Then I thought It would be nice to have these configurations stored somewhere and make interface to use target configuration when needed. Fortunately there is eselect tool in Gentoo making this task easy and familiar to Gentoo user.

 

reith ... openrc/netifrc already provides a (better and more flexible) method to do just that using net.<interface>.<runlevel> ... for example (using a "stacked" runlevel via the '-s' switch):

```
# mkdir /etc/runlevels/foo

# rc-update -s add default foo

# $EDITOR /etc/conf.d/net.<interface>.foo

# rc-update add net.<interface>.foo foo

# rc foo
```

Similarly other services can be added to the runlevel ('foo') to provide a specific set of services, and configuration, for that setup.

```
# ln -s /etc/init.d/iptables /etc/init.d/iptables.foo

# cp /etc/conf.d/iptables /etc/conf.d/iptables.foo

# $EDITOR /etc/conf.d/iptables.foo

# rc-update add iptables.foo foo
```

... and so on (mounting shares, etc, etc).

Once your runlevels are configured you need then only call 'rc <runlevel>' to switch configuration. Additionally you can add 'softlevel=<runlevel>' to the kernel command line and so be able to select <runlevel> at boot.

EDIT: corrected, add 'mkdir /etc/runlevels/foo'

best ... khayLast edited by khayyam on Sat Dec 31, 2016 6:45 am; edited 2 times in total

----------

## mv

@khayyam: Thanks for sharing the information. I knew neither about stacked runlevels nor about the .<runlevel> mechanism.

Nevertheless, reith's script remains useful since using separate runlevels is not always what one wants when one is "only" interested in a switch of the network configuration: If one already has several runlevels, the "runlevel" mechanism multiplies their number by the number of network configurations...

----------

## reith

yes, as mv explained, this script's main usage is for switching between configurations.  using separate run-levels does not help to reuse network configuration; you should still keep track of conf.d/net.interface.runlevel* which are now even increased in number. and consider the case you plug a wifi dongle into your laptop, you'll got an interface and want configure it to start wpa_supplicant. you already have a wifi configuration for you internal card, so you just link init.d/net.wlXXX to init.d/net.lo and make net.wlXXX use that config by something like:

```
eselect net set wlXXX wifi-wpa_supplicant
```

you don't need to clone current configuration, replace interface in new config and mess up conf.d/ with old and temporary configurations.

using your run-level trick seems quiet useful when someone reconfigures several services time to time to do his different set-ups for different tasks. thanks!

----------

## khayyam

 *reith wrote:*   

> yes, as mv explained, this script's main usage is for switching between configurations.  using separate run-levels does not help to reuse network configuration; you should still keep track of conf.d/net.interface.runlevel* which are now even increased in number. and consider the case you plug a wifi dongle into your laptop, you'll got an interface and want configure it to start wpa_supplicant. you already have a wifi configuration for you internal card, so you just link init.d/net.wlXXX to init.d/net.lo and make net.wlXXX use that config [...]

 

reith ... I really don't think it is all that difficult to "switch between configurations", or that your objections amount to much, so there are a few more files in conf.d, that's really not a problem, and they can be "reused" as you might the standard net.<interface> ... they simply provide specific configuration (ie, for mesh, hostap, adhoc, ppp, "work", or however you might want to define them (so, specific connectivity, services, etc), there is no reason not to have a generic net.<interface>.online, nothing that need exclude you from doing that. You are suggesting that by configuring these specific setups you loose the ability to quickly switch (ie, if connecting to a new network, or using a usb dongle) that isn't the case.

 *reith wrote:*   

> you don't need to clone current configuration, replace interface in new config and mess up conf.d/ with old and temporary configurations.

 

You are being silly, if I create a runlevel then its for a specific purpose (ie, eth0 is connected to a gateway, wlan0 is serving wireless via hostap, and x,y,z are started), these are configured for reuse (so, not "temporary"), I could use this whenever I wanted the laptop to act as an AP, and I need only type two words to do so. On other occasions I simply want some form of network (wireless, or what-have-you) and that is similarly configured for regular use. I don't need to do anything subsequently, that is the point of configuration, and that is what conf.d/ is for. 

 *mv wrote:*   

> @khayyam: Thanks for sharing the information. I knew neither about stacked runlevels nor about the .<runlevel> mechanism.

 

You're welcome.

best ... khay

----------

## reith

 *khayyam wrote:*   

> reith ... I really don't think it is all that difficult to "switch between configurations", or that your objections amount to much, so there are a few more files in conf.d, that's really not a problem, and they can be "reused" as you might the standard net.<interface>

 

Of course it's not very hard and the whole problem and humble solution is to handle things a bit cleaner and faster.

 *khayyam wrote:*   

> You are being silly, if I create a runlevel then its for a specific purpose (ie, eth0 is connected to a gateway, wlan0 is serving wireless via hostap, and x,y,z are started), these are configured for reuse (so, not "temporary"), I could use this whenever I wanted the laptop to act as an AP, and I need only type two words to do so. On other occasions I simply want some form of network (wireless, or what-have-you) and that is similarly configured for regular use. I don't need to do anything subsequently, that is the point of configuration, and that is what conf.d/ is for. 

 

I was saying about network peripherals that don't have a conf.d/net.iface.runlevel at the time.  Whenn you do have net.iface.runlevels for all configurations of that device, yes switching is easy.. Not saying for new devices It's so hard to configure, but it's something..

BTW, I'm curious to know how multiple devices using common configurations being handled.. consider two 3G dongle can use carriers  X and Y.  You made net.ppp1.X, net.ppp2.X, net.ppp1.Y and net.ppp2.Y.  How do you activate net.ppp1.X and net.ppp2.Y ? Would you make a run-level for each interface too?

----------

## khayyam

 *reith wrote:*   

> BTW, I'm curious to know how multiple devices using common configurations being handled.. consider two 3G dongle can use carriers X and Y.  You made net.ppp1.X, net.ppp2.X, net.ppp1.Y and net.ppp2.Y.  How do you activate net.ppp1.X and net.ppp2.Y ? Would you make a run-level for each interface too?

 

reith ... I consider that a very improbable set of circumstances (two carriers simultaniously, each of which may, or may not, be using a specific dongle), however, as I'm not using "predictable network names"  ppp0 or ppp1 wouldn't particularly matter in terms of what dongle was selected, I would simply define *_ppp0 and *_ppp1 in conf.d/net.runlevel and let nature take its course ... noting that <interface> is optional. That said, I consider my configuration to be real world use, and not hypothetical use ... if such a setup were needed I could probably create a runlevel for it, but, again, this would seem an instance of the impobable, and something I need not be prepared for.

best ... khay

----------

