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

[Dan Williams]

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.

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!
> 
> On Fri, Jul 17, 2015 at 05:40:56PM +0200, Tomas Hozza wrote:
> > Hello all.
> > 
> > I would like to share the outcome of the discussion between GNOME and NM developers
> > and the "Default DNS resolver" [1] Change for F23.
> > 
> > The full summary can be found here [2] and recording here [3] is anyone is interested.
> > 
> > 
> > Integration points:
> > - Captive portal detection
> > - Captive portal handling
> > - User interaction
> > 
> > 
> > Points we agreed on:
> > * Captive portal detecion
> >   * NM side
> >     * NM will be the only daemon doing Captive portal detection
> >     * NM moves connectivity check before NM_DEVICE_STATE_ACTIVATED, emits signal before network is "up"
> >     * If portal has been detected, NM blocks NM_DEVICE_STATE_ACTIVATED for a specific device until there is no more portal
> >     * NM regularly does the Captive portal detection (connectivity check) to determine if the login using GNOME was already done
> >     * Once the login was done and Internet connectivity is detected, NM triggers some event in nm-dispatcher (or something like that)
> >   * GNOME side
> >     * GNOME Shell does not do detection itself, but relies on the NM (as already done)
> >     * GNOME is watching the change of "connectivity state" property in NM
> >   * dnssec-trigger side
> >     * Does not do any detection
> >     * does not do any user interaction
> >     * Only relies on events triggered by NM and acts based on the connectivity status
> > 
> > * Captive portal handling (login)
> >   * GNOME side
> >     * If Captive portal is detected, then browser window is launched
> >     * The browser window ls launched with LD_PRELOAD (https://github.com/hadess/resolvconf-override) as resolv.conf override
> >     * GNOME should fetch the connection-provided DNS servers using NM API (existing) and use those for LD_PRELOAD solution
> >   * dnssec-trigger side
> >     * does not do any user interaction
> >     * Only relies on events triggered by NM and acts based on the connectivity status
> > 
> > * User interface / user interaction
> >   * Fedora Workstation product
> >     * GNOME shell
> >       * informs the user about the Captive portal
> >       * launches the window 
> >     * dnssec-trigger
> >       * the applet will be split into separate package and not installed by default (already done)
> >       * if all falbacks fail, it switches automatically to "Insecure" mode (no DNSSEC validation) without user interaction
> >         * automatic switch to insecure mode will be possible to turn off using configuration file for expert users
> >         * a notification can be emited about switching to insecure mode (so far by default OFF)
> >   * Other desktops / Spins
> >     * dnssec-trigger applet
> >       * should handle the UI that is usually handled by GNOME Shell (if there is not any specific Spin implementation to do that, i.e. if GNOME is not in use)
> >       * Captive portal detection will be still done in NM
> > 
> > * under discussion:
> >   * notification can be turned OFF by default, but configurable in config file for expert users - unfortunatelly this will not create pressure on admins to fix the networks
> >   * alternative: display a message which will say that local network is broken and that admin should be woken up:
> >     * 'Your network is seriously broken. Go and kick your network admin NOW!
> >     * This broken network will stop working from Fedora 24 on because it does not support DNSSEC. (Tell this to your admin!)'
> >     
> > 
> > [1] https://fedoraproject.org/wiki/Changes/Default_Local_DNS_Resolver
> > [2] https://www.piratepad.ca/p/default-dns-resolver-f23
> > [3] https://bluejeans.com/s/8pTY/
> > 
> > 
> > Regards,
> > -- 
> > Tomas Hozza
> > Software Engineer - EMEA ENG Developer Experience
> > 
> > PGP: 1D9F3C2D
> > Red Hat Inc.                 http://cz.redhat.com