netconf

Revamping the network configuration system

What is netconf

• a modular, daemon-based network configuration management system
• policy-driven, flexible, and extensible
• backwards-compatible with ifupdown, can replace it
• suitable for servers, desktops, and laptops
• written^W prototyped in Python

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

Overview

• Desired functionality
• netconf design
• Implementation & outlook
• Discussion

Let's go

• Desired functionality

• netconf design
• Implementation & outlook
• Discussion

The wishlist

From http://wiki.debian.org/netconf:

• statelessness, as far as possible
• policy-driven
• interface for UIs
• extensibility at the method level
• resolv.conf management
• printer, SMTP relay, Proxy, APT mirror registration

The wishlist, cont'd...

• non-hackish (two-way) integration of
  • link-status and environment detection
  • firewalling
  • zeroconf
  • WiFi configuration
  • VPN configuration
  • bridging
• ponies

But!

• not looking to design a one-for-all tool, which would be non-Unix-y
• ifupdown hooks not suitable for every task
• netconf must be extensible in Debian-fashion

What about: NetworkManager?

• an acceptable GUI (with flaws)
• top-down, GUI-centric design
• backends are nightmares
  • can only configure a single static IP
  • hard-coded policies (e.g. "if cable connected, disable wireless")
  • not easily extensible, i.e. cannot add bonding, bridging, etc (other than through ifupdown hooks)
• it is goal for netconf to Provides: network-manager so that e.g. network-manager-gnome can still be used.

What about: ifupdown-scripts-zg2

• a set of hooks by Marc Haber
• supports advanced networking concepts: - CIDR (advanced!) - ATM - 802.1q VLAN tagging - renaming of interfaces - static route handling
• generates code to down interfaces when bringing them up to ensure symmetry
• definitely a source of inspiration

What about: ifupdown-extra

• implemented by Javier Fernandez-Sanguino Peña
• a mixture between location/link detection and network testing - tests link status - checks for existing IP - tests reachability of default gateway - support for static routes per interface
• in addition, network-test can give status information
• also definitely a source of inspiration

How does it do it?

• Desired functionality

• netconf design

• Implementation & outlook
• Discussion

netconf design

A design document is available online.

Event sources

• pretty much everything in netconf happens in response to events
• events include:
  • user requests on control sockets
  • kernel-level state changes on NETLINK socket
  • application-specific state change from helper apps, such as dhclient and wpa_supplicant
• events are queued with the central daemon
• events can be piggy-backed / chained

The brain

• the central daemon processes the event queue and takes appropriate action:
  • obtain configuration details in response to an ifup request
  • invoke a method to apply configuration details chained to an ifup event
  • take appropriate action on receipt of an event such as failing to renew a DHCP lease
• the decision on how to react to an event is delegate to the policy broker.

Policy broker

• 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)

Configuration sources

• answers requests for configuration details.
• policy determines which source to consult.
• sources may be
  • interface-specific (dhclient) vs. generic (/e/n/i)
  • one-off jobs (LinkLocal) vs. event sources (wpa_supplicant)
• configuration sources become event sources, even if only for one event

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

The big picture

Control socket operation

I'm too lazy to draw a picture for this, so let the bullets speak:

• client connects to socket and issues HTTP-like request followed by EOF
• control socket handler creates event from request and queues event
• event object contains an open write-only stream to the client and a mark_done callback function
• daemon dispatches event to handler, which may output anything to the client
• handler is expected to call mark_done callback to inform client of completion
• passphrase changes etc. via additional named pipe, not within protocol

How do I do it?

• Desired functionality
• netconf design

• Implementation & outlook

• Discussion

Implementation

• currently in Python for easy prototyping
• should/will be ported to C
• abstain from use of higher-level Python to make porting easier.
• code is in git repository

Current status

• Control socket dispatches events, modular event handlers
• /e/n/i parser (thanks to Thomas Hood and Enrico Zini)
• dhclient thread, but not integrated
• NETLINK listener, but no event processor yet

Help needed

Contributors needed on every level:

• hecklers
• beggars
• people conceptualising
• people writing unit tests
• people documenting the code
• people writing code

Thank you

Thank you for your attention!

Now heckle!

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.