Re: RFC for VIP17: unix domain sockets for listen and backend addresses

2017-05-22 Thread Dridi Boukelmoune
> OK, that should be documented though (there is other software that > works with UDSen that does in fact unlink before bind). There should be a limit to hand-holding. I have bitter memories of tracking down processes holding unlinked files around and leaving a partition with no space. The upside

Re: RFC for VIP17: unix domain sockets for listen and backend addresses

2017-05-22 Thread Geoff Simmons
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 This will be comments on this part of the thread so far, and on the current state of the draft in Wiki. On 05/15/2017 11:41 AM, Dridi Boukelmoune wrote: >> >> For connect(2), BSD-derived systems don't care about permissions >> on the UDS path at

Re: RFC for VIP17: unix domain sockets for listen and backend addresses

2017-05-19 Thread Dridi Boukelmoune
> +1 I just had a use case for this yesterday, which might also be a general use > case: cross-container communication (in docker). Sharing a file system with a > UDS (read only) between container is safe and easy, while configuring a shared > network between containers is not. The VIP now covers

Re: RFC for VIP17: unix domain sockets for listen and backend addresses

2017-05-18 Thread Dridi Boukelmoune
On Mon, May 15, 2017 at 11:41 AM, Dridi Boukelmoune wrote: Hello, Making slow progress on the draft, but getting there. While gathering details from the first v6wash and the original draft, I found that named listen addresses could once again solve one of the issues. In this

Re: RFC for VIP17: unix domain sockets for listen and backend addresses

2017-05-15 Thread Dridi Boukelmoune
> First of all (a lesser matter): OK, we can go with commas as a > separator, with the consequence that UDS paths may not have a comma. > There is a precedent for that with -sfile. Yes, we can probably get away with no commas in file names. Also see this comment from phk:

Re: RFC for VIP17: unix domain sockets for listen and backend addresses

2017-05-15 Thread Geoff Simmons
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 04/25/2017 04:42 PM, Dridi Boukelmoune wrote: > >> ## Access permissions on the listen address For the ``-a`` >> address, I suggest an optional means of specifying who can access >> the UDS: ``` varnishd -a unix:/path/to/uds:uid=foo,gid=bar ```

Re: RFC for VIP17: unix domain sockets for listen and backend addresses

2017-05-10 Thread Dridi Boukelmoune
>> So I say do it right from the beginning this time, and make it >> possible to use relative paths and just change the uds_path parameter >> when you have to. > > Define "when you have to", as I said earlier listen addresses are > immutable once the manager is started. That's a condition that >

Re: RFC for VIP17: unix domain sockets for listen and backend addresses

2017-05-08 Thread Geoff Simmons
On 04/25/2017 04:42 PM, Dridi Boukelmoune wrote: >> >> # How? ## Address notation I suggest that we require a prefix >> such as ``unix:`` to identify UDS addresses (nginx uses >> ``unix:``, haproxy uses ``unix@``): ``` varnishd -a >> unix:/path/to/uds > > This should be enough: > > varnishd -a

Re: RFC for VIP17: unix domain sockets for listen and backend addresses

2017-04-25 Thread Dridi Boukelmoune
> # Synopsis > Allow unix domain sockets as a listen address for Varnish (``-a`` > option) and as addresses for backends, and for use in ACLs. Obtain > credentials of the peer process connected on a UDS, such as uid and > gid, for use in VCL. Except for ACLs, I find the idea compelling so far. I