Re: (solved) Re: wireless fail after stretch installation

2018-03-10 Thread Brian
At some point Jude DaShiell Cc'ed -devel. This accounts for some of the
traffic in this thread. I am also Cc'ing -devel. You didn't, but I am
not trimming any of your post; nor am I replying to every portion in
it.


On Sat 10 Mar 2018 at 09:53:58 -0600, David Wright wrote:

> On Wed 07 Mar 2018 at 13:25:16 (+), 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

Many apologies for quoting out of context.

> > 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.
> 
> […]

The word "deliberately" was picked up and labelled as giving the message
an unfortunate tone and then linked with "deliberately breaking stuff".
A deliberate action need not be done with malice and there was nothing
in what I said which put ill-intent forward as a reason.

> 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 conta

Re: (solved) Re: wireless fail after stretch installation

2018-03-08 Thread Jude DaShiell
So, debian installer does not use wpa_passphrase on the wireless 
password as it is entered.  Had that been done no reason would exist to 
strip out connectivity files from the installation.


On Wed, 7 Mar 2018, Ian Jackson wrote:


Date: Wed, 7 Mar 2018 08:25:16
From: Ian Jackson <ijack...@chiark.greenend.org.uk>
To: bw <bwtn...@yahoo.com>
Cc: debian-u...@lists.debian.org, debian-devel@lists.debian.org
Newsgroups: chiark.mail.debian.devel
Subject: Re: (solved) Re: wireless fail after stretch installation
Resent-Date: Wed,  7 Mar 2018 13:25:34 + (UTC)
Resent-From: debian-u...@lists.debian.org

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.

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.

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.)

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.

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" <

--



Re: (solved) Re: wireless fail after stretch installation

2018-03-07 Thread Ian Jackson
bw writes ("Re: (solved) Re: wireless fail after stretch installation"):
> On Tue, 6 Mar 2018, Ian Jackson wrote:
> > I have read the bug logs and Trent Buck's message here
> >   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=694068#47
> > seems to suggest a way forward.
> > 
> > Perhaps someone would care to write and test a patch to d-i's network
> > configuration arrangements, to implement Trent's suggestion ?  I think
> > that the people who don't have network-manager would probably prefer
> > this to use ifupdown, and making a whole new udeb will be work, so
> > Trent's second suggestion seems sensible.
> 
> Second suggestion being networkd preferred over ifupdown?  yeah, I had 
> thought this was going to come up eventually.  State it in plain english, 
> if ifupdown is to be replaced, then let's get on with it.

I appreciate that you have reason for your paranoia, but in this case
it is entirely misplaced.  You have misunderstood me.  I meant this
part of Trent's suggestion:

|  If you don't want to udebify wpa_passphrase, you can do it by hand:
|
|  cat >"/etc/wpa_supplicant/wpa_supplicant-$iface.conf" < I think the whole thread is unfortunate, because it was started by a 
> person (Long Wind) who earlier posted a request for help about how to hack 
> into their neighbor's wireless network to steal internet service.

"Whatever".  Now, this thread is about Bug#694068.  Which is annoying
a number of people and should be fixed.

> I'm really shocked that anybody would try and make wireless easier to use 
> for thieves.  They should be shunned, not used as example clueless users 
> to implement fixes or new features.

I struggle to see how fixing #694068 is about helping "thieves".

Ian.

-- 
Ian Jackson <ijack...@chiark.greenend.org.uk>   These opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.



Re: (solved) Re: wireless fail after stretch installation

2018-03-07 Thread Ian Jackson
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.

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.

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.)

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.

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" <   These opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.



Re: (solved) Re: wireless fail after stretch installation

2018-03-06 Thread Brian
On Tue 06 Mar 2018 at 18:34:27 +, Ian Jackson wrote:

> bw writes ("Re: (solved) Re: wireless fail after stretch installation"):
> > I think the idea needs to be talked over a little better, because using 
> > e/n/i for wireless by default after first boot has implications if the 
> > user (who is clueless) later installs a desktop environment.
> 
> If installing a desktop environment, after putting the wireless in
> /e/n/i, does not work, then that is a bug in the desktop environment,
> surely ?

Most probably. But desktop environments were not the subject of this
thread. (Sorry for trying to keep on-topic).

> In practice I would expect the config in /e/n/i to keep working
> because nowadays network-manager will ignore things in /e/n/i.  The
> difficulty would only come if you
>   - used the installer to install a bare system over wifi

That difficulty is  exactly the subject of this thread. The rest of this
post is snipped because it side-steps addressing the issue. What is put
in /e/n/i ceases to work because it is obliterated by the installer for
reasons unknown.

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.

(Yes, I know we are all volunteers).

-- 
Brian.




>   - later install network-manager or wicd
>   - then expect the system to give you a gui prompt for new wifi
> networks, rather than expect to have to edit /e/n/i
> 
> It would be possible for the n-m and wicd packages to spot when this
> is happening and offer to take over the interface.  And I do think
> that in the absence of code to do that, it would be more important to
> make the barebones system work in the first place, than to improve the
> behaviour you later install n-m.
> 
> (I'm not sure if what I say about wicd is right.  I use n-m on
> machines I have where the user needs to switch between various network
> connections, wifi networks, etc.)
> 
> > I'd hate to see the bug tracker turned into a discussion forum though.  
> 
> The bug tyracker is precisely the right place to discuss how to solve
> a particular bug.  So I have CC'd it.
> 
> Ian.
> 
> -- 
> Ian Jackson <ijack...@chiark.greenend.org.uk>   These opinions are my own.
> 
> If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
> a private address which bypasses my fierce spamfilter.
> 



Re: (solved) Re: wireless fail after stretch installation

2018-03-06 Thread Brian Potkin
On Tue 06 Mar 2018 at 18:27:29 +, Ian Jackson wrote:

> Brian writes ("Re: (solved) Re: wireless fail after stretch installation"):
> > #694068, #696755, #727740 and #777439.
> 
> Thanks.
> 
> I have read the bug logs and Trent Buck's message here
>   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=694068#47
> seems to suggest a way forward.
> 
> Perhaps someone would care to write and test a patch to d-i's network
> configuration arrangements, to implement Trent's suggestion ?  I think
> that the people who don't have network-manager would probably prefer
> this to use ifupdown, and making a whole new udeb will be work, so
> Trent's second suggestion seems sensible.

I would hazard a guess and say that 100% of users would expect to be
able to use the network they have set up during installation, afterwards.
Without an ethernet interface on the machine it becomes resorting to
setting it up again (5%), resorting to -user or the internet from
another machine (20%) or some head-scratching followed by walking away.
(The percentages are rough estimates).
 
> > > > The plain and simple fact is that a user who installs over a wireless
> > > > link and does not have network-manager does not have any connectivity
> > > > to the internet after first boot. Long Wind solved the issue by taking
> > > > the advice given and Charlie S used his initiative and knowledge to
> > > > devise an /e/n/i file which replaced the one the installer had wiped
> > > > out.
> > > > 
> > > > This has been going on since Debian 7.0.0 and is not the first time the
> > > > issue has arisen here. Debian must be the only OS which deliberately
> > > > removes connectivity present during installation.
> 
> I have to say that the tone of this message is rather unfortunate.
> You make it sound like someone is deliberately breaking stuff.  That
> doesn't seem to be the case.

The message was written to -user. Besides having a really helpful bunch
of users, there can sometimes be a robustness and directness to the
exchanges. Don't let it put you off if you are used to a more gentile
environment.

I hadn't realised the breakage was accidental and unplanned. OTOH, I am
not in possession of the reasons behind it; apart from some conjecture,
they still remain unknown. As you will see from the bug record, even
Debian developers are mystified.

> Comparing to other distros can be very helpful but generalised
> statements that they don't have this bug is less useful than looking
> into how they solve the problem.

We don't know what the problem is.

-- 
Brian.



Re: (solved) Re: wireless fail after stretch installation

2018-03-06 Thread Ian Jackson
bw writes ("Re: (solved) Re: wireless fail after stretch installation"):
> I think the idea needs to be talked over a little better, because using 
> e/n/i for wireless by default after first boot has implications if the 
> user (who is clueless) later installs a desktop environment.

If installing a desktop environment, after putting the wireless in
/e/n/i, does not work, then that is a bug in the desktop environment,
surely ?

In practice I would expect the config in /e/n/i to keep working
because nowadays network-manager will ignore things in /e/n/i.  The
difficulty would only come if you
  - used the installer to install a bare system over wifi
  - later install network-manager or wicd
  - then expect the system to give you a gui prompt for new wifi
networks, rather than expect to have to edit /e/n/i

It would be possible for the n-m and wicd packages to spot when this
is happening and offer to take over the interface.  And I do think
that in the absence of code to do that, it would be more important to
make the barebones system work in the first place, than to improve the
behaviour you later install n-m.

(I'm not sure if what I say about wicd is right.  I use n-m on
machines I have where the user needs to switch between various network
connections, wifi networks, etc.)

> I'd hate to see the bug tracker turned into a discussion forum though.  

The bug tyracker is precisely the right place to discuss how to solve
a particular bug.  So I have CC'd it.

Ian.

-- 
Ian Jackson <ijack...@chiark.greenend.org.uk>   These opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.



Re: (solved) Re: wireless fail after stretch installation

2018-03-06 Thread Ian Jackson
Brian writes ("Re: (solved) Re: wireless fail after stretch installation"):
> #694068, #696755, #727740 and #777439.

Thanks.

I have read the bug logs and Trent Buck's message here
  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=694068#47
seems to suggest a way forward.

Perhaps someone would care to write and test a patch to d-i's network
configuration arrangements, to implement Trent's suggestion ?  I think
that the people who don't have network-manager would probably prefer
this to use ifupdown, and making a whole new udeb will be work, so
Trent's second suggestion seems sensible.

> > > The plain and simple fact is that a user who installs over a wireless
> > > link and does not have network-manager does not have any connectivity
> > > to the internet after first boot. Long Wind solved the issue by taking
> > > the advice given and Charlie S used his initiative and knowledge to
> > > devise an /e/n/i file which replaced the one the installer had wiped
> > > out.
> > > 
> > > This has been going on since Debian 7.0.0 and is not the first time the
> > > issue has arisen here. Debian must be the only OS which deliberately
> > > removes connectivity present during installation.

I have to say that the tone of this message is rather unfortunate.
You make it sound like someone is deliberately breaking stuff.  That
doesn't seem to be the case.

Comparing to other distros can be very helpful but generalised
statements that they don't have this bug is less useful than looking
into how they solve the problem.

Ian.

-- 
Ian Jackson <ijack...@chiark.greenend.org.uk>   These opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.



Re: (solved) Re: wireless fail after stretch installation

2018-03-06 Thread Brian
On Tue 06 Mar 2018 at 15:01:03 +, Ian Jackson wrote:

> Brian writes ("Re: (solved) Re: wireless fail after stretch installation"):
> > The plain and simple fact is that a user who installs over a wireless
> > link and does not have network-manager does not have any connectivity
> > to the internet after first boot. Long Wind solved the issue by taking
> > the advice given and Charlie S used his initiative and knowledge to
> > devise an /e/n/i file which replaced the one the installer had wiped
> > out.
> > 
> > This has been going on since Debian 7.0.0 and is not the first time the
> > issue has arisen here. Debian must be the only OS which deliberately
> > removes connectivity present during installation.
> 
> Can someone point me to the bug report about this ?
> 
> Ian.

#694068, #696755, #727740 and #777439.

-- 
Brian.



Re: (solved) Re: wireless fail after stretch installation

2018-03-06 Thread Ian Jackson
Brian writes ("Re: (solved) Re: wireless fail after stretch installation"):
> The plain and simple fact is that a user who installs over a wireless
> link and does not have network-manager does not have any connectivity
> to the internet after first boot. Long Wind solved the issue by taking
> the advice given and Charlie S used his initiative and knowledge to
> devise an /e/n/i file which replaced the one the installer had wiped
> out.
> 
> This has been going on since Debian 7.0.0 and is not the first time the
> issue has arisen here. Debian must be the only OS which deliberately
> removes connectivity present during installation.

Can someone point me to the bug report about this ?

Ian.

-- 
Ian Jackson <ijack...@chiark.greenend.org.uk>   These opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.



Re: (solved) Re: wireless fail after stretch installation

2018-03-05 Thread Brian
On Sun 04 Mar 2018 at 19:10:02 +0100, Philip Hands wrote:

> Jude DaShiell  writes:
> 
> > The least debian-boot membership could do would be to have a note come 
> > up for installers to execute a shell and do the file copy before 
> > rebooting once hard drive got mounted.  This is a problem for wifi users 
> > with no impact for ethernet users.
> 
> Your tone does not encourage a civil response, but you're going to get
> one anyway I'm afraid.
> 
> Since you didn't bother to say what you are complaining about in any
> useful way, I thought I'd look at the first post in the first thread
> referred to in the mail from Brian, which is about the fact that
> desktop-configured wifi connections don't come up until someone logs in.

You would have done better to have read further and, amongst other posts
which are pertinent to what Long Wind and Charlie S wrote, you would have
found this:

  https://lists.debian.org/debian-user/2018/02/msg00015.html

The plain and simple fact is that a user who installs over a wireless
link and does not have network-manager does not have any connectivity
to the internet after first boot. Long Wind solved the issue by taking
the advice given and Charlie S used his initiative and knowledge to
devise an /e/n/i file which replaced the one the installer had wiped
out.

This has been going on since Debian 7.0.0 and is not the first time the
issue has arisen here. Debian must be the only OS which deliberately
removes connectivity present during installation.

In the link above David Wright asks whether this is a "sick joke". If
the reasons for inflicting this issue on users were explained in some
detail, we could perhaps answer sensibly.

[Snip. The issue in this thread has nothing to do with an installed
network-manager.]

-- 
Brian.