Summary of Thursday's call between GNOME and NM devels and Default DNS resolver change owners

[Chuck Anderson]

On Fri, Jul 17, 2015 at 01:18:51PM -0500, Dan Williams wrote:
> On Fri, 2015-07-17 at 13:22 -0400, Chuck Anderson wrote:
> > Looks great!  I've been using this daily on Fedora 21 and I have to
> > say it mostly works well EXCEPT for the captive portal detection stuff
> > which is just horrendously bad, so I'm happy to see a new design that
> > may work a lot better.
> 
> What doesn't work in your experience with the captive portal stuff?
> Just wondering so we can improve it.  This plan doesn't necessarily make
> anything about *detecting* a portal better, just the flow after one has
> been detected.

Usually, the dnssec-triggerd captive portal detection pops up a
dialog, and when I click "log in" nothing happens.  When I click
"skip" (sorry I might be forgetting the exact button names) then a
captive portal browser pops up (I think this is the normal Gnome or NM
one, again not sure).  Usually things work fine after logging in
there.

Yesterday I happened to be testing a captive portal implementation (a
new guest wireless system we are deploying) using my Fedora 21 laptop,
and whatever I did, I couldn't get dnssec-triggerd to cooperate.  I
had to shut it off completely, because I kept hitting SELinux issues.
Even after I did "setenforce 0" I kept getting an authentication
dialog popup for ABRT and/or selinux-troubleshooter "to be able to
read other people's reports" or something to that effect.  I couldn't
get the darn thing to shut up, so I had to disable it.  I know there
is/was an outstanding SELinux issue with dnssec-triggerd sending a
signal to NM, so that might be fixed by now.

Now without dnssec-triggerd in the picture, the Gnome/NM captive
portal detection worked beautifully.

Even without the recent SELinux issues, dnssec-triggerd's captive
portal implementation has been iffy.  Sometimes it works, and
sometimes it doesn't.  I think there may be an issue with it trying to
launch the captive portal login browser, or timing issues between
Gnome/NM and dnssec-triggerd.

So I think the bulk of my troubles are the fighting between
dnssec-trigger's captive portal code and the Gnome/NM code.  But that
is exactly what you all agreed to address, so I'm happy that this will
be fixed.  I just hope it can all be implemented in time for the
Change Completion Deadline (10 days away).

Keep in mind all of my experience so far is on Fedora 21, so even F22
may have improved things already.

> 
> Dan
> 
> > Will the below be substantially implemented and testable
> > by the July 28 Change CheckPoint: Completion deadline (testable)?
> > That is only 10 days away...
> > 
> > It would be great if the Change page could be updated with these plans
> > and the current status, how to test, etc.
> > 
> > Thanks!