So, you have seen some interesting new feature in the monthly development update, and you want to try it out. Maybe you want to check exactly how a particular change was implemented. Or maybe you would like to produce a patch which depends on some changes being made in the development version.
Zabbix stores all its source code in a code repository, namely a Subversion one. As an open source project, it also provides access to this repository to everybody, so it is possible to take a look at how a development version is shaping up. In general, there are many possibilities - not unique to Zabbix, but possible because of the open source approach that open this way. Some might be:
Trying out new a development version out of curiosity
Testing the development version to provide feedback sooner in the development cycle
Using the development version to create patches
Providing feedback and improving documentation of new features
Providing early feedback is also an influential method to impact future of Zabbix if a particular feature is important to you, testing it early and letting developers know about any problems you find with it and what improvements are possible is more likely to result in those changes happening.
The first thing we have to solve is actually getting the source.
When looking for the Zabbix development version, there are two ways to get it, each with it's strengths and weaknesses.
On the Zabbix development download page, http://www.zabbix.com/developers.php, there are daily snapshots of development versions provided. These usually have the same setup procedures as the released versions. Benefits of using daily snapshots include:
Getting them is a simple download
The package is already generated for you
drawbacks include:
No way to update only those parts of the development version that have actually changed
No way to see what actually has changed
No way to get some arbitrary older version
It is suggested to use daily snapshots if you want a simple, one time peek at how Zabbix's development is progressing.
If you plan to follow Zabbix development for a longer time period, or you want to see how exactly a particular change was implemented, daily snapshots would soon become cumbersome to use. Luckily, we can directly access the system Zabbix developers themselves use, a popular version control system Subversion or SVN.
To access SVN repositories, some specific software, a client, is needed. There are many different SVN clients for various platforms, and you can choose whichever seems more convenient to you. Here we will use the official command line client. As this client is available in almost all Linux distributions, you may want to use it on our Zabbix test server. But before we start playing with it, we must know that the Zabbix source code repository resides at svn://svn.zabbix.com. In SVN, development is usually split into a trunk and branches. While the trunk represents the most recent development work, branches usually are used for stable version maintenance. Zabbix uses the same schema, and there are branches for stable version maintenance like 1.6 while 1.8, and big changes happen in the development section, trunk.
So let's say we are interested in latest new features and want to retrieve trunk. To do this, create some directory to hold the data, called checkout. Enter it and run:
$ svn checkout svn://svn.zabbix.com/trunk
This will proceed to retrieve all the files in the trunk. As of this writing, Zabbix trunk checkout uses approximately 114 MB on disk, but the amount transferred over the network will be smaller than that. Once the process completes, you might be tempted to proceed but that won't be easy to do, as there is no configure script at all. According to Zabbix scripts, we should now execute some commands to create this script:
$ aclocal -I m4
$ autoconf
$ autoheader
$ automake -a
$ automake
Note
Since February, 2010, you can simply launch script named bootstrap.sh instead of the commands above.
After these are completed, we should have the configuration script. Now we can compile this development version of Zabbix, right? Not quite yet. Development repositories hold only generic database schema, so we would not be able to create the database. We will have to generate the actual schema files ourselves. It is also suggested to create a package, one just like those downloadable from Zabbix site, so let's do that. Before we can generate the database schema and package, we have to use configure script, though. But we can make it slightly faster and requiring less dependencies by omitting any features that are not required. This also allows the creation of a Zabbix package on another machine that would not have all dependencies for the required functionality like SNMP or IPMI monitoring installed. In the simplest approach, run:
$ ./configure
This will produce the files required for database schema and package generation. Now we can proceed with schema generation:
$ make dbschema
With database schema files generated, we are ready to create a package:
$ make dist
After this command completes, the source directory should have a new package named zabbix-<version>.tar.gz. Here, the version will be whatever name the development part has received. As we discussed before, odd numbers are used for development versions, so it could be named 1.9, for example. From now on we are back to the known path, as this package pretty much the same you can download from released version area or from the daily snapshots area.
But that was a lot of work to get the same thing as we could have downloaded right away - why do it at all? Indeed, if you only want to grab development version once, daily snapshots should be your choice. But SVN checkout presents other benefits. Let's see what they are.
A collection of changes to repository is called changeset. A changeset that has been placed in a repository is said to be committed. We can list changesets being committed. For example, if we would like to know what the last two changesets that were committed to this part of the repository, we would issue:
$ svn log -r PREV:HEAD
The Subversion switch -r allows us to specify revisions - numeric representations of each change. PREV and HEAD are special references, being the previous change and latest version respectively. Sometimes we might be instructed to test or use a specific version, called revision. In that case, it is possible to retrieve it by issuing:
$ svn up -r 1234
Replace 1234 with the revision number you are told to use. This will update the whole checkout to that revision, and you should now run again the commands discussed above, repeating the same process as after just having checked out. But sometimes we might need to update only one or a few files to a specific revision - that can be done by specifying path, for example:
$ svn up -r 1234 frontends/php/discovery.php
You can specify both directories and files and get different revisions to test behavior changes or find the specific change that introduced a problem for you.
So you have tried out a development version, maybe several revisions. Some time later, you decide to find out what changes have been made to the trunk. First, the current revision should be figured out, while in the checkout directory, run the following command:
$ svn info
Look for the line that looks like this:
Revision: 8000
With that number on hand, it is now time to update local copy to the latest and greatest. From the local copy directory, run:
$ svn up
This will proceed to update everything that has changed, compared to whatever copy you have. As only changes are pulled, this will result in much less data downloaded, compared to downloading daily snapshots over and over again. Now you can just proceed with building Zabbix as discussed before, or you can choose to view what exact changes developers have committed:
$ svn log -r 11000:HEAD
This command will display the exact changes pushed to the code repository, along with any comments that the developers decided to add. This can be used to determine what exactly was changed. But all this about forward looking development version, trunk - what if you want to see a particular bug fix for some problem in the stable version, applied to that particular branch? Just as we grabbed the trunk from the code repository, we can also grab the branch. Create a separate directory to hold this checkout, and issue:
$ svn checkout svn://svn.zabbix.com/branches/1.8
As we can see, instead of the trunk we are now specifying the subsection branches. After that comes the specific branch, which can be any valid branch.
While installing a branch version is pretty much the same as installing the trunk, there's one more use case with branches. If a particular bug is fixed in the branch and you want to benefit from that before the next stable version is out, it is possible to apply this single change to the installed copy. To do that, though, the change first has to be extracted in a format that is easy to reuse. Here, another command comes to help. Remember svn log we used to look at the changesets before? It showed the revision number for each changeset. If we now have this number, we can take a look at what files a particular commit modified.
$ svn log -v -c 8001
Here we use the switches -c to specify single changeset and -v to increase verbosity level. In the Changed paths section one or more files will be listed, for example:
M /trunk/ChangeLog M /trunk/src/zabbix_server/operations.c
When creating a patch, we might want to omit files that do not affect actual software behavior, ChangeLog in this case. Creating a patch thus would be done like this:
$ svn diff -c 8001 src/zabbix_server/operations.c > /tmp/zabbix.patch
Notice how we used Subversion's diff subcommand, specified a single file, and redirected output to a file. Now the patch should be applied to our Zabbix installation. To do this, transfer the patch file to Zabbix source installation directory and execute:
$ patch -p 0 -i zabbix.patch
The patch utility is instructed use input file zabbix.patch and use full path information as specified to apply the changes. After patching we should evaluate areas the patch applies to - if it's the server, we should recompile and reinstall our server binary, the same with the agent daemon. If changes were performed on the frontend only, we'll usually want to apply the patch to the installed frontend directly, by placing the patch in the frontend directory and applying it as root with:
# patch -p 2 -i zabbix.patch.
Note that in this case we are instructing the patch utility to strip the first two directories from the path. When we are patching the frontend, no recompilation is necessary, and all changes will be visible immediately. What if we applied a patch, but it only made things worse? Thankfully, that is easy to undo by applying the same patch in reverse:
# patch -R -p 2 -i zabbix.patch
If using the above command line for the frontend, again, no further action is required. If it affects binaries, we would have to recompile them.