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.

Well... I trust this connection to protect 

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(_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 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 

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 <d...@redhat.com>
> 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
> > > > > > mean
> > > > > > “address
&g

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: 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: 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 <d...@redhat.com> 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: 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 Tue, 2015-11-17 at 17:36 -0600, Jason L Tibbitts III wrote:
> > > > > > "DW" == Dan Williams <d...@redhat.com> 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 Wed, 2015-11-18 at 11:32 -0600, Jason L Tibbitts III wrote:
> > > > > > "DW" == Dan Williams <d...@redhat.com> 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 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 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
  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

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 a list of server
+domain, and then a fallback of server+* for anything not matching
that list.

 any resolve calls made will use the non-system resolv.conf's nameserver
 addresses.
 
 So the hotspot check could be:
 
 ctx = unbound.ub_ctx()
 ctx.add_ta_file(rootanchor) # DNSSEC root key
 ctx.resolvconf(/this/networks/respresentation/of/resolv.conf)
 status, result = ctx.resolve(fedoraproject.org, unbound.RR_TYPE_A)
 if not result.havedata or not result.secure:
   # we're captive because fedoraproject.org is DNSSEC signed and
   # we got an error (forged) response
   # Redo query with a non-DNSSEC cache to get forged A record to
   # authenticate to the hotspot
   insecurectx = unbound.ub_ctx()
   insecurectx.resolvconf(/this/networks/respresentation/of/resolv.conf)
   status, result

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.
 
  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
  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?
 
  The only trusted DNS resolver is the local Unbound. The DNS resolver
  from the network you are connected to is never trusted. It is just used
  in case it can provide all the necessary information to do the DNSSEC
  validation. Since using such data we are able to build the chain of
  trust and verify that the Answer is correct, there is no point in
  distinguishing if network provided resolver

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 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 context, I do have some thoughts to
contribute here.



The third part of the problem, unrelated to 

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
  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?
 
 The only trusted DNS resolver is the local Unbound. The DNS resolver
 from the network you are connected to is never trusted. It is just used
 in case it can provide all the necessary information to do the DNSSEC
 validation. Since using such data we are able to build the chain of
 trust and verify that the Answer is correct, there is no point in
 distinguishing if network provided resolver is trusted or not... it is
 not. This is the reason we do the validation locally.

Ok, I should rephrase my question to be clearer.  NM's connectivity
checking

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 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 as long as we can manually resolve the connectivity
URI address without telling applications about the new DNS servers.

Once we've determined

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 d...@redhat.com 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 NM provided its own
 UI, that UI tended to work.  These days I frequently notice the
 gnome-shell UI for networking, bluetooth, etc missing features that
 are supported by the backend or just straight-up not working.
  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
 
 Updates what information to what?  resolv.conf should be more or less 
 invariant.

I was unclear.  Here I mean do whatever the config files say to do
which is either write resolv.conf, not touch resolv.conf at all
(dns

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 siddh...@redhat.com 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 sergio.pa...@gmail.com 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 p...@draigbrady.com 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 bnoc...@redhat.com 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
   mzerq...@0pointer.de 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: 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: 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 14:50 -0500, Nico Kadel-Garcia wrote:
 On Sun, Jan 25, 2015 at 12:40 PM, Adam Williamson
 adamw...@fedoraproject.org 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 name |
UUID 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: 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
  adamw...@fedoraproject.org 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
 adamw...@fedoraproject.org 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: 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: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=8044663name=build.logoffset=-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: 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=8044663name=build.logoffset=-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: 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 08:55 +0200, drago01 wrote:
 On Thu, Jun 19, 2014 at 8:59 PM, Jared K. Smith
 jsm...@fedoraproject.org wrote:
  On Thu, Jun 19, 2014 at 2:01 PM, Reindl Harald h.rei...@thelounge.net
  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: 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
  jsm...@fedoraproject.org wrote:
  On Thu, Jun 19, 2014 at 2:01 PM, Reindl Harald h.rei...@thelounge.net
  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: 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 d...@redhat.com wrote:
  On Tue, 2014-06-10 at 21:37 +0400, Igor Gnatenko wrote:
  On Tue, Jun 10, 2014 at 9:34 PM, Thomas Haller thal...@redhat.com 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 thal...@redhat.com 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 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 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 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 d...@redhat.com 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 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 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 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 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: 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 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:45 -0600, Kevin Fenzi wrote:
 On Fri, 11 Apr 2014 16:39:34 -0400 (EDT)
 Paul Wouters p...@nohats.ca 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: 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 awill...@redhat.com:
 
  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: 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 seb...@gmail.com 
  mailto:seb...@gmail.com 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: 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: 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 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 dav...@redhat.com 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: 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 dav...@redhat.com 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 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: 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
 mmarzantow...@osdf.com.pl 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:
 
 info (bridge0): IPv4 config waiting until carrier is on
 info (bridge0): IPv6 config waiting until carrier is on
 info 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:
 
 info (bridge0): IPv4 config waiting until carrier is on
 info (bridge0): IPv6 config waiting until carrier is on
 info 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 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: 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:
 
info (bridge0): IPv4 config waiting until carrier is on
info (bridge0): IPv6 config waiting until carrier is on
info 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: 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 errno.h)
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 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: 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: 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 o...@actcom.co.il 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=73UP,LOOPBACK,RUNNING  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 to...@pipebreaker.pl 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 jrez...@redhat.com 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

Re: F20 Self Contained Change: Plasma-nm

[Dan Williams]

On Tue, 2013-07-16 at 12:52 +0100, David Woodhouse wrote:
 On Tue, 2013-07-16 at 13:25 +0200, Jaroslav Reznik wrote:
  = Proposed Self Contained Change: Plasma-nm =
  https://fedoraproject.org/wiki/Changes/Plasma-nm
  
  Change owner(s): Jan Grulich jgrul...@redhat.com, Lukáš Tinkl 
  lti...@redhat.com 
  
  Replace current network applet in KDE with a new one and bring the latest 
  news 
  in NetworkManager to KDE. 
  
  == Detailed description ==
  Plasma-nm is a new plasma applet for network management in KDE which uses 
  the 
  latest KDE technologies. It supports all connection types from 
  NetworkManager 
  like bonding, bridging etc.
 
 ... and all types of VPN?

One thing we're going to be working on upstream is a more agnostic way
for VPN plugins to present their configuration UI, since there are
multiple things that need this information, including command-line
programs.  I'm not sure yet how that will get presented, but likely in
some form of UI description files that can be easily parsed by whatever
UI you've got and the widgets reconstructed.  We've come to the point
where it's increasingly hard to keep duplicating the UI logic every time
updated UI happens.  This would ideally help the KDE folks too as they
wouldn't have to write completely new VPN UI for each plugin.

Dan

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