This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH] resolv/resolv.h: allow alternative resolv.conf files
- From: Carlos O'Donell <carlos at redhat dot com>
- To: Florian Weimer <fweimer at redhat dot com>, Renzo Davoli <renzo at cs dot unibo dot it>, libc-alpha at sourceware dot org
- Date: Mon, 18 Sep 2017 09:27:29 -0600
- Subject: Re: [PATCH] resolv/resolv.h: allow alternative resolv.conf files
- Authentication-results: sourceware.org; auth=none
- References: <20170817115013.sepjn4aqfi3dlwje@cs.unibo.it> <2c02df5b-f7ce-dd9d-48f1-56cfd003f55d@redhat.com>
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.