Summary/Minutes from today's FESCo Meeting (2020-05-11)

[Igor Raits]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

=====================================
#fedora-meeting-1: FESCO (2020-05-11)
=====================================


Meeting started by ignatenkobrain at 15:03:42 UTC. The full logs are
available at
https://meetbot.fedoraproject.org/fedora-meeting-1/2020-05-11/fesco.2020-...
.



Meeting summary
- ---------------
* init process  (ignatenkobrain, 15:04:07)

* #2372 F33 Self-contained Change: Network Time Security
  (ignatenkobrain, 15:05:24)
  * ACTION: ignatenkobrain to contact change owners and clarify
anaconda
    part of the change.  (ignatenkobrain, 15:10:14)
  * AGREED: APPROVED (+9, ±0, -0)  (ignatenkobrain, 15:10:17)

* #2381 F33 System-Wide Change: systemd-resolved  (ignatenkobrain,
  15:10:20)
  * AGREED: APPROVED (+4, ±5, -0)  (ignatenkobrain, 15:18:40)
  * AGREED: APPROVED (+5, ±4, -0)  (ignatenkobrain, 15:20:51)
  * AGREED: APPROVED (+6, ±3, -0)  (ignatenkobrain, 15:21:23)

* Next week's chair  (ignatenkobrain, 15:21:27)
  * ACTION: sgallagh will chair next meeting  (ignatenkobrain,
15:22:24)

* Open Floor  (ignatenkobrain, 15:22:31)
  * ACTION: sgallagh to open a ticket to discuss abstention policy
    (sgallagh, 15:26:19)
  * LINK: https://hackmd.io/Eqsf5wFoQRGYhAVwSKJvIA is our running
    planning/tasks (but might be too detailed)  (nirik, 15:34:15)
  * LINK: 
https://bodhi.fedoraproject.org/updates/FEDORA-2020-2c6c85202d
    this is the update, which has upstream fixes  (bookwar, 15:48:58)
  * LINK: 
https://bodhi.fedoraproject.org/updates/FEDORA-2020-073c252157
    (nirik, 15:53:24)
  * ACTION: bookwar to discuss with Fedora QA how to cover runtime
    testing better  (ignatenkobrain, 16:01:06)

Meeting ended at 16:05:41 UTC.




Action Items
- ------------
* ignatenkobrain to contact change owners and clarify anaconda part of
  the change.
* sgallagh will chair next meeting
* sgallagh to open a ticket to discuss abstention policy
* bookwar to discuss with Fedora QA how to cover runtime testing better




Action Items, by person
- -----------------------
* bookwar
  * bookwar to discuss with Fedora QA how to cover runtime testing
    better
* ignatenkobrain
  * ignatenkobrain to contact change owners and clarify anaconda part
of
    the change.
* sgallagh
  * sgallagh will chair next meeting
  * sgallagh to open a ticket to discuss abstention policy
* **UNASSIGNED**
  * (none)




People Present (lines said)
- ---------------------------
* ignatenkobrain (71)
* bookwar (43)
* mhroncok (40)
* zbyszek (37)
* sgallagh (36)
* nirik (33)
* dcantrell (25)
* zodbot (22)
* decathorpe (7)
* bcotton (3)
* contyk (3)
* smooge (1)
* bookwar1 (1)




Generated by `MeetBot`_ 0.1.4

.. _`MeetBot`: http://wiki.debian.org/MeetBot
- -- 
Igor Raits <ignatenkobrain(a)fedoraproject.org&gt;
> -----BEGIN PGP SIGNATURE-----
>
> iQIzBAEBCgAdFiEEcwgJ58gsbV5f5dMcEV1auJxcHh4FAl65e3MACgkQEV1auJxc
> Hh4B+w/9FHtHZPycgzgyOeIzATes2zDuUxabvDTMyLFSl2Zs+q+XNYOmX01uohic
> +Pk2//vnQHVXkg1ptA5/gtiNnt9H4/Fjes4ScgRhysVjb+75dIB8wNmxh8URLxkF
> AAVY3wQm1/q3EQIpuOqVMFG8LfkjJ1idREu+7pfzvxxuAdEp3WnflC9B/zw79dYx
> iN1wJ1pjHO9e7vtGoKEBKeirH34isQg4fIJsInIUpc8yvwcGN2O2jSJwxqQv4Hwf
> L+EP6CV+tiEivxXXEXg65d6/CGQlHsAz2o1ctSex1w2c1rx3YlUAZRpZnYxsOJ9e
> JAf0LodtDv9WjBWzlxRHlH7tccoRcuE914KY5g6vfQLdaUeDySHp7O3sDSfHKucr
> d+LoJgbtywp0K1cuoM51fhDW3cyyYSnnMEZP2EtHtjuPQDePf+NrXp/jfyMzHRwo
> dn7s+5ADkljSnlxv8oWm+8415BK9jchTglHL07DpYeC5qjdioGU/vmnAfocw/GPy
> k0nMTuH0E3u5yu/ZDG6qXcqQ2Jm3Qoj4qRDSZ2qCn9zzPOzwimKZyZ0DR1q2OlDp
> CZpVinKCc5a0k0R419gZydXp+j+qHbm5IFMqmMwB3tFV6l/6+TCuowTznXzohKHx
> H3Rl2HNXcHrMtrgBhS/VuZEPfFLaan/0DBeC2wQhK10a2d9GZKA=
> =iux/
> -----END PGP SIGNATURE-----

[Chris Adams]

Once upon a time, Igor Raits <ignatenkobrain(a)fedoraproject.org&gt; said:
>  * #2381 F33 System-Wide Change: systemd-resolved  (ignatenkobrain,
>    15:10:20)
>    * AGREED: APPROVED (+4, ±5, -0)  (ignatenkobrain, 15:18:40)
>    * AGREED: APPROVED (+5, ±4, -0)  (ignatenkobrain, 15:20:51)
>    * AGREED: APPROVED (+6, ±3, -0)  (ignatenkobrain, 15:21:23) 
So, this is kind of annoying.  Last week's meeting had this as "Post
feedback on the devel list and restart discussion"... but that never
happened.

This change means applications will no longer be able to find the
working DNS servers for any kind of lookups not handled by systemd
(systemd-resolved is intentionally not a true DNS server).  The only
interface for that has been /etc/resolv.conf, but as I understand it,
that will go away (replaced with a stub that refers to 127.0.0.53).

If actual DNS servers are not going to be listed in /etc/resolv.conf,
then there needs to be a well-defined way for applications to discover
the current DNS servers.  resolv.conf has been the way to find DNS
servers for decades; dropping it (and with no clear replacement) is a
bad idea.

-- 
Chris Adams <linux(a)cmadams.net&gt;

[Zbigniew Jędrzejewski-Szmek]

On Mon, May 11, 2020 at 01:02:56PM -0500, Chris Adams wrote:
>  Once upon a time, Igor Raits <ignatenkobrain(a)fedoraproject.org&gt;
> said:
>  > * #2381 F33 System-Wide Change: systemd-resolved  (ignatenkobrain,
>  >   15:10:20)
>  >   * AGREED: APPROVED (+4, ±5, -0)  (ignatenkobrain, 15:18:40)
>  >   * AGREED: APPROVED (+5, ±4, -0)  (ignatenkobrain, 15:20:51)
>  >   * AGREED: APPROVED (+6, ±3, -0)  (ignatenkobrain, 15:21:23)
>  
>  So, this is kind of annoying.  Last week's meeting had this as "Post
>  feedback on the devel list and restart discussion"... but that never
>  happened.
>
>  This change means applications will no longer be able to find the
>  working DNS servers for any kind of lookups not handled by systemd
>  (systemd-resolved is intentionally not a true DNS server).  The only
>  interface for that has been /etc/resolv.conf, 
One of the purposes of this change is to have per-interface DNS
servers (so that split-DNS with VPN works). This means that the
"single list of DNS servers" doesn't actually describe reality any
more. So please note that even if we *do* provide a resolv.conf-style
file with some list of name servers, it is of limited use.

>  but as I understand it,
>  that will go away (replaced with a stub that refers to 127.0.0.53). 
Yep.
There's also /run/systemd/resolve/resolv.conf, where systemd-resolved
always exposes a list (with the limitations described above).

>  If actual DNS servers are not going to be listed in
> /etc/resolv.conf,
>  then there needs to be a well-defined way for applications to discover
>  the current DNS servers.  resolv.conf has been the way to find DNS
>  servers for decades; dropping it (and with no clear replacement) is a
>  bad idea. 
Is /run/systemd/resolve/resolv.conf good enough? Would a comment in
/etc/resolv.conf pointing the user to that file help?

Zbyszek

[Marius Schwarz]

Am 11.05.20 um 20:35 schrieb Zbigniew Jędrzejewski-Szmek:
>  Is /run/systemd/resolve/resolv.conf good enough? Would a comment in
>  /etc/resolv.conf pointing the user to that file help?
>  
Why not using a symlink from new to old resolve.conf?

This way old app will keep working and admins also do not need to dive
into systemds internals.

best regards,
Marius

[Zbigniew Jędrzejewski-Szmek]

On Mon, May 11, 2020 at 08:58:46PM +0200, Marius Schwarz wrote:
>  Am 11.05.20 um 20:35 schrieb Zbigniew Jędrzejewski-Szmek:
>  >
>  > Is /run/systemd/resolve/resolv.conf good enough? Would a comment in
>  > /etc/resolv.conf pointing the user to that file help?
>  >
>  Why not using a symlink from new to old resolve.conf? 
A symlink is already provided. /etc/resolv.conf symlinks to
/run/systemd/resolve/stub-resolv.conf. But that contains only 127.0.0.1,
and not the full list of DNS servers. (That is appropriate for an
application that wants to do some DNS resolution on its own, bypassing
the nss stack. But it is not enough for an application that wants to
know the "real" list of servers.)

>  This way old app will keep working and admins also do not need to
> dive
>  into systemds internals. 
Zbyszek

[Chris Adams]

Once upon a time, Zbigniew Jędrzejewski-Szmek <zbyszek(a)in.waw.pl&gt; said:
>  Yep. There's also /run/systemd/resolve/resolv.conf, where
> systemd-resolved
>  always exposes a list (with the limitations described above). 
I wasn't aware of that file... to me, that's a rather obscure location
(and I didn't find it mentioned anywhere in the change proposal).  I
think having it (or at least having it symlinked to by something) in the
more "usual" location, /etc, would be better.  Something like
/etc/resolv.conf.upstream?  I don't know, I'm really bad at naming
things. :)

And while I get that the multi-VPN thing is an important use case, I'd
also wager it's a fairly small use case, so not super important to the
people that want to query "real" DNS servers (which I grant is also a
small use case, but I'm just saying it's definitely non-zero and worth
considering).

Even better would be a standard location (and maybe even defaulting it
to be symlinked to /etc/resolv.conf if systemd-resolved is not in use),
plus trying to get upstreams for common utilities like "dig" to learn
about the alternate (at least with an easy-to-use option).

-- 
Chris Adams <linux(a)cmadams.net&gt;

[Zbigniew Jędrzejewski-Szmek]

On Mon, May 11, 2020 at 09:11:32PM -0500, Chris Adams wrote:
>  Once upon a time, Zbigniew Jędrzejewski-Szmek
> <zbyszek(a)in.waw.pl&gt; said:
>  > Yep. There's also /run/systemd/resolve/resolv.conf, where systemd-resolved
>  > always exposes a list (with the limitations described above).
>  
>  I wasn't aware of that file... to me, that's a rather obscure location
>  (and I didn't find it mentioned anywhere in the change proposal).  I
>  think having it (or at least having it symlinked to by something) in the
>  more "usual" location, /etc, would be better.  Something like
>  /etc/resolv.conf.upstream?  I don't know, I'm really bad at naming
>  things. :) 
The file is created dynamically at runtime, so symlinking from /etc has
the downside that you'd get a dangling symlink if systemd-resolved is not
running. The name would be "new" anyway, and we can document the name
under /run just as well as any name under /etc. So I don't think adding
a symlink in /etc/ is useful.

I added the following to the Change page:
https://fedoraproject.org/w/index.php?title=Changes%2Fsystemd-resolved&am...

>  And while I get that the multi-VPN thing is an important use case,
> I'd
>  also wager it's a fairly small use case, so not super important to the
>  people that want to query "real" DNS servers (which I grant is also a
>  small use case, but I'm just saying it's definitely non-zero and worth
>  considering). 
Right. Sadly dig doesn't seem to have an option to specify
resolv.conf
path, and host also doesn't. I guess it would be a useful addition esp.
in case of dig.

>  Even better would be a standard location (and maybe even defaulting
> it
>  to be symlinked to /etc/resolv.conf if systemd-resolved is not in use),
>  plus trying to get upstreams for common utilities like "dig" to learn
>  about the alternate (at least with an easy-to-use option). 
If systemd-resolved is
not in use, then most likely you want something
else to manage that file, e.g. NetworkManager. In other words, if
systemd-resolved is not "on", then we want to fall back to what we do
currently, and we don't want systemd-resolved to touch that file at
all.

Zbyszek