[Test-Announce] Fedora 33 Beta Go/No-Go and Release Readiness meetings

[Ben Cotton]

Hi everyone,

It's that time already! The Fedora 33 Beta Go/No-Go[1] and Release
Readiness[2] meetings are scheduled for Thursday 10 September.

As a reminder, please update the Release Readiness page[3] with your
team's readiness if appropriate. We will use that to keep the Release
Readiness meeting short and focused.

[1] https://apps.fedoraproject.org/calendar/meeting/9804/?from_date=2020-09-07
[2] https://apps.fedoraproject.org/calendar/meeting/9805/
[3] https://fedoraproject.org/wiki/Release_Readiness

-- 
Ben Cotton
He / Him / His
Senior Program Manager, Fedora & CentOS Stream
Red Hat
TZ=America/Indiana/Indianapolis
_______________________________________________
test-announce mailing list -- test-announce(a)lists.fedoraproject.org
To unsubscribe send an email to test-announce-leave(a)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/[e-mail]...

[Test-Announce] Re: Fedora 33 Beta Go/No-Go and Release Readiness meetings

[Ben Cotton]

Due to outstanding unresolved blockers, there is no release candidate
for Fedora 33 Beta yet. I am cancelling tomorrow's Go/No-Go meeting.
The Release Readiness meeting *will be held* as scheduled[1]. Please
update the Release Readiness wiki page[2] with your team's readiness
if appropriate. We will use that to keep the Release Readiness meeting
short and focused.

The Fedora 33 Beta Go/No-Go meeting[3] will be held at 1700 UTC on
Thursday 17 September in #fedora-meeting-1. We will target the Beta
target date #1 milestone. The release schedule[5] has been updated
accordingly. This change does not impact the final release date.

 Help is wanted with any of the outstanding blockers.

[1] https://apps.fedoraproject.org/calendar/meeting/9805/
[2] https://fedoraproject.org/wiki/Release_Readiness
[3] https://apps.fedoraproject.org/calendar/meeting/9808/
[4] https://qa.fedoraproject.org/blockerbugs/milestone/33/beta/buglist
[5] https://fedorapeople.org/groups/schedule/f-33/f-33-key-tasks.html

-- 
Ben Cotton
He / Him / His
Senior Program Manager, Fedora & CentOS Stream
Red Hat
TZ=America/Indiana/Indianapolis
_______________________________________________
test-announce mailing list -- test-announce(a)lists.fedoraproject.org
To unsubscribe send an email to test-announce-leave(a)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/[e-mail]...

[Test-Announce] Re: Fedora 33 Beta Go/No-Go and Release Readiness meetings

[John M. Harris Jr]

On Wednesday, September 9, 2020 12:43:28 PM MST Ben Cotton wrote:
>  Due to outstanding unresolved blockers, there is no release
> candidate
>  for Fedora 33 Beta yet. I am cancelling tomorrow's Go/No-Go meeting.
>  The Release Readiness meeting *will be held* as scheduled[1]. Please
>  update the Release Readiness wiki page[2] with your team's readiness
>  if appropriate. We will use that to keep the Release Readiness meeting
>  short and focused.
>  
>  The Fedora 33 Beta Go/No-Go meeting[3] will be held at 1700 UTC on
>  Thursday 17 September in #fedora-meeting-1. We will target the Beta
>  target date #1 milestone. The release schedule[5] has been updated
>  accordingly. This change does not impact the final release date.
>  
>   Help is wanted with any of the outstanding blockers.
>  
>  [1] https://apps.fedoraproject.org/calendar/meeting/9805/
>  [2] https://fedoraproject.org/wiki/Release_Readiness
>  [3] https://apps.fedoraproject.org/calendar/meeting/9808/
>  [4] https://qa.fedoraproject.org/blockerbugs/milestone/33/beta/buglist
>  [5] https://fedorapeople.org/groups/schedule/f-33/f-33-key-tasks.html 
A quick reminder that we're about to release with the system configured to use 
Google DNS when no DNS servers are configured. If privacy is valued at all, 
this needs to be addressed before release.

-- 
John M. Harris, Jr.

[Test-Announce] Re: Fedora 33 Beta Go/No-Go and Release Readiness meetings

On Thu, 2020-09-10 at 01:02 -0700, John M. Harris Jr wrote:
>  
>  
>  A quick reminder that we're about to release with the system
>  configured to use 
>  Google DNS when no DNS servers are configured. If privacy is valued
>  at all, 
>  this needs to be addressed before release. 

These DNS addresses are bundled upstream in systemd. And they are used
in the event of a misconfiguration of your network settings, isn't it?
However they are easily customizable in /etc/systemd/resolved.conf
(FallbackDNS option)

And for the records: https://github.com/systemd/systemd/issues/8782

The same thing is true for system time and date (systemd default to
Google NTP servers). But as far as I can see it is already addressed
here
https://src.fedoraproject.org/rpms/systemd/blob/master/f/systemd.spec#_329


Ciao,
A.

[Test-Announce] Re: Fedora 33 Beta Go/No-Go and Release Readiness meetings

[Eugene Syromiatnikov]

On Thu, Sep 10, 2020 at 10:36:18AM +0200, alciregi(a)posteo.net wrote:
>  On Thu, 2020-09-10 at 01:02 -0700, John M. Harris Jr wrote:
>  > 
>  > 
>  > A quick reminder that we're about to release with the system
>  > configured to use 
>  > Google DNS when no DNS servers are configured. If privacy is valued
>  > at all, 
>  > this needs to be addressed before release.
>  
>  
>  These DNS addresses are bundled upstream in systemd. And they are used
>  in the event of a misconfiguration of your network settings, isn't it?
>  However they are easily customizable in /etc/systemd/resolved.conf
>  (FallbackDNS option) 
It's about the distribution's default setting, not a configuration possibility.

>  And for the records: https://github.com/systemd/systemd/issues/8782
>  
>  The same thing is true for system time and date (systemd default to
>  Google NTP servers). But as far as I can see it is already addressed
>  here
>  https://src.fedoraproject.org/rpms/systemd/blob/master/f/systemd.spec#_329 
I believe that it is the point of the John's e-mail: this issue is still
*not* addressed in Fedora.

[Test-Announce] Re: Fedora 33 Beta Go/No-Go and Release Readiness meetings

On Thu, 2020-09-10 at 12:06 +0200, Eugene Syromiatnikov wrote:
>  > 
>  > These DNS addresses are bundled upstream in systemd. And they are
>  > used
>  > in the event of a misconfiguration of your network settings, isn't
>  > it?
>  > However they are easily customizable in /etc/systemd/resolved.conf
>  > (FallbackDNS option)
>  
>  It's about the distribution's default setting, not a configuration
>  possibility. 
"Which servers are used (or any at all) as a fallback is a compile-time
as well as a runtime option. If you don't like the upstream defaults,
then please work with downstream to pick different options or make the
choices locally in your configuration files."

As a concerned user, you can configure the FallbackDNS option in
/etc/systemd/resolved.conf and put whatever DNS you prefer. Google and
so on will never be contacted.

Obviously the distribution can put different DNS in systemd at compile
time, or provide a default resolved.conf file where FallbackDNS is
uncommented and filled.


Ciao,
A.

[Test-Announce] Re: Fedora 33 Beta Go/No-Go and Release Readiness meetings

[Zbigniew Jędrzejewski-Szmek]

On Thu, Sep 10, 2020 at 01:27:30PM +0200, alciregi(a)posteo.net wrote:
>  On Thu, 2020-09-10 at 12:06 +0200, Eugene Syromiatnikov wrote:
>  > > 
>  > > These DNS addresses are bundled upstream in systemd. And they are
>  > > used
>  > > in the event of a misconfiguration of your network settings, isn't
>  > > it?
>  > > However they are easily customizable in /etc/systemd/resolved.conf
>  > > (FallbackDNS option)
>  > 
>  > It's about the distribution's default setting, not a configuration
>  > possibility.
>  
>  "Which servers are used (or any at all) as a fallback is a compile-time
>  as well as a runtime option. If you don't like the upstream defaults,
>  then please work with downstream to pick different options or make the
>  choices locally in your configuration files."
>  
>  As a concerned user, you can configure the FallbackDNS option in
>  /etc/systemd/resolved.conf and put whatever DNS you prefer. Google and
>  so on will never be contacted.
>  
>  Obviously the distribution can put different DNS in systemd at compile
>  time, or provide a default resolved.conf file where FallbackDNS is
>  uncommented and filled. 
Exactly. With my maintainer hat on: this is a non-issue. We consider
current defaults (a working fallback configuration out of the box that
has a very minor information leak) better than the proposed (a non-working
fallback configuration). If you need to, provide the trivial two-line dropin
file to override this locally.

Zbyszek

[Test-Announce] Re: Fedora 33 Beta Go/No-Go and Release Readiness meetings

[John M. Harris Jr]

On Thursday, September 10, 2020 4:42:24 AM MST Zbigniew Jędrzejewski-Szmek 
wrote:
>  On Thu, Sep 10, 2020 at 01:27:30PM +0200, alciregi(a)posteo.net wrote:
>  
>  > On Thu, 2020-09-10 at 12:06 +0200, Eugene Syromiatnikov wrote:
>  > 
>  > > > 
>  > > > These DNS addresses are bundled upstream in systemd. And they are
>  > > > used
>  > > > in the event of a misconfiguration of your network settings, isn't
>  > > > it?
>  > > > However they are easily customizable in /etc/systemd/resolved.conf
>  > > > (FallbackDNS option)
>  > > 
>  > > 
>  > > It's about the distribution's default setting, not a configuration
>  > > possibility.
>  > 
>  > 
>  > "Which servers are used (or any at all) as a fallback is a compile-time
>  > as well as a runtime option. If you don't like the upstream defaults,
>  > then please work with downstream to pick different options or make the
>  > choices locally in your configuration files."
>  > 
>  > As a concerned user, you can configure the FallbackDNS option in
>  > /etc/systemd/resolved.conf and put whatever DNS you prefer. Google and
>  > so on will never be contacted.
>  > 
>  > Obviously the distribution can put different DNS in systemd at compile
>  > time, or provide a default resolved.conf file where FallbackDNS is
>  > uncommented and filled.
>  
>  
>  Exactly. With my maintainer hat on: this is a non-issue. We consider
>  current defaults (a working fallback configuration out of the box that
>  has a very minor information leak) better than the proposed (a non-working
>  fallback configuration). If you need to, provide the trivial two-line
>  dropin file to override this locally. 
Zbyszek,

I'm definitely not suggesting something that is "non-working". That said,
not 
having any DNS servers configured indicates that remote lookup should not be 
used, not that a random DNS server should be picked by the resolver itself. 
When there are no DNS servers, the expected behavior is that no external 
servers are used for lookup.

-- 
John M. Harris, Jr.

[Test-Announce] Re: Fedora 33 Beta Go/No-Go and Release Readiness meetings

[Zbigniew Jędrzejewski-Szmek]

On Thu, Sep 10, 2020 at 06:37:56PM -0700, John M. Harris Jr wrote:
>  On Thursday, September 10, 2020 4:42:24 AM MST Zbigniew
> Jędrzejewski-Szmek 
>  wrote:
>  > On Thu, Sep 10, 2020 at 01:27:30PM +0200, alciregi(a)posteo.net wrote:
>  > 
>  > > On Thu, 2020-09-10 at 12:06 +0200, Eugene Syromiatnikov wrote:
>  > > 
>  > > > > 
>  > > > > These DNS addresses are bundled upstream in systemd. And they are
>  > > > > used
>  > > > > in the event of a misconfiguration of your network settings,
> isn't
>  > > > > it?
>  > > > > However they are easily customizable in /etc/systemd/resolved.conf
>  > > > > (FallbackDNS option)
>  > > > 
>  > > > 
>  > > > It's about the distribution's default setting, not a
> configuration
>  > > > possibility.
>  > > 
>  > > 
>  > > "Which servers are used (or any at all) as a fallback is a compile-time
>  > > as well as a runtime option. If you don't like the upstream defaults,
>  > > then please work with downstream to pick different options or make the
>  > > choices locally in your configuration files."
>  > > 
>  > > As a concerned user, you can configure the FallbackDNS option in
>  > > /etc/systemd/resolved.conf and put whatever DNS you prefer. Google and
>  > > so on will never be contacted.
>  > > 
>  > > Obviously the distribution can put different DNS in systemd at compile
>  > > time, or provide a default resolved.conf file where FallbackDNS is
>  > > uncommented and filled.
>  > 
>  > 
>  > Exactly. With my maintainer hat on: this is a non-issue. We consider
>  > current defaults (a working fallback configuration out of the box that
>  > has a very minor information leak) better than the proposed (a non-working
>  > fallback configuration). If you need to, provide the trivial two-line
>  > dropin file to override this locally.
>  
>  Zbyszek,
>  
>  I'm definitely not suggesting something that is "non-working". That said,
> not 
>  having any DNS servers configured indicates that remote lookup should not be 
>  used, not that a random DNS server should be picked by the resolver itself. 
>  When there are no DNS servers, the expected behavior is that no external 
>  servers are used for lookup. 
There are no environments where remote lookup SHOULD NOT not be used. There
are remote environments where it MUST NOT be used, and environments where it
is expected to work. For the former, just emptying /etc/resolv.conf is a halfway
measure that doesn't do enough so strong filtering with namespaces or routing
must be provided anyway. In the second case, we want to have working networking
(even if your local crappy dns router forgets to attach a dns server to the
dhcp lease or such).

Zbyszek

[Test-Announce] Re: Fedora 33 Beta Go/No-Go and Release Readiness meetings

[John M. Harris Jr]

On Thursday, September 10, 2020 10:38:51 PM MST Zbigniew Jędrzejewski-Szmek 
wrote:
>  On Thu, Sep 10, 2020 at 06:37:56PM -0700, John M. Harris Jr wrote:
>  
>  > On Thursday, September 10, 2020 4:42:24 AM MST Zbigniew Jędrzejewski-Szmek
>  >  
 wrote:
>  > 
>  > > On Thu, Sep 10, 2020 at 01:27:30PM +0200, alciregi(a)posteo.net wrote:
>  > > 
>  > > 
>  > > > On Thu, 2020-09-10 at 12:06 +0200, Eugene Syromiatnikov wrote:
>  > > > 
>  > > > 
>  > > > > > 
>  > > > > > These DNS addresses are bundled upstream in systemd. And they
> are
>  > > > > > used
>  > > > > > in the event of a misconfiguration of your network settings,
>  > > > > > isn't
>  > > > > > it?
>  > > > > > However they are easily customizable in
>  > > > > > /etc/systemd/resolved.conf
>  > > > > > (FallbackDNS option)
>  > > > > 
>  > > > > 
>  > > > > 
>  > > > > It's about the distribution's default setting, not a
> configuration
>  > > > > possibility.
>  > > > 
>  > > > 
>  > > > 
>  > > > "Which servers are used (or any at all) as a fallback is a
>  > > > compile-time
>  > > > as well as a runtime option. If you don't like the upstream defaults,
>  > > > then please work with downstream to pick different options or make
>  > > > the
>  > > > choices locally in your configuration files."
>  > > > 
>  > > > As a concerned user, you can configure the FallbackDNS option in
>  > > > /etc/systemd/resolved.conf and put whatever DNS you prefer. Google
>  > > > and
>  > > > so on will never be contacted.
>  > > > 
>  > > > Obviously the distribution can put different DNS in systemd at
>  > > > compile
>  > > > time, or provide a default resolved.conf file where FallbackDNS is
>  > > > uncommented and filled.
>  > > 
>  > > 
>  > > 
>  > > Exactly. With my maintainer hat on: this is a non-issue. We consider
>  > > current defaults (a working fallback configuration out of the box that
>  > > has a very minor information leak) better than the proposed (a
>  > > non-working
>  > > fallback configuration). If you need to, provide the trivial two-line
>  > > dropin file to override this locally.
>  > 
>  > 
>  > Zbyszek,
>  > 
>  > I'm definitely not suggesting something that is "non-working". That
> said,
>  > not  having any DNS servers configured indicates that remote lookup
>  > should not be used, not that a random DNS server should be picked by the
>  > resolver itself. When there are no DNS servers, the expected behavior is
>  > that no external servers are used for lookup.
>  
>  
>  There are no environments where remote lookup SHOULD NOT not be used. There
>  are remote environments where it MUST NOT be used, and environments where
>  it is expected to work. For the former, just emptying /etc/resolv.conf is a
>  halfway measure that doesn't do enough so strong filtering with namespaces
>  or routing must be provided anyway. In the second case, we want to have
>  working networking (even if your local crappy dns router forgets to attach
>  a dns server to the dhcp lease or such). 
When you have no configured DNS servers, remote lookup SHOULD NOT be used. 
Only local domain resolution should be used. This is how it has been for 
decades, and there's no reason to change this. That's expected functionality.

We have working networking even without DNS. If there are no DNS servers 
configured, no remote DNS servers should ever be contacted by the resolver.

-- 
John M. Harris, Jr.

[Test-Announce] Re: Fedora 33 Beta Go/No-Go and Release Readiness meetings

[Zbigniew Jędrzejewski-Szmek]

On Fri, Sep 11, 2020 at 01:55:54AM -0700, John M. Harris Jr wrote:
>  On Thursday, September 10, 2020 10:38:51 PM MST Zbigniew
> Jędrzejewski-Szmek 
>  wrote:
>  > On Thu, Sep 10, 2020 at 06:37:56PM -0700, John M. Harris Jr wrote:
>  > 
>  > > On Thursday, September 10, 2020 4:42:24 AM MST Zbigniew Jędrzejewski-Szmek
>  > > 
>   wrote:
>  > > 
>  > > > On Thu, Sep 10, 2020 at 01:27:30PM +0200, alciregi(a)posteo.net wrote:
>  > > > 
>  > > > 
>  > > > > On Thu, 2020-09-10 at 12:06 +0200, Eugene Syromiatnikov wrote:
>  > > > > 
>  > > > > 
>  > > > > > > 
>  > > > > > > These DNS addresses are bundled upstream in systemd. And
> they are
>  > > > > > > used
>  > > > > > > in the event of a misconfiguration of your network
> settings,
>  > > > > > > isn't
>  > > > > > > it?
>  > > > > > > However they are easily customizable in
>  > > > > > > /etc/systemd/resolved.conf
>  > > > > > > (FallbackDNS option)
>  > > > > > 
>  > > > > > 
>  > > > > > 
>  > > > > > It's about the distribution's default setting, not a
> configuration
>  > > > > > possibility.
>  > > > > 
>  > > > > 
>  > > > > 
>  > > > > "Which servers are used (or any at all) as a fallback is a
>  > > > > compile-time
>  > > > > as well as a runtime option. If you don't like the upstream
> defaults,
>  > > > > then please work with downstream to pick different options or make
>  > > > > the
>  > > > > choices locally in your configuration files."
>  > > > > 
>  > > > > As a concerned user, you can configure the FallbackDNS option in
>  > > > > /etc/systemd/resolved.conf and put whatever DNS you prefer. Google
>  > > > > and
>  > > > > so on will never be contacted.
>  > > > > 
>  > > > > Obviously the distribution can put different DNS in systemd at
>  > > > > compile
>  > > > > time, or provide a default resolved.conf file where FallbackDNS is
>  > > > > uncommented and filled.
>  > > > 
>  > > > 
>  > > > 
>  > > > Exactly. With my maintainer hat on: this is a non-issue. We consider
>  > > > current defaults (a working fallback configuration out of the box that
>  > > > has a very minor information leak) better than the proposed (a
>  > > > non-working
>  > > > fallback configuration). If you need to, provide the trivial two-line
>  > > > dropin file to override this locally.
>  > > 
>  > > 
>  > > Zbyszek,
>  > > 
>  > > I'm definitely not suggesting something that is "non-working".
> That said,
>  > > not  having any DNS servers configured indicates that remote lookup
>  > > should not be used, not that a random DNS server should be picked by the
>  > > resolver itself. When there are no DNS servers, the expected behavior is
>  > > that no external servers are used for lookup.
>  > 
>  > 
>  > There are no environments where remote lookup SHOULD NOT not be used. There
>  > are remote environments where it MUST NOT be used, and environments where
>  > it is expected to work. For the former, just emptying /etc/resolv.conf is a
>  > halfway measure that doesn't do enough so strong filtering with namespaces
>  > or routing must be provided anyway. In the second case, we want to have
>  > working networking (even if your local crappy dns router forgets to attach
>  > a dns server to the dhcp lease or such).
>  
>  When you have no configured DNS servers, remote lookup SHOULD NOT be used. 
>  Only local domain resolution should be used. This is how it has been for 
>  decades, and there's no reason to change this. That's expected functionality.
>  
>  We have working networking even without DNS. If there are no DNS servers 
>  configured, no remote DNS servers should ever be contacted by the resolver. 
You position is very clear. Let's agree to disagree.

Zbyszek

[Test-Announce] Re: Fedora 33 Beta Go/No-Go and Release Readiness meetings

[John M. Harris Jr]

On Thursday, September 10, 2020 4:27:30 AM MST alciregi(a)posteo.net wrote:
>  On Thu, 2020-09-10 at 12:06 +0200, Eugene Syromiatnikov wrote:
>  
>  > > 
>  > > These DNS addresses are bundled upstream in systemd. And they are
>  > > used
>  > > in the event of a misconfiguration of your network settings, isn't
>  > > it?
>  > > However they are easily customizable in /etc/systemd/resolved.conf
>  > > (FallbackDNS option)
>  > 
>  > 
>  > It's about the distribution's default setting, not a configuration
>  > possibility.
>  
>  
>  "Which servers are used (or any at all) as a fallback is a compile-time
>  as well as a runtime option. If you don't like the upstream defaults,
>  then please work with downstream to pick different options or make the
>  choices locally in your configuration files."
>  
>  As a concerned user, you can configure the FallbackDNS option in
>  /etc/systemd/resolved.conf and put whatever DNS you prefer. Google and
>  so on will never be contacted.
>  
>  Obviously the distribution can put different DNS in systemd at compile
>  time, or provide a default resolved.conf file where FallbackDNS is
>  uncommented and filled. 
It's important to note that this is also a major change in behavior. 
Currently, when no DNS servers are configured, your system will only perform 
local lookup, and will not look at an external DNS server.

-- 
John M. Harris, Jr.

[Test-Announce] Re: Fedora 33 Beta Go/No-Go and Release Readiness meetings

[John M. Harris Jr]

On Thursday, September 10, 2020 1:36:18 AM MST alciregi(a)posteo.net wrote:
>  On Thu, 2020-09-10 at 01:02 -0700, John M. Harris Jr wrote:
>  
>  > 
>  > 
>  > A quick reminder that we're about to release with the system
>  > configured to use 
>  > Google DNS when no DNS servers are configured. If privacy is valued
>  > at all, 
>  > this needs to be addressed before release.
>  
>  
>  
>  These DNS addresses are bundled upstream in systemd. And they are used
>  in the event of a misconfiguration of your network settings, isn't it?
>  However they are easily customizable in /etc/systemd/resolved.conf
>  (FallbackDNS option)
>  
>  And for the records: https://github.com/systemd/systemd/issues/8782
>  
>  The same thing is true for system time and date (systemd default to
>  Google NTP servers). But as far as I can see it is already addressed
>  here
>  https://src.fedoraproject.org/rpms/systemd/blob/master/f/systemd.spec#_329 
Regardless of Lennart's personal views, this is something that definitely 
merits some attention, and perhaps to be fixed before go-live. They're used 
whenever there are no configured DNS servers, not in the event of 
misconfiguration. Perhaps we should update /etc/systemd/resolved.conf to 
include "FallbackDNS=" system-wide? That would fix this behavior, for sure, 
and prevent the privacy issue for our users.

Why in the world would systemd have anything to do with NTP? We still use 
ntpd, do we not? Checking my system.. Nope, but it's chronyd. Still not 
systemd.

Also, looks like systemd is adding itself as a user and group database? This 
is probably a bug. Right?

https://src.fedoraproject.org/rpms/systemd/blob/master/f/systemd.spec#_655

-- 
John M. Harris, Jr.

[Test-Announce] Re: Fedora 33 Beta Go/No-Go and Release Readiness meetings

[Neal Gompa]

On Thu, Sep 10, 2020 at 9:34 PM John M. Harris Jr <johnmh(a)splentity.com&gt; wrote:
>  On Thursday, September 10, 2020 1:36:18 AM MST alciregi(a)posteo.net wrote:
>  > On Thu, 2020-09-10 at 01:02 -0700, John M. Harris Jr wrote:
>  >
>  > >
>  > >
>  > > A quick reminder that we're about to release with the system
>  > > configured to use
>  > > Google DNS when no DNS servers are configured. If privacy is valued
>  > > at all,
>  > > this needs to be addressed before release.
>  >
>  >
>  >
>  > These DNS addresses are bundled upstream in systemd. And they are used
>  > in the event of a misconfiguration of your network settings, isn't it?
>  > However they are easily customizable in /etc/systemd/resolved.conf
>  > (FallbackDNS option)
>  >
>  > And for the records: https://github.com/systemd/systemd/issues/8782
>  >
>  > The same thing is true for system time and date (systemd default to
>  > Google NTP servers). But as far as I can see it is already addressed
>  > here
>  > https://src.fedoraproject.org/rpms/systemd/blob/master/f/systemd.spec#_329
>
>  Regardless of Lennart's personal views, this is something that definitely
>  merits some attention, and perhaps to be fixed before go-live. They're used
>  whenever there are no configured DNS servers, not in the event of
>  misconfiguration. Perhaps we should update /etc/systemd/resolved.conf to
>  include "FallbackDNS=" system-wide? That would fix this behavior, for sure,
>  and prevent the privacy issue for our users.
>  
I'd rather have fallback DNS than no DNS by default.

>  Why in the world would systemd have anything to do with NTP? We still
> use
>  ntpd, do we not? Checking my system.. Nope, but it's chronyd. Still not
>  systemd.
>  
timesyncd is a simple NTP client for minimal Linux systems. We don't
use it, because chronyd is miles better.

>  Also, looks like systemd is adding itself as a user and group
> database? This
>  is probably a bug. Right?
>
>  https://src.fedoraproject.org/rpms/systemd/blob/master/f/systemd.spec#_655
>  
No. nss-systemd has been a thing for many years. It was added so that
DynamicUsers= functionality for systemd units would work.




--
真実はいつも一つ！/ Always, there's only one truth!

[Test-Announce] Re: Fedora 33 Beta Go/No-Go and Release Readiness meetings

On Thu, 2020-09-10 at 18:33 -0700, John M. Harris Jr wrote:
>  
>  Why in the world would systemd have anything to do with NTP? We still
>  use  
It has to do with NTP in the same degree it has to do with DNS.
Sure, we use chronyd. But, if I'm not wrong, if a user disables chronyd
and enable systemd-timesyncd, without configuring any NTP server,
systemd by default would fall back to Google NTP servers. But systemd
in Fedora is built to use 
FallbackNTPServers=0.fedora.pool.ntp.org 1.fedora.pool.ntp.org
2.fedora.pool.ntp.org 3.fedora.pool.ntp.org


Ciao,
A.

[Test-Announce] Re: Fedora 33 Beta Go/No-Go and Release Readiness meetings

[John M. Harris Jr]

On Thursday, September 10, 2020 11:56:25 PM MST alciregi(a)posteo.net wrote:
>  On Thu, 2020-09-10 at 18:33 -0700, John M. Harris Jr wrote:
>  
>  > 
>  > Why in the world would systemd have anything to do with NTP? We still
>  > use 
>  
>  
>  It has to do with NTP in the same degree it has to do with DNS.
>  Sure, we use chronyd. But, if I'm not wrong, if a user disables chronyd
>  and enable systemd-timesyncd, without configuring any NTP server,
>  systemd by default would fall back to Google NTP servers. But systemd
>  in Fedora is built to use 
>  FallbackNTPServers=0.fedora.pool.ntp.org 1.fedora.pool.ntp.org
>  2.fedora.pool.ntp.org 3.fedora.pool.ntp.org 
Sounds like a good change, which should be made for DNS as well. Still, the 
major difference here is that F33 is ditching the existing resolver for 
systemd's, so it'd be best to get it set up before shipping it..

-- 
John M. Harris, Jr.

[Test-Announce] Re: Fedora 33 Beta Go/No-Go and Release Readiness meetings

[Björn Persson]

John M. Harris Jr wrote:
>  On Thursday, September 10, 2020 11:56:25 PM MST alciregi(a)posteo.net
> wrote:
>  > But systemd in Fedora is built to use 
>  > FallbackNTPServers=0.fedora.pool.ntp.org 1.fedora.pool.ntp.org
>  > 2.fedora.pool.ntp.org 3.fedora.pool.ntp.org  
>  
>  Sounds like a good change, which should be made for DNS as well. 
So where is a global pool of volunteer-provided DNS resolvers similar
to pool.ntp.org? I've never heard of one, and I suspect it's not
advisable to do that with DNS.

Björn Persson

[Test-Announce] Re: Fedora 33 Beta Go/No-Go and Release Readiness meetings

[David Kaufmann]

On Fri, Sep 11, 2020 at 01:36:38PM +0200, Björn Persson wrote:
>  So where is a global pool of volunteer-provided DNS resolvers
> similar
>  to pool.ntp.org? I've never heard of one, and I suspect it's not
>  advisable to do that with DNS. 
There is currently no such thing that I know of, but lacking that the
next best thing is to also add other providers as FallbackDNS, so that
no single provider has all the requests for the machine.

e.g.:
FallbackDNS=8.8.8.8,9.9.9.10,1.1.1.1,208.67.222.222

I've included one address for the four big providers I know of, and (if
possible) the non-censoring variant.
I'm not sure if systemd uses them in a random order, but if it can this
would be preferable.

All the best,
David

[Test-Announce] Re: Fedora 33 Beta Go/No-Go and Release Readiness meetings

[John M. Harris Jr]

On Friday, September 11, 2020 4:36:38 AM MST Björn Persson wrote:
>  John M. Harris Jr wrote:
>  > On Thursday, September 10, 2020 11:56:25 PM MST alciregi(a)posteo.net wrote:
>  > > But systemd in Fedora is built to use
>  > > FallbackNTPServers=0.fedora.pool.ntp.org 1.fedora.pool.ntp.org
>  > > 2.fedora.pool.ntp.org 3.fedora.pool.ntp.org
>  > 
>  > Sounds like a good change, which should be made for DNS as well.
>  
>  So where is a global pool of volunteer-provided DNS resolvers similar
>  to pool.ntp.org? I've never heard of one, and I suspect it's not
>  advisable to do that with DNS. 
For DNS, I'm suggesting that "FallbackDNSServers=\n" should be added to the

configuration file. The only case where I can see no configured DNS servers 
being populated with preset DNS servers would be when DHCP is used, in which 
case, NetworkManager can be modified to include some logic for that. 
Otherwise, the system is actively acting against the interests of the user.

-- 
John M. Harris, Jr.