CentOS Linux release 7.5.1804

Do you think this will be enough:

<?xml version="1.0" encoding="utf-8"?>
<service>
  <short>Zabbix server</short>
  <description>Zabbix server with MySQL or MariaDB database support.</description>
  <port port="10051" protocol="tcp"/>
</service>

Looks like it is completely enough. These files are official:

[root@centos dotneft]# cat /usr/lib/firewalld/services/nrpe.xml 
<?xml version="1.0" encoding="utf-8"?>
<service>
  <short>NRPE</short>
  <description>NRPE allows you to execute Nagios plugins on a remote host in as transparent a manner as possible.</description>
  <port protocol="tcp" port="5666"/>
</service>
[root@centos dotneft]# cat /usr/lib/firewalld/services/syslog.xml 
<?xml version="1.0" encoding="utf-8"?>
<service>
  <short>syslog</short>
  <description>Syslog is a client/server protocol: a logging application transmits a text message to the syslog receiver. The receiver is commonly called syslogd, syslog daemon or syslog server.</description>
  <port protocol="udp" port="514"/>
</service>

Also I suppose name could be like we already have:

 cat /etc/services  | grep -i zabbix
zabbix-agent    10050/tcp               # Zabbix Agent
zabbix-agent    10050/udp               # Zabbix Agent
zabbix-trapper  10051/tcp               # Zabbix Trapper
zabbix-trapper  10051/udp               # Zabbix Trapper

dimir Your description is not quite good. It is not Zabbix server port only. It is Zabbix trapper port. So we need to use some general descriptions, like you see in my comment above.

Could be. I just pulled this one from our packages.

Open question: should we open the ports in firewall right after installation?

The reason for not opening, the component could be meant for using in active mode.

IMHO, It's sufficient to call a service zabbix-server that allows zbxsrv to listen for everything it needs and make a service zabbix-agent that allows for listening on 10050.

@dimir:

Open question: should we open the ports in firewall right after installation?

IMO, no, You shouldn't enable service in firewalld during postinstall. They just should be installed and firewalld reloaded, not activated.
Maybe a little stdout to remind about enabling them in firewalld.

From these instructions, do you mean that %firewalld_reload will enable the usage of the files but not actually open ports?

And I suppose we should also reload it after uninstallation:

%postun
%firewalld_reload

Yes, you are right. Just like it's stated  in those docs (https://en.opensuse.org/Firewalld/RPM_Packaging)

While fact gathering, I came to find that the firewalld project started shipping service configuration files for Zabbix almost 5 years ago.

There are a few nits I have with their package, namely:

1. the short description used in the zabbix-server configuration (instead of saying Zabbix Server, it should probably be Zabbix Trapper)
2. the long form description of both zabbix-server and zabbix-agent configurations, where instead of describing what Zabbix is, we should describe the purpose of the port
3. the lack of port entries for UDP
4. a configuration missing for the Java Gateway, which is provided in this ticket

Besides that, the only questions that need to be resolved are:

1. where in the tree should these configurations be placed?
   1. misc/firewalld/services ?
   2. conf/firewalld/services ?
   3. a dedicated directory where we'll accumulate third-party software configurations?
   4. or should we handle it like the selinux policy template, and keep it outside the main repo and only add the configurations during packaging?
2. how do we go about resolving package file collisions with the firewalld package? Apparently, not an issue, as we can place our configurations in /etc/firewalld/services as described in these RH docs.

dotneft, yurii, dimir - any thoughts?

Looks like the files have reached major distributions:

Debian

$ cat /etc/debian_version 
11.3

$ dpkg -l firewalld | grep ^ii
ii  firewalld      0.9.3-2      all          dynamically managed firewall with support for network zones

RedCap

# cat /etc/redhat-release 
CentOS Stream release 9

# rpm -q firewalld
firewalld-1.0.0-2.el9.noarch

Both have these:

/usr/lib/firewalld/services/zabbix-agent.xml:
<?xml version="1.0" encoding="utf-8"?>
<service>
  <short>Zabbix Agent</short>
  <description>Zabbix is a mature and effortless enterprise-class open source monitoring solution for network monitoring and application monitoring of millions of metrics.</description>
  <port protocol="tcp" port="10050"/>
</service>

/usr/lib/firewalld/services/zabbix-server.xml:
<?xml version="1.0" encoding="utf-8"?>
<service>
  <short>Zabbix Server</short>
  <description>Zabbix is a mature and effortless enterprise-class open source monitoring solution for network monitoring and application monitoring of millions of metrics.</description>
  <port protocol="tcp" port="10051"/>
</service>

So I propose to do nothing here and close "Won't Fix".

Great job!

Internally, we decided to submit a PR to the firewalld project with a few changes to the existing service configurations and additions of configurations for the Java Gateway and Web Service services. I've prepared the patches for submitting and have requested that radix adds my GitHub account to the Zabbix organization to avoid creating another account.

Once that is done, I'll open an issue ticket in the firewalld project with a PR and request for comments to see if they're fine with making the changes. Depending on the feedback, they'll either get merged, or worst case - we'll include these as overrides in the respective component packages that we distribute ourselves. Leaving the ticket in NEED INFO state for now.

A pull request has been submitted to the firewalld GitHub issues, #1072, to update their service configurations for Zabbix components.

Awaiting feedback.

EDIT: January 25th, 2023: The pull request hasn't received any comments since submission, so I commented on the issue to remind about it and ask for any feedback.

The Pull Request has been merged!

Thank you everyone for contributing configurations, discussion ideas and opinions! It took us 5 years, but we've made this happen together!

CLOSING.

I can't remeber how I found this Jira 5 years ago, but I'm so proud of You all that this epic journey came to the end!