This is the mail archive of the
mailing list for the glibc project.
Re: [PATCH] resolv/resolv.h: allow alternative resolv.conf files
I have released userbindconf, a library and a utility command to
bind-mount files and directores in user-namespaces.
Nevertheless, the whole stuff sounds as a workaround to me.
On Fri, Aug 18, 2017 at 12:41:50PM -0400, Carlos O'Donell wrote:
> On 08/18/2017 11:07 AM, Renzo Davoli wrote:
> > It seems a bizantine procedure just to tell resolv to use a different
> > resolv.conf.
> I agree, but that's not the extent of this...
> > There is some extra work for the kernel (keep track of the new
> > namespaces, separate mounttables, more mount items) for a problem
> > that could be solved entirely at user level.
> Yes, you are right.
> You are paying the cost for a design abstraction.
> Design abstractions make it easier for your users to know how your
> systems work without needing to learn something new e.g. a new
> environment variable.
An abstraction should be a simple concept able to represent a wide
range of situations. Astractions should be simpler than the
Using complicated methods to override a lack of generalization of
the lower layer is more a "distraction" than an "abstraction".
There are several environment variables already in glibc to
configure the name resolving process:
RES_OPTIONS, RESOLV_ADD_TRIM_DOMAINS RESOLV_MULTI
What to say about:
It redefines the path to be used instead of /etc/host.conf.
Isn't this very close to what I proposed as PATH_RESCONF?
(which could be renamed as RESOLV_RESCONF to be consistent
with the others).
Is there really the need for a user-namespace for a so simple
(and common) generalization?
Timezones and locales should be implemented as "abstractions"
requiring namespaces if this is the idea, isn't it?
Try to think on how complex would be the management of
timezones and locales it this was the case...