Building istatd

Home - Building istatd

istatd is pretty easy to build on Linux, but it will require a few other packages to be installed first:

• g++
• make
• libboost-all-dev
• libstatgrab-dev

Then ensure you have a copy of the source on your drive (you may git clone or download the source as a .tar.gz)

After that, compiling should be as simple as running configure and make in your terminal. This should produce a file in the bin/ directory.

From there, you can sudo make install to install the built-from-source istatd to your machine. If you want to install under the /usr/local hierarchy, pass --prefix /usr/local to the ./configure script.

Building a Debian Package

You can run make dpkg to make a debian package for istatd.

This will produce a debian package containing an optimized istatd build, with symbol tables intact. Afterwards, in a folder one up from the Makefile, there should be various build artifacts, including a .deb file, which can be installed with an appropriate dpkg -i command.

Make files, not autotools

The make file is automatic.

• Anything in lib/ ending in .cpp gets included into libistat.
• Headers for those things should live in include/istat (this will simplify later installation builds, if appropriate).
• Anything in daemon/ ending in .cpp gets included into the bin/istatd executable. Headers just live in daemon as well.
• Anything in tool/ ending in .cpp gets built as a separate command-line tool, with the libistat library linked (as well as boost dependencies etc).
• Anything in test/ ending in .cpp gets built as a separate command-line program, and executed as part of the make. This ensures that unit tests pass.
• Unit tests are not as comprehensive as they could be, and the daemon is not as factored into testable parts as it could be. It's still a lot better than nothing.
• The build uses one small lib with a "public" API (libistat) and one large lib with everything else except main.cpp. The reason for the second lib is largely to support unit testing.
• Dependencies (included files, outputs) are automatically tracked, so toucing a .h file will automatically re-build the necessary .cpp files etc.
• Files in ftest/ starting with test_ are run as functional tests at the end of a build. These make use of a common set of functions in ftest/functions and also a common set of configurations in ftest/*.cfg

Because the daemon may want to open privileged files for local stats, bind to ports that may be privileged, and update the number of files that may be opened at one time (important!), it wants to run as suid root. It will drop privileges after starting up. However, as the file gets re-written each time it is built, a script named suid.sh is called after linking if it exists and is executable. This will attempt to sudo chmod the output file -- prepare to enter your password, or abort.