• nlnetlabs.nl :: DNSSEC HOWTO :: – "This HOWTO is intended for those people who want to deploy DNSSEC and are seeking a document that lives between a typical high level description of the topic (see the excellent Surfnet White Paper on DNSSEC for that (http://www.surfnet.nl/Documents/DNSSSEC-web.pdf ), the typical out of the box recipe, and an in depth description of the technology."

• Start page – collectd – The system statistics collection daemon – "collectd is a daemon which collects system performance statistics periodically and provides mechanisms to store the values in a variety of ways, for example in RRD files."
• crafterm's sprinkle at master – GitHub – "Sprinkle is a software provisioning tool you can use to build remote servers with. eg. to install a Rails, or Sinatra stack on a brand new slice directly after its been created."
• Sprinkle Some Powder! – Sprinkle is a provisioning automation tool.
• Cloudelay – Amazon CloudFront – In-browser table showing latency to various Amazon CloudFront locations.
• cloud exchange – Historical graphs of Amazon Web Services Elastic Compute Cloud Spot Instance pricing.
• VMware Communities: Using vscsiStats for Storage Performance Analysis – "vscsiStats collects and reports counters on storage activity. Its data is collected at the virtual SCSI device level in the kernel. This means that results are reported per VMDK (or RDM) irrespective of the underlying storage protocol."
• Meet Hudson – hudson – Hudson Wiki – "Hudson monitors executions of repeated jobs, such as building a software project or jobs run by cron."
• Chef – Opscode – "Chef is an open source systems integration framework built to bring the benefits of configuration mangement to your entire infrastructure. You write source code to describe how you want each part of your infrastructure to be built, then apply those descriptions to your servers. The result is a fully automated infrastructure: when a new server comes on line, the only thing you have to do is tell Chef what role it should play in your architecture."
• EC2BuildinganImage < Main < TWiki – Notes on building an Amazon EC2 image for Scientific Linux (or CentOS). Includes detailed instructions under "Make Customizations for running on EC2".
• namebench – Project Hosting on Google Code – "namebench runs a fair and thorough benchmark using your web browser history, tcpdump output, or standardized datasets in order to provide an individualized recommendation. namebench is completely free and does not modify your system in any way."
• Migrating a Linux S3 Based AMI to an EBS Based AMI | full360.com – "I put this article together to show migrating an existing Linux AMI to EBS can be a trivial task."
• Softies on Rails: The Absolute Moron's Guide to Capistrano – A gentle introduction to using Capistrano to deploy a Ruby on Rails app.

• Tame Electrical and Heating Costs with CPU Power Management » boche.net – VMware Virtualization Evangelist – Notes on "using vSphere’s Advanced CPU Power Management feature."
• Root Server Technical Operations Assn – Map of DNS Root Servers locations throughout the world.

Running a chrooted BIND server within a FreeBSD jail requires mounting its devfs outside of the jail; this document provides an RCng start stop script to do that.

Attempting to start BIND using the stock RCng script in a FreeBSD jail results in the following error:

> sudo /etc/rc.d/named start
mount_devfs: Operation not permitted
/etc/rc.d/named: WARNING: devfs_domount(): Unable to mount devfs on /var/named/dev
devfs rule: ioctl DEVFSIO_RAPPLY: Operation not permitted
devfs rule: ioctl DEVFSIO_RAPPLY: Operation not permitted
Starting named.

The reason for this is that you are unable to mount and manipulate the devfs for the chroot within the jail itself; it must be done in the parent of the jail. To do this at boot, the script below can be used.

#!/bin/sh

# PROVIDE: jailedchrootdevfs
# REQUIRE: rcconf mountcritremote
# BEFORE: jail
# KEYWORD: nojail

. /etc/rc.subr

name="jailed-chroot-devfs"
start_cmd='start'
stop_cmd=':'
#rc_debug=1

jailed_named_chrootdir='/u1/jail/192.168.1.234/var/named'
start()
{
umount ${jailed_named_chrootdir}/dev 2>/dev/null
devfs_domount ${jailed_named_chrootdir}/dev devfsrules_hide_all
devfs -m ${jailed_named_chrootdir}/dev rule apply path null unhide
devfs -m ${jailed_named_chrootdir}/dev rule apply path random unhide
}

load_rc_config $name
run_rc_command "$1"

Next, within the jail, edit /etc/rc.d/named to comment out the equivalent lines to those above, found within the chroot_autoupdate() function:

*** named Thu Feb 23 12:34:41 2006
--- ../../../../../etc/rc.d/named Thu Nov 3 00:12:06 2005
***************
*** 58,67 ****

# Mount a devfs in the chroot directory if needed
#
! #umount ${named_chrootdir}/dev 2>/dev/null
! #devfs_domount ${named_chrootdir}/dev devfsrules_hide_all
! #devfs -m ${named_chrootdir}/dev rule apply path null unhide
! #devfs -m ${named_chrootdir}/dev rule apply path random unhide

# Copy local timezone information if it is not up to date.
#
--- 58,67 ----

# Mount a devfs in the chroot directory if needed
#
! umount ${named_chrootdir}/dev 2>/dev/null
! devfs_domount ${named_chrootdir}/dev devfsrules_hide_all
! devfs -m ${named_chrootdir}/dev rule apply path null unhide
! devfs -m ${named_chrootdir}/dev rule apply path random unhide

# Copy local timezone information if it is not up to date.
#

Notes on the RCng script:

• Specifiying that the RCng script run BEFORE: jail ensures that the directory is mounted before the jail starts up, and starts its BIND process.
• The devfs commands in start() are adapted from the /etc/rc.d/namedscript.
• /etc/rc.subr contains the devfs_domount subroutine; load_rc_config $name is required to load the devfs variables it needs to work.

Other notes:

• You will need to set the security.jail.allow_raw_sockets sysctl to 1 to allow named to open a UDP socket.