The installation is skipped indeed if all needed fields are there in the config and if database tables exist. I'm not quite sure what the exact problem is? Did you want to install Piwik via command line by providing parameters like "--database-host"?

Yeah, the main issue is that headless installation is not supported and one has to use the ui to provide the db connection and bootstrap the database. While this is ok for one-off installations, it becomes problematic when you're doing automated provisioning.

The config way was one idea, ideally the main outcome would be to have a way to install Piwik up to a state where the admin user is created, without requiring manual steps.

got it. I thought I created a similar issue a few years ago when I built a vagrant box for Piwik but cannot find it anymore. Possibly I didn't actually create the issue. It would be a useful feature to have nowadays.

Basically we would only need to create the config file from the input and validate the entered data. For validation and creation of config file everything is already here so it shouldn't be too complex

Hi @dessant

we may in the future release such a tool as open source. If your company can support us in this area, please get in touch via https://piwik.org/contact/

Let's say the automation can be run with a script named install-piwik.sh, we need 2 different ways to provide the configuration:

• command lines args (e.g. install-piwik.sh --dbuser=myuser --dbpassword=pass ...) => drawback: the tool appears in the command history
• install.ini file (running install-piwik.sh will then remove install.ini, so it can be more secure)

If someone is keen to work on this I'm happy to assist. Be good to have this

I had a stab at this yesterday. It's not particularly brilliant, but gets the job done for me.
I'm running docker containers, so it's not really an option for me to use the CURL method.
For anyone interested: https://github.com/nebev/piwik-cli-setup

Thanks @nebev , I'm no programmer but I can think of some more features or maybe it should be a different script?

1. Option to upgrade instead of installing
2. Option to fetch the source from http://builds.piwik.org/latest.tar.gz (or any version) or a local directory.
3. Test download against *.asc PGP signature.

I'm also wondering if such script should be maintain by Piwik CoreTeam once interest grow?

All in all, thanks anyway for sharing the code. :)

I'm also very interested in an automated mechanism to complete the initial configuration and creation/update of the db tables. 👍

Please note we have this automation available but it's one of the rare things we haven't published as Open source. If you want to access this please contact InnoCraft here: https://www.innocraft.com/#contact

As for me I wanted to have a cli installer in order to make a custom docker image.

I have been looking at how to script Piwik installs and came across the Cauldron install script which adopts another approach to this problem from the examples above -- using a minimal MySQL dump to populate the database and then using the php console script to setup the config file.

Hi, I'm the author of that Cloudron package and I think it is a quite bad hack using the sql dump. Since I lack deeper knowledge of the piwik install process, this was just an option to get around the setup in our case, but I would not recommend that in the long run at all. The alternative solution I did first was to replay the requests to the setup webinterface via script, but that was even uglier.

I agree. SQL dump is a bad idea as schemas change. Best to use API calls and existing functions where possible. I'm successfully running my CLI setup script in a docker image for brand new installs of Piwik 3.0.2.

I'm interested if anyone has a good solution to automatically install (and maybe upgrade) to the last stable version.
I'm trying to create an ansible playbook to setup the full stack and piwik is part of the environment.

I've been doing this via Chef, but it uses SQL dumps so as mentioned, isn't great long term. However, it means I can always install the same Piwik version correctly

Any news on this one? I have everything setup using docker and docker-composer including a customized config.ini.php file. It all works when I do a first manual run that creates the user and database tables, but if config.ini.php is present it fails (as was said above). Could we see matomo create/bootstrap the database when it's not there but the credentials are there?

Thanks!

While the ExtraTools plugin doesn't work for Matomo 4 yet, so the console command matomo:install can't be used for automatic installs, I have found that automating via the web installer is not so hard, see for example these Ansible tasks which are based on these tasks.

However I do agree with @bluikko — it would be great to have the ability to properly interact with Matomo using a CLI.

Just chiming in here, and agreeing that having Matomo CLI installation would be awesome.

You can install Drupal with Drush from the command line with this:

drush site:install --db-url=mysql://drupal9:drupal9@database/drupal9

It would be great if similarly you could download Matomo, instantiate whatever web server you like and install it:

matomo install \
--db-url=mysql://lamp:lamp@database/lamp \
--option user=admin \
--option pw=admin \
--option email=admin@example.org \
--option sitename='Example Org' \
--option siteurl=example.org

FYI: we managed to automate the installation in a docker environment without going through the web-wizard by
a) cloning the matomo github repo
b) cloning the ExtraTools-Plugin into the plugin directory
c) update composer dependencies (incl. sub-repositories)
d) build a custom docker image (especially requiring mysql-client / mysqladmin dependencies for ExtraTools)
e) running the parameterized install command from ExtraTools in the container

We also added several other plugins and install those properly by ExtraTools.

@arosenhagen , how do you create the database? I've tried to repeat the steps you tell above, but it doesn't allow to activate ExtraTools as there is no database created (and I've to activate ExtraTools for being able to run step e ).

FYI: we managed to automate the installation in a docker environment without going through the web-wizard by a) cloning the matomo github repo b) cloning the ExtraTools-Plugin into the plugin directory c) update composer dependencies (incl. sub-repositories) d) build a custom docker image (especially requiring mysql-client / mysqladmin dependencies for ExtraTools) e) running the parameterized install command from ExtraTools in the container

We also added several other plugins and install those properly by ExtraTools.

It does work but it is very, very painful.

The most stupidest thing of all (...I've ever seen?!) is that the database is not fully initialized until first HTTP GET to the website!!

Following @arosenhagen message #10257 (comment) guidance, I've managed to get a full unattended installation, doing some tinkering with ExtraTools (https://plugins.matomo.org/ExtraTools). Those are the steps I've followed:

1. Choose your favourite method for getting a uninitialized Matomo server (in my case, I was using a docker compose configuration like https://github.com/matomo-org/docker/blob/master/.examples/apache/docker-compose.yml). I've not tried installing from zip or git in a PHP server, but I guess it doesn't change so much.
2. Install ExtraTools server dependencies:
   apt update && apt install -y unzip mariadb-client
   (Dependency is actually mysqladmin, but for mariaDB it comes into mariadb-client package).
3. Install composer.
4. If Matomo composer.json is missing, add it (i.e. from GitHub: https://raw.githubusercontent.com/matomo-org/matomo/4.7.1/composer.json ).
5. Install ExtraTools composer dependencies: https://plugins.matomo.org/ExtraTools#documentation.
6. Install ExtraTools: Download zip, uncompress and move it to plugins directory.
7. Copy a config.ini.php in Matomo config dir, containing database connection parameters only.
8. Copy plugins/ExtraTools/Commands/InstallMatomo.php to plugins/CoreConsole/Commands and change its namespace to Piwik\Plugins\CoreConsole\Commands: Here is where the magic is. ExtraTools is not going to work initially; there is no database created yet so ExtraTools activation fails. Doing this copy, the next step will work.
9. Run matomo:install command: Installation parameters can be added as command arguments, but it's easier to create an install.json file (like in https://github.com/digitalist-se/extratools/blob/4.x-dev/docs/example.json):
   console matomo:install --install-file=install.json
10. Delete temporary plugins/ExtraTools/Commands/InstallMatomo.php.
11. Add an initial site (current ExtraTools version doesn't create any site in matomo:install).
12. As I'm building a docker container, cleaning up (mariadb-client, ExtraTools, composer...).

All steps can be easily automated in a script or Dockerfile.

I hope it helps someone there. As I said is mostly tinkering, and I think this feature would have to be available in vanilla Matomo, as unattended containers or virtualized installations are common today.

Hey @vikenbauer I am trying to get this set up on a serverless system. Therefore, I am extending the Docker image for matomo:alpine and writing the steps you mentioned in that Dockerfile.
However, I seem to be getting this error when running matomo:install:
[Exception] Adapter 'mysql' is not valid. Maybe check that your Matomo configuration files in config/ *.ini.php are readable by the webserver.
I have given the folder read and write access to everything in config/ and also doublechedk with ls -l any ideas on what could be wrong?

Trying to activate the ExtraTools plugin leads to the following error:
[PDOException] SQLSTATE[42S02]: Base table or view not found: 1146 Table 'matomo.matomo_option' doesn't exist

I updated the confg.ini.php to only have db connection params and the plugin now activates however, still getting the same error on matomo:install.
On closer inspection, matomo:install seems to be changing the config.ini.php file to include adapter = "mysql" under [database]

All steps can be easily automated in a script or Dockerfile.

@vikenbauer do you mind providing a bash script to do all of that please?

I'm running Matomo 4.12.3 in Swarm and all tables are created in DB. I've added environment variables for the DB related fields to the stack but whenever the container restarts I have to go through the wizard (but with prefilled credentials from the environment variables). you mentioned having config.ini.php beforehand will allow us to skip the installation wizard, could you please provide an example of how to set that up in a swarm env?

would be a good example to add to your documentation unless it already exists and I failed to find it

Hi @its-Saab,

thank you for the question. Unfortunately we are not in a position to provide custom setup support, however we would happily review a community raised PR.

In multi-server environments, it is important that all containers have access to the shared filesystem where the config file is written to and that it is persisted across container restarts. Once you configure your Matomo instance, if you locate which container (and where) created config.ini.php, you might be able to either copy the file to other containers or use it for when containers restart, though as I mentioned at the beginning, the best solution is to make sure the files created by Matomo are persisted and available to new containers. With that, all new containers should pick it up automatically. If that's not possible, you may make config/confg.ini.php part of your container build.

@michalkleiner thanks for your response!

I ended up using "volumes" where the initial content of that volume is created by a Matomo container which seems to have solved my issue.

The thing is, at least when I was looking into it, I found some examples mentioned in the docs but not pointing this requirement out as you just did

Just a note on our side, if you're all interested in running in kubernetes, I ended up creating a helm chart mapping config.ini.php, /tmp, matomo.js and the GeoIP mmdb in /misc to a NFS persistent volume. and I'm able to run matomo as a replicaset.

it took me a while to get to this point, but I had been migrating my multiple Matomo VM's to Kubernetes, so didn't have to do the setup part while in a container.... However, this thread has given me insight in to programmatically setting up a new instance. so I'm gonna give that a try..

thanks all..!