Can't install Matomo, perhaps due to Ghost, Nginx, or fastcgi_pass/php-fpm

Hi. I fell in love with the idea of having an open source alternative to Google Analytics, but I can’t materialize that dream because I can’t install Matomo.

I’m trying to do so in the same server as my Ghost blog. The blog is small, hosted at the free tier virtual machine that Amazon Web Services provides. There, I setup a machine with Ubuntu 18.04LTS, and have successfully made the website run with a valid SSL certificate. Broadly, that’s my situation.

Now, regarding Matomo, I figured that Nginx was a good bet because Ghost uses it. I think this also limits the memory and CPU usage of my measly machine. This is also why I have not used Docker or some other automatic installation app. Note that I’m aware I will need extra space in the future.

So what is the problem? I unzipped the Matomo files at /var/www/html, /var/www/, and my Ghost theme’s asset folder (which I guess wouldn’t be pertinent to you, but maybe), each in different attempts to get the Matomo installation website, and nothing. I get a 404 error.

I went step by step through the Nginx Matomo Github guide, and did everything except two steps. Those steps, I suspect, may be the issue.

Configuring PHP
The first step I couldn’t follow is configuring PHP. The Nginx Matomo Github guide says this step depends on my OS and PHP setup. Sure, but I don’t know the specific implications that having Ubuntu 18.04LTS, PHP 7.0.33, or Ghost 3.31.1has on the PHP configuration. The guide says I am probably using fastcgi_pass. Apparently, this requires php-fpm, which I didn’t have installed. This means Ghost, through Nginx, uses some other way to process PHP, right?

I tried to fix this by installing php-fpm and modifying the Nginx folders. The folder modifications were done following these steps*. Those steps, however were only half-done, because I was never able to create the elusive .sock file. It’s as if php-fpm really isn’t the way to go, given the usual Ghost and Nginx installation. What do you think? Given my Ghost and Nginx installation, how should I perform the PHP-configuration step?

The other step: restarting systemctl
This step may be a silly fix, or maybe it will lead me to another rabbit hole, just like the PHP configuration step. The thing is, it so happens that I cannot do the sudo systemctl restart command. My console tells me there are too few arguments. My guess is this isn’t as important as the above step. But I may be wrong.

It may be pertinent to say that my website used to work well up to a couple of minutes ago, when I was tinkering with the Nginx and php-fpm files. When I come back to this, I’ll try to first get my blog back on its own (perhaps having to do a clean install…) before tinkering further with Nginx, Ghost, and Matomo.

*Please note that by this point I had already modified the matomo.conf files as per the Nginx Matomo Github guide up to the PHP step, of course excluding the PHP step.

Hi,

I am the one who wrote the nginx guide and is using nginx exclusively for his websites, so I hope I can help.

As far as I know Ghost CMS uses Node.js and not PHP, so the setup would be completely different.

It doesn’t matter where you place your files (but /var/www/matomo/ would be a reasonable place) as long as you specify this path in the nginx config.

If you use nginx on ubuntu, you need php-fpm, so you just need to install it. There is no need to create or adjust socket files, the linked guide is for centos.

Yes it is, it’s just a stupid typo by myself. The command is sudo systemctl restart nginx to restart nginx. I’ll fix it in the docs.

Hey, Lukas!

Thanks for taking the time to respond and for your clarification.

I have good news: my blog is up and running now. For that to happen, I reinstalled nginx, Ghost, and php-fpm. Also, in my attempt to get Matomo up and running, I re-downloaded the .zip file you have on Github. Sadly, I haven’t been able to make it work.

My guess is I’m not facing a major technical hurdle, but small changes here and there. To understand where I am, I figured you may want to look at my matomo.conf file. Before linking it, I do want to point out a couple of things:

Every single time I modify the matomo.conf file at the sites-available, I delete the matomo.conf file at the sites-enabled and do a new symlink. I don’t know if this is overkill, since the symlink may update the file automatically or something, but I do it anyway just in case.

I just double-checked (just in case), and the big Matomo install files are indeed at /var/www.

/var/www/matomo$ ls
 CHANGELOG.md     'How to install Matomo.html'   LICENSE                PRIVACY.md   SECURITY.md   console   index.php   lang   matomo.js    misc       piwik.php   tests   vendor
 CONTRIBUTING.md   LEGALNOTICE                   LegacyAutoloader.php   README.md    config        core      js          libs   matomo.php   piwik.js   plugins     tmp

Lastly, I have been using the ssl file that was already in /etc/Nginx and not the one you provided. Maybe Ghost or LetsEncrypt put it there. Also, I don’t care about old browsers. I trust my two visitors have machines powerful enough to handle my dog pictures. Umm, I do hope I’m not making a mistake here.

Okay, so here’s the .conf files: https://github.com/gabrielpaipa/PlzWorkMatomoNNginx

Hi,

The main issue occurs a layer above your server. You set up your Matomo to point at matomo.yourdomain.example, but your DNS is not set up so that this domain points at your server:

; <<>> DiG 9.16.6-Debian <<>> matomo.yourdomain.example
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 33472
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;matomo.yourdomain.example.      IN      A

;; Query time: 16 msec
;; SERVER: 192.168.188.70#53(192.168.188.70)
;; WHEN: Mo Aug 31 20:05:34 CEST 2020
;; MSG SIZE  rcvd: 53

I guess that means I could be done with the .conf files. So what remains is making sure that people, when installing Matomo, are able to redirect their domains to the server where Matomo is.

I guess I have two options: mydomain.com/matomo or matomo.mydomain.com. I’ll consider each one.

matomo.mydomain.com
This ‘domain setup’ is how my .conf file is currently written.

Do I simply need to tell Google, my domain provider, to do as follows:

?

I tried doing exactly that, and now I no longer get a blank page at matomo.cafebuenvivir.com, but I do get a warning from Brave Browser saying the connection isn’t safe, as if SSL is freaking out. I disabled the SSL setting over at the Google Domain setup and am currently waiting for the changes to take effect. Maybe that’s it.

Another option is that I do indeed need separate SSL files for different subdomains, and so I’d need to run another letsencrypt script.

However, do note that I’m literally pointing at exactly the same IP address as with plain-old cafebuenvivir.com. Is that correct?

cafebuenvivir.com/matomo
What I like about this subdomain is that I guess I wouldn’t have to redirect URLs from my domain manager. I also think I wouldn’t need another LetsEncrypt script.

What I dislike is that I can’t make it work at the .conf level. I got errors whenever I tried it. The Nginx “-t” test didn’t like the slash ("/") or something. It said I had suspicious symbols. I tried Googling the error but it seems as if nobody is having the exact issue I’m having. My guess is I don’t know how subdomains work with Nginx.

Hi,

I’d strongly recommend to go with the former. They are two separate websites that nginx has to forward to two separate programs (nodejs-ghost-server or php-fpm). Keeping them in two separate virtual hosts makes this by far the easiest.

Yes, this is the right thing to do. Alternatively you could point *.yourdomain.example to the IP, which avoids a long list of subdomains.


The SSL issue is because the SSL certificate is for the main domain. You would need to run certbot again to generate new certs (sudo certbot certonly -d matomo.yourdomain.example) and then edit the two lines in the nginx config.


And for the main issue, make sure you have restarted nginx, that /var/run/php/php7.2-fpm.sock exists (if you are running php 7.0, then it might rather be php7.0-fps.sock) and check the nginx error log if the error persists.