FreeBSD

FreeBSD TiddlyWiki rc.d script

After manually starting a TiddlyWiki node.js server in a tmux environment for many years at each reboot of my system, I decided it was finally time to create a fancy rc.d for this. TiddlyWiki can be installed using npm install -g tiddlywiki.

The rc.d script

The script should be placed in /usr/local/etc/rc.d.

#!/bin/sh

# PROVIDE: tiddlywiki
# REQUIRE: LOGIN
# KEYWORD: shutdown

. /etc/rc.subr
load_rc_config $name

: ${tiddlywiki_enable:=no}
: ${tiddlywiki_user:="www"}
: ${tiddlywiki_group:="www"}
: ${tiddlywiki_port:="8080"}

name="tiddlywiki"
desc="TiddlyWiki server"
rcvar="tiddlywiki_enable"
command="/usr/local/bin/${name}"
procname="node"
pidfile="/var/run/${name}.pid"
command_args="${tiddlywiki_dir} --listen port=${tiddlywiki_port}"
start_precmd="tiddlywiki_precmd"
start_cmd="daemon -u ${tiddlywiki_user} -p ${pidfile} -f \
           ${command} ${command_args} ${tiddlywiki_flags}"

PATH="${PATH}:/usr/local/bin" # Otherwise node not found

tiddlywiki_precmd()
{
  if [ ! -d ${tiddlywiki_dir} ]; then
    info "TiddlyWiki dir does not exist. Creating one ..."
    if ! mkdir -p ${tiddlywiki_dir}; then
      err 1 "Failed to create TiddlyWiki dir."
    fi

    chown ${tiddlywiki_user}:${tiddlywiki_group} ${tiddlywiki_dir}
  fi

  if [ ! -f ${tiddlywiki_dir}/tiddlywiki.info ]; then
    info "No tiddlywiki.info found. Creating one ..."
    su -m ${tiddlywiki_user} -c "${command} ${tiddlywiki_dir} --init server"
  fi
}

run_rc_command "$1"

The procname variable is defined here, to aid the check_pidfile to find the correct process. If procname is not defined it defaults to command. To give an impression, this is how the process look like in the ps output:

OpenIKED based IPsec VPN tunnel on FreeBSD

This post will show how to set up an IPsec based VPN tunnel using OpenIKED. Road warrior clients will be placed within their own subnet of 10.0.5.0/24. Authentication between road warriors and the VPN server will be based on certificates. A word of advice for those attempting this journey; IPsec based VPNs with certificate based authentication is a messy endeavour. The first messy part is the Internet Key Exchange (IKE), both client and server have their own set of supported algorithms. During key negotiation a common ground needs to be found between client and server regarding cipher suites. Second messy part are the certificates, as a random guy on the internet, has so nicely phrased: public key infrastructure (PKI) and X.509 certificates are a wild, wild, west.

Assign T-mobile public IP to own server (FreeBSD)

With the recent (forced) transition from ADSL to fibre optic broadband internet, an interesting oppertunity arose. It enabled assigning the public ip address from the provider easily to a network interface of my private home server. The fibre optic cable entering our house is fed to a media converer which has a UTP connection. The default set-up from the installer attaches the media converter directly to the supplied T-Mobile router. For home networking enthousiasts it is also possible to connect the media converter directly to your home server. But why is this cool?! Here are two reasons:

Unbound as DNS Sinkhole

Inspired by the popular pi-hole project which sends advertisements and tracking scripts into oblivion, I decided to roll my own solution as an educational exercise. First place to look was at a DNS server, dnsmasq is a common choice for this kind of task, but I noticed that FreeBSD is shiped with the Unbound DNS server installed by default. As I like to keep my system as clean as possible, I decided to use this one. Below is the config file used for the unbound DNS server, the important lines are the local-zone: lines. This tells the server to return NXDOMAIN which stands for non-existent domain. Also frequently seen on the internet is to return 127.0.0.1 instead of NXDOMAIN, the downside of this solution is that the client will make an additional request to 127.0.0.1 to find the data it was looking for. Using the local-zone: approach also any subdomains are automatically blocked. Any non-blocked DNS queries are forwarded to upstream DNS servers in the forward-zone.