search

zokradonh / kopano-docker

Unofficial Kopano Docker images for all Kopano services.
MIT License
59 stars 37 forks source link

email address off broken, own proxy ssl termination broken #108

Closed cguentherTUChemnitz closed 5 years ago

cguentherTUChemnitz commented 5 years ago

I want to run this stack behind my existing ssl-terminating reverse proxy. As far as i understand the configuration, i should switch the encryption to off. So i use the E-Mail for letsencrypt option "off". Nevertheless, the newly introduced services seem to connect against the internal network directly and assume an encryption there also, which breaks the ssl-termination behaviour expectation.

A was able to test this easily by running the full stack with default configuration except the E-Mail for letsencrypt setting using "off". The following errors i get are:

kopano_kwmserver         | kcoidc: 2019/03/11 15:15:15 kcoid discovery error: Get https://kopano.demo/.well-known/openid-configuration: http: server gave HTTP response to HTTPS client
kopano_spooler           | Mon Mar 11 16:15:17 2019: [error  ] [    6] gsoap connect: ()
kopano_spooler           | Mon Mar 11 16:15:17 2019: [error  ] [    6] HrLogon server "default:" user "SYSTEM": network error
kopano_spooler           | Mon Mar 11 16:15:17 2019: [error  ] [    6] Unable to open admin session: network error (80040115)
kopano_kapi              | kcoidc: 2019/03/11 16:15:17 kcoid discovery error: Get https://kopano.demo/.well-known/openid-configuration: http: server gave HTTP response to HTTPS client
fbartels commented 5 years ago

Yes, it's required that the discovery document is served through https. For scenarios where the web container is run without https the best solution I have found is setting FQDNCLEANED to an "invalid" value forcing clients to request the document externally.

cguentherTUChemnitz commented 5 years ago

I tried as an alternative to proxy the sell_signed configuration. But i am not able to proxy this one with traefik correctly. I am only able to produce Internal Server Error. So no having the caddy ssl off option available, seems to break my use case of having an own reverse proxy in front of this stack. EDIT: Thanks for your reply in the meantime. I did not see it at the moment i wrote this comment. I will give some feedback on your proposal afterwards.

mithomas commented 5 years ago

Incidentally I ran into the issue today - but since I have another loadbalancer in front of all my docker containers anyway I decided to bypass kweb altogether.

cguentherTUChemnitz commented 5 years ago

I like to use kweb, since this should be more stable when updating this service stack. I hope that the configuration to stich all services together can be centrally maintained and tested using the kweb container and i have to provide only the central point for my reverse proxy.

Nevertheless thanks alot @fbartels for your fast answer and quick work-around. I think we should go for a solution where the use-case of running this service stack behind an external proxy is tested in CI. In my eyes this should be the most common way to use this service stack in production.

cguentherTUChemnitz commented 5 years ago

So for others running into this problem. It is working with the following docker-compose.override.yml. The proxy-net network refers to the used network for the traefik instance.

version: "3.5"

services:
  web:
    networks:
      proxy-net:
    labels:
      traefik.enable: true 
      traefik.frontend.rule: "Host:${FQDN}"
      traefik.port: 2015
      traefik.protocol: http
      traefik.docker.network: "proxy-net"

networks:
  proxy-net:
   external: true

It is kind of disturbing to read port 443 with http protocol, but this is the current configration of the internal caddy / kweb proxy, when the configuration option E-Mail for letsencrypt is set to "off". The forwarding from 80 to 443 remains, but only the tls is disabled completely. Keeping this in mind, you can proxy kweb without any problems.

And the patched value in .env

FQDNCLEANED=SomeInvalidValueToForceConnectionsAgainstTheExternalEndpoint
fbartels commented 5 years ago

It is kind of disturbing to read port 443 with http protocol

You could alternatively forward to port 2015.

If you already have an override file, you could also just define a different alias directly in your override.

cguentherTUChemnitz commented 5 years ago

Thanks for this hint. I updated the port in my post.

cguentherTUChemnitz commented 5 years ago

I do not know if this is related to the reverse proxy config. I post this here, since i am not able to get my reverse proxy config running. My kopano_server crashes on login attempt with example user user1:user1 showing this log:

kopano_server            | 2019/03/11 21:40:02 Problem with dial: dial tcp 127.0.0.1:236: connect: connection refused. Sleeping 1s
kopano_server            | Mon Mar 11 21:40:02 2019: [=======] Starting kopano-server version 8.7.80 (pid 6 uid 0)
kopano_server            | Mon Mar 11 21:40:02 2019: [=======] Starting kopano-server version 8.7.80 (pid 6 uid 999)
kopano_server            | kcoid discovery error: unexpected response content-type: text/plain
kopano_server            | 2019/03/11 21:40:03 Connected to tcp://localhost:236
kopano_server            | 2019/03/11 21:40:03 Connected to tcp://localhost:236
kopano_server            | kcoid discovery error: unexpected response content-type: text/plain
kopano_server            | kcoid discovery error: unexpected response content-type: text/plain
...
kopano_server            | kcoid discovery error: unexpected response content-type: text/plain
kopano_server            | kcoid discovery error: unexpected response content-type: text/plain
kopano_server            | Mon Mar 11 21:46:02 2019: [error  ] KCOIDC: provider (https://<MYHiddenFQDN>) failed to initialize: 0x105
kopano_server            | [error  ] gsoap connect: ()
kopano_server            | [error  ] gsoap connect: ()
kopano_server            | [error  ] HrLogon server "default:" user "SYSTEM": network error
kopano_server            | could not connect to server at 'default:'
kopano_server            | [error  ] HrLogon server "default:" user "SYSTEM": network error
kopano_server            | [error  ] OpenECSession: network error (80040115)
kopano_server            | [error  ] KServerContext::logon: network error (80040115)
kopano_server            | Mon Mar 11 21:46:02 2019: [=======] Server shutdown complete.
kopano_server            | 2019/03/11 21:46:02 Command exited with error: exit status 1

I am running on these versions:

CORE_VERSION=8.7.80.782 WEBAPP_VERSION=3.5.4.2211 ZPUSH_VERSION=2.4.5 KONNECT_VERSION=0.19.1 KWM_VERSION=latest MEET_VERSION=latest KDAV_VERSION=latest

update: This does happen also for CORE_VERSION=latest

fbartels commented 5 years ago

Hi @cguentherTUChemnitz,

while I do not see a crash in your log (the server shuts down since he cannot retrieve the oidc discovery document) this is certainly connected.

You'd have to enter the container and then check e.g. with curl what the server retrieves from https://$FQDN/.well-known/openid-configuration.

cguentherTUChemnitz commented 5 years ago

Okay thanks for the clarification. I missed to syncronize the FQDN used for the service setup and the domain name used in my configured reverse proxy. So i had to change from traefik.frontend.rule: "Host:kopano.${FQDN}" to traefik.frontend.rule: "Host:${FQDN}" and my login process runs fine :)

I updated the snipped above accordingly in the case some else want to use it this way.

fbartels commented 5 years ago

Case closed?

cguentherTUChemnitz commented 5 years ago

Since i was able to get it running, we can define it as closed. Nevertheless i think a lot of users trying to first test this stack are integrating it into an existing reverse proxy configuration. Therefore it would be beneficial if the setup.sh does more help to achieve a valid configuration for this case. Additionally some more readme documentation would also be fine.

My first picture in my mind is an additional question in the setup.sh asking for the situation of running this stack behind an ssl terminating reverse proxy. This should set than the not obvious options accordingly. I see the options:

Additionally hinting the service stack consumer on how to proxy this service would be nice. I think a comment in the readme of providing http access to port 2015 to the web container would be sufficient. Giving examples of docker-compose.override.yml files for common proxies either in the Wiki or in the source and linking to it would be the best options.

The most i am concerned about is to test this use case. I think some CI test of running this stack behind an additional reverse proxy is a crucial step to provide a production ready service stack, where the customer does not fear (alot) of doing updates / upgrades.

cguentherTUChemnitz commented 5 years ago

One plugin still has a problem reaching the server. The webapp complains about the mdm z-push serice. I see Unable to connect to Z-Push Server. Not found. at the moment i switch to the settings page. Also the general tab shows in version imformation: Z-Push: version not available Could the also be related to this reverse proxy configuration?

fbartels commented 5 years ago

Additionally hinting the service stack consumer on how to proxy this service would be nice.

not my personal goal, so I won't invest my time in it. But I'll gladly accept a PR for this.

I think some CI test of running this stack behind an additional reverse proxy is a crucial step

Yes, some general testing would indeed be nice within this repo. I have already added goss to the travis file for this a while back, but did not make any progress on this (general ticket for this is https://github.com/zokradonh/kopano-docker/issues/26). But for me these tests would then rather cover the standard setup and no special configurations with outside components.

the customer

I've said this already in the past. If you are a "customer" then you have an actual contact person (e.g. your Kopano partner or the Kopano support) and do not pull some code from Github and hope for the best.

The webapp complains about the mdm z-push serice

yes, that plugin needs to be configured to be properly used. https://stash.kopano.io/projects/KWA/repos/mobile-device-management/browse/config.php#3

cguentherTUChemnitz commented 5 years ago

Additionally hinting the service stack consumer on how to proxy this service would be nice.

not my personal goal, so I won't invest my time in it. But I'll gladly accept a PR for this.

Sure i will contribute my insights. I discuss this so openly here, to check that i will contribute documentation that is interesting for as much people as possible.

I think some CI test of running this stack behind an additional reverse proxy is a crucial step

Yes, some general testing would indeed be nice within this repo. I have already added goss to the travis file for this a while back, but did not make any progress on this (general ticket for this is #26). But for me these tests would then rather cover the standard setup and no special configurations with outside components.

Jap sure, will try to build such tests on my own CI instance and report problems as soon as they arrive ;) Nevertheless thanks a lot for your great support :)

The webapp complains about the mdm z-push serice

yes, that plugin needs to be configured to be properly used. https://stash.kopano.io/projects/KWA/repos/mobile-device-management/browse/config.php#3

In which way should be this configured? Is there a possibility to set this as env-vars? Or do i have to patch files in the volume of the container?

fbartels commented 5 years ago

Sure i will contribute my insights. I discuss this so openly here, to check that i will contribute documentation that is interesting for as much people as possible.

Thanks, very much appreciated. I have added https://github.com/zokradonh/kopano-docker/tree/master/examples a while back and I think I would prefer this over adding a wiki to this project. For the moment everything in there is a flat hierarchy, but I am open to change this up.

In which way should be this configured? Is there a possibility to set this as env-vars? Or do i have to patch files in the volume of the container?

Yes, unfortunately the current images do not offer a way to modify the webapp config files at startup. For the core image there is a python script to set config at startup. For Meet I recently worked on https://github.com/zokradonh/kopano-docker/blob/a7c213434766f5433148ea6b50e0894094b92e12/meet/start-service.sh#L22-L27 (still a wip).

Another docker images uses https://github.com/mlan/docker-kopano/blob/master/assets/entrypoint.sh#L80-L92 which looks like a nice approach.

fbartels commented 5 years ago

@cguentherTUChemnitz have you already started tinkering with updating the config files in php? I was thinking of playing with this over the weekend.

fbartels commented 5 years ago

a first try at making webapp and its plugins configurable through env is now in https://github.com/zokradonh/kopano-docker/pull/112

Could be ported to z-push afterwards as well.

cguentherTUChemnitz commented 5 years ago

@fbartels I will use this ticket for all my problems i am running into, when trying to setup this stack behind my reverse-proxy. If you want that i handle this in a different manner, than please let me know. As soon i have a validated running version, i will provide my insights as you suggested as an example file.

The current latest images seem to introduce a new problem using ssl-termination. I am using the most reset master (inluding the merge of https://github.com/zokradonh/kopano-docker/pull/112). When i try to access the webpage i get an Error 400 with the message:

[Mon Mar 18 13:53:23.352624 2019] [core:notice] [pid 7] AH00094: Command line: '/usr/sbin/apache2 -D FOREGROUND'
[Mon Mar 18 13:53:43.184689 2019] [:error] [pid 217] [client 192.168.128.3:44626] Rejected insecure request as configuration for 'INSECURE_COOKIES' is false.

Looing into the configuration of the webapp itself shows, that this one accepts insecure cookies:

docker exec -it kopano_webapp cat /etc/kopano/webapp/config.php | grep INSECURE_COOKIES
define('INSECURE_COOKIES', 'true');

I inspected my kopano networks and found that the container, which has currently the ip 192.168.128.3, is the web one, aka kopano_web. So i have to set this configuration for this one as well. Do you have such configuration mechanism for this container as well?

fbartels commented 5 years ago

I guess this is because of the quotes around the true. can you try https://github.com/zokradonh/kopano-docker/pull/115 ?

cguentherTUChemnitz commented 5 years ago

Thanks again for your fast fix ;)

fbartels commented 5 years ago

Issue resolved? If not please reopen (or create a new issue)