Run Icingaweb behind Rancher web proxy

Hi,

we are using the the Docker image jordan/icinga2 for deploying Icinga2 and Icingaweb2 on our Kubernetes cluster. This also installs a services named icinga2 on port 80 so you can access Icingaweb2.

But there is also an other way of reaching web applications like this. You simply log in to Rancher and then open a address like this:
https://rancher.example.com/k8s/clusters/c-abcde/api/v1/namespaces/icinga2/services/http:icinga2:80/proxy/icingaweb2

It proxies the web application in Namespace icinga2 on cluster abcde provided by the service with name icinga2 on port 80.

If I go to this URL the Icingaweb2 login screens appears. If I login now I instantly get an CRLF exception and stack trace. So I modified /etc/icingaweb2/config.ini on the POD by adding this cookie path:

[cookie]
path = "/"

Now I am able to login, but then the next problem occurs. At first CSS, HTML, JS, SVG and PNG files are loaded correctly. But then the Javscript from icinga.min.js starts working. It tries to load the services using this URL: https://rancher.example.com/icingaweb2/monitoring/list/services?service_problem=1&limit=10&sort=service_severity&showCompact=1
But of course this is wrong. It should be this one: https://rancher.example.com/k8s/clusters/c-abcde/api/v1/namespaces/icinga2/services/http:icinga2:80/proxy/icingaweb2/monitoring/list/services?service_problem=1&limit=10&sort=service_severity&showCompact=1

Is there a way to convince the background Javascript jobs to use the correct base URL? Or is Icingaweb2 designed to always use the sub path /icingaweb? Or is it an issue with absolute and relative URLs?

Anyway it would be really cool if there is some configuration I am not aware of to solve that issue.

Here some additional information:

  • Icinga Web 2 2.8.2
  • Git Commit 8a89839af94a247ee2149b2336c73b8251b477c0
  • PHP Version 7.3.19-1~deb10u1
  • modules:
    • director 1.7.2
    • doc 2.8.2
    • incubator 0.5.0
    • ipl v0.3.0
    • monitoring 2.8.2
    • reactbundle 0.7.0
  • Debian GNU/Linux 10 (buster)
  • Firefox 98.0.2

The Icingaweb is delivered via a web service (ngix, apache).
There are corresponding configurations that map to the paths of the requests.
For example, I deliver the web interface via a subdomain (icinga.domain.tld) and via a path.
I think you need to configure the web service in the container cleanly.

I think the issue starts with loadDashlets in icinga.min.js after loading the structure of the main interface:
grafik
(Hint: right click on the image and open it in a new tab)
As you can see it tries to load the dashboard using AJAX with an absolute path instead of an relative path. Because of that the dashboard loads from the wrong URL:
grafik

Any idea how to fix this withing Apache? Or is it possible to change that absolute URL somewhere else in the configuration?

The apache configuration is pretty standard at the moment:

Alias /icingaweb2 "/usr/share/icingaweb2/public"

<Directory "/usr/share/icingaweb2/public">
    Options SymLinksIfOwnerMatch
    AllowOverride None

    SetEnv ICINGAWEB_CONFIGDIR "/etc/icingaweb2"

    EnableSendfile Off

    <IfModule mod_rewrite.c>
        RewriteEngine on
        RewriteBase /icingaweb2/
        RewriteCond %{REQUEST_FILENAME} -s [OR]
        RewriteCond %{REQUEST_FILENAME} -l [OR]
        RewriteCond %{REQUEST_FILENAME} -d
        RewriteRule ^.*$ - [NC,L]
        RewriteRule ^.*$ index.php [NC,L]
    </IfModule>

    <IfModule !mod_rewrite.c>
        DirectoryIndex error_norewrite.html
        ErrorDocument 404 /error_norewrite.html
    </IfModule>
</Directory>

I also tried the virtualhost configuration from the documention for running icingaweb on the root path: https://github.com/Icinga/icingaweb2/blob/master/doc/20-Advanced-Topics.md#virtualhost-configuration-for-apache-

But this results in the same issue.