[pkg-wpa-devel] Bug#537790: Bug#537790: wpa_supplicant references dynamic libs in /usr/lib; will not run at boot

[Stefan Lippers-Hollmann]

Hi

On Saturday 29 March 2014, Cameron Norman wrote:
> This bug can be seen in Upstart (#694963), and hangs boot in a NFS 
> mounted /usr, as well as errors the network setup when one uses "auto" 
> in /etc/network/interfaces. Here is the output of ldd, with the libs in 
> /usr bolded (HTML):

[ please avoid HTML Mails, they're very likely to be eaten by antispam
  measures along their way ]

As you see in the bugreport, this is a long standing issue, which is
only partially under our control. Actually the situation has been 
improved significantly during the last release cycle with many of the
required libraries moving from /usr/lib/ to /lib/ already. What remains
is libssl1.0.0, as libpcsclite can be avoided, but actually working on
that (which is a bit problematic on kfreebsd-any) doesn't make sense
before the hard-dependency is out of the way (libssl).

So yes, wpa_supplicant being in /sbin/ is a bug, done ages ago by 
previous maintainers of the package. However moving it to /usr/ isn't
a solution either, as wpa_supplicant is heavily used in local 
configuration scripts, which may break hard if wpa_supplicant were to
disappear from /sbin/ (and introducing a compatibility symlink from 
/sbin/wpa_supplicant to /usr/sbin/ wouldn't actually gain you 
anything in practice, other than papering over the problem). And 
technically speaking you do want the stuff needed to bring up the 
network outside of /usr/.

That said, trying to mount any remote filesystem over wlan at the 
kernel level, even more so for vital filesystems just as /usr/, /var/
or /tmp/ would be plainly insane, as you do have to expect interruption
with wlan for any real world deployment (which would make your system
hang, if vital parts are mounted over wlan). Likewise 'auto' is usually
not a good configuration for wireless interfaces either, as -like you 
mentioned- this does block booting until a connection has been 
established, which is something you can't guarantee for wlan - not even
for a static system.

So what are the options to fix this?
- the ideal fix for this would be to move libssl into /lib/, which
  is outside of our domain and depends on the openssl maintainer.
  Combined with using weak symbols for the libpcsclite dependency[1] 
  (this has been tried already, but failed on kfreebsd-any - although 
  this is fixable given enough attention), this would close the bug 
  once and for all. However anyone mounting /usr/ over a wireless link 
  would still be insane, even if this were possible from the policy 
  side of it.
- another approach would be mounting /usr/, along the rootfs, from 
  within the initramfs environment, to the best of my knowledge this
  has been planned for quite a while already (and should even be 
  possible in experimental, iirc rleigh's efforts correctly).
- moving wpa_supplicant from the rootfs into /usr/ would fullfill the
  letter of the FHS and Debian policy, but wouldn't actually solve this
  problem at all (combined with a lot of pain in breaking lots of local
  configuration). Still, doing this would be the easiest option for us
  to close this bug (so consider me happy to oblige) - but that's not 
  really helping anyone in practice.

Whatever we end up with, you won't *ever* be able to depend on wireless
links for reliable operations or mounting vital parts of your 
filesystem tree remotely. It just is, by definition, an unreliable 
network connection in practice (just about anywhere outside of lab 
environments). While you may not notice short interruptions for 
browsing the web (other than some log spam talking about reconnecting),
the kernel (and nfsd in particular) doesn't like stalled network 
connections for mounted remote filesystems at all. Any assumptions
relying on stable (and early boot) availability of wireless links are
simply flawed, even if the the FHS issues were fixed.

Regards
	Stefan Lippers-Hollmann

[1]	using weak symbols for libpcsclite would reduce the breakage to
	wpa_supplicant configurations reading wpa credentials from 
	smartcards, which is a corner-case I'd be willing to risk.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.alioth.debian.org/pipermail/pkg-wpa-devel/attachments/20140329/bc8f9b4b/attachment.sig>