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@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
