Original issue

This plugin allows the user to use operating system credentials when connecting to MariaDB via Unix socket. It works by retrieving uid of the process that has connected to the socket [...] and allowing to connect to the MariaDB account with the corresponding user name.

So no password should be set for the root user. Here's the pertinent information from /usr/share/doc/mariadb-server-10.0/README.Debian.gz:

On new installs no root password is set and no debian-sys-maint user is
created anymore. Instead the MariaDB root account is set to be authenticated
using the unix socket, e.g. any mysqld invocation by root or via sudo will
let the user see the mysqld prompt.

You may never ever delete the mysql user "root". Although it has no password
is set, the unix_auth plugin ensure that it can only be run locally as the root
user.

The credentials in /etc/mysql/debian.cnf specify the user which is used by the
init scripts to stop the server and perform logrotation. This used to be the
debian-sys-maint user which is no longer used as root can run directly.

I'm assuming that this is why Debian package installation is failing on Ubuntu 16.04:

I tried entering nothing when the two password prompts came up, but this had no effect. So maybe the attempt to use a password (even though it's empty) is causing the problem.

I also tried disabling the plug-in for root, and then setting a traditional password. This got Aegir up & running, but broke the database package's cron job as it now assumes no password. We probably shouldn't mess with it.

The above-mentioned README also says:

Scripts should run as a user have have the required grants and be identified via unix_socket.

So given that we have an aegir user, I'm thinking that we should grant it the necessary permissions before it starts doing its work, and then it can connect without a password.

How does this process work now? Where is the code that handles it?

I'd like to see if it's possible to come up with a quick solution right away.

I just confirmed that everything works fine with MySQL 5.7. Seems that package is still doing things the old way.

So this is just a MariaDB 10 problem. I updated the issue title & description. As I'm not sure if we're actually supporting MariaDB, I demoted the priority to Normal. As this appears to be an upstream bug (given that MySQL works), let's link to it if/when we find it.

Looks like it actually is 10, not 10.1, as that's what's in Xenial. However, it could be the Debian package and not the database server application itself, or something we're doing in Provision that no longer works (or something specific to our Debian package). More investigation will be required to track this one down.

At the very least, it would be great if someone else could confirm by installing the default mariadb-server and then aegir3 on Xenial (Ubuntu 16.04). I was using the unstable Aegir channel, but stable channel tests are welcome.

@colans -- Maybe it's Xenial specific issue? We never experienced any issues with MariaDB 10.0 in BOA, but we use and recommend Debian, while Ubuntu is minimally supported, and we didn't add Xenial support, yet.

I also tried disabling the plug-in for root, and then setting a traditional password. This got Aegir up & running, but broke the database package's cron job as it now assumes no password. We probably shouldn't mess with it.

The above-mentioned README also says:

Scripts should run as a user have have the required grants and be identified via unix_socket.

So for now, I'm running MySQL instead, but it's less than ideal because of the memory leak. Running on a tiny VM is not possible; 2 GBs of memory or more seems fine.

I've managed to install Aegir on Debian Stretch, using MariaDB (default-mysql-server), by creating a new user (e.g., 'aegir_root') with the proper privileges, and providing that user to the hostmaster-install process.

The gist is to seed the debian package with the username 'aegir_root' and create and account e.g. sudo /usr/bin/mysql -e "GRANT ALL ON *.* TO 'aegir_root'@'localhost' IDENTIFIED BY 'mysecretPASSWORD' WITH GRANT OPTION"

The normal installation will ask for the password but not the username, so we either have to make it ask or change the default.