On Fri, 25 Jan 2019, at 11:18, Michael Fair wrote: > I see the main differences are: > 1) if I don't turn on clustering, because i'm single node, the only network > way into Couch data is via the HTTP layer (at least so I would assume) > 2) if I do turn on clustering, and I manually connect in to the cluster, I > haven't been given tools in every scripting language to directly query and > rewrite the entire dataset. There's still a lot of internal workings I > need to understand.
true; bear in mind that couchdb will also have a couch->fdb k/v layer so it's still not going to be quite as transparent as that. > With the FDB approach, as a single machine instance, I seem to have no > choice but to allow every program/script on my machine access to the > backend of the Couch data. File level user privileges can't apply, all > security to the underlying backend data becomes "was the source IP > 127.0.0.1" or more generally "did the connection come from the right IP > address". I am certainly going to find that very useful for my own > "explorations" to poke around the insides, but it just feels like a step > backward securitywise. I agree. > I'm confident the issue will be addressed somehow, and perhaps the TLS > stuff is all that's really required, but I would think it's really > important for a server to be able to specify what/who its legitimate peers > are. I think this is definitely going to become more of an issue as these > kinds of decentralized services mature more. > t > It'd be awesome if FDB had the option to be/do something like a SQLite > library or work over a spawned PIPE or something to lock it down so only > the Couch server instance that launched it could use it... TLS and TCP are non-negligable overheads, but this may not matter much in practise. This is what I was thinking of with UNIX domain sockets. So I asked: https://forums.foundationdb.org/t/feature-request-support-unix-domain-sockets-for-client-local-server-access/1071 A+ Dave
