Note: This howto requires a patch to your FreeBSD ports tree. The patch has been submitted to the FreeBSD port maintainers. I hope that it will eventually end up in the ports tree.

My initial readings about this was on the official Icinga docs covering installing Icinga on FreeBSD with IDOUtils.
However, as it turned out, the docs our a bit outdated, and yet do not reflect a way of doing the install using ports.

So here’s just a short primer on what I did do install Icinga from ports, imposing as little additional work four you, my fellow reader, as well

Now let’s turn to Icinga, which has a port on it’s own, which you’ll find it at /usr/ports/net-mgtm/icinga. First change to that directory.

cd /usr/ports/net-mgtm/icinga

Now download the patch file I made into your ports directory.
The patch will inject a new rc-script for ido2db and enable your port to build IDOutils.

[root@localhost /usr/ports/net-mgmt/icinga]# fetch http://phaq.phunsites.net/files/2012/01/patch_icinga_1.5.1_idoutils_fbs_port.txt

Then apply the patch like this:

[root@localhost /usr/ports/net-mgmt/icinga]# patch -p0 < patch_icinga_1.5.1_idoutils_fbs_port.txt
Hmm...  Looks like a unified diff to me...
The text leading up to this was:
--------------------------
|--- Makefile.org	2012-01-28 16:36:46.000000000 +0000
|+++ Makefile	2012-01-28 17:51:38.000000000 +0000
--------------------------
Patching file Makefile using Plan A...
Hunk #1 succeeded at 27.
Hunk #2 succeeded at 109.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|--- /dev/null	2012-01-28 18:00:51.000000000 +0000
|+++ files/ido2db.in	2012-01-28 18:00:30.000000000 +0000
--------------------------
(Creating file files/ido2db.in...)
Patching file files/ido2db.in using Plan A...
Hunk #1 succeeded at 1.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|--- files/pkg-message.in.org	2012-01-28 17:48:37.000000000 +0000
|+++ files/pkg-message.in	2012-01-28 17:49:38.000000000 +0000
--------------------------
Patching file files/pkg-message.in using Plan A...
Hunk #1 succeeded at 4.
done

Now you’re ready to configure the port:

[root@localhost /usr/ports/net-mgmt/icinga]# make config

Note the now IDOUtils option that now has appeared. Check it to enable IDOUtils.

Then compile and install as usual. The port will install also all required dependies, two of them being mysql55-client and libdbi-drivers, both to be found at /usr/ports/databases.

[root@localhost /usr/ports/net-mgmt/icinga]# make install clean

Afterwards, you should end up with a few additional files, which would not be installed with the stock FreeBSD port.

[root@localhost /usr/ports/net-mgmt/icinga]# ls -l /usr/local/bin/ido*
-rwxrwxr--  1 root  wheel  238326 Jan 28 16:53 /usr/local/bin/ido2db
-rwxrwxr--  1 root  wheel   80419 Jan 28 16:53 /usr/local/bin/idomod.o

[root@mgmp-bs01 /usr/ports/net-mgmt/icinga]# ls -l /usr/local/etc/rc.d/ido2db
-r-xr-xr-x  1 root  wheel  738 Jan 28 18:00 /usr/local/etc/rc.d/ido2db

Now you can enable Icinage and IDO2DB in /etc/rc.conf by adding these lines:

icinga_enable="YES"
ido2db_enable="YES"

Of course, you still need to perform the usual Icinga configuration steps, which are not covered in this post.
Please check with the official docs for this procedure.

If your configuration is proper, you should notice this in your logs indicating that IDOMOD (IDOUtils) is really working.

[1327773651] Icinga 1.5.1 starting... (PID=95448)
[1327773651] Local time is Sat Jan 28 18:00:51 UTC 2012
[1327773651] LOG VERSION: 2.0
[1327773651] idomod: IDOMOD 1.5.1 (09-09-2011) Copyright (c) 2005-2008 Ethan Galstad (nagios@nagios.org), Copyright (c) 2009-2011 Icinga Development Team (http://www.icinga.org))
[1327773651] idomod: Successfully connected to data sink.  26 queued items to flush.
[1327773651] idomod: Successfully flushed 26 queued items to data sink.
[1327773651] Event broker module '/usr/local/bin/idomod.o' initialized successfully.
[1327773651] Finished daemonizing... (New PID=95450)

That’s it, you conquered the beast!


[root@localhost ~]# cd /usr/ports/math/php5-bcmath && make clean install


However, I ended up with a crude error message:

Cannot find autoconf. Please check your autoconf installation and the
$PHP_AUTOCONF environment variable. Then, rerun this script.

Bummer! So let’s see how to fix this.

Here’s the complete output from the failed build:


[root@localhost /usr/ports/math/php5-bcmath]# make
===> Vulnerability check disabled, database not found
===> License check disabled, port has not defined LICENSE
===> Extracting for php5-bcmath-5.3.3_2
=> SHA256 Checksum OK for php-5.3.3.tar.bz2.
===> Patching for php5-bcmath-5.3.3_2
===> php5-bcmath-5.3.3_2 depends on file: /usr/local/bin/phpize - found
===> php5-bcmath-5.3.3_2 depends on file: /usr/local/bin/autoconf-2.68 - found
===> PHPizing for php5-bcmath-5.3.3_2
Configuring for:
PHP Api Version: 20090626
Zend Module Api No: 20090626
Zend Extension Api No: 220090626
Cannot find autoconf. Please check your autoconf installation and the
$PHP_AUTOCONF environment variable. Then, rerun this script.

Stop in /usr/ports/math/php5-bcmath.


From this we see, that error occurs during phpize, which tries to configure/build the extension matching up the currently installed PHP.

Looking into phpize, which is actually a plain script, we find these lines:


[root@noc2 /usr/ports/math/php5-bcmath]# grep -E -e 'PHP_AUTO(CONF|HEADER)' /usr/local/bin/phpize
test -z "$PHP_AUTOCONF" && PHP_AUTOCONF=autoconf-2.62
test -z "$PHP_AUTOHEADER" && PHP_AUTOHEADER=autoheader-2.62
if test ! -x "$PHP_AUTOCONF" && test ! -x "`$php_shtool path $PHP_AUTOCONF`"; then
\$PHP_AUTOCONF environment variable. Then, rerun this script.
if test ! -x "$PHP_AUTOHEADER" && test ! -x "`$php_shtool path $PHP_AUTOHEADER`"; then
\$PHP_AUTOHEADER environment variable. Then, rerun this script.
$PHP_AUTOCONF || exit 1
$PHP_AUTOHEADER || exit 1


So phpize actually checks for existence of the PHP_AUTOCONF and PHP_AUTOHEADER environment variables.
If these are missing, it will use some defaults for the autoconf/autoheader tools. The default were derived during the initial build which at that time were autoconf-2.62 and autoheader-2.62.

Checking installed ports reveals that there’s a newer version installed, which is why phpize fails so terribly.


[root@noc2 /usr/ports/math/php5-bcmath]# pkg_info|grep autoconf
autoconf-2.68 Automatically configure source code on many Un*x platforms
autoconf-wrapper-20071109 Wrapper script for GNU autoconf


To permanently fix this, you can do either of the following:

1. simply change the PHP_AUTOCONF and PHP_AUTOHEADER variables in /usr/local/bin/phpize to reflect the currently installed version
2. additionally install the old autoconf version besides the new one
3. Invoke the build like this:
   
PHP_AUTOCONF=autoconf PHP_AUTOHEADER=autoheader make configure


So you don’t have native IPv6 network access? No problem, just use a Teredo Tunnel to get connected.
Here’s a very short primer on doing so on FreeBSD.

Firstly install the miredo package from the ports tree.


[root@GPWS ~]# cd /usr/ports/net/miredo/
[root@GPWS /usr/ports/net/miredo]# make clean install


Alternatively, install the binary package:


[root@GPWS ~]# pkg_add -r miredo


Enable miredo in your rc.conf:


[root@GPWS ~]# echo miredo_enable=YES >> /etc/rc.conf


Make sure to have a proper /usr/local/etc/miredo.conf.
Here’s my very minimalistic config:


#! /usr/local/sbin/miredo -f -c
#
RelayType client
InterfaceName teredo
#BindPort 3545
#BindAddress 192.168.2.1
ServerAddress teredo.ipv6.microsoft.com


Note: Depending on your setup, e.g. with multiple interfaces, you may need to specify a BindAddress to use the proper network interface.
So to speak, you may need to specify also a specific port for some NAT setups.

Now fire up miredo:


[root@GPWS ~]# /usr/local/etc/rc.d/miredo start


You should end up with a new network interface by the name of ‘teredo’:


[root@GPWS ~]# ifconfig teredo
teredo: flags=43 metric 0 mtu 1500
options=80000
inet6 fe80::ffff:ffff:ffff%teredo prefixlen 64 scopeid 0xb
inet6 2001:0:5ef5:79fb:4e9:5e1b:2ba5:360b prefixlen 128
nd6 options=3
Opened by PID 93528


You should now be able to ping6 any IPv6-enabled host on the internet.


[root@GPWS ~]# ping6 www.google.ch
PING6(56=40+8+8 bytes) 2001:0:5ef5:79fb:4e9:5e1b:2ba5:360b --> 2a00:1450:8001::93
16 bytes from 2a00:1450:8001::93, icmp_seq=0 hlim=57 time=90.062 ms
16 bytes from 2a00:1450:8001::93, icmp_seq=1 hlim=57 time=18.996 ms
16 bytes from 2a00:1450:8001::93, icmp_seq=2 hlim=57 time=18.810 ms
^C
--- www.l.google.com ping6 statistics ---
3 packets transmitted, 3 packets received, 0.0% packet loss
round-trip min/avg/max/std-dev = 18.810/42.623/90.062/33.545 ms


Happy surfing!

Here’s my short primer on setting up Redmine on FreeBSD.

In my case, I just wanted a rather simplistic and stripped-down environment, which was the reason to choose Redmine.
While it can perfectly integrate with Apache, Nginx and other web-servers, I preferred to use the minimalistic “thin” web-server.
I do as well use self-compiled port in favor to binary packages. Feel free to use binary packages if you like

Installing the software

Redmine requires a database server. Either MySQL or PostgreSQL or sqlite.
If chose to use MySQL and installed it from the ports using defaults:


[root@localhost ~] cd /usr/ports/databases/mysql51-server; make build install


Then install Redmine from /usr/ports/www/redmine.


[root@localhost ~] cd /usr/ports/www/redmine; WITHOUT_X11=true make config build install


It’s important to fire up the “config dialog” to include the “thin” web-server:

Enable service configuration

Enable the services in your /etc/rc.conf.


mysql_enable="YES" # enable MySQL server
redmine_enable="YES" # enable redmine server
redmine_flags="-a 0.0.0.0 -p 3000 -e production --ssl --ssl-key-file=/usr/local/www/redmine/config/server.key --ssl-cert-file=/usr/local/www/redmine/config/server.crt"


I choose to enable SSL in the configuration above. If you don’t need SSL, then change the “redmine_flags” line to read as follows:


redmine_flags="-a 0.0.0.0 -p 3000 -e production"


Prepare MySQL

Now start mysql server:


[root@localhost ~] /usr/local/etc/rc.d/mysql-server start


Fire up the mysql console.
If this happens to be the first time you use MySQL, then you won’t have a password yet. It may be a good idea then, to first assign new passwords and remove the default database stuff. Do this


delete from user where user='';
delete from db where user='';
drop database test;
flush privileges;


Now create the database and user for use with Redmine:


create database redmine character set utf8;
create database redmine_devel;
create database redmine_test;
create user 'redmine'@'localhost' identified by 'A_secRET_passw0RD';
grant all privileges on redmine.* to 'redmine'@'localhost';
grant all privileges on redmine_devel.* to 'redmine'@'localhost';
grant all privileges on redmine_test.* to 'redmine'@'localhost';


Prepare Redmine

For Redmine you’ll need to edit some configuration files at /usr/local/www/redmine/config first.
First copy the “database.yml.example” file to “database.yml”.


[root@localhost ~]# cd /usr/local/www/redmine/config
[root@locahost /data/local/www/redmine/config]# cp database.yml.example database.yml


Now edit the “database.yml” file to your correct database settings:

production:
  adapter: mysql
  database: redmine
  host: localhost
  username: redmine
  password: A_secRET_passw0RD
  encoding: utf8

development:
  adapter: mysql
  database: redmine_development
  host: localhost
  username: redmine
  password: A_secRET_passw0RD
  encoding: utf8

# Warning: The database defined as "test" will be erased and
# re-generated from your development database when you run "rake".
# Do not set this db to the same as development or production.
test:
  adapter: mysql
  database: redmine_test
  host: localhost
  username: redmine
  password: A_secRET_passw0RD
  encoding: utf8

Now create the session store and import the initial database as follows:


[root@localhost /data/local/www/redmine/config]# rake generate_session_store
[root@localhost /data/local/www/redmine/config]# RAILS_ENV=production rake db:migrate


To enable mail processing, you need to copy “email.yml.example” to “email.yml”:


[root@locahost /data/local/www/redmine/config]# cp email.yml.example email.yml


Then edit “email.yml” to your proper email settings. The following example is for SMTP delivery through an external host:

production:
  delivery_method: :smtp
  smtp_settings:
    address: SMTP.DOMAIN.TLD
    port: 25
    domain: SMTP.DOMAIN.TLD
    authentication: :login
    user_name: "smtp_user_name"
    password: "some_password"

development:
  delivery_method: :smtp
  smtp_settings:
    address: SMTP.DOMAIN.TLD
    port: 25
    domain: SMTP.DOMAIN.TLD
    authentication: :login
    user_name: "smtp_user_name"
    password: "some_password"

Optional: Enable SSL mode

I enabled SSL for the “thin” web-server in /etc/rc.conf. If you choose to not use SSL, skip this step.

To enable SSL, you need to create the SSL private key and a certificate.
I’m giving just the command list here, as this procedure is otherwise very well documented over there at the mod_ssl FAQ.


openssl genrsa -des3 -out server.key.cryped 1024
openssl rsa -in server.key.crypted -out server.key
openssl req -new -key server.key -out server.csr
openssl req -new -x509 -days 365 -key server.key -out server.crt


The above procedure would essentially create a password-protected key (step 1), which would then get the password removed (step 2). I’d then create a signing request in the 3rd step and have a self-signed certificate created (last command).
The removal of the password is essential to start the web-server without prompting for a password.

Now, there was just one little cave-at I came along. On my setup, Redmine would not properly run in SSL mode in some cases create redirect url containing http:// instead of https://.
I suspect this is a problem caused by the “thin” web-server, which would not properly state that it runs in SSL mode to the application. Obviously, wenn running “thin” in SSL mode, it would no longer word in “http plain” mode, so this causes some errors.

For example, when logging on to your host using https://HOSTNAME:3000, you’d get redirected to http://HOSTNAME:3000/login?back_url=http://HOSTNAME:3000″.
Now, as this obviously won’t work, there’s a little change required in the “/usr/local/www/redmine/vendor/rails/actionpack/lib/action_controller/request.rb” file.

Look out for this text block:

    # Is this an SSL request?
    def ssl?
      @env['HTTPS'] == 'on' || @env['HTTP_X_FORWARDED_PROTO'] == 'https'
    end

Then change it to look like this:

    # Is this an SSL request?
    def ssl?
        true
    end

This will force Redmine into thinking it’s permanently SSL enabled, thus it will always generate proper https:// URLs.
This particular issue would propably not come up when using Apache or Nginx in SSL forwarding mode.

Start using Redmine

Now you’re basically done. Start accessing Redmine through https://YOURHOSTNAME:3000 (or http://YOURHOSTNAME:3000, in case you left SSL disabled).

And don’t forget to change your default username/password settings upon first login.

I recommed the Redmine User’s Guide for further reading

I used to do hot-plugging before, but I’ve never done this with a whole enclosure at once. Well worth a try?

Some things to be considered for my scenario:

• The Sun StorEdge Multipack auto-assigns SCSI-IDs ascending through it’s internal slots. Depending on the mode switch, it’ll assign IDs 1 through 6 or 9 through 15. On the Netra T1 105 only IDs 1 through 7 are supported. This is no big deal, unless you already have two disks plugged into the internals bays (they take IDs 0 and 1).
  So you can add a maximum of 5 additional disks (IDs 2 through 6). This actually means that you can only add disks to bays 2 through 6, leaving bay 1 empty. If you keep a disk inside, it’ll get ID 1, which won’t work out as this is already taken by an internal bay hard drive.
• Also important is that the enclosure is not powered-up. Attach it to the SCSI bus first, before you power on.

After powering on the enclosure it’ll take a few moments to initialize and spin-up the drives.

I recommend waiting for the SCSI ID LED to light up, before you proceed.
Before you rescan the bus, check which devices you see.


[root@rohan ~]# camcontrol devlist
IBM DDYST1835SUN18G S96H at scbus0 target 0 lun 0 (da0,pass0)
IBM DDYST1835SUN18G S96H at scbus0 target 1 lun 0 (da1,pass1)


The you can either add each new divice one by one, issuing a “scan” command for the respective SCSI-ID:


[root@rohan ~]# camcontrol rescan scbus0:2:0
[root@rohan ~]# camcontrol devlist
IBM DDYST1835SUN18G S96H at scbus0 target 0 lun 0 (da0,pass0)
IBM DDYST1835SUN18G S96H at scbus0 target 1 lun 0 (da1,pass1)
FUJITSU MAN3184M SUN18G 1502 at scbus0 target 2 lun 0 (da2,pass2)


Or you could try to rescan to whole bus at once:


[root@rohan ~]# camcontrol rescan scbus0
Re-scan of bus 0 was successful
[root@rohan ~]# camcontrol devlist
IBM DDYST1835SUN18G S96H at scbus0 target 0 lun 0 (da0,pass0)
IBM DDYST1835SUN18G S96H at scbus0 target 1 lun 0 (da1,pass1)
FUJITSU MAN3184M SUN18G 1502 at scbus0 target 2 lun 0 (da2,pass2)
FUJITSU MAJ3182M SUN18G 0804 at scbus0 target 3 lun 0 (da3,pass3)
IBM DDYST1835SUN18G S96H at scbus0 target 4 lun 0 (da4,pass4)
SEAGATE ST318203LSUN18G 034A at scbus0 target 5 lun 0 (da5,pass5)
SEAGATE ST318203LSUN18G 034A at scbus0 target 6 lun 0 (da6,pass6)


Conclusion: If you first connect to the bus and then power-up the enclosure so all disks can properly initialize, adding the enclosure and it’s disks while online is definitely possible. Of course, you should only be doing this with hot-plug ready equipment, which supports auto-termination.

This comes in handy in creating disk images, which can be a very time consuming task.

Let’s look at the numbers of creating a 20gig file, which fills up available disk space at once but takes about five minutes to do so. Not to forget about the I/O load the task produces, which affects performance.

[root@localhost vz]# time dd if=/dev/zero of=test1.img bs=1024k count=20480
20480+0 records in
20480+0 records out
21474836480 bytes (21 GB) copied, 321.902 seconds, 66.7 MB/s

real    5m21.903s
user    0m0.021s
sys     0m55.282s

Creating a 20gig sparse file is done almost immediately, with the difference that disk blocks are not allocated right away.

[root@localhost ~]# dd of=test2.img bs=1024k count=0 seek=20480
0+0 records in
0+0 records out
0 bytes (0 B) copied, 1.4744e-05 seconds, 0.0 kB/s

real    0m0.002s
user    0m0.000s
sys     0m0.002s

Some possible drawbacks when using sparse files:

• Peformance degredation when having multiple sparse files to which data is written randomly. This may end up in heavy fragmentation as the sparse files are likely not to be written contiguously in that case, which in term causes slow read access performance
• Race conditions when creating many sparse files which would exceed the available disk space (e.g. 20 sparse files of 20 gigs each, but the disk is only 200 gigs in size). To handle this, a special monitoring script would be needed to consider logical vs. physical space allocation.

Up until today, I always used pre-allocated disk images, but at the expense of non-usable disk space.
I think that sparse files might be a good choice actually, at least as long as there’s not much random data written to it, so the payload stays mostly identical over longer periods of time.
For sure, a sparse file used as image for a jail-based database server is definitely a bad idea.
Nevertheless, I’m keen to try and see, if this might be a considered options for some real-live scenarios.

Despite having it compiled with IPV6 support enabled, it pretended in missing IPv6 support, throwing this error message at me.

Syntax error on line 336 of /usr/local/etc/apache22/httpd.conf:
The specified IP address is invalid.


The line in question contained a “limit” clause like this:

allow from ::1

This behaviour is very odd indeed, as one would expect that compiling Apache 2.2 with IPv6 should effectively permit the afore mentioned configuration statement.

The reason for this behaviour lies much deeper and is not directly related to the Apache 2.2 port itself, but to one of it’s core dependencies, the APR (Apache Portable Runtime).

Depending on which ports you compile and install, chances are that a few may require the APR library to work properly.
One amongst them is subversion (svn).
If you don’t pay attention to the port configuration dialogs (usually seen by invoking “make config”), chances are likely you choose wrong values or just go with the defaults, so you may end up with an APR without IPv6 support.

To check if your APR has IPv6 support enable, just invoke this command:

localhost:/# pkg_info apr*
Information for apr-gdbm-db42-1.3.3.1.3.4_1:

WWW: http://apr.apache.org/


The package name gives a clear statement if it supports IPv6 or not. If it does, it’ll read something like this:

apr-ipv6-gdbm-db42-1.3.3.1.3.4_1

If it does NOT, it’ll read something like this:

apr-gdbm-db42-1.3.3.1.3.4_1

So, if you insist in managing your port build options manually, make sure to always do a “make config WITH_IPV6=yes” first.
This is your best bet to catch all ports, as most of them support the WITH_IPV6 flag.

You’re better off however, if you add the flag to /etc/make.conf like this: