[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CACCP0GqEr+e8OQHENzeNOCfzguF+EY-FkRB-t5hTMf=jT4=SQA@mail.gmail.com>
Date: Tue, 3 Dec 2013 20:51:07 +0000
From: Raphael Cohn <raphael.cohn@...rmmq.com>
To: musl@...ts.openwall.com
Subject: Re: _PATH_LASTLOG
I've always believed that the filesystem itself should be used as a
packaging system...
This is EXACTLY what I want to do. Each package is its own FHS...
Raphael Cohn
Chief Architect, stormmq
Co-Chair, OASIS MQTT Standard
Secretary, OASIS AMQP Standard
raphael.cohn@...rmmq.com
+44 7590 675 756
UK Office:
Hamblethorpe Farm, Crag Lane, Bradley BD20 9DB, North Yorkshire, United
Kingdom
Telephone: +44 845 3712 567
Registered office:
16 Anchor Street, Chelmsford, Essex, CM2 0JY, United Kingdom
StormMQ Limited is Registered in England and Wales under Company Number
07175657
StormMQ.com
On 3 December 2013 20:44, Laurent Bercot <ska-dietlibc@...rnet.org> wrote:
>
> 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
>
>
Content of type "text/html" skipped
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.
