The default net-snmp binary builds don’t come with lm_sensors MIBs configured. If you want to add sensor graphs (voltage, fans, temperatures) to your cacti graph trees, you’ll have to build net-snmp from source and enable the lm_sensors MIBs when configuring.

First, install lm_sensors and configure using sensors-detect. Once you are able to see sensor data by running sensors move on with installing net-snmp.

PKGBUILD (Arch Linux)

# Maintainer: Eric Belanger <eric <at> archlinux.org>
# Contributor: Herbert Molenda <me <at> herbertm.ca>

pkgname=net-snmp
pkgver=5.6.1
pkgrel=2
pkgdesc="net-snmp with lm_sensors MIB"
arch=('i686' 'x86_64')
url="http://www.net-snmp.org/"
license=('custom')
depends=('openssl' 'tcp_wrappers' 'libnl' 'lm_sensors')
makedepends=('setuptools')
optdepends=('perl-term-readkey: for snmpcheck application' 
            'perl-tk: for snmpcheck and tkmib applications'
            'python2: for the python modules')
provides=('ucd-snmp')
options=('!libtool' '!makeflags' '!emptydirs')
source=("http://downloads.sourceforge.net/sourceforge/${pkgname}/${pkgname}-${pkgver}.tar.gz"
        'snmpd.rc')
md5sums=('b4e30ead5783b0bb1d280172c6095ea4'
         '9f0d13676ba1fae1eb7eb178edd85b43')
sha1sums=('45bbf1295253d5379a5d1efd918593160387fd00' '2c679b564a2c319d9ce2714a9776aa0e6d89c60a')

build() {
  cd "${srcdir}/${pkgname}-${pkgver}"
  sed -i -e "s:\(install --basedir=\$\$dir\):\1 --root='${pkgdir}':" Makefile.in
  ./configure --prefix=/usr --sysconfdir=/etc --mandir=/usr/share/man \
    --enable-ucd-snmp-compatibility --enable-ipv6 --with-libwrap --with-python-modules \
    --with-default-snmp-version="3" --with-sys-contact="root@localhost" \
    --with-sys-location="Unknown" --with-logfile="/var/log/snmpd.log" \
    --with-mib-modules="host misc/ipfwacc ucd-snmp/diskio tunnel ucd-snmp/dlmod ucd-snmp/lmsensorsMib" \
    --with-persistent-directory="/var/net-snmp" \
    PYTHONPROG=/usr/bin/python2
  make NETSNMP_DONT_CHECK_VERSION=1 LDFLAGS+="-Wl,-lsensors"
}

package() {
  cd "${srcdir}/${pkgname}-${pkgver}"
  make DESTDIR="${pkgdir}" INSTALL_PREFIX="${pkgdir}" INSTALLDIRS=vendor install
  install -D -m755 "${srcdir}/snmpd.rc" "${pkgdir}/etc/rc.d/snmpd"
  install -D -m644 COPYING "${pkgdir}/usr/share/licenses/${pkgname}/COPYING"
}
</me></eric>

Documentation in this arena being slim, I felt it would be helpful to write a short article on my configuration. FastCGI examples are generally documented in about two or three blog posts on the subject, all of which have become dated. For the basic ground work take a look at streamhacker.

Firstly, the fastcgi process is unaware whether you are using HTTP or HTTPS, another fastcgi_param must be passed to solve the following error:

searching for changes
ssl required

fastcgi_param   HTTPS           on;

If you are having the following error, and you have ensured that HTTPS is functioning and allow_push = username is specified in the repo’s .hg/hgrc:

searching for changes
27 changesets found
abort: authorization failed

Then the fastcgi process isn’t receiving the username from nginx. Ensure that the following lines are added to your nginx config:

fastcgi_param   AUTH_USER       $remote_user;
fastcgi_param   REMOTE_USER     $remote_user;

Nginx is also liable to spit out a:

413 Request Entity Too Large

on your first major commit. This is because the max_body_size is set low by default and is unacceptable for a mercurial application. Ensure to add and modify this line to your needs:

client_max_body_size    100M;

my entire nginx vhost.conf

server {
    listen      443;
    server_name hg.DOMAIN.COM;

    ssl                  on;
    ssl_certificate      server.crt;
    ssl_certificate_key  server.key;
    ssl_session_timeout  5m;
    ssl_protocols  SSLv2 SSLv3 TLSv1;
    ssl_ciphers  ALL:!ADH:!EXPORT56:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP;
    ssl_prefer_server_ciphers   on;

        # Increase transfer size to accommodate large pushes
        client_max_body_size    100M;

        location / {
                auth_basic "Restricted Access";
                auth_basic_user_file /repo/sites/hg.DOMAIN.COM/mercurial_passwd;
                fastcgi_pass    127.0.0.1:9001;
                fastcgi_param   PATH_INFO       $fastcgi_script_name;
                fastcgi_param   AUTH_USER       $remote_user;
                fastcgi_param   REMOTE_USER     $remote_user;
                fastcgi_param   QUERY_STRING    $query_string;
                fastcgi_param   REQUEST_METHOD  $request_method;
                fastcgi_param   CONTENT_TYPE    $content_type;
                fastcgi_param   CONTENT_LENGTH  $content_length;
                fastcgi_param   SERVER_PROTOCOL $server_protocol;
                fastcgi_param   SERVER_PORT     $server_port;
                fastcgi_param   SERVER_NAME     $server_name;
                fastcgi_param   HTTPS           on;
        }
        location ~ /\.ht {
            deny  all;
        }
}

hg clone ssh://user@host/path/to/repo

Is simple enough…

But what about when you have a repo called “big repo”. Took me a while to figure out (with ssh verbosity) that a combination of the regular special character ‘\’ and quotes is required for hg to call the right ssh command.

hg clone "ssh://user@host/path/to/big\ repo"

A simple test this evening between two FreeBSD 8.0-RELEASE machines. OpenVPN 2.1.1 compile from ports (source).

gen2 i386, Pentium 4 2.0GHz 2.0GB circa 2003

[root@gen2 /usr/ports/security/openvpn]# make install
real	4m11.491s
user	1m46.402s
sys	0m26.863s

blackbox i386, Athlon Thunderbird 1.0GHz 512MB circa 2001

[root@blackbox /usr/ports/security/openvpn]# make install
real	6m9.970s
user	3m15.515s
sys	0m43.739s

I recently migrated my RAID-5 home storage array to RAIDZ using ZFS on FreeBSD 8.0-RELEASE. FreeBSD’s latest release includes ZFS v13 with many tuning patches, making ZFS not only more stable but easier to tune.

It is noted that on 64-bit systems with over 2GB RAM, default auto-tuning settings will be quite stable. However in any other configuration some tuning is still necessary to achieve a stable system.

On 32-bit you still have to compile a custom kernel per these instructions. If it is your first time compiling a custom kernel, don’t worry it is a very short procedure. Kernel KVA_PAGES (virtual address space) must be increased to allow for ZFS to use more kernel memory. The setting for this value depends on other userland applications that will be running on the server, and how much memory they require. KVA_PAGES value must be a multiple of 4 and that is how you can determine the kernel memory allocation, in my case:

KVA_PAGES=384 -> 384 * 4 -> 1536MB (1.5GB)

System configuration:

FreeBSD/i386 8.0 (Pentium 4)
2GB RAM
965GB ZFS RAID-Z over 3 drives

The general guideline I followed for setting tuning values was:

vm.kmem_size -> 1/2 of total RAM
vm.kmem_size_max -> 1/2 of total RAM
vfs.zfs.arc_max -> 1/2 of vm.kmem_size_max

However when testing at high transfer load (1000mbit LAN) with arc_max set to 512MB I still experienced kernel panics. I still suggest starting at 1/2 of kmem_size and working down from there.

Final stable tuning values:

# /boot/loader.conf
vm.kmem_size="1024M"
vm.kmem_size_max="1024M"
vfs.zfs.arc_max="256M"

# /etc/sysctl.conf
kern.maxvnodes="400000"

# Custom Kernel Options
options    KVA_PAGES=384    # increase kernel virtual address space for ZFS