[CUWiN-Dev] Post-Summit dev thoughts

[Paul Smith]

Great to see everyone at the Summit this weekend, especially Charles (cool
bamboo masts, btw) and John and other folks using CUWiNware that I hadn't
met before.

I wanted to start a thread on fleshing out some of the ideas brought up in
the course of panels and informal chats. Here are some unorganized thoughts
mostly straight out of my Moleskin.

I think everyone agrees that configuration is an area that needs some
attention. By "configuration" we mean operator control over how interfaces
are set up, and what information services (dhcpd, etc.) are provided and
how. I brought up that currently configuration is spread across several
different files and scripts, and that things that should be "runtime" are
currently only twiddleable at build/compile time. For instance, a dhcpd
config template is hard-wired in /sbin/dhcpselect, and the flag for enabling
it is hard-wired in the /etc/ifconfig.*.tmpl templates. The main config
persistance store /etc/cuw_config is a flat-file which I prefer (as opposed
to say a sqlite db or XML document or some binary store) but is also a flat
namespace which makes adding data on multiple interfaces, for instance,
currently problematic. Mike K described how his wireless system keeps its
per-node config in a central Internet-addressable MySQL database and the
nodes pull down their runtime config at boot, and a "last good" copy of the
config is kept locally for when the Internet is down. Regardless of a
central RDBMS piece which may not work for some networks, at the least I
think a new local persistance config format should be thought up, kept in a
simple format like YAML or JSON or something else well-known and with
existing parse tools.

A whole discussion could probably be had on what constitutes the
configurable state of a node.

I complained I believe to Chase who just happened to be the nearest person
who would listen that the heuristics for figuring out what roles a node
should play at runtime are complex and break down with the introduction of
additional interfaces. It's just really hard to divine what the operator
intent is for a particular interface, be it backhaul, client, AP, dhcpd or
no dhcpd, gateway, etc. I think the goal of zero-config out of the box
community wireless node is noble and can be preserved at some level but
probably accounts in some small part for the current state of the config.

So there is the configuration "backend" and then there is exposing those
knobs to an operator via a limited interface like a Web or ncurses form.
Bryan C had begun an update of the Web interface that looked super cool at
some point in the recent past but that effort is where right down? Can it be
resurrected? Also, should it be in light of a retooling of the backend
architecture. Which brings up a good point which is that it would be nice to
have the Web interface have more or less an API that can be extended for
other platforms, hooks for calling the platform-specific calls like
ifconfig(8) with its particular options.

I'm going to stop now but another thing that Mike K and I were trying to
elaborate on was this idea of an open source community wireless for lack of
a better term enterprise solution. This would consist of CUWiNware for the
node smarts, monitoring like Nagios, Chase's node map, and a captive portal
for auth all made to play nice with each other, a platform that communities
or municipalities could grok as a unified mesh wireless system. The
assumption being that part of the reason Tropos et al steal all of the RFPs
is that they have the complete soup to nuts package and that is something
decision makers are looking for, you know, turnkey. *cringe* If vegetarian
turkey is called tofurkey, should open source metro wireless be called
turnfookey?

-Paul

--
Paul Smith
Center for Neighborhood Technology
Manager, Wireless Community Networks
Chicago IL, USA
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.chambana.net/mailman/archive/cu-wireless-dev/attachments/20060404/c508404f/attachment.htm