On 4/1/07, Thomas Bächler <thomas@archlinux.org> wrote:

Hi James,

I am not saying I don't appreciate your work, but I am posting here to point out a few things I don't like about our old and new network scripts (more for general discussion than related to your specific efforts):

A network "profile" is always only one interface. I'd expect a profile to be several interfaces that are activated all at once and are sort of tied together (I didn't read your latest version yet, did you already add such a thing?).

That leads me to the second: While configuration via bash-script is easy for the programmer (you can simply parse it via 'source'), it is unsafe and becomes rather complicated when features are added. Especially when we want more than one interface in a profile, it becomes messy. I would suggest a inifile-like configuration style where each section '[foo]' marks an interface. This is much more readable to the user and allows more flexibility but itis not as easy to work with.

Last but not least, invoking our netcfg tool from a GUI or any other external application is not optimal. netcfg is a shell script, but IMO should be a library. We could then have proper bindings to C/C++/python and so on. Also, when it becomes more complicated, writing bash becomes ugly very fast.

I actually started a little C++ implementation of the above ideas, but got lost in bison/flex soon (anyone wanna give me a crash course on how to do it right? I have a parser that works good enough so I can start experimenting, but nothing fool-proof). I may or may not continue this work soon. The current state is this: Nothing works, I have many ideas, a highly experimental framework and hopefully some free time soon.

Open for discussion :)

I think getting too complex with configuration tools is not the best idea. I do, however agree that the profile-to-interface mapping should be a one-to-many mapping. Regarding the "using bash is unsafe" thing, you could say that's true only if this person making it "unsafe" has root access - if it is the owner, it's their fault if they make something unsafe. If it is a third party, you have more problems than just network configuration being unsafe. Also, if bash is unsafe, we need to rewrite rc.conf, makepkg, and probably a hundred other utilities. Dan and I might be willing to accept patches for a binary makepkg, so feel free.

James schrieb:

one-to-many, multi support is included.

I'll have a closer look then :)

I designed these so they were clear and easy to work with. Documentation needs a bit of work, but making changes anywhere is very simple. And more approachable than C. Not sure how it's 'unsafe'

I'll also have a closer look at that. By 'unsafe' I meant the scope gotchas you mention below, as well as error handling: if you do something wrong, there will be no "parse error" message, but just weird things happening. And - of course - if a third party has rights to change config files, they could exploit that easily.

The bash is fairly simple and readable too though.

Sometimes it is, but network configuration can become rather complex.

Is there such a demand though? Arch has always tended away from GUI tools. I'd rather not switch to a C implementation, just so we can make writing GUI's easier.

There is a demand. People want to configure their wireless when they change their location, they want to configure their network when they plug a cable in and so on. Arch is design to not depend on GUI tools, but having them does not hurt. With a bash netcfg, we need to invoke it and parse the output everytime we change something, or simply reimplement its functionality. That is not good for a GUI.

And that's the state of many Arch projects. Arch has needed these scripts for *ages* and nobody else has had any interest. There is a need though, every day, there's still multiple new threads on the forums with wireless and other networking problems. And simply, the current scripts do not cater nicely towards > 1 network per interface.

You can write C based scripts, but unless you knuckle down and work on them, I doubt we'll see them before the end of the year. If they do appear, they won't have reached the stage of the bash scripts before us.

This is the problem we have, ideas are raised, but we don't have enough implementers.

You are absolutely right about that. It is great that you spent so much time on the scripts and I hope they work great. As I said, I added this item for general discussion and my efforts are only experimental.

...

I think getting too complex with configuration tools is not the best idea. I do, however agree that the profile-to-interface mapping should be a one-to-many mapping.

one-to-many available in these.

That is great. IMO, the disadvantage here is that we need several configuration files for them (that is the approach I made when I hacked with your original scripts, but got lost in bash scope stuff). Do you know a cool bash-parsable configuration file layout where we could put them into one file?

...

Also, if bash is unsafe, we need to rewrite rc.conf, makepkg, and probably a hundred other utilities. Dan and I might be willing to accept patches for a binary makepkg, so feel free.

Aye, so many of arch's scripts are written in bash. These network scripts as they're implemented, are simpler and tidier than many other things i've seen come out of Arch...

I wanted to try something different to be able to put more configuration into one file and still stay readable. If you say that the network scripts are nicely implemented, then I believe you and will indeed look at them more carefully tonight (I was just too tired yesterday, so I added my thoughts and didn't read the latest version of the scripts).

However..... we could make a compromise, a halfway.

If we could design a better config file, and then write a C(++) based program to parse this file and spit out requested variables, then we could have a tidier and better implementation in many aspects. We could keep the simplicity of the bash scripts, and allow the extra power of a better config file.

That would be worth looking into.

James schrieb:

Arrays is the only thing I can think of,

PROFILE='multi' KEY[0]=something CONNECTION[0]='somehing else'

Or...

CONNECTION="multi" HOME_CONNECTION="wireless" HOME_KEY="sdasdsa" WORK_CONNECTION="ethernet" WORK_IP="dsaomdsadas" NETWORKS=(HOME WORK)

Or.......... my dream setup, ala bsd

home="connection wireless key 12346 interface ipw0" main="connection multi childs home,work "

but it's very nasty to parse -- not impossible though, I have done it in experiments -- and involves wrapping all of the iwconfig and ifconfig options to acheive an equivalent functionality level. wrapping that many is icky.

Another idea, completely using bash-style: INTERFACES=('if1' 'if2' 'if3') profile_if1() { [options for if1] } profile_if2() { [options for if2] } profile_if3() { [options for if3] } Then source the file, and 'eval profile_$i', then set up the interface. But it would be more difficult for the average user.

...

That would be worth looking into.

Further thoughts, and implementation idea: I thought about an ini style config. That could work *really* well. I don't want to drop the bash side of these either, it'll be too long before we see something new, and these work well, I havn't picked up any new bugs for a few days now... not to say they don't exist.

So... a Csomething based parser of ini files. Would be totally awesome. [main] connection=wireless key=something security=super

Orr.... another file.... ------ [main] connection=multi profiles=home something else [home] connection=wireless [something] connection=ethernet ------- .... and you get the idea.

If I could run: netini main.connection and get the value from the ini file, I'll rewrite these netscripts in a night and they will work far better, and the codebase will be far better.

As I said, I have a partially working parser in flex/bison, but I don't think I did it right. It may be a good idea, though I would suggest this format: generaloption1=foobar dns="1.2.3.4 5.6.7.8" [interface1] someoptions=somevalue otheroption="other value" [interface2] moreoptions="more values" We could parse it like that: calling 'netini profilename' would return generaloption1=foobar dns="1.2.3.4 5.6.7.8" INTERFACE_LIST=('interface1' 'interface2') Later you would call 'netini profilename interface1' which would return the options for interface1. You could eval those in the scripts. I think this would make a very readable configuration. And the parser is definitely possible in C or C++ easily, if you worked with bison before. If someone will give me a crash course on how to do that right, I could take care of that.

Roman Kyrylych schrieb:

Why not just use any freely available ini parsing lib? iniparser and confuse are in community

Thanks, will look at it.

On 4/4/07, James <iphitus@gmail.com> wrote:

I havn't actually written anything in C for a long time, this was based on the example and some fumbling so... criticism is welcome I guess. Depends on iniparser in community.

Only point would be that returning 2 and 3 from main are sort of undefined (only 1 and 0 are standard)... I wouldn't use numbers to indicate where it failed like that, though that's personal preference... I'd just return 1 for any error. Another think that *might* be useful depending on the lib: - fprintf(stderr, "Cannot parse file [%s]\n", file); + fprintf(stderr, "Cannot parse file [%s]: %s\n", + file, strerror(errno));

Dan McGee schrieb:

Small thing too- we should just statically link to iniparser in the final product, in order to not make it a runtime depend.

It doesn't have a shared library anyway, you can only link it statically.