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.133.124]) by sourceware.org (Postfix) with ESMTPS id 09B83383FBB1 for ; Thu, 15 Sep 2022 12:38:02 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 09B83383FBB1 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=1663245481; 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=yHK64Xevy6zxrNY6cnJ5a7C8CxhIbYrBbhIJnpHtdKw=; b=R9hTTVp261gdjVfsIR3UFNUwjc2FOkqECkqdDIx15S83o4Z4G0rUHI3PiTtTJXM8LsM68b 3KZC8svAL5NjgX7RDN7079N9PKp+LVW7Ww1Qly/FeooJZSlDByvthsw7zb0YQ3P5SMUWTa auaqx7k3PZKiMjM7ODl3Kpgj/xS//G4= Received: from mimecast-mx02.redhat.com (mimecast-mx02.redhat.com [66.187.233.88]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-640-MczZ9SKKM8OgpD7bUKh3_A-1; Thu, 15 Sep 2022 08:38:00 -0400 X-MC-Unique: MczZ9SKKM8OgpD7bUKh3_A-1 Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.rdu2.redhat.com [10.11.54.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 11A238CEE26 for ; Thu, 15 Sep 2022 12:38:00 +0000 (UTC) Received: from oldenburg.str.redhat.com (unknown [10.39.194.198]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 7E9542166B26; Thu, 15 Sep 2022 12:37:59 +0000 (UTC) From: Florian Weimer To: Carlos O'Donell Cc: libc-alpha@sourceware.org Subject: Re: [PATCH 0/2] Fix nss/tst-nss-files-hosts-long on single-stack hosts (bug 24816) References: <877d26e0wo.fsf@oldenburg.str.redhat.com> Date: Thu, 15 Sep 2022 14:37:58 +0200 In-Reply-To: (Carlos O'Donell's message of "Wed, 14 Sep 2022 18:26:10 -0400") Message-ID: <87illoke3d.fsf@oldenburg.str.redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.2 (gnu/linux) MIME-Version: 1.0 X-Scanned-By: MIMEDefang 3.1 on 10.11.54.6 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain X-Spam-Status: No, score=-5.0 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 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: * Carlos O'Donell: > 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? I think it dates back when it was assumed that AI_ADDRCONFIG was useful. Back then, it looked like that if your system had IPv6 addresses configured, it could reach the entire IPv6 Internet. In practice, what applications should do is to get all addresses, always, and make connections in parallel over both address families. Filtering out addresses that are clearly unusable is just an optimization (but glibc isn't very good at that, getting the IPv6 support status of a host the way we do it can be very expensive, or give inaccurate results over time). > 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. Yeah, that too. getent ahosts is not really useful because of the address duplication. Thanks, Florian