From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/4347 Path: news.gmane.org!not-for-mail From: Raphael Cohn Newsgroups: gmane.linux.lib.musl.general Subject: Re: _PATH_LASTLOG Date: Tue, 3 Dec 2013 21:05:00 +0000 Message-ID: References: <20131203184248.GT1685@port70.net> <20131203195433.GM24286@brightrain.aerifal.cx> <20131203202502.GO24286@brightrain.aerifal.cx> <529E4291.1030100@skarnet.org> <529E466A.8050907@gmail.com> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=e89a8ff1ce02464fd104eca7a61c X-Trace: ger.gmane.org 1386104713 12058 80.91.229.3 (3 Dec 2013 21:05:13 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 3 Dec 2013 21:05:13 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-4351-gllmg-musl=m.gmane.org@lists.openwall.com Tue Dec 03 22:05:20 2013 Return-path: Envelope-to: gllmg-musl@plane.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1Vnx9d-0004IB-5J for gllmg-musl@plane.gmane.org; Tue, 03 Dec 2013 22:05:13 +0100 Original-Received: (qmail 3854 invoked by uid 550); 3 Dec 2013 21:05:12 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Original-Received: (qmail 3846 invoked from network); 3 Dec 2013 21:05:12 -0000 X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=yiKYqB9Ul/Q7naxlKg6OrvBulm0Dizl225cT+sTu6bw=; b=YhpWup4AkSmYDUZ3/VKfAhx/VrsTef/8agC2/bmaRqrBOySil5jARfsCS0dzniWw03 Zij41BqeHmsceMiLlpis99HJeFnkIaom8JCazBgYU0sunIMMlFX14h5JnouOAvoFCtVt 5rNBVRPnN2ifsiborPicSiR7v6xe2K7I3kiXfZWHW3AZ7WWUCThX8gbUcCNOOCecwtzE x7xbMgWVyqf9a9uVMhgxT6Sv0eEnFktVeEgjSocIkc4/OJ5vy6g7RFW4YNDonjhTfGTg dI9z6PVSF6ytkyWsjq/ClVDsyvg0HBpgM/dGzWJEmS300rZyg6sBH10j2VaZ+jE8YMUt pJBg== X-Gm-Message-State: ALoCoQl5eREJ2nwDaMYr9eDrwQ1U+mnTjazYl9cCxbwtExduyIlrz5M/ny4THoV1BQqu7blgSHP/ X-Received: by 10.182.166.40 with SMTP id zd8mr60169557obb.25.1386104700157; Tue, 03 Dec 2013 13:05:00 -0800 (PST) X-Originating-IP: [2001:8b0:862:b944:a534:c887:3b4d:f028] In-Reply-To: <529E466A.8050907@gmail.com> Xref: news.gmane.org gmane.linux.lib.musl.general:4347 Archived-At: --e89a8ff1ce02464fd104eca7a61c Content-Type: text/plain; charset=UTF-8 Yes, we can - the only problem being that a lot of the systems I have access to have either broken implementations or lack the necessary stuff in the kernel.UnionFS' code base seems very complex. And bind mounts are very hard to track by 'just looking at the file system'. We're very keen on something that has good visual audit qualities, ie a sysadmin can look at it and go 'that doesn't like right...' We'd also need a lot of bind mounts... The performance argument from the few tests I did does seem moot - symlink look up is almost instantaneous on a SSD. On rust it might be different. But rust isn't where we're going... Raphael Cohn Chief Architect, stormmq Co-Chair, OASIS MQTT Standard Secretary, OASIS AMQP Standard raphael.cohn@stormmq.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 21:00, Nathan McSween wrote: > You can implement this with bind mounts and containers as well, maybe > when Linux gets union mounts within the vfs this can be done cleanly > and per container. > > On Tuesday, December 03, 2013 12:51:07 PM, Raphael Cohn wrote: > > 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@stormmq.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 > 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 > >> > >> > > > --e89a8ff1ce02464fd104eca7a61c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Yes, we can - the only problem being that a lot of th= e systems I have access to have either broken implementations or lack the n= ecessary stuff in the kernel.UnionFS' code base seems very complex. And= bind mounts are very hard to track by 'just looking at the file system= '. We're very keen on something that has good visual audit qualitie= s, ie a sysadmin can look at it and go 'that doesn't like right...&= #39; We'd also need a lot of bind mounts...

The performance argument from the few tests I did does seem moot = - symlink look up is almost instantaneous on a SSD. On rust it might be dif= ferent. But rust isn't where we're going...


Raphael Cohn
Chief Architect, stormmq
Co-Chai= r, OASIS MQTT Standard
Secretary, OASIS AMQP Standard
raphael.cohn@stormmq.co= m
+44 7590 675 756

UK Office:
Hamblethorpe Farm, Crag = Lane, Bradley BD20 9DB, North Yorkshire, United Kingdom
Telephone: +44 8= 45 3712 567

Registered office:
16 Anchor Street, Chelmsford, Essex, CM2 0JY, U= nited Kingdom
StormMQ Limited is Registered in England and Wales under Company Number 071= 75657
StormMQ.com


On 3 December 2013 21:00, Nathan McSween= <nwmcsween@gmail.com> wrote:
You can implement this with bind mounts and containers as well, maybe
when Linux gets union mounts within the vfs this can be done cleanly
and per container.

On Tuesday, December 03, 2013 12:51:07 PM, Raphael Cohn wrote:
> 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@stormmq.com
> +44 7= 590 675 756
>
> UK Office:
> Hamblethorpe Farm, Crag Lane, Bradley BD20 9DB, North Yorkshire, Unite= d
> 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 Numbe= r
> 07175657
> StormMQ.com
>
>
> On 3 December 2013 20:44, Laurent Bercot <ska-dietlibc@skarnet.org> wrote:
>
>>
>> =C2=A0One problem I'd like to solve is making a way for users = to override
>>> the system resolv.conf;
>>>
>>
>> =C2=A0The s6-dns client library uses the DNSCACHEIP environment va= riable 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 ha= s been
>> extended to a full list instead of a single cache address.)
>> =C2=A0Same thing with the DNSQUALIFY environment variable, which c= an have
>> a list of suffixes that overrides resolv.conf. (djbdns had a compl= ex
>> rules-rewriting-based qualification mechanism that nobody ever use= d,
>> so the simpler approach was easier and better.)
>>
>> =C2=A0Maybe musl could use the same approach: environment variable= s are a
>> reasonable place for hardcoded-path overrides. But it has to be ba= lanced
>> against namespace pollution.
>>
>>
>>
>> =C2=A0This seems like a good foundation for a package system. I= 9;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 interesti= ng. :-)
>>>
>>
>> =C2=A0I've always believed that the filesystem itself should b= e used as a
>> packaging system: every package should have its own system user an= d 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 absolute= ly
>> reluctant to do this.
>>
>>
>>
>> =C2=A0The philosophy used in musl, which is somewhat different fro= m 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.
>>>
>>
>> =C2=A0I don't agree with all decisions in musl, but this one I= can definitely
>> stand for.
>>
>>
>>
>> =C2=A0There are LOTS of ways one could extend hostname lookups, ra= nging from
>>> =C2=A0NSS modules to
>>> hosts.d and resolv.d, but rather than trying to support everyt= hing
>>> imaginable (result: bloat and serious security considerations)= in
>>> libc, the musl approach to hostname lookup is that libc contai= ns the
>>> basics that are suitable for most/all simple systems, and anyt= hing
>>> more advances can be provided by an external daemon running on=
>>> localhost that speaks DNS protocol and provides whatever looku= p
>>> semantics you desire.
>>>
>>
>> =C2=A0In 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/res= olv.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.
>>
>> --
>> =C2=A0Laurent
>>
>>
>

--e89a8ff1ce02464fd104eca7a61c--