Public SourceMage Discussion List

[Juuso Alasuutari <iuso AT sourcemage.org>]

On Friday 14 April 2006 12:57, Mads Laursen wrote:
> > > Perhaps the network configuration tool could do that? Either by adding
> > > the setup to 00-binding.rules or to the .dev files in
> > > /etc/sysconfig/network.
> >
> > I'm not yet sure what tool would qualify for this. But I think we have to
> > add udev rules. I don't see what use the .dev files would be, other than
> > maybe to act as reminders in case something is lost.
>
> The tool i was thinking of is our netconf command, in which you can
> setup the networking.

Yeah, this does sound logical.

> > > How much magic can udev actually invoke when figuring out the names of
> > > things?
> >
> > I don't understand what you mean by this, could you explain?
>
> I'm thinking that it might be nicer to have a MAC field in eth?.dev
> and have the line in oo-binding.rules call a script that looks into
> the .dev files for a match and figures out the name that way. It could
> perhaps allow us to setup new default .dev files for newly added
> interfaces.

It would indeed probably be good to store MACs with netconf. But I'm not sure 
if bending udev like that is viable. It'd be much simpler to just make 
netconf modify the rules without any. I'm not even sure if what you suggested 
is possible.

> The reason I'm suggesting this is, that I think it would be a lot
> nicer to keep all the network(-card) config in /etc/sysconfig/network
> instead of spreading it out over more files. And the format is also
> simple enough that something like netconf actually works quite nicely.

True, of course we don't need loose ends hanging around. But udev rules are 
udev rules, they need to have info such as MAC addresses if they are to work. 
I don't think that has anything to do with decentralization. Or am I mistaken 
with what you're saying?

> In fact I'm thinking that maybe stuff like ifplugd and wpa_supplicant
> would be nicer if their _per-interface_ config was also in eth?.dev,
> if they are installed? Maybe have a plugin dir that netconf scans for
> scripts that add features, and then each screen would display its
> default options plus any that was added by a plugin?

I think the placement of ifplugd and wpa_supplicant config files is also a 
question of what comes natural or is necessary. It would be counterproductive 
for netconf to assume a "master configurator" role over these programs. 
Ifplugd has a simple config file which will be very easy for netconf to read 
and modify when needed, so there's no need to reinvent the wheel by 
assimilating ifplugd settings to the .dev files.
Also I don't think it's netconf's job at all to store wpa_supplicant data. 
Netconf configures how the interfaces function, which doesn't include 
specific wifi station settings. Of course if/when we write a utility that is 
meant to ease wireless login management, it can store access point -specific 
data and use that when talking to wpa_supplicant.

> The reason I looked at gnome-system-tools is that they claim to do
> some xml-based frontend/backend stuff, so perhaps we could have a
> backend that does what netconf does and suddenly we can choose to use
> $EDITOR, netconf, or the gnome gui - all using the same config-files.
> But of cause somebody has to do the backend, so unless I get
> interested enough and find the time to do it, I guess it will just sit
> there. BTW it is a required depend of gnome-profile and the only tools
> that work in it is the boot (grub) editor and possibly the gdm
> configurator (but that one doesn't understand how to ask for the root
> password).

At this point I'm not a fan of splitting netconf into a front- and backend. I 
feel that now our main task is to ensure smooth operation and configuration 
of various networking tasks. Netconf is far from ready, although it is 
advancing. But that doesn't mean that your idea isn't viable. In fact, I 
think that eventually we should have most if not all our programs done that 
way.
That's also the reason why I don't like the idea of storing other programs' 
settings in netconf. Having programs work separately keeps the whole 
system "airy" and flexible. And isn't that exactly the reason why utilities 
are split into front- and backends? Netconf should be a frontend to ifplugd 
(like it is to dhcpcd now), not its mother. :)

> On the other hand I think wpa_supplicant can handle all kinds of
> network setups, so maybe I just need to improve the setup.

That's what I think, too. It goes along well with ifplugd: when you run 
wpa_supplicant with the right config so that it connects to an access point, 
ifplugd reacts to that (as if someone had just plugged a network cable) and 
launches ifup. :)

The downside to wpa_supplicant is that it doesn't seem to understand config 
files with more than one entry. So I have to have diff files for each wifi 
station I connect to.

> Do you have anything clever to run wpa_supplicant - init-script or
> something? It does not seem to have anything included in the spell.

No, I just run wpa_supplicant like this:
wpa_supplicant -i wlan -D wext -B -w -c /path/to/config.file
And then ifplugd magically connects me.

I've also thought of writing a script/daemon that manages wpa_supplicant. 
Here's what it should do:
- Monitor available access points using 'iwlist scan'
- When told to connect to a network, query for password/key if needed, and 
launch wpa_supplicant with settings parsed from iwlist (settings can be given 
to wpa_supplicant straight from command line without the need for a config 
file). Basic settings like interface name and driver can be extracted from a 
preconfigured file.


I'm sorry, but at this point I've completely run out of energy to write. :) 
Anyway I think you have some nice ideas about backends and so on, we just 
need to take one step at a time and carefully consider the options.

I hope ifplugd is working for you already!

Juuso