feature/mariadb-upgrade-10.2

[jrouzierinverse]

Description

Upgrade to MariaDB

NEW Package(s) required

MariaDB-server-10.2.37
MariaDB-client-10.2.37

Issue

fixes #5907

Delete branch after merge

YES

Checklist

• Add unit tests
• Add acceptance tests (TestLink)

NEWS file entries

Enhancements

• Upgrade to MariaDB 10.2.37

UPGRADE file entries

MariaDB upgrade (CentOS + RHEL only)

Before packetfence upgrade:

In order to upgrade the MariaDB metadata files and tables, first stop any started process.

systemctl stop packetfence-mariadb
rpm -e --nodeps MariaDB-client MariaDB-common MariaDB-server MariaDB-shared
yum install --enablerepo=packetfence MariaDB-server-10.2.37

Then start a mysqld_safe process manually (this will start a background process)

systemctl unmask mariadb
systemctl start mariadb

Then, execute the upgrade script and enter the root password when prompted

mysql_upgrade -u root -p

When done, stop mariadb

systemctl stop mariadb
systemctl mask mariadb

Note that it might take up to a few minutes for the process to exit depending on the size of your database.

Once done, restart the MariaDB service (managed by PacketFence)

systemctl start packetfence-mariadb

Next proceed with yum update packetfence

Centos7 Cluster upgrade

tee /etc/yum.repos.d/mariadb.repo << EOF
[mariadb]
name = MariaDB
enabled=0
baseurl = http://yum.mariadb.org/10.2/centos7-amd64
gpgkey=https://yum.mariadb.org/RPM-GPG-KEY-MariaDB
gpgcheck=1
EOF

bin/pfcmd service pf stop
systemctl stop packetfence-mariadb
rpm -e --nodeps MariaDB-client MariaDB-common MariaDB-server MariaDB-shared

yum install --enablerepo=mariadb MariaDB-server MariaDB-backup

systemctl unmask mariadb
systemctl start mariadb

if error with "Recovering after a crash using tc.log" then delete tc.log

mysql_upgrade -u root -p

systemctl stop mariadb
systemctl mask mariadb

yum update packetfence --enablerepo=packetfence

bin/pfcmd generatemariadbconfig

/usr/local/pf/sbin/pf-mariadb --force-new-cluster

Debian 9 only

Before packetfence upgrade:

dpkg -r --force-depends mariadb-server mariadb-client-10.1 mariadb-client-core-10.1 mariadb-common mariadb-server-10.1 mariadb-server-core-10.1 libmariadbclient18

apt install mariadb-server-10.2 mariadb-common mariadb-client-10.2 mariadb-client-core-10.2 mariadb-server-core-10.2 libmariadb3 libmariadbclient18 mariadb-server

[extrafu]

@fdurand and @lzammit and @JeGoi - please test that PR on a standalone server and also on a cluster. Also test the autofix service we have on a cluster.

[nqb]

I run a pipeline here to see if build passed: https://gitlab.com/inverse-inc/packetfence/-/pipelines/263867228.

If build passed, you should have a package ready for your tests on Debian and CentOS.

[lzammit]

I've tested out the upgrade so far and I get Mariadb errors:

Mar 12 13:46:07 unicorn mysqld: 2021-03-12 13:46:07 140469393680128 [Warning] Aborted connection 12967 to db: 'pf' user: 'pf' host: 'localhost' (Got an error reading communication packets)
Mar 12 13:46:07 unicorn mysqld: 2021-03-12 13:46:07 140469389686528 [Warning] Aborted connection 12968 to db: 'pf' user: 'pf' host: 'localhost' (Got an error reading communication packets)
Mar 12 13:46:19 unicorn mysqld: 2021-03-12 13:46:19 140469394908928 [Warning] Aborted connection 12974 to db: 'pf' user: 'pf' host: 'localhost' (Got an error reading communication packets)
Mar 12 13:46:19 unicorn mysqld: 2021-03-12 13:46:19 140469390608128 [Warning] Aborted connection 12975 to db: 'pf' user: 'pf' host: 'localhost' (Got an error reading communication packets)

MariaDB [(none)]> SELECT VERSION();
+-----------------+
| VERSION()       |
+-----------------+
| 10.2.37-MariaDB |
+-----------------+

MariaDB [pf]> select * from pf_version;
+--------+---------+
| id     | version |
+--------+---------+
| 655872 | 10.2.0  |
| 655881 | 10.2.9  |
+--------+---------+

[root@unicorn pf]# rpm -qa | grep -i mariadb
MariaDB-compat-10.2.37-1.el7.centos.x86_64
MariaDB-shared-10.2.37-1.el7.centos.x86_64
MariaDB-common-10.2.37-1.el7.centos.x86_64
MariaDB-client-10.2.37-1.el7.centos.x86_64
MariaDB-server-10.2.37-1.el7.centos.x86_64

[lzammit]

haproxy-admin errors also:

Mar 12 13:41:35 unicorn.inverse.ca haproxy[17526]: [WARNING] 070/134135 (17526) : parsing [/usr/local/pf/var/conf/haproxy-admin.conf:110] : a 'http-request' rule pla
Mar 12 13:41:35 unicorn.inverse.ca haproxy[17526]: [WARNING] 070/134135 (17526) : parsing [/usr/local/pf/var/conf/haproxy-admin.conf:111] : a 'http-request' rule pla
Mar 12 13:41:35 unicorn.inverse.ca haproxy[17526]: [ALERT] 070/134135 (17526) : Error(s) found in configuration file : /usr/local/pf/var/conf/haproxy-admin.conf
Mar 12 13:41:35 unicorn.inverse.ca haproxy[17526]: [ALERT] 070/134135 (17526) : Fatal errors found in configuration.
Mar 12 13:41:35 unicorn.inverse.ca systemd[1]: Failed to start PacketFence HAProxy Load Balancer for the Admin GUI.
Mar 12 13:41:35 unicorn.inverse.ca systemd[1]: Unit packetfence-haproxy-admin.service entered failed state.
Mar 12 13:41:35 unicorn.inverse.ca systemd[1]: packetfence-haproxy-admin.service failed.
Mar 12 13:41:35 unicorn.inverse.ca systemd[1]: packetfence-haproxy-admin.service holdoff time over, scheduling restart.
Mar 12 13:41:35 unicorn.inverse.ca systemd[1]: Stopped PacketFence HAProxy Load Balancer for the Admin GUI.
Mar 12 13:41:35 unicorn.inverse.ca systemd[1]: start request repeated too quickly for packetfence-haproxy-admin.service
Mar 12 13:41:35 unicorn.inverse.ca systemd[1]: Failed to start PacketFence HAProxy Load Balancer for the Admin GUI.
Mar 12 13:41:35 unicorn.inverse.ca systemd[1]: Unit packetfence-haproxy-admin.service entered failed state.
Mar 12 13:41:35 unicorn.inverse.ca systemd[1]: packetfence-haproxy-admin.service failed.

[fdurand]

remove tab

[extrafu]

What's preventing us from merging that branch now?

[julsemaan]

Needs at least a rebase

[fdurand]

I still testing it. I have some weird issues with it.

[julsemaan]

Here is a list of the things we'd need in my opinion:

• Update clustering install guide if necessary
• Create update procedure for standalone server
• Create update procedure for a cluster
• Test galera-autofix with MariaDB 10.2
• Perform a lot of tests of the clustering layer to ensure there are no regressions (hard reboot, soft reboot, pkill -9, etc)