Re: RFC authselect: mdns or mdns-minimal

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
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@xxxxxxxxxxxxxxxxxxxxxxx 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@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
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@xxxxxxxxxxxxxxxxxxxxxxx
Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Users]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]

  Powered by Linux