GBwebNET Wiki | Repackaging RPM Source

Compiling the Source Code

Building an RPM is dependent on libraries of the build host, so following the ensuing process on a host with newer libraries can cause issues when trying to install the RPM on an older OS with older libraries. Due to the fact that our OS versions are very out-of-date in many environments, the following process is best performed on zabbix.uk3, which is also particularly out of date (currently CentOS 5.4 - _GB 2012-08-08)_.

Get the latest (or current) version

The agent is created from the http://sourceforge.net/projects/zabbix/files/ZABBIX%20Release%20Candidates/ and configured with different parameters.

Dependencies

The build process has the following dependencies. Run:

$ yum install sqlite-devel.x86_64 libcurl-devel.x86_64 net-snmp-devel.x86_64 OpenIPMI-devel.x86_64 make.x86_64 OpenIPMI.x86_64 zlib-devel.x86_64 glibc-devel.x86_64 openssl-devel.x86_64 popt-devel.x86_64 rpm-devel.x86_64 libssh2-devel.x86_64 net-snmp.x86_64 rpm-build.x86_64

For this whole process there is also a requirement for checkinstall and rpmrebuild but they are discussed below

Configure and Compile

untar the source code, cd into the created sub-directory and run:

Agent

$ ./configure --enable-agent --with-libcurl --with-net-snmp --with-openipmi && make

Proxy

$ ./configure --enable-proxy --with-sqlite3 --with-libcurl --with-net-snmp --with-openipmi && make

Server

./configure --enable-server --with-mysql --with-net-snmp --with-libcurl --with-openipmi --enable-agent

Create an RPM

http://pkgs.repoforge.org/checkinstall/ and using http://www.asic-linux.com.mx/~izto/checkinstall/, creating a usable RPM is simply a case of running the following command (*substitute agent for proxy or server*):

$ sudo checkinstall --nodoc --install=no  --pkgname=zabbix_agent.version

It will print out the output location for the resulting RPM. Something like:

**********************************************************************
Done. The new package has NOT been installed. The RPM has been saved to
/usr/src/centos/RPMS/x86_64/zabbix_agent.1.8.1-1.x86_64.rpm
You can remove it from your system anytime using:
     rpm -e zabbix_agent.1.8.1-1.x86_64
**********************************************************************

Modifiying The RPM

Now we need to modify the RPM to personalise it to our needs. For this we will http://rpmrebuild.sourceforge.net/install.html and use http://rpmrebuild.sourceforge.net/. It has the same library dependencies http://buffalosoldier.omnifone.com:8081/display/OPS/Building+a+Zabbix+Agent#BuildingaZabbixAgent-CompilingtheSourceCode so ensure a sufficient system is used as the build host. Zabbix.uk3 currently has rpmrebuild installed.

A build environment needs setting up as follows

directory structure

{CODE()}

$ ls -R rpmbuild
rpmbuild:
BUILD RPMS SOURCES SPECS SRPMS

rpmbuild/BUILD:

rpmbuild/RPMS:
noarch x86_64

rpmbuild/RPMS/noarch:

rpmbuild/RPMS/x86_64:

rpmbuild/SOURCES:

rpmbuild/SPECS:

rpmbuild/SRPMS:

!!!!Macros
add the following line to the file .rpmmacros
{CODE()}
%_topdir %(echo $HOME)/rpmbuild

Adding/Amending files

Open the RPM, ready for modification:

$ rpmrebuild --edit-whole -p /path/to/rpm/dir/arch/zabbix_agentd.version.rpm

This will open the spec file in an editor and expand the file structure into a temporary directory indicated at the top of the spec file (_BuildRoot: /home/gbrown/.tmp/rpmrebuild.20735/work/root_)
Copy or amend the relevant files in(to) the correct sub-directory of the BuildRoot (I.e. /home/gbrown/.tmp/rpmrebuild.20735/work/root/usr/local/zabbix/scripts). If the sub-directory doesn’t exist just us mkdir to create it.
In the spec file, find the section called %files. In here we need to specify any new files and directories; and their relevant permissions.
1. For files use:
```
%attr(bitmap permissions, owner, group) "/path/to/file"
```
  1. If we want to add multiple files in a directory, we can use a wildcard:
```
%attr(bitmap permissions, owner, group) "/path/to/file/*"
```
2. For directories use:
```
%dir %attr(bitmap permissions, owner, group) "/path/to/dir"
```
3. The RPM spec also provides a %config directive for configuration files that is used so that edits to config files won’t get lost during a subsequent upgrade. Without this, the config files from an RPM upgrade would tend to overwrite any edited config files from the current version. {{%config}} can also apper as {{%config(noreplace). }} By using this macro option, the current, edited config file remains untouched and the file from the update is copied to the relevant directory with “{{.rpmnew”}} appended to the filename. An example of which is as follows:
```
%config(noreplace) %attr(0750, zabbix, zabbix) %verify(not md5 size mtime) "/etc/zabbix/zabbix_agentd.conf"
```
  1. %verify(not md5 size mtime) tells the RPM installer not to verify the MD5 hash, size or modify time of the subsequent file
Write and quit the spec file editor and confirm the rebuild of the RPM

Editing pre/post (un)install requirements

RPM has some useful directives for customising an install. Some useful ones of which are %pre, %post, %preun and %postun. Commands within these sections will be performed pre-install, post-install, pre-_un{_}intstall and post-_un{_}install respectively. A couple of examples of which are:

BEFORE the application is installed, add the Zabbix user to the system and validate*

%pre -p /bin/sh
if ! grep zabbix /etc/passwd > /dev/null; then
        echo -e "Creating Zabbix User..."
        /usr/sbin/useradd zabbix -c Zabbix\ Monitoring -u 1099
        if [ "$?" = 0 ];then
                echo -e "\nDone.\n"
        fi
fi

AFTER the application is* *{_}un{_}{*}{*}installed remove the Zabbix user*

%postun \-p /bin/sh
if grep zabbix /etc/passwd > /dev/null; then
         echo \-e "Removing Zabbix User..."
         /usr/sbin/userdel \-r zabbix
         if \[ "$?" = 0 \];then
                 echo \-e "\nDone.\n"
         fi
fi

Audit

The spec file also has a directive called %changelog so that we are able to keep a record of what has changed. That way, should something not work properly, we can easily trace back all of the changes until we come across a likely candidate for correction. An example would be:

%changelog
* Thu Dec 29 2011 Initial Commit
*  Ney Walens de Mesquita Revision 1.0   2011/12/29 16:27:00  Ney Walens de Mesquita
- Agent RPM Spec file for Zabbix 1.8.10 for RHEL 5.x/6.x

Revision 1.1    2012/08/07      16:15   Gareth Brown
- Added specific local scripts, Zabbix user, Agent to startup and echo comments to ammend script config files

Monitored Host

Agent Installation

Copy the RPM to the host we want to monitor (RPMs are found {color:black}on the Group Windows drive in Operations/OSS/Zabbix/Installation/RPMs/{color}):
```
$ scp zabbix_agent.version.rpm remote_user@remote_host:
```
Login to the remote host:
```
$ ssh remote_user@remote_host
```

install the RPM:

[remote_user@remote_host] $ sudo rpm -vi zabbix_agent.version.rpm

Update any configurations as necessary (there are plans to automate this part). I.e.:

*** REMEMBER ***

Check "Server=" option in /etc/zabbix/zabbix_agentd.conf is set to the correct
 Zabbix Server or Zabbix Proxy

And that the "SERVER=" and "HOST_TYPE=" parameters in ${ZABBIX_SCRIPTS}/conf/global.conf
are set to the correct type.

Start the Agent:

[remote_user@remote_host] $ sudo /sbin/service zabbix_agentd start

Verify data is being received by the Zabbix Server. I.e. tail the server log for the hostname and check for errors or unsupported items. Also check that the host in the Zabbix GUI is receiving values.
Have someone proof your work

Repackaging RPM Source