Re: RFC authselect: mdns or mdns-minimal
On 8/7/23 12:38, Pavel Březina wrote: IIUC, when 2228533 is resolved, I should switch from mdns[-|4|6]_minimal to mdns[-|4|6] and otherwise keep it as is? Yes. The order of the modules should be also kept: Current order is: hosts: files myhostname libvirt libvirt_guest mdns_minimal|mdns4_minimal|mdns6_minimal [NOTFOUND=return] resolve [!UNAVAIL=return] dns I wouldn't play with the order, because I don't understand it perfectly to make such decisions, so yes, keep the order as it is. Thanks, Pavel But I'm not a nss-mdns or avahi maintainer, just a maintainer of stacks which use mdns often - printing and scanning. I've got this opinion from issues in past, by checking nss-mdns code and by intention of minimizing of new work in authselect, unless it is necessary. Zdenek Yes, I admit current way of providing different plugins instead of one plugin with related configuration is unfortunate. Because it depends on avahi-daemon anyway, I hope it can be reduced to single plugin, where every customization can be done on side of avahi-daemon. But needs code modifications first, so waiting for a volunteer. -- Zdenek Dohnal Senior Software Engineer Red Hat, BRQ-TPBC ___ 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, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: RFC authselect: mdns or mdns-minimal
On 07. 08. 23 12:49, Dominik 'Rathann' Mierzejewski wrote:
On Tuesday, 01 August 2023 at 12:16, Petr Menšík wrote:
Hi Pavel,
With Avahi upstream maintainer hat on, I would say it still makes sense to
have separate mdns*_minimal and mdns? modules. I would say mdns
(non-minimal) should be rarely needed, because by default it should be used
just for *.local names. As I have wrote to referenced ticket, I think we
want to prefer mdns_minimal in the future, but it first needs solving
increased timeouts for not present names [1]. As soon as it is solved on
avahi-daemon side, we can deprecate mdns{4,6}_minimal and mdns{4,6}
variants. If only one family should be resolved, I think it would be better
to configure it on side of avahi-daemon.
Simpler is good if it still offers the features required by Fedora.
I think mdns resolution needs smarter approach from avahi-daemon. It might
be useful to not open and re-parse /etc/mdns.allow on every single
``getaddrinfo()`` call, but cache it in thread local storage and re-read its
contents only on timestamp change. Maybe with checking the file stamp only
once per second at most.
Isn't inotify what should be used in such cases?
Regards,
Dominik
inotify is good for such changes, but I would prefer having inotify
socket on side of avahi-daemon. I think inotify sockets are limited and
should not be used by every common client application using nss plugin
for resolution. Let alone by every thread. I think default limit of
inotify sockets is something around 256.
/proc/sys/fs/inotify/max_user_instances gives 128 on my f37. nss plugin
files reads /etc/hosts on every resolution too. I made the change to try
opening /etc/mdns.allow from every call therefore. I am not sure how
critical this file optimization might be.
I haven't found any good way to store cached structures after calls to
getaddrinfo() or getnameinfo(), which would be reasonably safe to use in
simple applications as well as threaded applications. It seems the way
how glibc handles /etc/resolv.conf is not simple to be reused by other
plugins. Cached structures might include allocated memory or any kind of
socket, including inotify. Maybe it is the correct way to rely on
filesystem caching and just call fopen() and fclose() on every name
resolution attempt. That is thread-safe and well supported, is
race-condition free.
res_ninit() call is able to open context for DNS resolution, but that is
available only fro DNS specific resolution. The abstract getaddrinfo()
or getnameinfo() have no way to open cache store on start and clean it
on thread stop or application exit. I think optimizations should be done
only if there is a correct way how to solve them. It seems to me
original nss plugin system does not offer something similar.
Cheers,
Petr
--
Petr Menšík
Software Engineer, RHEL
Red Hat, http://www.redhat.com/
PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB
___
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, report it:
https://pagure.io/fedora-infrastructure/new_issue
Re: RFC authselect: mdns or mdns-minimal
On Tuesday, 01 August 2023 at 12:16, Petr Menšík wrote:
> Hi Pavel,
>
> With Avahi upstream maintainer hat on, I would say it still makes sense to
> have separate mdns*_minimal and mdns? modules. I would say mdns
> (non-minimal) should be rarely needed, because by default it should be used
> just for *.local names. As I have wrote to referenced ticket, I think we
> want to prefer mdns_minimal in the future, but it first needs solving
> increased timeouts for not present names [1]. As soon as it is solved on
> avahi-daemon side, we can deprecate mdns{4,6}_minimal and mdns{4,6}
> variants. If only one family should be resolved, I think it would be better
> to configure it on side of avahi-daemon.
Simpler is good if it still offers the features required by Fedora.
> I think mdns resolution needs smarter approach from avahi-daemon. It might
> be useful to not open and re-parse /etc/mdns.allow on every single
> ``getaddrinfo()`` call, but cache it in thread local storage and re-read its
> contents only on timestamp change. Maybe with checking the file stamp only
> once per second at most.
Isn't inotify what should be used in such cases?
Regards,
Dominik
--
Fedora https://fedoraproject.org
There should be a science of discontent. People need hard times and
oppression to develop psychic muscles.
-- from "Collected Sayings of Muad'Dib" by the Princess Irulan
___
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, report it:
https://pagure.io/fedora-infrastructure/new_issue
Re: RFC authselect: mdns or mdns-minimal
On 8/2/23 17:04, Petr Menšík wrote: I have created upstream pull request, which makes non-minimal plugins to behave like minimal plugins except it tries to find /etc/mdns.allow. If that file does not exist, it copies also reverse queries from minimal plugin. Here: https://github.com/lathiat/nss-mdns/pull/89 On 02. 08. 23 9:15, Zdenek Dohnal wrote: On 8/1/23 12:41, Petr Menšík wrote: Hi Zdenek, the current logic is: - with-mdns4: mdns4_minimal - with-mdns6: mdns6_minimal - with-mdns4 and with-mdns6? mdns_minimal Ah, I have missed last part, that it uses mdns plugin for both queries. If I understand your message correctly, you propose to keep this logic but use mdns4/mdns6/mdns instead of minimal and drop support for minimal completely. Is that right? Thank, Pavel No, not at all. We want minimal variants preferred until nss-mdns is changes significantly. Check nss-mdns issue #88 [1]. 1. https://github.com/lathiat/nss-mdns/issues/88 Petr, this issue exists only if mdns.allow exists, so if we don't ship it as I recommend, we don't hit this issue. The file will be created by a user in case he needs to override settings which are against standards, where IMO a delay is tolerable. Thus, the issue is nice to have and should not block using mdns4/mdns6 variants. What I would support is adding a note into README file of nss-mdns, mentioning the delay due the mentioned bug - until it is fixed. So Pavel, I've understood me correctly - use mdns/mdns4/mdns6 instead of minimal variants, because they provide the same functionality as minimal + possibility to override network misconfigurations. And don't use complete 'mdns' by default. Okay, makes sense, once we include required changes into stable releases. I have created bug #2228533 to track this change, which once in stable, authselect might switch to non-minimal variants. IIUC, when 2228533 is resolved, I should switch from mdns[-|4|6]_minimal to mdns[-|4|6] and otherwise keep it as is? The order of the modules should be also kept: Current order is: hosts: files myhostname libvirt libvirt_guest mdns_minimal|mdns4_minimal|mdns6_minimal [NOTFOUND=return] resolve [!UNAVAIL=return] dns Thanks, Pavel But I'm not a nss-mdns or avahi maintainer, just a maintainer of stacks which use mdns often - printing and scanning. I've got this opinion from issues in past, by checking nss-mdns code and by intention of minimizing of new work in authselect, unless it is necessary. Zdenek Yes, I admit current way of providing different plugins instead of one plugin with related configuration is unfortunate. Because it depends on avahi-daemon anyway, I hope it can be reduced to single plugin, where every customization can be done on side of avahi-daemon. But needs code modifications first, so waiting for a volunteer. ___ 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, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: RFC authselect: mdns or mdns-minimal
I have created upstream pull request, which makes non-minimal plugins to behave like minimal plugins except it tries to find /etc/mdns.allow. If that file does not exist, it copies also reverse queries from minimal plugin. Here: https://github.com/lathiat/nss-mdns/pull/89 On 02. 08. 23 9:15, Zdenek Dohnal wrote: On 8/1/23 12:41, Petr Menšík wrote: Hi Zdenek, the current logic is: - with-mdns4: mdns4_minimal - with-mdns6: mdns6_minimal - with-mdns4 and with-mdns6? mdns_minimal Ah, I have missed last part, that it uses mdns plugin for both queries. If I understand your message correctly, you propose to keep this logic but use mdns4/mdns6/mdns instead of minimal and drop support for minimal completely. Is that right? Thank, Pavel No, not at all. We want minimal variants preferred until nss-mdns is changes significantly. Check nss-mdns issue #88 [1]. 1. https://github.com/lathiat/nss-mdns/issues/88 Petr, this issue exists only if mdns.allow exists, so if we don't ship it as I recommend, we don't hit this issue. The file will be created by a user in case he needs to override settings which are against standards, where IMO a delay is tolerable. Thus, the issue is nice to have and should not block using mdns4/mdns6 variants. What I would support is adding a note into README file of nss-mdns, mentioning the delay due the mentioned bug - until it is fixed. So Pavel, I've understood me correctly - use mdns/mdns4/mdns6 instead of minimal variants, because they provide the same functionality as minimal + possibility to override network misconfigurations. And don't use complete 'mdns' by default. Okay, makes sense, once we include required changes into stable releases. I have created bug #2228533 to track this change, which once in stable, authselect might switch to non-minimal variants. But I'm not a nss-mdns or avahi maintainer, just a maintainer of stacks which use mdns often - printing and scanning. I've got this opinion from issues in past, by checking nss-mdns code and by intention of minimizing of new work in authselect, unless it is necessary. Zdenek Yes, I admit current way of providing different plugins instead of one plugin with related configuration is unfortunate. Because it depends on avahi-daemon anyway, I hope it can be reduced to single plugin, where every customization can be done on side of avahi-daemon. But needs code modifications first, so waiting for a volunteer. -- Petr Menšík Software Engineer, RHEL Red Hat, http://www.redhat.com/ PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB ___ 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, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: RFC authselect: mdns or mdns-minimal
On 8/1/23 12:41, Petr Menšík wrote: Hi Zdenek, the current logic is: - with-mdns4: mdns4_minimal - with-mdns6: mdns6_minimal - with-mdns4 and with-mdns6? mdns_minimal If I understand your message correctly, you propose to keep this logic but use mdns4/mdns6/mdns instead of minimal and drop support for minimal completely. Is that right? Thank, Pavel No, not at all. We want minimal variants preferred until nss-mdns is changes significantly. Check nss-mdns issue #88 [1]. 1. https://github.com/lathiat/nss-mdns/issues/88 Petr, this issue exists only if mdns.allow exists, so if we don't ship it as I recommend, we don't hit this issue. The file will be created by a user in case he needs to override settings which are against standards, where IMO a delay is tolerable. Thus, the issue is nice to have and should not block using mdns4/mdns6 variants. What I would support is adding a note into README file of nss-mdns, mentioning the delay due the mentioned bug - until it is fixed. So Pavel, I've understood me correctly - use mdns/mdns4/mdns6 instead of minimal variants, because they provide the same functionality as minimal + possibility to override network misconfigurations. And don't use complete 'mdns' by default. But I'm not a nss-mdns or avahi maintainer, just a maintainer of stacks which use mdns often - printing and scanning. I've got this opinion from issues in past, by checking nss-mdns code and by intention of minimizing of new work in authselect, unless it is necessary. Zdenek -- Zdenek Dohnal Senior Software Engineer Red Hat, BRQ-TPBC ___ 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, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: RFC authselect: mdns or mdns-minimal
On 8/1/23 12:16, Petr Menšík wrote:
Hi Pavel,
With Avahi upstream maintainer hat on, I would say it still makes
sense to have separate mdns*_minimal and mdns? modules. I would say
mdns (non-minimal) should be rarely needed, because by default it
should be used just for *.local names.
I would expect there can be network setups which aren't according
standards and normal users are not able to change it, so it would be
great to have a way how to setup an override in default configuration
instead of expecting authselect to provide 3 more profile features for
no relevant gain so far I can see it.
I've looked into nss-mdns code about what are differences between full
and _minimal except for mdns.allow support and I found a difference in a
function (_nss_mdns_gethostbyaddr_r()) is only used on FreeBSD,
otherwise they're the same.
If there is not, I don't see an important reason why don't use full
variants (I don't mean full in meaning IPv support, but regarding
not-minimal) - the file won't exist in 99% (rhetorically speaking) of
configurations, so it won't be read and
https://github.com/lathiat/nss-mdns/issues/88 is irrelevant in those cases.
In the cases where it will exist, then there is something against
standards in local network configuration, so IMO a delay is tolerable.
As I have wrote to referenced ticket, I think we want to prefer
mdns_minimal in the future, but it first needs solving increased
timeouts for not present names [1]. As soon as it is solved on
avahi-daemon side, we can deprecate mdns{4,6}_minimal and mdns{4,6}
variants. If only one family should be resolved, I think it would be
better to configure it on side of avahi-daemon.
Since there is no solution for it now, I repeat my previous answer
regarding this - no profile feature in authselect for this, do not set
plain mdns/mdns_minimal as default, if someone wants it, he can enable
it by enabling both --with-mdns4 and --with-mdns6.
I think mdns resolution needs smarter approach from avahi-daemon. It
might be useful to not open and re-parse /etc/mdns.allow on every
single ``getaddrinfo()`` call, but cache it in thread local storage
and re-read its contents only on timestamp change. Maybe with checking
the file stamp only once per second at most.
An alternative approach might be fetching list of wanted domains first
time the process uses mdns plugin from avahi-daemon. And cache it in
thread local storage of the process (with some ttl before refresh).
That would avoid separate mdns?_minimal and mdns? plugins, because the
smartness would be at avahi-daemon. That is required for any
combination anyway. No slowing down unrelated queries after the first
one. I guess that would make browser people happy, because they try
hard to make everything quite fast. Wrote new issue [2] for this idea.
IMO this is nice to have fix, because of reasons above.
So a quick summary. I am afraid all those variants are needed until
some volunteer improves the situation and makes them obsolete. I think
we are not there yet.
I beg to differ here - there is no downside for majority of user by
supporting full variants mdns4/mdns6 in authselect by default instead of
_minimal (if the file won't be shipped by default, which I highly
recommend to not ship to get '_minimal' behavior by default) and IMO it
is tolerable to have a delay for setups which don't follow standards.
AFAIK this solution has the following pros:
- no new profile features for authselect,
- _minimal behavior by default,
- having a way how to override default without changing authselect
settings in case there are discrepancies in network
Cons:
- delay if /etc/mdns.allow exists
Zdenek
Cheers,
Petr
1. https://github.com/lathiat/nss-mdns/issues/83
2. https://github.com/lathiat/nss-mdns/issues/88
On 31. 07. 23 14:47, Pavel Březina wrote:
Hi Fedora,
I have this ticket opened against authselect:
https://github.com/authselect/authselect/issues/334
I am not user of mdns myself, so I wonder if non-minimal version of
mdns is something used and if it should be included in the authselect
profiles (or even replace the minimal version).
mdns support is already complicated since there are mdns, mdns4 and
mdns6 full and minimal versions of the module. Is it really required
nowadays? In might opinion, it might be good to move the logic out of
nsswitch into a configuration file.
Thank you for your feedback,
Pavel.
___
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, report it:
https://pagure.io/fedora-infrastructure/new_issue
--
Zdenek Dohnal
Senior
Re: RFC authselect: mdns or mdns-minimal
On 8/1/23 12:41, Petr Menšík wrote: No, I am afraid that is not gist of that response. We still want mdns4_minimal to be preferred variant and others to be configurable manually. Sadly, they are all still needed, with minimal variants preferred. and also --with-mdns should be possible in addition to existing 4 and 6 variants. On 01. 08. 23 12:10, Pavel Březina wrote: On 8/1/23 09:56, Zdenek Dohnal wrote: Hi Pavel, since authselect already advertises features for profiles regarding mdns as: --with-mdns4 --with-mdns6 it would be great if the profile feature logically matched what is going to be enabled - --with-mdn4 will put 'mdns4' into 'hosts' in nsswitch.conf instead of current mdns_minimal. AFAIK from Avahi people (pemensik in CC) I wouldn't go for mdns and mdns_minimal, because hostname->IPv6 + hostname->IPv4 address resolutions are currently made in sequence in Avahi, so the getting the result will be unnecessary delayed if one of them is not defined. IIUC nss-mdns README, the main difference between mdns4 and mdns4_minimal is /etc/mdns.allow file support, which can allow bypassing heuristics and allows user to do mDNS queries in conflict to mDNS standard (f.e. standard specifies that only .local or .local. domains can be used for mDNS) - although it would be great if networks were up to the standards, it is not a case in reality. We had this issue https://bugzilla.redhat.com/show_bug.cgi?id=2148500 , where ISP injected DNS server which defined 'local' domain as classic DNS record, breaking mDNS resolution in whole user's environment. Fortunately Petr came up with solution for it (now nss-mdns does always mDNS lookup for .local, but if there is DNS SOA for .local and mDNS lookup didn't succeed, moves to DNS), so this scenario doesn't need mdns.allow anymore, but IMO there could be other divergence from standards in the networks, so having the option to use mdns.allow in default configuration is welcome. So what I would propose: - use mdns4/mdns6 with authselect --with-mdns4 and --with-mdns6 profile features instead of _minimal to honor name logic, - don't use mdns/mdns_minimal - if someone wants to use it, he can enable both features separately, - if someone would like to use mdns4/6_minimal, he can opt-out from authselect and update nsswitch.conf manually. @Adam, @Petr, please let me know if there are other things to consider or disadvantages in this. Hi Zdenek, the current logic is: - with-mdns4: mdns4_minimal - with-mdns6: mdns6_minimal - with-mdns4 and with-mdns6? mdns_minimal Where exactly are those variants documented? I have looked into man authselect, but failed any word on mdns. How can I check how authselect presents them, please? Anything better than command: $ authselect list-features minimal You want `authselect show sssd` If I understand your message correctly, you propose to keep this logic but use mdns4/mdns6/mdns instead of minimal and drop support for minimal completely. Is that right? Thank, Pavel No, not at all. We want minimal variants preferred until nss-mdns is changes significantly. Check nss-mdns issue #88 [1]. 1. https://github.com/lathiat/nss-mdns/issues/88 ___ 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, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: RFC authselect: mdns or mdns-minimal
No, I am afraid that is not gist of that response. We still want mdns4_minimal to be preferred variant and others to be configurable manually. Sadly, they are all still needed, with minimal variants preferred. and also --with-mdns should be possible in addition to existing 4 and 6 variants. On 01. 08. 23 12:10, Pavel Březina wrote: On 8/1/23 09:56, Zdenek Dohnal wrote: Hi Pavel, since authselect already advertises features for profiles regarding mdns as: --with-mdns4 --with-mdns6 it would be great if the profile feature logically matched what is going to be enabled - --with-mdn4 will put 'mdns4' into 'hosts' in nsswitch.conf instead of current mdns_minimal. AFAIK from Avahi people (pemensik in CC) I wouldn't go for mdns and mdns_minimal, because hostname->IPv6 + hostname->IPv4 address resolutions are currently made in sequence in Avahi, so the getting the result will be unnecessary delayed if one of them is not defined. IIUC nss-mdns README, the main difference between mdns4 and mdns4_minimal is /etc/mdns.allow file support, which can allow bypassing heuristics and allows user to do mDNS queries in conflict to mDNS standard (f.e. standard specifies that only .local or .local. domains can be used for mDNS) - although it would be great if networks were up to the standards, it is not a case in reality. We had this issue https://bugzilla.redhat.com/show_bug.cgi?id=2148500 , where ISP injected DNS server which defined 'local' domain as classic DNS record, breaking mDNS resolution in whole user's environment. Fortunately Petr came up with solution for it (now nss-mdns does always mDNS lookup for .local, but if there is DNS SOA for .local and mDNS lookup didn't succeed, moves to DNS), so this scenario doesn't need mdns.allow anymore, but IMO there could be other divergence from standards in the networks, so having the option to use mdns.allow in default configuration is welcome. So what I would propose: - use mdns4/mdns6 with authselect --with-mdns4 and --with-mdns6 profile features instead of _minimal to honor name logic, - don't use mdns/mdns_minimal - if someone wants to use it, he can enable both features separately, - if someone would like to use mdns4/6_minimal, he can opt-out from authselect and update nsswitch.conf manually. @Adam, @Petr, please let me know if there are other things to consider or disadvantages in this. Hi Zdenek, the current logic is: - with-mdns4: mdns4_minimal - with-mdns6: mdns6_minimal - with-mdns4 and with-mdns6? mdns_minimal Where exactly are those variants documented? I have looked into man authselect, but failed any word on mdns. How can I check how authselect presents them, please? Anything better than command: $ authselect list-features minimal If I understand your message correctly, you propose to keep this logic but use mdns4/mdns6/mdns instead of minimal and drop support for minimal completely. Is that right? Thank, Pavel No, not at all. We want minimal variants preferred until nss-mdns is changes significantly. Check nss-mdns issue #88 [1]. 1. https://github.com/lathiat/nss-mdns/issues/88 -- Petr Menšík Software Engineer, RHEL Red Hat, http://www.redhat.com/ PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB ___ 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, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: RFC authselect: mdns or mdns-minimal
Hi Pavel,
With Avahi upstream maintainer hat on, I would say it still makes sense
to have separate mdns*_minimal and mdns? modules. I would say mdns
(non-minimal) should be rarely needed, because by default it should be
used just for *.local names. As I have wrote to referenced ticket, I
think we want to prefer mdns_minimal in the future, but it first needs
solving increased timeouts for not present names [1]. As soon as it is
solved on avahi-daemon side, we can deprecate mdns{4,6}_minimal and
mdns{4,6} variants. If only one family should be resolved, I think it
would be better to configure it on side of avahi-daemon.
I think mdns resolution needs smarter approach from avahi-daemon. It
might be useful to not open and re-parse /etc/mdns.allow on every single
``getaddrinfo()`` call, but cache it in thread local storage and re-read
its contents only on timestamp change. Maybe with checking the file
stamp only once per second at most.
An alternative approach might be fetching list of wanted domains first
time the process uses mdns plugin from avahi-daemon. And cache it in
thread local storage of the process (with some ttl before refresh). That
would avoid separate mdns?_minimal and mdns? plugins, because the
smartness would be at avahi-daemon. That is required for any combination
anyway. No slowing down unrelated queries after the first one. I guess
that would make browser people happy, because they try hard to make
everything quite fast. Wrote new issue [2] for this idea.
So a quick summary. I am afraid all those variants are needed until some
volunteer improves the situation and makes them obsolete. I think we are
not there yet.
Cheers,
Petr
1. https://github.com/lathiat/nss-mdns/issues/83
2. https://github.com/lathiat/nss-mdns/issues/88
On 31. 07. 23 14:47, Pavel Březina wrote:
Hi Fedora,
I have this ticket opened against authselect:
https://github.com/authselect/authselect/issues/334
I am not user of mdns myself, so I wonder if non-minimal version of
mdns is something used and if it should be included in the authselect
profiles (or even replace the minimal version).
mdns support is already complicated since there are mdns, mdns4 and
mdns6 full and minimal versions of the module. Is it really required
nowadays? In might opinion, it might be good to move the logic out of
nsswitch into a configuration file.
Thank you for your feedback,
Pavel.
___
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, report it:
https://pagure.io/fedora-infrastructure/new_issue
--
Petr Menšík
Software Engineer, RHEL
Red Hat, http://www.redhat.com/
PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB
___
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, report it:
https://pagure.io/fedora-infrastructure/new_issue
Re: RFC authselect: mdns or mdns-minimal
On 8/1/23 03:46, Adam Williamson wrote: On Mon, 2023-07-31 at 14:47 +0200, Pavel Březina wrote: Hi Fedora, I have this ticket opened against authselect: https://github.com/authselect/authselect/issues/334 I am not user of mdns myself, so I wonder if non-minimal version of mdns is something used and if it should be included in the authselect profiles (or even replace the minimal version). mdns support is already complicated since there are mdns, mdns4 and mdns6 full and minimal versions of the module. Is it really required nowadays? In might opinion, it might be good to move the logic out of nsswitch into a configuration file. If mdns is the thing that lets me just do 'ssh somehostname.local' to reach that host on my local network, then yes, I use it. I have no idea what configuration it should have, except that that should work OOTB, IMHO. By configuration, I meant to choose between minimal and full versions and ipv4 and ipv6 via configuration file and have single nss module instead of having 6 different modules that you need to choose from in nsswitch.conf. Thanks, Pavel ___ 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, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: RFC authselect: mdns or mdns-minimal
On 8/1/23 09:56, Zdenek Dohnal wrote: Hi Pavel, since authselect already advertises features for profiles regarding mdns as: --with-mdns4 --with-mdns6 it would be great if the profile feature logically matched what is going to be enabled - --with-mdn4 will put 'mdns4' into 'hosts' in nsswitch.conf instead of current mdns_minimal. AFAIK from Avahi people (pemensik in CC) I wouldn't go for mdns and mdns_minimal, because hostname->IPv6 + hostname->IPv4 address resolutions are currently made in sequence in Avahi, so the getting the result will be unnecessary delayed if one of them is not defined. IIUC nss-mdns README, the main difference between mdns4 and mdns4_minimal is /etc/mdns.allow file support, which can allow bypassing heuristics and allows user to do mDNS queries in conflict to mDNS standard (f.e. standard specifies that only .local or .local. domains can be used for mDNS) - although it would be great if networks were up to the standards, it is not a case in reality. We had this issue https://bugzilla.redhat.com/show_bug.cgi?id=2148500 , where ISP injected DNS server which defined 'local' domain as classic DNS record, breaking mDNS resolution in whole user's environment. Fortunately Petr came up with solution for it (now nss-mdns does always mDNS lookup for .local, but if there is DNS SOA for .local and mDNS lookup didn't succeed, moves to DNS), so this scenario doesn't need mdns.allow anymore, but IMO there could be other divergence from standards in the networks, so having the option to use mdns.allow in default configuration is welcome. So what I would propose: - use mdns4/mdns6 with authselect --with-mdns4 and --with-mdns6 profile features instead of _minimal to honor name logic, - don't use mdns/mdns_minimal - if someone wants to use it, he can enable both features separately, - if someone would like to use mdns4/6_minimal, he can opt-out from authselect and update nsswitch.conf manually. @Adam, @Petr, please let me know if there are other things to consider or disadvantages in this. Hi Zdenek, the current logic is: - with-mdns4: mdns4_minimal - with-mdns6: mdns6_minimal - with-mdns4 and with-mdns6? mdns_minimal If I understand your message correctly, you propose to keep this logic but use mdns4/mdns6/mdns instead of minimal and drop support for minimal completely. Is that right? Thank, Pavel ___ 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, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: RFC authselect: mdns or mdns-minimal
On 8/1/23 09:56, Zdenek Dohnal wrote: Fortunately Petr came up with solution for it (now nss-mdns does always mDNS lookup for .local, but if there is DNS SOA for .local and mDNS lookup didn't succeed, moves to DNS), so this scenario doesn't need mdns.allow anymore, but IMO there could be other divergence from standards in the networks, so having the option to use mdns.allow in default configuration is welcome. Of course, the bypassing would be turned off by default (nss-mdns will not ship any /etc/mdns.allow file), so mDNS resolution would have worked according standards by default. User will be expected to create the file and make necessary changes if he needs to. -- Zdenek Dohnal Senior Software Engineer Red Hat, BRQ-TPBC ___ 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, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: RFC authselect: mdns or mdns-minimal
Hi Pavel, since authselect already advertises features for profiles regarding mdns as: --with-mdns4 --with-mdns6 it would be great if the profile feature logically matched what is going to be enabled - --with-mdn4 will put 'mdns4' into 'hosts' in nsswitch.conf instead of current mdns_minimal. AFAIK from Avahi people (pemensik in CC) I wouldn't go for mdns and mdns_minimal, because hostname->IPv6 + hostname->IPv4 address resolutions are currently made in sequence in Avahi, so the getting the result will be unnecessary delayed if one of them is not defined. IIUC nss-mdns README, the main difference between mdns4 and mdns4_minimal is /etc/mdns.allow file support, which can allow bypassing heuristics and allows user to do mDNS queries in conflict to mDNS standard (f.e. standard specifies that only .local or .local. domains can be used for mDNS) - although it would be great if networks were up to the standards, it is not a case in reality. We had this issue https://bugzilla.redhat.com/show_bug.cgi?id=2148500 , where ISP injected DNS server which defined 'local' domain as classic DNS record, breaking mDNS resolution in whole user's environment. Fortunately Petr came up with solution for it (now nss-mdns does always mDNS lookup for .local, but if there is DNS SOA for .local and mDNS lookup didn't succeed, moves to DNS), so this scenario doesn't need mdns.allow anymore, but IMO there could be other divergence from standards in the networks, so having the option to use mdns.allow in default configuration is welcome. So what I would propose: - use mdns4/mdns6 with authselect --with-mdns4 and --with-mdns6 profile features instead of _minimal to honor name logic, - don't use mdns/mdns_minimal - if someone wants to use it, he can enable both features separately, - if someone would like to use mdns4/6_minimal, he can opt-out from authselect and update nsswitch.conf manually. @Adam, @Petr, please let me know if there are other things to consider or disadvantages in this. Zdenek On 7/31/23 14:47, Pavel Březina wrote: Hi Fedora, I have this ticket opened against authselect: https://github.com/authselect/authselect/issues/334 I am not user of mdns myself, so I wonder if non-minimal version of mdns is something used and if it should be included in the authselect profiles (or even replace the minimal version). mdns support is already complicated since there are mdns, mdns4 and mdns6 full and minimal versions of the module. Is it really required nowadays? In might opinion, it might be good to move the logic out of nsswitch into a configuration file. Thank you for your feedback, Pavel. ___ 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, report it: https://pagure.io/fedora-infrastructure/new_issue -- Zdenek Dohnal Senior Software Engineer Red Hat, BRQ-TPBC ___ 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, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: RFC authselect: mdns or mdns-minimal
On Mon, 2023-07-31 at 14:47 +0200, Pavel Březina wrote: > Hi Fedora, > I have this ticket opened against authselect: > https://github.com/authselect/authselect/issues/334 > > I am not user of mdns myself, so I wonder if non-minimal version of mdns > is something used and if it should be included in the authselect > profiles (or even replace the minimal version). > > mdns support is already complicated since there are mdns, mdns4 and > mdns6 full and minimal versions of the module. Is it really required > nowadays? In might opinion, it might be good to move the logic out of > nsswitch into a configuration file. If mdns is the thing that lets me just do 'ssh somehostname.local' to reach that host on my local network, then yes, I use it. I have no idea what configuration it should have, except that that should work OOTB, IMHO. -- Adam Williamson (he/him/his) Fedora QA Fedora Chat: @adamwill:fedora.im | Mastodon: @ad...@fosstodon.org https://www.happyassassin.net ___ 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, report it: https://pagure.io/fedora-infrastructure/new_issue
RFC authselect: mdns or mdns-minimal
Hi Fedora, I have this ticket opened against authselect: https://github.com/authselect/authselect/issues/334 I am not user of mdns myself, so I wonder if non-minimal version of mdns is something used and if it should be included in the authselect profiles (or even replace the minimal version). mdns support is already complicated since there are mdns, mdns4 and mdns6 full and minimal versions of the module. Is it really required nowadays? In might opinion, it might be good to move the logic out of nsswitch into a configuration file. Thank you for your feedback, Pavel. ___ 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, report it: https://pagure.io/fedora-infrastructure/new_issue
