.. This document is © Martin F. Krafft <mail@martin-krafft.net>
   It is available under the terms of the Creative Commons
   Attribution-NonCommercial-ShareAlike Licence 2.5

==========================================================================
netconf
==========================================================================
Revamping the network configuration system
--------------------------------------------------------------------------

.. |event| replace:: DebConf7, Edinburgh, Scotland
.. |talkdate| replace:: 18 Jun 2007
.. |author| replace:: Martin F. Krafft
.. |authoremail| replace:: madduck@debian.org
.. |footer| replace:: More info: http://netconf.alioth.debian.org/

.. container:: author

  |author| <|authoremail|>

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

.. _Debian: http://debian.org/
.. _Ph.D. student: http://martin-krafft.net/phd/
.. _Lero: http://lero.ie/
.. _CSIS: http://www.csis.ul.ie/
.. _University of Limerick: http://ul.ie/
.. _The Debian System — Concepts and Techniques: http://debiansystem.info/

.. container:: event

  |event|
  |talkdate|

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
========

.. class:: current

  - Desired functionality

- ``netconf`` design
- Implementation & outlook
- Discussion

The wishlist
============

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

.. class:: incremental

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

.. class:: incremental

  - non-hackish (two-way) integration of

    .. class:: incremental

      - 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

.. class:: current

  - ``netconf`` design

- Implementation & outlook
- Discussion

``netconf`` design
==================

A design document is `available online
<http://git.debian.org/?p=netconf/netconf/master.git;a=blob;f=doc/design.txt;hb=HEAD>`_.

Event sources
=============

.. class:: incremental

  - pretty much everything in netconf happens in response to events
  - events include:

    .. class:: incremental

      - 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
=========

.. class:: incremental

  - the central daemon processes the event queue and takes appropriate action:

    .. class:: incremental

      - 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
=============

.. class:: incremental

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

    .. class:: incremental

      - 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
=====================

.. class:: incremental

  - answers requests for configuration details.
  - policy determines which source to consult.
  - sources may be

    .. class:: incremental

      - 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
=======

.. class:: incremental

  - 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
===============

.. container:: center

  .. image:: design.png

Control socket operation
========================

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

.. class:: incremental

  - 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

.. class:: current

  - Implementation & outlook

- Discussion

Implementation
==============

.. class:: incremental

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

.. container:: author

  |author| <|authoremail|>

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

.. include:: licence.en.rst
.. include:: common.inc
.. footer:: |footer|
