Skip to Content.
Sympa Menu

sm-discuss - Re: [SM-Discuss] udev module loading order

sm-discuss AT lists.ibiblio.org

Subject: Public SourceMage Discussion List

List archive

Chronological Thread  
  • From: Juuso Alasuutari <iuso AT sourcemage.org>
  • To: sm-discuss AT lists.ibiblio.org
  • Subject: Re: [SM-Discuss] udev module loading order
  • Date: Sat, 15 Apr 2006 00:26:19 +0300

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




Archive powered by MHonArc 2.6.24.

Top of Page