Re: (solved) Re: wireless fail after stretch installation
On Wed 07 Mar 2018 at 13:25:16 (+0000), Ian Jackson wrote:
> bw writes ("Re: (solved) Re: wireless fail after stretch installation"):
> > On Tue, 6 Mar 2018, Brian wrote:
> > > One user calls it a "sick joke". After five years and with no attempt
> > > to rectify the situation, I'm beginning to have sympathy with that view.
>
> Debian, like all ordinary software, is full of bugs. Many bugs
> languish unfixed for years. This is not malice, or a "sick joke".
> It's just that there is too much to do and too few people to do it.
I'm afraid I've been misquoted. The exchange was (my lines are marked ★):
--✄--------
> How connectivity is re-established on a machine with only a wireless
> interface is left as an exercise for the user.
This is some sort of sick joke. ★
--✄--------
https://lists.debian.org/debian-user/2018/02/msg00015.html
> There are rare cases where horrible people deliberately sabotage
> things. They are very high profile because they are so outrageous,
> but they are not the norm. I see no evidence in relation to this bug
> that anyone is sabotaging anything.
I made no accusations of sabotage. Again:
--✄--------
> > > So this must be intentioal, wouldn't you say?
> >
> > No. ★
[…]
> > > And this is also clearly intentional.
> >
> > Intended to do what? ★
>
> To leave the user without network connectivity after first boot? There
> are at least three bug reports against netcfg on the matter. My
> recollection is that no deeper intention is revealed there.
[…]
Yes, I don't think the intentions are deeper, but just that simple ★
cases have been overlooked, and overlooked for several years. ★
--✄--------
The thing that seemed odd to me when I examined the log was that the
installer removed the wireless configuration right at the last moment,
with no method of circumventing it.
On discovering the udeb package called netcfg and looking through its
bugs, it seemed that the network connection was torn down (with good
reason, to do with DHCP leases perhaps) but then the configuration
itself was also torn down, and this was considered a good thing for
reasons I couldn't fathom, and which seemed to forget the case of a
wireless interface and its intended future use of ifupdown with /e/n/i
after rebooting.
> The correct approach to this bug is to figure out how to fix it, and
> send a patch.
>
> > Brute forcing this thing with wifi to /e/n/i might not be the best
> > approach? What about people who want a different config than the
> > installer? What about people who don;t want to be UP (auto) on bootup?
> > What about static configs? Wifi is by nature a mobile environment, what
> > about security or several devices? Let's help the devs by hashing out the
> > pros and cons and making a coherent proposal?
>
> We are considering the situation where the user has installed a
> barebones system, with no GUI network management tools.
>
> Such a user will probably *expect* to edit a configuration file when
> they want to change their network configuration, whether because their
> needs change, or because their needs are different to those of the
> majority of people.
>
> Consequently, there is no problem in principle with setting up /e/n/i
> to have the wifi configuration from the install. That is what most
> people who do this will want; and if it doesn't suit them, they can
> change it. (It is easier to change it or delete it, than it is to set
> it up from scratch.)
Yes, that's just what I had originally expected, and would be great.
> AFAICT from reading #694068, the reason d-i currently strips this
> information out of the installed system is because it contains the
> wifi password in /e/n/i, a world-readable file. That would obviously
> be wrong.
The odd thing about this reasoning was that I seem to recall several
generations ago (more than ten years?) finding that /e/n/i was not
world-readable upon installation. (If this was when I was using ppp/
mgetty/CHAPS etc, it would be pre-2004. I could be misremembering here.)
> Someone should implement and test the suggestion made by Trent Buck,
> here,
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=694068#47
>
> Specifically:
>
> | If you don't want to udebify wpa_passphrase, you can do it by hand:
> |
> | cat >"/etc/wpa_supplicant/wpa_supplicant-$iface.conf" <<EOF
> | network={
> | ssid="$ssid"
> | psk="$passphrase"
> | }
> | EOF
>
> This should be arranged in the appropriate bit of d-i, so that the
> installed system works the same way as the installer.
That would be a great improvement, and with least surprise.
BTW if you read right to the end of
https://lists.debian.org/debian-user/2018/02/msg00015.html
the last sentence is meant to be a reference to our
Great Leader's Orwellian press briefings.
Cheers,
David.
Reply to: