Hi all, when trying to setup TLS, i got the following error: Could not flush buffer: Broken pipe (os error 32) Socket error, Message: Could not flush buffer: Broken pipe (os error 32) Any ideas?

hi Brandon, can you elaborate what exactly do you mean by “trying to setup TLS”? are you fronting a QuestDB server with a TLS-terminating proxy? What protocol is it for?

I am using a reverse proxy with Caddy

I see. so this is for the HTTP protocol? and you are getting this error on a server when Caddy is connecting to QuestDB?

Yes HTTPS, I have a domain pointing out to the QuestDB server, with two reverse proxies, one for the UI/REST and one only for ILP. I already change the port so i can use 9009 externally. But i am getting this error, the weird thing is that it “works” with small volume of data, in any case, this data is not being received at the DB. I already change commit lag to 100 so i think thats not the issue

Can Caddy act as a reverse proxy for a plain TCP? It works on the HTTP layer, doesn’t it? QuestDB ILP is not based on HTTP. Something like HAProxy might work better for you.

Ok, that makes sense to me. I was not considering this, I will try with HAProxy, Thank you!

yes, I think that should work. but I have never tried it myself.

ok, finally working, thank u @Jaromir Hamala for pointing me out the correct direction 🙂

cool, glad to hear that! would you be interested in documenting your steps? I think other could benefit from it too

Sure thing, I was thinking about this, since in my head the process was different, i think some will be in the same boat

we have this for HTTP: https://questdb.io/blog/2022/08/05/setting-basic-auth-nginx/ but currently no docs how to setup TLS with ILP

Yeah i’ve seen this one, i can start drafting the process

that would be awesome! cc @Amy Wang ☝️

Btw, TLS is achievable in Kubernetes with the ingress?

Depending on you ingress controller it might be achievable. I assume most ingress controllers will be very HTTP centric, but in principle they can work on a lower level too. Caveat: I am not a Kubernetes expert. There is another issue tho: The traffic between a reverse proxy and QuestDB would be still unencrypted. So you would have to make sure a reverse proxy container is collocated (in the same pod) with QuestDB. It smells more like a service mesh use-case to me: A side-car collocated with a QuestDB container, the QuestDB is listening on a local loopback only and the side-car expose QuestDB to the rest of the universe and terminates TLS.

Ok thank you, i will check! 🙂, btw, if you don’t mind i am wondering if there is a way to include auth per user in QuestDB or to add an auth firewall so the query to rest api can go into client side ?

you can switch the REST interface into the read-only mode. but it doesn’t support authentication. the common pattern is to use a reverse proxy for auth.

How you use a reverse proxy for auth?

it’s described in the blog: https://questdb.io/blog/2022/08/05/setting-basic-auth-nginx/ if you are using Caddy then it looks it supports auth. too: https://github.com/DoTheEvo/selfhosted-apps-docker/tree/master/caddy_v2#basic-authentication

In any case, if the final user is facing the DB, they can get other data that doesn’t belong to them, so i need to put the db access within an API even though making slower the retrieval of the data 😢

that’s right. but it’s usually not too bad. the extra network hop will be negligible unless you run very simple queries: if you are on a good network than a network round trip is in small 10s of microseconds. even a crappy (local) network won’t go over small 100s of microseconds. the reverse proxy will also add some penalty, but e.g. nginx can be pretty fast.

Yeah, i think it’s a trade-off, in any case, i will do some improvements in performance so the penalty is lower. btw, do u think it could be possible to include some auth management within the rest api?

as far as I know it’s not on the project roadmap so I would not expect that.