=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.
==Where's my Flash watch?==
It's not included in Fedora! Fedora's policy does not allow to include blobs:
https://support.zabbix.com/browse/ZBX-4794
==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/2.2 place configuration files directly in /etc. Symlinks preserve
compatibility. maintenance.inc.php moved from /usr/share/zabbix/conf to
/etc/zabbix/web.
==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 legal issue with one of
the modules (json). See https://support.zabbix.com/browse/ZBX-4800 and feel free
to vote on it.
==No SQLite front-end or server implementation==
Sadly it doesn't work with how Fedora's/EPEL's PHP is compiled.
=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 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
=Guide for upgrading to 2.0 from 1.8=
https://www.zabbix.com/documentation/2.0/manual/installation/upgrade_notes?s[]=upgrade&s[]=notes&s[]=2&s[]=0
Be sure to read the upgrades notes of the latest minor release too!
The below should be the relevant steps, picked from
http://www.zabbix.com/documentation/2.0/manual/installation/upgrade
- Review all rpmnew and rpmsave files; merge where necessary
- Review permissions, ownerships and group memberships for zabbixsrv
- 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, ...)
- Run the fitting database update script/s
- The scripts can run very long, depending on the content of your database and
your hardware;
- Check the output of the script for errors
Volker Fröhlich volker27@gmx.at Jan 5 2013