|
Message-ID: <529E4291.1030100@skarnet.org> 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.