Install Zabbix 8.0 LTS on Rocky Linux 10 / AlmaLinux 10

Zabbix 8.0 LTS installs on Rocky Linux 10 from the release repository. You no longer need the unstable repo or the --enablerepo flag older guides used, but two other things will catch you if you come from 7.0 LTS: the frontend lives in /usr/share/zabbix/ui, which breaks a hand-written Nginx vhost that still points at /usr/share/zabbix, and a fresh install switches off API access for every role except Super admin. You’ll hit both within the first hour if you install Zabbix 8 on Rocky Linux 10 from an older guide.

Original content from computingforgeeks.com - post 164294

Below you set up the Zabbix server, frontend and Agent 2 with PostgreSQL and Nginx on Rocky Linux 10 or AlmaLinux 10, behind HTTPS with SELinux enforcing, plus the EPEL conflict and new API defaults. Every command below was run in November 2026 on Rocky Linux 10.2 with Zabbix 8.0.0, and the AlmaLinux 10.2 packages were checked on a second VM.

What you need

A small box runs Zabbix fine, because the database is what grows, not the server process. The 2 vCPU and 4 GB lab VM handled the built-in “Zabbix server” host at about 2 new values per second. Size a production server on new values per second and how long you keep history, and give PostgreSQL its own fast disk once you pass a few hundred hosts. The layout this guide builds looks like this:

Everything in the dashed box runs on the one server you build here. Only Nginx on 80 and 443 and the two Zabbix ports need to be reachable from outside (80 stays open for Let’s Encrypt renewals and the HTTPS redirect), which is why PostgreSQL keeps its default loopback-only listener the whole way through. Before you start, have these ready:

• Rocky Linux 10 or AlmaLinux 10, 2 vCPU and 4 GB RAM as a floor
• A user with sudo rights, SELinux in enforcing mode
• A DNS A record such as zabbix.example.com pointing at the server, with port 80 reachable for the certificate
• Ports 80 and 443 (web), 10050 (agent) and 10051 (server) open to the hosts that need them

If you are still on Zabbix 7.0 and want to keep it, the Zabbix 7.0 LTS install on Rocky Linux 10 is the guide for that branch. Existing 7.0 servers should follow the Zabbix 7.0 to 8.0 upgrade instead of a fresh install, because the database schema has to be converted in place.

Add the Zabbix 8.0 repository

Zabbix publishes a separate release RPM for each rebuild, and the latest-8.0 file name always points at the newest repo package, so the URL below keeps working after point releases. On Rocky Linux 10:

sudo rpm -Uvh https://repo.zabbix.com/zabbix/8.0/release/rocky/10/noarch/zabbix-release-latest-8.0.el10.noarch.rpm
sudo dnf clean all

AlmaLinux 10 takes the alma path instead. The packages inside are the same build, and on the AlmaLinux 10.2 VM the install pulled identical 8.0.0-release1.el10 RPMs:

sudo rpm -Uvh https://repo.zabbix.com/zabbix/8.0/release/alma/10/noarch/zabbix-release-latest-8.0.el10.noarch.rpm
sudo dnf clean all

List the repositories to confirm what you just added. There is no zabbix-unstable entry any more, which is how you know you are on the GA tree.

sudo dnf repolist | grep -i zabbix

Five Zabbix repositories show up, with the server packages in the plain zabbix repo:

zabbix                Zabbix Official Repository - x86_64
zabbix-release        Zabbix Official Repository (release packages) - noarch
zabbix-sources        Zabbix Official Repository (sources) - x86_64
zabbix-third-party    Zabbix Official Repository (third-party) - x86_64
zabbix-tools          Zabbix Official Repository (tools) - x86_64

Check which build dnf is going to pick before you install anything, because a server that already has EPEL can offer a second Zabbix from there. We look at one line only: Repository should read zabbix, not epel. If it says epel, do the next section first.

sudo dnf info zabbix-server-pgsql

On our lab box the release repo offered the GA build, and the AlmaLinux VM got the same release1.el10 build from its own path.

Name         : zabbix-server-pgsql
Epoch        : 2
Version      : 8.0.0
Release      : release1.el10
Architecture : x86_64
Size         : 2.9 M
Source       : zabbix-8.0.0-release1.el10.src.rpm
Repository   : zabbix

Epoch 2 is normal for the official Zabbix RPMs, so don’t be surprised to see 2: in front of the version in dnf transactions. The release field is the part to compare across servers when you audit a fleet later.

Keep EPEL away from the Zabbix packages

Most Rocky and Alma servers end up with EPEL, and you’ll need it later in this guide for certbot. EPEL 10 carries its own Zabbix 7.0 packages under zabbix7.0-* names, which is exactly the kind of overlap that lets a routine dnf update drag in the wrong agent or web package months from now. Install EPEL, then tell dnf to ignore anything Zabbix from it:

sudo dnf install -y epel-release
sudo dnf config-manager --save --setopt=epel.excludepkgs="zabbix*"

Before the exclude, EPEL listed 16 zabbix7.0 packages at version 7.0.31; after it, the same query returns nothing:

The setting lands in /etc/yum.repos.d/epel.repo as excludepkgs=zabbix*, so it survives reboots and future EPEL updates. If you ever want EPEL’s 7.0 agent on some other machine, remove the line there, not here, because this server should only ever see the 8.0 packages from repo.zabbix.com.

Install the server, frontend and Agent 2

One dnf transaction pulls in the server with PostgreSQL support, the PHP frontend, the Nginx config, the SQL schema, the SELinux policy module and Agent 2 with its PostgreSQL plugin:

sudo dnf install -y zabbix-server-pgsql zabbix-web-pgsql zabbix-nginx-conf zabbix-sql-scripts zabbix-selinux-policy zabbix-agent2 zabbix-agent2-plugin-postgresql

That came to 49 packages and 61 MB on the lab VM, and the run took 3 minutes 23 seconds. Watch the PHP line in the transaction: Rocky Linux 10.2 resolves the frontend’s php-fpm dependency to the versioned php8.4-* packages from AppStream, not PHP 8.3, which older Rocky 10 guides show. The service is still called php-fpm, so nothing else changes. The zabbix-selinux-policy package also pulls in zabbix-selinux-policy-main on Rocky, which matters in the SELinux step. Our AlmaLinux VM had the CRB repository enabled, and there dnf satisfied the same dependency with selinux-policy-targeted-extra from CRB instead; the two conflict, so don’t try to install both.

Confirm what you actually got before you touch the database, because the schema you import next has to match the server build exactly. We also query the release package, since its version tells you which repo tree the box points at.

zabbix_server -V | head -2
rpm -q zabbix-release zabbix-server-pgsql zabbix-web-pgsql
php-fpm -v | head -1

The server reports 8.0.0, built on 4 November 2026, alongside PHP 8.4 from AppStream:

If zabbix_server -V prints a version with a suffix after 8.0.0, your box still carries a build from the unstable repo. Remove it and reinstall from the release repo rather than layering the GA packages over it, because a mixed set of server and frontend builds is how you end up with a schema mismatch.

Set up PostgreSQL

Zabbix 8.0 needs PostgreSQL 15 or newer, and Rocky Linux 10 ships PostgreSQL 16 in AppStream, so no PGDG repository is needed. Install it, create the data directory and start the service:

sudo dnf install -y postgresql-server postgresql
sudo postgresql-setup --initdb
sudo systemctl enable --now postgresql

The init step reports where the cluster lives. We keep the default path because the next step edits pg_hba.conf inside it, and the SELinux labels are already correct there.

 * Initializing database in '/var/lib/pgsql/data'
 * Initialized, logs are in /var/lib/pgsql/initdb_postgresql.log

The lab got PostgreSQL 16.15 from AppStream. That is inside the supported range for Zabbix 8.0, so there is no reason to add the PGDG repository unless you want a newer major for other workloads.

Allow password logins for the zabbix role

By default, Rocky’s pg_hba.conf uses peer on the Unix socket and ident on 127.0.0.1 and ::1. The Zabbix frontend logs in with a password over TCP, so ident rejects it. Switch the loopback lines to scram-sha-256, which is the password hashing PostgreSQL 16 uses by default, and add a socket line for the zabbix role above the catch-all peer line. Open the file:

sudo vim /var/lib/pgsql/data/pg_hba.conf

The active lines should end up like this (the replication lines below them stay as they are):

local   all             zabbix                                  scram-sha-256
local   all             all                                     peer
host    all             all             127.0.0.1/32            scram-sha-256
host    all             all             ::1/128                 scram-sha-256

Restart PostgreSQL so it reads the new rules. A typo in this file stops the service from starting, so if the restart fails, journalctl -u postgresql names the bad line.

sudo systemctl restart postgresql

Nothing else in PostgreSQL needs changing for a single-box install. It keeps listening on loopback only, which is what you want while the database and the frontend share a host.

Create the database and import the schema

Create the role and the database it owns. createuser asks for the password twice; keep it handy, because the server config and the web installer both need it:

sudo -u postgres createuser --pwprompt zabbix
sudo -u postgres createdb -O zabbix zabbix

Because the zabbix role now needs a password on the socket too, the schema import has to supply one. Read it into PGPASSWORD without echoing it, pass it through sudo, and clear it afterwards. The import took 55 seconds on the lab VM:

read -rsp 'zabbix DB password: ' PGPASSWORD; echo; export PGPASSWORD
zcat /usr/share/zabbix/sql-scripts/postgresql/server.sql.gz | sudo -u zabbix --preserve-env=PGPASSWORD psql -q zabbix
sudo -u zabbix --preserve-env=PGPASSWORD psql -c "select mandatory, optional from dbversion" zabbix
unset PGPASSWORD

The dbversion row is the one value worth checking here. 8000000 means the 8.0 schema is in place, and the server refuses to start against any other number:

 mandatory | optional
-----------+----------
   8000000 |  8000000
(1 row)

The fresh schema created 230 tables. An import that finishes in a second or two did not work, because the real one takes close to a minute, so check the row above before you move on. If the pipe exits instantly with an authentication error, see the first entry under the errors section below.

Point the server at the database

The server config already defaults to a local database named zabbix owned by a zabbix user, so the password is the only line to set:

sudo vim /etc/zabbix/zabbix_server.conf

Find the commented # DBPassword= line and replace it with the password you created:

DBPassword=YourStrongPasswordHere

We leave DBHost unset on a single box. The server then reaches the local PostgreSQL with its built-in default, which worked without any SELinux change, so there is nothing to debug later. Set it only when the database lives on another host, and expect to revisit the booleans in the next section if you do.

Check SELinux before you touch a boolean

Older Zabbix guides for Rocky, including the earlier version of this one, tell you to switch on httpd_can_network_connect_db before the web installer. With the zabbix-selinux-policy package installed that turned out to be unnecessary: we ran the whole wizard and the dashboard with every Zabbix and httpd network boolean still off, and the audit log stayed empty. The package loads a module called zabbix_policy that lets the web server domain reach PostgreSQL and the Zabbix server port without any boolean. You can see it with sesearch, which comes from the setools-console package and isn’t on minimal images:

sudo dnf install -y setools-console
sesearch -A -s httpd_t -t postgresql_port_t -c tcp_socket -p name_connect
sesearch -A -s httpd_t -t zabbix_port_t -c tcp_socket -p name_connect

The rules with no boolean in brackets are always on, and they are the ones the Zabbix module adds:

allow httpd_t port_type:tcp_socket name_connect; [ httpd_can_network_connect ]:True
allow httpd_t postgresql_port_t:tcp_socket name_connect;
allow httpd_t port_type:tcp_socket name_connect; [ httpd_can_network_connect ]:True
allow httpd_t zabbix_port_t:tcp_socket name_connect;

We proved where they come from by disabling the module with sudo semodule -d zabbix_policy on the lab box: the same two queries then showed both rules gated again, behind httpd_can_network_connect_db and httpd_can_connect_zabbix. Re-enable it with sudo semodule -e zabbix_policy if you try that yourself. The practical point is that skipping zabbix-selinux-policy puts you back on the booleans. We ran this check on Rocky; on AlmaLinux, where the policy dependency can come from CRB instead, run the same ausearch check below before you trust it.

So leave the booleans alone and let the audit log tell you if something is blocked. After the installer finishes, this should print <no matches>:

sudo ausearch -m avc -ts today

The Zabbix package install docs still list httpd_can_connect_zabbix and httpd_can_network_connect_db for RHEL 7 and later. Set them with sudo setsebool -P only if ausearch shows a denial, for example when you left out the policy package, PostgreSQL listens on a non-default port, or the frontend reports the server as not running. Turning booleans on preemptively widens what Nginx and PHP-FPM may reach for no gain.

Configure the Nginx vhost

The zabbix-nginx-conf package drops a server block into /etc/nginx/conf.d/zabbix.conf with root /usr/share/zabbix/ui and the PHP-FPM socket already wired up. Only the listen and server_name lines are commented out. Edit the packaged file instead of pasting an old vhost over it. The official packages moved the PHP files to /usr/share/zabbix/ui back in 7.2, so a vhost copied from a 7.0 LTS guide still points at /usr/share/zabbix and lands on a “Manual intervention is required” page instead of the frontend:

sudo vim /etc/nginx/conf.d/zabbix.conf

Uncomment the two lines at the top, change the port to 80 and put in your hostname:

server {
        listen          80;
        server_name     zabbix.example.com;

        root    /usr/share/zabbix/ui;

Test the syntax before you go further. Certbot edits this same file later on, and it refuses to touch a config that doesn’t parse.

sudo nginx -t

Both lines should come back clean.

nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful

The packaged block listens on IPv4 only, while the default server in /etc/nginx/nginx.conf also listens on [::]:80. Keep the hostname on an A record for now, because an AAAA record would send Let’s Encrypt’s IPv6 check to the default server instead of this one. HTTPS comes after the firewall and the services are up, since the certificate check needs Nginx answering on port 80.

Open the firewall

The Rocky 10 cloud image used for the lab had no firewalld at all, so install it first if rpm -q firewalld says it is missing. Then open the web ports and the two Zabbix ports in one go:

sudo dnf install -y firewalld
sudo systemctl enable --now firewalld
sudo firewall-cmd --permanent --add-service={http,https}
sudo firewall-cmd --permanent --add-port={10050,10051}/tcp
sudo firewall-cmd --reload

Check the zone afterwards. A --permanent rule without the reload only lands on disk, so you wouldn’t notice it missing until the first agent times out.

sudo firewall-cmd --list-all

You should see http and https next to the defaults, and both Zabbix ports.

  services: cockpit dhcpv6-client http https ssh
  ports: 10050/tcp 10051/tcp

Port 10051 only needs to be open to agents in active mode and to proxies. Port 10050 on this box matters only if another server or proxy polls its agent, because the local server reaches its own agent over loopback. If every monitored host is on one subnet, a rich rule limited to that subnet is tighter than opening either port to the world.

Start the services

PostgreSQL is already running, so you only start the four Zabbix-facing services. Use enable --now rather than a plain start, because a monitoring server that doesn’t come back after a kernel update is the one outage nobody gets alerted about.

sudo systemctl enable --now zabbix-server zabbix-agent2 nginx php-fpm

Check all five units, the server’s startup lines and the listening ports in one pass:

for svc in zabbix-server zabbix-agent2 nginx php-fpm postgresql; do echo "$svc: $(systemctl is-active $svc)"; done
sudo grep -E "Starting Zabbix Server|database version" /var/log/zabbix/zabbix_server.log
sudo ss -tln | grep -E ":(80|443|5432|10050|10051) "

Everything reports active, the server logs revision c81e276e505 against schema 08000000, and PostgreSQL listens only on loopback. This capture was taken after our lab’s HTTPS was in place, so it includes a 443 listener; at this point in your own run, 443 only appears after the certificate step below.

The lab log also printed a few slow query warnings on commits during the first minutes, while the server filled its caches on a slow shared disk. They stopped on their own. If you keep seeing them on a real server, the disk under /var/lib/pgsql is too slow for your value rate, and moving the database is cheaper than tuning around it.

Get the Let’s Encrypt certificate

With Nginx answering on port 80 and the firewall open, certbot can prove you own the hostname. Certbot and its Nginx plugin come from EPEL, which you added earlier; on the lab VM that gave certbot 4.2.0 with the nginx, standalone and webroot plugins, and it installed without CRB enabled.

sudo dnf install -y certbot python3-certbot-nginx

Request the certificate with the HTTP-01 challenge. Certbot adds the listen 443 ssl and certificate lines to the Zabbix server block and sets up the redirect from port 80, and it works with any DNS provider as long as port 80 is reachable from the internet:

sudo certbot --nginx -d zabbix.example.com --non-interactive --agree-tos --redirect -m [email protected]

Our lab VM sits on a private network with no public DNS record, so Let’s Encrypt could not reach it and the issuance itself was not run there. Instead the same listen 443 ssl, ssl_certificate and ssl_certificate_key lines were added by hand with a self-signed certificate, which is why the browser screenshots below are served over HTTPS. Servers that can’t expose port 80 can use a DNS-01 plugin such as python3-certbot-dns-cloudflare or the Route 53 one with certbot certonly instead. Renewal is the part that bites later. On the lab VM, EPEL’s certbot left certbot-renew.timer enabled but not running, and systemctl list-timers showed no timer at all, so certificates would quietly expire after 90 days. Start it yourself and confirm it is scheduled:

sudo systemctl enable --now certbot-renew.timer
systemctl list-timers certbot-renew.timer

The timer now shows a next run time:

NEXT                            LEFT LAST PASSED UNIT                ACTIVATES
Thu 2026-11-05 17:01:36 UTC 5h 41min -         - certbot-renew.timer certbot-renew.service

Once a real certificate is issued, sudo certbot renew --dry-run tests the renewal path itself against Let’s Encrypt’s staging server, which is a separate check from the timer.

Run the web installer

Browse to https://zabbix.example.com. The setup wizard opens on the welcome page, where you can pick the interface language:

Click Next step. The prerequisite check compares PHP against the 8.0 minimums; the PHP-FPM pool that zabbix-web installs already sets the memory, upload and execution limits, so every row should read OK with PHP 8.4.27 against a required 8.2.0:

On the database page, leave Database type on PostgreSQL and the host as localhost, type the zabbix role’s password into Password and click Next step:

1. 1Database type
2. 2Password
3. 3Next step

The Database TLS encryption box is still ticked by default. Against a local PostgreSQL with ssl = off the frontend quietly falls back to an unencrypted loopback connection and the step passes, which is what happened here. With a remote database, turn on SSL in PostgreSQL and give the frontend the CA file, otherwise every query and result crosses the network unencrypted (the scram-sha-256 login itself never sends the password).

The Settings page takes a display name for the server (it shows under the logo, zbx01 here), the default time zone and the theme:

Step through the summary and the installer writes /etc/zabbix/web/zabbix.conf.php and reports success:

Click Finish to reach the sign-in page. The default account is Admin with the password zabbix, and it has Super admin rights. Change that password before anything else, because Admin/zabbix is the first pair anyone tries against an exposed Zabbix login page:

After sign-in you land on the Global view dashboard. Read the System information widget first: Zabbix server is running should say Yes against localhost:10051, and both server and frontend should report 8.0.0 as up to date. The Host availability widget shows the built-in “Zabbix server” host available through Agent 2:

The same numbers, plus counts of templates, items and triggers, sit under Reports > System information. A fresh install ships 390 templates, and the one host carried 149 items with 13 of them not supported at first, which is normal for template items that probe features the box doesn’t have:

If Zabbix server is running says No while systemctl shows the server active, that is the case where an SELinux denial for the frontend talking to port 10051 would show up in ausearch. It did not happen on this stack.

Turn on API access for the roles that need it

Zabbix 8.0 disables API access by default for new installs, and that bites the moment you connect Grafana, Ansible or a script with a normal account. The release notes say “all roles”, but the built-in Super admin role is the exception on a real install. On the lab install, the role_rule table showed exactly where it landed:

• Super admin role: API on, empty deny list
• Admin role: API off
• User role: API off
• Guest role: API off

So the built-in Admin account still works against the API, which makes a quick curl test look fine, while every account you create in another role is locked out. That gap is why the problem usually shows up days later, when you wire up the real integration user.

To prove it, we created a user called grafana in the Admin role. It could still call user.login and get a session token, but the first real method failed:

{"jsonrpc":"2.0","error":{"code":-32500,"message":"Application error.","data":"No permissions to call \"host.get\"."},"id":4}

The switch is per role. Go to Users > User roles, open the role your integration account uses and scroll to the Access to API block. Tick the Access to API Enabled checkbox, which is cleared on a new install:

Then pick how the method list works, because 8.0 changed its meaning. An Allow list with no methods in it now denies everything, where older releases ignored an empty list. For a read-only dashboard account, choose Allow list and add only the *.get methods it needs. For a broad automation account, choose Deny list and leave it empty, which permits every method the role’s host permissions allow. After switching the Admin role to an empty deny list and clicking Update, the same host.get call from the grafana user returned a normal result:

{"jsonrpc":"2.0","result":[],"id":4}

The empty array is correct: the user has API access now but no host group permissions yet, so it sees no hosts. Grant the user group read access to the host groups it should see, and the hosts appear.

Two more 8.0 defaults touch new installs, according to the 8.0 what’s new page. HTTP templates and webhook media types now verify the endpoint’s TLS certificate through the {$HTTP.TLS.VERIFY} macro. A webhook pointed at an internal service with a self-signed certificate therefore fails until you trust that CA or set the macro to a weaker level. A new SAML configuration also has every signing option enabled, so you need an SP key and certificate before it will save.

Errors we hit and how to fix them

Two errors came up in the lab run, and neither one says which layer produced it. Both are quick to fix once you know whether PostgreSQL or the Zabbix frontend is refusing you, so the first thing to read is the prefix of the message.

psql: error: FATAL: password authentication failed for user “zabbix”

You get this from the schema import when no password reaches psql. Once pg_hba.conf asks the zabbix role for a password on the socket, sudo -u zabbix psql has to supply one. In an interactive shell it prompts, but in a script, a non-interactive SSH command or an Ansible shell task there is no terminal to prompt on. The import then exits in a fraction of a second:

psql: error: connection to server on socket "/var/run/postgresql/.s.PGSQL.5432" failed: FATAL:  password authentication failed for user "zabbix"

Use the PGPASSWORD form from the schema step, with --preserve-env=PGPASSWORD on sudo, because sudo strips the variable otherwise. Nothing was imported, so you can rerun it straight away without dropping the database.

No permissions to call “host.get”

An API client that logs in fine and then fails on every method is hitting the 8.0 role default, not a password or token problem. Enable Access to API on the user’s role as shown above, and if the role uses an allow list, make sure the method is actually on it. Regenerating tokens or resetting the password won’t change this error.

Harden the install before you add hosts

The server works at this point, but a few defaults are wrong for anything beyond a lab. These are the ones we’d fix on day one, in this order:

1. Change the Admin password
2. Create a named Super admin, then disable Admin
3. Give API clients their own role and allow list
4. Set retention in Administration > Housekeeping
5. Ship a nightly pg_dump off the box
6. Limit 10050 and 10051 to agent subnets

With that done, roll out Zabbix Agent 2 on your other Rocky and AlmaLinux hosts and register them in the frontend. The Debian and Ubuntu sides of a mixed fleet are covered in the Zabbix 8.0 install on Debian, the Ubuntu 24.04 version and the Ubuntu 26.04 LTS guide. For reference, these are the exact versions this install ran on:

Component	Rocky Linux 10.2 lab VM
Zabbix server, frontend, Agent 2	8.0.0 (release1.el10, revision c81e276e505)
zabbix-release	8.0-2.el10
PostgreSQL	16.15 (AppStream)
PHP-FPM	8.4.27 (php8.4 packages, AppStream)
Nginx	1.26.3
certbot	4.2.0 (EPEL)
Kernel	6.12.0-211.73.1.el10_2
SELinux	Enforcing, no booleans changed, no AVC denials

AlmaLinux 10.2 resolved the same Zabbix and PHP package versions from its own mirrors. The only difference we saw there was the SELinux dependency coming from CRB, as described in the install step.