Is the Matomo Debian package dead?

[nomandera]

I absolutely hate posts like this because FOSS should not be about timescales and deliverables BUT this is also the official apt repository for a commercial product listed to this day as a supported method of installation.

I dont want to labour the point but some details are listed here

To summarise:

• Matomo 3, whilst technically still officially supported, receives no updates and speaking personally this also extends to plugins (even all the subscription ones we pay for). It has in all practical ways been put out to pasture.
• Matomo 3 will install and upgrade on Debian 9 but if you are running this OS in a commercial environment you will likely be getting told it fails security accreditation now.
• Matomo 3 will not install or upgrade on Debian 10. If you try it will break badly.
• All development and innovation seems to be on Matomo 4 which cannot be updated to or installed direct using apt.

I apologise for making this post but we are closing in on a year of missed updates and I am now at a cross roads. The effort to port from apt to manual install will be huge and I both dont want to do it or tell people how much its going to take in man hours.

Please can we have a roadmap.

[Findus23]

I just updated the title to make it clear this is about the debian packages as this repository also contains build-package.sh which is the main way all Matomo releases are created and is updated for this all the time.

[nomandera]

Yes thank you that is a worthy and important clarification to make.

[mattab]

Thanks @nomandera for your interest. I've talked to the previous maintainer and I can confirm that he is not going to maintain the Debian package anymore.

So at this point we have two options:

• Deprecate the package, close it, make it clear that it won't be maintained anymore
• Find a new maintainer, who uses this package in production, and who could own this package (and eventually help us automate the debian package release using github actions)

Is there maybe anyone reading this who would be interested to take over the debian package for Matomo?

we do have quite solid docs and scripts that @aureq created, but it does need some work and knowledge of Debian.

[Dreamsorcerer]

Not sure it makes sense to close all the other issues. If there is a new maintainer, then many of those issues probably need to be reopened.

[mattab]

@Dreamsorcerer Most issues seem really low impact, and hadn't been commented/touched for years. Trying to be pragmatic and have a clean slate for whoever comes next (if we're lucky to find a new maintainer...)

[Dreamsorcerer]

No problem, I guess just a "reopen if this still affects you" then. I do see that some of them appear to have been fixed, although probably need some documentation.

[nomandera]

Is there any option for Team Matomo to step in and take over even if it is a temporary measure?

During my initial research of install options the official announcement and apt repository left no doubt that the project was backed by Team Matomo.

Sorry if this seems negative, just feeling a bit left out in the rain here given that the very first time we need the Matomo team to maintain the Debian Matomo repository the response it to twilight the project and call for the community to step in or it will be closed.

[mattab]

@nomandera thanks for the note! the blog post now redirects to the official non-debian installation guide, to remove any possibly confusion.

we've also redirected https://debian.matomo.org/ for now, to make sure nobody else could get false expectations.

FYI Looking at some basic server logs stats, we can see that Since Jan 1st 2020 there were only 244 downloads of the release matomo_3.10.0-1_all.deb. So it looks to me like Debian package is not a very popular installation method.

Big thanks and kuddos to @aureq for his work all these years maintaining the package! 👏

[BenSturmfels]

@nomandera thanks for the note! the blog post now redirects to the official non-debian installation guide, to remove any possibly confusion.

@mattab just wanted to note that I found the redirection from the Debian repo to the installation guide quite confusing! Would it be possible to redirect to a paragraph explaining that the Debian repository is no longer supported? I don't think the redirection alone communicates this effectively - I very nearly opened an issue about the redirection heh.

Thanks for all your work on Matomo - I've been a happy user for many years! Thanks @aureq too!

[BenSturmfels]

PS. This is still live in the docs:

How do I install Matomo on Debian GNU/Linux servers?
https://matomo.org/faq/how-to-install/#faq_17844

Perhaps this is a good place to explain that the Debian package is no longer supported?

[nomandera]

Since it is looking likely that the repository will be gone now forever could instructions on how to migrate to a supported install be provided as a sign of good faith from Matomo?

[Findus23]

@nomandera If I can find some time in the next days, I'll write something. As I never used the package and can't reliably test it, this would be more of a community wiki for everyone to contribute to.

[nomandera]

I very much appreciate the efforts @Findus23 as currently we are all feeling pretty annoyed at Matomo over here.

We followed the official install guide, purchased and renewed several addons during the subsequent years, contributed time and effort in this project and for our troubles we are now left with a a load of completely unmaintainable installs in the Douglas Adams style of "So long and thanks for all the fish".

This is what happens if a project just kills a repo:

Reading package lists... Done  
E: Failed to fetch http://debian.matomo.org/dists/piwik/InRelease  Clearsigned file isn't valid, got 'NOSPLIT' (does the network require authentication?)
E: The repository 'http://debian.matomo.org piwik InRelease' is no longer signed.
N: Updating from such a repository can't be done securely, and is therefore disabled by default.
N: See apt-secure(8) manpage for repository creation and user configuration details.

[mattab]

@BenSturmfels Thanks for the note the FAQ has been fixed

Thanks for the hint @nomandera - we restored the website at https://debian.matomo.org/ so it still works for now. (i hadn't realised setting a redirect would have broken the system...)

To install Matomo on Debian:

1. your system can meet the requirements
2. then proceed to install Matomo by following the instructions in our Matomo Installation Guide.

And when you install Matomo using these steps, you can enter the DB credentials of your existing database (the one that was managed by Debian before, you will find the DB credentials in the config/config.ini.php file), so your database will be reused and no data be lost.

Maybe @Findus23 will provide more details, or you can write here any questions or issues, we will help you migrate

[BenSturmfels]

Thanks @mattab! I still feel it would have been helpful to me to have a more direct statement in that FAQ answer such as "The previous Debian package repository is no longer actively maintained. We recommend migrating to the our standard installation approach." Thanks again.

[mattab]

@BenSturmfels we've just updated the page at https://debian.matomo.org/ - hope it's more clear. i'll leave the FAQ as is I think as people would easily find https://debian.matomo.org/ if they search 👍

[BenSturmfels]

Thanks @mattab

[nomandera]

OK we are definitely making progress but we are not there yet.

The instructions

To install Matomo on Debian:

    your system can meet the requirements
    then proceed to install Matomo by following the instructions in our Matomo Installation Guide.

is fine for a new install but if you were to follow this as-is for an exiting apt install you would end up with a Frankensteins monster of two installs.

I would suggest we should be looking at an initial backup phase (of what I cant say) and then an apt remove or even and apt purge of apache2 matomo.

WARNING: untested please anyone following this thread dont just try this without being able to recover.

So what actually

• needs backed up beyond config/config.ini.php and the database?
• How closely do the apt and manual install versions os Matomo need to be (remember everyone on apt is almost a year out of date)

[Findus23]

Create a backup of everything (Matomo files and Database) is always a good thing.

In theory nothing needs to be backed up (even config/config.ini.php can be regenerated by going through the installer again).
But there are a few things that will be lost:

• installed Plugins (not their settings)
• GeoIP database (you can find them in misc/)
• custom logos and favicons (also in misc/)
• salt (in not copying the config) which means password resets, things like this and maybe logged in sessions will be lost

You can download every release of Matomo from https://builds.matomo.org/ which would allow you to migrate to the identical version and afterwards update. In theory you can do both things at once, but I think doing them separately is easier.

Things you also need to set up, that the debian package included:

• The apache config of your webserver
• The archiving cron job: https://matomo.org/docs/setup-auto-archiving/
• A logrotate of the output of the cronjob (if you like): https://github.com/matomo-org/matomo-package/blob/master/debian/conf/matomo-log

Also I noticed that an apt remove deletes the Matomo directory so maybe copy it somewhere else first.

[nomandera]

Just to confirm.

Is Matomo going to provide a set of upgrade instructions to port apt existing users to a mechanism that is still supported or is this on the community?

I ask because I have been tasked with pulling this off here and I dont want to forge ahead trying to work this out on the fly if an correct/official methodology is forthcoming.

[Findus23]

@nomandera
As noone asked here anymore, I assumed the steps explained above were enough.

But if you have any questions, I can answer them when they arise.

[nomandera]

Thanks for the follow up. I just assumed that since apt was an official install method and since it has now been officially removed that some guide to port would be forthcoming.

There is a big difference between a series of tips and a official supplied and tested migration document.

Please realise that those of us with this in commercial production are now in a situation of having to build, R&D and test this procedure. This is unplanned cost and not an easy sell.

It is what it is I suppose but Matomo did not shine here. Far from it.

[e-gaulue]

Hi all,

For those interested in trying the "new" repository, you can add "next" to the classical https://debian.matomo.org/ URL.

Be careful, this documentation has been written as if it was already the production repository. So do not forget to add next to the URL in the source.list. And remember you'll have to remove it as soon as this site will be in production.

I don't see any reason why it would not work for you, but I believe there are hundreds of different configurations, so we never know. Feel free to discuss here any point that could be improved regarding this package availability and installation.

If most of you reports success, this "next" alias will be removed to become the production URL at the beginning of April.

Best regards,

[colans]

@e-gaulue So, instead of https://debian.matomo.org/, use https://debian.matomo.org/next before April 1st?

[e-gaulue]

@colans Yes, exactly, I just wanted to avoid this URL to be referenced by search engines. I added noindex,nofollow.

[colans]

Seems to work fine when upgrading from an old DB, even though I got this error (which didn't affect anything):

[...Lots of DB updates...]
Matomo has been successfully updated!
Segmentation fault (core dumped)
dpkg: error processing package matomo (--configure):
installed matomo package post-installation script subprocess returned error exit status 139

It killed my terraform apply, but then I re-ran it without problems.

So I'd say this is a success. Thank you! 🚀

[tombreit]

Same here:
Quoting @colans : Seems to work fine when upgrading from an old DB, even though I got this error (which didn't affect anything):

[...]
Matomo database will be upgraded from version 3.14.1 to the new version 4.7.1.
[...]
Matomo has been successfully updated!

Segmentation fault
dpkg: error processing package matomo (--configure):
 installed matomo package post-installation script subprocess returned error exit status 139
Errors were encountered while processing:
 matomo
E: Sub-process /usr/bin/dpkg returned an error code (1)

Thank you for bringing this package back to life.

[e-gaulue]

That's the second time this point is underline. I will look at it.

[WhilelM]

Segmentation fault here too, but during tables update.

Matomo database will be upgraded from version 3.14.1 to the new version 4.7.1.

[...]
Executing UPDATE piwik_archive_numeric_2019_09 SET name = 'done' WHERE name = 'done.';... Done. [265 / 537]
Executing UPDATE piwik_archive_numeric_2019_10 SET name = 'done' WHERE name = 'done.';... Done. [266 / 537]
Executing UPDATE piwik_archive_numeric_2019_11 SET name = 'done' WHERE name = 'done.';... Done. [267 / 537]
Executing UPDATE piwik_archive_numeric_2019_12 SET name = 'done' WHERE name = 'done.';... Done. [268 / 537]

Installation is interrupted. Lost message mentionning that's the table piwik_segment that was in update at the segfault.

In kern.log got this

Mar 28 12:22:23 server kernel: [12925988.725592] php[32306]: segfault at 17 ip 00007f8ce4e15dc7 sp 00007ffd11a95d50 error 4 in pdo.so[7f8ce4e0d000+c000]
Mar 28 12:22:23 server kernel: [12925988.725647] Code: 9f 73 ff ff 48 89 ef e8 e7 79 ff ff e9 42 fe ff ff 66 90 4c 89 f8 48 8b 7c 24 08 4d 8b 06 48 c1 e0 05 48 03 43 18 48 8b 0c 38 <0f> b6 41 18 3c 39 0f 8e d9 07 00 00 48 89 ea 48 89 ce 4c 89 c7 e8

I restored a backup of database to give it another try, followed by apt install -f. New segfault, at the same point.

Executing UPDATE piwik_archive_numeric_2022_01 SET name = 'done' WHERE name = 'done.';... Done. [294 / 541]
Executing UPDATE piwik_archive_numeric_2022_02 SET name = 'done' WHERE name = 'done.';... Done. [295 / 541]
Executing UPDATE piwik_archive_numeric_2022_03 SET name = 'done' WHERE name = 'done.';... Done. [296 / 541]
Executing ALTER TABLE piwik_segment ADD COLUMN hash CHAR(32) NULL AFTER definition;... Done. [297 / 541]
Segmentation fault
dpkg: erreur de traitement du paquet matomo (--configure) :
installed matomo package post-installation script subprocess returned error exit status 139
Des erreurs ont été rencontrées pendant l'exécution :
matomo
E: Sub-process /usr/bin/dpkg returned an error code (1)

[...]

In kern.log got this

Mar 28 17:14:00 server kernel: [ 8222.154096] php[11785]: segfault at 17 ip 00007faa2a822dc7 sp 00007ffd6d160220 error 4 in pdo.so[7faa2a81a000+c000]
Mar 28 17:14:00 server kernel: [ 8222.154149] Code: 9f 73 ff ff 48 89 ef e8 e7 79 ff ff e9 42 fe ff ff 66 90 4c 89 f8 48 8b 7c 24 08 4d 8b 06 48 c1 e0 05 48 03 43 18 48 8b 0c 38 <0f> b6 41 18 3c 39 0f 8e d9 07 00 00 48 89 ea 48 89 ce 4c 89 c7 e8

[e-gaulue]

@WhilelM

If the trouble is just in the database upgrade process, this means new matomo script files are already here. I would just reset the database to the backup and go to the back office admin update page or invoke /usr/bin/php /usr/share/matomo/console core:update. Maybe you will get more information as it will be interactive.

You can also stop package installation to automatically run core:update as non interactive by doing: sudo dpkg-reconfigure matomo.

Regards

[mattab]

The segmentation fault we document here: https://matomo.org/faq/troubleshooting/faq_131/
The solution is typically to "update PHP" or update other bits of the system.

I have a question: although it failed with this error, is the Matomo actually working or not?
It's possible that it errored, but actually everything worked and there is no impact.
If that's the case then maybe the error can be ignored for now?
or is it a blocking issue?

[colans]

@e-gaulue @mattab Do you folks have a new ETA for when the new site will go to Prod (as it doesn't seem to be the beginning of April anymore)? We have some infrastructure work planned, which is depending on this, but can't start it until that happens. Thanks for getting this up & running again!

[e-gaulue]

I hoped to do it last week-end, but I didn't get the time. I'll try to find the time, one of this night (not next for sure), before next week-end. It won't take long. I'll will just change the link to have the site in production and add a warning regarding those core dumps happening during core:update. I will mention the link provided by @mattab and maybe the github issues page.

If really a problem, we can go back to a package where core:update is not run by the package as a default, so we just get a warning message requesting us to do it. But, I remember, I often didn't see it or forgot to run it, so I was happy when this option has appeared a few year ago.

[e-gaulue]

@colans Should be online right now!

[WhilelM]

Hello, how things are going for this repository ? I'm not able to find updates for months.

[e-gaulue]

You are right, I'm going to build new debs in the next days.

Building those deps with a production skill is rather fastidious. The best I found is to build them all twice a year (3 to 6 versions each time). It's something like 1 hour for the first and 10 minutes for the next ones if everything is OK. It's sometimes worse depending on the changes in the sources.

Regards,

[sgiehl]

@e-gaulue Do you see any possibility to maybe automate that process using a github action? We could then trigger that action after each release

[e-gaulue]

Well, it's always the same with Debian. Fast package distribution has never been in its scope.

Package building is closely linked with lintian. If almost nothing change, we are in the 10 minutes process I spoke. If ever lintian complains you have to analyse the reasons: new/rename files/directory, missing licence file, providing library while a Debian package already exists... I discover new ones as long as I build some, that happens every 2/3 building process.

I've already changed scripts to detect filename changes before lintian, but to go to a full automation looks to me hard. Moreover, it's not this way Debian would like things to be done. It hopes package builders to look as much as they can to the content they provide. I mean when lintian fail, most of the time it's because you have to make a decision.

There are two kind of changes in the commits I pulled. Some are needed by the core of the Debian building process (rare) and the other are just here to satisfy lintian.

Regards,

[e-gaulue]

Just to inform 6 versions were built this week-end. It would be really hard to build 2 packages when two versions have been released the same day. Anyway, changelog is the same. Only the last one is build.

@sgiehl We should reorganize this repository since it's only use for Debian for more than a year now. Accept pull requests. Remove scripts and maybe archives directories. Change README.md to link to https://github.com/matomo-org/matomo-package/tree/master/debian#readme...

Regards,

[mattab]

Great work @e-gaulue - Thank you for your contributions to Matomo Debian package 💪 🎉

[MatthiasKuehneEllerhold]

I noticed that the latest version of matomo on https://debian.matomo.org is 4.13.3-1 ...
Are these scripts here used for the packages in this repo? Is this repo still in use and will it get new versions or should I build the packages myself?

[mattab]

Thanks for the feedback @MatthiasKuehneEllerhold
@e-gaulue Maybe you have some feedback about this, or could it be that you maybe don't have time anymore to maintain this project? in which case we could look for a new maintainer maybe, or find someone to help..

[e-gaulue]

@MatthiasKuehneEllerhold and @mattab

I'll look at it this week-end. I should be able to produce new versions till 4.15.0 (7 versions). Just notice that Debian Bookworm is out for 3 months now. I still haven't migrate my own servers to this system, so I may need more time to have a package working with Bookworm, or not... Package may be installable, but the building process mays be broken. Everything is possible.

For Matomo 5, depending on the size of the changes, it may also require more time.

Lots of people use snap nowadays. It looks easier to install, update and it's more portable (all linux platforms). As an admin sys, I'm not so fond of it, as it's often not tested as much as Debian packages are. There are pros and cons. But maybe Matomo could provide this kind of snap for those not so concerned by security and reliability and who want new version as soon as possible.

[e-gaulue]

@mattab

I've build the first package, but I can't connect to matomo.org server anymore. Is there new protocol?

I need to build every package and upload them sequentially, in order the process to work normally.

Regards,

[mattab]

@e-gaulue thanks for your quick answer!
can you maybe reach out on slack and I can help resolve the issue with permission?

[MatthiasKuehneEllerhold]

My system just updated to 4.14.1. Im eagerly awaiting further packages! Thank you very much.

My 2 cents regarding snap vs dpkg:
Were not using snap at all atm, so that would be a completely new system I'd have to familiarize myself with. So ... I'd like to keep installing the dpkg version but wouldnt be opposed to snaps. IDK if thats helpful for you or not ;-)

[vostorga]

Matomo debian package has not been updated since 4.15.1

[mattab]

Thanks @vostorga for the heads up. Sorry about the delay with the release. I've reached out to @e-gaulue to discuss our next steps. Hope to have an update within 2-3 weeks.

[vostorga]

Thank you very much for your fast reply

[e-gaulue]

This post to inform Debian matomo v5 package is out.

Please report any issues whose resolution could/should be included in this package.

[mattab]

Congrats @e-gaulue! Thank you for your great work! 👏

[MatthiasKuehneEllerhold]

The newest version on https://github.com/matomo-org/matomo is 5.1.0 (released 3 weeks ago), but the newest version on the debian repository is 5.0.3.