Guide to upgrade mariadb to v12 in virtualmin

SYSTEM INFORMATION
OS type and version Ubunutu 24.04
Webmin version 2.402
Virtualmin version 7.30.8
Webserver version Apache/2.4.58
Related packages mariadb 12.x.x

Don’t believe anyone that says you can’t or don’t do it. You can and with a little bit of work it will operate very happily.

Below is a guide on how to install mariadb v12.x.x on a ubuntu 24.04 system with virtualmin. This guide will fix all the errors and re-engage mariadb in virtualmin.

It would also be possible to get it to work on 22.04 but you will need to change the key in the first step below to a repo suitable. I’m not running 22.04 but I believe you would just need to change where is has ubuntu noble main to ubuntu jammy main

Make sure you backup your database before doing the upgrade

Please excuse the formatting, this isn’t the easiest system to write this out in.

1) Install MariaDB 12.0.x from MariaDB’s official repo for Ubuntu 24.04 (noble) and optionally prefer upstream over Ubuntu.

# Add the mariadb Key + repo
sudo mkdir -p /etc/apt/keyrings
curl -fsSL https://mariadb.org/mariadb_release_signing_key.asc | sudo gpg --dearmor -o /etc/apt/keyrings/mariadb.gpgecho "deb [arch=amd64,arm64 signed-by=/etc/apt/keyrings/mariadb.gpg] https://dlm.mariadb.com/repo/mariadb-server/12.0/repo/ubuntu noble main"   | sudo tee /etc/apt/sources.list.d/mariadb.list
# (Optional, but recommended) prefer mariaDB upstream over ubunutu's repo
sudo tee /etc/apt/preferences.d/mariadb.pref >/dev/null <<'EOF'
Package: *
Pin: origin dlm.mariadb.com
Pin-Priority: 700EOF
sudo apt update
sudo apt install mariadb-server mariadb-clientmariadb    

2) Update Virtualmin module binaries

Make sure Virtualmin/Webmin is recent. Many fixes land via package updates.

sudo apt update
sudo apt install webmin

3) Verify services

Check client/server versions and that mariadb service is running.

mariadb --version
mariadbd --version
systemctl status mariadb --no-pager

4) Clear any old Webmin cache (optional)

If you already tried earlier and Webmin cached a failing version parse, clear and restart Webmin.

sudo rm -f /etc/webmin/mysql/version
sudo systemctl restart webmin

5) Make Webmin accept MariaDB 12 (version wrapper + paths)

Virtualmin’s MySQL module expects a classic “mysql Ver … Distrib …” line and currently rejects any version > 10.11.13. Here we spoof the last known working version and its formatted version output. This does not affect the version installed; it will still report as 12.x.x in Virtualmin — this wrapper is only to bypass Virtualmin’s checks.

# Wrapper so "mysql -V" prints a classic, parseable line

sudo tee /usr/local/bin/mysql >/dev/null <<'EOF'
#!/bin/sh
if [ "$1" = "-V" ] || [ "$1" = "–version" ]; then
  echo "mariadb  Ver 15.1 Distrib 10.11.13-MariaDB, for debian-linux-gnu (x86_64) using  EditLine wrapper"
  exit 0
fi
exec /usr/bin/mariadb "$@"
EOF

sudo chmod +x /usr/local/bin/mysql

6) Go to Webmin → Servers → MySQL Database Server → Module Config → System configuration

Set:

Path to mysql /usr/local/bin/mysql
Path to mysqladmin /usr/bin/mariadb-admin
Path to mysqlshow /usr/bin/mariadb-show
Path to mysqldump /usr/bin/mariadb-dump
Path to mysqlimport /usr/bin/mariadb-import
Path to mysqld /usr/sbin/mariadbd
Start/Stop systemctl start/stop mariadb

Disable MYSQL_PWD, Save, Refresh Modules.

If needed, clear cache and restart Webmin:

sudo rm -f /etc/webmin/mysql/version && sudo systemctl restart webmin

7) Fix “Could not find [mysqld] section in my.cnf” (Configuration & SSL)Provide a drop‑in with [mysqld] and point Webmin to it.

# Create a drop-in that contains [mysqld]
sudo tee /etc/mysql/mariadb.conf.d/99-webmin.cnf >/dev/null <<'EOF'
[mysqld]

# Webmin placeholder. Real settings live in other files.
# Webmin's "Configuration & SSL certificate" page will write here.
EOF

# Tell Webmin to use it
sudo sed -i 's|^my_cnf=.*|my_cnf=/etc/mysql/mariadb.conf.d/99-webmin.cnf|' /etc/webmin/mysql/config

# Restart Webmin to apply
sudo systemctl restart webmin

now when you visit webmin → servers → Mariadb Database Server or MySQLServer it will report MariaDB version 12.x.x on 127.0.0.1
You can create, edit and delete databases and users from within virtualmin/webmin

Now that I have proven it all works, I do not see why Virtualmin does not offer the upgrade path or latest version already installed. As they are pushing to use mariaDB they should maintain support for it’s integration. but that is jsut my opinion.

Virtualmin uses the versions of software supplied through your os. To date I have not seen a default upgrade to mariadb v12 in the standard channels so therefore as using a version of software which is not endorsed by the os I am using i would not want this to happen stability is key in live environments

just because it is not installed by default by the os or made it’s way into the default repos of the os does not make it unstable. Virtualmin and webmin is not installed by default or available through the “standard channels” and to install it, you need to their install script.

So by your standards you should not be using virtualmin.

If you add the virtualmin repository you will get software that is in a position to work 100% with your installed os assuming that you installed on a grade a os. My point here is if your os vendor does not see a possible problem with a new version of some software they could update to this version however stability is their keyword with longer term releases adding different versions of software may break something else in certain situations so if you want cutting edge software add the repository and install it, and fix the problems rather than waiting for the next release when the newer version of the software will work ‘out of the box’

Look man, you do you. Stay with out of the box. v11 of mariaDB has been out for over 18 months and virtualmin still doesn’t support it. This has nothing to with OS, but a restriction within the construct of virtualmin. Many people have sought a solution to upgrading maraiDB to v11 with virtualmin and my solution above fixes that issue. All they have to do is change the repo to v11.

Clearly you’re not a programmer and are satisfied with store bought products, and that’s fine. My solution is not for you. Good programmers are looking to stay ahead of the curve and that sometimes means breaking a few eggs. In this case I’ve turned the eggs into omletes. :grinning_face_with_smiling_eyes:

to quote a Virtualmin staff member

I mean, it’s fine. Everybody makes their own choices about how they want to spend their time and I’m not here to stop that. OP seems to know enough to be able to make decisions for themselves.

My admonishments about leaving well enough alone generally applies to folks who need a lot of hand-holding and are going to get themselves into trouble by going off-roading, and who don’t know what they don’t know about the kinds of things that will go wrong and how to fix them.

In short: If you have to ask, you probably shouldn’t, but if you figure it out yourself and understand the implications, more power to you. (Though, I’ll mention that I know how to do all this stuff, up to and including maintaining my own packages and repos, and I choose to run the OS standard packages in almost every case on almost every server I manage, because experience has taught me to not go out of my way to make more work for myself and others.)

2 Likes

Reading the thread the OP wants the ability to ‘go off roading’ built into virtualmin with regard to mariadb and/or other applications however that seems the wrong thing to do, the virtualmin way of using the os default is surely the best way to go

Actually I do code stuff but most of my projects use sqlite rather than a database server, that said if I’m writing addons for someone else’s code I’m stuck with using a database server, and I would prefer to have a level playing field for this rather than running into issues because of a non standard application running, but as you say ‘you are you’

System admins look to stability and reliability for their customers/clients/users. Redhat, the most successful Linux distro, has done quite well with that model. We upgrade ‘as needed’ rather than risk server disruptions. If you NEED the newer version, that is another issue. But to upgrade just because it is the latest/greatest? Not worth the stomach churning for the typical admin.

I’ve worked in enterprise environments where ANY change had you posting first and then sitting through a meeting with all stake holders to get approval.

Most of the things that Virtualmin handles doesn’t require the latest/greatest database features. I’m on Debian and won’t even use backports on my personal server.

This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.