> 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
-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
> +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
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
> 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:
-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 ```
>> 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
>
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
> # 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