My friend Sam Ruby dabbles in a lot of technology, and he tends to do writeups on his blog as he experiments with the stuff. I figured to take a page from his book, and share my own issues/troubles getting Zabbix up and running on my MacBook (running Leopard).
I grabbed the 1.8.8 tarball and unpacked it. For my scenario, I needed the server, the agent, and the frontend (but not the proxy). For simplicity in testing, and because I don't need to monitor bunches o' boxes, I decided to go with SQLite for the database. Zabbix uses the standard "configure/make/make install" pattern, so no hassle so far.
Burp. The compilation failed. Investigating, I found that I needed to apply the patch from ZBX-4085. The build completed, so started to look at the frontend.
The Frontend is written in PHP, which is natively available (along with Apache) on my laptop. With some configuration, I got the frontend to load in my browser. There is a click-through GPL license (huh?) and then a really awesome page that checks your setup. I quickly realized that the builtin PHP was not going to work. Sigh.
I've got MacPorts installed on my laptop, so I just continued with that. Homebrew is all the new rage with the kids, but it doesn't have builtin recipes for PHP. There are a few out on the 'net, but I really didn't want to monkey with that stuff.
Lots of packages were needed: php5, php5-gd, php5-mbstring, php5-sockets, php5-sqlite3, sqlite3. A hojillion dependencies were installed, including another copy of Apache (sigh).
Reloading the setup page, it continued to say SQLite wasn't installed. Looking at the frontend source, it was using a function named sqlite3_open(). With some investigation, I found an email describing the SQLite interfaces for PHP. Zabbix was using an unmaintained version. Rather than monkeying with that, I just edited the code to use the preferred PHP SQLite interface, and filed issue ZBX-4289 to push my changes upstream.
Finally, I needed to tweak /opt/local/etc/php5/php.ini for the recommended Zabbix settings (after copying php.ini-development to php.ini). This included some timezone settings, timeouts, upload sizes, etc. The Zabbix setup page is quite good about guiding you here.
So I created my initial SQLite .db file based on the instructions from the manual and pointed the Zabbix configuration page at it (taking a moment to realize it wanted the pathname put into the database field of the form). The test connection worked and then Zabbix saved the configuration file into frontends/php/conf/zabbix.conf.php. It looks like there is a "download" option for that configuration file, which I presume appears when the conf directory is not writeable. The Apache server (running from MacPorts now, using the MacPorts PHP) was running as myself, so it had no problem writing that configuration file.
Next up: wrestling with the zabbix-server. The first annoying problem was that you cannot give it a configuration file in the current directory. It fails trying to lock "." for some dumb reason. Solution: pass an absolute path to the custom configuration file (the default is in /etc or somesuch, which I didn't want to monkey with). Getting the server running was very frustrating because it spawns multiple processes which communicate using shared memory. It kept failing with errors about not being able to allocate the shared memory segments. After some research, I found that Mac OS defaults to some pretty small limits. Given that I wasn't about to reconfigure my kernel (using sysctl and some recipes I found on the web), I went to rejigger all the various cache sizes in the zabbix_server.conf file.
It ended up that I had to drop all the sizes to their minimum 128k setting: CacheSize, HistoryCacheSize, TrendCacheSize, HistoryTextCacheSize. Each were set to 131072. Finally, the server started. Whew.
When I returned to the frontend to "Finish" the installation and bring up the console... it hung. No response from the server. Huge sigh. With a bunch of investigation, I found that something was holding an exclusive lock on the whole damned SQLite file. Nothing else could write to it (and it seems the frontend likes to test its writability by creating/dropping a dummy table).
Fuck. Time to scrap the whole damned "simple SQLite" idea. Fine... I've used MySQL before, so I went with that. Back to MacPorts to install MySQL, the server, and the PHP driver for MySQL. Then I fired it up, created a "zabbix" user, loaded in all the tables, and zapped the zabbix.conf.php file to trigger reconfiguration (after noting to restart Apache to pick up the PHP changes).
The frontend looked happy now, so I tweaked the server's configuration file for MySQL and restarted the server. No workee. Damn. Forgot to reconfigure the server using --with-mysql=/opt/local/lib/mysql5/bin/mysql_config. After reconfiguring, the link failed with unsatisfied references to iconv(), iconv_open(), and iconv_close(). The MySQL interface in the server needs these for some UTF-8 conversions. The builtin Mac OS libiconv should work, but my MacPorts copy of libiconv was interfering, and these functions are named libiconv(), libiconv_open(), and libiconv_close(). My patience was ending, so I was not about to delve into autoconf bullshit and conditional compilation and all that. I simply edited src/libs/zbxcommon/str.c to call the libiconv* versions of the functions. The compile and link succeeded, and I re-installed the newly built server.
Yay! The server restarted, and the website loads up with a nifty little default console.
After a day to get this sucker installed, now I gotta start figuring out how to use it. Oh, joy.
I hope this post will help some future person treading these waters. Good luck!
ps. I may have missed some steps or packages to install or whatever. YMMV, but I think that I've got most of it down. Zabbix is supposed to be some hotness, and I do like its custom agent capability. But hoo-wee. Not a simple package to bring up (I hope it will be easier on a recent Ubuntu, than it was on my creaky Leopard install).
