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!

Now, I made up a similar script to do the same on OS X.

The basic idea, now and then, was that I would not want to send all traffic through the VPN.
Thus the script will assist in restoring your local default route after the VPN connection is established.
Furthermore, it’ll add some specific routes directed to the VPN.

This way, all your usual traffic (internet, surfing, skype, whatever) is sent through your default gateway, while more specific routes (your business stuff) is sent through the VPN.

Below’s the code for the initial release. It may lack some details yet, like auto-detecting the tunnel device name, but it does the job already.

Just copy the code into Apple Script Editor and save it to a convenient location. Make sure you save it as “Application” and not as “Script” (which is the default). You you don’t, double-clicking the script will open the Script Editor instead of executing the script. Surely, not what you want.

Pay attention to the variables on the top, which need to be edited before you save the Script: _vpn_name, _default_gw, _networks, and _sudo_password (optional).
I hope directions are clear enough from the comments sections.

# VpnInit
# ---
# an AppleScript utility to connect your vpn,
# restore local default route and add selected
# routes directed to the VPN only
# thus you'll end up sending only selected
# traffic through the VPN, while the rest
# goes through your local default gateway
# as usual
# ---
# released "as is" under the terms of GPL v2.
# Copyright © 2011 Gianpaolo Del Matto
# 
# r0.1 initial release 2011/12/29
#
# ToDo:
# - hardcoding the "sudo" password is a bad idea, maybe
#	need a better way to get away with it
# - vpn tunnel (utun0) is still hardcoded,
#	should be auto-detected
#

# the name of your vpn connection
#
set _vpn_name to "My VPN"

# your local default gateway
#
set _default_gw to "192.168.1.1"

# your remote networks to pass via VPN, separate multiple with comma
# like so: {"1.2.3.4/30", "5.6.7.8/30"}
#
set _networks to {"192.168.2.1/24"}

# your super-user (root) password
# actually needed to bypass the prompts
# leave empty to get prompted
#
set _sudo_password to ""

# ##################################################################
# DO NOT CHANGE ANYTHING BELOW
# ##################################################################

# kindly borrowed from
# http://www.macosxautomation.com/applescript/uiscripting/index.html
# make sure that support for assistive devices is enabled
#
tell application "System Events"
	if UI elements enabled is false then
		tell application "System Preferences"
			activate
			set current pane to pane id "com.apple.preference.universalaccess"
			display dialog "This script requires access for assistive devices be enabled." & return & return & "To continue, click the OK button and enter an administrative password in the forthcoming security dialog." with icon 1
		end tell
		set UI elements enabled to true
		if UI elements enabled is false then
			display dialog "This script cannot run while access for assistive devices is disabled." & return & "Exiting now." buttons {"OK"} with icon 2
			return "user cancelled"
		end if
	end if
end tell

# now dive into the VPN setup part
#
tell application "System Events"
	set _if_tunnel to "utun0" #	do not change, will be auto-detected, just giving a reasonable default
	tell current location of network preferences
		if exists service _vpn_name then
			# try to connect the VPN service if it's disconnected
			#
			if current configuration of service _vpn_name is not connected then
				connect service _vpn_name
			end if

			# give it some time to settle
			#
			set _retval to false
			repeat until (_retval) is true
				set counter to 0
				repeat while counter is less than 16
					# exit if we get connected
					#
					if current configuration of service _vpn_name is connected then
						set _retval to true
						exit repeat
					end if

					# opt for exit if still not connected after 15 seconds
					#
					if counter is equal to 15 then
						display dialog "VPN '" & _vpn_name & "' is still not connected after 15 seconds. Do you want to keep waiting?" with title "VPN still not connected" buttons {"Yes", "No"}
						if button returned of result is "No" then
							# bail out if user decided not to wait any longer
							#
							set _retval to true
							return
						else
							# otherwise reset the counter so we can trigger again
							#
							set counter to 0
						end if
					end if

					set counter to counter + 1
					delay 1
				end repeat
			end repeat

			# now go to post processing and to the following:
			# - delete default route via vpn
			# - restore original default route
			# - add specific routes to vpn
			#
			if current configuration of service _vpn_name is connected then
				# restore local default route
				#
				do shell script "route delete default" password _sudo_password with administrator privileges
				do shell script "route add default " & _default_gw password _sudo_password with administrator privileges

				# inject custom routes via VPN
				#
				repeat with _network in _networks
					do shell script "route add -interface " & _network & " utun0" password _sudo_password with administrator privileges
				end repeat
			end if
		else
			# bail out if the VPN service does not exist
			#
			display dialog "Given VPN '" & _vpn_name & "' does not exist. Please check the name"
		end if
	end tell
end tell

Now, if you want to know if they site you’re visiting is running IPv4 or IPv6, I’d recommend installing the “sixornot” Firefox plugin, which reveals this at a glance.

The plugin is available from Mozilla Add-ons page and adds a decent dropdown to the right of the address bar.

This will help you identify quickly which protocol the site is running. Klicking on the dropdown will reveal further information about the remote and local IP addresses.

After all, a very decent plugin without any bloat. Thanks to the author.

This is where CUPS-PDF kicks in. It adds a virtual printer to the system, thus enabling non-native applications to print to a PDF as well.

Mission accomplished!

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


gianpaolo-del-mattos-macbook-pro:trunk Gianpaolo$ svn update
svn: URL 'svn+ssh://...../webinterface/files/lib/webmin' of existing directory '...../webinterface/files/lib/Webmin' does not match expected URL 'svn+ssh://..../webinterface/files/lib/Webmin'


What had happened? Looking into the repository I found two folders, one by the name of ‘webmin’ and the other being ‘Webmin’.
Googl’ing for the error message I found references to SVN on Windows, having issues checking out folders by the same name onto a case-insensitive NTFS.

I though OS X would be case-sensitive, it’s basically UNIXish in it’s core, right? WRONG.
For historical reasons, OS X uses HFS+ with case-sensitivity disabled by default. Thus folders ‘webmin’ and ‘Webmin’ or even ‘webmiN’ are the same.

Test this on your own. Fire up a terminal and create a folder called ‘Test’.

mkdir Test

Now try to enter it using the name of ‘TESt’:

cd TESt

You’ll notice that it indeed works. HFS+ default settings are case-preserving, but nevertheless case-insensitive.

Solution? One possible work-around would be to REFORMAT the whole disk using HFS+ with case-sensitivity enabled, which would require a complete reinstall of OS X. There’s some issues with this, though. Various sources report, that some applications may not work properly on case-sensitive HFS+ volumes.

So, a more versatile, but albeit complicated, work-around would be to create virtual disk image and use this to store case-sensitive content.
For this you need to start “Disk Utility”. Although my screenshot is in german language, you should get the point easily.

1. Create a new disk image and give it some memorizable name (I used ‘CaseSensitive’ in the example) and store it in any folder you like
2. Give it some practical size depending on your need
3. Use HFS+ with journaling and case-sensitiveness as file system
4. Make sure you create this as a writable image

This will create a new disk image by the name of ‘CaseSensitive.dmg’. It should get mounted automatically. If not, just double-clicking should do so.

Now you can move all your content to the Disk Image. When it’s mounted, you can access it’s path through ‘/Volumes/CaseSensitive’ (the name in fact depending on the image name you chose earlier).

For me, this fixed the afore-mentioned SVN issue, as I could now properly checkout my repository and have the case-sensitive folders co-exist beneath each other.

Mission accomplished

I have these since years and made them ready for web-download in 2001 already.
Now I gathered them back from my archives to put them aside to download at phunsites.net.

Maybe, these are of use to others to.

Here’s a short overview of the bootdisks available:

• MS-DOS 6.22*
• MS-DOS 7.0 Beta (never released)**
• IBM PC-DOS 7.01*
• DR-DOS 7.03**
• Windows 95 4.00.950*
• Windows 95 4.00.1212*
• Windows 98 4.10.1998*
• Windows 95 SE 4.10.2222
• Windows ME 4.90

Additionally, there’s the following tools available:

• DOS/Windows Version of ‘dd’
• DOS/Windows CLI to overwrite floppy boot code; will allow to boot from HD even if the floppy is inserted
• DOS CD-ROM drivers for various drives

Maybe these can still be of value, despite floppy drives being gone and virtualization on the edge.

Disclaimer: I take no liability whatsoever damage could arise out of the use of these disk images.
These boot disks are provided “as is”. The copyright of the software contained on the boot disks retains to their respective copyright holder.

One possible approach would be to add some lines like these to fstab:

/dev/sda1       /mnt/sda1       ext3    defaults,noauto 0       0

This may be good enough in some cases, though it wasn’t sufficient for me, when there were dozens of device nodes which could get mounted eventually.

So I basically wanted something that would allow me to just access a directory, while the underlying disk was mounted automatically, then having it unmounted automatically if not in use, but still being dynamic in it’s nature so it would auto-adjust.

Now there’s a simple trick using an AutoFS feature called “executable maps”, which would allow me to achive this all.

The idea is, that all devices (let’s say /dev/sda1, /dev/sda2, /dev/sdb1, /dev/sdc1 as an example) will get mounted to /mnt/disks/[devicename].

First make sure, that AutoFS is installed. On Debian for example, it is installed like this:

apt-get install autofs

Then create a file called /etc/auto.disks with the following lines therein:

#!/bin/bash

# $1 is passed-over from automount
# key refers to the mount point we are looking for
key="$1"

# default mount options
opts="-fstype=ext3,rw"

# if a block device exists at /dev/[key]
# pass it back to automount
[ -b /dev/${key} ] && { echo "$opts \"; echo -e "t:/dev/${key}"; }

Don’t forget to chmod 755 /etc/auto.disks.

This script will create an automounter map dynamically as soon as it passed
a device node. It it finds it (e.g. while looking up /dev/sda1, which exists), it’ll
return the map to automount, which will cause the device node to be mounted.

In my case, the script didn’t need to be very sophisticated as I only have ext3-formatted disks, but it’s easy to script it for automatic file system recognition.

Btw, the script can be tested like this to see if it’s actually working:

satyr:~# bash /etc/auto.disks sda1
-fstype=ext3,rw
        :/dev/sda1
satyr:~# bash /etc/auto.disks sdx1

The first command returns the map for an existing device node /dev/sda1, while the second command returns nothing as /dev/sdx1 doesn’t exist on the system.

Now set AutoFS to use the executable map for /mnt/disks directory. Add this line to /etc/auto.master:

/mnt/disks  /etc/auto.disks --timeout=360

This will cause AutoFS to examine the executable map on all requested sub directories beneath /mnt/disks. So if you’re going to access /mnt/disks/sda1, /mnt/disks/sda2, /mnt/disks/sdb1, /mnt/disks/sdc1, the block devices corresponding to the directories are mounted automatically — as long as the devices exist of course.

The timeout value designates after how much time (of inactivity) an automounted file system expires and get’s unmounted.

This makes it very easy to change a particular boot image. It’s merely a matter of picking the right file, changing it and burning a new CD-ROM.

Now there are also CD-ROMs which do not rely upon a boot loader or images inside the iso9660 filesystem.
Instead, the bootable image is stored within the first sectors of the CD-ROM, referenced only from the boot catalog by it’s sector offset. This actually means, that the boot image is hidden and neither visible from the iso9660 filesystem nor loaded from there.

This drawing should get you the basic idea (have a look at the El Torito Specification for further Details):

               +-------------------------+
    Sector 0:  |          SYSTEM         |
               |-------------------------|
    Sector 16: |      Primary Volume     |
               |-------------------------|
    Sector 17: |    Boot Record Volume   |-------+
               |-------------------------|       |
               |                         |       |
               |-------------------------|       |
               | Set Termination Volume  |       |
               |-------------------------|       |
               |     Boot Catalog        | <-----+
               |                         |-------+
               |-------------------------|       |
               |  Bootable Disk/Loader   | <-----+
               |-------------------------|
               |   CD-ROM File System    |
               +-------------------------+

So to change the boot image, it needs to be extracted from the CD-ROM first.

This is where geteltorito comes in, a perl utility by Rainer Krienke, which serves exactly this purpose.

Luckily enough I found this one before I started writing an image dumper on my own…