Installing and Configuring MariaDB on Fedora 40
MariaDB ships as the default relational database engine in Fedora's repositories, making it the most natural choice for system administrators who need MySQL-compatible features without licensing overhead. The packages are signed, current, and maintained by the Fedora community, so a clean install on Fedora 40 takes only a few minutes once the host is ready. For Australian teams running workloads on-shore — whether on bare metal in a Sydney colocation facility or on a workstation in a Brisbane office — keeping the database local and open-source remains a common pattern.
This walkthrough covers a fresh install of the server, the post-install hardening steps, the firewall and SELinux adjustments needed for network access, and a few daily administration tasks. It assumes a recent Fedora 40 host with sudo access and a static IP.
Preparing the Fedora workstation or server
Before touching any database packages, refresh the system so the kernel, libraries, and existing services match the repositories. Run a full upgrade with sudo dnf upgrade --refresh, then reboot if the kernel was replaced. Australian data centres such as those operated by Macquarie Telecom or NEXTDC often image Fedora hosts from a frozen golden template, so an explicit refresh helps avoid drift between what is on disk and what the package index knows about.
Confirm that the fedora and updates repositories are enabled with sudo dnf repolist. Most Fedora installations do not need the RPM Fusion or EPEL repositories for MariaDB, so leaving them disabled keeps the attack surface smaller and aligns with the Australian Cyber Security Centre's guidance on minimising software sources. If you maintain more than a handful of hosts, scheduling these refreshes through Automating system updates with dnf-automatic on RHEL reduces the manual effort considerably.
Installing the MariaDB server package
The server package is mariadb-server and the client utilities ship in mariadb. Install both with sudo dnf install mariadb-server mariadb. Dnf resolves dependencies including the MariaDB common files, the Galera wsrep provider, and the InnoDB replacement engine. The total footprint is modest, usually under 200 MB, which fits comfortably on the small SSDs that ship in entry-level servers used by Australian SMBs in retail and hospitality.
Once the packages land, enable the service so it starts at boot and bring it up immediately with sudo systemctl enable --now mariadb. Check the state with sudo systemctl status mariadb; the active line should read active (running) and there should be no failed unit dependencies. If the process is running as the mysql user and listening on the default unix socket under /var/lib/mysql/mysql.sock, the installation is healthy and ready for hardening.
Securing the initial database
Fresh MariaDB installs ship with a relaxed default configuration: an empty root password, an anonymous user, and a world-readable test database. Run sudo mariadb-secure-installation to clean that up. The script walks through switching the root authentication to a unix socket check, removing anonymous accounts, dropping the test schema, and reloading the privilege tables.
Set a strong root password using a passphrase that mixes Australian-specific context — for example, a phrase including a street name from your Melbourne or Adelaide office — so it is easy to remember but hard to guess. The script will ask whether to disallow remote root logins; answer yes unless you have a strict operational reason to allow them, since remote root access is one of the most common audit findings under the Australian Government Information Security Manual.
Adjusting firewall and SELinux for network access
MariaDB listens on 127.0.0.1 by default, which is fine for local development but blocks every external connection. If your application runs on a different host — common when a Perth web farm queries a database server in Sydney — open the service through firewalld with sudo firewall-cmd --permanent --add-service=mysql and reload with sudo firewall-cmd --reload. Confirm the open port with sudo firewall-cmd --list-services.
On the database side, edit /etc/my.cnf.d/mariadb-server.cnf and set bind-address to the server's LAN IP rather than 0.0.0.0, which would expose the daemon to the wider internet. SELinux on Fedora 40 still controls MySQL network access through the mysql_connect_any boolean; enable it with sudo setsebool -P mysql_connect_any 1 only if you genuinely need cross-host connectivity. For most Australian deployments behind a perimeter firewall, keeping SELinux in enforcing mode and mysql_connect_any disabled is the safer default.
Managing databases, users, and ongoing maintenance
With the service hardened, create application users rather than handing out root credentials. Log in with sudo mariadb -u root, then run CREATE DATABASE appdb; CREATE USER 'appuser'@'10.0.0.%' IDENTIFIED BY 'strongpass'; GRANT ALL ON appdb.* TO 'appuser'@'10.0.0.%'; FLUSH PRIVILEGES;. Restricting the host pattern to your office subnet keeps the credential useful only from expected networks.
Schedule logical backups with mariadb-dump --all-databases through a systemd timer that fires during the quiet AEST window after midnight, and store the resulting .sql files on a separate volume. Once the database is reachable, the next step for many administrators is layering a web server on top — the guide on LAMP on Fedora 40 covers that path end to end. Pair your backups with periodic mariadb-check --optimize runs and monitor the slow query log for statements that exceed a few hundred milliseconds.
With the server installed, the firewall tightened, and a backup routine in place, your Fedora 40 host is ready to serve applications reliably. The combination of MariaDB's modern storage engine, Fedora's short release cadence, and the security baselines published by the ACSC gives Australian operators a solid foundation. Treat the database the same way you would any production asset: patch it on a schedule, watch the logs, and verify your restores before you ever need them.