© Martin F. Krafft

# netconf

## Revamping the network configuration system

Martin F. Krafft <madduck@debian.org>

- Debian developer
- Author of the book The Debian System — Concepts and Techniques
- Ph.D. student, Lero, CSIS, University of Limerick, Ireland

DebConf7, Edinburgh, Scotland 18 Jun 2007

# 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!

Martin F. Krafft <madduck@debian.org>

- http://netconf.alioth.debian.org
- http://people.debian.org/~madduck/
- http://martin-krafft.net/phd/

# 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.