Hello Martin,
Hello Nam,
I am the author of netconf (http://netconf.alioth.debian.org), which
Brian has already introduced in another post to this thread. I am
very interested in your work because all the issues you highlight in
your mail are core to my motivations for writing netconf.
You are asking us to evaluate the quality of a software based only
on the descriptions you provide. This is really difficult. While
others have picked up on shortcomings, such as the use of XML,
I wonder about certain other things:
I have just read netconf wiki pages, and I think that our ideas are
exactly the same. I've finished my work in 2004 and used it on some
mission critical enterprise gateways of different companies we provide
service to. The gateways are all have multiple internet connections
(ranging from 4 to 11 connections). In 2005, I rewrote a new code from
scratch to make the design better. Since then, I've been occupied by a
lot of management works so I could not revive it. Now I have time again
any continue developing it seriously.
- what language are you using?
- netupdown is in Perl.
- is this a daemon-based design?
- netupdown is not daemon based, it reads the config, read the current
runtime state, does the job, save the runtime state, and exit. It flock
the state so only one process can do the job at a given time. But there
is a daemon to support it, mostly monitor the availability of
connections and log the counters into a Round Robin Database, and log
the conntrack events using netlink socket as well.
- how much internal state do you keep?
- I have posted a full example of internal state on the first email.
Runtime state contains info about interfaces, about networks running on
those interfaces, routes running on those networks, and multipath routes
using the available routes.
- how extensible is the software?
- The software is made to be extensible, otherwise it can't survive
itself because of 6 different types of interface. In order to release
it, I am trying to improve it further. Each feature will be stored in a
separated file.
- how large is the code base?
Very compact, about 1500 lines in Perl, other stuff doesn't count.
- how do you interface with e.g. openvpn? Do you wrap it (and thus
limit the possible configuration), or do you feedthrough to it
(and thus provide the full configuration abilities)?
I generate configuration file for them from specified template, and run
the daemons (pppd, openvpn, vtun, ...) with the newly generated
configuration file. Full configuration abilities are guranteed.
- does your software handle wireless networks, including those
configured by wpa_supplicant?
My laptop use the software itself to manage connectivity, of course, the
laptop uses wireless. But currently, it's not so nice because it doesn't
integrate very well with wifi-radar. It's not my first priority because
I care about internet gateways more than personal computers.
I think it's always a good idea to release software to the public.
As such, I encourage you to convince your management to slap a good
licence onto your work.
I agree. But it will take some effort so I will only try to release it
if some conditions are met:
- It attracts enough developers
- The quality is good, so it is worthy to continue developing
On the other hand, you and your team may also be interested in
netconf. You surely have a lot of experience in the domain, and
netconf could greatly benefit from your input. While netupdown seems
designed to override shortcomings in ifupdown, netconf aims to fix
those at the root.
I'm sure I will study it.
netconf is currently implemented in Python, but that only really
makes it easier for others to read the code and contribute to it.
Unfortunately, netconf is not yet ready for use, but it's not very
far either.
Even I am not familiar with python, I'll try to learn from netconf. My
software have been in production use for years so many bugs are fixed,
the users are very happy with it.
Please release your software to the public and then consider joining
the netconf team and getting your colleagues interested too. We can
then reuse your work on netupdown and integrate it into netconf to
add advanced network configuration abilities to Debian by default!
There is a challenge here, until Larry Wall does some breakthrough with
his perl6, I don't know how Perl developers and Python developers can
code together :(
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
