Closed XtraLarge closed 5 years ago
Hi @XtraLarge,
First I host my docker behind a complex Apache Reverse Proxy with an wildcard dns domain (for every service one name). This works without any problems, but if I reverse proxy your docker container to the port 443 kopano_web, The webapp background image appears, but the login mask was not shown. If I use the full internal fqdn, it works perfectly but no chance to reverse proxy it.
This sounds a bit like this was already discussed in an earlier issue. Without logs or configuration files the following is just a guess but I would think that when you do not get the login screen on WebApp the internal redirect to Konnect fails, since your hostname cannot be resolved.
Maybe https://stash.z-hub.io/projects/K4U/repos/kopano-apps/browse/kopano-meet/compose?at=refs%2Fheads%2Funivention#8-12 gives you the required hint as this uses a similar scenario (Meet running behind Apache reverse proxy).
For the MTA stack this project uses https://github.com/tomav/docker-mailserver, thence your questions regarding Fetchmail and rewriting are probably better suited in that project.
In the past (non Docker) I have used https://github.com/initdotlove/fetchmail-ldap for fetching mails, in a container world I could even imagine starting a single container for each pulled account.
I would like to host some kopano stack instances, because I also host a kopano system for a friend of me. I found no solution to give every kopano stack an ip adress for its own, I found only a solution to take the host ip.
Can you explain that a bit more? It should be no problem to problem to run multiple instances of this project on one host. For this you need to change the COMPOSE_PROJECT_NAME
(in .env
) to a per instance unique value. The next would then be to use non conflicting ports, for all the web stuff you could just use a random one since you have a reverse proxy in front anyways. For stuff like the MTA you could specify just a different binding ip in the ports section (like 192.168.1.1:25:25, see https://docs.docker.com/compose/compose-file/#ports for more info).
Practicality speaking for a true "hosting" setup you probably want to run a central instance for the MTA and database.
closing because of inactivity
Hello,
I'm in holiday in greece, because of that I can no answer soon. I've tried
the link you give me, but it wouldn't be found.
-----Ursprüngliche Nachricht----- Von: Felix Bartels notifications@github.com Gesendet: Samstag 5 Oktober 2019 19:44 An: zokradonh/kopano-docker kopano-docker@noreply.github.com CC: Hans-Willi Werres werres@fritz.box; Mention mention@noreply.github.com Betreff: Re: [zokradonh/kopano-docker] Some features I missed or did not found (#249)
Hi @XtraLarge,
First I host my docker behind a complex Apache Reverse Proxy with an wildcard dns domain (for every service one name). This works without any problems, but if I reverse proxy your docker container to the port 443 kopano_web, The webapp background image appears, but the login mask was not shown. If I use the full internal fqdn, it works perfectly but no chance to reverse proxy it.
This sounds a bit like this was already discussed in an earlier issue. Without logs or configuration files the following is just a guess but I would think that when you do not get the login screen on WebApp the internal redirect to Konnect fails, since your hostname cannot be resolved.
Maybe https://stash.z-hub.io/projects/K4U/repos/kopano-apps/browse/kopano-meet/compose?at=refs%2Fheads%2Funivention#8-12gives you the required hint as this uses a similar scenario (Meet running behind Apache reverse proxy).
For the MTA stack this project uses https://github.com/tomav/docker-mailserver, thence your questions regarding Fetchmail and rewriting are probably better suited in that project.
In the past (non Docker) I have used https://github.com/initdotlove/fetchmail-ldapfor fetching mails, in a container world I could even imagine starting a single container for each pulled account.
I would like to host some kopano stack instances, because I also host a kopano system for a friend of me. I found no solution to give every kopano stack an ip adress for its own, I found only a solution to take the host ip.
Can you explain that a bit more? It should be no problem to problem to run multiple instances of this project on one host. For this you need to change the COMPOSE_PROJECT_NAME (in .env) to a per instance unique value. The next would then be to use non conflicting ports, for all the web stuff you could just use a random one since you have a reverse proxy in front anyways. For stuff like the MTA you could specify just a different binding ip in the ports section (like 192.168.1.1:25:25, seehttps://docs.docker.com/compose/compose-file/#portsfor more info).
Practicality speaking for a true "hosting" setup you probably want to run a central instance for the MTA and database.
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.
Hi,
the branch in question has since then be merged and you can now find the referenced data at https://stash.z-hub.io/projects/K4U/repos/kopano-apps/browse/kopano-meet/compose#8-12
Hello,
I've found the problem for the Apache reverse proxy. KWeb did not accept TLSv1. You must configure Apache to use TLSv1.3 for the client component. You can configure it with the command: SSLProxyProtocol -all +TLSv1.3
At the next I try to configure the Folder Names in German.
best regards Willi Werres
Hello,
first I must praise your job, this was my first view of such a complex stack and a very comfortable infrstructure.
I've tested it a lot, but for my use case there are some things I missed or that did not work as expected:
First I host my docker behind a complex Apache Reverse Proxy with an wildcard dns domain (for every service one name). This works without any problems, but if I reverse proxy your docker container to the port 443 kopano_web, The webapp background image appears, but the login mask was not shown. If I use the full internal fqdn, it works perfectly but no chance to reverse proxy it.
I use some different email providers and get the mails through fetchmail. Because it is not very comfortable to wait for the next time slot of fetchmail to get the mails, I use "imap idle". The result is that the fetchmail process stays connected with the account and forward the emails at once. This would work perfectly with your system, but only for one account. If you enter a second account the fetchmail process will stay connected with the first account and will never pull the emails for the second one. To change this behavior there must be started an fetchmail process for every account. Example
Many email providers take only messages (smtp) for senders from there domain. My solution was to configure sender-based-smtp for the postfix, but I found no way to configure it with docker environment variables.
I use my own internal dns domain to send emails between my systems without sending to the internet. So my internal adresses must be rewritten for external delivery, this was a problem to configure it to your system with docker environment variables.
I would like to host some kopano stack instances, because I also host a kopano system for a friend of me. I found no solution to give every kopano stack an ip adress for its own, I found only a solution to take the host ip.
It would be nice if you will support some of my problems in future releases. Or give me a hint how to configure it.
Despite the criticisms, I would like to repeat that you have created a very good system for which you deserve the highest praise.
PS: Sorry for my bad english, I'm not a native speaker and use english not so often.