netconf

modern, bottom-up, stateless network interface configuration

What is netconf?

• a network interface configuration system
• a modular design, extensible on the filesystem
• a flexible, policy-driven infrastructure
• a daemon
• suitable for servers, desktops, and laptops
• written with the Debian (minimal) base system in mind
• currently prototyped in Python, port to C/C++ planned

Homepage: http://netconf.alioth.debian.org/

What's in this talk?

• my motivation to write netconf
• my vision, goals, and desired functionality
• an introduction to the netconf design
• implementation status
• discussion

What about the name?

netconf could also be:

• RFC 4741, the NETCONF protocol
• the annual netdev@vger.linux.org conference at LCA
• internal/proprietary tools (e.g. netconf.org)

I don't insist on the name, but I don't see too much of a conflict.

The menu

• motivation

• vision, goals, and desired functionality
• netconf design
• status and outlook
• discussion

Motivation

• Debian's ifupdown is aging:
  • "modern" configuration requires hooks which do not communicate with ifupdown
  • statefulness cannot deal with status quo diverging
  • not extensible, forces hackish integration of e.g. wpa_supplicant
  • single interface concept, no dependencies
• other distros have similar approaches with their own shortcomings
• some employ GUIs, or NetworkManager

What about NetworkManager?

• an acceptable GUI
• top-down, GUI-centric design
• backends are limited
  • can only configure a single static IP (fixed recently, I think)
  • hard-coded policies (e.g. "if cable connected, disable wireless")
  • not easily extensible, i.e. cannot add bonding, bridging, etc. (other than through distro-specific hooks)
• netconf will be able to interface with the NetworkManager GUI(s).

The menu

• motivation

• vision, goals, and desired functionality

• netconf design
• status and outlook
• discussion

The netconf vision

• bottom-up
• a simple core daemon which collects events and routes them to interface handlers
• decisions are outsourced to a policy in /etc.
• stateless, do not get in the way of the administrator manipulating interfaces or routing tables directly ("the Debian way")
• actual manipulation happens from the same set of shell scripts for all configuration methods

netconf goals

• extensible, modular design, cross-distro target
• allow non-root users to perform standard configuration tasks
• integrate tools for "standard" tasks:
  • resolv.conf management
  • firewalling
  • link-status (netlink) and environment detection
• make many hackish, local solutions obsolete
• no magic! Clear separation of tasks and components.
• make network configuration fun again (yeah, well…)

Desired functionality

A roadmap for netconf 1.0 is in the (Git) repository.

Selected items:

• provide ifup/ifdown and handle most of /etc/network/interfaces
• implement a policy layer to externalise the high-level control flow and authenticate non-root users
• listen to netlink events and react appropriately

Broken drivers

• netconf does not cater for broken drivers
• link detection happens exclusively via the Netlink socket
• powersaving mode is activated by bringing the link down.

Debian

• I am a Debian developer
• netconf 1.0 should be able to replace ifupdown
• Debian-specific stuff is implemented as plugins!
• I want to make netconf cross-distro.

Consider joining!

OpenSolaris "Network Auto-Magic"

http://opensolaris.org/os/project/nwam

• geared at laptops
• seems OpenSolaris-specific; kernel integration
• CDDL ("choice of venue" problem?)
• "magic"
• source of inspiration?

The menu

• motivation
• vision, goals, and desired functionality

• netconf design

• status and outlook
• discussion

netconf design

A design document is available online.

Main loop:

while _is_running:
    fds = select(fdrreactors.keys(), [], [], timeout=None)
    for fd in fds[0]:
        fdrreactors[fd](READ, fd, self)

Reactor registration:

def register_fdrreactor(fd, reactor):
    fdrreactors[fd] = reactor
def unregister_fdrreactor(fd):
    del fdrreactors[fd]

Thread-less and cooperative reactors

• netconf is thread-less
  • to prevent polling (batteries)
  • to make control flow explicit and facilitate debugging
• reactors thus need to be cooperative:
  • finish promptly and consume all data from their file descriptor
  • fork for long-running processes
  • if a process is expected to take longer, it needs to be split up and its components handled by a job queue runner

The big picture

Example: bringing up an interface with DHCP on Debian

1. user calls ifup eth0, which issues an IFUP event via the control socket.
2. the control socket handler dispatches the event to the interface policy.
3. the interface policy consults /etc/network/interfaces, determines that DHCP is to be used, and instantiates and delegates control to a DHCPHandler.
4. the DHCPHandler spawns dhclient and registers its stdout with the core along with a reactor callback.

Continued: bringing up an interface with DHCP on Debian

5. dhclient now issues PREINIT and BOUND events, which are split by the reactor callback into component calls to the interface manipulator.
6. the manipulator populates the environment and spawns shell scripts to do the actual work.
7. should dhclient fail to obtain a lease, it will issue a FAIL or TIMEOUT event.
8. The policy might tell netconf to then fire off zeroconf.

Example: bringing down a DHCP-configured interface on Debian

1. user calls ifdown eth0, which issues an IFDOWN event via the control socket.
2. the control socket handler dispatches the event to the interface policy.
3. the interface policy finds that there is already a handler assigned to eth0 and tells it about the IFDOWN event.
4. the previously instantiated DHCPHandler kills dhclient and takes the interface down.
5. on success, the policy deletes the handler instance for eth0.

Questions so far?

The policy

user-defined, per-interface policy (+ a default) used to e.g.

• decide whether a user has privileges for a specific request
• determine what to do upon receipt of configuration details, such as bringing up and configuring the interface
• proceed with DHCP if no static configuration was found
• proceed with LinkLocal (or PowerOff) if DHCP failed
• determine prerequisites for interfaces (e.g. eth0 for OpenVPN)

Policy example #1

[IFUP]
allow @group1 user2
startat ENI

[cfg ENI]
file /etc/network/interfaces
NOTFOUND DHCP

[cfg DHCP]
dhcp-client-param1 foobar
FAIL,TIMEOUT LinkLocal

#[cfg LinkLocal]
#nothing here

Policy example #2

[IFUP]
allow @users
prereq ifup eth0
startat OpenVPN

[cfg OpenVPN]
config /etc/openvpn/work.cfg
BIND ENI

[cfg ENI]
file /etc/network/interfaces.d/tun0
#NOTFOUND error #(default)

Methods

• invoked by daemon to do the actual work (OS-specific stuff)
• no-one else may interact with the networking subsystem
• get information from daemon via environment
• declarative: make minimal changes to reach desired state

Implementation

• currently in Python for easy prototyping
• should/will be ported to C/C++ (or Nickel, right Keith?)
• abstain from use of higher-level Python to make porting easier
• code is in git repository

The menu

• motivation
• vision, goals, and desired functionality
• netconf design

• status and outlook

• discussion

Current status

• definitely pre-alpha / design stage
• I don't have a lot of time to work on this
• core and control flows done
• DHCP handler needs corner case implementations
• need to conceptualise interface dependencies

Outlook: wanted features

• bridging, bonding, VPN, …
• central location of configuration data (e.g. obtained from DHCP), such as SMTP server, proxy, package repositories, …
• environment detection
• restoring custom routes
• remembering networks and ad-hoc configurations

Thank you

Thank you for your attention!

Now heckle! Then join!

Licence

These slides, their design, and the content are © Martin F. Krafft and released under the terms of the CC by-nc-sa 2.5 licence.

reStructuredText sources: slides.rst and ui/debian/*.

Slides based on the S5 presentation system.