From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by sourceware.org (Postfix) with ESMTPS id 44930384D1A5 for ; Wed, 14 Sep 2022 22:26:15 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 44930384D1A5 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=redhat.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1663194374; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=n2gcsu1pMNNlJMJ9gExhgjJd06IQxkO7x54cgsJdkF4=; b=fGg3u8sE8i7HQt54ywHNawFywFJkmnNRl5lHcTjVHXYswo7WUAXg5QbV6ntRU6In6oQiGQ 2hIYBNaYcYzybTB6dcrxmkjuxt5wmjQixrsLXKtLv62WJE9N4j34/fAKEpAPFHenSfqfj/ E6hZMY5K/N8chcL9xicazhDurC2XW8Q= Received: from mail-ed1-f71.google.com (mail-ed1-f71.google.com [209.85.208.71]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_128_GCM_SHA256) id us-mta-39-T7V148MkN6uxiP1GObb0mA-1; Wed, 14 Sep 2022 18:26:13 -0400 X-MC-Unique: T7V148MkN6uxiP1GObb0mA-1 Received: by mail-ed1-f71.google.com with SMTP id v11-20020a056402348b00b004516e0b7eedso8915187edc.8 for ; Wed, 14 Sep 2022 15:26:13 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date; bh=n2gcsu1pMNNlJMJ9gExhgjJd06IQxkO7x54cgsJdkF4=; b=vwUCSxjhxPMUzqgGS+SbY3l21CFG+k00u7DLuj8/Bn6KLdquxPOAzAVJMEd3avhmmG up4gQxjwxz/vBfXbwFSWu1S6F8GUFHfskCOzcGZT0aAaoGEWpv0UdiKD/SSVISq3WItY QJ3fDLW3Ys3tRw+Zo3npWt6mesUDsUrg7NdD+/5Su0dAFp7lBwMAuuO8nJ4tCV6MtGSs Hs1YT5qT0l8607I8oBBdQpKmZ6mrPn3Ubc/sFhPH7/lks3VNeG8XoLhVFBGn3tu7sgyD yELZbQB7Rad05ARzdShGjvcC+pWpAEP9dkN2c7MPZKZvOghL30EN6xL2jHFoAi4aVhVe IuIA== X-Gm-Message-State: ACgBeo0tw88U0ZWzRPngkrcDzl02CAj1Gl1k5vTp1IBvk7ijvoQM6r0l nELiKrRk/7vbssWYicFdDJaNyky1mDxjcJyP/rSzwPZHdKxQZ5W40LLj7/Sn5kbu08rEGA2ckDE 0vtRCIANloI7XmmggjLyQ X-Received: by 2002:a05:6402:1e8d:b0:441:58db:b6a2 with SMTP id f13-20020a0564021e8d00b0044158dbb6a2mr31470704edf.277.1663194372457; Wed, 14 Sep 2022 15:26:12 -0700 (PDT) X-Google-Smtp-Source: AA6agR7/VGa3pGVLepm19LIFFk0mYXVwsqgvaC7FXgLeJ+lqMabPxWn5REt2LMKcPX4bUsLSj/GZcA== X-Received: by 2002:a05:6402:1e8d:b0:441:58db:b6a2 with SMTP id f13-20020a0564021e8d00b0044158dbb6a2mr31470688edf.277.1663194372274; Wed, 14 Sep 2022 15:26:12 -0700 (PDT) Received: from fedora ([62.209.192.211]) by smtp.gmail.com with ESMTPSA id 9-20020a170906310900b00779cde476e4sm8122278ejx.62.2022.09.14.15.26.11 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 14 Sep 2022 15:26:11 -0700 (PDT) Date: Wed, 14 Sep 2022 18:26:10 -0400 From: Carlos O'Donell To: Florian Weimer Cc: libc-alpha@sourceware.org Subject: Re: [PATCH 0/2] Fix nss/tst-nss-files-hosts-long on single-stack hosts (bug 24816) Message-ID: References: <877d26e0wo.fsf@oldenburg.str.redhat.com> MIME-Version: 1.0 In-Reply-To: <877d26e0wo.fsf@oldenburg.str.redhat.com> X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Spam-Status: No, score=-6.3 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_LOW,SPF_HELO_NONE,SPF_NONE,TXREP,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: 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.