Location: split again? (borg2)

[ThomasWaldmann]

status quo (borg2 / master branch)

for borg2, we already have implemented splitting Location URLs like ssh://server:port/path/to/repo::archive into:

• repo location ssh://server:port/path/to/repo
• separate archive name (as a positional parameter or -a ... matching pattern).

when working on socket support #6183 and #7615, another problem in the repo location part came up:

while a ssh user / server / port spec can be nicely combined with a repo path inside one repo URL,
it would be somehow ugly and confusing if we have to combine a UNIX domain socket path and a repo path inside one repo URL:

• ssh://server:port/path/to/repo
• socket:///path/to/socket::/path/to/repo (UNIX domain socket at /path/to/socket) ugly / confusing
• socket://server:port/path/to/repo (later maybe: TCP socket to server:port)

split it again!? (for borg2)

maybe it would be better to just split server and repo spec, like borg --server=... --repo=...:

• --server=builtin (default: no client/server, direct access to local filesystem)
• --server=ssh://user@host:port (client/server, server is at this location, use ssh or whatever --rsh gave to connect)
• --server=socket:///path/to/socket (client/server, use a UNIX domain socket at /path/to/socket)
• --server=socket (client/server, use a UNIX domain socket at the default location)
• --server=socket://host:port (client/server, use a TCP socket connection to host:port, later maybe)

in the client/server cases, --repo would just give a spec for the repo which borg serve can deal with (currently this would be just the repo fs path from the perspective of borg serve).

[ThomasWaldmann]

See also #4749.

[PhrozenByte]

Just for others who want to participate in the discussion, you can find my thoughts about this here: #6183 (comment)

To sum my opinion up on this: This issue only exists for UNIX sockets due to their nature of being file paths, any other remote usage plays nice with the current single option approach. Adding --server (or --remote as it was proposed earlier) makes things harder for any user, whereas --socket (i.e. a distinct option for UNIX sockets) only affects the people requiring more advanced setups with UNIX sockets. I see --socket in line with --rsh: It's an option for advanced usages. Don't make the basic usage harder because of advanced usages.

[RonnyPfannschmidt]

I'd recommend to consider the unix domain socket as always for one repository,

[PhrozenByte]

I'd recommend to consider the unix domain socket as always for one repository,

This only works if the Borg server (borg serve) is running on the same machine as the Borg client, and as the same user (resp. the client user has full access to the repo). If both is true, one wouldn't use sockets. For sockets we must assume that the Borg client has no access to the Borg repo, either due to missing file permissions or simply because the Borg repo is on a different machine.

[ThomasWaldmann]

@RonnyPfannschmidt why so?

[RonnyPfannschmidt]

It's very easy to define socket activated services with modern init systems and it helps to elevate the API Design pressure on remote repo locations

Unlike SSH Location local sockets can't sanely Carry both repo name and socket name

If Borg goes for repo location as URI, then sockets are a third wheel as one would have to tell extra location

If instead a local socket may refer only to one repo,its clear