On Thursday 04 December 2008 20:29:26 Soren Hansen wrote: > > I disagree to an extent, the problem doesn't sound specific to > > wpa_supplicant's shell glue at all, > > If wpasupplicant tells ifupdown that it's done configuring the > interface, and that everything went fine, but it that's not actually the > case... That's wrong. No matter how you look at it. It is, in my opinion, a pitfall of the design of ifupdown, as explained later in this email. > > > but rather, the inflexibility of the statically maintained ifupdown > > software on an ever evolving Debian/Ubuntu software ecosystem. > > What exactly do you mean by "statically maintained"? Sorry for poor choice of words. It means that ifupdown software, in my opinion, is in deep maintenance mode and is no longer actively developed. Meanwhile, the Debian and Ubuntu systems and the demands of users of the named systems evolve at a very rapid pace, especially when compared to ifupdown's progress in the same time period. > > > A "cheap" fix could be included in an individual ifupdown hook script, > > but it strikes me that the central network dispatcher/configurator > > framework should be striving to handle situations such as that > > described, as future hooks may also fall prey to this pitfall. > > "situations such as that described"? You mean a particular application > having specific needs? It's not ifupdown's responsibility to know about > all these things. If wpasupplicant doesn't know when it can expect to be > succesful, how on earth should ifupdown know? So the problems as I see them are: * wpa_supplicant to the best of my knowledge requires stuff from /usr at runtime, but is unable to signal/communicate with ifupdown to let it know that. * The wpasupplicant package installs its binaries to /sbin, which makes it seem like the binaries can be used in operations which occur at early boot when /usr is unmounted, but in fact they cannot. * wpa_supplicant is executed via shell scripts which are installed as conffiles and must also adhere to the Debian policy that applies to conffiles. The conffile is unable to know whether a required binary has been removed, or if it is simply not available yet because the system is in an early stage of system initialization and /usr is on another filesystem which is still to be mounted. Firstly, the case of requiring /usr is not wpa_supplicant specific. For example iw will require libnl from /usr in future if libnl doesn't change [1]. [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=499537#22 Secondly, wpa_supplicant and wpa_cli live in /sbin and not /usr/sbin. The speculation that i've read in this report which hightlights the following code is the cause of the problem is likely invalid: > # quit if executables are not installed > if [ ! -x "$WPA_SUP_BIN" ] || [ ! -x "$WPA_CLI_BIN" ]; then > exit 0 > fi because: > WPA_SUP_BIN="/sbin/wpa_supplicant" > WPA_CLI_BIN="/sbin/wpa_cli" The most likely reason that wpa_supplicant fails to do anything at early boot sequence with an unmounted /usr is related to fact it links with stuff there. Someone could redirect stdout and stderr via exec trick to a logfile to try and capture any error that wpa_supplicant outputs when invoked. > > Leaving this decision to each of the modular network configuration > things is the right thing to do. I don't see any reason at all why you'd > want to put something like that into ifupdown. > You did not present any facts that support your claim to know what the right thing to do is that I could read after skimming the Launchpad bug discussion at LP#44194. I also find that the words you have written in parts of this discussion, to myself but mostly Reinhard, have made me "feel" a bit negative in attitude towards you and leaves me with more motivation to ignore this Ubuntu problem then help discuss and resolve it. The individual ifupdown plugins should handle all things related to the individual component that they are mandated to make work and should not be independently handling generic system wide problems such as waiting for /usr to become available. That is the job of the network configuration framework, which in this case is ifupdown. The plugins do not even have the ability to give feedback to the framework, nor is there any facility to make sure plugins are executed in correct sequence, nor is there any way to influence other plugins once an error condition is encountered. All ifupdown does is trigger a series of configuration events and hope for the best. Plugin's do not have the ability to tell if a binary is uninstalled or on a volume which is not mounted. If such logic was hacked in to one plugin, what about the next plugin which falls to the same pitfall. Fixing generic problems in seperate, isolated scripts seems like a less useful thing to do than provide a solution that can be taken advantage of by all scripts which require a general solution now and in the future. This solution would most likely be at the point which the signal to configure a network interface from the system is recieved, but before the events which perform the step to completely configure the interface; in this case it is ifupdown. .o0( I am sure the netconf [2] (shameless plug) guru's would have some advice about this problem, as their motivation stems from the fact that the current choice of network configuration frameworks have a few pitfalls. [2] http://netconf.alioth.debian.org/ ) Thanks, Kel.