zokradonh/kopano-docker

LDAP SSL custom CA

Closed this issue · 10 comments

So I wanted to connect Kopano server to a test Samba4 instance, and at least the current samba versions won't let you bind without SSL/TLS.
After some research I got the idea to simply install my custom public CA cert on the docker host and add the folders to the container.

root:~$ cp my-custom-ca.crt /usr/local/share/ca-certificates/
root:~$ update-ca-certificates
Updating certificates in /etc/ssl/certs...
1 added, 0 removed; done.
Running hooks in /etc/ca-certificates/update.d...
done.

Afterwards creating a new override file

docker-compose.override.yml

version: "3.5"

services:
  kopano_server:
    volumes:
      - /etc/ssl/certs/:/etc/ssl/certs/:ro
      - /usr/local/share/ca-certificates/:/usr/local/share/ca-certificates/:ro

And including it in the .env COMPOSE_FILE= section.

I guess I propably will have to do that for the tvial/docker-mailserver, for SMTP/IMAP access, but I'll burn that bridge when I cross it.

Long story short, I would like to find a nice little place inside this repo, where to put this little bit of informtaion. Is the WiKi an option or is it not used for a good reason?

Furthermore one might want to enable STARTTLS for some reason instead of using the SSL port, but with the given KCCONFIG_... this seems to be impossible, since it makes everything lowercase.

Hi @engelant,

yes the way you have solved it by mounting the certificates into the container is how I would have solved this as well.

Long story short, I would like to find a nice little place inside this repo, where to put this little bit of informtaion. Is the WiKi an option or is it not used for a good reason?

I personally dislike the wiki for storing information as its quite disconnected from the actual code and therefore I have so far used https://github.com/zokradonh/kopano-docker/tree/master/examples for storing small snippets of knowledge and other examples. But reading https://drewdevault.com/2020/06/06/Add-a-contrib-directory.html maybe it would be a nice idea to rename it to contrib to make its meaning clearer.

Yes, having these bits of documentation as part of the git repository means its slightly more complicated for externals to contribute to them, but having everything in one place and free to move to a different repo is imho worth this.

What do you think?

Furthermore one might want to enable STARTTLS for some reason instead of using the SSL port, but with the given KCCONFIG_... this seems to be impossible, since it makes everything lowercase.

Maybe I misunderstood, but as all options withing the Kopano cfg files are lowercase I don't think this should be an issue.

   ldap_starttls
       Request that any LDAP connections be secured with TLS, and reject the connection
       if this security cannot be established. See the OpenLDAP documentation for
       setting up ldap.cfg and TLS requirements.

       Default: no

Hi @fbartels,
regarding the Wiki I'd like to refer to this project or more precisly this page. Imho this is by far better readable, while the author has more tools in terms of formatting and comments to outline pitfalls etc.

Regarding ldap_starttls, yeah, i misred that one, I was thinking of TLS_CACERT=, the variable I tried to overwrite in my first attempt.

Imho this is by far better readable

What specifically do you like better?

Are you hinting towards the "If you're looking for support:" footer?

What I like better is the markdown format for documentation in contrast to the current examples. Take a look at this section, it gives a potential author (like me) the possibility to not only present final configuration, but also highlight important bits, warnings of non working methods.

I could just start adding Markdown to the example folder, referencing to the current examples and adding my own example to the current folder. Still I think it's worth discussing if this is in the spirit of the project aswell as how to do it.

There is quite a bit of documentation available, also the forums and last but by any means not least the availability of commercial support. Are you hinting towards that?

Ah, you are talking about the "examples" folder and not about the readme in general. Yes I totally agree that this folder could use a better organisation.

Ok, since we agree on that point this still leaves the question who gets to decide (@zokradonh ?) if and how we can add docker related documentation for this project. Maybe even define or better reference a template/standard for code/variable/comments inside the markdown. And the question ether to use the wiki or md files in the tree.

Correct me if I'm wrong, but from my point of view the online editing capabilities of the Wiki are more convinient to use than merging mds from forked branches.

this still leaves the question who gets to decide

In the past @zokradonh did trust my judgement, alter all I have write permissions for this repository.

I of course want what is best for the project, but I have also already said what speaks imho against using the wiki functionality of Github:

Yes, having these bits of documentation as part of the git repository means its slightly more complicated for externals to contribute to them, but having everything in one place and free to move to a different repo is imho worth this.

So be it, can I then just add a md file to the example folder for merging? Any structure I should follow?

I'd say if it fits a single file, place it directly in the folder. If multiple files are necessary create a subfolder with a readme.md.

This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 5 days