[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Tue, 03 Dec 2013 20:44:01 +0000
From: Laurent Bercot <ska-dietlibc@...rnet.org>
To: musl@...ts.openwall.com
Subject: Re: _PATH_LASTLOG
> One problem I'd like to solve is making a way for users to override
> the system resolv.conf;
The s6-dns client library uses the DNSCACHEIP environment variable for
this: if it contains a list of DNS caches, this list will override the
/etc/resolv.conf-provided one. (The idea comes from djbdns, but has been
extended to a full list instead of a single cache address.)
Same thing with the DNSQUALIFY environment variable, which can have
a list of suffixes that overrides resolv.conf. (djbdns had a complex
rules-rewriting-based qualification mechanism that nobody ever used,
so the simpler approach was easier and better.)
Maybe musl could use the same approach: environment variables are a
reasonable place for hardcoded-path overrides. But it has to be balanced
against namespace pollution.
> This seems like a good foundation for a package system. I've looked
> into Nixos before but never really tried it out, and got the
> impression that the concept was very good but it might not be the best
> implementation. So something similar to Nixos sounds interesting. :-)
I've always believed that the filesystem itself should be used as a
packaging system: every package should have its own system user and reside
in its own directory, and /usr/bin and friends should only contain
symlinks. Native isolation via Unix permissions, atomic package replacement,
easy package management. But for some reason, people seem absolutely
reluctant to do this.
> The philosophy used in musl, which is somewhat different from the sort
> of philosophy you might have when designing a new distribution, is not
> to invent new policy but to avoid policy and build on existing,
> already-widely-accepteed policy when it's unavoidable.
I don't agree with all decisions in musl, but this one I can definitely
stand for.
> There are LOTS of ways one could extend hostname lookups, ranging from NSS modules to
> hosts.d and resolv.d, but rather than trying to support everything
> imaginable (result: bloat and serious security considerations) in
> libc, the musl approach to hostname lookup is that libc contains the
> basics that are suitable for most/all simple systems, and anything
> more advances can be provided by an external daemon running on
> localhost that speaks DNS protocol and provides whatever lookup
> semantics you desire.
In the DNS case, the flexible - and best, IMNSHO - approach is to run a
small local DNS cache on localhost indeed; but the problem is that there's
an existing codebase that sometimes insists on clobbering /etc/resolv.conf,
which adds to the packaging burden when your purpose is to create or maintain
a distribution. Having extension mechanisms at the libc level can help in
that situation.
--
Laurent
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
