Re: [PATCH 0/2] Fix nss/tst-nss-files-hosts-long on single-stack hosts (bug 24816)

[Carlos O'Donell <carlos@redhat.com>]

On Wed, Sep 14, 2022 at 11:54:47AM +0200, Florian Weimer wrote:
> * Carlos O'Donell:
> 
> > On Tue, Sep 13, 2022 at 04:35:39PM +0200, Florian Weimer via Libc-alpha wrote:
> >> Our Fedora builders started running the container tests (after the
> >> switch to systemd-nspawn), and we encountered this test failure as well.
> >> Fix this by disabling address configuration in the getent tool.
> >
> > Two things I'd like to discuss.
> >
> > (1) Change the getent default and drop AI_ADDRCONFIG.
> >
> > I'm hesitant to add a new option to getent as a solution to a testing
> > problem. The documented description for getent ahosts talks only
> > about enumerating the host entries or calling getaddrinfo with
> > AF_UNSPEC. Could we just change the default and ignore the host
> > configuration? This is less conservative but logically it seems to me
> > that we could just drop AI_ADDRCONFIG, and add a --addrconfig option to
> > get back the old behaviour. What could we possibly break?
> 
> I'm not sure why we would make such a backwards-incompatible change just
> to fix a test.  It sounds even more preposterous than adding the new
> option.

I fully agree that the most backwards compatible change is to add
an option that allows getent to operate without AI_ADDRCONFIG.

What I want to explore here is: Why use AI_ADDRCONFIG at all with
getent?

If our collective answer is: Because that's just the way we've always
done it and changing it would be a backwards incompatible change, then
I'm fine with that. I just wanted to explore that a bit.

I can see arguments both ways. I was looking for your opinion here.
My read of your opinion is that we should make the minimum backwards
compatible change.

> There have been support cases where the --no-addrconfig option would
> have been useful.  Today, getent isn't a great tool for diagnosing DNS
> issues, and I think this option improves the situation slightly.

That's a good point in favour of the new option.

> > (2) Fix the test.
> >
> > Alternatively the test should be checking to see if it is in a dual
> > stack environment or single stack environment and only call getent for
> > the specific case when such interfaces are enabled.
> >
> > Can we resolve this entirely in tst-nss-files-hosts-long?
> 
> I think it's futile to try to replicate the AI_ADDRCONFIG behavior in
> the test.

I did an audit and it looks like getent, and this specific test are
the only ones that we'd need cood like this for, and so there isn't
a win-win here with other tests.

Cheers,
Carlos.