Re: Request for comment: a new software to manage linux networking features
Am Sonntag 17 Februar 2008 schrieb namnd: In this case, the configuration is as easy as: interface name=fpt1 type=ppp ppp type=pppoe options= depend_on=tap1 username=*** password=***/ network id=11 name=FPT1 auto=1/ /interface The ppp stanza should not contain authentication information. Especially since username/password only covers the most simple authentication method. And other parts could use a auth tag, too (ethernet, wlan, etc.). Additionally, the options attribute sounds like a work-around. HS
Re: Request for comment: a new software to manage linux networking features
On Sun, Feb 17, 2008 at 11:20:48PM +0700, namnd wrote: * The configuration file is in XML so netupdown can handle sophisticated configuration. Editing the XML the configuration by hand or by software will be easy and comfortable. Forgive me, but yeah right! Have you ever actually edited XML by hand? Try tweaking a build.xml or some other suitably complex XML document and you will think differently. Basically, if your XML is so simple that it can be edited by hand, your needs are such that it is better handled without XML. If your needs are such that you actually require XML, then what you end up with is too complex to edit by hand. ?xml version=1.0 encoding=utf-8? config version=1.0 logLevel=debug ... /config * The configuration syntax is unified and consistent, for example, I need a VPN tunnel to run on a pppoe connection, the computer has more than one ppp interfaces. You know, ppp numbers are automatically allocated so it's quite troublesome, netupdown can solve this problem because interfaces are mentioned by a fixed name, netupdown will translate it into a name that the kernel can understand when necessary. When the pppoe interface is down, the openvpn process is killed, when the pppoe interface is up again, netupdown will generate the new openvpn option file based on a template, and bind the local ip address to the ip address of pppoe. In this case, the configuration is as easy as: interface name=fpt1 type=ppp ppp type=pppoe options= depend_on=tap1 username=*** password=***/ network id=11 name=FPT1 auto=1/ /interface interface name=tap7 auto=0 type=ethernet sub_type=openvpn openvpn remote=210.245.87.151 rport=19817 comp=comp-lzo depend_on=FPT1/ network id=7 name=TAP auto=1 config=dhcp/ /interface This is supposed to be easy to read and easy to edit by hand? It seems to me that a properly commented normal text configuration file would be much more appropriate to the task. I will not even comment on the rest of your examples, except to say that the Swiss Army Knife approach is certainly not in the *nix tradition. After reading the brief overview of my software, please give me your opinions: 1. What is the quality of idea (1 star to 5 star) 2. What is the quality of the source code (1 to 5) 3. Your other comments I do not have time to review the code right now. However, the abuse of XML that you call a configuration file really needs to be fixed. Regards, -Roberto -- Roberto C. Sánchez http://people.connexer.com/~roberto http://www.connexer.com signature.asc Description: Digital signature
Re: Request for comment: a new software to manage linux networking features
Roberto C. Sánchez wrote: * The configuration file is in XML so netupdown can handle sophisticated configuration. Editing the XML the configuration by hand or by software will be easy and comfortable. Forgive me, but yeah right! Have you ever actually edited XML by hand? Try tweaking a build.xml or some other suitably complex XML document and you will think differently. Basically, if your XML is so simple that it can be edited by hand, your needs are such that it is better handled without XML. If your needs are such that you actually require XML, then what you end up with is too complex to edit by hand. I agree that a suitably complex XML is hard to edit by a simple editing tool such as vim-tiny, but even a sophisticated networking configuration isn't as complex as build.xml, I hope. And this software package is intended to handle computers with quite sophisticated network configuration, so it should be configured using a web based software, and I will release the configurator as well. This software doesn't have the ambition to replace ifupdown, but to solve the problems ifupdown can not, and stays being compatible with ifupdown. In this case, the configuration is as easy as: interface name=fpt1 type=ppp ppp type=pppoe options= depend_on=tap1 username=*** password=***/ network id=11 name=FPT1 auto=1/ /interface This is supposed to be easy to read and easy to edit by hand? It seems to me that a properly commented normal text configuration file would be much more appropriate to the task. I will not even comment on the rest of your examples, except to say that the Swiss Army Knife approach is certainly not in the *nix tradition. I do not have time to review the code right now. However, the abuse of XML that you call a configuration file really needs to be fixed In this software, XML is just a tool, it's totally separated from the main code. There is a script parsing the configuration and generating an equivalent Perl structure, and store it /var/run (caching mechanism), the primary code eval() that piece of code to import the configuration before running, so I may throw away the XML file and replace it with traditional conf format. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Request for comment: a new software to manage linux networking features
On Sun, Feb 17, 2008 at 11:20:48PM +0700, namnd wrote: * The configuration file is in XML so netupdown can handle sophisticated configuration. Editing the XML the configuration by hand or by software will be easy and comfortable. Editing XML by hand easy and comfortable?!? In which world? Best regards -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Request for comment: a new software to manage linux networking features
Hendrik Sattler wrote: Am Sonntag 17 Februar 2008 schrieb namnd: In this case, the configuration is as easy as: interface name=fpt1 type=ppp ppp type=pppoe options= depend_on=tap1 username=*** password=***/ network id=11 name=FPT1 auto=1/ /interface The ppp stanza should not contain authentication information. Especially since username/password only covers the most simple authentication method. And other parts could use a auth tag, too (ethernet, wlan, etc.). Additionally, the options attribute sounds like a work-around. Some people may want to put everything related to network config in 1 file to ease the management, other people may put it in /etc/ppp/chap-secrets or anywhere else, they are all supported. No doubt, each interface type may has its own authentication configuration (such as wlan interface will support WPA). The idea is that there is a template for external daemon (such as pppd, openvpn, vtun, ...) lying somewhere else, netupdown takes the template and fill the place holders with the content in the main config file, save the final conf file in /var/run, and starts the daemon. This template mechanism solves many problems fixed conf file can not do, such as binding local IP address to the dynamic IP address of a ppp interface. The options attribute is used for people who need to configure parameters aren't defined in the template, this work arround is necessary for some of my cases. Best regards, Nam -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Request for comment: a new software to manage linux networking features
Tzafrir Cohen wrote: It is part of the base system. And people will have to manipulate it even when the web interface is not available. Think of using globs and stats. Also think of creative usages of symlinks. Well, I guess that it is up to me to think (demonstrate fisibility) here. Otherwise I'm just talking :-( BTW: perl-base is part of the base system, but perl and perl-modules isn't. Thank you, Cohen, for your many comments, I'm likely to replace XML format by traditional conf format after receiving comments from several people. I'll try to inherit the format of /etc/network/interfaces if possible. My idea of using the package is not to replace ifupdown in the normal installer because many system requires a very simple network config, and ifupdown is much more compact. netupdown should be installed later by people having a complex network, like many people install /usr/bin/less to replace /bin/more, and vim to replace vim-tiny after finish installing the base Debian. Best regards, Nam -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Request for comment: a new software to manage linux networking features
namnd == namnd [EMAIL PROTECTED] writes: namnd To be short, I consider my software an evolution of ifupdown, so the namnd main part is called netupdown, the purpose of this software is to namnd use on corporate internet gateway, the main features of the software: Have you looked at netconf? It also claims it will solve problems with ifupdown. http://netconf.alioth.debian.org/ Also see presentation at LCA2008: http://mirror.linux.org.au/pub/linux.conf.au/2008/slides/072-netconf_lca2008_2008.01.31.tar.gz http://mirror.linux.org.au/pub/linux.conf.au/2008/Thu/mel8-072.ogg http://mirror.linux.org.au/pub/linux.conf.au/2008/Thu/mel8-072.spx -- Brian May [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Request for comment: a new software to manage linux networking features
also sprach namnd [EMAIL PROTECTED] [2008.02.17.1720 +0100]: My team have been developing a software for my company since 2004, now I have plan to release it to the public, hopefully in an open source license if the management board doesn't object. So I need the peer reviews from the community of the quality of the software […] 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: - what language are you using? - is this a daemon-based design? - how much internal state do you keep? - how extensible is the software? - how large is the code base? - 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)? - does your software handle wireless networks, including those configured by wpa_supplicant? 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. 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. 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. 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! -- .''`. martin f. krafft [EMAIL PROTECTED] : :' : proud Debian developer, author, administrator, and user `. `'` http://people.debian.org/~madduck - http://debiansystem.info `- Debian - when you have better things to do than fixing systems there is no place like ~ digital_signature_gpg.asc Description: Digital signature (see http://martin-krafft.net/gpg/)
Re: Request for comment: a new software to manage linux networking features
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]
Re: Request for comment: a new software to manage linux networking features
On lun, 2008-02-18 at 06:49 +0100, martin f krafft wrote: You are asking us to evaluate the quality of a software based only on the descriptions you provide. There was a link to the source code in the initial mail too. Cheers, -- Yves-Alexis signature.asc Description: This is a digitally signed message part
Re: Request for comment: a new software to manage linux networking features
also sprach martin f krafft [EMAIL PROTECTED] [2008.02.18.0843 +0100]: I really want to look at it, even though I am bad at Perl. Please try to release it. I am tempted to ask you to show it to me beforehand under a non-disclosure agreement, but then I might have difficulty keeping netconf clean, so I'd much rather have you open the code. Ah, thanks to Yves, I found the code. I am still not going to look at it before you make a clear statement about the licence because otherwise it might infiltrate how I write netconf code and we'll open a can of worms... -- .''`. martin f. krafft [EMAIL PROTECTED] : :' : proud Debian developer, author, administrator, and user `. `'` http://people.debian.org/~madduck - http://debiansystem.info `- Debian - when you have better things to do than fixing systems if I can't dance, i don't want to be part of your revolution. - emma goldman digital_signature_gpg.asc Description: Digital signature (see http://martin-krafft.net/gpg/)
Re: Request for comment: a new software to manage linux networking features
also sprach namnd [EMAIL PROTECTED] [2008.02.18.0750 +0100]: - 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. This is one of the reasons why I started netconf: stateful configuration is really bad because it's very difficult to keep the stored state and the real world in sync. netconf tries to have minimal state only, which makes it quite a challenge. However, I think it's worth it. Anyone who has been told by ifup that the interface is already configured when it in fact is not knows what I mean. This is a simple example, but it's an important thing to realise. - how large is the code base? Very compact, about 1500 lines in Perl, other stuff doesn't count. I really want to look at it, even though I am bad at Perl. Please try to release it. I am tempted to ask you to show it to me beforehand under a non-disclosure agreement, but then I might have difficulty keeping netconf clean, so I'd much rather have you open the code. 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. I am interested in knowing more about how you do this. For instance, how would you add a ccd profile to the openvpn configuration, or an iroute, or a hook? 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 This cannot be answered in advance, you'll have to try it. 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 :( I think with enough maturity, they can. :) Python is really easy to work with. I tried Perl a couple of times and it's just very complex. Thus, I went down the Python route and have never looked back. However, I find it very difficult to work on Perl projects, such as ikiwiki. I would like to, and I don't have anything against Perl (nothing religious anyway), but it's just a very steep learning curve I cannot climb at the moment for lack of time. I still argue that Python doesn't have this learning curve, so it should be a lot easier for Perl people to work on Python, than the other way around. -- .''`. martin f. krafft [EMAIL PROTECTED] : :' : proud Debian developer, author, administrator, and user `. `'` http://people.debian.org/~madduck - http://debiansystem.info `- Debian - when you have better things to do than fixing systems always remember you're unique, just like everyone else. digital_signature_gpg.asc Description: Digital signature (see http://martin-krafft.net/gpg/)
