From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 72950 invoked by alias); 18 Sep 2017 15:27:35 -0000 Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libc-alpha-owner@sourceware.org Received: (qmail 72941 invoked by uid 89); 18 Sep 2017 15:27:35 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.2 spammy=18th, maintaining X-HELO: mail-qk0-f170.google.com X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=bhpMRqU6UF3dFfOWVmbC9NawKeEfNNSEsde4j29JoI0=; b=OaiWqhvQlikB4I07D07lkDbtnNMUOgz6OlffR5y0B91fueg1PlVprBxc2AN8YJ8mIQ dtAFqrlA6o0GWp8kyQ9TpEZZtwhwtj51PQMpya5/2vhJr/b96IKVCQiHjZaW8BnNBkpp 9ImqDzvMKtg8C5oL5hB8Qhg2YxSu+irZXY1Ns16JXMCVVBSke/qfH9T1yhow/PXTbvAD uuw2VwK5coW2VdRoNnmiEU8zNiE6Ze+SWSivaAkQPCu8EWzDNUtQF/ny9zEFV+B1pY91 pWxdPdeWW17bbMxuVRXXWDOawv0Bj1n9sIx6aQBbg2s6ipx5Crh8P+eqh+ojFdzeqPtS SYrw== X-Gm-Message-State: AHPjjUj8wxUwZXfUpNMGmqhzdHCAFPvTHqewK5K2GwEiJoHTI8RjefG6 4aOwezDJg4eFzKwQCuZ59w== X-Google-Smtp-Source: AOwi7QAyAjYnQjHKn3hHEIlWKmWjyJ9odR5kfArqbl7gOFCVX07tz6+im/swWlJV98u5OmiiWycrpw== X-Received: by 10.55.116.134 with SMTP id p128mr20835474qkc.50.1505748452098; Mon, 18 Sep 2017 08:27:32 -0700 (PDT) Subject: Re: [PATCH] resolv/resolv.h: allow alternative resolv.conf files To: Florian Weimer , Renzo Davoli , libc-alpha@sourceware.org References: <20170817115013.sepjn4aqfi3dlwje@cs.unibo.it> <2c02df5b-f7ce-dd9d-48f1-56cfd003f55d@redhat.com> From: Carlos O'Donell Message-ID: Date: Mon, 18 Sep 2017 15:27:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <2c02df5b-f7ce-dd9d-48f1-56cfd003f55d@redhat.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-SW-Source: 2017-09/txt/msg00686.txt.bz2 On 09/18/2017 09:12 AM, Florian Weimer wrote: > My main concern at this point is that a lot of software hard-codes > the /etc/resolv.conf path and parses the file on its own, to obtain > the search path and the configured name servers. > > Once we add an environment variable to change the path, that's going > to add a lot of confusion because the system will have an > inconsistent view on the data. I do not have a good answer to that. Restating my position from August 18th (up thread): Making there only be 1 way to set the resolver configuration makes it easier for application developers, and administrators to manage and develop such systems. The only remaining alternative is to have glibc become responsible for maintaining the consistency between /etc/resolv.conf and the env var. It would require hiding the difference to the application using one or other complex implementations e.g. mount namespace, hijacked open, etc. I don't see a good tradeoff between the value of the new feature and the complexity of the implementation. Higher level frameworks will likely already need mount namespaces for other reasons so it makes sense to delegate the normal system configuration to those frameworks. -- Cheers, Carlos.