search

mbologna / docker-bitlbee

Run bitlbee with TLS and custom protocols in a container
MIT License
45 stars 25 forks source link

SSL support #6

Closed hasufell closed 4 years ago

hasufell commented 4 years ago

Seems there is no support for connecting to bitlbee over an stunnel.

hasufell commented 4 years ago

https://github.com/hashbang/docker-bitlbee/blob/master/stunnel.conf

mbologna commented 4 years ago

Thanks for bringing this limitation up. Normally, bitlbee runs bound to localhost but I understand your concern: if you run bitlbee somewhere, someone can sniff the traffic in between.

IMHO, it should be only one daemon per container. This means that stunnel must live in a separate container. Then, everything must be glued together in a docker network (that can be automated in a docker-compose).

Added-value of this approach: the user can select whether they want to connect via TLS or not.

I can address this issue in the future: in the meanwhile, I will be happy to review any PR you may want to open in this direction.

hasufell commented 4 years ago

IMHO, it should be only one daemon per container.

I don't generally share this philosophy. It makes setups needlessly complicated. The reasons you want to separate things in different containers are:

  1. security concerns
  2. maintainability concerns (one daemon needs more frequent maintenance/updates/different OS)
  3. replacability (user wants postgres, not mysql)
  4. size of the images

It is quite easy to run a multi-daemon docker container with supervisord and have a startup configuration for that. stunnel is small and has almost zero config/overhead.

And: I don't use docker-compose for anything on my server. It doesn't integrate well with other specialized approaches to spawn and control containers.

mbologna commented 4 years ago

It is quite easy to run a multi-daemon docker container with supervisord and have a startup configuration for that. stunnel is small and has almost zero config/overhead.

This is debatable, because:

I prefer providing a separate container for stunnel and package everything into an easily deployable solution with docker-compose: if someone wants to have TLS termination for bitlbee, it is enough to link it to bitlbee. Speaking of which, can you suggest an alternative to docker-compose for this kind of requirement?

hasufell commented 4 years ago

We would need to add a dependency (supervisord) in the bitlbee container

Yes, which is simpler than docker-compose with all of its complexity.

We need to deal with supervisord restart policy - what happens if stunnel crashes?

With containers, you have the same problem.

Updates: if stunnel requires an update, we need to rebuild bitlbee and its plugins (and the other way around)

If you want to optimise build times, you can use layers for this.

if someone wants to have TLS termination for bitlbee, it is enough to link it to bitlbee.

Well, you're adding configuration complexity while it could simply just be a command line switch in the entrypoint that enables stunnel.

Speaking of which, can you suggest an alternative to docker-compose for this kind of requirement?

No, I don't really use docker-compose much. The only containers I have separately are front-proxies and mysql containers. Those have reasons to be separate. And I don't need docker-compose for that.

hasufell commented 4 years ago

But you could indeed argue this is outside of the scope of this Dockerfile and might as well be a separate Dockerfile that derives from this.

mbologna commented 4 years ago

We need to deal with supervisord restart policy - what happens if stunnel crashes?

With containers, you have the same problem.

Not really: it depends on how supervisord handles a process termination and the policy to restart a service.

mbologna commented 4 years ago

This issue has been fixed in https://github.com/mbologna/docker-bitlbee/commit/f11fce3f4afb380c9d009f519199e48deb4d22bb, tested and pushed to master Thanks for bringing this up, and enjoy TLS terminated bitlbee!

hasufell commented 4 years ago

Not really: it depends on how supervisord handles a process termination and the policy to restart a service.

Yes, you're just trading supervisord with docker-compose. Both have restart policies.

Thanks for bringing this up, and enjoy TLS terminated bitlbee!

Interesting work! I'm using a derived Dockerfile, however.