You installed Fedora and need a database
You installed Fedora for a new project and need a relational database. You run dnf install mysql-server and the package manager tells you nothing matches. Or you installed MariaDB, started the service, and now mysql -u root drops you in without a password, but your application refuses to connect. The default authentication on Fedora behaves differently than the tutorials you found online. You need the database running, secure, and accessible to your app without wrestling with authentication plugins.
What's actually happening
Fedora ships MariaDB as the default database server. MariaDB started as a fork of MySQL when Oracle changed the license terms. The command-line tools and SQL syntax are nearly identical, but the package name is mariadb-server, not mysql-server. This is why your dnf search for MySQL comes up empty.
The bigger confusion usually hits during configuration. Fedora defaults the root account to use the unix_socket authentication plugin. This means the database trusts the operating system user. If you are logged in as root on the shell, you can log in as root in the database without a password. If you are logged in as fedorauser, you cannot access the database root account at all. This is secure for local administration but breaks applications that expect a password. The mysql_secure_installation script switches the root account to password authentication and locks down the rest of the installation.
Check the package name before you search. Fedora uses MariaDB, not MySQL.
Install and secure MariaDB
Install the server package and pull in the client tools.
sudo dnf install mariadb-server -y
# -y skips the confirmation prompt.
# mariadb-server pulls in mariadb as a dependency, giving you the client tools automatically.
Start the service immediately and ensure it survives a reboot.
sudo systemctl enable --now mariadb
# enable adds the service to the default target so it starts on boot.
# --now starts the service immediately in the same command.
Always check the service status after starting it. systemctl status mariadb shows recent log lines and the current state in one view. Look for Active: active (running) in green text. If the service failed, the output includes the last few journal lines to help you diagnose the issue.
Run the security script to set the root password and remove default risks.
sudo mysql_secure_installation
# This script prompts you for the current root password.
# Press Enter to skip the prompt if you have not set a password yet.
The script asks several questions. The most important one is whether to switch to unix_socket authentication. If you answer yes, you revert to the default behavior where the OS user controls access. Answer no to force password authentication for the root account.
Enter current password for root (enter for none):
Set root password? [Y/n] Y
Remove anonymous users? [Y/n] Y
Disallow root login remotely? [Y/n] Y
Remove test database and access to it? [Y/n] Y
Reload privilege tables now? [Y/n] Y
Answer yes to remove anonymous users, disallow remote root login, and remove the test database. These defaults exist for development convenience but pose a security risk in production. Reload the privilege tables at the end to apply the changes.
Run the security script immediately. An unsecured database is a liability, not a feature.
Configure the database for your application
Create a dedicated user for your application. Never run your app as the database root. The root account has administrative privileges that your application does not need. If your app is compromised, an attacker gains full control of the database server.
sudo mysql -u root -p
# -u root specifies the user.
# -p prompts for the password you just set.
Create the database and user with limited privileges.
CREATE DATABASE myapp_db;
-- Create the database for your application.
CREATE USER 'myapp_user'@'localhost' IDENTIFIED BY 'strong_password';
-- Create a user that can only connect from the local machine.
GRANT ALL PRIVILEGES ON myapp_db.* TO 'myapp_user'@'localhost';
-- Grant full access to the specific database, not the whole server.
FLUSH PRIVILEGES;
-- Reload the grant tables so the changes take effect immediately.
EXIT;
The @'localhost' restriction ensures the user can only connect from the server itself. If your application runs on a different machine, replace localhost with the client IP address or use a wildcard % with caution. Wildcards allow connections from any host and increase the attack surface.
Tune configuration and firewall
Adjust the default configuration for your workload. Config files in /etc/my.cnf.d/ are user-modified. Files in /usr/lib/my.cnf.d/ ship with the package. Edit /etc/. Never edit /usr/lib/. Package updates overwrite files in /usr/lib/ and destroy your changes.
Create a custom configuration file to override defaults.
# /etc/my.cnf.d/custom.cnf
[mysqld]
# Set the default storage engine.
default-storage-engine=InnoDB
# Limit the maximum number of connections.
max_connections=100
# Define the character set for new databases.
character-set-server=utf8mb4
InnoDB is the standard storage engine with transaction support and row-level locking. The utf8mb4 character set supports full Unicode, including emojis and rare characters. Restart the service to apply configuration changes.
If you need to allow remote connections to the database, you must open port 3306 in the firewall. Fedora enables firewalld by default.
sudo firewall-cmd --permanent --add-service=mysql
# Add the mysql service definition to the permanent zone.
sudo firewall-cmd --reload
# Apply the change to the runtime configuration immediately.
Run firewall-cmd --reload after every rule change. Otherwise the runtime config and the persistent config diverge, and your changes disappear on reboot.
Verify the installation
Confirm the service is active and the app user can connect.
systemctl status mariadb
# Look for Active: active (running) in green text.
# The output includes recent journal lines to catch startup errors.
Test the application user credentials.
mysql -u myapp_user -p myapp_db
# Connect as the app user to the specific database.
# Enter the password when prompted.
# If successful, you see the MariaDB monitor prompt.
If the connection fails, check the logs. journalctl -xeu mariadb reads better than journalctl alone. The x flag adds explanatory text and the e flag jumps to the end. Most sysadmins type journalctl -xeu <unit> muscle-memory style.
journalctl -xeu mariadb
# -x adds explanatory text for common errors.
# -e jumps to the end of the log.
# -u mariadb filters output to the mariadb unit only.
If the service fails and you see SELinux denials, check the audit log. Fedora enables SELinux in enforcing mode by default.
sudo ausearch -m avc -ts recent
# Search the audit log for Access Vector Cache denials since the last boot.
# Look for lines mentioning mariadb or mysqld.
SELinux denials show up in journalctl -t setroubleshoot with a one-line summary. Read those before disabling SELinux. Disabling SELinux removes a critical security layer and is rarely the correct fix.
Test the app user, not root. If the app user works, the configuration is correct.
Common pitfalls
The mysql command will refuse to connect and print an error. The error code tells you exactly what went wrong.
ERROR 1045 (28000): Access denied for user 'root'@'localhost' (using password: YES)
Error 1045 means authentication failed. You typed the wrong password, or you are trying to use a password when the account uses unix_socket authentication. Check the authentication plugin for the user. If you ran mysql_secure_installation and answered yes to switching to unix_socket, you must log in via the OS user. If you want password authentication, re-run the script and answer no.
ERROR 2002 (HY000): Can't connect to local MySQL server through socket '/var/lib/mysql/mysql.sock' (2)
Error 2002 means the client cannot find the socket file. The MariaDB service is not running. Start the service with systemctl start mariadb. If the service fails to start, check the journal logs for disk space issues or configuration errors.
Read the error code. 1045 is authentication. 2002 is connection. Fix the root cause, don't guess.
When to use MariaDB vs alternatives
Use MariaDB when you need a drop-in replacement for MySQL with Fedora's default package support and long-term stability. Use PostgreSQL when your application requires advanced JSON features, complex queries, or strict SQL compliance. Use upstream MySQL when your application depends on specific MySQL features that MariaDB has not yet implemented or has diverged from. Stay on MariaDB if you are migrating an old MySQL setup and want minimal changes to your SQL code.