Re: split-DNS, resolvconf on Fedora (OpenVPN related issues)

[Dan Williams]

On Thu, 2021-02-25 at 11:57 +0100, David Sommerseth wrote:
> On 22/02/2021 16:29, Petr Menšík wrote:
> > Why? I thought about common interface to various DNS cache
> > implementations for workstations and different VPN providers
> > available.
> > While I think the best place to direct, which interface resolvers
> > should
> > handle given domains. resolvconf handles conflicting requests from
> > different interfaces, when multiple DNS resolver providers are
> > configured by connection.
> 
> Just providing some input from the OpenVPN perspective.
> 
> * OpenVPN 3 Linux
> 
> OpenVPN 3 Linux [0] since the v10 release provides native
> systemd-resolved support.
> 
> It is not optimal yet, but we plan to provide full support for split-
> DNS 
> the VPN server) and exclusive DNS (use only the DNS server pushed by
> VPN 
> server).
> 
> The current implementation will query all DNS servers on all
> interfaces. 
>   This hybrid mode will also be supported.
> 
> At the moment I'm not yet decided what should be the default mode,
> but 
> I'm leaning towards split-DNS - as that provides the least risk for
> DNS 
> are also considering how far the server can go to push for a certain 
> profile - as the use cases for VPN provider side are also very
> diverse 
> with different requirements.
> 
> For the v10+ releases you need to do a little configuration step [1]
> to 
> Fedora 33+.  Ubuntu 20.04 will probably also be updated to use it by 
> default.  This will most likely happen from the v14 release.
> 
> 
> * OpenVPN 2.x
> 
> We are also considering to fully embrace the update-systemd-resolved
> [2] 
> script for the OpenVPN 2.x versions.  And will work together with
> this 
> project to ensure OpenVPN 3 Linux and OpenVPN 2.x will behave a
> similar 
> as possible.
> 
> 
> * NetworkManger and OpenVPN
> 
> Outside of that, OpenVPN via NetworkManager will be a different beast
> to 
> tackle which we have not yet dug into from the OpenVPN project side. 
>  From the OpenVPN side, we are not too happy about the current 
> NetworkManager plug-in from a general point of view.
> 
> It is good with the graphical interface, but NetworkManager does not 
> too much in several areas (like killing the OpenVPN process if the
> main 
> link disappears; OpenVPN is capable of recovering quite nicely when 
> network recovers).  And we have more OpenVPN specific features
> planned 
> as well, where the NetworkManager can cause more damage - as it does
> not 
> (and should not) understand how OpenVPN operates.

I'm pretty sure the NM team would be receptive to improvements
especially given new OpenVPN capabilities.

But NM has supported a feature that allows VPN connections to persist
across link changes (the VPN service returns the "can-persist" key in
its IP config response if it knows the underlying service can handle
it). I don't see that exposed/utilized by nm-openvpn, but perhaps it
should be if the connection properties will allow it (eg, if --
keepalive/ping*/whatever is enabled?).

I'm sure they'd accept patches to that effect...

Dan

> * DNS updates
> 
> If NetworkManager is capable of fully integrating with a unified DNS 
> resolver management which OpenVPN and other updateresolve
> alternatives 
> could work with would definitely be the best for all of this.
> 
> OpenVPN 3 Linux and OpenVPN 2.x can be extended and taught to
> integrate 
> with various DNS management approaches.  systemd-resolved is already
> on 
> the way, but does not need to be restricted here.  But we are very
> much 
> interested in being involved in such discussions.
> 
> 
> [0] 
> [1] 
> <
> https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg20607.html
> >
> [2] 
> 
> 
> -- 
> kind regards,
> 
> David Sommerseth
> OpenVPN Inc
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: 
> https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam on the list, report it: 
> https://pagure.io/fedora-infrastructure

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: This is bad, was Re: Fedora 33 System-Wide Change proposal: systemd-resolved

[Dan Williams]

On Tue, 2020-09-29 at 15:14 -0400, Simo Sorce wrote:
> On Tue, 2020-09-29 at 11:20 -0500, Dan Williams wrote:
> > On Mon, 2020-09-28 at 16:40 -0500, Michael Catanzaro wrote:
> > > On Mon, Sep 28, 2020 at 5:18 pm, Chuck Anderson  > > > 
> > > wrote:
> > > > I think the VPN plugin and VPN server has some input, no?  All
> > > > the
> > > > VPN
> > > > servers I've used send routes to the VPN client to determine
> > > > which
> > > > traffic the client should send via the VPN.  How does that
> > > > interact
> > > > with "use this connection only for resources on its
> > > > network"?  Does
> > > > the user preference take precendence over the VPN server-
> > > > provided
> > > > routes?  What if the VPN server doesn't send any route other
> > > > than
> > > > 0.0.0.0/0?
> > > 
> > > Good question! So good that I don't know the answer. Yes, the
> > > VPN 
> > > plugin indeed gets to make decision based on configuration pushed
> > > by 
> > > the VPN server. The NetworkManager developers are experts in how
> > > these 
> > > settings interact. I *think* the routes provided by the VPN take 
> > > precedence over the checkbox (but only for routing, not for DNS)?
> > > But 
> > > this would certainly be good to document and explore more fully.
> > 
> > If you check "Use this connection..." then NetworkManager will:
> > 
> > (a) never set the default route through the VPN
> > (b) enable split DNS using the VPN-provided (or manually
> > configured)
> > DNS search domains
> > 
> > If you do not check that box, then the VPN will become the default
> > route and all your non-local traffic will be sent to it.
> > 
> > Unfortunately you cannot rely on VPNs to "do the right thing" and
> > always pass back 0.0.0.0 when it wants all the traffic. Plus the
> > user
> > may not want to pass all traffic to the VPN, regardless of what the
> > VPN
> > wants. If you have a corporate laptop and the company wants all
> > your
> > data to go through the VPN, then that laptop is presumably well-
> > managed 
> > and the IT admin will enforce that "Use this connection..." is
> > unchecked.
> 
> Dan,
> I think that unfortunately we cannot conflate "Use this
> connection..."
> to both decide on packet routing and well as DNS routing.

I'm not disagreeing that in a perfect world we'd actually differentiate
two different things.

But it's been this way for 12+ years with NM and (even though I've been
out of NetworkManager for a long time) I've never seen this much
discussion about the topic. Clearly something has worked for the
majority of users for a long, long time.

But perhaps it's time to evaluate improvements.

> There are definitely VPNs where routing allows only to reach internal
> networks and does not allow passthrough, and at the same time VPN
> expects that all DNS resolution happens through the VPN DNS server as
> they selectively override names so some traffic is routed over VPN
> when
> connected but over the regular internet when not (via DNS views).
> 
> I am not saying this is good or bad, it just is, and if we conflate
> this setting we cannot express that setup, which is common (for
> example
> this is the recommended/required configuration for our RH VPN IIRC).

Sure, those setups are not possible with the binary option we have to
day with NM.

> I am also *not* saying we should have two flags that read the same
> but
> just add "for DNS" in one and "for packets" in the other, as most
> users
> would probably be confused.
> 
> In general I would say that for the common case the default should be
> to send queries to the VPN even if there is packet routing split,
> especially if we are thinking about the "café case" I would
> definitely
> trust more the DNS server via the VPN than the one spoofed by the
> café
> broken wifi.

That is the current default, if you leave "Use this connection..."
unchecked. Of course that also sends your traffic to the VPN, which may
not actually work depending on your VPN config.

> Maybe the way to do this is to provide a different switch that say
> something like "I trust this connection to protect my privacy". Then
> if
> you do not want to trust the DNS provided by the VPN for everything,
> you can toggle that one off (default would be on), and that will
> cause
> split DNS as well based on configured domains.

Re: This is bad, was Re: Fedora 33 System-Wide Change proposal: systemd-resolved

[Dan Williams]

On Tue, 2020-09-29 at 09:18 -0700, John M. Harris Jr wrote:
> On Tuesday, September 29, 2020 5:13:48 AM MST Zbigniew Jędrzejewski-
> Szmek 
> wrote:
> > On Mon, Sep 28, 2020 at 11:41:12PM -0700, John M. Harris Jr wrote:
> > 
> > > On Monday, September 28, 2020 9:39:17 AM MST Michael Catanzaro
> > > wrote:
> > > 
> > > > You can do this, but again, you need to use the command line.
> > > > E.g. 
> > > > 'resolvectl dns tun0 8.8.8.8'
> > > > 
> > > > We're actually no longer debating how systemd-resolved works;
> > > > rather, 
> > > > we're now debating how NetworkManager chooses to configure 
> > > > systemd-resolved. systemd-resolved just does what it's told to
> > > > do. It's
> > > > 
> > > > actually NetworkManager that decides to split DNS according to
> > > > routing 
> > > > by default as a matter of policy. It could do otherwise if it
> > > > wanted 
> > > > to, but I think this is a good default. Nothing stops you from
> > > > changing
> > > > 
> > > > it though. :)
> > > 
> > > Michael,
> > > By what mechanism does NetworkManager "split DNS according to
> > > routing"? If
> > > it  hasn't already made a request from both your cleartext and
> > > your VPN
> > > connection's DNS servers, it has no way of knowing what network
> > > should be
> > > used to get the right results. Routing and DNS are unrelated.
> > 
> > NetworkManager pushes DNS server configuration (and associated bits
> > like
> > domain search and routing domains) over dbus to resolved. That way
> > it
> > "[tells resolved how to] split DNS according to routing". Of
> > course, after
> > the name has been resolved to an IP address, the packets to that IP
> > address
> > are routed too. So there is "routing" in the sense of deciding
> > which
> > interface is appropriate for a given DNS name and "routing" in the
> > sense of
> > deciding which interface is appropriate for a given IP address.
> 
> It seems that the terminology is fairly confusing, considering it's
> right 
> alongside actual routing configuration.. Okay, so "routing" means
> something 
> wildly different than you'd think with systemd-resolved, got it.
> 
> In most cases, in order to get to a DNS server inside a VPN, your
> packets have 
> to have a route which can reach the IP of that server for that
> interface, 
> which is configured using NetworkManager (or a VPN config file,
> imported into 
> NM). Anyone that understands basic networking will likely be confused
> by this 
> terminology.
> 
> That aside, where in NetworkManager do these "routing domains" get
> specified?

In the connection itself (GUI or CLI), or they come from DHCP or SLAAC
or the VPN.

nmcli con mod rh-openvpn ipv4.dns-search "foobar.com"
nmcli con mod rh-openvpn ipv4.never-default true

combined with having a local caching DNS server (or resolved) enabled
will route queries for those search domains only to the VPN-provided
DNS servers.

There are corresponding GUI boxes for these in nm-connection-editor,
GNOME network settings, and KDE.

Dan


> -- 
> John M. Harris, Jr.
> 
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: 
> https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: This is bad, was Re: Fedora 33 System-Wide Change proposal: systemd-resolved

[Dan Williams]

On Mon, 2020-09-28 at 16:40 -0500, Michael Catanzaro wrote:
> On Mon, Sep 28, 2020 at 5:18 pm, Chuck Anderson  
> wrote:
> > I think the VPN plugin and VPN server has some input, no?  All the
> > VPN
> > servers I've used send routes to the VPN client to determine which
> > traffic the client should send via the VPN.  How does that interact
> > with "use this connection only for resources on its network"?  Does
> > the user preference take precendence over the VPN server-provided
> > routes?  What if the VPN server doesn't send any route other than
> > 0.0.0.0/0?
> 
> Good question! So good that I don't know the answer. Yes, the VPN 
> plugin indeed gets to make decision based on configuration pushed by 
> the VPN server. The NetworkManager developers are experts in how
> these 
> settings interact. I *think* the routes provided by the VPN take 
> precedence over the checkbox (but only for routing, not for DNS)?
> But 
> this would certainly be good to document and explore more fully.

If you check "Use this connection..." then NetworkManager will:

(a) never set the default route through the VPN
(b) enable split DNS using the VPN-provided (or manually configured)
DNS search domains

If you do not check that box, then the VPN will become the default
route and all your non-local traffic will be sent to it.

Unfortunately you cannot rely on VPNs to "do the right thing" and
always pass back 0.0.0.0 when it wants all the traffic. Plus the user
may not want to pass all traffic to the VPN, regardless of what the VPN
wants. If you have a corporate laptop and the company wants all your
data to go through the VPN, then that laptop is presumably well-managed 
and the IT admin will enforce that "Use this connection..." is
unchecked.

Dan

> This is actually at issue in 
> https://bugzilla.redhat.com/show_bug.cgi?id=1863041 where we
> currently 
> wind up doing the wrong thing by default. See e.g. comment #81 where 
> the VPN plugin is constructing routing information to pass to 
> NetworkManager.
> 
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: 
> https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: This is bad, was Re: Fedora 33 System-Wide Change proposal: systemd-resolved

[Dan Williams]

On Mon, 2020-09-28 at 23:37 -0700, John M. Harris Jr wrote:
> On Monday, September 28, 2020 12:42:32 PM MST Lennart Poettering
> wrote:
> > On Mo, 28.09.20 12:14, Paul Wouters (p...@nohats.ca) wrote:
> > 
> > 
> > > On Mon, 28 Sep 2020, Michael Catanzaro wrote:
> > > 
> > > 
> > > 
> > > > I don't think it would be smart for employees to voluntarily
> > > > opt-in to
> > > > sending all DNS to their employer anyway... there's little
> > > > benefit to
> > > > the employee, and a lot of downside.
> > > 
> > > 
> > > Again, it is not up to systemd to limit valid use cases.
> > > 
> > > 
> > > 
> > > Perhaps Listen or read to Paul Vixie, father of many Bind
> > > software
> > > releases:
> > > 
> > > https://www.youtube.com/watch?v=ZxTdEEuyxHU
> > > 
> > > 
> > > 
> > > https://www.theregister.com/2018/10/23/paul_vixie_slaps_doh_as_dns_privacy
> > > _feature_becomes_a_standard/
> > > 
> > > There are use cases for and against routing all DNS over your
> > > VPN. If
> > > systemd wants to play system resolver, it needs to be able to be
> > > configured for either use case. You don't get to limit our use
> > > cases.
> > 
> > Configure "." as "routing domain" on a specific iface and the
> > lookups
> > wil go there preferably. If you put that on your VPN iface this
> > means
> > DNS traffic goes there preferably. If you put that ont he main
> > iface this
> > means DNS traffic goes there preferably.
> > 
> > Ideally you'd use more fine grained routing domains however.
> > 
> > Lennart
> 
> Lennart,
> 
> Is that a NetworkManager setting or a systemd-resolved setting? Is
> that going 
> to be exposed in the GUI, or is it something that gets hidden away?

NM gets "routing domains" for a given connection (eg, network
interface) from a couple different sources:

1) DHCP
2) SLAAC RDNSS
3) VPN
4) manually configured in the connection info, eg:

nmcli con mod rh-openvpn ipv4.dns-search "foobar.com"

It passes this information on to resolved or its own local caching DNS
configuration which uses dnsmasq, which both use it for directing
lookups for those domains to the DNS servers detected/configured for
that interface.

Dan

> How does systemd-resolved figure out what domains "should" be sent to
> a given 
> connection's DNS server without some arcane incantation from the
> systemd docs?
> 
> -- 
> John M. Harris, Jr.
> 
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: 
> https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora Workstation and disabled by default firewall

[Dan Williams]

On Mon, 2019-08-26 at 09:15 -0400, Robert Marcano wrote:
> On 8/26/19 9:07 AM, mcatanz...@gnome.org wrote:
> > Well the thing is, blocknig ports tends to break applications that
> > want 
> > to use those ports. We're not going to do that, period. It also
> > doesn't 
> > really accomplish anything: either your app or service needs
> > network 
> > access and you have whitelisted it (in which case the firewall
> > provides 
> > no security), or it needs network access and you have not
> > whitelisted it 
> > (in which case your firewall breaks your app/service). In no case
> > does 
> > it increase your security without breaking your app, right? Unless
> > you 
> > have malware installed (in which case, you have bigger problems
> > than the 
> > firewall). Or unless you have a vulnerable network service
> > installed 
> > that you don't want (in which case, uninstall it).
> 
> This is a reasonable point of view, until you notice Linux desktops 
> evironments don't provide applications with a method to detect if
> they 
> are running on a private network or not (See Windows Home, Office, 
> Internet network settings).
> 
> Then a non technical user start Rythmbox, enable music sharing, and
> it 
> works perfectly on their home network but then decides to buy a WAN 
> card/USB stick and suddenly all the music is being shared to the
> world.
> 
> I wish NetworkManager could do something about these situations,
> maybe 
> the default should be the public zone for interfaces that receive
> public 
> IP addresses.

The idea was originally that applications like Rhythmbox or desktop
sharing or printer sharing or whatever would do something intelligent
with the currently active firewalld zone that NM puts the connected
interface into. eg if the zone was "public" Rhythmbox wouldn't enable
sharing.

Unfortunately applications didn't do that, and the mechanism to tie all
these things together (assigning zone to connections, having
applications know about zones, what happens if you're not running
firewalld, etc) were never fully planned out or implemented.

Dan


> > So if you want to change the firewall settings, you'd need to
> > completely 
> > rethink how the firewall works. And nobody seems interested in
> > doing 
> > that. We could e.g. have a list of apps th at are allowed network 
> > access, but then we'd need some form of attestation so apps can't 
> > impersonate each other. So only sandboxed (flatpaked) apps could
> > use 
> > this hypothetical new firewall. And we surely don't want to have
> > yes/no 
> > permission prompts, so we can't really ask the user "do you want
> > your 
> > app to access the network?" (the user will almost always say yes).
> > I'm 
> > not really sure what design would even work.
> > 
> > Avoiding unnecessary network services makes more sense.
> > 
> > On Mon, Aug 26, 2019 at 3:45 PM, Alexander Ploumistos 
> >  wrote:
> > > As a matter of fact, you did: 
> > > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/3LHDQD5HCZMPV6O4LZRSKTVEIKEFJIBY/#3LHDQD5HCZMPV6O4LZRSKTVEIKEFJIBY
> > >  
> > > https://docs.fedoraproject.org/en-US/Fedora/21/html/Release_Notes/sect-Products.html#idm225474210784
> > >  
> > 
> > Thanks for dredging up these links!
> > 
> > Michael
> > 
> > ___
> > devel mailing list -- devel@lists.fedoraproject.org
> > To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> > Fedora Code of Conduct: 
> > https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> > List Guidelines: 
> > https://fedoraproject.org/wiki/Mailing_list_guidelines
> > List Archives: 
> > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> > 
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: 
> https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Non-responsive maintainer: Lubomir Rintel (lkundrak)

[Dan Williams]

On Wed, 2018-02-14 at 23:49 +0100, Sandro Mani wrote:
> Hi
> 
> Does anyone know how to contact Lubomir Rintel (lkundrak)? He is 
> obviously still active since his last koji build is as recent as
> last 
> Sunday the 11th, but he isn't answering to this ticket [1] and I
> also 
> had no luck e-mailing him directly.

As a follow-up, he replied on the bug.

Dan
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Testers for LCD Panel Self Refresh on laptops with Intel graphics wanted

[Dan Williams]

On Thu, 2018-02-01 at 12:34 +0100, Hans de Goede wrote:
> Hi All,
> 
> For the "Improved Laptop Battery Life" feature:
> https://fedoraproject.org/wiki/Changes/ImprovedLaptopBatteryLife
> 
> I'm working on for Fedora 28 I would like to also try and enable
> Panel Self Refresh on laptops with Intel graphics, some quick tests
> have shown this to save another 0.5W (when idle / nothing on the
> screen changes). This is currently off be default because it is
> known to cause issues on some devices. So I think we will probably
> need a white- or black-list. But first we need more data on this.
> 
> If you can spare 10 minutes, please see my blogpost for how to test
> this and send me a mail with the info request in the blogpost:
> https://hansdegoede.livejournal.com/18653.html

ThinkPad X1 Carbon 3rd gen (i7-5600U) kernel 4.14.14-300.fc27.x86_64. 
I added i915.enable_psr=1 but it doesn't seem to have enabled PSR on
the panel:

Sink_Support: no
Source_OK: no
Enabled: no
Active: no
Busy frontbuffer bits: 0x000
Re-enable work scheduled: no
Main link in standby mode: no
HW Enabled & Active bit: no
Performance_Counter: 0

Shouldn't Sink_Support:no mean that the panel doesn't support PSR?  At
least that's what would be implied by intel_dp.c:

/* Check if the panel supports PSR */
drm_dp_dpcd_read(&intel_dp->aux, DP_PSR_SUPPORT,
 intel_dp->psr_dpcd,
 sizeof(intel_dp->psr_dpcd));
if (intel_dp->psr_dpcd[0] & DP_PSR_IS_SUPPORTED) {
dev_priv->psr.sink_support = true;
DRM_DEBUG_KMS("Detected EDP PSR Panel.\n");
}

if (INTEL_GEN(dev_priv) >= 9 &&
(intel_dp->psr_dpcd[0] & DP_PSR2_IS_SUPPORTED)) {
uint8_t frame_sync_cap;

dev_priv->psr.sink_support = true;

Dan
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: No i686 kernel: Can we require SSE2 for i686?

[Dan Williams]

On Wed, 2017-07-12 at 09:05 -0600, Chris Murphy wrote:
> On Wed, Jul 12, 2017 at 7:09 AM, Hans de Goede 
> wrote:
> 
> > If the kernel team wants some specific help with ia32 support then
> > 2 things need to happen:
> > 
> > 1) A clear request for help needs to be send
> > 2) What exactly they need help with needs to be clearly defined
> 
> Has happened multiple times over two years.
> 
> https://lists.fedoraproject.org/pipermail/devel/2015-February/208368.
> html
> 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproje
> ct.org/message/GSIXKLR5RP5OIF6XMDP2WWYOKD4Y5LFM/
> 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproje
> ct.org/message/NJF45R5WFYVDJQJILQEWU2I4ADRYMAFN/
> 
> I'm not sure how it could be more clear.
> 
> 
> Of course, it could have been trolled better by someone, by wiping
> out
> the original subject and substituting -- Fedora: "death to i686!" --
> 
> 
> 
> > Last as others have said, this is _clearly_ a systemwide change
> > and the deadline for systemwide change proposals for F27 was July
> > 4th, where as this page was created July 6th, moreover a change as
> > big as this really needs to be discussed out in the open long
> > before
> > it gets implemented rather then hidden away in a Changes page.
> 
> I see it both ways. It is self-contained in that it's strictly the
> kernel without affecting user space at all. But it's system-wide in
> that it does affect the distribution, it's effectively dropping the
> hardware support for an entire architecture. But anyway, dropping
> i686
> kernel is not a surprise to me, this has been a rather long leadout
> train.

While you're at it Chris, I (possibly ill-advisedly) touched https://bu
gzilla.redhat.com/show_bug.cgi?id=1185518 if you've still got that
machine with the ipw2100 around.

Dan
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Nested rich-dependencies in rpm

[Dan Williams]

On Wed, 2017-04-12 at 16:28 +0200, Christian Dersch wrote:
> On 04/12/2017 04:19 PM, Matthew Miller wrote:
> > On Wed, Apr 12, 2017 at 02:56:24PM +0200, Christian Dersch wrote:
> > > > On Wed, Apr 12, 2017 at 11:08:46AM +0200, Björn 'besser82'
> > > > Esser wrote:
> > > > > I hope someone can help me with the following question:
> > > > > Does recent Fedora's rpm support nested rich-dependencies
> > > > > like:
> > > > >    Supplements: (pkg_a and pkg_b and pkg_c and (pkg_d or
> > > > > pkg_e))
> > > > > Is there any way to express a dependency like that?
> > > > 
> > > > Can you give an example of when this might be a good idea? It
> > > > seems
> > > > easy to go overboard with this without clear benefit.
> > > > 
> > > 
> > > The example is dnfdragora, a nice new GUI for DNF. It uses libyui
> > > abstraction to provide native GUI/TUI for GTK+3, Qt and ncurses.
> > > The
> > > rich-dependencies ensure that the right libyui bindings get
> > > installed. So an Xfce user would get libyui-gtk while an LXQt
> > > user
> > > would get libyui-qt.
> > 
> > So, in concrete terms:
> > 
> > Supplements: dnf and  and  and (libyui-gtk or libyui-qt)
> > 
> > ?
> > 
> > What are the blanks? And the meaning is: this shouldn't show up as
> > a suggested addition unless those blanks _and_ a libyui of some
> > sort
> > is already installed (or will be installed)?
> > 
> > Going back to the benefits question: why is this better than
> > including
> > dnfdragora in the appropriate groups in comps?
> > 
> > 
> 
> Maybe I wrote not detailed enough or even a bit wrong, dnfdragora is
> the 
> use-case because it requires libyui and some toolkit binding. But
> that 
> stuff where we want to add that is libyui itself. So that the user
> gets 
> the libyui bindings matching his desktop environment. So libyui-qt
> would 
> supplement libyui and (plasma-desktop or lxqt-session) for example. 
> Similar with gtk. We want to ensure that the user always gets the 
> bindings for the toolkit his installed desktops use. So this is a
> logic 
> for libyui, not dnfdragora (which is just the application using it).

It's not uncommon to have any or all of GTK, GNOME, and KDE installed
at the same time. What libyui-* does dnfdragora use?  What happens if
both libyui-gtk and libyui-qt are installed, which one gets picked?

Dan
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: i915 firmware not in Fedora?

[Dan Williams]

On Mon, 2016-12-12 at 12:26 -0700, Chris Murphy wrote:
> On Mon, Dec 12, 2016 at 12:23 PM, Tom Hughes  wrote:
> > 
> > On 12/12/16 18:56, Chris Murphy wrote:
> > 
> > > 
> > > The firmware https://01.org/linuxgraphics/intel-linux-graphics-fi
> > > rmwares
> > > is not included in Fedora Workstation by default, I'm also not
> > > finding
> > > them in any repo.
> > > 
> > > I learned about this firmware from a bug I filed upstream and
> > > it's
> > > recommended that it be used.
> > > https://bugs.freedesktop.org/show_bug.cgi?id=99057
> > > 
> > > Are there problems including it in Fedora?
> > 
> > 
> > It's in linux-firmware isn't it? Here's what I see on F25:
> > 
> > dunsmere [~] % rpm -ql linux-firmware | fgrep i915
> > /usr/lib/firmware/i915
> > /usr/lib/firmware/i915/bxt_dmc_ver1.bin
> > /usr/lib/firmware/i915/bxt_dmc_ver1_07.bin
> > /usr/lib/firmware/i915/kbl_dmc_ver1.bin
> > /usr/lib/firmware/i915/kbl_dmc_ver1_01.bin
> > /usr/lib/firmware/i915/skl_dmc_ver1.bin
> > /usr/lib/firmware/i915/skl_dmc_ver1_23.bin
> > /usr/lib/firmware/i915/skl_dmc_ver1_26.bin
> > /usr/lib/firmware/i915/skl_guc_ver1.bin
> > /usr/lib/firmware/i915/skl_guc_ver4.bin
> > /usr/lib/firmware/i915/skl_guc_ver6.bin
> > /usr/lib/firmware/i915/skl_guc_ver6_1.bin
> > /usr/share/doc/linux-firmware/LICENSE.i915
> 
> Indeed it is, I've updated the bug. But still something unexpected is
> going on:
> 
> [1.812375] [drm] Replacing VGA console driver
> [1.818937] [drm] Supports vblank timestamp caching Rev 2
> (21.10.2013).
> [1.818941] [drm] Driver supports precise vblank timestamp query.
> [1.827858] [drm] Finished loading i915/skl_dmc_ver1_26.bin
> (v1.26)
> [1.828224] vgaarb: device changed decodes:
> PCI::00:02.0,olddecodes=io+mem,decodes=io+mem:owns=io+mem
> [1.835177] [drm] GuC firmware load skipped

"modinfo i915 | grep guc" says:

parm: enable_guc_loading:Enable GuC firmware loading (-1=auto, 0=never 
[default], 1=if available, 2=required) (int)

I'd guess upstream just isn't ready to enable GUC firmware loading by
default. If you set that parameter to -1 (autodetect) it might work.

Dan
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Docker/Libvirt networking issue / bug?

[Dan Williams]

On Thu, 2016-10-06 at 12:39 -0600, Nathanael D. Noblet wrote:
> On Thu, 2016-10-06 at 14:28 -0400, Neil Horman wrote:
> > 
> > I rarely mess with docker, but I expect that the docker0 bridge has
> > an ip
> > address on it which may conflict with the one on libvirt
> > bridge.  That is to
> > say, if they are on the same subnet, and the route for the docker0
> > bridge takes
> > precidence, you will loose dhcp.  Check the docker bridge ip and
> > remove it if
> > you see one, I expect that will restore your functionality
> > 
> 
> Unfortunately that isn't the issue as the docker bridge is 172... and
> bridge0 is 192.168... so they don't conflict. Also docker0 doesn't
> seem
> to have any devices (meaning it brctl show has no interfaces attached
> to it). Finally shutting down docker and removing docker0 doesn't
> restore connectivity, only a reboot does. Not even restarting NM
> fixes
> the issue.

Try running 'iptables-save' before you start docker, and then running
'iptables-save' after.  Diff the results.  Did docker remove anything?

Dan
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Disable ipv6 doesn't work

[Dan Williams]

On Sun, 2016-08-07 at 08:31 +, jack smith wrote:
> Hello,
> 
> Disabling ipv6 in Gnome Control Center / Network / "My connection"
> doesn't work. ifconfig show that an ipv6 is still attributed and the
> problem I have with ipv6 enabled is still there (gone if I really
> disable ipv6).

NetworkManager doesn't completely disable IPv6 when you turn it off, it
simply stops doing any IPv6-related stuff on the interface.  That was
mainly for backwards compatibility; you'll still get an IPv6 Link Local
address (eg, starts with fe:80).  If you'd like to turn off IPv6
entirely, you can use sysctls to do so for all interfaces:

net.ipv6.conf.all.disable_ipv6 = 1
net.ipv6.conf.default.disable_ipv6 = 1

Dan
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: How to configure a network bridge from script ?

[Dan Williams]

On Fri, 2016-05-13 at 09:36 +0300, Alexander Todorov wrote:
> На 12.05.2016 в 15:32, Phil Sutter написа:
> > 
> > Hi,
> > 
> > On Thu, May 12, 2016 at 02:47:19PM +0300, Alexander Todorov wrote:
> > > 
> > > # cat /etc/sysconfig/network-scripts/ifcfg-enp1s0f0
> > > Generated by dracut initrd
> > The line above is supposed to be a comment.
> > 
> OK, fixed that then I got:
> 
> # systemctl status network.service
> ● network.service - LSB: Bring up/down networking
> Loaded: loaded (/etc/rc.d/init.d/network)
> Active: failed (Result: exit-code) since пт 2016-05-13 02:33:54
> EDT; 36s ago
>   Docs: man:systemd-sysv-generator(8)
>    Process: 2189 ExecStart=/etc/rc.d/init.d/network start
> (code=exited, 
> status=1/FAILURE)
> 
> май 13 02:33:53 amd-dinar-02.lab.bos.redhat.com network[2189]: Could
> not load 
> file '/etc/sysconfig/network-scripts/ifcfg-lo'
> май 13 02:33:53 amd-dinar-02.lab.bos.redhat.com network[2189]:
> [  OK  ]
> май 13 02:33:53 amd-dinar-02.lab.bos.redhat.com network[2189]:
> Bringing up 
> interface enp1s0f0:  [  OK  ]
> май 13 02:33:53 amd-dinar-02.lab.bos.redhat.com network[2189]:
> Bringing up 
> interface enp1s0f1:  Error: Connection activation f...tion.

This line indicates that the scripts are returning a NetworkManager
error, but that error is elided so we don't know what it is.  When
NetworkManager is running, the ifup script basically calls 'nmcli con
up '.  So to better figure this out, you can:

nmcli g log level debug
ifup enp1s0f0

and then grab 'journalctl -b -u NetworkManager' and lets see what's
going on.

Dan

> май 13 02:33:53 amd-dinar-02.lab.bos.redhat.com network[2189]:
> [FAILED]
> май 13 02:33:53 amd-dinar-02.lab.bos.redhat.com network[2189]:
> Bringing up 
> interface br0:  [  OK  ]
> май 13 02:33:54 amd-dinar-02.lab.bos.redhat.com systemd[1]:
> network.service: 
> Control process exited, code=exited status=1
> май 13 02:33:54 amd-dinar-02.lab.bos.redhat.com systemd[1]: Failed to
> start LSB: 
> Bring up/down networking.
> май 13 02:33:54 amd-dinar-02.lab.bos.redhat.com systemd[1]:
> network.service: 
> Unit entered failed state.
> май 13 02:33:54 amd-dinar-02.lab.bos.redhat.com systemd[1]:
> network.service: 
> Failed with result 'exit-code'.
> Hint: Some lines were ellipsized, use -l to show in full.
> 
> 
> 
> And
> 
> # ip a s
> 1: lo:  mtu 65536 qdisc noqueue state UNKNOWN
> group 
> default qlen 1
>  link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
>  inet 127.0.0.1/8 scope host lo
> valid_lft forever preferred_lft forever
>  inet6 ::1/128 scope host
> valid_lft forever preferred_lft forever
> 2: enp1s0f0:  mtu 1500 qdisc mq
> state UP group 
> default qlen 1000
>  link/ether 00:00:1a:1a:94:70 brd ff:ff:ff:ff:ff:ff
>  inet 10.16.42.33/21 brd 10.16.47.255 scope global dynamic
> enp1s0f0
> valid_lft 77820sec preferred_lft 77820sec
>  inet6 2620:52:0:102f:200:1aff:fe1a:9470/64 scope global
> noprefixroute dynamic
> valid_lft 2591924sec preferred_lft 604724sec
>  inet6 fe80::200:1aff:fe1a:9470/64 scope link
> valid_lft forever preferred_lft forever
> 3: enp1s0f1:  mtu 1500 qdisc mq
> state DOWN 
> group default qlen 1000
>  link/ether 00:00:1a:1a:94:71 brd ff:ff:ff:ff:ff:ff
> 4: br0:  mtu 1500 qdisc noqueue
> state DOWN 
> group default qlen 1000
>  link/ether 42:61:9f:68:1d:85 brd ff:ff:ff:ff:ff:ff
> 
> 
> --
> Alex
> --
> devel mailing list
> devel@lists.fedoraproject.org
> http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.
> org
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: nss_myhostname as default in Fedora

[Dan Williams]

On Tue, 2016-01-26 at 13:32 -0800, Andrew Lutomirski wrote:
> On Tue, Jan 26, 2016 at 12:48 PM, Samuel Sieb 
> wrote:
> > On 01/26/2016 09:47 AM, Andrew Lutomirski wrote:
> > > 
> > > I still think that, for the default workstation use case,
> > > configuring
> > > a hostname as a mandatory part of installation is
> > > counterproductive.
> > > Would it make sense to improve support for hostname-less
> > > workstations?
> > >   NetworkManager could take hostname=="localhost" or
> > > "localhost.localdomain" to mean that DDNS should be turned off
> > > and the
> > > client ID should be "MAC" instead of "localhost".Would it
> > > make
> > > sense to teach NetworkManager to skip sending the client ID (or
> > > send
> > > some compatibility value) instead of "localhost"?
> > > 
> > It's not mandatory for installation. If your IP address resolves,
> > it uses
> > whatever hostname is returned.  If not, it stays at localhost.  You
> > can
> > manually modify that of course, but you aren't required to.  This
> > works
> > perfectly for me deploying computers with freeipa.  I set up the
> > DHCP
> > server, the installer picks up the right name and freeipa
> > configures
> > correctly.
> 
> This is rather awkward for laptops in particular.  It gets a bit
> confusing when my laptop's idea of what it's called varies depending
> on where I am.

The only way to keep a stable, guaranteed hostname is by putting that
into /etc/hostname, regardless of whether it's localhost or something
else.  So in the workstation case, just leaving it as localhost is
fine.

FWIW, NetworkManager will never send "localhost"-type hostnames to the
DHCP server for DDNS, even if you set dhcp-send-hostname=true.

Dan
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: nss_myhostname as default in Fedora

[Dan Williams]

On Tue, 2016-01-26 at 09:47 -0800, Andrew Lutomirski wrote:
> On Tue, Jan 26, 2016 at 9:19 AM, Dan Williams 
> wrote:
> > On Mon, 2016-01-25 at 19:43 -0800, Andrew Lutomirski wrote:
> > > On Mon, Jan 25, 2016 at 6:34 PM, Peter Robinson <
> > > pbrobin...@gmail.com
> > > > wrote:
> > > > > > > > > It is intended as a convenient fallback mechanism,
> > > > > > > > > and is
> > > > > > > > > only supposed
> > > > > > > > > to have an effect if 'gateway' is not defined in the
> > > > > > > > > local DNS (the
> > > > > > > > > 'domain' or 'search' zones). Would it help if those
> > > > > > > > > limitations were
> > > > > > > > > more explicit, e.g. documented in nss-myhostname(8)?
> > > > > > > > 
> > > > > > > > I understand that the goal is that nss_myhostname will
> > > > > > > > not
> > > > > > > > override
> > > > > > > > existing names, due to the way the NSS is configured.
> > > > > > > > 
> > > > > > > > What I do not understand is how the the “gateway” name
> > > > > > > > can
> > > > > > > > be
> > > > > > > > useful.
> > > > > > > 
> > > > > > > Here's a very obvious, trivial example: wherever I am I
> > > > > > > can
> > > > > > > now simply
> > > > > > > type "ping gateway" to know whether connectivity to my
> > > > > > > local
> > > > > > > router
> > > > > > > works.
> > > > > > 
> > > > > > But that's not actually true, isn't it?  If nss_myhostname
> > > > > > doesn't
> > > > > > override “gateway”, the outcome depends on the network you
> > > > > > are
> > > > > > on.  With
> > > > > > a captive portal, you are likely pinging the portal server,
> > > > > > not
> > > > > > the
> > > > > > default gateway.  And if you are on one of Microsoft's
> > > > > > corporate
> > > > > > networks, you might end up at gateway.microsoft.com
> > > > > > (whatever
> > > > > > this
> > > > > > is).
> > > > > 
> > > > > Well, IRL you'd actually quickly notice, since ping shows you
> > > > > the
> > > > > full
> > > > > fqdn of the host, and hence gives you a very clear hint on
> > > > > what
> > > > > it is
> > > > > actually pinging.
> > > > > 
> > > > > > Because it's so unreliable, we cannot put this trick into
> > > > > > documentation,
> > > > > > and we shouldn't train users to rely on this functionality.
> > > > > 
> > > > > Yeah, single-label names are like that. If you want trustable
> > > > > single-label names, you better shouldn't use search domains
> > > > > (and
> > > > > quite
> > > > > frankly, I am not particularly a fan of the search domain
> > > > > concept
> > > > > myself, because of its ambiguities. In systemd-resolved we by
> > > > > default
> > > > > ignore the DHCP-reported search domains because of this.)
> > > > > 
> > > > > Note that systemd-resolved's LLMNR implementation actually
> > > > > excepts
> > > > > itself from resolving "gateway" even though a single-label
> > > > > name
> > > > > (it
> > > > > also excepts itself from a couple of other names, such as
> > > > > "localhost"). Which basically means: the "gateway" name is
> > > > > safe
> > > > > exactly when you turn off the search domain logic (or to put
> > > > > this
> > > > > correctly if networkd is used: it is safe unless you *turn
> > > > > on*
> > > > > the
> > > > > search domain logic).
> > > > > 
> > > > > > Right.  If software (or documentation) uses “gateway” to
> > > > > 

Re: nss_myhostname as default in Fedora

[Dan Williams]

On Mon, 2016-01-25 at 19:43 -0800, Andrew Lutomirski wrote:
> On Mon, Jan 25, 2016 at 6:34 PM, Peter Robinson  > wrote:
> > > > > > > It is intended as a convenient fallback mechanism, and is
> > > > > > > only supposed
> > > > > > > to have an effect if 'gateway' is not defined in the
> > > > > > > local DNS (the
> > > > > > > 'domain' or 'search' zones). Would it help if those
> > > > > > > limitations were
> > > > > > > more explicit, e.g. documented in nss-myhostname(8)?
> > > > > > 
> > > > > > I understand that the goal is that nss_myhostname will not
> > > > > > override
> > > > > > existing names, due to the way the NSS is configured.
> > > > > > 
> > > > > > What I do not understand is how the the “gateway” name can
> > > > > > be
> > > > > > useful.
> > > > > 
> > > > > Here's a very obvious, trivial example: wherever I am I can
> > > > > now simply
> > > > > type "ping gateway" to know whether connectivity to my local
> > > > > router
> > > > > works.
> > > > 
> > > > But that's not actually true, isn't it?  If nss_myhostname
> > > > doesn't
> > > > override “gateway”, the outcome depends on the network you are
> > > > on.  With
> > > > a captive portal, you are likely pinging the portal server, not
> > > > the
> > > > default gateway.  And if you are on one of Microsoft's
> > > > corporate
> > > > networks, you might end up at gateway.microsoft.com (whatever
> > > > this
> > > > is).
> > > 
> > > Well, IRL you'd actually quickly notice, since ping shows you the
> > > full
> > > fqdn of the host, and hence gives you a very clear hint on what
> > > it is
> > > actually pinging.
> > > 
> > > > Because it's so unreliable, we cannot put this trick into
> > > > documentation,
> > > > and we shouldn't train users to rely on this functionality.
> > > 
> > > Yeah, single-label names are like that. If you want trustable
> > > single-label names, you better shouldn't use search domains (and
> > > quite
> > > frankly, I am not particularly a fan of the search domain concept
> > > myself, because of its ambiguities. In systemd-resolved we by
> > > default
> > > ignore the DHCP-reported search domains because of this.)
> > > 
> > > Note that systemd-resolved's LLMNR implementation actually
> > > excepts
> > > itself from resolving "gateway" even though a single-label name
> > > (it
> > > also excepts itself from a couple of other names, such as
> > > "localhost"). Which basically means: the "gateway" name is safe
> > > exactly when you turn off the search domain logic (or to put this
> > > correctly if networkd is used: it is safe unless you *turn on*
> > > the
> > > search domain logic).
> > > 
> > > > Right.  If software (or documentation) uses “gateway” to mean
> > > > “address
> > > > of the default gateway”, it will break, depending on search
> > > > path
> > > > configuration and other network properties.
> > > > 
> > > > I don't think this is what Fedora wants (and what you
> > > > intended).
> > > 
> > > I disagree. It only breaks if the user enables domain search
> > > logic,
> > > and configures a domain in there that actually serves a host
> > > called
> > > "gateway".
> > 
> > Which from my time, a good 10 years or so, at a large global
> > service
> > provider and as a Red Hat consultant on customer sites both of
> > those
> > were often true so I'm not sure it's something that you can assume
> > either way. And given on those networks there's generally LOT of
> > legacy platforms that make assumptions about that sort of thing I'm
> > not sure it's something you can just turn around and say "well just
> > turn it off you idiots".
> > 
> 
> I think that the "gateway" override should not be conflated with
> always letting the gethostname(2) return value resolve.
> 
> I also think that the whole gethostname(2) mechanism is terminally
> screwed up.  We abuse the hostname for multiple purposes:
> 
> 1. It shows up in the default bash prompt.
> 2. It gets sent to remote DHCP servers.  I think this is a mistake on
> desktop machines

When sent to DHCP servers, the hostname is used only for DDNS updates
and not for any kind of client identification.  That's what the Client
Identifier is used for, or missing that, the MAC address (depending on
the server).  I'm not aware of any DHCP server that uses the DDNS
hostname as a lease identifier.

It's not a mistake to send a hostname if your DHCP server also handles
DDNS updates.  It doesn't have to be the name set for the local
machine, but almost all of the time its going to be since you want your
local queries to return the same result for your machine name as non
-local queries would.

One problem is that there is no way to determine that the DHCP server
has DDNS functionality enabled, and thus to selectively send the
hostname.  Which is why NetworkManager has ipv4.dhcp-send-hostname and
ipv6.dhcp-send-hostname toggles so you can turn it off.

Dan

> 3. Some programs seem to thing that gethostbyname(gethostname())
> should return some reasonable concept of

Re: Attempting to contact unresponsive maintainer - jklimes

[Dan Williams]

On Wed, 2016-01-06 at 10:51 -0700, Kevin Fenzi wrote:
> On Wed, 06 Jan 2016 09:46:32 -0600
> Dan Williams  wrote:
> 
> > On Tue, 2016-01-05 at 17:07 -0700, Kevin Fenzi wrote:
> > > Greetings, we've been told that the email addresses
> > > for this package maintainer is no longer valid.  I'm starting the
> > > unresponsive maintainer policy to find out if they are still
> > > interested
> > > in maintaining their packages (and if so, have them update their
> > > email
> > > addresses in FAS).  If they're not interested in maintaining or
> > > we
> > > can't locate them I'll have FESCo orphan the packages so that
> > > others
> > > can take them over.
> > > 
> > > If you have a way to contact this maintainer, please let them
> > > know that we'd appreciate knowing what to do with their packages.
> > > Thanks!
> > > 
> > > * jklimes - former email: jkli...@redhat.com  
> > 
> > Jirka last day with Red Hat was right before the holidays (he'll be
> > missed), so yes this email is no longer active.  I'll ask him if
> > he'd
> > like to continue maintaining packages, but that would of course
> > involve an email change to his personal one anyway.  We might as
> > well
> > remove jklimes@rh from package maintainership.
> 
> ok. Do you want me to set the point of contact to you on that
> package? 

Actually Lubomir Rintel should get it, he should be on all the other
packages too.

Dan
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Attempting to contact unresponsive maintainer - jklimes

[Dan Williams]

On Tue, 2016-01-05 at 17:07 -0700, Kevin Fenzi wrote:
> Greetings, we've been told that the email addresses
> for this package maintainer is no longer valid.  I'm starting the
> unresponsive maintainer policy to find out if they are still
> interested
> in maintaining their packages (and if so, have them update their
> email
> addresses in FAS).  If they're not interested in maintaining or we
> can't locate them I'll have FESCo orphan the packages so that others
> can take them over.
> 
> If you have a way to contact this maintainer, please let them
> know that we'd appreciate knowing what to do with their packages.
> Thanks!
> 
> * jklimes - former email: jkli...@redhat.com

Jirka last day with Red Hat was right before the holidays (he'll be
missed), so yes this email is no longer active.  I'll ask him if he'd
like to continue maintaining packages, but that would of course involve
an email change to his personal one anyway.  We might as well remove 
jklimes@rh from package maintainership.

Dan

> Point of contact:
> 
> rpms/mobile-broadband-provider-info -- Mobile broadband provider
> database ( master f23 f22 )
> 
> Co-maintainer:
> 
> rpms/ModemManager -- Mobile broadband modem management service (
> master f23 f22 )
> rpms/NetworkManager -- Network connection manager and user
> applications ( master f23 f22 )
> rpms/NetworkManager-openvpn -- NetworkManager VPN plugin for
> OpenVPN ( master f23 f22 )
> rpms/NetworkManager-pptp -- NetworkManager VPN plugin for PPTP (
> master f23 f22 )
> rpms/NetworkManager-vpnc -- NetworkManager VPN plugin for vpnc (
> master f23 f22 )
> rpms/network-manager-applet -- A network control and status
> applet for NetworkManager ( master f23 f22 )
> rpms/wpa_supplicant -- WPA/WPA2/IEEE 802.1X Supplicant ( master
> f23
> f22 )
> 
> kevin
> --
> devel mailing list
> devel@lists.fedoraproject.org
> http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.
> org
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: F24 System Wide Change: Default Local DNS Resolver

[Dan Williams]

On Wed, 2015-12-16 at 10:45 -0500, Neal Becker wrote:
> Tomasz Torcz wrote:
> 
> > On Wed, Dec 16, 2015 at 09:33:18AM -0500, Neal Becker wrote:
> > > P J P wrote:
> > > 
> > > > > On Wednesday, 2 December 2015 6:33 PM, Neal Becker wrote:
> > > > 
> > > > > > https://bugzilla.redhat.com/show_bug.cgi?id=1287607
> > > > 
> > > > 
> > > >   Thank you for filing the bug.
> > > > 
> > > > 
> > > > > * howto prevent dnsmasq from starting (right now I'm just
> > > > > manually
> > > > > killing it for testing)
> > > > 
> > > >   # systemctl disable dnsmasq
> > > > 
> > > > 
> > > 
> > > ps aux | grep dns
> > > nobody1056  0.0  0.0  57544   484 ?SDec14   0:00
> > > /sbin/dnsmasq --conf-file=/var/lib/libvir
> > > root  1058  0.0  0.0  5751624 ?SDec14   0:00
> > > /sbin/dnsmasq --conf-file=/var/lib/libvir
> > 
> >   Try
> > systemctl status 1056
> > 
> > I guess it's started by libvirtd.
> > 
> 
> Yes, and does it have to be stopped in order for local dns resolver
> to 
> function?

No, it doesn't.  If you look at the config file for each instance
you'll see 

interface=virbr0(or something similar)
except-interface=lo

otherwise you'd never be able to run multiple VMs with different
network setups.  The libvirt dnsmasq instance should be binding to the
interface that libvirt owns/manages and nothing else.

Same thing for NetworkManager's "internet connection sharing"
functionality with dnsmasq.

But using NetworkManager's dns=dnsmasq config option *does* tell NM to
spawn dnsmasq as a local caching nameserver listening on lo and that
will conflict with unbound.

Dan
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: F24 System Wide Change: Default Local DNS Resolver

[Dan Williams]

On Fri, 2015-12-04 at 16:09 +0100, Timotheus Pokorra wrote:
> > is deployed in probably half of the homes in Germany... Also I am
> > pretty sure other routers form other manufacturers do the same
> > thing. Now, if we default to DNSSEC validation soon, does this mean
> 
> Same for Vodafone Routers in Germany: I go to http://easy.box to
> configure my router.
> 

Older Netgear routers also used http://routerlogin.net before they were
set up.

Dan
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Some analysis on the size of the minimal and Server installs of Fedora 23

[Dan Williams]

On Wed, 2015-11-18 at 11:32 -0600, Jason L Tibbitts III wrote:
> > > > > > "DW" == Dan Williams  writes:
> 
> DW> I suppose NM-tui could be pulled out of Server since not that
> many
> DW> other things require newt, and nmcli is always going to be there
> DW> anyway.
> 
> For some reason I thought NM-tui _was_ nmcli.  There's no reason to
> have
> anything other than the command line tool in server, indeed.  Some
> might
> argue that you don't even need that since you can just edit some
> files
> and restart.  Are any deps there just because of nmcli?

The only additional dep nmcli pulls in is a readline library.

Dan
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Some analysis on the size of the minimal and Server installs of Fedora 23

[Dan Williams]

On Tue, 2015-11-17 at 17:36 -0600, Jason L Tibbitts III wrote:
> > > > > > "DW" == Dan Williams  writes:
> 
> DW> Could you confirm what NetworkManager-* packages are installed on
> DW> F23 server?
> 
> On my custom install (which just lists the packages I need in my
> kickstart file) I have:
> 
> NetworkManager-glib-1.0.6-8.fc22.x86_64
> NetworkManager-1.0.6-8.fc22.x86_64
> NetworkManager-libnm-1.0.6-8.fc22.x86_64
> NetworkManager-config-connectivity-fedora-1.0.6-8.fc22.x86_64
> NetworkManager-tui-1.0.6-8.fc22.x86_64

Thanks; config-connectivity-fedora would indeed be unexpected on
Server.  Thankfully that's just a config file and has no additional RPM
requirements to pull in.

NM-tui needs newt, which pulls in slang, which isn't small (2MB on
disk?).  I suppose NM-tui could be pulled out of Server since not that
many other things require newt, and nmcli is always going to be there
anyway.

Dan
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Some analysis on the size of the minimal and Server installs of Fedora 23

[Dan Williams]

On Mon, 2015-11-16 at 20:39 -0500, Stephen Gallagher wrote:
> b'NetworkManager': 138

NM does have a larger dep-chain than we'd like, however we did split
the package apart a couple releases ago and made sure that WWAN, WiFi,
and Bluetooth were no longer required for the server cases.  Could you
confirm what NetworkManager-* packages are installed on F23 server?

The largest deps should be mostly glib2, systemd/udev, NSS, and D-Bus,
all of which should already be on a server install.  We'd love to see
if anything unexpected snuck into the dep chain.

Dan
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Unexpected NIC naming f23 firewall implications

[Dan Williams]

On Sun, 2015-11-08 at 20:36 +0100, Reindl Harald wrote:
> 
> Am 08.11.2015 um 20:29 schrieb Richard W.M. Jones:
> > On Sat, Nov 07, 2015 at 05:28:54PM +, Christopher wrote:
> >> I recently updated my desktop to f23, and it went smoothly, for the most
> >> part. However, it broke my mediatomb server because the NIC changed from
> >> em1 to eno1.
> >>
> >> Is this something that was expected? It certainly surprised me.
> >
> > It happened to a bunch of servers when I updated them from F22 to F23.
> > Their NICs changed from p6p1 -> enp3s0.  It was annoying because I had
> > to boot each one with a display and keyboard and change the network
> > configuration by hand.
> >
> > "predictable, stable network interface names"
> > https://wiki.freedesktop.org/www/Software/systemd/PredictableNetworkInterfaceNames/
> 
> that is simple to solve forever
> 
> * add "net.ifnames=0 biosdevname=0" to your kernel params
> * get rid of NetworkManager

FYI, NetworkManager has nothing to do with device naming at all.  So
disabling NM will do nothing to solve your problems with device names.

Dan

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Fedora IPv6 testing and improvements - request for ideas

[Dan Williams]

On Thu, 2015-10-29 at 15:30 -0500, Chris Adams wrote:
> Once upon a time, Zach Villers  said:
> > If it helps, Sixxs (https://www.sixxs.net/main/) is a very highly
> > recommended tunnel broker. I have not tried it and am not affiliated. I do
> > have ipv6 capability from my isp, so could help with testing.
> 
> There's also Hurricane Electric's free IPv6 tunnels.
> 
> BTW: one issue that I have seen with IPv6 and address privacy extensions
> is that, since temporary address handling moved to user-space
> (NetworkManager I guess?) instead of kernel-space, temporary addresses
> are expired even when they are still in use.  This affects anything that
> uses long-lived sessions (such as SSH to a server) and is highly
> annoying.
> 
> The RFC (4941 section 3.4) says:
> 
>   "As an optional optimization, an implementation MAY remove a
>deprecated temporary address that is not in use by applications or
>upper layers as detailed in Section 6."

You can set this on a per-connection basis with NM.  It just defaults to
"unset", which then defaults to "on".  You can also set a global default
through /etc/NetworkManager/NetworkManager.conf so that all new
connections on your system get "disabled" when they have the privacy
value unset.

nmcli con mod "" ipv6.ip6-privacy 0

Dan

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: 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


-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: F23 System Wide Change: Default Local DNS Resolver

[Dan Williams]

On Fri, 2015-06-12 at 14:32 -0400, Paul Wouters wrote:
> On Fri, 12 Jun 2015, Dan Williams wrote:
> 
> >> That is why HTTP redirection and DNS failure have to be detected by
> >> whatever is the "hot spot detector". Both items weigh in on triggering
> >> a hotspot logon window.
> >
> > Agreed.  But how does the DNS failure actually get relayed to the thing
> > doing the HTTP request, when unbound + DNSSEC is involved?  That's one
> > point I'm very unclear on.
> 
> In hotspot mode (dnssec-trigger's version of hotspot mode)
> /etc/resolv.conf contains the DHCP supplied DNS servers. Those are used
> to determine both the "DNS cleanliness" state, and is also used to fetch
> the fedoraproject hot spot detection page. The unbound DNS server, while
> running, is not used at all for anything, as resolv.conf does not point
> to it. Unfortunately, because this is not isolated to dnssec-triggerd,
> all applications doing DNS during this time get crap/dangerous DNS
> resolves, leading to add the bad certificate warning popups. And why I
> was hoping to isolate that with either a network namespace, or other
> solution that prevents us from requiring to affect the whole system
> by changing resolv.conf.
> 
> If selecting "cache only", then resolv.conf points to 127.0.0.1 and
> unbound is configured with a "DNS forwarder" for everything set to
> 127.0.0.127 so no DNS lookups ever leave the host.
> 
> >>> 1. NM connects to a new network
> >>> 2. NM updates DNS information
> >>
> >> I don't know what 2) means. If it means rewriting /etc/resolv.conf or
> >> the unbound forwarder configuration, we have already lost if the DNS
> >> was malicious (and/or a hotspot DNS)
> >
> > It means whatever "dns" action was set in NM, either writing
> > resolv.conf, not touching anything (dns=none), sending split DNS to
> > unbound (dns=unbound), or to dnsmasq (dns=dnsmasq), etc.  In this case
> > I'll presume dns=unbound.
> 
> Ahh thanks.
> 
> >> dnssec-trigger currently detects the difference by also checking for an
> >> http hotspot redirect using http://fedoraproject.org/static/hotspot.txt
> >> If no http redirect, then DNS is broken and it tries to work around it
> >> by becoming a full iterative resolver or doing DNS over TCP or DNS over
> >> TLS. and if it all fails, presents the "insecure or cache only" dialog.
> >
> > NM also checks for redirection.
> >
> > Though, what do you mean by "if no HTTP redirect, then DNS is broken"?
> 
> Sorry I meant "If no http redirect, and DNS is broken, then it tries to
> work around by ...". That is, when there is an http redirect, there is
> no point doing anything about DNS because after authenticating to the
> hotspot, DNS might turn out to be either fine or broken for other
> reasons.
> 
> >> 1) NM detects a new nework, but doesn't tell the applications that there
> >> is network connectivity yet. So firefox won't throw HTTPS warnings
> >> and pidgin/IM won't throw https warnings. Because as far as they know
> >> the network is still down.
> >
> > Agreed.  Right now we have "connectivity" states, but they are all
> > determined after the interface is signaled as "connected".  We can do
> > some work here to indicate connectivity status on this interface before
> > indicating to applications that the interface is fully connected.
> 
> That would be awesome!
> 
> >> 2) NM/dnssec-trigger does the HTTP and DNS probing and prompting using
> >> a dedicated container and any DNS requests in that container are
> >> thrown away with the container once hotspot has been authenticated.
> >> This would allow us to never have resolv.conf on the host be
> >> different from 127.0.0.1. (currently, it needs to put in the hotspot
> >> DNS servers for the hotspot logon, exposing other applications to
> >> fake DNS)
> >
> > I'm not sure a container really needs to be involved as long as the DNS
> > resolution can be done without hitting resolv.conf.  That's not hugely
> > hard to do I think
> 
> True. In fact with unbound it is pretty trivial to do. The equivalent
> unbound python code for that would be:
> 
> import unbound
> 
> ctx = unbound.ub_ctx()
> ctx.resolvconf("/this/networks/respresentation/of/resolv.conf")

Hmm, that doesn't really allow for split DNS though since it uses the
resolv.conf format?  Ideally we could just send unbound

Re: F23 System Wide Change: Default Local DNS Resolver

[Dan Williams]

On Wed, 2015-06-17 at 13:17 +0200, Tomas Hozza wrote:
> On 12.06.2015 18:58, Dan Williams wrote:
> > On Fri, 2015-06-12 at 10:58 +0200, Tomas Hozza wrote:
> >> On 11.06.2015 22:48, Dan Williams wrote:
> >>> On Tue, 2015-06-09 at 12:30 -0400, Matthew Miller wrote:
> >>>> On Tue, Jun 09, 2015 at 11:34:39AM -0400, Paul Wouters wrote:
> >>>>> decision needs to then be made by the system. I believe that's been
> >>>>> mostly due to lack of time for the various parties to sit down and
> >>>>> plan and then program this further.
> >>>>
> >>>> We should try to make that happen.
> >>>
> >>> Unfortunately the Proposal doesn't say anything about how this will
> >>> actually work, which is something NetworkManager needs to know.  It also
> >>> fails to address the failure cases where your local DNS doesn't support
> >>> DNSSEC or is otherwise broken here out of no fault of your own.
> >>
> >> NetworkManager is pure network configuration manager in this scenario.
> >> We don't expect nor want NM to handle /etc/resolv.conf. We will only get
> >> the current network configuration from it and act upon it. NM
> >> configuration will contain "dns=unbound".
> > 
> > Correct, and I personally have no problem with this.  NM is quite happy
> > to hand off DNS information wherever it has been told to do so.
> > 
> > But this is separate from the connectivity detection/hotspot issue which
> > I think we'll discuss more below.
> > 
> >> The cases when local (to the network you are connected to) DNS resolver
> >> does not support DNSSEC is handled by the logic in dnssec-trigger and
> >> dnssec-trigger script. Unbound is always configured in a way that it is
> >> able to do DNS resolution and DNSSEC validation. If this can not be
> >> done, the user is informed.
> > 
> > Right, and that's where most of this discussion lies, I think.
> > 
> >>>>>> I see that there's a "hotspot sign on" option if you right click on the
> >>>>>> icon. How does this work with Network Manager and GNOME's captive
> >>>>>> portal detection?
> >>>>> I have never seen those work except for when the backend was down and
> >>>>> I got a stream of false positives. But possibly that is because I've 
> >>>>> used
> >>>>> dnssec-trigger for years now and it might win the captive portal
> >>>>> detection race. There are some bugs once in a while but overal it works
> >>>>> pretty reliably.
> >>>>
> >>>> I think that's probably it — the race. The hotspot signon thing works
> >>>> for me at coffeeshops. Or it did before I enabled this feature. We'll
> >>>> see now!
> >>>
> >>> So, if you're behind a portal then unbound could potentially fail all
> >>> DNS lookups.  That means that NetworkManager's connectivity detection,
> >>> which relies on retrieving a URL from a known website, will fail because
> >>> the DNS lookup for it was blocked by unbound.  Thus GNOME Shell portal
> >>> detection will also fail.  That kinda sucks.
> >>
> >> If there is such situation, that Unbound fails all DNS lookups, then it
> >> is a bug. This is pure theory until you have some real situation. The
> >> logic is designed in a way to prevent such situations from ever happen.
> >> Hotspot detection is done by dnssec-trigger. The hot-spot-signon is done
> >> by putting DHCP provided resolvers into resolv.conf. So in this
> >> situation Unbound it not used at all.
> >>
> >>> While I'm sure the dnssec-trigger panel applet works great for some
> >>> people, I think the GNOME team would rather have the portal
> >>> functionality in the existing GNOME Shell indicator.  There is nothing
> >>> wrong with having DNSSEC enabled and part of the portal detection
> >>> scheme, but the UI handling portals is clearly a desktop-specific
> >>> decision.  So whatever we need to do in NM to enable the workflow that
> >>> desktops need is what we'll end up doing...  Ideally the process goes
> >>> like this when unbound/dnssec-trigger are installed:
> >>>
> >>> 1. NM connects to a new network
> >>
> >> 1.1. Dispatch dispatcher with the network configuration change event.
> >

Re: F23 System Wide Change: Default Local DNS Resolver

[Dan Williams]

On Mon, 2015-06-15 at 14:57 +0200, Petr Spacek wrote:
> On 12.6.2015 18:53, Dan Williams wrote:
> > On Fri, 2015-06-12 at 17:10 +0200, Petr Spacek wrote:
> >>> On Tue, 2015-06-09 at 12:30 -0400, Matthew Miller wrote:
> >>>> On Tue, Jun 09, 2015 at 11:34:39AM -0400, Paul Wouters wrote:
> >>>>> decision needs to then be made by the system. I believe that's been
> >>>>> mostly due to lack of time for the various parties to sit down and
> >>>>> plan and then program this further.
> >>>>
> >>>> We should try to make that happen.
> >>
> >> Okay, let's start once again from scratch.
> >>
> >> All of this was already discussed and we even had a huge meeting around
> >> DevConf and FLOCK 2014 about this, so following text will be just a short
> >> refresher:
> > 
> > Yeah, we did.  From my recollection, most of that focused on the unbound
> > parts and how NM could add the dns=unbound stuff (which Pavel
> > contributed) but less on the NM connectivity checking, becuase Fedora
> > hadn't turned that on by default yet.  I'm all fine with dns=unbound,
> > that's not the issue.  The issue is more around what happens with NM's
> > connectivity checking, since that's used by quite a few clients,
> > including GNOME Shell.
> > 
> >> The ultimate goal
> >> =
> >> Make various man-in-the-middle attacks *automatically* detectable - without
> >> any user interaction. Especially we want to get rid of dialogs like "Site
> >> www.gmail.com is using certificate issued for xxx.porn and certificate's
> >> validity ended 10 years ago. Do you want to continue? [YES] [YES] [YES]".
> >>
> >>
> >> Tools
> >> =
> >> To achieve this goal we need to do DNSSEC validation on every client 
> >> machine
> >> (ignoring Docker for a moment, see below) and allow applications to use 
> >> DNS as
> >> trusted source of sensitive data (certificate fingerprints, SSH 
> >> fingerprints,
> >> etc.).
> >>
> >> DNSSEC allows all parties to publish their fingerprints in DNS and gives 
> >> us a
> >> secure way to get the data and to detect that someone prevents us from 
> >> getting
> >> the data.
> >>
> >>
> >> Longer description
> >> ==
> >> http://developerblog.redhat.com/2015/04/14/writing-an-application-that-supports-dnssec-in-rhel-and-fedora/
> >>
> >>
> >> First step: DNSSEC validation
> >> =
> >> Contemporary networks are full of broken DNS proxies so we need to jump
> >> through various hoops to get non-faked DNSSEC data for DNSSEC validation.
> >>
> >> The goal of this step is to get *cryptographical* proof that the data we
> >> received are the same as DNS zone owner published.
> >>
> >> This includes two sub-problems:
> >> a) Hot-spots:
> >> Captive portal detection needs to allow user to disable all the security 
> >> so he
> >> can log-in but this needs to be done in a secure and reliable way so an
> >> attacker cannot misuse this.
> >>
> >> b) Broken networks:
> >> Some networks are so broken that even without captive portal they are not 
> >> able
> >> to deliver DNSSEC data to the clients.
> >>
> >> In that case will try tunnel to other DNS servers on the Internet (Fedora
> >> Infra or public DNS root) and use them. Naturally, local/internal domains 
> >> need
> >> to be available.
> > 
> > While I don't actually care, this might well be a sticking point for
> > many people since their DNS information is going to an untrusted (to
> > them) DNS server.  Yeah, I tend to trust Fedora, but not everyone will.
> > Can the tunnel be turned off, or the broken servers whitelisted, or is
> > the answer here to just "dnf remove dnssec-trigger"?
> > 
> >> All these sub-problems (including VPN handling an so on) are solved by
> >> dnssec-trigger with tweaks by Tomas Hozza and Pavel Simerda.
> >>
> >>
> >> HERE we need to coordinate with other parties who might want to write into 
> >> the
> >> /etc/resolv.conf file. These include (but might not be limited to):
> >> NetworkManager
> >> initscripts
> >> dhclient
> >> libreswan ?
> >> resolved
> >&g

Re: F23 System Wide Change: Default Local DNS Resolver

[Dan Williams]

On Thu, 2015-06-11 at 14:41 -0700, Andrew Lutomirski wrote:
> On Thu, Jun 11, 2015 at 1:48 PM, Dan Williams  wrote:
> > On Tue, 2015-06-09 at 12:30 -0400, Matthew Miller wrote:
> >> On Tue, Jun 09, 2015 at 11:34:39AM -0400, Paul Wouters wrote:
> >> > decision needs to then be made by the system. I believe that's been
> >> > mostly due to lack of time for the various parties to sit down and
> >> > plan and then program this further.
> >>
> >> We should try to make that happen.
> >
> > Unfortunately the Proposal doesn't say anything about how this will
> > actually work, which is something NetworkManager needs to know.  It also
> > fails to address the failure cases where your local DNS doesn't support
> > DNSSEC or is otherwise broken here out of no fault of your own.
> >
> >> > >I see that there's a "hotspot sign on" option if you right click on the
> >> > >icon. How does this work with Network Manager and GNOME's captive
> >> > >portal detection?
> >> > I have never seen those work except for when the backend was down and
> >> > I got a stream of false positives. But possibly that is because I've used
> >> > dnssec-trigger for years now and it might win the captive portal
> >> > detection race. There are some bugs once in a while but overal it works
> >> > pretty reliably.
> >>
> >> I think that's probably it — the race. The hotspot signon thing works
> >> for me at coffeeshops. Or it did before I enabled this feature. We'll
> >> see now!
> >
> > So, if you're behind a portal then unbound could potentially fail all
> > DNS lookups.  That means that NetworkManager's connectivity detection,
> > which relies on retrieving a URL from a known website, will fail because
> > the DNS lookup for it was blocked by unbound.  Thus GNOME Shell portal
> > detection will also fail.  That kinda sucks.
> 
> I think that part of the problem is that there are too many
> implementations of captive portal detection and too many
> half-thought-out implementations of what do do if a captive portal is
> detected.
> 
> I think that, on a well-functioning system, if I connect to a wireless
> network, something should detect if I'm behind a captive portal.  If
> so, I should get a stateless browser that clearly indicates that it's
> a captive portal browser, probably lives in a sandbox, and sees the
> raw view of the network (no local DNSSEC validation).  We have network
> namespaces -- the browser part is doable even in a scenario where we
> wouldn't want to expose the incorrect view of DNS or some other aspect
> of the network to normal applications.   (Heck, on a configuration
> where we want to use a VPN over untrusted wireless, we could avoid
> exposing the untrusted wireless network to applications other than
> captive portal login at all.)
> 
> Please note that the current GNOME captive portal mechanism is
> blatantly insecure, and I've already filed a bug report with no
> resolution.  I'm not disclosing a subtle 0-day here -- the insecurity
> is fairly obvious.  I'll probably post to oss-security soon, but
> that's a somewhat separate topic.
> 
> Once we determine that there's no captive portal or that we've logged
> in to it, we should validate DNSSEC and otherwise behave sensibly.  If
> the network is screwed up enough that normal DNSSEC can't get through
> the DHCP-provided resolver (which happens -- I've seen ISPs that
> tamper with DNS results for www.google.com), then we should tunnel
> around it.  IIRC dnssec-triggerd already supports this.

So it sounds like there are two levels here:

1) connectivity detection and hotspot login using the network-provided
DNS servers, which are quite possibly insecure and/or broken

2) once that is all done, handling DNSSEC issues if the network-provided
DNS servers are insecure/broken.

Which is fine; I'm mostly concerned with #1 at this point because I
don't think NetworkManager has much to do with #2 since it already has
mechanisms to push the network's DNS servers to whatever wants it
(unbound, etc).

> >
> > While I'm sure the dnssec-trigger panel applet works great for some
> > people, I think the GNOME team would rather have the portal
> > functionality in the existing GNOME Shell indicator.  There is nothing
> > wrong with having DNSSEC enabled and part of the portal detection
> > scheme, but the UI handling portals is clearly a desktop-specific
> > decision.
> 
> This hasn't worked so well in the past.  Back when 

Re: F23 System Wide Change: Default Local DNS Resolver

[Dan Williams]

On Fri, 2015-06-12 at 00:48 -0400, Paul Wouters wrote:
> On Thu, 11 Jun 2015, Dan Williams wrote:
> 
> > Unfortunately the Proposal doesn't say anything about how this will
> > actually work, which is something NetworkManager needs to know.  It also
> > fails to address the failure cases where your local DNS doesn't support
> > DNSSEC or is otherwise broken here out of no fault of your own.
> 
> dnssec-trigger prompts the user with a choice of "allow insecure DNS" or
> "cache only mode". The latter means "no new DNS and use what's already
> in the cache only".

Yeah, and the interaction story here has been controversial for a long
time.  The GNOME team certainly has ideas about how it should work,
which are partly shown by the current hotspot/portal implementation in
GNOME Shell.  I'll let them discuss these ideas since NM is not involved
in the higher-level UI story here, just the mechanics of providing
"might this be a portal" to any NM client, GNOME Shell included.

> > So, if you're behind a portal then unbound could potentially fail all
> > DNS lookups.  That means that NetworkManager's connectivity detection,
> > which relies on retrieving a URL from a known website, will fail because
> > the DNS lookup for it was blocked by unbound.  Thus GNOME Shell portal
> > detection will also fail.  That kinda sucks.
> 
> That is why HTTP redirection and DNS failure have to be detected by
> whatever is the "hot spot detector". Both items weigh in on triggering
> a hotspot logon window.

Agreed.  But how does the DNS failure actually get relayed to the thing
doing the HTTP request, when unbound + DNSSEC is involved?  That's one
point I'm very unclear on.

> > While I'm sure the dnssec-trigger panel applet works great for some
> > people, I think the GNOME team would rather have the portal
> > functionality in the existing GNOME Shell indicator.
> 
> Everyone is in agreement here I believe. No one particularly likes the
> dnssec-trigger ui. It was written as an desktop agnostic tool - for
> instance it works on Windows and OSX. I'd love to see this better
> integrated into gnome.
> 
> > desktops need is what we'll end up doing...  Ideally the process goes
> > like this when unbound/dnssec-trigger are installed:
> >
> > 1. NM connects to a new network
> > 2. NM updates DNS information
> 
> I don't know what 2) means. If it means rewriting /etc/resolv.conf or
> the unbound forwarder configuration, we have already lost if the DNS
> was malicious (and/or a hotspot DNS)

It means whatever "dns" action was set in NM, either writing
resolv.conf, not touching anything (dns=none), sending split DNS to
unbound (dns=unbound), or to dnsmasq (dns=dnsmasq), etc.  In this case
I'll presume dns=unbound.

> > 3. NM waits for some signal from unbound/dnssec-trigger about the
> > trustability of the DNS server
> > 3a. if the DNS server is trusted, NM continues with its connectivity
> > check
> > 3b. if the DNS server is not trusted or DNSSEC is broken, then ???  How
> > do we distinguish between "portal" and simply that your local DNS
> > doesn't support DNSSEC or is otherwise broken, if we cannot resolve the
> > address of the connectivity server?
> 
> dnssec-trigger currently detects the difference by also checking for an
> http hotspot redirect using http://fedoraproject.org/static/hotspot.txt
> If no http redirect, then DNS is broken and it tries to work around it
> by becoming a full iterative resolver or doing DNS over TCP or DNS over
> TLS. and if it all fails, presents the "insecure or cache only" dialog.

NM also checks for redirection.

Though, what do you mean by "if no HTTP redirect, then DNS is broken"?
Do you mean to prefix that with "If the correct response is not
recevied..."?

> But, if I could have my "ideal scenario", things would be a little
> different:
> 
> 1) NM detects a new nework, but doesn't tell the applications that there
> is network connectivity yet. So firefox won't throw HTTPS warnings
> and pidgin/IM won't throw https warnings. Because as far as they know
> the network is still down.

Agreed.  Right now we have "connectivity" states, but they are all
determined after the interface is signaled as "connected".  We can do
some work here to indicate connectivity status on this interface before
indicating to applications that the interface is fully connected.

> 2) NM/dnssec-trigger does the HTTP and DNS probing and prompting using
> a dedicated container and any DNS requests in that container are
> thrown away wi

Re: F23 System Wide Change: Default Local DNS Resolver

[Dan Williams]

On Fri, 2015-06-12 at 10:58 +0200, Tomas Hozza wrote:
> On 11.06.2015 22:48, Dan Williams wrote:
> > On Tue, 2015-06-09 at 12:30 -0400, Matthew Miller wrote:
> >> On Tue, Jun 09, 2015 at 11:34:39AM -0400, Paul Wouters wrote:
> >>> decision needs to then be made by the system. I believe that's been
> >>> mostly due to lack of time for the various parties to sit down and
> >>> plan and then program this further.
> >>
> >> We should try to make that happen.
> > 
> > Unfortunately the Proposal doesn't say anything about how this will
> > actually work, which is something NetworkManager needs to know.  It also
> > fails to address the failure cases where your local DNS doesn't support
> > DNSSEC or is otherwise broken here out of no fault of your own.
> 
> NetworkManager is pure network configuration manager in this scenario.
> We don't expect nor want NM to handle /etc/resolv.conf. We will only get
> the current network configuration from it and act upon it. NM
> configuration will contain "dns=unbound".

Correct, and I personally have no problem with this.  NM is quite happy
to hand off DNS information wherever it has been told to do so.

But this is separate from the connectivity detection/hotspot issue which
I think we'll discuss more below.

> The cases when local (to the network you are connected to) DNS resolver
> does not support DNSSEC is handled by the logic in dnssec-trigger and
> dnssec-trigger script. Unbound is always configured in a way that it is
> able to do DNS resolution and DNSSEC validation. If this can not be
> done, the user is informed.

Right, and that's where most of this discussion lies, I think.

> >>>> I see that there's a "hotspot sign on" option if you right click on the
> >>>> icon. How does this work with Network Manager and GNOME's captive
> >>>> portal detection?
> >>> I have never seen those work except for when the backend was down and
> >>> I got a stream of false positives. But possibly that is because I've used
> >>> dnssec-trigger for years now and it might win the captive portal
> >>> detection race. There are some bugs once in a while but overal it works
> >>> pretty reliably.
> >>
> >> I think that's probably it — the race. The hotspot signon thing works
> >> for me at coffeeshops. Or it did before I enabled this feature. We'll
> >> see now!
> > 
> > So, if you're behind a portal then unbound could potentially fail all
> > DNS lookups.  That means that NetworkManager's connectivity detection,
> > which relies on retrieving a URL from a known website, will fail because
> > the DNS lookup for it was blocked by unbound.  Thus GNOME Shell portal
> > detection will also fail.  That kinda sucks.
> 
> If there is such situation, that Unbound fails all DNS lookups, then it
> is a bug. This is pure theory until you have some real situation. The
> logic is designed in a way to prevent such situations from ever happen.
> Hotspot detection is done by dnssec-trigger. The hot-spot-signon is done
> by putting DHCP provided resolvers into resolv.conf. So in this
> situation Unbound it not used at all.
> 
> > While I'm sure the dnssec-trigger panel applet works great for some
> > people, I think the GNOME team would rather have the portal
> > functionality in the existing GNOME Shell indicator.  There is nothing
> > wrong with having DNSSEC enabled and part of the portal detection
> > scheme, but the UI handling portals is clearly a desktop-specific
> > decision.  So whatever we need to do in NM to enable the workflow that
> > desktops need is what we'll end up doing...  Ideally the process goes
> > like this when unbound/dnssec-trigger are installed:
> > 
> > 1. NM connects to a new network
> 
> 1.1. Dispatch dispatcher with the network configuration change event.
> 
> > 2. NM updates DNS information
> 
> NM is not expected to touch resolv.conf in the intended default
> configuration.

My #2 was intended to be the same as your #1.1.  I was assuming
"dns=unbound" here.

> > 3. NM waits for some signal from unbound/dnssec-trigger about the
> > trustability of the DNS server
> 
> If you think NM needs to do some action (as I don't), we don't have
> problem with notifying NM (if you provide some API).

NM may need to do some action for connectivity checking.

> > 3a. if the DNS server is trusted, NM continues with its connectivity
> > check
> > 3b. if the DNS server is not trusted or DNSSEC is broken, then ???  How
> >

Re: F23 System Wide Change: Default Local DNS Resolver

[Dan Williams]

On Fri, 2015-06-12 at 17:10 +0200, Petr Spacek wrote:
> > On Tue, 2015-06-09 at 12:30 -0400, Matthew Miller wrote:
> >> On Tue, Jun 09, 2015 at 11:34:39AM -0400, Paul Wouters wrote:
> >>> decision needs to then be made by the system. I believe that's been
> >>> mostly due to lack of time for the various parties to sit down and
> >>> plan and then program this further.
> >>
> >> We should try to make that happen.
> 
> Okay, let's start once again from scratch.
> 
> All of this was already discussed and we even had a huge meeting around
> DevConf and FLOCK 2014 about this, so following text will be just a short
> refresher:

Yeah, we did.  From my recollection, most of that focused on the unbound
parts and how NM could add the dns=unbound stuff (which Pavel
contributed) but less on the NM connectivity checking, becuase Fedora
hadn't turned that on by default yet.  I'm all fine with dns=unbound,
that's not the issue.  The issue is more around what happens with NM's
connectivity checking, since that's used by quite a few clients,
including GNOME Shell.

> The ultimate goal
> =
> Make various man-in-the-middle attacks *automatically* detectable - without
> any user interaction. Especially we want to get rid of dialogs like "Site
> www.gmail.com is using certificate issued for xxx.porn and certificate's
> validity ended 10 years ago. Do you want to continue? [YES] [YES] [YES]".
> 
> 
> Tools
> =
> To achieve this goal we need to do DNSSEC validation on every client machine
> (ignoring Docker for a moment, see below) and allow applications to use DNS as
> trusted source of sensitive data (certificate fingerprints, SSH fingerprints,
> etc.).
> 
> DNSSEC allows all parties to publish their fingerprints in DNS and gives us a
> secure way to get the data and to detect that someone prevents us from getting
> the data.
> 
> 
> Longer description
> ==
> http://developerblog.redhat.com/2015/04/14/writing-an-application-that-supports-dnssec-in-rhel-and-fedora/
> 
> 
> First step: DNSSEC validation
> =
> Contemporary networks are full of broken DNS proxies so we need to jump
> through various hoops to get non-faked DNSSEC data for DNSSEC validation.
> 
> The goal of this step is to get *cryptographical* proof that the data we
> received are the same as DNS zone owner published.
> 
> This includes two sub-problems:
> a) Hot-spots:
> Captive portal detection needs to allow user to disable all the security so he
> can log-in but this needs to be done in a secure and reliable way so an
> attacker cannot misuse this.
> 
> b) Broken networks:
> Some networks are so broken that even without captive portal they are not able
> to deliver DNSSEC data to the clients.
> 
> In that case will try tunnel to other DNS servers on the Internet (Fedora
> Infra or public DNS root) and use them. Naturally, local/internal domains need
> to be available.

While I don't actually care, this might well be a sticking point for
many people since their DNS information is going to an untrusted (to
them) DNS server.  Yeah, I tend to trust Fedora, but not everyone will.
Can the tunnel be turned off, or the broken servers whitelisted, or is
the answer here to just "dnf remove dnssec-trigger"?

> All these sub-problems (including VPN handling an so on) are solved by
> dnssec-trigger with tweaks by Tomas Hozza and Pavel Simerda.
> 
> 
> HERE we need to coordinate with other parties who might want to write into the
> /etc/resolv.conf file. These include (but might not be limited to):
> NetworkManager
> initscripts
> dhclient
> libreswan ?
> resolved
> connman

pppd, vpnc, openvpn, etc. should get added to the list since they all
have scripts that can potentially write to /etc/resolv.conf.

> Option is either to implement all the checks and workarounds in all the
> projects over and over or to implement all the logic in one place -
> dnssec-trigger might be such place.
> 
> Anyone who is going to write to resolv.conf needs to check for captive
> portals, find a DNSSEC-enabled DNS server, and deal with VPN-provided DNS
> servers and domains.
> 
> *Questions:*
> Guys, what are your plans for handling the situations mentioned above?
> 
> Can we integrate on one place (e.g. by calling into dnssec-trigger) instead
> overwriting /etc/resolv.conf independently?

This is the real issue.  It sounds like What you're proposing is to make
dnssec-trigger into the "DNS broker".  The previous solutions
(resolvconf, NetworkManager, etc) have all failed for various reasons.
Touching/changing something so fundamental to the system, as you've
probably discovered, can be hard...

systemd-resolved might have a chance here, since it's small and pretty
simple, but they don't have an external API and don't seem interested in
creating one any time soon which severely limits it's usefulness.

If this is indeed what you're proposing, then lets have a discussion
about dnssec-trigger+unbound in that c

Re: F23 System Wide Change: Default Local DNS Resolver

[Dan Williams]

On Fri, 2015-06-12 at 10:20 -0400, Matthew Miller wrote:
> On Fri, Jun 12, 2015 at 10:58:14AM +0200, Tomas Hozza wrote:
> > NetworkManager is pure network configuration manager in this scenario.
> > We don't expect nor want NM to handle /etc/resolv.conf. We will only get
> > the current network configuration from it and act upon it. NM
> > configuration will contain "dns=unbound".
> 
> Another integration concern: the network config GUI (and ifcfg files,
> for that matter) let me list specific DNS servers. With this
> feature, are those used (and if so, how)? If not, is my configuration
> just silently ignored?

NM will use those DNS servers as it always has, and with dns=unbound
will simply forward them to unbound, which will use your servers as the
upstream servers.  Basically, any information that NM used to write to
resolv.conf will now instead get forwarded to unbound.

What unbound wants to do with it is another story, of course, that I'm
not an expert on but Thomas/Paul/etc are.

Dan

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: F23 System Wide Change: Default Local DNS Resolver

[Dan Williams]

On Tue, 2015-06-09 at 12:30 -0400, Matthew Miller wrote:
> On Tue, Jun 09, 2015 at 11:34:39AM -0400, Paul Wouters wrote:
> > decision needs to then be made by the system. I believe that's been
> > mostly due to lack of time for the various parties to sit down and
> > plan and then program this further.
> 
> We should try to make that happen.

Unfortunately the Proposal doesn't say anything about how this will
actually work, which is something NetworkManager needs to know.  It also
fails to address the failure cases where your local DNS doesn't support
DNSSEC or is otherwise broken here out of no fault of your own.

> > >I see that there's a "hotspot sign on" option if you right click on the
> > >icon. How does this work with Network Manager and GNOME's captive
> > >portal detection?
> > I have never seen those work except for when the backend was down and
> > I got a stream of false positives. But possibly that is because I've used
> > dnssec-trigger for years now and it might win the captive portal
> > detection race. There are some bugs once in a while but overal it works
> > pretty reliably.
> 
> I think that's probably it — the race. The hotspot signon thing works
> for me at coffeeshops. Or it did before I enabled this feature. We'll
> see now!

So, if you're behind a portal then unbound could potentially fail all
DNS lookups.  That means that NetworkManager's connectivity detection,
which relies on retrieving a URL from a known website, will fail because
the DNS lookup for it was blocked by unbound.  Thus GNOME Shell portal
detection will also fail.  That kinda sucks.

While I'm sure the dnssec-trigger panel applet works great for some
people, I think the GNOME team would rather have the portal
functionality in the existing GNOME Shell indicator.  There is nothing
wrong with having DNSSEC enabled and part of the portal detection
scheme, but the UI handling portals is clearly a desktop-specific
decision.  So whatever we need to do in NM to enable the workflow that
desktops need is what we'll end up doing...  Ideally the process goes
like this when unbound/dnssec-trigger are installed:

1. NM connects to a new network
2. NM updates DNS information
3. NM waits for some signal from unbound/dnssec-trigger about the
trustability of the DNS server
3a. if the DNS server is trusted, NM continues with its connectivity
check
3b. if the DNS server is not trusted or DNSSEC is broken, then ???  How
do we distinguish between "portal" and simply that your local DNS
doesn't support DNSSEC or is otherwise broken, if we cannot resolve the
address of the connectivity server?

Dan

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Roaming, and libresolv being stuck in the 1980's mindset

[Dan Williams]

On Mon, 2015-04-20 at 16:27 -0600, Philip Prindeville wrote:
> On Apr 20, 2015, at 12:23 AM, Siddhesh Poyarekar  wrote:
> 
> > On Sat, Apr 18, 2015 at 01:49:57PM -0600, Philip Prindeville wrote:
> >> If you go back through the previous glibc bugs, you'll find:
> >> 
> >> https://sourceware.org/bugzilla/show_bug.cgi?id=984
> >> 
> >> from 2005 which was closed out as "RESOLVED, WONTFIX" with the text:
> >> 
> >>There is a solution, already implemented.
> >>Use nscd and nscd -i hosts in the script that rewrites your resolv.conf
> >>(or nsswitch.conf etc.).
> > 
> > Yes, that has been the upstream stance since quite some time now, so I
> > don't know if filing a fresh bug would change that.  You could however
> > start a discussion upstream (libc-alpha at sourceware dot org) and
> > make a case for the resolver to watch for changes in resolv.conf.
> 
> 
> Yeah… I think inotify() might be the cleanest fix for that, but it’s not 
> particularly portable.
> 
> stat() would work everywhere else.
> 
> Threading complicates things a bit, though.

We tried to push inotify() style watching in glibc in the past, and I
think even Debian ships a patch for that.  But the response was always
"use a local caching nameserver" because glibc cannot be all things to
everyone.  And honestly, that's not an unreasonable answer.  If you use
a local caching nameserver then you get split DNS too, which libresolv
cannot give you.  You may encounter this same argument from upstream.

However, when we last tried in NetworkManager land, that was like 2
glibc maintainers ago, and current maintainers might have softened their
stance.  In any case, I think it makes sense to just go with a local
caching nameserver anyway, for the split DNS.  Then the network
management daemon (or whatever you use to switch networks) can forward
the DNS+domain info to the caching nameserver and everything is happy.

Obviously, this doesn't excuse apps like Evolution/Thunderbird/etc from
the equation, since they should really be smart enough to know that if
they are not connected to the corporate VPN, they can't pull mail from
it.  But that's between the network management daemon and the app, and
doesn't involve the resolver at all.

Dan

> > 
> >> Problem with that is that no one seems to have gravitated towards
> >> this solution, and I don't blame them. It adds an extra layer of
> >> complexity and makes debugging issues that much more murky.
> >> 
> >> A simpler fix is to grab mtime from stat()ing _PATH_RESCONF each
> >> time through res_query() and see if it's changed since the last
> >> time.  Perhaps caching the inode # also and checking that, since an
> >> older version of the file might have been renamed as
> >> /etc/resolv.conf.
> > 
> > That is conceptually simple, but expensive, since you'll be adding
> > syscalls to every lookup.  One may argue that it is not much overhead
> > for a network lookup since the latter will still take up a bulk of the
> > time, but it is an added cost nevertheless.
> > 
> > Siddhesh
> 
> 
> syscalls are a lot cheaper than network round-trips.  At least in 99% of the 
> cases.
> 
> How often does name resolution happen, anyway?  Not very often.  You 
> typically take call it before opening a socket, and then that socket persists 
> a long time…
> 
> In the case of split-horizon DNS service in a corporate environment, this 
> problem still wouldn’t be solved, at least not directly.
> 
> What might happen is you resolve imap.mycorp.com to some inside-the-firewall 
> 10.x.x.x address, and connect to that.  Then you roam off the network, but of 
> course Thunderbird (for instance) knows nothing about this… it just 
> eventually drops the connection because that address becomes unreachable (or 
> points a new host with no knowledge of this TCP connection and it promptly 
> RESETs).  TB then tries to reopen a connection… I’ve not looked at TB source 
> in about 8 years so I don’t know if it would redo the name resolution or not… 
> if yes, then it might point to a new exterior name server and get the 
> external (public-facing) address of imap.mycorp.com and things work again…  
> But that’s being optimistic.
> 
> The behavior I’ve seen implies that it caches the address from the original 
> resolution and keeps trying to reconnect to that.
> 
> But having libresolv transparently relearn the /etc/resolv.conf settings is 
> the first step toward doing the right thing.
> 
> -Philip
> 
> 
> 
> 


-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Enable Wake-On-LAN in current Fedora

[Dan Williams]

On Tue, 2015-04-14 at 09:12 -0700, Samuel Sieb wrote:
> On 04/14/2015 09:06 AM, Chris Adams wrote:
> > Once upon a time, Sergio Pascual  said:
> >> I was wondering what is the "correct" way of enabling WOL on a network 
> >> card.
> >
> > I think it is enabled by default.  At least, I didn't do anything to
> > enable it on a couple of computers at home and it "just works".
> >
> Make sure it's enabled in the BIOS.

On the NetworkManager side there isn't any checkbox for enable/disable
since that's a bit lower-level than NM right now, but NM won't screw
anything up if you enable WoL with ethtool through some other mechanism,
like a systemd unit file.

Dan

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Captive portal detection on wired connections - bug or feature?

[Dan Williams]

On Fri, 2015-03-27 at 20:30 +0200, Alexander Ploumistos wrote:
> On Fri, Mar 27, 2015 at 8:09 PM, Pádraig Brady  wrote:
> > There are still quite a few unknowns.
> > To summarise, does this locally disable?
> >
> >   crudini --set /etc/NetworkManager/conf.d/21-connectivity-local.conf 
> > connectivity interval 0
> >   systemctl reload NetworkManager
> 
> Take a look at
> https://blogs.gnome.org/dcbw/2015/02/16/networkmanager-for-administrators-part-1
> it's Dan Williams' blog post I mentioned earlier. According to that,
> your command should work.
> As stated before, all the options are documented in the
> NetworkManager.conf manpage.

Also note that NM 1.2 will have SIGHUP-style reloading of the
connectivity config parameters, so when that shows up you won't need the
wield the restart hammer.  1.0 and earlier do need a restart to notice.

Dan

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Captive portal detection on wired connections - bug or feature?

[Dan Williams]

On Thu, 2015-03-26 at 18:29 +0200, Alexander Ploumistos wrote:
> On Thu, Mar 26, 2015 at 6:24 PM, Bastien Nocera  wrote:
> 
> > You can edit /etc/NetworkManager/conf.d/20-connectivity-fedora.conf to
> > disable it.
> >
> 
> Is there a *proper* way to do that so that there aren't any conflicts with
> future updates, e.g. commenting the lines out, removing/renaming the file,
> setting the interval to 0, etc.?

As Adam implied, you can add your own, higher-numbered file with the
same options and NM will use those in preference to the Fedora-installed
one.  See 'man NetworkManager.conf' for specifics.

---
   If a default NetworkManager.conf is provided by your
distribution's packages, you should not modify it, since your changes
may get overwritten by
   package updates. Instead, you can add additional .conf files to
the conf.d directory. These will be read in order, with later files
overriding
   earlier ones.
---

Sorting of filenames is strcmp()-style, so 90-my-stuff.conf takes
precedence over 10-bad-stuff.conf.

Dan

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Captive portal detection on wired connections - bug or feature?

[Dan Williams]

On Thu, 2015-03-26 at 10:45 -0500, Michael Catanzaro wrote:
> On Wed, 2015-03-25 at 21:02 -0600, Kevin Fenzi wrote:
> > This was most likely caused by some issues with out proxy servers this
> > evening. We were adding 3 new proxy servers into the rotation and there
> > were some config issues with some of them. ;( 
> > 
> > This would have only affected some folks in North America sporadically,
> > (when they happened to hit a proxy that wasn't working right) not
> > everyone. 
> > 
> > Sorry this happened, everything should be back to normal now. 
> 
> I think it would make sense to do a second ping to some other server if
> the first one to fedoraproject.org fails, for robustness. Maybe to
> redhat.com, or something that should never be down like google.com (my
> vote), or to someplace that promises not to track users, like
> duckduckgo.com (hardly matters much for a connectivity check?).

We could always use the Google servers that Android uses by default,
instead of Fedora :)  Those would be pretty well guaranteed to be up...

Dan

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: systemd-219 issues with 22 and Rawhide composes

[Dan Williams]

On Mon, 2015-03-02 at 08:42 -0800, Brian C. Lane wrote:
> On Fri, Feb 27, 2015 at 04:21:51PM +0100, Zbigniew Jędrzejewski-Szmek wrote:
> > On Fri, Feb 27, 2015 at 08:18:12AM -0500, Nico Kadel-Garcia wrote:
> > > On Mon, Feb 23, 2015 at 10:43 AM, Lennart Poettering
> > >  wrote:
> > > > On Mon, 23.02.15 08:45, Nico Kadel-Garcia (nka...@gmail.com) wrote:
> > > 
> > > [ notes snipped, ]
> > > 
> > > > You know, that systemd creates a symlink if the file is missing is not
> > > > going to change behaviour of anything, since it will only do something
> > > > if the file is *missing*.
> > > 
> > > Congratulations. We now have inconsistent behavior if anyone, *ever*,
> > > edits /etc/resolf.conf with 'sed -i', uses "rsync -a" or "cp -a" tp
> > > reproduce it from a known good repository, and with a symlink in place
> > > we're storing absolutely critical system information in a non /etc
> > > location, meaning that non-modified backup systems won't get a copy
> > > with valid content.
> > > 
> > > Just. great.
> > > 
> > > Look, deciding to ignore the File System Hierarchy for installing
> > > config files and creating new locations to store system configuration
> > Actually it might be considered that we are *starting* to follow FHS.
> > In many (most?) setups /etc/resolv.conf configuration is very dynamic:
> > the set of resolvers depends on dhcp leases, VPNs, network interfaces
> > coming and going. Storing this information in /etc/ is wrong. It's good
> > that this ephmeral content is not backed up. If the machine reboots, you
> > do not want to restore it, you want to recreate it from scratch.
> > 
> > If someone has a static setup and a static resolv.conf is fine for them,
> > there's no problem: just create a normal file.
> 
> The underlying problem here is that it isn't just created when it is
> missing. It is created *before* other tools have a chance to create it.
> As I explained in 1197204 the boot.iso is created without a
> /etc/resolv.conf, this means that NM should create it with whatever
> content it needs. Except that systemd-tmpfiles comes along first,
> assumes it can create it and then breaks NM.

With NM <= 1.0, it will create a tempfile in /etc and then rename that
over top of the existing /etc/resolv.conf, though it does try to follow
a link (with realpath(2)) and replace that file atomically (with
rename(2)).  If that's being broken by systemd we should probably handle
this case better in NM too, along with whatever systemd changes need to
happen.

With NM > 1.0, NM will stop touching resolv.conf at all if it's a
symlink, because that file is owned by some other process.  NM will
still write out it's own resolv.conf to /var/run.  If resolv.conf is a
file, and NM is allowed to manage DNS through its config, then NM will
make resolv.conf a symlink to its file in /var/run, much like I
understand systemd does.

Dan

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: systemd-219 issues with 22 and Rawhide composes

[Dan Williams]

On Fri, 2015-02-20 at 17:43 +0100, Florian Weimer wrote:
> On 02/20/2015 05:11 PM, Lennart Poettering wrote:
> 
> > Also, NM fixed a similar issue with /etc/resolve.conf in their code a
> > long time ago, to my knowledge. Am I so misguided to assume that
> > Anaconda can fix a fricking file copy too, in all those months?
> 
> Maybe it is time to step back and consider if replacing /etc/resolv.conf
> with a symbolic link is something that can be reasonably implemented
> from a backwards compatibility perspective?
> 
> Usually, if we face this much trouble within Fedora itself, it's a good
> indicator of the pain that we'll have to deal with downstream.

I would love to know the outcome of this discussion, since we just made
a change to NetworkManager git master (will be version 1.2, target
Fedora 23) to make /etc/resolv.conf a symlink when it's under NM's
control.  If there are problems here, we want to know too.

* NM won't replace a symlinked /etc/resolv.conf that doesn't point to
NM's copy in /var
* You can disable this behavior with "dns=none"
in /etc/NetworkManager/NetworkManager.conf and manage resolv.conf on
your own too

Dan

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: initscripts

[Dan Williams]

On Mon, 2015-02-02 at 06:19 +0100, Björn Persson wrote:
> Dan Williams wrote:
> >I'd also point out that there are three different NetworkManager GUIs,
> >and one TUI:
> >
> >1) GNOME Shell network settings - not really targeted for server
> >environments, has a smaller set of options that are suitable for
> >desktop/workstation use-cases
> >
> >2) nm-connection-editor - presents a larger set of options than #1, and
> >only modifies *saved configuration*, not runtime configuration.  eg, it
> >is basically a much more capable system-config-network but without the
> >"up/down" buttons
> >
> >3) KDE's network configuration dialogs
> >
> >4) nmtui - a slightly simpler version of nm-connection-editor intended
> >for GUI-less environments, like a more capable
> >system-config-network-tui
> >
> >#2 and #4 obviously run much better in desktop environments like LXDE,
> >XFCE, etc where the full GNOME stack is not available.
> >
> >It's important to note which one you're talking about when suggesting
> >improvements, since they are developed by different projects and each
> >one has a different target audience.  That said, I understand it can be
> >confusing which one is for who and available where...
> 
> I bet most users aren't even aware that there are multiple user
> interfaces for network configuration, and therefore they also aren't
> aware that there is a need to specify which of them one is talking
> about.
> 
> What's the recommended way for a user to find out which of the three
> GUIs it is that pops up when one clicks on a menu entry, when the
> window title is something generic like "network configuration" and
> there is no about dialog? Run "ps -ef" and look for recently started
> processes?

Assuming the current versions of the various DEs, then in GNOME, the
thing you're looking at is the GNOME tools.  If you're in KDE, then it's
the KDE tools.  If you're in XFCE/LXDE, then it's likely
nm-connection-editor.  So I guess I should say "what DE are you
running"...

Dan

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Filing Bugs for Python 3 Switch

[Dan Williams]

On Wed, 2015-01-28 at 11:09 -0500, Bohuslav Kabrda wrote:
> Hi,
> I just filed 2 bugs [A], [B] for the Python 3 switch [C] and I realized that 
> I should probably follow the mass bug filing policy.
> As I've said previously, we've already had both Python 2 and Python 3 on 
> LiveCDs for few releases, so it makes sense to move as much as possible to 
> Python 3. My intention is to mass file bugs only for "applications" (see the 
> second item in second list at [D]) - in short, these are packages for which 
> it doesn't make sense to introduce python3- subpackage, but it only makes 
> sense to rebuild them with Python 3.
> The mass bug filing policy suggests providing text of the bug for review, so 
> here it is:
> 
> 
> Since your package requires Python and is considered an application as per 
> [1], I'd like to ask you to rebuild it with Python 3. Please see 
> recommendations and notes at [2]. Note: this switch should only be done 
> assuming you need to do none or very little downstream patching of upstream 
> source. If upstream source doesn't work with Python 3, it's ok to stay with 
> Python 2.
> 
> Some general notes:
> If your package depends on Python because of a Python script that has 
> /usr/bin/python in hashbang, you need to change this to /usr/bin/python3. All 
> "Requires" and "BuildRequires" on Python extension modules have to be changed 
> from "python-foo" to "python3-foo" in order for this change to work. If your 
> package is an "application" (let's call it "foo") and it also generates a 
> subpackage with Python bindings (i.e. "python-foo" or "foo-python"), you 
> should provide a python3 subpackage ("python3-foo" or "foo-python3") and use 
> that as dependency of other subpackages.

How about "#!/usr/bin/env python"?  I don't recall who suggested this a
long time ago, but I'm 99% sure it was to better handle python3...

Dan

> [1] http://fedoraproject.org/wiki/Changes/Python_3_as_Default
> [2] https://fedoraproject.org/wiki/Packaging:Python#Guidelines
> 
> 
> If everyone agrees, I'll send a mail to devel-announce, saying that we're 
> switching to Python 3 and all maintainers should rebuild with it, assuming 
> that upstream sources are Python 3 compatible. After a week or so I'll file 
> bugs for the remaining components. I haven't yet determined the number of 
> affected packages, since I'm mostly interested in packages that are on 
> LiveCD/cloud images - there are ~10 of these that don't have bugs filed.
> 
> I'll wait a while before sending the mail to devel-announce so that everyone 
> has time to comment on this.
> 
> Thanks,
> Slavek
> 
> [A] https://bugzilla.redhat.com/show_bug.cgi?id=1186791
> [B] https://bugzilla.redhat.com/show_bug.cgi?id=1186792
> [C] http://fedoraproject.org/wiki/Changes/Python_3_as_Default
> [D] https://fedoraproject.org/wiki/Changes/Python_3_as_Default#Scope


-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: initscripts

[Dan Williams]

On Tue, 2015-01-27 at 22:20 -0500, Scott Schmit wrote:
> On Tue, Jan 27, 2015 at 02:18:31PM -0600, Dan Williams wrote:
> > NetworkManager is not intended only for mobile devices or notebooks,
> > because that's a small part of the networking story.  Plus, more than
> > just notebooks have needs for the things that NetworkManager brings to
> > the table.
> > 
> > If it's useful for you, that's great.  If you do not find it useful,
> > that's also fine, and it can be masked.  However, we have put great
> > effort into NM so that even if it *is* enabled, it can coexist
> > peacefully with whatever you do on the system outside of NM, and we are
> > constantly improving this.
> > 
> > We hope that NM can be installed on most systems, and will be there when
> > required and useful, but will get out of the way when not required.
> 
> What's the story for NM in router configurations?
> 
> The last time I brought up handling DHCPv6-PD (a strong non-laptop use
> case for NM if I ever saw one), I was told that router configurations
> were out of scope for NM (at least, at that point in time).
> 
> Has that changed? (Or maybe I'm misremembering some nuance...)

Yeah, that would have changed over the past few years.  PD is definitely
something that NM will be able to do in the future.

Dan


-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: initscripts

[Dan Williams]

On Tue, 2015-01-27 at 14:50 -0500, Nico Kadel-Garcia wrote:
> On Sun, Jan 25, 2015 at 12:40 PM, Adam Williamson
>  wrote:
> > On Sun, 2015-01-25 at 08:49 -0500, Nico Kadel-Garcia wrote:
> >
> >> * KVM bridge configuration
> >
> > Works fine in F21+, I'm using NM on both my main desktop/test box and
> > my server VM host.
> 
> Testing now on a VM, with the Fedora 21 Workstation. Getting the gui's
> to work after installation with the "Server" installation ISO than I
> could spend, even after I brought in enough debris to get a GUI
> screen.
> 
> I'll also point out that with either installation, it's unusably slow,
> it's unusably slow as a VM on a 2 GHz server with a pretty good ATI
> video card and 2 Gig of RAM allocated, so that makes testing awkward
> for me. I can switch window managers to something remotely sane, but
> then I lose the complex integration that makes the NetworkManager
> configuration utilities available.

I'd also point out that there are three different NetworkManager GUIs,
and one TUI:

1) GNOME Shell network settings - not really targeted for server
environments, has a smaller set of options that are suitable for
desktop/workstation use-cases

2) nm-connection-editor - presents a larger set of options than #1, and
only modifies *saved configuration*, not runtime configuration.  eg, it
is basically a much more capable system-config-network but without the
"up/down" buttons

3) KDE's network configuration dialogs

4) nmtui - a slightly simpler version of nm-connection-editor intended
for GUI-less environments, like a more capable system-config-network-tui

#2 and #4 obviously run much better in desktop environments like LXDE,
XFCE, etc where the full GNOME stack is not available.

It's important to note which one you're talking about when suggesting
improvements, since they are developed by different projects and each
one has a different target audience.  That said, I understand it can be
confusing which one is for who and available where...

Dan

> The modern anaconda tools and NetworkManager do indeed have access to
> installation time configuration of tagged VLAN's and pair bonding,
> although the interface is quite poor. Please refer to Eric Raymond's
> old essay on "The Luxury of Ignorance" for guidelines on why it is so
> poor, the lack of display of "what am I going to change from the
> current status" is merely one of its many issues, and the lack of a
> usable 'Help' key is pretty serious.
> 
> Bridges for KVM are not supported. What is apparent is that
> NetworkManager supports 'DCB', data center bridging. That's a
> different technology. And that puts us right into one of the
> guidelines Eric added to his essay as a postscript:
> 
>  Are there settings you can do from the command line or
> hand-editing config files that cannot be done from the GUI? Are they
> documented anywhere? Does using the GUI erase these settings?
> 
> I have to admit that I remain pretty unhappy with NetworkManager. It's
> a complex GUI on top of the underlying actual iinit scrupts, it
> doesn't do a good job of exposing the available options and there's no
> usable 'help' interface. Altogether, I'm afraid I have to classify it
> as a "bad tool" and recommend strongly against it for producton use.
> It's also partly why I try to put 'NM_CONTROLLED=no' in every
> /etc/sysconfig/network for servers that I work with.


-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: initscripts

[Dan Williams]

On Tue, 2015-01-27 at 20:56 +0100, Reindl Harald wrote:
> 
> Am 27.01.2015 um 20:50 schrieb Nico Kadel-Garcia:
> > On Sun, Jan 25, 2015 at 12:40 PM, Adam Williamson
> >  wrote:
> >> On Sun, 2015-01-25 at 08:49 -0500, Nico Kadel-Garcia wrote:
> >>
> >>> * KVM bridge configuration
> >>
> >> Works fine in F21+, I'm using NM on both my main desktop/test box and
> >> my server VM host.
> >
> > Testing now on a VM, with the Fedora 21 Workstation. Getting the gui's
> > to work after installation with the "Server" installation ISO than I
> > could spend, even after I brought in enough debris to get a GUI
> > screen.
> >
> > I'll also point out that with either installation, it's unusably slow,
> > it's unusably slow as a VM on a 2 GHz server with a pretty good ATI
> > video card and 2 Gig of RAM allocated, so that makes testing awkward
> > for me. I can switch window managers to something remotely sane, but
> > then I lose the complex integration that makes the NetworkManager
> > configuration utilities available.
> >
> > The modern anaconda tools and NetworkManager do indeed have access to
> > installation time configuration of tagged VLAN's and pair bonding,
> > although the interface is quite poor. Please refer to Eric Raymond's
> > old essay on "The Luxury of Ignorance" for guidelines on why it is so
> > poor, the lack of display of "what am I going to change from the
> > current status" is merely one of its many issues, and the lack of a
> > usable 'Help' key is pretty serious.
> >
> > Bridges for KVM are not supported. What is apparent is that
> > NetworkManager supports 'DCB', data center bridging. That's a
> > different technology. And that puts us right into one of the
> > guidelines Eric added to his essay as a postscript:
> >
> >   Are there settings you can do from the command line or
> > hand-editing config files that cannot be done from the GUI? Are they
> > documented anywhere? Does using the GUI erase these settings?
> >
> > I have to admit that I remain pretty unhappy with NetworkManager. It's
> > a complex GUI on top of the underlying actual iinit scrupts, it
> > doesn't do a good job of exposing the available options and there's no
> > usable 'help' interface. Altogether, I'm afraid I have to classify it
> > as a "bad tool" and recommend strongly against it for producton use.
> > It's also partly why I try to put 'NM_CONTROLLED=no' in every
> > /etc/sysconfig/network for servers that I work with
> 
> signed!
> 
> and the main point is: there is no need to replace network.service on 
> *any* static configured machine and nobody with responsibility for 
> complex networks right in his mind is playing games if he is running a 
> magnitude of machines, all similar configured, all with differnt jobs 
> and a mix of Fedora/RHEL5,6,7
> 
> that won't change for many years
> 
> there is a usecase for NM, surely, but not for me and not for a lot of 
> other people working professional in serious setups and tend to 
> configure personal workstations left and right as much as possible ike 
> the production environment
> 
> frankly i have enough of "change for the sake of change" as well i won't 
> use notebooks or other "mobile devices" for serious tasks for the rest 
> of my life - period

NetworkManager is not intended only for mobile devices or notebooks,
because that's a small part of the networking story.  Plus, more than
just notebooks have needs for the things that NetworkManager brings to
the table.

If it's useful for you, that's great.  If you do not find it useful,
that's also fine, and it can be masked.  However, we have put great
effort into NM so that even if it *is* enabled, it can coexist
peacefully with whatever you do on the system outside of NM, and we are
constantly improving this.

We hope that NM can be installed on most systems, and will be there when
required and useful, but will get out of the way when not required.

Dan


-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: initscripts

[Dan Williams]

On Tue, 2015-01-27 at 14:50 -0500, Nico Kadel-Garcia wrote:
> On Sun, Jan 25, 2015 at 12:40 PM, Adam Williamson
>  wrote:
> > On Sun, 2015-01-25 at 08:49 -0500, Nico Kadel-Garcia wrote:
> >
> >> * KVM bridge configuration
> >
> > Works fine in F21+, I'm using NM on both my main desktop/test box and
> > my server VM host.
> 
> Testing now on a VM, with the Fedora 21 Workstation. Getting the gui's
> to work after installation with the "Server" installation ISO than I
> could spend, even after I brought in enough debris to get a GUI
> screen.
> 
> I'll also point out that with either installation, it's unusably slow,
> it's unusably slow as a VM on a 2 GHz server with a pretty good ATI
> video card and 2 Gig of RAM allocated, so that makes testing awkward
> for me. I can switch window managers to something remotely sane, but
> then I lose the complex integration that makes the NetworkManager
> configuration utilities available.
> 
> The modern anaconda tools and NetworkManager do indeed have access to
> installation time configuration of tagged VLAN's and pair bonding,
> although the interface is quite poor. Please refer to Eric Raymond's
> old essay on "The Luxury of Ignorance" for guidelines on why it is so
> poor, the lack of display of "what am I going to change from the
> current status" is merely one of its many issues, and the lack of a
> usable 'Help' key is pretty serious.

I'll assume you're talking about either anaconda or nm-connection-editor
here?  eg, the GUI tools?

> Bridges for KVM are not supported. What is apparent is that
> NetworkManager supports 'DCB', data center bridging. That's a
> different technology. And that puts us right into one of the
> guidelines Eric added to his essay as a postscript:

Not sure what you mean about bridges for KVM not being supported.  NM
can create bridges/bonds/vlans/teams/etc and assign slaves to any of
them, and also set up a NAT-ed configuration much like libvirt does for
a bridge.  Obviously there needs to be a way for the kvm/qemu instance
to figure out what interface to use for connecting the guest, but that's
somewhat out of scope for NetworkManager.  

>  Are there settings you can do from the command line or
> hand-editing config files that cannot be done from the GUI? Are they
> documented anywhere? Does using the GUI erase these settings?

Yes, there are things the GUI cannot do that nmcli and text files can
do.  The GUIs present in GNOME Shell and nm-connection-editor are not
intended to expose the full configuration possibilities of
NetworkManager, much like you don't expect a GUI to expose all the
options in apache or freeradius configuration.  For that, you can use
your favorite text editor along with 'man', or the built-in nmcli help.
We don't plan to significantly duplicate all the functionality of nmcli
or config files in nm-connection-editor, since that's not the target
audience of the tool.

Yes, there could be GUI online help for nm-connection-editor that
explains everything that it cannot do, but that misses the most of the
point of a general purpose GUI.  A more server-oriented GUI (like
Cockpit) could certainly expose more of the server-oriented
configuration options.

Note that nm-connection-editor has tooltips that give more information
about what most of the options are.  You may find these useful.

> I have to admit that I remain pretty unhappy with NetworkManager. It's
> a complex GUI on top of the underlying actual iinit scrupts, it
> doesn't do a good job of exposing the available options and there's no
> usable 'help' interface. Altogether, I'm afraid I have to classify it
> as a "bad tool" and recommend strongly against it for producton use.
> It's also partly why I try to put 'NM_CONTROLLED=no' in every
> /etc/sysconfig/network for servers that I work with.

nmcli (the command-line tool) has what I would consider very good
built-in help when modifying configuration.  eg, "nmcli con edit " and then "desc dcb.app-fcoe-flags" will give you a description of
what that is and what values are allowed.  Obviously it can always be
better.

There are also detailed manpages for nmcli, that refer you to
nmcli-examples(5), nm-settings(5), and others.

We're happy to take concrete suggestions on how to improve the
documentation, both in the manpages, GUI tooltips, nmcli interactive
help, etc.

Dan

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Split DNS broken again - test case?

[Dan Williams]

On Wed, 2015-01-14 at 14:29 -0600, Ian Pilcher wrote:
> https://bugzilla.redhat.com/show_bug.cgi?id=1161232
> 
> It seems like this is the 3rd or 4th time that this functionality has
> been broken, leaving anyone who needs to simultaneously connect to both
> VPN and other non-public (e.g. home network) resources up a creek.
> 
> Would this be worth of a test case?

It seems that the issue never actually got fixed, so it was always
broken.  Patches have been submitted upstream (to the bug linked from
rhbz#1161232) which will be backported to F21's 0.9.10 and submitted as
an update soon.

Dan

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: "Workstation" Product defaults to wide-open firewall

[Dan Williams]

On Tue, 2014-12-09 at 10:19 -0500, Bastien Nocera wrote:
> 
> - Original Message -
> > Hi,
> > 
> > > > I also thought that the whole points of having Zones etc, was so that
> > > > we could pick a different zone per network connection,
> > 
> > /me too.
> > 
> > > > so if I'm in the office or at home I can say use this zone, if I'm
> > > > at a coffee shop I can pick a different one etc.
> > > > 
> > > > Or was this consider too much UI for the normal user? Surely
> > > > OSX has something to copy from, since they seem to define what
> > > > a normal user expects.
> > > 
> > > OSX has a firewall integration that I would rank as "awful". It's not
> > > any better than what we had in Fedora 20 (blocking firewall and a tool
> > > to open up ports).
> > 
> > Have a look at Windows then.  Each time you hook a windows machine to a
> > new network it asks what network this is.  Used to be "public", "home",
> > "work".  Recently they simplified that and kicked the "home" / "work"
> > separation, so it's only public / non-public now.  With some explanation
> > along the lines of "use public for hotspots, use home for your private
> > network where you want share stuff".
> > 
> > Why we can't have something like this?  And if you don't want a popup
> > asking, have something in the NetworkManager applet menu, where people
> > can easily find the switch without having to search for it?  A "[x]
> > allow sharing" checkbox?  A firewall zone selector?
> > 
> > Side Note: For the latter we need to cleanup the zones though.  There
> >are *way* to many to choose from, and the names suck big
> >time.  WTF is a "Fedora$product" zone?  And wasn't that
> >discussed before on this list?  Why do we *still* have this
> >mess?
> 
> This isn't a side note, IMO. It was one of the major reasons why we chose
> not to expose users to the concept of zones. In addition to the names being
> obscure in firewalld (there's a bug filed about that), they also are obscure
> in Windows.
> 
> What configuration difference is there between home and work, and how do you
> explain them without going deeper into technical details? Are there cases
> where I want to share things in a work environment and not a home environment?
> 
> > IMO there is simply no way around asking the user.
> 
> Instead of asking the user, we're getting the user to tell us they want to 
> share
> things. This avoids unnecessary nagging.
> 
> >  Make sharing stuff
> > easy (so you can watch your dnla-exported photo/video collection at your
> > smart tv) is a reasonable request.  But enabling that by allowing
> > everybody fetch your private photo collection via dnla while you are
> > surfing @ starbucks is a non-starter.
> 
> This isn't what was implemented. DLNA share will be turned off by default on
> new networks. In fact, we won't allow any unencrypted services to run when
> on unencrypted Wi-Fi.
> 
> > cheers,
> >   Gerd
> > 
> > PS: Seems windows can even identify different wired networks.  I've
> > switched my router recently, and windows re-asked what network
> > I'm on.  Probably they remember the mac address of the default
> > gateway or something like that.
> 
> This will be implemented as soon as NetworkManager makes it easier for us
> to detect different wired connections. For now, all wired connections are 
> considered
> to be the same one, which could be a problem.

Just a reminder that wired detection is always best-effort, unless the
switch is using 802.1x (which few do outside of highly secure
enterprises).  It's trivial for somebody to spoof any mechanism for
wired network detection.

Dan

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Note: polkit daemon now optional (notably with NM)

[Dan Williams]

On Sat, 2014-11-08 at 16:09 -0500, Colin Walters wrote:
> I pushed: 
> http://pkgs.fedoraproject.org/cgit/polkit.git/commit/?id=1224d7b427a507339087e2f72c481b560c85149b
> Built as: http://koji.fedoraproject.org/koji/taskinfo?taskID=8072916
> 
> Which makes polkit optional if NM (or anything else that links to libpolkit) 
> is used.  This is a follow up to 
> http://cgit.freedesktop.org/NetworkManager/NetworkManager/commit/?id=53e244bef637c3e4004961651d4ed23eda7393b5
> 
> I suspect for most people this is a "duh, finally" thing.  Upgrades should 
> work fine (polkit gains a new dep on polkit-libs).   But do be aware that if 
> you *do* want it and you are constructing a system from scratch, you'll now 
> have to explicitly install "polkit".  I can't think offhand of any realistic 
> case that would break, but here's a heads up anyways.

Thanks!  We should change the rawhide NM package to depend only on
-libs, I'll put that on the todo list.

Dan

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: iccjpeg.h errors

[Dan Williams]

On Wed, 2014-11-05 at 18:57 +0100, Antonio Trande wrote:
> Hi Dan.
> 
> On 11/05/2014 06:44 PM, Dan Williams wrote:
> > On Wed, 2014-11-05 at 18:17 +0100, Antonio Trande wrote:
> >> Hi all.
> >>
> >> I don't know how to fix these errors during IceCat compilation. Lately I
> >> tried to adapt Fedora compilations flags but there is wrong something.
> >>
> >> Here the log:
> >> http://koji.fedoraproject.org/koji/getfile?taskID=8044663&name=build.log&offset=-4000
> > 
> > Where are JPP, JOCTET, and FAR defined?  Is that header included in the
> > file that is causing errors?
> > 
> > Dan
> > 
> 
> I suppose you need to read image/decoders/iccjpeg.h involved:
> http://ur1.ca/ipcjo

Can you get/post the jconfig.h and jmorecfg.h that's getting used?
Those are where the defines in question come from, and perhaps some
options in jconfig.h are different on this build than in past builds.

Dan

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: iccjpeg.h errors

[Dan Williams]

On Wed, 2014-11-05 at 18:17 +0100, Antonio Trande wrote:
> Hi all.
> 
> I don't know how to fix these errors during IceCat compilation. Lately I
> tried to adapt Fedora compilations flags but there is wrong something.
> 
> Here the log:
> http://koji.fedoraproject.org/koji/getfile?taskID=8044663&name=build.log&offset=-4000

Where are JPP, JOCTET, and FAR defined?  Is that header included in the
file that is causing errors?

Dan

> This is SPEC file that I'm using,
> https://sagitter.fedorapeople.org/Icecat/icecat.spec
> 
> -- 
> Antonio Trande
> 
> mailto: sagitter 'at' fedoraproject 'dot' org
> http://fedoraos.wordpress.com/
> https://fedoraproject.org/wiki/User:Sagitter
> GPG Key: 0x66E15D00
> Check on https://keys.fedoraproject.org/


-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: ModemManager & MBIM & QMI & USB_ModeSwitch

[Dan Williams]

On Tue, 2014-08-05 at 09:26 +0200, poma wrote:
> ModemManager
> http://freedesktop.org/wiki/Software/ModemManager
> - update to 1.3.0 git3dd6f93, almost ready for the new 1.4 release.
>   https://bugzilla.redhat.com/show_bug.cgi?id=1125426

I actually did a full stack rebuild yesterday for the latest upstream
release of libmbim and libqmi, and git master snapshot of ModemManager,
for both F21 and rawhide.  So we should be all good here.

For the QMI static vs. DHCP thing, lets follow up on the existing
upstream ModemManager-devel list thread.

Dan

> **
> 
> MBIM modem protocol helper library
> http://freedesktop.org/wiki/Software/libmbim
> - update to 1.11.0 git536bdae, this is literally the 1.10.0 release, however 
> let's move on.
>   https://bugzilla.redhat.com/show_bug.cgi?id=1125422
> 
> Overview of changes in libmbim 1.10
> 
> 
>  * API break: Flag values in 'MbimRegistrationFlag' were updated to match the
>ones in the MBIM documentation.
> 
>  * Implemented a new 'mbim-proxy', which allows sharing a single MBIM control
>port among different processes. The usage of the proxy is optional, and can
>be requested by specifying the MBIM_DEVICE_OPEN_FLAGS_PROXY flag in the new
>mbim_device_open_full() method. The 'mbimcli' command line tool was also
>extended with a new '--device-open-proxy,-p' option, to allow requesting 
> the
>use of the proxy process.
> 
>  * New 'removed' signal added to the MbimDevice, to notify when the underlying
>connection to the device is lost (e.g. lost connection to the mbim-proxy, 
> or
>lost access to the MBIM control port).
> 
>  * Added support for registering and using custom services.
> 
>  * Added additional GMM cause codes to MbimNwError.
> 
>  * Transactions are now matched not only by ID but also by type.
> 
>  * Several other minor improvements and fixes.
> 
> **
> 
> QMI modem protocol helper library
> http://freedesktop.org/wiki/Software/libqmi
> - update to 1.11.0 git852b5bf, this is the 1.10.0 release with some 
> additional repairs.
>   https://bugzilla.redhat.com/show_bug.cgi?id=1125424
> 
> Overview of changes in libqmi 1.10.0
> 
> 
> * Fixed default internal proxy timeout for requests.
> * Added initial support for the WDA service.
> * Added support for cell location info retrieval.
> * Added support for UIM card status retrieval.
> * Added support to specify net open flags in the command line.
> 
> **
> 
> USB_ModeSwitch - Handling Mode-Switching USB Devices on Linux
> http://www.draisberghof.de/usb_modeswitch
> - update to 2.2.0
>   https://bugzilla.redhat.com/show_bug.cgi?id=1126710
> 
> History of USB_ModeSwitch
> =
> 
> Version 2.2.0, 2014/05/29
> Introduction of parameter "HuaweiNewMode", wrapping the standard bulk
> message for all newer Huawei devices; support for generic fall-back
> config files, combined with OS switch (per vendor ID), implementation
> to use a specific switching command on Android for all Huawei devices
> (see README of data package for details); this change was suggested
> by Huawei
> 
> - update "data" to 20140529
>   https://bugzilla.redhat.com/show_bug.cgi?id=1126711
> 
> ChangeLog
> 
> 20140529:
> ATTENTION: requires usb-modeswitch version >= 2.2.0 due to new para-
> meter HuaweiNewMode (further reducing config file size);
> Added devices: Nexperia TM TD-SCDMA, Sunplus SU-3200U, Olivetti
> Olicard 160 and Olicard 500, Ericsson F5521gw, Sony Ericsson EC400,
> Huawei EC168, Huawei/Vod. W5101 Router, Huawei E3531, Huawei E3131
> (Variant), Novatel MiFi 4082, Emobile D12LC, Emobile D21LC, Prolink
> PCM100, Titan 3.5G, several nameless ZTE modems, several minor device
> configuration corrections (thanks once again to Lars Melin for the
> tedious device research and compilation!);
> Substantial change in handling of Huawei devices - generic udev rule and
> additional generic configuration files (as fallback for unknown models
> or as OS-specific catch-all); see README for details
> 
> 
> Soon in theaters.
> 
> 
> poma
> 


-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: [RFE/ENH] A network bandwidth monitor plugin for NetworkManager

[Dan Williams]

On Tue, 2014-06-24 at 08:57 +0200, poma wrote:
> We’ll Build A Dream House Of Net - by Dan Williams
> http://blogs.gnome.org/dcbw/2014/06/20/well-build-a-dream-house-of-net/
> 
>   Geez, are we done yet?
>   
>   Not even close!  Seriously, there’s more but I’m kinda tired of 
> typing.
>   Try it out (the final release will be out later this week) and tell 
> us what you think.
>   *Then tell us what you want*.  Don’t be afraid to dream a little 
> bigger, darling!
> 
> Darlingly please take into consideration, if possible. :)
> 
> RFE/ENH - NetworkManager
> A network bandwidth monitor plugin for NetworkManager - "NetworkManager-nbm",
> aka "NetworkManager-kmp(keep my pants)".
> 
> Ref. reps:
> 
> - [enh] enable bandwidth usage monitoring
> 2009-07-17
> https://bugzilla.gnome.org/show_bug.cgi?id=588870
> 
> - Support for transfered data amount per configured connection quota
> 2009-11-30
> https://bugzilla.gnome.org/show_bug.cgi?id=603372
> 
> - RFE to provide periodic network traffic statistics and warnings by 
> connection
> 2010-03-09
> https://bugzilla.redhat.com/show_bug.cgi?id=571774
> 
> - RFE: add attribute "limited data" to connection and expose it via API/DBUS
> 2014-06-23
> https://bugzilla.redhat.com/show_bug.cgi?id=1112230
> 
> 
> Very well described by Darius Mažeika [reporter]:
> 
>   It would be very nice to have support for transfered data amount 
> quota/limit in
>   NetworkManager.
>   
>   1. Counter per configured connection, persisting between computer 
> restart,
>   suspend, shutdown, interface activation and deactivation.
>   
>   2. Interface to specify quota. When quota is soon to be reached 
> (let's say,
>   95%), an optional notification could be shown (an icon in traybar, 
> maybe?).
>   When limit is reached, NM should optionally automatically 
> disconnect the
>   connection and show a message
>   
>   3. Interface to view collected data and set/reset counters.
>   
>   It is possible to extend this wish list, but these functions would 
> cover most
>   roaming user's with limited network connection needs.

Thanks for the consolidated overview!  Definitely useful, and would
actually be pretty straightforward if anyone wanted to tackle it;
volunteers? :)

Dan

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: DNF: why does it refresh metadata all the time

[Dan Williams]

On Fri, 2014-06-20 at 23:27 +0200, poma wrote:
> On 20.06.2014 17:55, Dan Williams wrote:
> > On Fri, 2014-06-20 at 08:55 +0200, drago01 wrote:
> >> On Thu, Jun 19, 2014 at 8:59 PM, Jared K. Smith
> >>  wrote:
> >>> On Thu, Jun 19, 2014 at 2:01 PM, Reindl Harald 
> >>> wrote:
> >>>>
> >>>> if *that* is what is supposed to make DNF faster it's just a lie
> >>>
> >>>
> >>> This is not the only thing that DNF does differently to try to make 
> >>> package
> >>> installations and updates go faster (or appear to go faster).  Calling the
> >>> developers liers doesn't help the situation any.
> >>>
> >>>>
> >>>> if i am really interested in updates now i do "yum clean metadata && yum
> >>>> upgrade"
> >>>> for many years simply because you don't know how accurat you metadata are
> >>>
> >>>
> >>> Sure, but you have to understand -- you're a power user.  You know enough 
> >>> to
> >>> do this in yum for your particular use case, which means you probably know
> >>> enough to change the DNF settings with regards to cron-based metadata
> >>> retrieval.  What I think you're missing (and frankly, seem to miss in the
> >>> lot of fedora-devel discussions you take part in) is that Fedora isn't
> >>> engineered around *your* particular needs.  We do things mostly by
> >>> consensus, and aim to make it a pleasant experience for the *average* user
> >>> (or whatever we have in the Fedora community that approximates an average
> >>> user), and not just for power users with very specific needs and
> >>> requirements.
> >>>
> >>> Whether you like it or not, one of the most common complaints about yum
> >>> (especially from people coming from another package management system) is
> >>> that it seems slow because of the necessity to download the metadata.  The
> >>> DNF developers -- in trying to address this common complaint -- had solved
> >>> it by handling metadata in a different way.  They've also added settings 
> >>> so
> >>> that power users like you and I can tune it to better fit our particular
> >>> needs.
> >>>
> >>>>
> >>>>
> >>>> and *no* traffic is not cheap everywhere, by far not
> >>>
> >>>
> >>> I probably understand this better than a lot of people on this list, as 
> >>> I've
> >>> been on a bandwidth-limited connection for the past nine years.  Only in 
> >>> the
> >>> past month have I been able to get high speed internet in my home that
> >>> wasn't limited to a few gigabytes per month.  So yes, I completely
> >>> understand that traffic isn't cheap (or fast) everywhere.
> >>
> >> It should be at least smart enough to not do it on mobile broadband
> >> (like packagekit does).
> >
> > Python + D-Bus example for detecting WWAN NetworkManager 0.9+ is here:
> >
> > http://cgit.freedesktop.org/NetworkManager/NetworkManager/tree/examples/python/dbus/is-wwan-default.py
> >
> > Dan
> >
> >
> 
> This is super duper, however if wwan is on the router as Ranhald wrote, you 
> can only click your heels three times and repeat, "There's no place like 
> home."

Certainly.  But that doesn't mean we shouldn't try to fix 50%, even if
we can't achieve the stars.  So I think there's a ton of value in doing
this despite the fact that we can't be perfect.

Dan

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: DNF: why does it refresh metadata all the time

[Dan Williams]

On Fri, 2014-06-20 at 08:55 +0200, drago01 wrote:
> On Thu, Jun 19, 2014 at 8:59 PM, Jared K. Smith
>  wrote:
> > On Thu, Jun 19, 2014 at 2:01 PM, Reindl Harald 
> > wrote:
> >>
> >> if *that* is what is supposed to make DNF faster it's just a lie
> >
> >
> > This is not the only thing that DNF does differently to try to make package
> > installations and updates go faster (or appear to go faster).  Calling the
> > developers liers doesn't help the situation any.
> >
> >>
> >> if i am really interested in updates now i do "yum clean metadata && yum
> >> upgrade"
> >> for many years simply because you don't know how accurat you metadata are
> >
> >
> > Sure, but you have to understand -- you're a power user.  You know enough to
> > do this in yum for your particular use case, which means you probably know
> > enough to change the DNF settings with regards to cron-based metadata
> > retrieval.  What I think you're missing (and frankly, seem to miss in the
> > lot of fedora-devel discussions you take part in) is that Fedora isn't
> > engineered around *your* particular needs.  We do things mostly by
> > consensus, and aim to make it a pleasant experience for the *average* user
> > (or whatever we have in the Fedora community that approximates an average
> > user), and not just for power users with very specific needs and
> > requirements.
> >
> > Whether you like it or not, one of the most common complaints about yum
> > (especially from people coming from another package management system) is
> > that it seems slow because of the necessity to download the metadata.  The
> > DNF developers -- in trying to address this common complaint -- had solved
> > it by handling metadata in a different way.  They've also added settings so
> > that power users like you and I can tune it to better fit our particular
> > needs.
> >
> >>
> >>
> >> and *no* traffic is not cheap everywhere, by far not
> >
> >
> > I probably understand this better than a lot of people on this list, as I've
> > been on a bandwidth-limited connection for the past nine years.  Only in the
> > past month have I been able to get high speed internet in my home that
> > wasn't limited to a few gigabytes per month.  So yes, I completely
> > understand that traffic isn't cheap (or fast) everywhere.
> 
> It should be at least smart enough to not do it on mobile broadband
> (like packagekit does).

Python + D-Bus example for detecting WWAN NetworkManager 0.9+ is here:

http://cgit.freedesktop.org/NetworkManager/NetworkManager/tree/examples/python/dbus/is-wwan-default.py

Dan


-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: NetworkManager-0.9.95 update in rawhide

[Dan Williams]

On Wed, 2014-06-11 at 12:00 +0400, Igor Gnatenko wrote:
> On Tue, Jun 10, 2014 at 11:19 PM, Dan Williams  wrote:
> > On Tue, 2014-06-10 at 21:37 +0400, Igor Gnatenko wrote:
> >> On Tue, Jun 10, 2014 at 9:34 PM, Thomas Haller  wrote:
> >> > On Tue, 2014-06-10 at 21:25 +0400, Igor Gnatenko wrote:
> >> >> Hi,
> >> >>
> >> >> After latest update i can't use my wifi in NM. Probably this bug not
> >> >> in NM, but I don't know how to debug this :(
> >> >
> >> > Do you have the package NetworkManager-wifi installed?
> >> no. Interesting.
> >> >
> >> > Check with
> >> > $ yum list NetworkManager-wifi
> >> >
> >> >
> >> > and you certainly need it. Actually, you should have gotten it
> >> > automatically...
> >> What's happens? Checking dnf logs.
> >
> > As Igor and I discussed on IRC, the new NetworkManager package and
> > sub-packages include "Obsoletes: NetworkManager < 1:0.9.9.95-1" which
> > should cause *all* the subpackages (including NetworkManager-wifi) to
> > replace the previous packages, and thus NM-wifi should be installed.
> > We're checking with dnf people to figure out why this doesn't seem to be
> > the case.  I tested with 'yum' and a local repo before building the F21
> > update and this worked correctly, so at the moment the issue seems to be
> > with dnf.
> https://bugzilla.redhat.com/show_bug.cgi?id=1107973

No response yet about what the expected procedure for package splitting
is with DNF, since it obviously does it differently than yum.  I think
before we switch over to DNF, we should solve this question.  Either:

1) DNF should use the same algorithm for obsoletes as yum did, so that
package splitting works the same way as yum

2) Somebody should update the packaging guidelines to explain exactly
how DNF expects package splitting to work, and then I'll update the NM
RPMS to use this method

Dan

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: NetworkManager-0.9.95 update in rawhide

[Dan Williams]

On Tue, 2014-06-10 at 21:37 +0400, Igor Gnatenko wrote:
> On Tue, Jun 10, 2014 at 9:34 PM, Thomas Haller  wrote:
> > On Tue, 2014-06-10 at 21:25 +0400, Igor Gnatenko wrote:
> >> Hi,
> >>
> >> After latest update i can't use my wifi in NM. Probably this bug not
> >> in NM, but I don't know how to debug this :(
> >
> > Do you have the package NetworkManager-wifi installed?
> no. Interesting.
> >
> > Check with
> > $ yum list NetworkManager-wifi
> >
> >
> > and you certainly need it. Actually, you should have gotten it
> > automatically...
> What's happens? Checking dnf logs.

As Igor and I discussed on IRC, the new NetworkManager package and
sub-packages include "Obsoletes: NetworkManager < 1:0.9.9.95-1" which
should cause *all* the subpackages (including NetworkManager-wifi) to
replace the previous packages, and thus NM-wifi should be installed.
We're checking with dnf people to figure out why this doesn't seem to be
the case.  I tested with 'yum' and a local repo before building the F21
update and this worked correctly, so at the moment the issue seems to be
with dnf.

Dan

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Don't use at_console in DBus policy files

[Dan Williams]

On Tue, 2014-05-06 at 14:36 +0100, Richard W.M. Jones wrote:
> On Fedora 20, I'm seeing this list:
> 
> /etc/dbus-1/system.d/nm-ifcfg-rh.conf: 
> NetworkManager-1:0.9.9.0-38.git20131003.fc20.x86_64
> /etc/dbus-1/system.d/nm-user-settings.conf: sugar-0:0.100.2-1.fc20.noarch
> /etc/dbus-1/system.d/org.freedesktop.NetworkManager.conf: 
> NetworkManager-1:0.9.9.0-38.git20131003.fc20.x86_64

The NetworkManager at_console removal is in F21+ as of NM 0.9.9.1 and
later, so this would be expected on F20.

Dan

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: F21 System Wide Change: Default Local DNS Resolver

[Dan Williams]

On Wed, 2014-04-30 at 16:12 -0400, Chuck Anderson wrote:
> On Wed, Apr 30, 2014 at 01:06:51PM -0700, Andrew Lutomirski wrote:
> > On Wed, Apr 30, 2014 at 1:02 PM, Dan Williams  wrote:
> > > On Wed, 2014-04-30 at 15:36 -0400, Paul Wouters wrote:
> > >> On Wed, 30 Apr 2014, Simo Sorce wrote:
> > >>
> > >> > Why would you care for the domain name as provided by dhcp ?
> > >>
> > >> internal DNS views, eg server.internal.corp.com where the search domain
> > >> gets set to "internal.corp.com" and "server.corp.com" does not exist.
> > >>
> > >> > By default you wouldn't want that as you roam with a fedora laptop on
> > >> > completely untrusted dhcp networks that can push whatever crap as a
> > >> > search path.
> > >>
> > >> Yes, which is why we tentatively came to the conclusion the best
> > >> compromise for this is "if the user authorizes to connect to this
> > >> network, allow it". Eg using physical cable or WPA secrets.
> > >
> > > Note that with NetworkManager, no WiFi connection is ever made (even
> > > open) without the user explicitly requesting it.  If you have the
> > > NetworkManager-config-server RPM installed, then no ethernet connection
> > > is ever made without the user explicitly configuring it.  So I'm not
> > > sure the description quite fits...
> > 
> > Except for that network called "linksys" that everyone has requested
> > at some point.
> 
> If I once connected to an open network called "MyFavoriteCoffeeShop"
> then later on someone creates a network with the same name but with
> malicous intent, will NetworkManager connect to it automatically?

If it uses the same SSID and compatible security settings, then yes.
That's the nature of 802.11.  However, if the malicious user doesn't
know the password that you have saved on your machine, or the network's
CA certificate does not validate, then the attempt will fail.

Furthermore, if the user creates a network of a different type (eg,
Ad-Hoc but yours is infrastructure), NM will not attempt to connect to
it.

Yes, there are ways to game the system, so you are correct that there
are some cases where NetworkManager could automatically attempt to
connect to a malicious network that mimics a known network, the same as
with most other OSs and phones.

Dan

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: F21 System Wide Change: Default Local DNS Resolver

[Dan Williams]

On Wed, 2014-04-30 at 15:36 -0400, Paul Wouters wrote:
> On Wed, 30 Apr 2014, Simo Sorce wrote:
> 
> > Why would you care for the domain name as provided by dhcp ?
> 
> internal DNS views, eg server.internal.corp.com where the search domain
> gets set to "internal.corp.com" and "server.corp.com" does not exist.
> 
> > By default you wouldn't want that as you roam with a fedora laptop on
> > completely untrusted dhcp networks that can push whatever crap as a
> > search path.
> 
> Yes, which is why we tentatively came to the conclusion the best
> compromise for this is "if the user authorizes to connect to this
> network, allow it". Eg using physical cable or WPA secrets.

Note that with NetworkManager, no WiFi connection is ever made (even
open) without the user explicitly requesting it.  If you have the
NetworkManager-config-server RPM installed, then no ethernet connection
is ever made without the user explicitly configuring it.  So I'm not
sure the description quite fits...

Dan

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: F21 System Wide Change: Default Local DNS Resolver

[Dan Williams]

On Wed, 2014-04-30 at 13:22 -0400, Paul Wouters wrote:
> On Wed, 30 Apr 2014, Robert Marcano wrote:
> 
> > What about domain and search lines? If NetworkManager will always use 
> > 127.0.0.1, it should still modify resolv.conf with the domain name received 
> > from DHCP
> 
> That's actually not always correct from a security point of view.
> 
> If you set your system do have domain "nohats.ca", and you "ssh bofh"
> and then some DHCP changes the domain/search list, you might not be
> going where you think you are going.
> 
> IMHO, DHCP should never touch the domain or search list _unless_ you are
> connecting to a trusted network - where trusted for practical reasons is
> defined as "you plug in a wire or use a wifi WPA secret to connect".

Untrusted networks use WPA too, like coffee shops that don't leave the
network open, but write the WPA key on the chalkboard menu or print it
on standup cards at the tables.  I've seen quite a few of these.

There's really no guessing what's trusted/not-trusted unless you're
using 802.1x/WPA Enterprise, or if the user has told you explicitly to
trust this network.

Dan

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: F21 System Wide Change: Default Local DNS Resolver

[Dan Williams]

On Tue, 2014-04-29 at 22:10 +0800, P J P wrote:
>Hello,
> 
> On Tuesday, 29 April 2014 7:22 PM, Miloslav Trmač wrote:
> >So what exactly happens on upgrade?  Before the upgrade,
> >most resolv.conf files will not point to 127.0.0.1.
> >What will they point to after the upgrade, and if they will point to 
> >127.0.0.1,
> >which package will actually do that, and what will happen with the old 
> >contents
> >of the file? For example, is it assumed that ifcfg-* are always authoritative
> >and it's safe to just overwrite resolv.conf?
> 
>After upgrade, the default DNS resolver should listen on 127.0.0.1:53. And 
> the entry will be added to '/etc/resolv.conf' by NetworkManager. The old 
> contents of the file should be passed on to the local resolver as transitory 
> name servers. The actual workflow is currently being worked upon.

If NetworkManager is used, an upgrade would simply involve dropping a
config file into /etc/NetworkManager/conf.d that specifies the
"dns=[plugin]" option.  Then, either NM rewrites resolv.conf to
127.0.0.1 (if an NM DNS plugin is used), or NM stops touching
resolv.conf entirely (dns=none) and something else handles resolv.conf.
In both cases, NetworkManager gets the DNS information from the same
places it already does, and passes it along to the caching nameserver
automatically.

If NetworkManager is not being used on the system, then yes, there are
some additional questions which the proposal needs to answer.

> >Similarly, what do we tell users who used to edit /etc/resolv.conf to do in 
> >the new system?
> 
> 
>   We tell users to never edit the '/etc/resolv.conf' file and ensure that the 
> local resolver is listening at 127.0.0.1:53.

If NetworkManager is being used, users already don't touch resolv.conf,
they edit /etc/sysconfig/network-scripts/ifcfg-* files and use
DNS1/DNS2/DNS3 and SEARCHES to set DNS information.

If NetworkManager is not being used, then the proposal needs to address
what config file users *do* edit to ensure that the upstream DNS servers
are pushed to the caching nameserver.

Dan

> >Generally, the page doesn't actually say which resolver will be used.  Has 
> >that been decided?  Or is that intentionally undefined?
> 
>   The choice of the default resolver is not yet done. From the discussion so 
> far unbound(https://unbound.net/) appears to be the strong contender.
> 
> ---
> Regards
>-Prasad
> http://feedmug.com
> 


-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: default local DNS failover solution needed, nscd?

[Dan Williams]

On Mon, 2014-04-28 at 10:14 -0400, Paul Wouters wrote:
> On Mon, 28 Apr 2014, Marcelo Ricardo Leitner wrote:
> 
> > Speaking of which, I am not sure how dnsmasq plays with DNSSEC and/or 
> > failover, but NetworkManager already has a config option 
> > (/etc/NetworkManager/NetworkManager.conf, dns=dnsmasq) that makes it 
> > configure a local dnsmasq instance on 127.0.0.1 for handling DNS requests. 
> > The dnsmasq then is the one who will go after the real servers & all..
> >
> > Isn't making this the default way enough perhaps?
> 
> No, that is missing all the features for hotspot signon and VPN
> integration.

NM already has connectivity checking like dnssec-trigger, which we use
for hotspot detection and twiddle some D-Bus API flags to indicate that
you might be behind a hotspot.  GNOME Shell displays a "hotspot" status
in this case.  NM will also do split DNS with dnsmasq as a local caching
nameserver to handle the VPN stuff, if your VPN passes down domains or
you specify them manually.

What that doesn't have is the DNSSEC support or the ability to start a
sandboxed web browser for hotspot login before making the upstream
nameservers system-wide, which is where dnssec-trigger and unbound would
come in.

Dan

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: default local DNS caching name server

[Dan Williams]

On Mon, 2014-04-14 at 12:00 -0400, Paul Wouters wrote:
> On Mon, 14 Apr 2014, Dan Williams wrote:
> 
> > But another scenario I've seen:  older Netgear routers which intercept
> > "www.routerlogin.net" as the setup page.  The instructions literally
> > are:
> >
> > 1) connect your computer to the router with a cable
> > 2) go to www.routerlogin.net
> > 3) follow the setup guide instructions
> >
> > Any idea how dnssec-trigger + unbound would handle this?  Since it's
> > router setup, maybe spawning the whole new window for the "portal" would
> > work, but you'd want to make sure the window didn't go away or DNS
> > didn't change until the user was done setting up the router.
> 
> I don't know what they do when you query for anything else. If there is
> no hotspot redirection on port 80/443 and their DNS server works
> properly, and your wifi was secure, you would then get their forward
> and the above would work. If it is an open wifi, we would not install

Since the user is setting things up, they can pick whether it's open or
protected wifi.  We don't control that.

> the forward and you would not get there. but in the current setup, you
> can pick "hotspot login" mode and it puts their DNS in place, and than
> you will reach it. Note that manual hotspot login sessions require you

Ok, that could be a problem.  This is a user setting up wifi on a router
they just bought, so it has no upstream connection yet, is not yet
configured at all, and they are just following the directions in the
printed brochure they got with the router.  Which obviously won't say
anything about "hotspot login" mode.

Also, this is the procedure you follow if you reset the router to
factory defaults, which support people sometimes tell you to do.  So
we'd run into the issue if/when the user contacted Netgear technical
support too.

Dan

> to manually mark them for "reprobe" as well because apparently we cannot
> probe for it because you manually overrode it. If you switch networks,
> and bring up the VPN, you'll encounter weird things. While still in
> hotspot mode, the VPN forward put into unbound is not active because you
> are not using unbound yet (until you hit reprobe to leave "hotspot
> signon" mode.
> 
> Paul


-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: default local DNS caching name server

[Dan Williams]

On Mon, 2014-04-14 at 10:21 -0400, Paul Wouters wrote:
> > Or how would you suggest this is solved. For arguments sake lets
> > say:
> >
> > SSID: myawesomeopenhotspot
> > DHCP provides no domain-name info.
> > I CNAME all records to my.hotspot. until authenticated.
> 
> If this does not do http(s) redirection, than it is a very very broken
> setup. You would also need to block port 53 to prevent people using
> 8.8.8.8 to bypass your authentication. So I do not see this in the wild
> (and I've done the hard work of sitting in many coffee shops for
> science). hotspots tend to intercept port 80 to a mini web server that
> only serves a redirect, sometimes without any DNS name, often with a DNS
> name only resolvable by using their DNS. And that is fully supported by
> the current solution.

Many of the captive portals I've seen block all access to anything
except the portal login.  You don't get to ping anything, you don't get
to DNS anything (let alone 8.8.8.8) and you certainly don't get to send
traffic outside the portal.  Only when you've authenticated does it
release you.  Sometimes that's done with VLANs and DHCP renewal,
sometimes it's done internally with firewall rules or something.

But another scenario I've seen:  older Netgear routers which intercept
"www.routerlogin.net" as the setup page.  The instructions literally
are:

1) connect your computer to the router with a cable
2) go to www.routerlogin.net
3) follow the setup guide instructions

Any idea how dnssec-trigger + unbound would handle this?  Since it's
router setup, maybe spawning the whole new window for the "portal" would
work, but you'd want to make sure the window didn't go away or DNS
didn't change until the user was done setting up the router.

Dan

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: default local DNS caching name server

[Dan Williams]

On Fri, 2014-04-11 at 14:45 -0600, Kevin Fenzi wrote:
> On Fri, 11 Apr 2014 16:39:34 -0400 (EDT)
> Paul Wouters  wrote:
> 
> ...snip...
> 
> > I've been running this solution on fedora for about five years now. It
> > works reasonably well, and anyone who is on this list surely has could
> > try it out. Because of lack of NM integration I would not call it
> > enduser ready yet.
> 
> Me too. :)
> 
> I hope the NM integration will show up at some point. It's really a
> pretty nice setup. 

It's getting worked on, slowly but surely.  And since DNSSEC has been
getting more interest, we've been having a lot more discussions about
how NetworkManager can better serve dnssec-trigger and other DNS
consumers like it.

Dan

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: default local DNS caching name server

[Dan Williams]

On Sat, 2014-04-12 at 03:35 +0800, P J P wrote:
>Hello Dan,
> 
> > On Saturday, 12 April 2014 12:51 AM, Dan Williams wrote:
> > NM has had local caching nameserver capability built-in since Fedora 12
> > or something like that.  Set 'dns=dnsmasq' in the [main] section
> > of /etc/NetworkManager/NetworkManager.conf and NM will spawn dnsmasq in
> > a local caching nameserver configuration and write 127.0.0.1 to
> > resolv.conf.  NM will update that dnsmasq instance whenever your network
> > configuration chagnes to ensure that dnsmasq has the latest nameservers.
> > 
> > It seems that 'unbound' is getting more love these days though, due to
> > it's DNSSEC capabilities, and there is not yet a NetworkManager DNS
> > plugin for unbound/dnssec-trigger.  I know some people are working on
> > that though (Thomas Hozza and Pavel Simerda) and I'd expect that to show
> > up in the near future.
> > 
> > Note that hotspot detection is an important part of this, since hotspots
> > will clearly break any kind of DNSSEC validation that happens, and
> > that's something that's being worked out between dnssec-trigger and
> > NetworkManager right now too.
> >
> > NM in F20+ already has a "dns=none" option that prevents NM from
> > touching resolv.conf, but obviously if NM isn't touching it, the DNS
> > information that NM gets from upstream or your local configuration needs
> > to get to the local caching nameserver somehow.  Which is what the
> > existing NM DNS plugins are for, like the dnsmasq one. 
> 
>   That's great. Thank you so much for sharing this information. I'll add it 
> to the wiki page.
> 
> About the wifi hotspots breakage, I'm still not in the clear. IIUC how they 
> work is, all client traffic is blocked/redirected to a designated server till 
> the time user authenticates/makes payment/accepts conditions etc. This 
> blockage/redirection is probably done on the the gateway or some such 
> entry/exit point, no?

They almost always run DNS interceptors, so that the DHCP server on the
captive side always returns the portal's login page for any request,
even "www.google.com" or "www.fedoraproject.org" will redirect you to
the login page.  Obviously that DNS reply will not be authenticated or
secure in any way, because it clearly cannot be a trusted reply from
google.com.  Thus they will break any kind of DNSSEC or any other kind
of authentication that the local caching DNS server might do.

I think the big issue for me is the use of "trusted" in the proposal.
What does that actually mean?  Who is doing the trusting?  Does it mean
that Firefox can "trust" the local caching DNS server, and if so, why
would that server be any more "trustworthy" than the upstream nameserver
delivered to you by DHCP?  If that local nameserver *is* somehow more
trustworthy, what specifically does it do to deserve that trust?  If it
does do something, does that something break hotspot or portal detection
and login?

Dan

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: default local DNS caching name server

[Dan Williams]

On Fri, 2014-04-11 at 14:21 -0500, Dan Williams wrote:
> On Sat, 2014-04-12 at 02:33 +0800, P J P wrote:
> >   Hello,
> > 
> > > On Thursday, 10 April 2014 11:39 PM, P J P wrote:
> > > I plan to file a feature/change request for this one. I got caught up 
> > > with other 
> > > work this past week so could not do it. Will start with it right away. 
> > 
> >   Please see -> 
> > https://fedoraproject.org/wiki/Changes/Default_Local_DNS_Resolver
> > 
> > It's a System Wide Change Proposal request up for review. 
> > 
> > I have set the target release as F22, because the proposal deadline for F21 
> > was 08 Apr 2014 [1]. Besides, this change would require significant work on 
> > the related packages like NetworkManager etc. So F22 seems safer.
> > 
> > In case if you spot any discrepancies or have additional inputs or links to 
> > relevant documents etc. please feel free to update the wiki page or let me 
> > know and I'll add it there.
> 
> NM has had local caching nameserver capability built-in since Fedora 12
> or something like that.  Set 'dns=dnsmasq' in the [main] section
> of /etc/NetworkManager/NetworkManager.conf and NM will spawn dnsmasq in
> a local caching nameserver configuration and write 127.0.0.1 to
> resolv.conf.  NM will update that dnsmasq instance whenever your network
> configuration chagnes to ensure that dnsmasq has the latest nameservers.
> 
> It seems that 'unbound' is getting more love these days though, due to
> it's DNSSEC capabilities, and there is not yet a NetworkManager DNS
> plugin for unbound/dnssec-trigger.  I know some people are working on
> that though (Thomas Hozza and Pavel Simerda) and I'd expect that to show
> up in the near future.
> 
> Note that hotspot detection is an important part of this, since hotspots
> will clearly break any kind of DNSSEC validation that happens, and
> that's something that's being worked out between dnssec-trigger and
> NetworkManager right now too.
> 
> NM in F20+ already has a "dns=none" option that prevents NM from
> touching resolv.conf, but obviously if NM isn't touching it, the DNS
> information that NM gets from upstream or your local configuration needs
> to get to the local caching nameserver somehow.  Which is what the
> existing NM DNS plugins are for, like the dnsmasq one.

" Add domain specific name server entries into local name server's
configuration file and ensure that applications are able to resolve
internal(company wide) domain names too. (try connecting to company
mail/IRC server)"

We want to make sure that any local caching nameserver that we do use
doesn't rely exclusively on file-based configuration, or if it does,
it's able to re-read that configuration file using SIGHUP or some
seamless reload functionality.  It *must* also be able to load new
configuration without dropping in-process DNS queries on the floor,
otherwise users will experience hung DNS a non-trivial amount of the
time.

The better way is to add/remove zones + servers from dnsmasq over D-Bus,
which NM does not yet do since the patches are not yet upstream, or to
use some other socket-based protocol like unbound does with
dnssec-trigger.

Dan

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: default local DNS caching name server

[Dan Williams]

On Sat, 2014-04-12 at 02:33 +0800, P J P wrote:
>   Hello,
> 
> > On Thursday, 10 April 2014 11:39 PM, P J P wrote:
> > I plan to file a feature/change request for this one. I got caught up with 
> > other 
> > work this past week so could not do it. Will start with it right away. 
> 
>   Please see -> 
> https://fedoraproject.org/wiki/Changes/Default_Local_DNS_Resolver
> 
> It's a System Wide Change Proposal request up for review. 
> 
> I have set the target release as F22, because the proposal deadline for F21 
> was 08 Apr 2014 [1]. Besides, this change would require significant work on 
> the related packages like NetworkManager etc. So F22 seems safer.
> 
> In case if you spot any discrepancies or have additional inputs or links to 
> relevant documents etc. please feel free to update the wiki page or let me 
> know and I'll add it there.

NM has had local caching nameserver capability built-in since Fedora 12
or something like that.  Set 'dns=dnsmasq' in the [main] section
of /etc/NetworkManager/NetworkManager.conf and NM will spawn dnsmasq in
a local caching nameserver configuration and write 127.0.0.1 to
resolv.conf.  NM will update that dnsmasq instance whenever your network
configuration chagnes to ensure that dnsmasq has the latest nameservers.

It seems that 'unbound' is getting more love these days though, due to
it's DNSSEC capabilities, and there is not yet a NetworkManager DNS
plugin for unbound/dnssec-trigger.  I know some people are working on
that though (Thomas Hozza and Pavel Simerda) and I'd expect that to show
up in the near future.

Note that hotspot detection is an important part of this, since hotspots
will clearly break any kind of DNSSEC validation that happens, and
that's something that's being worked out between dnssec-trigger and
NetworkManager right now too.

NM in F20+ already has a "dns=none" option that prevents NM from
touching resolv.conf, but obviously if NM isn't touching it, the DNS
information that NM gets from upstream or your local configuration needs
to get to the local caching nameserver somehow.  Which is what the
existing NM DNS plugins are for, like the dnsmasq one.

Dan

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: NetworkManager "forget" user network configurations: bug or feature?

[Dan Williams]

On Wed, 2014-03-26 at 16:57 -0300, Sergio Belkin wrote:
> El 26/03/14 12:45, Stephen John Smoogen escribió:
> >
> >
> >
> > On 25 March 2014 13:53, Sergio Belkin  > > wrote:
> >
> >
> >
> > Adam,
> >
> > I've found that by default when I create a user, the checkbox in
> > NetworkManager that says
> >
> > "All users may connect to this network" is checked!
> >
> > If I uncheck anyway the network configuration files are in
> > /etc/sysconfig/network-scripts/
> >
> > Really I don't understand this behavior (using mate-desktop on F20)
> >
> >
> >
> > I believe the reason for this is due to various users who have their 
> > home directories on network mounted systems (even if only the user is 
> > the only one to set up the network connection.) If the data was stored 
> > in the home directory then the network could not start to thus mount 
> > the home directory to get the account. A similar problem occurs if the 
> > /home is encrypted separately from the root partition.
> >
> > In general, I just make sure that /root /etc and /home are backed up 
> > when I move from OS version to OS version so that I don't lose stuff I 
> > might need later.
> > -- 
> > Stephen J Smoogen.
> >
> >
> >
> 
> Hmmm... but NetworkManager should think in desktop users (ok, somewhat 
> power desktop users) that install a new release/distro and a user 
> configuration should be completely independent. Or at least give the 
> chance to save either systemwide or "userwide". Anyway thanks for your 
> answers and ideas, I understand that all of this is somewhat Off-Topic :)

TLDR; there used to be user-session config, there isn't any more, the
reasons for that are mostly security-related, and network connections
are most global anyway (until network namespaces hits for user
sessions).  NM defaults to user-session *password* storage though, and
VPNs always default to per-user visibility.
---

NM used to have system-wide and user-wide data years ago, and it stopped
doing that for a few reasons:

1) Every single Desktop Environment (KDE, GNOME, etc) had to implement
the user data store themselves in their preferred location (gconf/dconf,
kconfig, etc); it's a massive duplication of code that's pretty
pointless.

2) User connections are not available before that user logs in, for
obvious reasons; this prevents things like network mounted user home
directories which require the user's credentials to access (because the
user session is required to ask the user for those credentials, and that
requires that the user already be logged in)

3) When the user logs out, the network connection goes away, because the
connection is private to that user and the user is no longer logged in

4) You cannot easily control access to the user data store; any
malicious program running in the user's context can manipulate
connection data which a root-level system service needs to eventually
read; this is Not Good (TM).  Things are now well-protected via
PolicyKit permissions.

5) And the Big One, which is that network connections are global to the
machine anyway, at least if you're not using network namespaces, which
nobody is using yet to isolate user login sessions.  That may be the
future, but once you've connected your "private" network connection, any
application on the machine, or any other logged in user (including Fast
User Switching users) can access those network resources.

The network connection itself is not really private, but the
*credentials* to start it are, and that's what NetworkManager lets each
user session manage.  If you choose to, you can store your passwords in
the user session's keyring, protected by your login password or keyring
unlock password.  This prevents other users from being able to start
that network connection (since they don't have the password), but also
prevents using this connection before login, of course.  User password
storage is the default for VPN, 802.1x, and WiFi connections.

Second, you can restrict NetworkManager connections to specific users,
so that your VPN connection is only ever
connectable/disconnectable/editable by your user alone.  This is the
default for VPN connections.

These two mechanisms, in concert with PolicyKit permissions, allow
administrators to lock down or open up the machine in a very flexible
manner.  By default, most users are allowed to do whatever they want,
but the ability to lock things down is a couple clicks/vims/emacs away
if that's what they desire.

To ask another question: why should most network configuration be
*private* to specific users, when the network like ethernet or wifi is a
shared network with shared passwords?

In any case, thanks for the feedback, it's always welcome, and
discussion like this is always useful!

Dan

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: NetworkManager "forget" user network configurations: bug or feature?

[Dan Williams]

On Tue, 2014-03-25 at 16:53 -0300, Sergio Belkin wrote:
> 2014-03-25 16:20 GMT-03:00 Adam Williamson :
> 
> > On Tue, 2014-03-25 at 16:19 -0300, Sergio Belkin wrote:
> > > Hi Fedora folks,
> > >
> > > Since NetworkManager I suffer the same issue, release after release, ok,
> > > it's not a Fedora issue
> > >
> > > If I preserve the home partition and perform a newly installation, eg
> > > f19->f20 NetworkManager configurations per user are lost. I think that
> > > NM should respect the user settings and not "happily" send them to trash.
> > >
> > > But what do you think? What is the rationale of saving user
> > > configurations in the /etc directory?
> > >
> > > What do you think?
> >
> > Um. Are you sure this is what is happening? Are you sure these aren't
> > set as systemwide connections?
> > --
> > Adam Williamson
> > Fedora QA Community Monkey
> > IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
> > http://www.happyassassin.net
> >
> > --
> > devel mailing list
> > devel@lists.fedoraproject.org
> > https://admin.fedoraproject.org/mailman/listinfo/devel
> > Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
> 
> 
> 
> Adam,
> 
> I've found that by default when I create a user, the checkbox in
> NetworkManager that says
> 
> "All users may connect to this network" is checked!
> 
> If I uncheck anyway the network configuration files are in
> /etc/sysconfig/network-scripts/
> 
> Really I don't understand this behavior (using mate-desktop on F20)

No matter how that box is checked, the connection configuration will
always be in either /etc/NetworkManager/system-connections/ (WWAN,
Bluetooth, VPN, etc) or in standard ifcfg files
in /etc/sysconfig/network-scripts/ (everything else).  They do not
switch around between these directories.

What *is* affected per-user is passwords, like VPN passwords and WiFi
passphrases/keys.  Since these are stored in the user's session keyring,
they will be wiped out if the user's data is deleted.  But
NetworkManager should simply ask for the password the next time.

Also, by default, VPN connections are locked to the specific user that
created them.  This means that if you change usernames, the connection
will no longer be visible to your new user.  You can update the
connection by editing the file directly though.

To debug your issue, what do you get when you run:

sudo nmcli con

?

Dan

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Packaging changes on NetworkManager? Whither NetworkManager-glib...

[Dan Williams]

On Fri, 2014-03-21 at 10:04 -0600, Philip Prindeville wrote:
> Did something recently change with the packaging of NetworkManager?
> 
> I’m not finding NetworkManager-glib, just NetworkManager-glib-devel:

Outdated mirrors perhaps?  It's clearly in the repos:

http://mirror.cc.vt.edu/pub/fedora/linux//updates/20/x86_64/NetworkManager-glib-0.9.9.0-32.git20131003.fc20.x86_64.rpm

Does "yum clean all; yum upgrade" make things better?

Dan

> [root@builder philipp]# yum update 
> Loaded plugins: langpacks, refresh-packagekit
> adobe-linux-x86_64   |  951 B 00:00   
>   
> rpmfusion-free-updates   | 3.3 kB 00:00   
>   
> updates/20/x86_64/metalink   | 9.7 kB 00:00   
>   
> updates  | 4.6 kB 00:00   
>   
> Resolving Dependencies
> --> Running transaction check
> ---> Package libnm-gtk.x86_64 0:0.9.9.0-7.git20131028.fc20 will be updated
> ---> Package libnm-gtk.x86_64 0:0.9.9.0-8.git20140123.fc20 will be an update
> ---> Package nm-connection-editor.x86_64 0:0.9.9.0-7.git20131028.fc20 will be 
> updated
> ---> Package nm-connection-editor.x86_64 0:0.9.9.0-8.git20140123.fc20 will be 
> an update
> --> Processing Dependency: NetworkManager-glib >= 1:0.9.9.0-26 for package: 
> nm-connection-editor-0.9.9.0-8.git20140123.fc20.x86_64
> --> Finished Dependency Resolution
> Error: Package: nm-connection-editor-0.9.9.0-8.git20140123.fc20.x86_64 
> (updates)
>Requires: NetworkManager-glib >= 1:0.9.9.0-26
>Installed: 
> 1:NetworkManager-glib-0.9.9.0-20.git20131003.fc20.x86_64 (@fedora)
>NetworkManager-glib = 1:0.9.9.0-20.git20131003.fc20
>  You could try using --skip-broken to work around the problem
>  You could try running: rpm -Va --nofiles --nodigest
> [root@builder philipp]# repoquery NetworkManager\*
> NetworkManager-config-server-1:0.9.9.0-31.git20131003.fc20.x86_64
> NetworkManager-devel-1:0.9.9.0-31.git20131003.fc20.i686
> NetworkManager-devel-1:0.9.9.0-31.git20131003.fc20.x86_64
> NetworkManager-glib-devel-1:0.9.9.0-31.git20131003.fc20.i686
> NetworkManager-glib-devel-1:0.9.9.0-31.git20131003.fc20.x86_64
> NetworkManager-iodine-0:0.0.4-2.fc20.x86_64
> NetworkManager-iodine-gnome-0:0.0.4-2.fc20.x86_64
> NetworkManager-l2tp-0:0.9.8.6-1.fc20.x86_64
> NetworkManager-openconnect-0:0.9.8.0-2.fc20.x86_64
> NetworkManager-openswan-0:0.9.8.0-1.fc20.x86_64
> NetworkManager-openvpn-1:0.9.9.0-0.1.git20140128.fc20.x86_64
> NetworkManager-openvpn-gnome-1:0.9.9.0-0.1.git20140128.fc20.x86_64
> NetworkManager-pptp-1:0.9.8.2-3.fc20.x86_64
> NetworkManager-pptp-gnome-1:0.9.8.2-3.fc20.x86_64
> NetworkManager-ssh-0:0.9.2-0.2.20140209git46247c2.fc20.x86_64
> NetworkManager-ssh-gnome-0:0.9.2-0.2.20140209git46247c2.fc20.x86_64
> NetworkManager-vpnc-1:0.9.8.2-2.fc20.x86_64
> NetworkManager-vpnc-gnome-1:0.9.8.2-2.fc20.x86_64
> [root@builder philipp]# 
> 
> 
> For what it’s worth, I don’t even use NetworkManager as my desktop machine 
> has no Wifi, no VPN tunnels, etc.  So I just use the ‘network’ service 
> instead.  It would be nice if control-center didn’t have a dependency on 
> NetworkManager, and that it was optional instead.
> 
> -Philip
> 


-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: F20: what connects the lid switch to triggering suspend?

[Dan Williams]

On Tue, 2014-03-18 at 02:21 +0100, Lennart Poettering wrote:
> On Mon, 17.03.14 17:18, Dan Williams (d...@redhat.com) wrote:
> 
> > >   systemd-inhibit --list
> > 
> > Thanks...
> > 
> > *drum roll*
> > 
> > The offending package was telepathy-mission-control.  Not really sure
> > why it cared about suspend/resume, since I didn't have any telepathy
> > services configured, and wasn't using it (or empathy or
> > gnome-accounts-service) for any online accounts.
> 
> They want to set the IM accounts to "offline" when the machine goes
> down.

Yeah, I figured that was the case, but since I didn't have any Telepathy
accounts actually configured, I assumed it wouldn't care about
suspend/resume.  Obviously a bug in mission-control.

> BTW, logind versions from Rawhide will actually log the identity of all
> processes that take "delay" suspend locks and which don't release them
> by the time the timeout we put on that elapses. Or with other words, if
> something like Telepathy delays your suspend you should see logind
> mentioned that it is responsible for that in the logs. This hopefully
> puts enough shame on people to not delay suspend unnecessarily... ;-)

Neat!

Dan

> Lennart
> 
> -- 
> Lennart Poettering, Red Hat


-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: F20: what connects the lid switch to triggering suspend?

[Dan Williams]

On Fri, 2014-03-14 at 17:41 +0100, Tomasz Torcz wrote:
> On Fri, Mar 14, 2014 at 11:38:31AM -0500, Dan Williams wrote:
> > > 
> > > The lid switch is exposed as input device in Linux. logind opens that
> > > device and reacts on it. However it gives DEs the chance to inhibit
> > > this if they desire so. Gnome at least doesn't inhibit it perminantly
> > > though, but some components might delay suspends, for example Telepathy
> > > to log you out of your Jabber server...
> > > 
> > > Normally when you close the lid logind should log something about "Lid
> > > closed" or so... Look around the logs around this to figure out what
> > > mightbe going on.
> > 
> > I've run into this too, is there a quick command to get the list of
> > offending suspend inhibitors so we can debug further?
> 
>   systemd-inhibit --list

Thanks...

*drum roll*

The offending package was telepathy-mission-control.  Not really sure
why it cared about suspend/resume, since I didn't have any telepathy
services configured, and wasn't using it (or empathy or
gnome-accounts-service) for any online accounts.

Dan

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: F20: what connects the lid switch to triggering suspend?

[Dan Williams]

On Fri, 2014-03-14 at 01:45 +0100, Lennart Poettering wrote:
> On Thu, 13.03.14 18:07, Martin Langhoff (martin.langh...@gmail.com) wrote:
> 
> > My Lenovo X220, running up-to-date F20 occasionally gets into a state where
> > closing the laptop lid does not trigger suspend.
> > 
> > I want to narrow down on the problem, but I'm slightly lost on how
> > "the signal is routed" through the stack. udev->?-> systemd-suspend ->
> > kernel  ?
> 
> The lid switch is exposed as input device in Linux. logind opens that
> device and reacts on it. However it gives DEs the chance to inhibit
> this if they desire so. Gnome at least doesn't inhibit it perminantly
> though, but some components might delay suspends, for example Telepathy
> to log you out of your Jabber server...
> 
> Normally when you close the lid logind should log something about "Lid
> closed" or so... Look around the logs around this to figure out what
> mightbe going on.

I've run into this too, is there a quick command to get the list of
offending suspend inhibitors so we can debug further?

(pressing the power button to initiate suspend usually works for me when
lid close does not...)

Dan


-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Read this if your package includes a status notifier / system tray icon

[Dan Williams]

On Fri, 2014-03-07 at 00:18 +0100, Kevin Kofler wrote:
> Matthias Clasen wrote:
> > Please stop rewriting history. The spec was proposed, flaws were pointed
> > out in the review, and there was no willingness to address those flaws
> > in any meaningful way.
> 
> The purported "flaws" were of 2 kinds:
> * claims of underspecification that are irrelevant in practice because it 
> was obvious to everyone (other than GNOME, perhaps) how the intended 
> rendering looks like (similar to the XEmbed system tray icons, just without 
> the technical limitations of the XEmbed hack),

"obvious to everyone" - assuming that everyone understands something the
same way is about the worst way to write a specification.  You need to
explicitly state what that understanding is, otherwise it's not a
specification, it's a vague idea and everyone will have a different
understanding of that idea.  And a different, potentially incompatible
implementation of.

> * change requests that would have broken compatibility with the existing 
> implementations of the protocol already in wide use for little to no 
> practical benefit, such as nitpicking about the names of some D-Bus methods.

So just because something is in use, but hasn't been standardized or
been through any kind of standardization discussion, it should
automatically be adopted as-is?  I think not...

Dan

> It is no surprise that those "issues" were not "addressed".
> 
> And how is that different from all those specs coming from the GNOME camp, 
> that are always of the "take it or leave it" kind?
> 
> > You can consider it an 'excuse' all you want, but from my perspective,
> > it was the right decision.
> 
> Thanks for showing again how GNOME does not give a darn about 
> interoperability with other desktops. (See also how BOTH the GTK+ theme 
> integration for Qt and the Qt/KDE theme integration for GTK+ are always 
> worked on exclusively by KDE developers.) Sometimes one has to make 
> compromises in the name of interoperability.
> 
> I don't see how it would make gnome-shell worse to just give the status 
> notifiers using the new protocol the same treatment given to the legacy 
> XEmbed ones (stuff them in the message tray by default, and let TopIcons 
> work with them)).
> 
> Kevin Kofler
> 


-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: ModemManager update

[Dan Williams]

On Thu, 2014-02-13 at 19:00 +, Sérgio Basto wrote:
> On Qui, 2014-02-13 at 12:56 -0600, Dan Williams wrote: 
> > On Sat, 2014-02-01 at 15:03 +0100, poma wrote:
> > > With a companion libraries. ;)
> > > 
> > > ↗ libmbim-1.6.0
> > > ↗ libqmi-1.8.0
> > > ↗ ModemManager-1.2.0
> > > 
> > > 
> > > poma
> > > 
> > > 
> > > Oh Danny boy, the pipes, the pipes are calling
> > > From glen to glen, and down the mountain side
> > > The summer's gone, and all the flowers are dying
> > > 'Tis you, 'tis you must go and I must bide.
> > 
> > I've done the builds for rawhide with your patches; lets let them be
> > there for a week to see if there are major issues, and then update F20.
> > Sound OK?
> 
> So to test it,  I need build [1]
> ModemManager, libmbim and libqmi any thing else ? 

I believe these 3 are all you need.  If you encounter any problems:

mmcli --set-logging=DEBUG

and then try to reproduce the problem, and grab the systemd journal
output from ModemManager.  "mmcli -m 0" output is also very useful, feel
free to XXX out any IMSI or IMEI or phone #.

Dan

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: ModemManager update

[Dan Williams]

On Sat, 2014-02-01 at 15:03 +0100, poma wrote:
> With a companion libraries. ;)
> 
> ↗ libmbim-1.6.0
> ↗ libqmi-1.8.0
> ↗ ModemManager-1.2.0
> 
> 
> poma
> 
> 
> Oh Danny boy, the pipes, the pipes are calling
> From glen to glen, and down the mountain side
> The summer's gone, and all the flowers are dying
> 'Tis you, 'tis you must go and I must bide.

I've done the builds for rawhide with your patches; lets let them be
there for a week to see if there are major issues, and then update F20.
Sound OK?

Dan


-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: RFC - Downgrade BlueZ to v4.101 in Fedora 20

[Dan Williams]

On Sat, 2014-01-25 at 17:24 +0100, Kevin Kofler wrote:
> Paolo Bonzini wrote:
> >  From the BlueZ 5.0 release notes:
> > 
> > "Remove internal support for telephony (HFP and HSP) profiles. They
> > should be implemented using the new Profile interface preferably by the
> > telephony subsystem of choice (e.g. oFono which already supports this)"
> > 
> > For Fedora this means PulseAudio.
> 
> This is a recurring problem in Fedora: Developers of software X think that 
> feature Z is better done in software Y and happily remove Z from X, often 
> without even talking to the developers of Y, and always without waiting for 
> Y to actually implement the feature. In some cases, it is not even clear 
> whether Z can be implemented properly (i.e., to the extent it was in X) in 
> Y, I don't know whether that's the case here or whether it's just a matter 
> of time.
> 
> Features MUST NOT get removed without a working replacement!

Unfortunately, it's upstream Bluez that removed/changed these features
for version 5.  And the upstream Bluez developers stopped working on
Bluez4 in mid-2012.  So staying with Bluez4 would have meant using a
very, very out-of-date Bluez that Fedora developers would have to
maintain, since upstream clearly wasn't interested.

Dan

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: RFC - Downgrade BlueZ to v4.101 in Fedora 20

[Dan Williams]

On Fri, 2014-01-24 at 12:21 +0100, David Sommerseth wrote:
> On 23/01/14 21:19, Dan Williams wrote:
> > On Thu, 2014-01-23 at 14:17 -0600, Dan Williams wrote:
> >> On Thu, 2014-01-23 at 20:04 +0100, David Sommerseth wrote:
> >>> On 23/01/14 19:58, Frank Murphy wrote:
> >>>> On Thu, 23 Jan 2014 19:53:19 +0100
> [...snip...]
> >>> Might even be a worse conflict for other users, depending on installed
> >>> packages.  I believe there's no way around re-compiling NetworkManager,
> >>> pulseaudio and other GNOME and KDE packages depending on bluez.
> >>
> >> NM only uses bluez via the D-Bus interface, so if you force install
> >> bluez4, NM will still work and should even handle the change at runtime.
> >> And then you'll get DUN back too :)
> > 
> > Clarification: I actually don't mean runtime.  NM must be restarted to
> > notice the change from bluez4 <-> bluez5, but it does not need to be
> > recompiled.
> 
> The DBus interface with bluez5 have changed too.
> 
> <http://www.bluez.org/bluez-5-api-introduction-and-porting-guide/>
> 
> Does NM support both bluez NM APIs?

Correct. It determines which one to use when it starts up, based on what
version of bluez is running at that time.

However, because of a significant change in how DUN works with Bluez5,
NetworkManager does not (yet!) support DUN when Bluez5 is running.  We
are working on that.

Dan

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: RFC - Downgrade BlueZ to v4.101 in Fedora 20

[Dan Williams]

On Thu, 2014-01-23 at 16:58 -0500, Brian J. Murrell wrote:
> On Thu, 2014-01-23 at 20:04 +0100, David Sommerseth wrote:
> > 
> > Nope, several packages depends on the bluez-5.13-1 package.
> 
> Indeed.  However I could probably live without gnome-bluetooth if
> blueman were still available.
> 
> pulseaudio-module-bluetooth though.  Would it work with Bluez4?  Would
> it need a compile to do so?  I wonder how you make that a functional
> downgrade that users can select if they still need Bluez4.
> 
> > ---
> > --> Finished Dependency Resolution
> > Error: Package: pulseaudio-module-bluetooth-4.0-9.gitf81e3.fc20.x86_64
> > (@updates/20)
> >Requires: bluez >= 5.0
> >Removing: bluez-5.13-1.fc20.x86_64 (@updates/20)
> >bluez = 5.13-1.fc20
> >Downgraded By: bluez-4.101-9.fc19.x86_64 (updates)
> >bluez = 4.101-9.fc19
> >Available: bluez-4.101-6.fc19.x86_64 (fedora)
> >bluez = 4.101-6.fc19
> > Error: Package: 1:gnome-bluetooth-3.10.0-1.fc20.x86_64 (@anaconda/20)
> >Requires: bluez >= 5.0
> >Removing: bluez-5.13-1.fc20.x86_64 (@updates/20)
> >bluez = 5.13-1.fc20
> >Downgraded By: bluez-4.101-9.fc19.x86_64 (updates)
> >bluez = 4.101-9.fc19
> >Available: bluez-4.101-6.fc19.x86_64 (fedora)
> >bluez = 4.101-6.fc19
> >  You could try using --skip-broken to work around the problem
> >  You could try running: rpm -Va --nofiles --nodigest
> > 
> > 
> > Might even be a worse conflict for other users, depending on installed
> > packages.  I believe there's no way around re-compiling NetworkManager,
> > pulseaudio and other GNOME and KDE packages depending on bluez.
> 
> Indeed.  I suspect the same.  Perhaps gnome-bluetooth could be
> uninstalled and replace with blueman without too much heartburn.  It's
> the other packages that get troublesome.  A
> pulseaudio-module-bluetooth-bluez4 as an alternative BT module for PA?
> Something similar for NM?  It's starting to get ugly and perhaps the
> effort spent doing that would be better put towards:
> 
> https://bugs.freedesktop.org/show_bug.cgi?id=73325#c5
> 
> But either way, it does seem a pretty serious regression.  Although
> maybe you and me, David, are the only F20 users using HSP bluetooth
> headsets.  :-/

Out of curiosity, what do people use Blueman for?

Dan

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: RFC - Downgrade BlueZ to v4.101 in Fedora 20

[Dan Williams]

On Thu, 2014-01-23 at 14:17 -0600, Dan Williams wrote:
> On Thu, 2014-01-23 at 20:04 +0100, David Sommerseth wrote:
> > On 23/01/14 19:58, Frank Murphy wrote:
> > > On Thu, 23 Jan 2014 19:53:19 +0100
> > > David Sommerseth  wrote:
> > > 
> > >>
> > >> Hi all,
> > >>
> > >> This might be a viewed as a fire torch, but there is, IMO, a major
> > >> regression in BlueZ 5 which is shipped in Fedora 20.  It doesn't
> > >> support HSP/HFP headset profiles, which enables the microphone on
> > >> many bluetooth headsets.  It's already tracked in this BZ:
> > >>
> > >>
> > > 
> > > is just downgrading bluez any help?
> > > yum downgrade bluez* --releasever=19
> > 
> > Nope, several packages depends on the bluez-5.13-1 package.
> > 
> > ---
> > --> Finished Dependency Resolution
> > Error: Package: pulseaudio-module-bluetooth-4.0-9.gitf81e3.fc20.x86_64
> > (@updates/20)
> >Requires: bluez >= 5.0
> >Removing: bluez-5.13-1.fc20.x86_64 (@updates/20)
> >bluez = 5.13-1.fc20
> >Downgraded By: bluez-4.101-9.fc19.x86_64 (updates)
> >bluez = 4.101-9.fc19
> >Available: bluez-4.101-6.fc19.x86_64 (fedora)
> >bluez = 4.101-6.fc19
> > Error: Package: 1:gnome-bluetooth-3.10.0-1.fc20.x86_64 (@anaconda/20)
> >Requires: bluez >= 5.0
> >Removing: bluez-5.13-1.fc20.x86_64 (@updates/20)
> >bluez = 5.13-1.fc20
> >Downgraded By: bluez-4.101-9.fc19.x86_64 (updates)
> >bluez = 4.101-9.fc19
> >Available: bluez-4.101-6.fc19.x86_64 (fedora)
> >bluez = 4.101-6.fc19
> >  You could try using --skip-broken to work around the problem
> >  You could try running: rpm -Va --nofiles --nodigest
> > 
> > 
> > Might even be a worse conflict for other users, depending on installed
> > packages.  I believe there's no way around re-compiling NetworkManager,
> > pulseaudio and other GNOME and KDE packages depending on bluez.
> 
> NM only uses bluez via the D-Bus interface, so if you force install
> bluez4, NM will still work and should even handle the change at runtime.
> And then you'll get DUN back too :)

Clarification: I actually don't mean runtime.  NM must be restarted to
notice the change from bluez4 <-> bluez5, but it does not need to be
recompiled.

Dan

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: RFC - Downgrade BlueZ to v4.101 in Fedora 20

[Dan Williams]

On Thu, 2014-01-23 at 20:04 +0100, David Sommerseth wrote:
> On 23/01/14 19:58, Frank Murphy wrote:
> > On Thu, 23 Jan 2014 19:53:19 +0100
> > David Sommerseth  wrote:
> > 
> >>
> >> Hi all,
> >>
> >> This might be a viewed as a fire torch, but there is, IMO, a major
> >> regression in BlueZ 5 which is shipped in Fedora 20.  It doesn't
> >> support HSP/HFP headset profiles, which enables the microphone on
> >> many bluetooth headsets.  It's already tracked in this BZ:
> >>
> >>
> > 
> > is just downgrading bluez any help?
> > yum downgrade bluez* --releasever=19
> 
> Nope, several packages depends on the bluez-5.13-1 package.
> 
> ---
> --> Finished Dependency Resolution
> Error: Package: pulseaudio-module-bluetooth-4.0-9.gitf81e3.fc20.x86_64
> (@updates/20)
>Requires: bluez >= 5.0
>Removing: bluez-5.13-1.fc20.x86_64 (@updates/20)
>bluez = 5.13-1.fc20
>Downgraded By: bluez-4.101-9.fc19.x86_64 (updates)
>bluez = 4.101-9.fc19
>Available: bluez-4.101-6.fc19.x86_64 (fedora)
>bluez = 4.101-6.fc19
> Error: Package: 1:gnome-bluetooth-3.10.0-1.fc20.x86_64 (@anaconda/20)
>Requires: bluez >= 5.0
>Removing: bluez-5.13-1.fc20.x86_64 (@updates/20)
>bluez = 5.13-1.fc20
>Downgraded By: bluez-4.101-9.fc19.x86_64 (updates)
>bluez = 4.101-9.fc19
>Available: bluez-4.101-6.fc19.x86_64 (fedora)
>bluez = 4.101-6.fc19
>  You could try using --skip-broken to work around the problem
>  You could try running: rpm -Va --nofiles --nodigest
> 
> 
> Might even be a worse conflict for other users, depending on installed
> packages.  I believe there's no way around re-compiling NetworkManager,
> pulseaudio and other GNOME and KDE packages depending on bluez.

NM only uses bluez via the D-Bus interface, so if you force install
bluez4, NM will still work and should even handle the change at runtime.
And then you'll get DUN back too :)

Dan

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: NetworkManager Bridges in Fedora

[Dan Williams]

On Mon, 2014-01-20 at 23:18 -0500, Nico Kadel-Garcia wrote:
> My old notes at
> https://wikis.uit.tufts.edu/confluence/display/TUSKpub/Configure+Pair+Bonding,+VLANs,+and+Bridges+for+KVM+Hypervisor
> were pretty good.
> 
> If you want stable KVM bridging, pair bonding, jumbo frames, or
> consistent network connections of any sort for server  grade
> installations, my urgent advice is to rip NetworkManager out by the
> routes. It provides no useful benefit for a stable server environment,
> and is actively destabilizing because it rewrite and overwrites
> network configurations inconsistently, and in ways that are not
> "idempotent": the same steps executed two times in a row do not
> produce the same results, and only approach consistency thorugh a sort
> of "Newtonian approximation" eventually, but only eventually,
> publishing a vaguely stable configuration.
> 
> Networkmanager is not your friend for stable servers.

We have spent the last few years ensuring this is not the case.  We have
been making tons of changes specifically to ensure stable networking,
eliminate the surprises you may have experienced in the past.  I'd
encourage you to try out these changes in F20 and beyond, and if you
find problems, by all means file bugs and we'll work to fix them.

Dan

> On Sat, Jan 18, 2014 at 11:35 AM, Mateusz Marzantowicz
>  wrote:
> > On 16.01.2014 21:38, Dan Williams wrote:
> >> On Thu, 2014-01-16 at 14:53 -0500, Steve Dickson wrote:
> >>>
> >>> On 16/01/14 14:39, Steve Dickson wrote:
> >>>>
> >>>>
> >>>> On 16/01/14 14:09, Dan Williams wrote:
> >>>>> Also, if wouldn't mind passing along the systemd journal output for
> >>>>> NetworkManager, that might help us figure out what's going on:
> >>>>>
> >>>>> journalctl -b _SYSTEMD_UNIT=NetworkManager.service
> >>>> The log is at:
> >>>>   http://steved.fedorapeople.org/tmp/nm.log
> >>> I bet ya the hang has something to do with these messages:
> >>>
> >>> (bridge0): IPv4 config waiting until carrier is on
> >>> (bridge0): IPv6 config waiting until carrier is on
> >>> Activation (bridge0) Stage 3 of 5 (IP Configure Start) complete.
> >>>
> >>> What carrier is it waiting on? em1 is already up and running...
> >>
> >> So what's happening here is that you two
> >> configurations/connections/profiles that apply to em1: "ifcfg-em1", and
> >> "ifcfg-bridge0_slave_1".  And "ifcfg-em1" is getting chosen, but it's
> >> not a bridge slave configuration, it's just a normal DHCP configuration.
> >>
> >> Since "ifcfg-em1" is not a bridge slave configuration, it never gets
> >> added to the bridge master, and the bridge master sits around waiting
> >> for slaves because it has no carrier which is required for DHCP.
> >>
> >> Persistent fix #1:
> >> edit ifcfg-em1 and change ONBOOT=yes to ONBOOT=no
> >> nmcli con reload
> >> then do "Runtime fix" below
> >>
> >> Persistent fix #2:
> >> rm /etc/sysconfig/network-scripts/ifcfg-em1
> >> nmcli con reload
> >> then do "Runtime fix" below
> >>
> >> (or use nm-connection-editor to delete 'em1' or uncheck "Connect
> >> automatically" from the General tab.)
> >>
> >> Runtime fix (not persistent):
> >> nmcli dev disconnect em1
> >> nmcli con up "bridge0 slave 1"
> >>
> >>
> >> --
> >> (In old "network" service speak, the runtime operation would be:
> >>
> >> ifdown em1
> >> ifup bridge0_slave_1
> >>
> >> and we still expect these commands to work even when NetworkManager is
> >> managing the interface.)
> >> --
> >>
> >> Dan
> >>
> >
> > I'm doing this differently and now I don't know which method is
> > recommended by RH/Fedora gurus. I don't use
> > /etc/sysconfig/network-scripts at all but placed all network related
> > configuration in /etc/NetworkManager/system-connections/ directory. Now
> > I'm not sure if I should convert back to using /etc/sysconfig or what?
> > Not to mention that GUI tool is c... and I had to use text editor to
> > configure network bridging.
> >
> >
> >
> > Mateusz Marzantowicz
> > --
> > devel mailing list
> > devel@lists.fedoraproject.org
> > https://admin.fedoraproject.org/mailman/listinfo/devel
> > Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct


-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: NetworkManager Bridges in Fedora

[Dan Williams]

On Sat, 2014-01-18 at 17:35 +0100, Mateusz Marzantowicz wrote:
> On 16.01.2014 21:38, Dan Williams wrote:
> > On Thu, 2014-01-16 at 14:53 -0500, Steve Dickson wrote:
> >>
> >> On 16/01/14 14:39, Steve Dickson wrote:
> >>>
> >>>
> >>> On 16/01/14 14:09, Dan Williams wrote:
> >>>> Also, if wouldn't mind passing along the systemd journal output for
> >>>> NetworkManager, that might help us figure out what's going on:
> >>>>
> >>>> journalctl -b _SYSTEMD_UNIT=NetworkManager.service
> >>> The log is at:
> >>>   http://steved.fedorapeople.org/tmp/nm.log 
> >> I bet ya the hang has something to do with these messages:
> >>
> >> (bridge0): IPv4 config waiting until carrier is on
> >> (bridge0): IPv6 config waiting until carrier is on
> >> Activation (bridge0) Stage 3 of 5 (IP Configure Start) complete.
> >>
> >> What carrier is it waiting on? em1 is already up and running... 
> > 
> > So what's happening here is that you two
> > configurations/connections/profiles that apply to em1: "ifcfg-em1", and
> > "ifcfg-bridge0_slave_1".  And "ifcfg-em1" is getting chosen, but it's
> > not a bridge slave configuration, it's just a normal DHCP configuration.
> > 
> > Since "ifcfg-em1" is not a bridge slave configuration, it never gets
> > added to the bridge master, and the bridge master sits around waiting
> > for slaves because it has no carrier which is required for DHCP.
> > 
> > Persistent fix #1:
> > edit ifcfg-em1 and change ONBOOT=yes to ONBOOT=no
> > nmcli con reload
> > then do "Runtime fix" below
> > 
> > Persistent fix #2:
> > rm /etc/sysconfig/network-scripts/ifcfg-em1
> > nmcli con reload
> > then do "Runtime fix" below
> > 
> > (or use nm-connection-editor to delete 'em1' or uncheck "Connect
> > automatically" from the General tab.)
> > 
> > Runtime fix (not persistent):
> > nmcli dev disconnect em1
> > nmcli con up "bridge0 slave 1"
> > 
> > 
> > --
> > (In old "network" service speak, the runtime operation would be:
> > 
> > ifdown em1
> > ifup bridge0_slave_1
> > 
> > and we still expect these commands to work even when NetworkManager is
> > managing the interface.)
> > --
> > 
> > Dan
> > 
> 
> I'm doing this differently and now I don't know which method is
> recommended by RH/Fedora gurus. I don't use
> /etc/sysconfig/network-scripts at all but placed all network related
> configuration in /etc/NetworkManager/system-connections/ directory. Now
> I'm not sure if I should convert back to using /etc/sysconfig or what?
> Not to mention that GUI tool is c... and I had to use text editor to
> configure network bridging.

Both ifcfg files (/etc/sysconfig/network-scripts) or keyfiles
(/etc/NetworkManager/system-connections) are supported, and the GUI
tools and nmcli work fine with both.  If they don't, that's a bug and
we'll fix it.

Dan

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: NetworkManager Bridges in Fedora

[Dan Williams]

On Thu, 2014-01-16 at 14:53 -0500, Steve Dickson wrote:
> 
> On 16/01/14 14:39, Steve Dickson wrote:
> > 
> > 
> > On 16/01/14 14:09, Dan Williams wrote:
> >> Also, if wouldn't mind passing along the systemd journal output for
> >> NetworkManager, that might help us figure out what's going on:
> >>
> >> journalctl -b _SYSTEMD_UNIT=NetworkManager.service
> > The log is at:
> >   http://steved.fedorapeople.org/tmp/nm.log 
> I bet ya the hang has something to do with these messages:
> 
> (bridge0): IPv4 config waiting until carrier is on
> (bridge0): IPv6 config waiting until carrier is on
> Activation (bridge0) Stage 3 of 5 (IP Configure Start) complete.
>
> What carrier is it waiting on? em1 is already up and running... 

So what's happening here is that you two
configurations/connections/profiles that apply to em1: "ifcfg-em1", and
"ifcfg-bridge0_slave_1".  And "ifcfg-em1" is getting chosen, but it's
not a bridge slave configuration, it's just a normal DHCP configuration.

Since "ifcfg-em1" is not a bridge slave configuration, it never gets
added to the bridge master, and the bridge master sits around waiting
for slaves because it has no carrier which is required for DHCP.

Persistent fix #1:
edit ifcfg-em1 and change ONBOOT=yes to ONBOOT=no
nmcli con reload
then do "Runtime fix" below

Persistent fix #2:
rm /etc/sysconfig/network-scripts/ifcfg-em1
nmcli con reload
then do "Runtime fix" below

(or use nm-connection-editor to delete 'em1' or uncheck "Connect
automatically" from the General tab.)

Runtime fix (not persistent):
nmcli dev disconnect em1
nmcli con up "bridge0 slave 1"


--
(In old "network" service speak, the runtime operation would be:

ifdown em1
ifup bridge0_slave_1

and we still expect these commands to work even when NetworkManager is
managing the interface.)
--

Dan

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: NetworkManager Bridges in Fedora

[Dan Williams]

On Thu, 2014-01-16 at 13:53 -0500, Steve Dickson wrote:
> Hello,
> 
> Has anybody had any luck with getting bridges
> consistently up in running in either F19 or F20?
> I know I have not... 
> 
> I go into setup/networks. Add a bridge which creates 
> two file in /etc/sysconfig/network-scripts
> 
> ifcfg-Bridge_connection_1
> ifcfg-bridge0_slave_1
> 
> The contents seem reasonable. 
> 
> After I reboot, I go back in to setup/networks. The status
> of the bridge is "connecting" and the Bridge slaves
> are "none"???

Quick question on that, are both the master and the slave set to
"connect automatically?"  Or, in the ifcfg files, is ONBOOT=yes set for
both master and slave?

Also, if wouldn't mind passing along the systemd journal output for
NetworkManager, that might help us figure out what's going on:

journalctl -b _SYSTEMD_UNIT=NetworkManager.service

Thanks!
Dan

> Anybody know what has to happen to get this code working??
> 
> tia,
> 
> steved.
> 
> P.S. If there is a better list for me to ask this 
>  question, please point me to it... 
> 


-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: PSA: If you are C/C++ developer, use cppcheck

[Dan Williams]

On Tue, 2013-12-17 at 12:17 -0500, Rahul Sundaram wrote:
> Hi
> 
> In the last few days, I have been running cppcheck on quite a few programs
> including systemd, transmission, libvirt,  ndjbdns etc and cppcheck has
> found real and potential bugs (null pointer dereferences, uninitialized
> variables, memory & resource leaks etc) in each of them.  I have reported
> the ones I found and several developers have already fixed the issues.   A
> couple of examples

How are you running it to get it to print the warnings?  I've tried
--enable=warning, but all I get are includes errors (like )
that aren't useful and are wrong AFAICT.

Dan

> http://cgit.freedesktop.org/systemd/systemd/commit/?id=e985665d2d226cb42b52bfcad6fd5b1586ad57d7
> 
> https://github.com/pjps/ndjbdns/commit/ee4112a702e22d447d9cd7bd31b880eacfe59a5e
> 
> You might also consider add a build target for regular checks
> 
> http://cgit.freedesktop.org/systemd/systemd/commit/?id=16f4efb4150c65e3c61adaa8ea512489de49f532
> 
> That would be all.  Thanks
> 
> Rahul


-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: TLS libraries and licenses

[Dan Williams]

On Wed, 2013-11-27 at 09:27 -0700, Jerry James wrote:
> For one package for which I am part of upstream, we are talking about
> adding TLS support.  The upstream project is GPLv3+.  We're looking at
> the preferred list of crypto implementations on
> http://fedoraproject.org/wiki/FedoraCryptoConsolidation and have a
> couple of questions.
> 
> The most preferred option is NSS, which is MPLv2.0.  The license list
> at https://fedoraproject.org/wiki/Licensing:Main?rd=Licensing#SoftwareLicenses
> says that MPLv2.0 is "sometimes" compatible with GPLv3.  If I'm
> reading the MPLv2.0 page correctly, then compatibility is strictly a
> function of the MPL-licensed package.  In that case, wouldn't it make
> sense for us to have two license tags for our RPMs:
> MPLv2.0-GPL-compatible and MPLv2.0-GPL-incompatible?  (Not necessarily
> with those names, of course.)  As it is, anyone in our situation has
> to independently evaluate the MPLv2.0 package to figure out whether it
> is GPL compatible or not.  (The NSS source code fortunately contains a
> note on GPL compatibility.)
> 
> The second option is gnutls, which is various flavors of GPL and LGPL,
> and so is fine for us.  We did have one developer wonder why gnutls is
> preferred over openssl, though.  Can anyone answer that question?

You answered that just below; because OpenSSL is GPL incompatible.
Since gnutls is LGPL, it can be used in most places openssl can be used,
*plus* it can be used with GPL software.  Obviously, consult your
lawyers for the specifics of your situation.

> The third option is OpenSSL, whose license is GPL-incompatible, and so
> not an option for us.
> 
> The fourth option is libgcrypt, which is LGPLv2+, and so is fine for
> us in terms of license (haven't looked at available functionality
> yet).

libgcrypt is actually just basic crypto, not TLS.  gnutls is based on
libgcrypt.  So it's not an alternative to anything above for TLS stuff,
but you'll get it anyway if you choose gnutls.

You really only need to plan for one or both of NSS or gnutls.  While it
may not help you much because it doesn't do any TLS stuff,
NetworkManager does have an abstraction layer for both NSS and gnutls
for basic crypto and certificate/private-key operations:

http://cgit.freedesktop.org/NetworkManager/NetworkManager/tree/libnm-util

See any of the crypto* files.

Dan

> Our plan, then, is to add an abstraction layer to hide the
> implementing library, and prepare implementations for nss, gnutls, and
> libgcrypt if it isn't too much work.  Does this seem reasonable?
> -- 
> Jerry James
> http://www.jamezone.org/


-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Fatal flaw in the udev paradigm?

[Dan Williams]

On Thu, 2013-10-31 at 12:50 -0400, Przemek Klosowski wrote:
> On 10/31/2013 02:03 AM, rran...@ihug.com.au wrote:
> > I have run into an issue which seems to call into question the udev 
> > paradigm for USB devices. In my case it has ramifications in 
> > ModemManager and gpsd packages, but I see it as a fundamental problem 
> > with udev which is in all current versions of Fedora.
> >
> > My USB GPS is a BU-353 which uses a pl2303 USB-Serial Controller 
> > (idVendor=067b, idProduct=2303). However, bugzilla report 878737 
> > indicates this same interface chip is used on other devices such as 
> > RS232-USB adapters.
> >
> > If the device is a GPS you do not want ModemManager run on it 
> > (bugzilla 1023234) but you do want gpsctl to tell gpsd about it when 
> > it is plugged in. If it is a RS232 adapter the opposite is true 
> > (bugzilla 878737). Note that it is reported that the DU-353 can be 
> > bricked if the wrong thing is written to it.
> >
> > After looking at the lsusb -v output for my BU-353 and the output for 
> > RS232 devices reported on the net, I do not see any way to distinguish 
> > between the two different types of devices that udev could use to tell 
> > them apart.
> >
> > Unless I am missing something this seems like a fatal flaw in the udev 
> > paradigm.
> >
> 
> As the others have said, there's no way to determine what's sitting 
> behind those serial controllers so it's not a problem with udev but with 
> the hardware it has to handle. The default udev setting is, or at least 
> used to be, designed for the most common case, which turns out wrong for 
> you. No matter what udev does, someone is not going to get their device 
> auto-configured, so the right choice is to handle the most common case.
> 
> Now, it's possible that modems aren't just used much any more, so that 
> requiring manual scan would make sense, and udev makes it possible.
> 
> By the way, it seems to me that on a computer with no modems, one should 
> simply uninistal ModemManager:

Not just a computer with no modems, but a computer into which you would
never plug a modem and use it.  These days, there aren't many 56k/POTS
devices, but the vast vast majority are WWAN modems.  And these are
sometimes, especially in embedded cases, driven by generic serial
converters like pl2xxx.  If you're on a server, and that server does not
have any "SMS me when you're down" functionality, then you may not want
ModemManager installed there.  But we'd also like to hear about devices
that MM probes-but-shouldn't-probe so we can black/greylist them as
appropriate.

Dan

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Fatal flaw in the udev paradigm?

[Dan Williams]

On Thu, 2013-10-31 at 11:49 -0400, DJ Delorie wrote:
> Can you wildcard the greylist so that modemmanager *never* runs?  I
> haven't used a modem in decades but MM keeps mucking with all my
> serial-connected toys.

You can do anything you want with the udev rules.  Just put them
in /etc/udev/rules.d.

But better yet, mind sharing which toys you have so we can update the
black/greylists as appropriate?

Thanks!
Dan


-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: gnome-boxes downgrade in F-19

[Dan Williams]

On Tue, 2013-10-08 at 08:42 -0600, Jerry James wrote:
> Do you remember when I ranted about lack of communication between
> provenpackagers and the maintainers of the packages they touch [1]?
> Here is another case of lack of communication between people touching
> the same package.
> 
> On Aug 8, Zeeshan Ali built gnome-boxes-3.8.4-1.fc19 and submitted
> update FEDORA-2013-14567.
> 
> On Aug 9, Christophe Fergeau built gnome-boxes-3.8.4-2.fc19.  Instead
> of editing the existing update, Christophe chose to create a competing
> update, FEDORA-2013-14530.

Seems like there's something wrong with Bodhi here, because every time I
create an update when there's already an older update pending, Bodhi
obsoletes the old one and adds all the bugs from the old one to the new
update.  Even if somebody else filed the older update and I'm creating
the new one. AFAIK, normal procedure is that you *don't* edit the old
update at all, but each package NVR should get a new Bodhi update (so
Christophe was correct in creating a new "competing" one) but that Bodhi
takes care of obsoleting the old one.

Dan

> On Aug 13, update FEDORA-2013-14530 acquired enough karma to be
> autopushed to stable.  It went stable on Aug 15.
> 
> The first update, FEDORA-2013-14567, stayed in limbo for awhile until
> positive karma was given to it on Sep 28 and 29, causing it to reach
> its karma threshold on Sep 29, and be autopushed to stable.  On Sep
> 30, it went stable, wiping out the -2 build.
> 
> Is there any way we can change the update system to detect competing
> updates like this?  The update system should have refused to create
> the second update, and required Christophe to either (1) edit the
> existing update, or (2) get the existing update canceled first, then
> submit the new one.
> 
> Footnotes:
> [1] https://lists.fedoraproject.org/pipermail/devel/2013-May/182432.html
> -- 
> Jerry James
> http://www.jamezone.org/


-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Firewall blocking desktop features

[Dan Williams]

On Fri, 2013-09-13 at 11:23 +0300, Oron Peled wrote:
> On Friday 13 September 2013 01:51:00 drago01 wrote:
> > On Fri, Sep 13, 2013 at 1:26 AM, Oron Peled  wrote:
> > >- This means that any privileged service controlled by GUI client (e.g:
> > >  NetworkManager) is still only as secure as it's controller (e.g:
> > >  nm-applet).
> > This is wrong. That's not how "controlling the service" works.
> 
> Care to explain?
>  * Let's assume someone exploit a buffer overflow in nm-applet to execute
>arbitrary code.
> 
>  * Now she can ask (over dbus) from NM to do "legitimate" operations without
>the user consent/knowledge -- e.g: connect to some random-joe wireless
>network, etc. (btw, the user can still discover the truth via other
>client which isn't subverted -- like nmcli, the kde widget, etc.)

nm-applet can certainly *ask* NetworkManager to do something.  Depending
on the policy that an administrator has set, NetworkManager will ask the
user to authorize the request via PolicyKit.  Only if the request is
authorized, will that request be granted.  If your user must authorize
before you can obtain the ModifySystem and ModifyOwn permissions, then
no, nm-applet can't ask NetworkManager to connect to malicious networks
unless that trojan also somehow subverts PolicyKit.

Dan

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Multiple Loopback Interfaces

[Dan Williams]

On Thu, 2013-08-29 at 15:46 +0200, Reindl Harald wrote:
> 
> Am 29.08.2013 15:38, schrieb John Chludzinski:
> > I need to used multiple loopback addresses (interfaces) for an server
> > application that communicates with multiple clients running on the same
> > machine.  Since a loopback interface short circuits the network stack
> > (looping back in the IP layer) it is a more efficient means of
> > communication, hence better for my purpose.
> > 
> > How do I define multiple loopback interfaces?
> > 
> > BTW, I'm a newbie to this mailing mailing list.  Hopefully this is an
> > appropriate question?
> 
> if you are running network.service it's trivial
> NetworkManager -> no ida, i do not touch it

NM does nothing with lo, so the same procedure below would certainly
apply if you're running NM.  Touch lo all you want.

Dan

> ___
> 
> [root@rh:/etc/sysconfig/network-scripts]$ cat 
> /etc/sysconfig/network-scripts/ifcfg-lo:1
> DEVICE=lo:1
> IPADDR=127.0.0.2
> ONPARENT=yes
> 
> [root@rh:/etc/sysconfig/network-scripts]$ ifup lo:1
> 
> [root@rh:/etc/sysconfig/network-scripts]$ ifconfig lo:1
> lo:1: flags=73  mtu 65536
> inet 127.0.0.2  netmask 255.0.0.0
> loop  txqueuelen 0  (Lokale Schleife)
> 
> [root@rh:/etc/sysconfig/network-scripts]$ ping 127.0.0.2
> PING 127.0.0.2 (127.0.0.2) 56(84) bytes of data.
> 64 bytes from 127.0.0.2: icmp_seq=1 ttl=50 time=0.056 ms
> ___
> 
> that's the "lo" config shipped with Fedora
> 
> [root@rh:/etc/sysconfig/network-scripts]$ cat 
> /etc/sysconfig/network-scripts/ifcfg-lo
> DEVICE=lo
> IPADDR=127.0.0.1
> NETMASK=255.0.0.0
> NETWORK=127.0.0.0
> # If you're having problems with gated making 127.0.0.0/8 a martian,
> # you can change this to something else (255.255.255.255, for example)
> BROADCAST=127.255.255.255
> ONBOOT=yes
> NAME=loopback
> 


-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: BlueZ Status in Fedora.

[Dan Williams]

On Thu, 2013-08-01 at 18:36 +0100, Peter Robinson wrote:
> On Thu, Aug 1, 2013 at 6:14 PM, Tomasz Torcz  wrote:
> > On Thu, Aug 01, 2013 at 07:05:39PM +0200, Stefan Held wrote:
> >> What exactly is holding the Updates back in Fedora?
> >> Is there a reason for excluding the 5.x Series?
> >
> >
> >   See https://fedoraproject.org/wiki/Changes/Bluez5
> > and the thread starting at 
> > https://lists.fedoraproject.org/pipermail/devel/2013-May/182355.html
> 
> I was kind of expecting this would have landed by now though, Bastien
> will be @ GUADEC this week so not sure if he'll respond quickly

For the NetworkManager side, porting to Bluez5 requires a couple things
yet to finish:

1) DUN support: bluez5 makes this incredibly difficult because the DUN
serial channel is no longer a kernel device and thus can't be used with
pppd, can only be seen by one process, thus we pretty much have to cut
Bluez5 out of the DUN path entirely.  That's being worked on slowly.

2) a behavior change in NetworkManager to show all PAN/DUN capable
devices immediately, not just ones that have been configured during
pairing.  This requires some updates to the GUI apps and some additional
changes to NetworkManager to prompt the user to configure the device
upon first-use, instead of at pair-time.

Dan

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Obsoleting ConsoleKit once and for all

[Dan Williams]

On Tue, 2013-07-30 at 23:03 +0200, Lars Seipel wrote:
> On Tue, Jul 30, 2013 at 04:28:55PM +0200, Christoph Wickert wrote:
> > thunar and pcmanfm are file managers and require ConsoleKit for handling
> > removable storage.
> 
> Are you sure you aren't confusing this with something? HAL maybe? 

There's some interaction with ConsoleKit to ensure that the removable
storage is tied to a specific session so that the logged-in user can
actually modify their USB drive.  Otherwise it's only accessible to
'root'.

So yes, something *else* (HAL, udisks, etc) actually handles the
mounting, but there's some other components involved in permissions and
mount location, and that's where ConsoleKit helps out.

Dan

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: F20 Self Contained Change: Adding NetworkManager Connections via CLI

[Dan Williams]

On Tue, 2013-07-23 at 11:46 -0700, David Strauss wrote:
> On Tue, Jul 23, 2013 at 6:12 AM, Jaroslav Reznik  wrote:
> > Support for adding new NetworkManager connections using the nmcli 
> > commandline
> > tool.
> 
> This would be wonderful to have on servers.

That is exactly the use-case we're targeting.

Dan

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel