[bitnami/matomo] Wrong include paths due to symlinks

[tmechsner]

Name and Version

bitnami/matomo 0.2.26

What architecture are you using?

amd64

What steps will reproduce the bug?

We are running this chart with the (anonymized) values given below. On the volume we inserted a backup containing the folders config, js, misc and plugins into the directory /bitnami/matomo/. Then nothing works, tracking, plugins, auto archiving etc., because in all these scripts relative imports of matomo core files are used. However, relative imports don't work here, because the actual base directory is /opt/bitnami/matomo/ which contains symlinks to the directories listed above. So, we fixed the files on the pv with relative imports and changed them to absolute paths. Then everything worked as expected. However, after a matomo restart all these scripts on the pv get overwritten and contain the non-functioning relative imports again. Changing the imports manually fixes the problem until the next restart.

Are you using any custom parameters or values?

namespaceOverride: tracking
image:
  tag: 4.14.1-debian-11-r0

matomoEmail: webadmin@xyz.com
matomoWebsiteName: Website Tracking
matomoWebsiteHost: tracking.website.com

smtpHost: "smtp-relay.mail-service.com"
smtpPort: 587
smtpUser: "user@website.com"
smtpPassword: "12345"

replicaCount: 1

updateStrategy:
  type: Recreate

persistence:
  enabled: true
  existingClaim: matomo-matomo-new

volumePermissions:
  enabled: true

resources:
  requests:
    cpu: 400m
    memory: 800Mi
  limits:
    cpu: 600m
    memory: 1Gi

service:
  type: NodePort

readinessProbe:
  enabled: true
  path: /matomo.php

livenessProbe:
  enabled: true
  path: /matomo.php

ingress:
  enabled: true
  ingressClassName: nginx
  hostname: tracking.website.com
  tls: true
  annotations:
    kubernetes.io/tls-acme: "true"
    nginx.ingress.kubernetes.io/ssl-redirect: "true"

What is the expected behavior?

We expect the symlinked folders on the pv to work like in every other non-cloud matomo installation without the need to manually modify the files. If this is not possible, we at least expect our modifications on the persistent volume to persist and not get overwritten on matomo restart, which breaks the tracking.

What do you see instead?

Lots of "File not found" errors, because relative imports from the symlinked directories in /bitnami/matomo/ don't work, as the base application files are in /opt/bitnami/matomo/

Additional information

No response

[tmechsner]

I just thought that this is probably more related to the bitnamit/matomo image? I could reopen the issue on the bitnami/containers repository as well.

[rafariossaa]

Hi, Could you share the logs ? This function should be detecting that there is an already deployed matomo and should not be doing all the first start initialization.

Regarding the symlinks, it should not be a problem if you use relative paths. In fact, matomo scripts uses relative paths to include other scripts.

[tmechsner]

I don't have the logs right now - will share them as soon as I can find the time to reproduce this in a non-production environment.

The part of the code you pointed out is exactly the one that causes our trouble. If is_app_initialized is true, we jump to line 209. In the following lines the js and plugins directories of the core get r-synced into the volume and overwrite our corrected scripts (where we replaced the relative imports with absolute paths) with the defaults (lines 213 and 216). This behavior would be okay if the default scripts worked fine - which is not the case for us :(

[rafariossaa]

Hi, Could you elaborate on the relative imports issue ? I think I am not fully understanding which is the issue. The files are copied to the persisted volume because in the case of an image upgrade you would need to have the new version of the scripts.

[tmechsner]

Sure. I'll take the script js/tracker.php as example. It contains the following lines:

define('PIWIK_DOCUMENT_ROOT', '..');
// ...
define('PIWIK_INCLUDE_PATH', PIWIK_DOCUMENT_ROOT);
// ...
if (is_dir(PIWIK_INCLUDE_PATH . '/vendor')) {
    define('PIWIK_VENDOR_PATH', PIWIK_INCLUDE_PATH . '/vendor'); // Piwik is the main project
} else {
    define('PIWIK_VENDOR_PATH', PIWIK_INCLUDE_PATH . '/../..'); // Piwik is installed as a Composer dependency
}

// Composer autoloader
require PIWIK_VENDOR_PATH . '/autoload.php';

This file gets copied to the volume so that it lies under /bitnami/matomo/js/tracker.php. The /bitnami/matomo/js directory is symlinked by /opt/bitnami/matomo/js.

When calling this script, the logs show the error that autoload.php could not be found although it is present in the expected location: /opt/bitnami/matomo/vendor/autoload.php.

When I change the definition of the PIWIK_DOCUMENT_ROOT from .. to /opt/bitnami/matomo the error is gone. So I think what's happening is that when calling is_dir or require with these relative paths PIWIK_INCLUDE_PATH points to /bitnami/matomo/js/../ which is the volume root directory and not the matomo core directory (/opt/bitnami/matomo), which would be expected. Hence, the autoload.php cannot be found in both cases of the if-statement - neither in /bitnami/matomo/js/../vendor/ nor in /bitnami/matomo/js/../../...

[rafariossaa]

Hi, I did the following test. If I run inside the pod

$ curl http://localhost:8080/js/tracker.php

I am getting the following error in the log and not response for the curl command:

matomo_1   | 127.0.0.1 - - [09/May/2023:09:07:26 +0000] "GET /js/tracker.php HTTP/1.1" 200 4
matomo_1   | [09-May-2023 09:07:35 UTC] PHP Warning:  require_once(../libs/upgradephp/upgrade.php): Failed to open stream: No such file or directory in /bitnami/matomo/js/tracker.php on line 38
matomo_1   | [09-May-2023 09:07:35 UTC] PHP Fatal error:  Uncaught Error: Failed opening required '../libs/upgradephp/upgrade.php' (include_path='.:/opt/bitnami/php/lib/php') in /bitnami/matomo/js/tracker.php:38
matomo_1   | Stack trace:
matomo_1   | #0 {main}
matomo_1   |   thrown in /bitnami/matomo/js/tracker.php on line 38

If using the docker-compose, the same happens, but if I get into the container and remove the symlink, it works.

$ docker exec -u root -it  matomo_matomo_1 bash

root@f36893b4e2e6:/# cd /opt/bitnami/matomo
root@f36893b4e2e6:/opt/bitnami/matomo# mkdir js2 
root@f36893b4e2e6:/opt/bitnami/matomo# cp -r js/* js2/
root@f36893b4e2e6:/opt/bitnami/matomo# ls js2/
root@f36893b4e2e6:/opt/bitnami/matomo# rm js
root@f36893b4e2e6:/opt/bitnami/matomo# mv js2 js  

root@f36893b4e2e6:/opt/bitnami/matomo# curl http://localhost:8080/js/tracker.php

;if(typeof _paq!=="object"){_paq=[]}if(typeof window.Matomo!=="object"){window.Matomo=window.Piwik=(function(){var r,b={},z={},J=document,g=navigator,ab=screen,W=window,h=W.performance||W.mozPerformance||W.msPerformance||W.webkitPerformance,t=W.encodeURIComponent,V=W.decodeURIComponent,k=unescape,L=[],H,u,al=[],y=0,af=0,X=0,m=false;function p(at){try{return V(at)}catch(au){return unescape(at)}}function M(au){var at=typeof au;return at!=="undefined"}function C(at){return typeof at==="function"}function Z(at){return typeof at==="object"}function x(at){return typeof at==="string"||at instanceof String}function ak(at){return typeof at==="number"||at instanceof Number
....

I am creating an internal task in order to address this.

[tmechsner]

That is exactly what I'm talking about, thanks for your effort!

[mdhont]

@tmechsner, we have released a new container chart version that persists the Matomo base directory instead. Please let us know if you encounter any issues.

https://github.com/bitnami/charts/pull/16982

I'm marking this issue as resolved for now.