netconf
Getting Debian network configuration up to speed
FOSDEM 2007, Brussels, Belgium
25 Feb 2007
What is netconf
- vapourware / my brain child
- a (backwards-compatible) replacement for ifupdown
- a modular, daemon-based network configuration management system
- suitable for servers, desktops, and laptops
- will commence implementation at Debcamp7
http://netconf.alioth.debian.org/
Overview
- Problems with ifupdown
- Desired functionality
- Alternative solutions
- (Preliminary) netconf design
Let's go
- Desired functionality
- Alternative solutions
- (Preliminary) netconf design
ifupdown
- split from netbase in 2000, started in 1999
- the Debian network configuration tool
- can handle IPv4 (incl. PPP), IPv6 (incl. tunneling), and IPX
- flexible mapping concept
- flexible hook support
Shortcomings of ifupdown: one-way hooks
not enough information/feedback for many helpers, such as wpasupplicant or
even dhclient:
lapse:~# ifdown eth0
ifdown: interface eth0 not configured
lapse:~# ifup eth0
Internet Systems Consortium DHCP Client V3.0.4
^C
lapse:~# ifup eth0
ifup: interface eth0 already configured
lapse:~# echo $?
0
Shortcomings of ifupdown: inflexible hooks
failures cannot be overridden by --force:
lapse:~# tail -2 /etc/network/interfaces
iface test inet manual
pre-up false
lapse:~# ifup eth0=test
Failed to bring up test.
lapse:~# ifup --force eth0=test
Failed to bring up test.
lapse:~# echo $?
0
Shortcomings of ifupdown: brittle hooks #1
disagreement on up failures:
lapse:~# tail -2 /etc/network/interfaces
iface test inet dhcp
up false
lapse:~# ifup eth0=test
Internet Systems Consortium DHCP Client V3.0.4
[...]
bound to 10.0.0.24 -- renewal in 20425 seconds.
Failed to bring up test.
lapse:~# grep eth0 /etc/networ/run/ifstate || echo none
none
lapse:~# ip l show eth0
2: eth0: <[...],UP> mtu 1500 [...]
Shortcomings of ifupdown: brittle hooks #2
ignoring of down failures:
lapse:~# tail -2 /etc/network/interfaces
iface test inet dhcp
down false
lapse:~# ifdown eth0
Internet Systems Consortium DHCP Client V3.0.4
[...]
DHCPRELEASE on cable to 192.168.14.1 port 67
[...]
lapse:~# echo $?
0
Other shortcomings of ifupdown
- stateful
- old tools, aged baseline assumptions (e.g. default gateway)
- not extensible, other than via manual method and hooks
- locking: hooks cannot bring up other interfaces (think VPN)
- unclear responsibilities: who actually configures the interface (DHCP)?
Other problems
- somewhat unmaintained/stable: 148 changelog entries in 6.5 years
- slightly obfuscated code-base
- mappings very counter-intuitive (or so I've been told)
I have tried to address most of these problems, but either I could not
make sense of the code or patches went unnoticed.
Anything else?
Can you think of anything else I haven't mentioned?
Will you hear me desires
- Alternative solutions
- (Preliminary) netconf design
My wishlist
- statelessness, as far as possible
- printer, SMTP relay, Proxy registration
- interfaces to status monitors, UIs
- user control policies
- notifications
- extensibility at the method level
- resolv.conf management
- /etc/network/interfaces.d
- status query interface
- ponies
My wishlist, cont'd...
- Non-hackish (two-way) integration of
- link-status and environment detection
- firewalling
- zeroconf
- WiFi configuration
- VPN configuration
- not looking to design a one-for-all tool, which would be non-Unix-y
- however, hooks not suitable for every task
Your wishlist?
What would you love to see in a network configuration system?
A glance around
- Problems with ifupdown
- Desired functionality
- Alternative solutions and extensions to ifupdown
- (Preliminary) netconf design
Alternative: NetworkManager
- a GNOME project, designed from the UI perspective
- designed for laptop users to make stuff just work
- daemon-based
- uses dbus for internal communication and can thus be connected to
- does not integrate with Debian's /etc/network
- not a solution for servers
Extension: 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
Outlook
- Problems with ifupdown
- Desired functionality
- Alternative solutions and extensions to ifupdown
- (Preliminary) netconf design
Braindump
- stateless, but not everything can be stateless
- thus a daemon process which stores external state only when necessary
- daemon searches for configuration in various places
- daemon invokes methods for configuration
- communication via sockets (dbus would be implemented on top)
Configuration broker
- first-come, first-serve iteration through sources
- if neither UI or interfaces give a clue, fall back …
- … to DHCP, then zeroconf (or poweroff)
- needs policy for when UI can override interfaces
Methods
- get information from daemon via environment or parameters
- do whatever they must
- potentially stay running (VPN, wpasupplicant, …)
- can be chained: DHCP for eth0, then VPN for e.g. tun0
Thoughts on DHCP
- ifupdown doesn't actually configure the interface with dhcp method
- the clean way would be:
- netconf asks dhclient for the information
- (needs a way for dhclient to notify daemon of changes)
- netconf passes information onward to the appropriate method
Implementation
- C and shell, possibly a shell or Python mockup, then rewrite
- policies controlled by the daemon to allow users to up/down/configure
certain interfaces
Outlook
- design thoughts and mailing list on the wiki
- anyone welcome to join in!
- a lot already done in scripts on my laptop (total chaos though)
- I am going to Debcamp7 to implement the first version
Thank you
Thank you for your attention!