=Custom in Fedora/EPEL=

==Pinger files==

Since /tmp is not a good place to spool files, the pinger files shall now reside

in /var/lib/zabbixsrv/tmp. This directory is automatically created and proxy and

server configuration files are changed accordingly from 2.0.8 on.

==Web configuration==

Web configuration resides in /etc/zabbix/web. The configuration file can be

created manually or by walking through the frontend setup tool, as soon as your

httpd configuration allows. The directory also contains maintenance.inc.php!

==Log files==

Log files are located in /var/log/zabbix for the agent and /var/log/zabbixsrv.

for server and proxy.

==No htaccess files==

Fedora ships an Apache configuration file instead. This solutions performs

better and is easier to maintain.

==Two users and groups==

There's a certain security risk involved, running agent and proxy/server as the

same user. This package therefore introduces an additional zabbixsrv user, used

for proxy and server. Please check the permissions of your scripts and group

memberships, if necessary.

==Using the Alternatives system instead of conflicting sub-packages==

You can now install Zabbix proxies or servers compiled for different database

back-ends on the same system. While this is not intended to happily switch back

and forth, it allows you to:

- Stop the daemon

- "Run alternatives --config zabbix-server" or

  "alternatives --config zabbix-proxy"

- Make your choice

- If you're using systemd, run systemctl reload

- Adjust the configuration file

- Start the daemon

- In some cases you have to use "restart" instead of "start".

  The reason is not yet clear to me.

"Alternatives" considers the first installed implementation of server or proxy as

default, respectively.

Don't forget to reconfigure the front-end when you switch the server to a

different DB implementation!

==How to run multiple instances of a Zabbix daemon with init scripts==

If you want to run multiple instances on the same host, do the following:

- Copy or symlink the init scripts 

- Create a file of the same name as the new init script in /etc/sysconfig

- Define CFG_FILE="</path/to/daemon_config_file>" in this file

- Create the file defined as CFG_FILE and adjust settings; in particular:

 - DB settings if you set up multiple instances of server and proxy daemons;

   IMPORTANT: Two daemons using the same database at the same time could act

   destructive!

 - PidFile

 - ListenPort and/or ListenIP, if you plan for simultaneous operation;

   Don't forget to review your firewall settings!

 - LogFile, if you don't use syslog

- Optionally run the following to register the new instance as a service and

  start it up automatically:

  chkconfig --add <init_script_name>

  chkconfig <init_script_name> on

- service <init_script_name> start

==Configuration changes==

Zabbix 2.0 and later place configuration files directly in /etc. Symlinks preserve

compatibility. maintenance.inc.php moved from /usr/share/zabbix/conf to

/etc/zabbix/web. Be careful not to replace the symlinks with files by mistake,

as the agent will not pick them up!

==Media scripts and external scripts==

The directories for external scripts and media scripts have moved to

/var/lib/zabbixsrv. Symlinks preserve compatibility.

/var/lib/zabbix is now intended for scripts run by the agent. Please move your

server or proxy scripts to /var/lib/zabbixsrv. Be sure to check permissions and

ownership.

==No Java bridge==

The Zabbix Java bridge can not be included now, due to missing dependencies.

=SELinux=

The settings necessary for you vary, depending on how you set up your system/s.

Most of the time, the only adjustments necessary should be on the machine that

holds the frontend:

#Allow to connect the frontend to a database by other means than sockets

setsebool -P httpd_can_network_connect_db 1

#Allow the frontend to create a connection to the server listening port

#That's the check the frontend uses to see whether the server is running.

#This option effectively supersedes the previous

setsebool -P httpd_can_network_connect 1

Using sebools is a somewhat coarse method of allowing things.

A more fine-grained approach for the latter would be to grab an actual

avc denial from the audit log, pipe it through audit2allow, put it in a

module package and load that:

echo "avc:  denied  { name_connect } for  pid=20619 comm="httpd" dest=10051 scontext=system_u:system_r:httpd_t:s0 tcontext=system_u:object_r:zabbix_port_t:s0 tclass=tcp_socket" | audit2allow -M zabbix_conn_httpd; sudo semodule -i zabbix_conn_httpd.pp

If you're using ping from the frontend:

echo "avc:  denied  { setpgid } for  pid=31880 comm="zabbix_server_p" scontext=system_u:system_r:zabbix_t:s0 tcontext=system_u:system_r:zabbix_t:s0 tclass=process" | audit2allow -M zabbix_ping_frontend; sudo semodule -i zabbix_ping_frontend.pp

=Additional packaging changes in Fedora/EPEL since 3.0=

==Configuration files contain the actual defaults==

Previously, the defaults in the config file were replaced by settings that

are suitable for Fedora. For non-mandatory settings, the daemon would default

to the hardcoded setting though, which is confusing. To make this

obvious, the original default settings are left in place and additional lines

added instead.

==Daemons are running in the foreground mode==

Systemd is more happy with this and it also solves the problem for the pidfile

setting, described in BZ #1220392. It is related to the above-mentioned.

==Minimal PHP configuration==

The httpd configuration contains the minimal settings necessary to operate

the frontend. Please refer to the manual for details:

https://www.zabbix.com/documentation/3.0/manual/installation/install

Make sure to review these settings!

=Additional packaging changes in Fedora/EPEL since 2.0=

==Zabbix 2.2 conflicts 1.8 and 2.0==

Please see the below section for the reason!

==Agent init script/unit file name==

For the sake of consistency between distributions, the agent init script,

respectively the systemd unit file, was renamed to zabbix-agentd -- mind the

trailing "d"! Symlinks with the old names are in place. Keep in mind, if

you created a configuration file in /etc/sysconfig, the sourced file must

the name of the init script you invoke! Consequently, if you decide to use

zabbix-agentd in the future, copy or symlink this file.

==zabbixsrv now has its own user group==

zabbixsrv used to be a member of the zabbix user group. Completely fresh

installations will create the zabbixsrv group and assign it as the primary

group. If the user zabbixsrv already exists (upgrade from 2.0), the user group

is replaced.

==Log and lock file locations, group membership==

All logs used to be in /var/log/zabbix. With zabbixsrv having its own

user group, the logs are now split between /var/log/zabbix for the agent and

/var/log/zabbixsrv for server and proxy.

=Additional packaging changes in Fedora/EPEL since 1.8=

==Zabbix 2.0 packages conflict Zabbix 1.8; 2.2 conflicts 1.8 and 2.0==

This measure was taken because this major version introduces various database

schema changes. A silent update would render Zabbix non-operational and possibly

break the database. Besides that, Zabbix 2.0/2.2 server only works with the

respective major versions of servers and proxies. Distributed setups must

therefore be updated at the same time to keep working.

http://www.zabbix.com/documentation/2.0/manual/appendix/compatibility

http://www.zabbix.com/documentation/2.2/manual/appendix/compatibility

--------------------------------------------------------------------------------

=Guide for upgrading to 2.2 from 2.0=

https://www.zabbix.com/documentation/2.2/manual/installation/upgrade

https://www.zabbix.com/documentation/2.2/manual/installation/upgrade_notes_220

Be sure to read the upgrades notes of the latest minor release too!

- Review all rpmnew and rpmsave files; merge where necessary

- Review permissions, ownerships and group memberships for zabbixsrv

- Migrate server and proxy logs to the new location, if you want

- Back up the Zabbix database (really!)

- Remove custom database changes, if any

- Make sure the database user has sufficing permissions

  (ALTER TABLE, DROP INDEX, DROP TABLE, ...)

- Start the server

- Check the server log for progress and possible errors

  The schema conversion should finish within minutes or hours

Volker Fröhlich volker27@gmx.at Jan  5 2013