add blog to git

.gitignore

@@ -0,0 +1,5 @@
+dist
+*.html
+rss.xml
+list.tmpl
+blog/list.tmpl

Makefile

@@ -0,0 +1,73 @@
+HTGEN=./scripts/htgen
+MKLIST=./scripts/mklist
+RSSGEN=./scripts/rssgen
+BLOG=blog
+POSTS!=find ${BLOG} -type f -mindepth 2 -maxdepth 2 -name index.tmpl
+OS!=uname
+
+.if ${OS} == "Darwin"
+INSTALL=ginstall -Dp -m 0444
+LOCAL_TARGET=${HOME}/Public/www.c0ffee.net
+.else
+INSTALL=install -Dp -m 0444
+LOCAL_TARGET=/var/www/htdocs/www
+.endif
+
+HEAD=partials/head.tmpl
+RSYNC_TARGET=puffy:/var/www/htdocs/www
+DOMAIN=www.c0ffee.net
+BASEURL=https://${DOMAIN}
+RSS_TITLE="Cullum Smith's Blog"
+RSS_DESCRIPTION="Articles about BSD, privacy, self-hosting, and more."
+
+.PHONY: all clean tarball rsync local
+
+all: index.html resume/index.html ${BLOG}/index.html ${POSTS:S/.tmpl$/.html/g} rss.xml
+
+index.html: ${HEAD} index.tmpl list.tmpl partials/footer_openbsd.tmpl
+	${HTGEN} -o $@ ${HEAD} '@index.tmpl' list.tmpl partials/footer_openbsd.tmpl
+
+resume/index.html: ${HEAD} resume/index.tmpl partials/footer.tmpl
+	${HTGEN} -o $@ ${HEAD} '@resume/index.tmpl' partials/footer.tmpl
+
+${BLOG}/index.html: ${HEAD} ${BLOG}/index.tmpl ${BLOG}/list.tmpl partials/footer_blog.tmpl
+	${HTGEN} -o $@ ${HEAD} ${BLOG}/index.tmpl '@${BLOG}/list.tmpl' partials/footer_blog.tmpl
+
+list.tmpl: ${POSTS}
+	${MKLIST} -o $@ -n 5 ${BLOG}
+
+${BLOG}/list.tmpl: ${POST}
+	${MKLIST} -o $@ ${BLOG}
+
+.for POST in ${POSTS}
+${POST:S/.tmpl$/.html/g}: ${HEAD} partials/header_${BLOG}.tmpl ${POST} partials/footer_post.tmpl
+	${HTGEN} -o $@ ${HEAD} partials/header_${BLOG}.tmpl '@${POST}' partials/footer_post.tmpl
+.endfor
+
+rss.xml: ${POSTS}
+	${RSSGEN} -o $@ -b "${BASEURL}" -t ${RSS_TITLE} -d ${RSS_DESCRIPTION} ${BLOG}
+
+dist: all
+	mkdir -p dist
+	find . -type d -path ./dist -prune -o -type f -name '*.html' -print | sed 's|^\./||' | xargs -n1 -I{} ${INSTALL} {} dist/{}
+	${INSTALL} css/style.css dist/css/style.css
+	${INSTALL} favicon.png   dist/favicon.png
+	${INSTALL} robots.txt    dist/robots.txt
+	${INSTALL} rss.xml       dist/rss/index.rss
+	find files -type f -exec ${INSTALL} {} dist/{} \;
+	find img   -type f -exec ${INSTALL} {} dist/{} \;
+
+tarball: dist
+	tar cvzf ${DOMAIN}.tar.gz dist
+
+local: dist
+	rsync -rlpth dist/ ${LOCAL_TARGET}
+
+rsync: dist
+	rsync -rlpth dist/ ${RSYNC_TARGET}
+
+clean:
+	rm -f list.tmpl ${BLOG}/list.tmpl rss.xml
+	find . -name '*.html' -exec rm -f {} \;
+	rm -rf dist
+	rm -f ${DOMAIN}.tar.gz

blog/dns-hidden-master/index.tmpl

@@ -0,0 +1,406 @@
+TITLE='DNS Hosting Guide: Hidden Master with DNSSEC'
+DESCRIPTION='Manage your own DNS using BIND in a hidden master configuration.'
+DATE=2017-11-04
+__HTML__
+<p>DNS is one of the few things I don't like to host myself. A DNS server running on a single host
+will cause slow queries for far-away clients, making your site seem less responsive. In addition, a
+failed DNS lookup is a much more serious problem than a web service being down. If your mail server
+isn't responding, most other mail servers will queue all your incoming mail to be retried later. But if
+the DNS lookup for your MX record fails, they will usually reject the message altogether.
+
+<p>Because of these issues, I have always used third-party DNS providers. Most professional DNS services
+are inexpensive for personal use, resistant to DDOS attacks and downtime, and support low-latency queries
+from anywhere in the world using <a href="https://en.wikipedia.org/wiki/Anycast">anycast routing</a>.
+However, using a paid DNS provider usually forces you to manage all your domains and subdomains through
+a clunky web interface. Until now!
+
+<p>This guide describes how to run the <a href="https://www.isc.org/downloads/bind/">BIND DNS server</a>
+in a <em>hidden master</em> configuration. The idea is that you run BIND locally, where you can easily
+edit your plain text zone file or automate your domain configuration, but use a secondary, more resilient
+DNS provider for all the actual query resolution. Your local BIND server will act as the primary (or <em>master</em>)
+DNS server, and will automatically notify your secondary DNS servers when any changes are made. The trick is that
+when setting your primary nameservers in your domain's registrar, you only use the IP addresses of your secondary
+nameservers. This way, you can easily manage your zone file locally, but none of the actual query traffic goes
+to your box.
+
+<p>I use <a href="https://cp.dnsmadeeasy.com/u/122648">DNS Made Easy</a> for my secondary DNS service. Their small business
+plan is about $30 per year, and that gets you support for 10 domain names, 5 million queries per month, and DNSSEC.
+I've found it more than adequate for a personal site, but there are other options as well—<a href="https://dyn.com">Dyn</a>
+comes to mind (but recently acquired by Oracle...buyer beware).
+
+<section>
+  <h2 id="installing-bind">Installing BIND</h2>
+
+  <p>As always, this guide assumes you're running FreeBSD. The instructions should map pretty closely to your Linux
+  distro of choice—just install <span class="monospace">bind</span> from your package manager and modify the file paths
+  where appropriate.
+
+  <p><del>On FreeBSD, install <span class="monospace">bind99</span> from ports. There are more recent versions available, but in
+  my experience they all had bugs in their <span class="monospace">rc</span> scripts and weird runtime issues. 9.9 is
+  the extended support release, and it's the only one that I can confirm works 100% on FreeBSD 11. Use other versions
+  at your own risk.</del>
+
+  <p><em><strong>EDIT (26 Nov 2017): These issues were actually caused by a problematic loader.conf optimization I had configured.</strong>
+  You can use BIND 9.11 without issue. Just make sure the <span class="monospace">net.inet.tcp.soreceive_stream</span> tunable is set to 0.
+  See <a href="https://forums.freebsd.org/threads/61064/">this forum post</a> for more information.</em>
+
+<pre>cd /usr/ports/dns/bind911
+make install clean</pre>
+
+  <p>I always make sure to build with the IPV6- and DNSSEC-related options. Then, enable <span class="monospace">bind</span>
+  to start on boot (the daemon is called <span class="monospace">named</span>):
+
+<pre><div class="code-title">/etc/rc.conf</div>named_enable="YES"</pre>
+
+  <p>Now you are ready to edit the configuration file. The annotated example below assumes you are hosting a domain
+  called <span class="monospace">example.com</span>. Most of the IP addresses in the example are fake. You will need
+  to substitute your own domain and relevant IP addresses where appropriate. Your secondary DNS provider should
+  provide you with the IP addresses for the zone transfers, as well as those of your public nameservers.
+
+<pre><div class="code-title">/usr/local/etc/namedb/named.conf</div><span class="code-comment">// IP addresses of your secondary nameservers, where the zone transfers will</span>
+<span class="code-comment">// take place. Your DNS provider should give you these addresses.</span>
+<span class="code-comment">// NOTE - these IPs are probably not the same as your DNS provider's public</span>
+<span class="code-comment">// nameservers (which will go in your zone file's ns1-3 A records).</span>
+masters secondaries {
+  198.51.100.51;
+  198.51.100.52;
+  198.51.100.53;
+};
+
+<span class="code-comment">// same as above - repetition needed for BIND's arcane config syntax</span>
+acl secondaries {
+  198.51.100.51;
+  198.51.100.52;
+  198.51.100.53;
+};
+
+<span class="code-comment">// localhost, and any other public IPs of your server</span>
+acl localnetworks {
+  127.0.0.1;
+  ::1;
+  203.0.113.41;
+  203.0.113.42;
+  2001:db8::2;
+  2001:db8::3;
+};
+
+options {
+  directory       "/usr/local/etc/namedb/working";
+  pid-file        "/var/run/named/pid";
+  dump-file       "/var/dump/named_dump.db";
+  statistics-file "/var/stats/named.stats";
+  key-directory   "/usr/local/etc/namedb/keys";
+
+  <span class="code-comment">// listen on all interfaces (needed for zone transfers to secondaries)</span>
+  listen-on    { any; };
+  listen-on-v6 { any; };
+
+  <span class="code-comment">// IP addresses of your upstream DNS servers. Your hosting provider most</span>
+  <span class="code-comment">// likely provides a DNS server. Alternatively, leave blank to have BIND</span>
+  <span class="code-comment">// recursively resolve all queries (slow).</span>
+  <span class="code-comment">//</span>
+  <span class="code-comment">// Note - below are Google's DNS servers. If you value your privacy, don't</span>
+  <span class="code-comment">// use them.</span>
+  forwarders {
+    8.8.8.8;
+    8.8.4.4;
+    2001:4860:4860::8888;
+    2001:4860:4860::8844;
+  };
+
+  <span class="code-comment">// If a lookup fails on upstream DNS servers, don't try to recursively</span>
+  <span class="code-comment">// resolve (comment out if not using forwarders).</span>
+  forward only;
+
+  <span class="code-comment">// When a zone is updated, only send NOTIFY to hosts in the zone's</span>
+  <span class="code-comment">// `also-notify` block (defined below).</span>
+  notify explicit;
+
+  <span class="code-comment">// Set safe default permissions. We will override these for some zones</span>
+  <span class="code-comment">// below.</span>
+  allow-transfer  { none; };
+  allow-update    { none; };
+  allow-recursion { localnetworks; };
+  allow-query     { localnetworks; };
+
+  <span class="code-comment">// If your server has multiple IP addresses, uncomment the two lines below</span>
+  <span class="code-comment">// and change the source address to the one you configured your secondary</span>
+  <span class="code-comment">// DNS provider to use.</span>
+  <span class="code-comment">//  query-source address 203.0.113.41;</span>
+  <span class="code-comment">//  notify-source        203.0.113.41;</span>
+
+  <span class="code-comment">// Comment out the three lines below if you don't want DNSSEC.</span>
+  dnssec-enable yes;
+  dnssec-validation auto;
+  dnssec-lookaside auto;
+};
+
+<span class="code-comment">// Don't attempt to resolve any private IPs</span>
+include "/usr/local/etc/namedb/localzones.conf";
+
+<span class="code-comment">// Your domain name goes here.</span>
+zone "example.com" in {
+  <span class="code-comment">// We are the "master" (or primary) server for our domain, but it just</span>
+  <span class="code-comment">// happens that we won't be getting any external queries.</span>
+  type master;
+
+  <span class="code-comment">// Comment out the two lines below if you don't want DNSSEC.</span>
+  auto-dnssec maintain;
+  inline-signing yes;
+
+  <span class="code-comment">// only allow zone transfers from localhost or our secondary DNS provider</span>
+  allow-transfer {
+    localnetworks;
+    secondaries;
+  };
+
+  <span class="code-comment">// only allow DNS queries from localhost or our secondary DNS provider</span>
+  allow-query {
+    localnetworks;
+    secondaries;
+  };
+
+  <span class="code-comment">// send NOTIFY messages to secondary DNS provider when the zone changes</span>
+  also-notify {
+    secondaries;
+  };
+
+  <span class="code-comment">// your domain's zone file goes here</span>
+  file "/usr/local/etc/namedb/master/example.com.db";
+};</pre>
+
+  <p>Now you need to write a zone file for your domain—this file contains the actual DNS records.
+
+  <section>
+    <h3 id="dnssec">Optional: Configuring DNSSEC</h3>
+
+    <p>If you want to configure DNSSEC for your domain, you'll need to generate some keys. Make sure your secondary
+    DNS provider supports DNSSEC first (<a href="https://support.dnsmadeeasy.com/index.php?/Knowledgebase/Article/View/172/18/do-you-support-dnssec">I know that DNS Made Easy does</a>).
+    I use the ECDSA algorithm when generating keys, since they are smaller and more computationally efficient.
+    However, if you're concerned about maximum compatibility with other DNS resolvers, you probably want to stick with
+    RSA—just replace <span class="monospace">ECDSAP256SHA256</span> with <span class="monospace">RSASHA256</span> below.
+    ECDSA is <a href="https://www.cloudflare.com/dns/dnssec/ecdsa-and-dnssec/">good enough for Cloudflare</a> though, so
+    I'm sticking with it for this example.
+
+    <p>First, generate a Zone Signing Key (ZSK) for your domain by running the following:
+
+<pre>dnssec-keygen -a ECDSAP256SHA256 -K /usr/local/etc/namedb/keys -n ZONE example.com
+<span class="code-comment">Generating key pair.</span>
+<span class="code-comment">Kexample.com.+013+29679</span></pre>
+
+    <p>This will generate a keypair for the <span class="monospace">example.com</span> in BIND's key directory. 
+    Next, generate a Key Signing Key (KSK) for the domain in a similar fashion:
+
+<pre>dnssec-keygen -f KSK -a ECDSAP256SHA256 -K /usr/local/etc/namedb/keys -n ZONE example.com
+<span class="code-comment">Generating key pair.</span>
+<span class="code-comment">Kexample.com.+013+15315</span> </pre>
+
+    <p>Take note of the KSK's generated filename—you'll need it in a bit. You should now have 4 files for this domain
+    in BIND's key directory: one pair for the ZSK, and another pair for the KSK. We will come back to these at the end of
+    the guide when you configure DNS settings at your registrar.
+
+  </section>
+
+</section>
+
+<section>
+  <h2 id="zone-file">Writing a Zone File</h2>
+
+  <p>Now we come to the fun part: writing your zone file! This is a plain text file where you'll specify all the DNS records
+  for your domain. The below example uses fake IP addresses for a domain named <span class="monospace">example.com</span>. I've
+  included some commentary to help you out, but basically you'll just be translating the existing records you configured in your original
+  DNS provider's web portal.
+
+<pre><div class="code-title">/usr/local/etc/namedb/master/example.com.db</div><span class="code-comment">; The $TTL variable defines a default TTL for all records in this file.</span>
+<span class="code-comment">; This value specifies how long other DNS servers should keep a record in</span>
+<span class="code-comment">; their cache. Individual records may override this value.</span>
+$TTL 3h
+
+<span class="code-comment">; your bare domain name</span>
+$ORIGIN example.com.
+
+<span class="code-comment">; "Start of Authority" record. First line should contain your  primary</span>
+<span class="code-comment">; nameserver and administrative contact's email (replace '@' with '.')</span>
+@  IN  SOA  ns1.example.com.  root.example.com. (
+
+<span class="code-comment">; serial:   you *must* increment this number whenever any change is made</span>
+<span class="code-comment">;           to this file, otherwise updates will not propagate to your</span>
+<span class="code-comment">;           secondary DNS servers</span>
+2017101800
+<span class="code-comment">; refresh:  how often your secondary DNS servers should poll your primary</span>
+<span class="code-comment">;           server for changes</span>
+1d
+<span class="code-comment">; retry:    how long your secondary DNS servers should wait before</span>
+<span class="code-comment">;           retrying after a failed update</span>
+3m
+<span class="code-comment">; expire:   how long your secondary DNS servers should be considered</span>
+<span class="code-comment">;           authoritative if your primary nameserver disappears</span>
+1w
+<span class="code-comment">; minimum:  "negative caching TTL," or how long other servers should wait</span>
+<span class="code-comment">;           before re-querying a record that didn't exist on the previous</span>
+<span class="code-comment">;           attempt</span>
+3h
+)
+
+<span class="code-comment">; Your domain's public nameservers go in the NS records here. You'll need</span>
+<span class="code-comment">; an A record for each one that points to your secondary DNS provider.</span>
+IN  NS     ns1.example.com.
+IN  NS     ns2.example.com.
+IN  NS     ns3.example.com.
+
+<span class="code-comment">; MX record (if you have a mail server)</span>
+IN  MX  10 mail.example.com.
+
+<span class="code-comment">; server host definitions</span>
+@           IN  A      203.0.113.41
+@           IN  AAAA   2001:db8::2
+mail        IN  A      203.0.113.42
+mail        IN  AAAA   2001:db8::3
+awesomebox  IN  A      203.0.113.43
+awesomebox  IN  AAAA   2001:db8::4
+
+<span class="code-comment">; These records should contain the IP addresses of your secondary DNS</span>
+<span class="code-comment">; provider's PUBLIC nameservers. Clients will use these DNS servers when</span>
+<span class="code-comment">; querying your domain.</span>
+ns1         IN  A      198.51.100.11
+ns1         IN  AAAA   2001:db8:beef::7
+ns2         IN  A      198.51.100.12
+ns2         IN  AAAA   2001:db8:beef::8
+ns3         IN  A      198.51.100.13
+ns3         IN  AAAA   2001:db8:beef::9</pre>
+</section>
+
+<section>
+  <h2 id="zone-transfer">Configuring Zone Transfers</h2>
+
+  <p>At this point, we're done configuring BIND. The next step is to ensure your secondary DNS provider can connect
+  to your server to perform zone transfers. You'll need to configure your server as the primary DNS server in your
+  secondary DNS provider's web portal. With <a href="https://cp.dnsmadeeasy.com/u/122648">DNS Made Easy</a>, this page is found in the <em>Advanced</em> menu under
+  <em>Secondary IP Sets</em>. Specify your server's public IP address here.
+
+  <p>If you have a firewall in place, you'll need to allow TCP and UDP traffic over port 53. If you used my <a href="https://www.c0ffee.net/blog/freebsd-server-guide#pf">FreeBSD Server Guide</a>
+  to configure the PF firewall, you can just add <span class="monospace">domain</span> to the <span class="monospace">inbound_tcp_services</span>
+  and <span class="monospace">inbound_udp_services</span> variables. Be sure to reload PF's ruleset:
+
+<pre>pfctl -f /etc/pf.conf</pre>
+
+  <p>Now, the moment of truth. It's time to start BIND and test your new DNS server!
+
+<pre>service named start</pre>
+
+  <p>Check <span class="monospace">/var/log/messages</span> to ensure BIND started up properly. Hopefully you didn't make any typos.
+  You can verify BIND is working by doing a simple DNS query:
+
+<pre>dig @127.0.0.1 +short google.com
+<span class="code-comment">172.217.5.206</span></pre>
+
+  <p>Also, make sure BIND is correctly serving the domain you configured in your zone file:
+
+<pre>dig @127.0.0.1 +short example.com
+<span class="code-comment">203.0.113.41</span></pre>
+
+  <p>Now, head to your secondary DNS provider's web portal. When BIND started up, it should have read your zone file and sent a
+  <span class="monospace">NOTIFY</span> to your secondary DNS servers, informing them to do a zone transfer from your hidden master.
+  If that happened successfully, your provider's web portal should show the DNS servers as in sync, with the current serial numbers
+  matching.
+
+  <p>If that didn't happen, or you see a problem, increment the serial number in your zone file and give BIND a reload:
+
+<pre>service named reload</pre>
+
+  <p>This should re-read your zone file and update your secondary servers. Check for any suspicious messages in your log files.
+
+  <p>Once you have zone transfers working, and your primary and secondary nameservers are in sync, you're ready to officially
+  change your public nameservers at your domain's registrar.
+
+</section>
+
+<section>
+  <h2 id="notifying-registrar">Notifying Your Registrar</h2>
+
+  <p>Your registrar has the secret sauce that tells other DNS servers which nameservers to query for information
+  about your domain. Once you've verified everything is working, you can switch your nameservers over to your secondary
+  DNS provider. You probably want to do this late at night, or during a time when you don't expect much traffic to your
+  site. I use <a href="https://www.namecheap.com/?aff=108349">Namecheap</a>, but the instructions should carry over to
+  most other registrars.
+
+  <p>In your registrar's web portal, your domain's settings page should have an option to set your nameservers. At <a href="https://www.namecheap.com/?aff=108349">Namecheap</a>,
+  you want to select <em>Custom DNS</em>. You will then need to provide the fully qualified domain name of your secondary
+  DNS provider's <em>public</em> DNS servers. As <a href="https://cp.dnsmadeeasy.com/u/122648">DNS Made Easy</a> states at the top of their portal: <em>These are the name servers that you will want to add as NS records in your zone and also assign to your domain at your domain registrar.</em>
+
+  <section>
+    <h3>Side Note: Vanity Nameservers</h3>
+    <p>If you'd like your public nameservers for <span class="monospace">example.com</span> to look like <span class="monospace">ns1.example.com</span>
+    instead of <span class="monospace">ns1.yourdnsprovider.com</span>, then you can configure "vanity nameservers" for your domain.
+    First, make sure you have A records (and probably AAAA records) for your secondary DNS provider's public name servers in your zone file (I emphasized this in
+    the example zone file above).
+
+    <p>I can't speak for other registrars, but at <a href="https://www.namecheap.com/?aff=108349">Namecheap</a>, you can go to the <em>Advanced DNS</em> page for your domain and
+    scroll down to <em>Personal DNS Server</em>. Then you can add <span class="monospace">ns1</span>, <span class="monospace">ns2</span>...
+    and map them to the IP addresses of your secondary DNS provider's public nameservers.
+
+    <p>Then, in the <em>Custom DNS</em> field, you can just put <span class="monospace">ns1.example.com</span>, <span class="monospace">ns2.example.com</span>, etc.
+
+    <p>Doing this creates a "glue record" at your registrar for your domain's DNS servers. You can Google this if you're interested in
+    the details. Also, the web interface at <a href="https://www.namecheap.com/?aff=108349">Namecheap</a> currently only allows IPv4 glue records. I had to open a support ticket to
+    have IPv6 glue records added for <a href="https://cp.dnsmadeeasy.com/u/122648">DNS Made Easy</a>'s public IPv6 servers.
+  </section>
+
+  <section>
+    <h3>Optional: DNSSEC at the Registrar</h3>
+
+    <p>If you configured DNSSEC above, there is one last step to complete while you're on your registrar's web portal. You'll
+    need to provide the SHA-1 and SHA-256 digests of the KSK you generated to your registrar. Your registrar will then add some
+    fancy records for you so that other resolvers can cryptographically verify your DNS records. (Sorry for the hand-wavy
+    explanation—it's 1:00 AM on a Friday night and I'm tired.)
+
+    <p>Remember the filename I asked you to remember from the <span class="monospace">dnssec-keygen</span> command above? We'll
+    use it now. You want the file containing the Key Signing Key (<strong>not</strong> the Zone Signing Key). It's annoying, because the filenames
+    look exactly the same except for a four-digit identifier at the end. It's easy to figure out though—the contents of the
+    <span class="monospace">.key</span> file will tell you which one it is.
+
+    <p>Once you've found the correct file, run the following command:
+
+<pre>dnssec-dsfromkey /usr/local/etc/namedb/keys/Kexample.com.+013+15315.key | awk '{print $4, $5, $6, $7}'
+<span class="code-comment">15315 13 1 7F5ED13547D9860965437D0F7CB6BFA7C70F1F62</span>
+<span class="code-comment">15315 13 2 AD0C012F749F0422E0CC88D11B65248E78945F149572D54C8AE7C5B63C30E621</span></pre>
+
+<p>You will use this output to populate the DS records for your domain at your registrar. At <a href="https://www.namecheap.com/?aff=108349">Namecheap</a>, this is located
+    under <em>Advanced DNS</em>→<em>DNSSEC</em>. The first column is the key tag, which corresponds to the key's file name.
+    The second column is the encryption type. If you used ECDSA, this will be <strong>13</strong>.  If you went with RSA, you'll use <strong>8</strong> here.
+    The third column is the digest type: <strong>1</strong> for SHA-1 and <strong>2</strong> for SHA-256. The final column contains the actual digest.
+
+    <p>These columns correspond to the four fields for DS records in the <a href="https://www.namecheap.com/?aff=108349">Namecheap</a> web portal. Copy and paste the appropriate values
+    there. Other registrars should have a similar process.
+
+    <p>It will take an hour or so for your DNS updates to propagate. You can verify DNSSEC is working by by querying a different
+    DNS server (the below example uses Google's public DNS).
+
+<pre>dig @8.8.8.8 example.com +dnssec | grep -m1 flags:
+<span class="code-comment">;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1</span></pre>
+
+    <p>If you see the <span class="monospace">ad</span> flag, then your DNSSEC was validated successfully. You can also check
+    your DNSSEC status on <a href="https://dnssec-debugger.verisignlabs.com">Verisign's test page</a>.
+  </section>
+
+</section>
+
+<section>
+  <h2 id="conclusion">Conclusion</h2>
+
+  <p>Once you've gotten all this working, you might consider setting the default nameserver on your server to your local BIND
+  instance. In addition to using no network overhead, you'll also take advantage of BIND's default query cache. All it takes
+  is a simple edit to your <span class="monospace">resolv.conf</span>:
+
+<pre><div class="code-title">/etc/resolv.conf</div>nameserver 127.0.0.1
+nameserver ::1</pre>
+
+  <p>If you perform DNS updates frequently, I think you'll find the hidden master setup an invaluable productivity boost for any
+  domains you control. Remember: to update your zone, just make the necessary record changes in your zone file, increment the serial,
+  and issue a <span class="monospace">service named reload</span>.
+
+  <p>As always, contact me via <a href="mailto:cullum@c0ffee.net">email</a> or ping me on <a href="https://twitter.com/cullumsmith">Twitter</a>
+  with any questions or issues you have.
+
+</section>
+

blog/dovecot-push-notifications/index.tmpl

@@ -0,0 +1,197 @@
+TITLE='Dovecot Push Notifications for iOS'
+DESCRIPTION='Native Apple push notifications for your self-hosted mail server.'
+DATE=2017-09-20
+__HTML__
+<p><strong>EDIT:</strong> <em>Apple has <a href=https://support.apple.com/en-us/HT208312">recently announced</a> that they
+are dropping mail suport from macOS Server Fall 2018. Once your APNS certificate expires after one year, the push notifications
+will stop working, and it seems like we won't be able to get new certificates from the Server app. Due to this news, I've stopped
+maintaining the patchset, since it's a fair amount of manual work to update it for each Dovecot release. Feel free
+to read on if you're interested in how this cool trick works though!</em>
+
+<p>Using a patched version of Dovecot and a small Perl script, it's possible to get native
+Apple push notifications for new mail using the stock iOS mail client. This is accomplished
+by mimicking Apple's <span class="monospace">XAPPLEPUSHSERVICE</span> IMAP extension for Dovecot
+used in macOS Server, whose source code is published on the
+<a href="https://opensource.apple.com/source/dovecot/dovecot-293/">Apple Open Source website</a>.
+
+<p>If you're running Dovecot on FreeBSD, this guide will be extremely easy: you can just use
+my patched Dovecot port <a href="https://github.com/cullum/freebsd-ports/tree/master/mail/dovecot">here</a>.
+It should work just as well on other Unix-like operating systems with a bit of manual work.
+
+<section>
+  <h2 id="acknowledgements">Acknowledgements</h2>
+
+  <p>All the credit for this goes to <a href="https://github.com/matthewpowell">Matthew Powell</a>
+  on GitHub. He wrote the <a href="https://github.com/matthewpowell/pushnotify">Dovecot patch and notification daemon</a>
+  to get push notifications working. I just packaged everything into nice FreeBSD ports.
+
+  <p>Much of this knowledge was discovered a few years ago by <a href="https://github.com/st3fan">Stefan Arentz</a>
+  in his <span class="monospace"><a href="https://github.com/st3fan/dovecot-xaps-plugin">dovecot-xaps-plugin</a></span>
+  project.
+
+</section>
+
+<section>
+  <h2 id="requirements">What You'll Need</h2>
+
+  <ul class="paragraph-list">
+    <li><strong>macOS Server:</strong> you will need access to an Apple device running macOS,
+      and a copy of <a href="https://www.apple.com/macos/server/">macOS Server</a>. You can
+      <a href="https://itunes.apple.com/us/app/macos-server/id883878097?mt=12">download macOS Server from the Mac App Store</a>
+      for $19.99. The macOS Server app is the only way to get the magic APNS certificates from
+      Apple that can send push notifications to the Mail app on your iPhone. Basically, we are
+      fooling your iPhone into thinking your Dovecot instance is actually running on a blessed
+      Mac server. Enable the <em>Push Notifications</em> option in the Server app to have Apple provision
+      the necessary certificates to your macOS Keychain.
+
+    <li><strong>A working Dovecot installation:</strong> you should have Dovecot installed and
+      working before trying to add push notifications into the mix. I recommend using
+      <a href="/blog/mail-server-guide/">my mail server guide</a>.
+  </ul>
+
+</section>
+
+<section>
+  <h2 id="installation">Installation</h2>
+
+  <p>The setup has two components: (1) a patched Dovecot installation to handle the APNS token
+  negotiation over IMAP, and (2) a small Perl daemon which sends notifications to Apple's push
+  servers whenever Dovecot receives a new message in a user's inbox.
+
+  <p>On FreeBSD, you can install both of these components by building my <span class="monospace"><a href="https://github.com/cullum/freebsd-ports/tree/master/mail/dovecot">mail/dovecot</a></span>
+  port with the <span class="monospace">APNS</span> option. This should automatically pull in
+  my <span class="monospace"><a href="https://github.com/cullum/freebsd-ports/tree/master/mail/dovecot-apns-daemon">mail/dovecot-apns-daemon</a></span> port as a dependency:
+
+<pre># clone my custom ports repo
+git clone https://github.com/cullum/freebsd-ports /usr/local/custom-ports
+
+# symlink my custom ports into your ports tree
+# (I need to find a cleaner way to do this)
+rm -rf /usr/ports/mail/dovecot
+ln -s /usr/local/custom-ports/devel/p5-Privileges-Drop   /usr/ports/devel/p5-Privileges-Drop
+ln -s /usr/local/custom-ports/net/p5-Net-APNS-Persistent /usr/ports/net/p5-Net-APNS-Persistent
+ln -s /usr/local/custom-ports/mail/dovecot-apns-daemon   /usr/ports/mail/dovecot-apns-daemon
+ln -s /usr/local/custom-ports/mail/dovecot               /usr/ports/mail/dovecot
+
+# build the patched dovecot
+cd /usr/ports/mail/dovecot
+make config  # ensure the APNS option is selected
+make reinstall clean</pre>
+
+  <p>The <span class="monospace">pkg-message</span> tells you how to export the magic APNS certificates
+  from your macOS Keychain to your FreeBSD server:
+
+<pre>Apple Push Notifications require a valid certificate keypair from
+a working copy of OS X Server. Export the following APNS certificate
+from your OS X keychain:
+
+APSP:com.apple.servermgrd.apns.mail 
+
+By default, the dovecot_apns daemon will look in the following
+locations for the certificate key pair:
+
+/usr/local/etc/dovecot-apns/mail.crt
+/usr/local/etc/dovecot-apns/mail.key
+
+If you exported a .p12 file from your OS X keychain, you can
+convert it to the proper PEM format with the following commands:
+
+openssl pkcs12 -in push.p12 -clcerts -nokeys | sed '/BEGIN CERTIFICATE/,$!d' &gt; mail.crt
+openssl pkcs12 -in push.p12 -nodes -nocerts | sed '/BEGIN RSA PRIVATE KEY/,$!d' &gt; mail.key
+
+The dovecot_apns daemon must be running for device registration and
+push notifications to work. Enable it in /etc/rc.conf:
+
+echo 'dovecot_apns_enable="YES"' &gt;&gt; /etc/rc.conf
+</pre>
+
+  <p>As well as how to configure Dovecot:
+
+<pre>Set the following variable somewhere in your Dovecot configuration:
+
+aps_topic = com.apple.mail.XServer.XXXXXXXXX
+
+replacing the X's to match the UID field in your APNS certificate.</pre>
+
+  <p>If you exported your mail push certificate as <span class="monospace">push.p12</span>, you
+  can get your <span class="monospace">aps_topic</span> value with the following command:
+
+<pre>openssl pkcs12 -in push.p12 -clcerts -nokeys -nomacver | grep -o 'com\.apple\.mail\.XServer\..*' | awk -F/ '{print $1}'</pre>
+
+  <p>I have mine configured like this:
+
+<pre><div class="code-title">/usr/local/etc/dovecot/conf.d/90-apns.conf</div>aps_topic = com.apple.mail.XServer.xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx</pre>
+
+  <p>Once you have your patched Dovecot installed, your APNS certificates in place, and your
+  Dovecot configuration updated, give the daemons a kick:
+
+<pre>service dovecot restart
+service dovecot_apns start</pre>
+
+  <p>Dovecot and the APNS daemon will both log to <span class="monospace">/var/log/maillog</span>.
+  Toggle Airplane Mode on your iPhone to force the IMAP connection to reset. You should see the
+  token negotiation logged in your mail log. On your iPhone, your mail account's fetch schedule
+  should automatically change to <em>push</em> in Settings → Accounts &#38; Passwords → Fetch New Data.
+
+  <p>Enjoy the battery savings and instant email notifications! I'll do my best to keep my Dovecot port
+  on GitHub in sync with whatever version is in the official FreeBSD ports tree, though updates may
+  not be instantaneous.
+
+  <section>
+    <h3>If You're Not Using FreeBSD</h3>
+
+    <p>If you're using Linux or something other than FreeBSD, you should still be able to get
+    this working. You'll just need to apply <a href="https://raw.githubusercontent.com/cullum/freebsd-ports/master/mail/dovecot/files/apns-2.2.32.patch">the Dovecot patch</a>
+    (currently valid for Dovecot 2.2.32) before building Dovecot from source. You'll also need
+    to install the Perl dependencies for the <span class="monospace">pushnotify.pl</span> script
+    using CPAN or your distribution's package manager. Finally, patch <span class="monospace">pushnotify.pl</span>
+    using <a href="https://raw.githubusercontent.com/cullum/freebsd-ports/master/mail/dovecot-apns-daemon/files/patch-pushnotify_pushnotify.pl">my patch</a>
+    and run it as a systemd unit file or <span class="monospace">tmux</span> session or something.
+    
+    <p>Or, just follow the instructions on <a href="https://github.com/matthewpowell/pushnotify">the original repo</a>,
+    it's probably easier. 😃
+
+  </section>
+
+</section>
+
+<section>
+  <h2 id="how-it-works">But How Does It Work?</h2>
+
+  <p>When your iPhone connects to an IMAP server, it checks for <span class="monospace">XAPPLEPUSHSERVICE</span>
+  in the server's <span class="monospace">CAPABILITY</span> list. If this special string is found, the iOS Mail
+  app assumes that it has connected to a macOS Server, which should support a custom song-and-dance
+  of IMAP commands to register for push notifications.
+
+  <p>In our case, we have simply patched Dovecot in a similar fashion to Apple's macOS Server. When
+  your iPhone sees the <span class="monospace">XAPPLEPUSHSERVICE</span> capability, it sends a
+  special command to register its device token for push notifications. Our patched Dovecot intercepts
+  this token and hands it off to our Perl APNS daemon over a local UNIX socket (<span class="monospace">/var/run/dovecot/apns</span>).
+  The APNS daemon stores a map of email accounts to APNS tokens in a flat file database, which you
+  can view at <span class="monospace">/var/db/dovecot-apns/devices</span>.
+
+  <p>When an email account receives a new message in its inbox, our patched Dovecot sends another message
+  over the APNS daemon's UNIX socket. The daemon looks up the email account's associated APNS token.
+  It then uses the <em>mail.XServer</em> keypair you exported from your macOS keychain to sign a
+  notification message, which it sends to Apple's push notification server. Your phone then receives a push
+  notification regarding the new email over a persistent, highly optimized connection to iCloud.
+
+  <p>As far as I can tell, buying macOS Server is the only way to get the necessary <em>mail.XServer</em>
+  certificate to send push notifications to the stock iOS Mail app. Other companies that advertise native
+  iOS push email (<a href="https://blog.fastmail.com/2015/07/17/push-email-now-available-in-ios-mail/">such as Fastmail</a>)
+  probably have a working relationship with Apple, which allows them to get more permanent APNS
+  certificates—the ones provisioned to macOS Server expire after one year and must be re-exported.
+
+</section>
+
+<section>
+  <h2 id="conclusion">Conclusion</h2>
+
+  <p>I can't guarantee how robust this setup is for "production" use, but it works great for my family's
+  email server. I do usually have to restart the APNS daemon whenever I restart Dovecot. Also, remember
+  your APNS certificate will need to be renewed after one year.
+  
+  <p>If you decide to try it out, <a href="https://twitter.com/cullumsmith">contact me on Twitter</a>
+  and let me know of any issues you have.
+</section>
+

blog/freebsd-full-disk-encryption-uefi/index.tmpl

@@ -0,0 +1,158 @@
+TITLE='FreeBSD: Full-Disk Encryption + UEFI'
+DESCRIPTION='How to install FreeBSD using a GELI-encrypted UFS root partition on UEFI.'
+DATE=2017-12-14
+__HTML__
+<p>After the almost comical stream of OS X security bugs recently, I dug up my old ThinkPad T530 and installed FreeBSD as my
+primary OS. Since a laptop is portable and easily stolen, full-disk encryption is a must. There are plenty of resources
+online for setting up an encrypted ZFS root partition on FreeBSD, but I still prefer UFS on desktop setups. Don't get
+me wrong—ZFS is my top choice for any kind of RAID situation—but I've always found it a bit overkill (and RAM intensive)
+for a single-disk OS partition. And I definitely wanted UEFI for that native resolution console at boot time. :-)
+
+<p>There were hardly any guides online for installing FreeBSD to a GELI-encrypted UFS partition, and there was even
+<em>less</em> information about how to get such a setup working with UEFI. However, I eventually figured it out,
+so here's a quick how-to in case another discerning daemon finds his way here.
+
+<section>
+  <h2 id="bios">Configuring Your BIOS</h2>
+
+  <p>I'm not sure if "BIOS" is the right word anymore, but you know what I mean. Reboot your computer and spam the
+  F2 or Delete key or whatever magic incantation you need in order to get to your BIOS settings. You'll definitely
+  need to disable Secure Boot, since <a href="https://wiki.freebsd.org/SecureBoot">it doesn't work yet</a> (and why
+  would you want it, anyway?). On my ThinkPad, I also had to disable all the compatibility boot options. Most
+  of these options were labeled "CSM".
+
+  <p>While you're in the BIOS, you might want to go ahead and disable the TPM if you have one—I've seen many reports
+  that it <a href="https://unrelenting.technology/notes/2017-11-22-15-11-44">breaks resuming from suspend in FreeBSD</a>.
+</section>
+
+<section>
+  <h2 id="partitioning">Partitioning the Disk</h2>
+
+  <p>At this point, I'm assuming that you've successfully booted the FreeBSD installation media via UEFI. If the installer
+  won't boot in pure UEFI mode, then you're probably out of luck—but the GELI encryption section of this guide might still
+  be helpful to you.
+
+  <p>Once you get to the partitioning step in the FreeBSD installer, choose the <span class="monospace">Shell</span> option
+  to manually partition the disks. The first thing you'll need to do is figure out which block device corresponds to your hard
+  drive. To show the current disk layout, just run:
+
+  <pre>gpart show</pre>
+  
+  <p>I'm going to assume your hard drive is called <span class="monospace">ada0</span>. Let's blow away the current partition
+  table and write a fresh GPT partitioning scheme.
+
+<pre>gpart destroy -F ada0
+gpart create -s gpt ada0</pre>
+
+  <p>The first partition you'll need is an <em>EFI System Partition</em>. This is a small FAT-formatted partition from which
+  your computer's firmware will boot the operating system. It just needs to be large enough to hold the FreeBSD UEFI
+  bootloader—800 KB is plenty. 
+
+<pre>gpart add -t efi -l freebsd-efi -a 4k -s 800k ada0
+newfs_msdos /dev/gpt/freebsd-efi</pre>
+
+  <p>Your computer's UEFI firmware should look for a boot executable in a specific location on this partition. You'll need
+  to mount the partition, create the folder hierarchy, and copy over the FreeBSD UEFI bootloader from the install media:
+
+<pre>mount -t msdosfs /dev/gpt/freebsd-efi /mnt
+mkdir -p /mnt/EFI/BOOT
+cp /boot/boot1.efi /mnt/EFI/BOOT/BOOTX64.efi
+echo BOOTx64.efi &gt; /mnt/EFI/BOOT/STARTUP.NSH
+umount /mnt</pre>
+
+  <p>Next, you'll need a boot partition. Confusing, I know. The EFI partition you just created contains
+  a small UEFI bootloader. However, this bootloader's only purpose is to look for a UFS (or ZFS) partition which contains the <em>real</em> 
+  FreeBSD bootloader, and then run it. The boot partition will also contain the kernel, boot configuration, and kernel modules.
+  
+  <p>This partition will have to remain unencrypted, since the bootloader needs to be able to find a kernel to execute. There
+  are some guides online for storing your boot partition and kernel on an external USB stick to achieve a fully encrypted system,
+  but I'm not that paranoid.
+
+  <p>Anyway, create the boot partition. 1 GB is probably overkill for the FreeBSD kernel, but I've got plenty of disk space. If
+  you have an SSD, be sure to pass the <span class="monospace">-t</span> flag to <span class="monospace">newfs</span> to enable
+  TRIM support.
+
+<pre>gpart add -t freebsd-ufs -l freebsd-boot -a 4k -s 1g ada0
+newfs -t -U -L bootfs /dev/gpt/freebsd-boot</pre>
+
+  <p>Finally, create a partition for your root filesystem. I don't bother with swap for a desktop machine, so I'll just use
+  the entire remainder of the disk.
+
+  <pre>gpart add -t freebsd-ufs -l freebsd-root -a 4k ada0</pre>
+
+  <p>Notice we didn't create a filesystem this time. That comes in the next section.
+
+</section>
+
+<section>
+  <h2 id="geli">GELI Encryption</h2>
+
+  <p>Now it's time to create your encrypted partition! FreeBSD's framework for disk encryption is called <a href="https://www.freebsd.org/doc/handbook/disks-encrypting.html">GELI</a>.
+  Basically, it's a layer in between the filesystem and the physical disk that manages encryption/decryption of the data blocks. Creating your
+  GELI root partition is a one-liner:
+
+  <pre>geli init -b -e AES-XTS -l 256 -s 4096 /dev/gpt/freebsd-root</pre>
+
+  <p>The <span class="monospace">-b</span> flag is critical, as it allows the encrypted partition to be used as a root filesystem.
+
+  <p>This will prompt you for an encryption passphrase. Use a good one! You will have to enter this passphrase every time you boot
+  your computer (and if you forget it, you're SOL). Once that's done, issue the following command to unlock the drive (it will
+  prompt you for the passphrase you just created):
+
+  <pre>geli attach /dev/gpt/freebsd-root</pre>
+
+  <p><em>Now</em> you can create the root UFS filesystem. Note the <span class="monospace">.eli</span> extension on the block device
+  this time:
+
+  <pre>newfs -t -U -L rootfs /dev/gpt/freebsd-root.eli</pre>
+
+</section>
+
+<section>
+  <h2 id="mounting">Mounting the Filesystems</h2>
+
+  <p>To complete the partitioning step, the FreeBSD installer expects you to mount your root filesystem at <span class="monospace">/mnt</span>:
+
+  <pre>mount /dev/gpt/freebsd-root.eli /mnt</pre>
+
+  <p>However, there is one <strong>very important</strong> caveat regarding the boot partition. The bootloader expects everything to be
+  under a folder called <span class="monospace">/boot</span> <em>on the boot partition itself</em>. Therefore, for the FreeBSD installer
+  to work, we'll need to mount the boot partition under a separate directory and create a symlink:
+
+<pre>mkdir /mnt/bootfs
+mount /dev/gpt/freebsd-boot /mnt/bootfs
+cd /mnt
+mkdir bootfs/boot
+ln -s bootfs/boot</pre>
+
+  <p><em>(Special thanks to ross at <a href="http://daemon-notes.com/articles/system/encryption">daemon-notes.com</a> for that tidbit.)</em>
+
+  <p>Finally, you'll need to create an <span class="monospace">fstab</span> and <span class="monospace">loader.conf</span> file for
+  your system to be bootable. At this stage in the installation, you can place these under <span class="monospace">/tmp/bsdinstall_*</span>
+  and the installer will copy them to the target filesystem appropriately.
+
+<pre><div class="code-title">/tmp/bsdinstall_etc/fstab</div>/dev/gpt/freebsd-root.eli /       ufs rw 1 1
+/dev/gpt/freebsd-boot     /bootfs ufs rw 0 0</pre>
+<p>
+<pre><div class="code-title">/tmp/bsdinstall_boot/loader.conf</div>geom_eli_load="YES"
+vfs.root.mountfrom="ufs:ada0p3.eli"</pre>
+
+  <p>At this point, you're finished! Exit the shell to continue the FreeBSD installation.
+
+</section>
+
+<section>
+  <h2 id="conclusion">Conclusion</h2>
+
+  <p>Once the installer has finished, you may want to open a shell before you reboot, just to make sure your <span class="monospace">fstab</span>
+  and <span class="monospace">loader.conf</span> files look correct. With any luck, your computer's UEFI firmware will be able to find your
+  bootloader and launch the FreeBSD kernel.
+
+  <p>When your system reboots, it will prompt you for your encryption passphrase during the boot process. The prompt is easy to miss
+  during the text-scrolling frenzy, so if it seems hung, just type your passphrase and press enter.
+
+  <p>As always, contact me via <a href="mailto:cullum@c0ffee.net">email</a> or ping me on <a href="https://twitter.com/cullumsmith">Twitter</a>
+  with any questions or issues you have.
+
+</section>
+

blog/freebsd-server-guide/index.tmpl

@@ -0,0 +1,760 @@
+TITLE='FreeBSD Server Guide'
+DESCRIPTION='A guide to configuring your new FreeBSD server for performance and security.'
+DATE=2017-01-21
+__HTML__
+<p><a href="https://www.freebsd.org/">FreeBSD</a> is a secure, high-performance Unix-like operating system.
+It has been my server OS of choice since I started this self-hosting hobby in my college days. In this post,
+I'll describe how I set up my FreeBSD servers—installing packages, securing the firewall, tweaking network
+performance, and configuring daemons. This will be similar to those "first five minutes on a server" articles,
+but with a focus on FreeBSD 11. If you're not a BSD fan, you're misinformed, but much of the advice in here
+will apply to any Unix-like server that you connect to the internet.
+
+<hr>
+
+<ol>
+  <li><a href="#why-freebsd">Why FreeBSD?</a>
+  <li><a href="#building-ports">Building Ports</a>
+  <li><a href="#hardware-configuration">Hardware Configuration</a>
+  <li><a href="#network-settings">Network Settings</a>
+  <li><a href="#environment-setup">Environment Setup</a>
+  <li><a href="#tweaking-network-performance">Tweaking Network Performance</a>
+  <li><a href="#ssh">LibreSSL and OpenSSH</a>
+  <li><a href="#ntp">Clock Sync with OpenNTP</a>
+  <li><a href="#pf">Securing the PF Firewall</a>
+  <li><a href="#conclusion">Conclusion</a>
+</ol>
+
+<hr>
+<section>
+  <h2 id="why-freebsd">Why FreeBSD?</h2>
+
+  <p>Simply put, I use FreeBSD because it makes my life easier. Compared to Linux, it is a more integrated,
+  stable, and well-documented operating system. And I don't mean <em>stable</em> in the sense that it has fewer
+  bugs, but in the sense that it doesn't do things like <a href="https://www.mail-archive.com/ubuntu-devel-announce@lists.ubuntu.com/msg00893.html">
+  switch init systems twice in the same decade</a>. In addition, the <a href="https://opensource.org/licenses/BSD-2-Clause">BSD License</a>
+  provides far more freedom to developers and users than the convoluted, marxist <a href="https://www.gnu.org/licenses/gpl-3.0.en.html">GPLv3</a>.
+
+  <p>For an introduction to FreeBSD from a Linux perspective, <a href="https://www.over-yonder.net/~fullermd/rants/bsd4linux/01">this guide</a>
+  is usually cited as the best on the 'net. But for a shortened version: FreeBSD is an operating system, Linux
+  is a kernel. FreeBSD is a <a href="https://upload.wikimedia.org/wikipedia/commons/thumb/9/9c/Cathedral_of_Saint_John_the_Baptist,_Charleston_SC,_Interior_view_20160704_1.jpg/1280px-Cathedral_of_Saint_John_the_Baptist,_Charleston_SC,_Interior_view_20160704_1.jpg">cathedral</a>,
+  Linux is a <a href="https://queue.acm.org/detail.cfm?id=2349257">bazaar</a>. But subjectively,
+  FreeBSD just <em>feels</em> better than Linux. Third party software is kept totally independent from the
+  base OS, <a href="https://www.freebsd.org/doc/handbook/jails.html">jails</a> and <a href="https://www.freebsd.org/doc/handbook/zfs.html">ZFS</a>
+  are awesome, <span class="monospace"><a href="https://www.freebsd.org/doc/handbook/firewalls-pf.html">PF</a></span> puts
+  <span class="monospace">iptables</span> to shame...I could go on and on. If you go with FreeBSD, you'll miss out on
+  whatever the new Linux hotness of the day is.  But in return, you'll get a solid, reliable Unix system that will quietly
+  serve you well for years to come.
+</section>
+
+<section>
+  <h2 id="building-ports">Building Ports</h2>
+
+  <p>Before we dive into system configuration, we'll at least want <span class="monospace">vim</span>
+  installed. Third-party software packages in FreeBSD are called <em>ports</em>. You can either install
+  binary packages using the <span class="monospace">pkg</span> utility or build them from source. I prefer to
+  build from source, as you get more fine-grained control over compile-time options and package
+  dependencies. It doesn't really matter which method you choose, as long as you're consistent—mixing
+  source and binary packages can sometimes cause odd behavior.
+
+  <p>To start building ports, we'll need the latest version of the ports tree. Grab a cup of coffee while
+  you run the following commands as root (it may take awhile).
+
+<pre>portsnap fetch
+portsnap extract
+</pre>
+
+  <p>Next, we'll specify some build options in <span class="monospace"><a href="https://www.freebsd.org/cgi/man.cgi?make.conf(5)">make.conf</a></span>.
+  Options that you put in this file will apply to every port you compile. It makes it easy to do things like
+  globally disable X11 support—we won't need that on a headless server. Here is what I have in my <span class="monospace">make.conf</span>:
+
+<pre><div class="code-title">/etc/make.conf</div><span class="code-comment"># allow compiler optimizations specific to our CPU model</span>
+CPUTYPE?=native
+
+<span class="code-comment"># optimization level O2 is the highest supported by FreeBSD and most ports.</span>
+CFLAGS=-O2 -pipe -fno-strict-aliasing
+
+<span class="code-comment"># COPTFLAGS only apply when building the kernel</span>
+COPTFLAGS=$CFLAGS
+
+<span class="code-comment"># don't pull in X11, CUPS, etc</span>
+OPTIONS_UNSET=DOCS NLS X11 EXAMPLES CUPS GUI DEBUG
+
+<span class="code-comment"># disable profiling, unless you like 1hr compile times</span>
+MK_PROFILE=no
+
+<span class="code-comment"># default version to use when certain ports are pulled in as dependencies</span>
+<span class="code-comment"># ..notice LibreSSL :-)</span>
+DEFAULT_VERSIONS+= ssl=libressl python=2.7 python2=2.7 python3=3.5 pgsql=9.6 php=7.0 ruby=2.3 perl=5.24 lua=5.1
+</pre>
+
+  <p>Now we can install <span class="monospace">vim</span>:
+
+  <pre><code>cd /usr/ports/editors/vim && make install clean</code></pre>
+
+  <p>You will be prompted to select some compile-time options before the package is built and installed
+  for you. You can search available packages by running <span class="monospace">make search name=$PACKAGENAME</span>
+  in <span class="monospace">/usr/ports</span>. I usually have at least the following installed on my servers:
+
+<pre>
+devel/git
+editors/vim
+ftp/curl
+net-mgmt/iftop
+ports-mgmt/portmaster
+security/sudo
+shells/zsh
+sysutils/coreutils
+sysutils/tmux
+</pre>
+</section>
+
+<section>
+  <h2 id="hardware-configuration">Hardware Configuration</h2>
+
+  <p>There are a few easy modifications we can make to improve FreeBSD's performance on modern hardware.
+  If you're using a solid state drive with the UFS file system, it's important to enable
+  <a href="https://en.wikipedia.org/wiki/Trim_(computing)">TRIM</a> support. You should also set filesystem
+  labels, so you won't have to worry about your disks getting renamed in between reboots (which often happens
+  when you enable AHCI). We can't make these changes while the disks are mounted, so you'll need to reboot
+  to single-user mode. Reboot your machine, and hit <span class="monospace">S</span> at the bootloader prompt.
+
+  <h3 id="enabling-trim">Enabling TRIM Support</h3>
+
+  <p>Once you've booted into the single-user shell, you can get a list of your partitions using
+  <span class="monospace">gpart show</span>. Here is what I see on my machine:
+
+  <pre><span class="code-comment"># gpart show</span>
+=>        34  1953525101  ada0  GPT  (932G)
+          34        2014        - free -  (1.0M)
+        2048  1953521664     1  freebsd-ufs  (932G)
+  1953523712        1423        - free -  (712K)
+
+=>       34  500118125  ada1  GPT  (238G)
+         34          6        - free -  (3.0K)
+         40       1024     1  freebsd-boot  (512K)
+       1064  500117088     2  freebsd-ufs  (238G)
+  500118152          7        - free -  (3.5K)
+</pre>
+
+  <p>So we've got two drives. <span class="monospace">ada0</span> is a 1 TB storage drive, and
+  <span class="monospace">ada1</span> is an SSD for the OS. The first partition just holds the
+  bootloader, but we'll want to make sure TRIM is enabled on the OS root partition.
+
+<pre><span class="code-comment"># tunefs -p /dev/ada1p2</span>
+tunefs: POSIX.1e ACLs: (-a)                                disabled
+tunefs: NFSv4 ACLs: (-N)                                   disabled
+tunefs: MAC multilabel: (-l)                               disabled
+tunefs: soft updates: (-n)                                 enabled
+tunefs: soft update journaling: (-j)                       enabled
+tunefs: gjournal: (-J)                                     disabled
+tunefs: trim: (-t)                                         disabled
+tunefs: maximum blocks per file in a cylinder group: (-e)  4096
+tunefs: average file size: (-f)                            16384
+tunefs: average number of files in a directory: (-s)       64
+tunefs: minimum percentage of free space: (-m)             8%
+tunefs: optimization preference: (-o)                      time
+tunefs: volume label: (-L)
+</pre>
+
+  <p>Let's go ahead and enable TRIM on this partition.
+
+<pre>tunefs -t enable /dev/ada1p2</pre>
+
+  <h3 id="ufs-labels">Setting UFS Labels</h3>
+
+  <p>While we have everything unmounted, we can set filesystem labels as well:
+
+<pre>tunefs -L rootfs /dev/ada1p2
+tunefs -L storagefs /dev/ada0p1
+</pre>
+
+  <p>Type <span class="monospace">exit</span> to leave single-user mode and continue the boot process.
+  Once you're back into your system, you can edit <span class="monospace">/etc/fstab</span> with your
+  new filesystem labels.
+
+<pre><div class="code-title">/etc/fstab</div>/dev/ufs/rootfs     /            ufs rw  1 1
+/dev/ufs/storagefs  /storage     ufs rw  1 2
+
+<span class="code-comment"># old disk names - replaced with labels above</span>
+<span class="code-comment">#/dev/ada1p2        /            ufs rw  1 1</span>
+<span class="code-comment">#/dev/ada0p1        /storage     ufs rw  1 2</span>
+</pre>
+
+  <h3 id="kernel-modules">Loading Useful Kernel Modules</h3>
+
+  <p>I usually put the following in <span class="monospace">/boot/loader.conf</span>:
+
+<pre><div class="code-title">/boot/loader.conf</div><span class="code-comment"># bootloader prompt timeout (seconds)</span>
+autoboot_delay="5"
+
+<span class="code-comment"># enable temperature sensors</span>
+coretemp_load="YES"
+
+<span class="code-comment"># enable AHCI on modern hardware for better performance</span>
+ahci_load="YES"
+
+<span class="code-comment"># enable hardware accelerated AES (can speed up TLS)</span>
+aesni_load="YES"
+
+<span class="code-comment"># enable asynchronous I/O (big performance gains with NGINX)</span>
+aio_load="YES"
+
+<span class="code-comment"># in-memory file system</span>
+tmpfs_load="YES"
+
+<span class="code-comment"># load PF firewall and the Intel ethernet driver early at boot time</span>
+pf_load="YES"
+pflog_load="YES"
+if_igb_load="YES"
+</pre>
+
+  <h3 id="disk-readahead">Increasing Disk Read Ahead</h3>
+  <p>Finally, increasing the UFS read ahead value almost always results in better performance.
+  Add the following to <span class="monospace">/etc/sysctl.conf</span>:
+
+<pre><div class="code-title">/etc/sysctl.conf</div>vfs.read_max="128"
+</pre>
+
+  <p>You should reboot your machine after making these changes to make sure you didn't break anything.
+</section>
+
+<section>
+  <h2 id="network-settings">Network Settings</h2>
+
+  <p>Open up <span class="monospace">/etc/rc.conf</span> to configure your network interfaces. You will need
+  an IP address (and hopefully an IPv6 address) for the machine, as well as a hostname of your choosing. I
+  use dual NICs with a <a href="https://www.freebsd.org/doc/handbook/network-aggregation.html"><span class="monospace">lagg</span>
+  failover interface</a>, so I've included that in the snippet below. This example uses fake IP addresses,
+  you will need real ones!
+
+<pre><div class="code-title">/etc/rc.conf</div><span class="code-comment"># choose a hostname for this machine. you did register a domain, right?</span>
+hostname="beastie.c0ffee.net"
+
+<span class="code-comment"># My machine has two interfaces in a failover configuration:</span>
+<span class="code-comment"># igb0 and igb1 are physical interfaces, lagg0 is a virtual aggregate.</span>
+<span class="code-comment"># You should disable LRO and TSO if this machine will route packets.</span>
+ifconfig_igb0="up -lro -tso"
+ifconfig_igb1="up -lro -tso"
+cloned_interfaces="lagg0"
+
+<span class="code-comment"># Your IPv4 address, netmask, and default gateway go here.</span>
+<span class="code-comment"># Your hosting provider should provide this info.</span>
+ifconfig_lagg0="laggproto failover laggport igb0 laggport igb1 192.168.1.12/24"
+defaultrouter="192.168.1.1"
+
+<span class="code-comment"># IPv6 address and IPv6 gateway go here (if applicable).</span>
+ifconfig_lagg0_ipv6="inet6 2000:f2a5:a440::2/64"
+ipv6_defaultrouter="2000:f2a5:a440::1"
+ipv6_activate_all_interfaces="YES"
+
+<span class="code-comment"># If you only had one network interface, then the below would suffice:</span>
+<span class="code-comment"># ifconfig_igb0="inet 192.168.1.12/24 -lro -tso"</span>
+<span class="code-comment"># defaultrouter="192.168.1.1"</span>
+<span class="code-comment"># ifconfig_igb0_ipv6="inet6 2000:f2a5:a440::2/64"</span>
+<span class="code-comment"># ipv6_defaultrouter="2000:f2a5:a440::1"</span>
+<span class="code-comment"># ipv6_activate_all_interfaces="YES"</span>
+</pre>
+
+  <p>You will need to set your DNS servers in <span class="monospace">/etc/resolv.conf</span>. For example, if
+  you are using Google's DNS:
+
+<pre><div class="code-title">/etc/resolv.conf</div>nameserver 8.8.8.8
+nameserver 8.8.4.4
+search c0ffee.net
+</pre>
+
+  <p>Also, make sure to add your machine's IP addresses to <span class="monospace">/etc/hosts</span>:
+
+<pre><div class="code-title">/etc/hosts</div>::1        localhost  localhost.c0ffee.net
+127.0.0.1  localhost  localhost.c0ffee.net
+
+2000:f2a5:a440::2  beastie  beastie.c0ffee.net
+192.168.1.12       beastie  beastie.c0ffee.net
+</pre>
+</section>
+
+<section>
+  <h2 id="environment-setup">Environment Setup</h2>
+
+  <p>It's the current year, so you should enable UTF-8 for your locale and charset everywhere. Add the following to
+  <span class="monospace">/etc/profile</span>:
+
+<pre><div class="code-title">/etc/profile</div>LANG=en_US.UTF-8; export LANG
+CHARSET=UTF-8;    export CHARSET
+</pre>
+
+  <p>Also, add the bolded lines below to your default login class in <span class="monospace">/etc/login.conf</span>:
+
+<pre><div class="code-title">/etc/login.conf</div>default:\
+  :passwd_format=sha512:\
+  :copyright=/etc/COPYRIGHT:\
+  :welcome=/etc/motd:\
+  :setenv=MAIL=/var/mail/$,BLOCKSIZE=K:\
+  :path=/sbin /bin /usr/sbin /usr/bin /usr/local/sbin /usr/local/bin ~/bin:\
+  :nologin=/var/run/nologin:\
+  :cputime=unlimited:\
+  :datasize=unlimited:\
+  :stacksize=unlimited:\
+  :memorylocked=64K:\
+  :memoryuse=unlimited:\
+  :filesize=unlimited:\
+  :coredumpsize=unlimited:\
+  :openfiles=unlimited:\
+  :maxproc=unlimited:\
+  :sbsize=unlimited:\
+  :vmemoryuse=unlimited:\
+  :swapuse=unlimited:\
+  :pseudoterminals=unlimited:\
+  :kqueues=unlimited:\
+  :umtxp=unlimited:\
+  :priority=0:\
+  :ignoretime@:\
+  :umask=022:\
+  <strong>:charset=UTF-8:\</strong>
+  <strong>:lang=en_US.UTF-8:</strong>
+</pre>
+
+  <p>You'll need to rebuild the login database after you edit that file:
+
+<pre>cap_mkdb /etc/login.conf
+</pre>
+
+  <p>You should also set your timezone. I'm on the east coast, so I use <span class="monospace">America/New_York</span>. Modify
+  according to your location.
+
+<pre>cp /usr/share/zoneinfo/America/New_York /etc/localtime
+</pre>
+</section>
+
+<section>
+  <h2 id="tweaking-network-performance">Tweaking Network Performance</h2>
+
+  <p>In my experience, the default TCP settings of the FreeBSD kernel yielded very poor network
+  performance. My server has a fairly fast 1 Gbps uplink, but the majority of my traffic must travel
+  all the way across the country to the east coast (about a 100ms round-trip-time). My biggest
+  problem involved
+  <a href="https://en.wikipedia.org/wiki/TCP_congestion_control#Slow_start">TCP Slow Start</a>,
+  the algorithm that initially increases the throughput of TCP connections. I could eventually
+  max out my server's network connection, but it would take 15 minutes or more for the transfer
+  speed to ramp up.
+
+  <p>To get decent
+  throughput, I had to tweak a fair amount of various kernel options and <span class="monospace">sysctl</span>s.
+  Most of my inspiration came from
+  <a href="https://calomel.org/freebsd_network_tuning.html">this awesome Calomel guide</a> and a
+  lot of trial and error. If you have a different network topology, you may have to modify some
+  of these values and see what works best for you.
+
+  <p>First, let's enable some boot-time kernel options in <span class="monospace">/boot/loader.conf</span>.
+
+<pre><div class="code-title">/boot/loader.conf</div><span class="code-comment"># Load the H-TCP algorithm. It has a more aggressive ramp-up to max</span>
+<span class="code-comment"># bandwidth, and is optimized for high-speed, high-latency connections.</span>
+cc_htcp_load="YES"
+
+<span class="code-comment"># accept filters allow the kernel to buffer certain incoming connections</span>
+<span class="code-comment"># until a complete request is received (such as HTTP headers). This can</span>
+<span class="code-comment"># reduce the number of context switches required by the CPU.</span>
+accf_http_load="YES"
+accf_data_load="YES"
+accf_dns_load="YES"
+
+<span class="code-comment"># The hostcache is used to "grade" the throughput of previous connections.</span>
+<span class="code-comment"># Calomel says that disabling it can increase throughput on connections</span>
+<span class="code-comment"># incorrectly marked as slow. I didn't notice much difference either way.</span>
+net.inet.tcp.hostcache.cachelimit="0"
+
+<span class="code-comment"># This is the network interface queue length. According to <a href="https://svnweb.freebsd.org/base?view=revision&revision=207554">this commit</a>,</span>
+<span class="code-comment"># the default value of 50 is far too low. Calomel recommends 2x the value</span>
+<span class="code-comment"># of hw.igb.txd, which has worked well for me.</span>
+net.link.ifqmaxlen="2048"
+
+<span class="code-comment"># Enables a faster but possibly buggy implementation of soreceive. I</span>
+<span class="code-comment"># haven't had any problems with it.</span>
+net.inet.tcp.soreceive_stream="1"
+
+<span class="code-comment"># FreeBSD sets an artificial limit on the number of packets an Intel card</span>
+<span class="code-comment"># can process per interrupt cycle (default 100). This is almost totally</span>
+<span class="code-comment"># useless on modern hardware. -1 means no limit.</span>
+hw.igb.rx_process_limit="-1"
+</pre>
+
+  <p>You'll have to reboot your machine for these changes to take effect.
+
+  <p>The rest of the network options can be tweaked on the fly using <span class="monospace">sysctl</span>:
+
+<pre><div class="code-title">/etc/sysctl.conf</div><span class="code-comment"># soacceptqueue is the kernel's backlog queue depth for accepting new TCP</span>
+<span class="code-comment"># connections. A larger value should prevent clients from being dropped</span>
+<span class="code-comment"># during sudden bursty periods at the expense of more RAM and CPU load.</span>
+kern.ipc.soacceptqueue=1024  <span class="code-comment"># (default 128)</span>
+
+<span class="code-comment"># maxsockbuf is the max amount of memory that can be allocated to a socket.</span>
+<span class="code-comment"># In practice, this value determines the <a href="https://en.wikipedia.org/wiki/TCP_window_scale_option">TCP window scaling</a> factor - the</span>
+<span class="code-comment"># number of bytes that can be transmitted without requiring an ACK. If our</span>
+<span class="code-comment"># server is not under heavy load, we want a large scaling factor, because</span>
+<span class="code-comment"># we can transmit packets as fast as the receiver can process them.</span>
+<span class="code-comment">#</span>
+<span class="code-comment"># The default maxsockbuf value (2MB) will result in a scaling factor of 6,</span>
+<span class="code-comment"># which is ideal for a low-latency gigabit network.</span>
+<span class="code-comment">#</span>
+<span class="code-comment"># However, my server is on the west coast, on a gigabit connection with</span>
+<span class="code-comment"># 100ms of latency to my hometown on the east coast. A scaling factor of 8:</span>
+<span class="code-comment">#</span>
+<span class="code-comment">#     2^8 x 65,535-byte IP packet size = 16,776,960 bytes</span>
+<span class="code-comment">#</span>
+<span class="code-comment"># happens to saturates my connection:</span>
+<span class="code-comment">#</span>
+<span class="code-comment">#   16,776,960 bytes * 8 / .1 sec latency / 10^9 = 1.3421568 Gbps</span>
+<span class="code-comment">#</span>
+<span class="code-comment"># You remember Bandwidth Delay Product from networking class, right? :-)</span>
+<span class="code-comment">#</span>
+<span class="code-comment"># A maxsockbuf value of 8MB will yield a scaling factor of 8. To see</span>
+<span class="code-comment"># how this is derived, you can check <a href="https://github.com/freebsd/freebsd/blob/master/sys/netinet/tcp_syncache.c#L1415">/sys/netinet/tcp_syncache.c</a>.</span>
+<span class="code-comment">#</span>
+kern.ipc.maxsockbuf=8388608
+
+<span class="code-comment"># sendspace and recvspace are the network buffer sizes *initially* allocated</span>
+<span class="code-comment"># to each TCP connection. Bandwidth can be improved by increasing the buffer</span>
+<span class="code-comment"># size at the cost of using more kernel memory per connection. Saturating my</span>
+<span class="code-comment"># gigabit connection with 100ms latency would require:</span>
+<span class="code-comment">#</span>
+<span class="code-comment">#  1000 megabits * .1 sec / 8 bits = 12.5 MB </span>
+<span class="code-comment">#</span>
+<span class="code-comment"># However, just 80 simultaneous connections would immediately consume a</span>
+<span class="code-comment"># GIGABYTE of RAM! Most of the traffic to my server is for small, static</span>
+<span class="code-comment"># HTML pages and some SSH connections, so I've set a smaller default size:</span>
+<span class="code-comment">#</span>
+<span class="code-comment">#   256 KB = 256 * 1024 bytes = 262,144 bytes</span>
+<span class="code-comment">#</span>
+<span class="code-comment"># The kernel will allocate more memory as needed (at a very slight</span>
+<span class="code-comment"># performance hit) for the occasional full-throttle transfer of large</span>
+<span class="code-comment"># files.</span>
+<span class="code-comment">#</span>
+net.inet.tcp.sendspace=262144  <span class="code-comment"># (default 32768)</span>
+net.inet.tcp.recvspace=262144  <span class="code-comment"># (default 65536)</span>
+
+<span class="code-comment"># sendbuf_max and recvbuf_max control the maximum send and recv buffer sizes</span>
+<span class="code-comment"># the kernel will ever allocate for a single TCP connection. I set mine to</span>
+<span class="code-comment"># 16 MB, which is slightly higher than the 12.5 MB I calculated above. This </span>
+<span class="code-comment"># should let me to saturate my 100ms connection, as well as leave some</span>
+<span class="code-comment"># wiggle room to saturate even higher-latency clients.</span>
+<span class="code-comment">#</span>
+<span class="code-comment"># You should probably make sure these values are at least as large as</span>
+<span class="code-comment"># maxsockbuf.</span>
+<span class="code-comment">#</span>
+net.inet.tcp.sendbuf_max=16777216
+net.inet.tcp.recvbuf_max=16777216
+
+<span class="code-comment"># sendbuf_inc and recvbuf_inc control the increments by which the kernel</span>
+<span class="code-comment"># increases sendspace and recvspace to sendbuf_max and recvbuf_max,</span>
+<span class="code-comment"># respectively. Higher values will cause fewer memory allocations, but may</span>
+<span class="code-comment"># result in wasted buffer space.</span>
+<span class="code-comment">#</span>
+net.inet.tcp.sendbuf_inc=32768  <span class="code-comment"># (default 8192)</span>
+net.inet.tcp.recvbuf_inc=65536  <span class="code-comment"># (default 16384)</span>
+
+<span class="code-comment"># increase the localhost buffer space, which may help localhost-only servers</span>
+<span class="code-comment"># more efficiently move data to network buffers.</span>
+net.local.stream.sendspace=16384  <span class="code-comment"># default (8192)</span>
+net.local.stream.recvspace=16384  <span class="code-comment"># default (8192)</span>
+
+<span class="code-comment"># increase the raw IP datagram buffers to the MTU for the localhost</span>
+<span class="code-comment"># interface (2^14 bytes = 16384). Thanks, Calomel!</span>
+net.inet.raw.maxdgram=16384
+net.inet.raw.recvspace=16384
+
+
+<span class="code-comment"># *** these two settings gave me the most drastic improvement: ***</span>
+
+<span class="code-comment"># TCP Slow Start gradually ramps up the data transmission rate until the</span>
+<span class="code-comment"># throughput on the network path has been determined. TCP Appropriate Byte</span>
+<span class="code-comment"># Counting (ABC) allows the kernel to increase the window size</span>
+<span class="code-comment"># exponentially. According to Calomel, with maxseg set to the default of</span>
+<span class="code-comment"># 1460 bytes, setting abc_l_var to 44 allows an increase of about 64 KB per</span>
+<span class="code-comment"># step, which happens to be the receive buffer size of most hosts that don't</span>
+<span class="code-comment"># support window scaling.</span>
+<span class="code-comment">#</span>
+net.inet.tcp.abc_l_var=44          <span class="code-comment"># (default 2)</span>
+
+<span class="code-comment"># The TCP initial congestion window determines the *initial* amount of data</span>
+<span class="code-comment"># that can be sent over the network before requiring an ACK from the other</span>
+<span class="code-comment"># side. The Slow Start algorithm will improve this value over time. A larger</span>
+<span class="code-comment"># initcwnd will speed up short, bursty connections. Google recommends 16,</span>
+<span class="code-comment"># but according to Calomel, you should also test 44.</span>
+net.inet.tcp.initcwnd_segments=44  <span class="code-comment"># (default 10)</span>
+
+
+<span class="code-comment"># Maximum Segment Size (MSS) specifies the largest amount of data that can</span>
+<span class="code-comment"># be placed in a single IPv4 TCP segment. This value is usually equal to:</span>
+<span class="code-comment">#</span>
+<span class="code-comment">#   MTU (usually 1500) - 20 byte IPv4 header - 20 byte TCP header = 1460</span>
+<span class="code-comment">#</span>
+<span class="code-comment"># If you have net.inet.tcp.rfc1323 enabled (it is by default on FreeBSD),</span>
+<span class="code-comment"># then TCP hosts can negotiate timestamps which increases the TCP headers</span>
+<span class="code-comment"># by 12 bytes. So in the case we'll use 1460 - 12  = 1448 bytes.</span>
+<span class="code-comment">#</span>
+net.inet.tcp.mssdflt=1448  <span class="code-comment"># (default 536)</span>
+
+<span class="code-comment"># The Minimum MSS specifies the smallest amount of data we will send in a</span>
+<span class="code-comment"># single IPv4 TCP segment. RFC 6691 requires a minimum value of 576 bytes.</span>
+<span class="code-comment"># Subtracting a 20 byte IP header and 20 (or 32, see above) byte TCP header</span>
+<span class="code-comment"># gives us:</span>
+<span class="code-comment">#</span>
+<span class="code-comment">#  576 (minimum MTU) - 20 byte IPv4 header - 32 byte TCP header = 524 bytes.</span>
+<span class="code-comment">#</span>
+net.inet.tcp.minmss=524  <span class="code-comment"># (default 216)</span>
+
+<span class="code-comment"># use the H-TCP algorithm that we enabled in /boot/loader.conf above.</span>
+net.inet.tcp.cc.algorithm=htcp
+
+<span class="code-comment"># Enable H-TCP's adaptive backoff optimization, which increases buffer</span>
+<span class="code-comment"># efficiency along the network path.</span>
+net.inet.tcp.cc.htcp.adaptive_backoff=1
+
+<span class="code-comment"># Enable H-TCP's RTT scaling optimization, which increases fairness between</span>
+<span class="code-comment"># flows with different RTTs.</span>
+net.inet.tcp.cc.htcp.rtt_scaling=1
+
+<span class="code-comment"># RFC 6675 improves TCP Fast Recovery when combined with SACK (which is</span>
+<span class="code-comment"># enabled by default on FreeBSD - net.inet.tcp.sack.enable)</span>
+net.inet.tcp.rfc6675_pipe=1
+
+<span class="code-comment"># Disabling syncookies will give us more TCP features like window scale and</span>
+<span class="code-comment"># timestamps at the expense of making us more vulnerable to DoS attacks.</span>
+net.inet.tcp.syncookies=0
+
+<span class="code-comment"># disable the TIME_WAIT state for the localhost interface, this should</span>
+<span class="code-comment"># result in localhost sockets being freed more quickly.</span>
+net.inet.tcp.nolocaltimewait=1
+
+<span class="code-comment"># TSO (and LRO) should be disabled on machines that forward packets. I use</span>
+<span class="code-comment"># OpenVPN, sometimes, so I've disabled TSO here. These options can also be</span>
+<span class="code-comment"># disabled in /etc/rc.conf using the `-tso -lro` options.</span>
+net.inet.tcp.tso=0
+
+<span class="code-comment"># these two values control the number of frames the NIC will accept before</span>
+<span class="code-comment"># firing an interrupt. If the queue fills up and the machine is overloaded,</span>
+<span class="code-comment"># packets will be dropped. Increasing this value should mitigate packet loss</span>
+<span class="code-comment"># in case of a storm of short, bursty packets, but if</span>
+<span class="code-comment"># net.inet.ip.intr_queue_drops remains greater than 0, you probably just</span>
+<span class="code-comment"># need better hardware.</span>
+<span class="code-comment">#</span>
+net.inet.ip.intr_queue_maxlen=2048  <span class="code-comment"># (default 256)</span>
+net.route.netisr_maxqlen=2048       <span class="code-comment"># (default 256)</span>
+
+<span class="code-comment"># Disable Intel's hardware-based ethernet flow control. Instead we will rely</span>
+<span class="code-comment"># on TCP which is peer-based and more fair to each flow.</span>
+dev.igb.0.fc=0  <span class="code-comment"># (default 3)</span>
+dev.igb.1.fc=0  <span class="code-comment"># (default 3)</span>
+</pre>
+
+  <p>Run the following command to update the kernel with the new values:
+
+<pre>sysctl -f /etc/sysctl.conf
+</pre>
+</section>
+
+<section>
+  <h2 id="ssh">LibreSSL and OpenSSH</h2>
+
+  <p>In the <a href="#building-ports">Building Ports</a> section above, we set our default <span class="monospace">openssl</span>
+  implementation to <a href="https://www.libressl.org/">LibreSSL</a>. LibreSSL is a fork of OpenSSL initiated by the
+  OpenBSD developers after the <a href="http://heartbleed.com/">heartbleed</a> bug was discovered. It aims to be a
+  more secure, modern, and less crufty replacement for OpenSSL.
+
+  <p>You can check the <a href="https://wiki.freebsd.org/LibreSSL">wiki page</a> for details about running LibreSSL on
+  FreeBSD. Currently, OpenSSL is still the default implementation in the base system, but you can build almost all ports
+  using LibreSSL without any issues.
+
+  <p>The base SSH daemon will continue to use the base OpenSSL. To use a more up-to-date, upstream build with LibreSSL,
+  you can use the <span class="monospace">security/openssh-portable</span> port.
+
+<pre>cd /usr/ports/security/openssh-portable
+make install clean</pre>
+
+<p>The default build options are fine. I usually enable LDNS so I can get DNS fingerprint verification.
+
+<p>Here are the options I set in my <span class="monospace">sshd_config</span>. Many of them are taken from
+<a href="https://wiki.mozilla.org/Security/Guidelines/OpenSSH#Modern_.28OpenSSH_6.7.2B.29">Mozilla's OpenSSH security guidelines</a>.
+At the very least, you'll want to set a non-default port for SSH unless you want Chinese botnets
+bruteforcing logins 24/7.
+
+<pre><div class="code-title">/usr/local/etc/ssh/sshd_config</div><span class="code-comment"># ANYTHING other than port 22!</span>
+Port 15522
+
+<span class="code-comment"># explicitly disable the less-secure protocol 1 </span>
+Protocol 2
+
+<span class="code-comment"># supported HostKey algorithms by order of preference.</span>
+<span class="code-comment"># I commented out the other ones.</span>
+HostKey /usr/local/etc/ssh/ssh_host_ed25519_key
+HostKey /usr/local/etc/ssh/ssh_host_rsa_key
+HostKey /usr/local/etc/ssh/ssh_host_ecdsa_key
+
+KexAlgorithms curve25519-sha256@libssh.org,ecdh-sha2-nistp521,ecdh-sha2-nistp384,ecdh-sha2-nistp256,diffie-hellman-group-exchange-sha256
+Ciphers chacha20-poly1305@openssh.com,aes256-gcm@openssh.com,aes128-gcm@openssh.com,aes256-ctr,aes192-ctr,aes128-ctr
+MACs hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-512,hmac-sha2-256,umac-128@openssh.com
+
+PermitRootLogin no
+StrictModes yes
+IgnoreRhosts yes
+
+<span class="code-comment"># only accept pubkey-based authentication</span>
+HostbasedAuthentication no
+PasswordAuthentication no
+PermitEmptyPasswords no
+ChallengeResponseAuthentication no
+AuthenticationMethods publickey
+
+X11Forwarding no
+UsePrivilegeSeparation sandbox
+
+Subsystem sftp  /usr/local/libexec/sftp-server
+
+<span class="code-comment"># only these whitelisted users may connect</span>
+AllowUsers joeuser janeuser
+</pre>
+
+  <p>Finally, you'll need to disable the base OpenSSH daemon and enable the new one we installed from ports:
+
+<pre><div class="code-title">/etc/rc.conf</div><span class="code-comment">#sshd_enable="YES"</span>
+openssh_enable="YES"
+</pre>
+  <p>Now start the new SSH server:
+
+<pre>service openssh start
+</pre>
+
+  <p>Since we have disabled all login mechanisms except for pubkey-based authentication,
+  make sure you copy your public keys to your <span class="monospace">~/.ssh/authorized_keys</span>
+  file on your server. I recommend <a href="https://ed25519.cr.yp.to/">ed25519</a> keys, as they are
+  much faster and arguably more secure than RSA. You can generate ed25519 keys on your client
+  machines with the following:
+
+<pre>ssh-keygen -t ed25519
+</pre>
+
+  <p>When you have successfully logged in over the new SSH port, you can stop the old SSH daemon.
+</section>
+
+<pre>service sshd onestop
+</pre>
+
+<section>
+  <h2 id="ntp">Clock Sync with OpenNTP</h2>
+
+  <p>There have been numerous security advisories related to the base NTP daemon, and I get the feeling that the
+  code is written by scientists rather than sysadmins. I use OpenBSD's NTP daemon, available at
+  <span class="monospace">net/openntpd</span>.
+
+<pre>cd /usr/ports/net/openntpd
+make install clean
+</pre>
+
+  <p>First, make sure the base NTP daemon isn't running:
+
+<pre>service ntpd stop
+</pre>
+
+  <p>Then enable the new OpenNTP daemon in <span class="monospace">/etc/rc.conf</span>. Make sure the base
+  NTP daemon is disabled:
+
+<pre><div class="code-title">/etc/rc.conf</div><span class="code-comment">#ntpd_enable="YES"</span>
+openntpd_enable="YES"
+<span class="code-comment"># the -s flag instructs OpenNTP to set the clock immediately at startup</span>
+openntpd_flags="-s"
+</pre>
+
+  <p>Start the new NTP service:
+
+<pre>service openntpd start
+</pre>
+</section>
+
+<section>
+  <h2 id="pf">Securing the PF Firewall</h2>
+
+  <p><a href="https://www.freebsd.org/doc/handbook/firewalls-pf.html">PF</a>, the OpenBSD firewall, is included
+  in the FreeBSD base install. People argue about performance between PF and IPFW, but I think PF's syntax
+  is the easiest of any firewall in existence. We'll use a simple PF setup—just blocking all inbound connections
+  except to specific services we allow.
+
+  <p>The PF configuration lives at <span class="monospace">/etc/pf.conf</span>:
+
+<pre><div class="code-title">/etc/pf.conf</div><span class="code-comment"># the external network interface to the internet</span>
+ext_if="lagg0"
+
+<span class="code-comment"># port on which sshd is running</span>
+ssh_port = "15522"
+
+<span class="code-comment"># allowed inbound ports (services hosted by this machine)</span>
+inbound_tcp_services = "{auth, http, https, " $ssh_port " }"
+inbound_udp_services = "{dhcpv6-client,openvpn}"
+
+<span class="code-comment"># politely send TCP RST for blocked packets. The alternative is</span>
+<span class="code-comment"># "set block-policy drop", which will cause clients to wait for a timeout</span>
+<span class="code-comment"># before giving up.</span>
+set block-policy return
+
+<span class="code-comment"># log only on the external interface</span>
+set loginterface $ext_if
+
+<span class="code-comment"># skip all filtering on localhost</span>
+set skip on lo
+
+<span class="code-comment"># reassemble all fragmented packets before filtering them</span>
+scrub in on $ext_if all fragment reassemble
+
+<span class="code-comment"># block forged client IPs (such as private addresses from WAN interface)</span>
+antispoof for $ext_if
+
+<span class="code-comment"># default behavior: block all traffic</span>
+block all
+
+<span class="code-comment"># allow all icmp traffic (like ping)</span>
+pass quick on $ext_if proto icmp
+pass quick on $ext_if proto icmp6
+
+<span class="code-comment"># allow incoming traffic to services hosted by this machine</span>
+pass in quick on $ext_if proto tcp to port $inbound_tcp_services
+pass in quick on $ext_if proto udp to port $inbound_udp_services
+
+<span class="code-comment"># allow all outgoing traffic</span>
+pass out quick on $ext_if
+</pre>
+  <p>You should check the syntax of your PF configuration before enabling the firewall:
+
+<pre>pfctl -vnf /etc/pf.conf
+</pre>
+
+  <p>If all is well, enable the PF firewall daemon:
+
+<pre><div class="code-title">/etc/rc.conf</div>pf_enable="YES"
+</pre>
+
+  <p>And then start the service. Your SSH session might get reset. (Note: it may be
+  a good idea to have a serial console session open before you enable the firewall, in case you
+  accidentally lock yourself out.)
+
+<pre>service pf start
+</pre>
+
+  <p>You should now have a basic firewall configuration to protect your server from unintended
+  open ports. If you are feeling more paranoid, you can restrict outgoing traffic as well. Remember
+  that PF processes rules from top to bottom—the last matching rule wins (with the exception of
+  rules with the <span class="monospace">quick</span> modifier: those rules match immediately, and no further
+  matching is attempted).
+
+  <p>If you are following my <a href="/blog/self-hosting-guide/">self-hosting guide</a>, we will be coming
+  back to this PF configuration frequently as we enable new services.
+
+</section>
+
+<section>
+  <h2 id="conclusion">Conclusion</h2>
+
+  <p>If you've followed everything in this guide, you should have a relatively modern and secure FreeBSD server
+  that you can safely connect to the internet. Check back to this page as new FreeBSD versions get released. I will
+  continue to update this post with what I consider to be <em>Best Practices™️️</em> as the FreeBSD ecosystem
+  evolves.
+</section>
+

blog/index.tmpl

@@ -0,0 +1,10 @@
+TITLE='Cullum Smith: Blog'
+DESCRIPTION="Cullum Smith's Blog"
+__HTML__
+%%NAV%%
+
+<header>
+  <h1 class="title">%%AUTHOR%%'s Blog</h1>
+</header>
+
+<main>

blog/openvpn-guide/index.tmpl

@@ -0,0 +1,436 @@
+TITLE='OpenVPN Setup Guide'
+DESCRIPTION='Browse securely from anywhere using a personal VPN with OpenVPN, LDAP, FreeBSD, and PF.'
+DATE=2017-11-26
+__HTML__
+<p>A VPN allows you to securely extend a private network over the internet via tunneling protocols and traffic encryption. For most
+people, a VPN offers two primary features: (1) the ability to access services on your local network over the internet, and (2) secure
+internet connectivity over an untrusted network. In this guide, I'll describe how to set up a personal VPN using 
+<a href="https://openvpn.net">OpenVPN</a> on FreeBSD. The configuration can use both SSL certificates and LDAP credentials for authentication. We'll also be using the PF
+firewall to NAT traffic from our VPN out to the internet.
+
+<p>One important note about running your own VPN: since you are most likely hosting your server using a VPS or hosting provider, with a
+public IP address allocated specifically to you, your VPN will <strong>not</strong> give you any extra anonymity on the internet. If anything,
+you'll be making yourself more of a target, since all your activity can be trivially traced back to your server's IP address. So while
+your VPN will protect you from a snooping hacker on the free WiFi at Starbucks, it won't protect you from a federal investigation.
+
+<p>This guide assumes you are running FreeBSD with the PF firewall. If you're using a different Unix flavor, I'll probably get you
+most of the way there—but you'll be on your own when configuring your firewall and networking.
+
+<p>Finally, I've used <span class="monospace">example.com</span> and a non-routable public IP address for all the examples in this guide.
+You'll need to replace them with your own domain name and public IP address.
+
+<p>With all that out of the way, let's get started.
+
+<section>
+  <h2>Configuring the OpenVPN Server</h2>
+  
+  <p>First, you'll need to install OpenVPN. You can use your distribution's package manager, but my examples assume you're using the FreeBSD
+  ports tree. I recommend building with the <span class="monospace">EASYRSA</span> option—you'll need it later.
+
+<pre>cd /usr/ports/security/openvpn
+make install clean</pre>
+
+  <p>OpenVPN should ship with a default configuration file. Open it up in your editor to see all the available options. I've pasted my own
+  configuration below, along with some commentary where appropriate. You'll almost certainly need to make some changes.
+
+<pre><div class="code-title">/usr/local/etc/openvpn/openvpn.conf</div><span class="code-comment"># port to listen on - 1194 is OpenVPN default</span>
+port 1194
+
+<span class="code-comment"># OpenVPN works best over UDP, but has support for TCP as well. UDP is</span>
+<span class="code-comment"># recommended, since tunneling TCP over TCP has well-known performance</span>
+<span class="code-comment"># issues.</span>
+proto udp
+
+<span class="code-comment"># OpenVPN supports TUN and TAP devices for the virtual network:</span>
+<span class="code-comment">#  TUN: uses layer 3, less overhead but cannot bridge with other interfaces</span>
+<span class="code-comment">#  TAP: uses layer 2, more overhead (emulates ethernet frames) but can</span>
+<span class="code-comment">#       bridge with other interfaces</span>
+<span class="code-comment"># The configuration I present here uses TUN.</span>
+dev tun
+
+<span class="code-comment"># DH params, CA, and key pair for your VPN server. Replace example.com with</span>
+<span class="code-comment"># your domain name. We will generate these using easy-rsa in the next step.</span>
+dh /usr/local/etc/openvpn/keys/dh.pem
+ca /usr/local/etc/openvpn/keys/ca.crt
+cert /usr/local/etc/openvpn/keys/vpn.example.com.crt <span class="code-comment"># change me!</span>
+key /usr/local/etc/openvpn/keys/vpn.example.com.key  <span class="code-comment"># change me!</span>
+
+<span class="code-comment"># Modern cipher recommendations from Mozilla. Comment these out if you need</span>
+<span class="code-comment"># to support old/legacy clients.</span>
+tls-version-min 1.2
+tls-cipher ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384
+
+<span class="code-comment"># No need to set block cipher manually anymore - OpenVPN 2.4+ automatically</span>
+<span class="code-comment"># negotiates AES-256-GCM. Uncomment if you use older clients that default</span>
+<span class="code-comment"># to insecure ciphers.</span>
+<span class="code-comment"># cipher AES-256-CBC</span>
+
+<span class="code-comment"># VPN network - server accessible @ 10.8.0.1</span>
+topology subnet
+server 10.8.0.0 255.255.255.0
+
+<span class="code-comment"># cache client IP addresses in a file for later re-use</span>
+ifconfig-pool-persist ipp.txt
+
+<span class="code-comment"># This line will force clients to route ALL their internet traffic through</span>
+<span class="code-comment"># the VPN. If you only want to use your VPN to access internal services,</span>
+<span class="code-comment"># comment this out.</span>
+push "redirect-gateway def1 bypass-dhcp"
+
+<span class="code-comment"># These lines tell clients which DNS servers to use once they are connected</span>
+<span class="code-comment"># to the VPN. If you run a local DNS server, you can have clients use the</span>
+<span class="code-comment"># server's own address (10.8.0.1). If you don't run a local DNS server, you</span>
+<span class="code-comment"># can substitute your server's configured nameserver here (check</span>
+<span class="code-comment"># /etc/resolv.conf).</span>
+push "dhcp-option DNS 10.8.0.1"
+push "dhcp-option DOMAIN example.com" <span class="code-comment"># change me!</span>
+
+<span class="code-comment"># let clients see each other</span>
+client-to-client
+
+<span class="code-comment"># ping every 10s, timeout after 120s</span>
+keepalive 10 120
+
+<span class="code-comment"># max simultaneous clients</span>
+max-clients 20
+
+<span class="code-comment"># drop privileges</span>
+user nobody
+group nobody
+persist-key
+persist-tun
+
+<span class="code-comment"># log levels 0-9</span>
+verb 3
+
+<span class="code-comment"># silence repeated messages</span>
+mute 10
+
+<span class="code-comment"># notify clients when the server restarts so they can automatically</span>
+<span class="code-comment"># reconnect</span>
+explicit-exit-notify 1
+
+<span class="code-comment"># experimental TUN UDP I/O optimizations</span>
+fast-io
+
+<span class="code-comment"># Uncomment the following line if you want to use LDAP authentication in</span>
+<span class="code-comment"># addition to SSL certificates.</span>
+<span class="code-comment"># plugin /usr/local/lib/openvpn-auth-ldap.so "/usr/local/etc/openvpn/auth-ldap.conf"</pre></span>
+
+  <section> 
+    <h3>LDAP Authentication</h3>
+
+    <p>For added security, you can have clients supply their LDAP credentials in addition to their
+    provisioned SSL certificates. You'll need to install a plugin first:
+
+<pre>cd /usr/ports/security/openvpn-auth-ldap
+make install clean</pre>
+
+    <p>Then, just supply your LDAP connectivity details in a separate configuration file. Make sure
+    you include each option below—I spent hours troubleshooting this part because I had neglected the
+    <span class="monospace">Timeout</span> parameter.
+
+<pre><div class="code-title">/usr/local/etc/openvpn/auth-ldap.conf</div>&lt;LDAP&gt;
+  URL              ldap://localhost
+  TLSEnable        no
+  FollowReferrals  no
+  Timeout          15
+&lt;/LDAP&gt;
+
+&lt;Authorization&gt;
+  BaseDN        "ou=users,dc=example,dc=com"
+  SearchFilter  "(&amp;(uid=%u))"
+  RequireGroup  false
+&lt;/Authorization&gt;</pre>
+
+  </section>
+
+  <h3>Notes on Using Your Own DNS Server</h3>
+
+  <p>If you're running your own DNS server for the VPN, make sure it's listening for DNS queries on the VPN's interface.
+  If you followed my <a href="/blog/dns-hidden-master/">DNS Hosting Guide</a>, you'll just need to add the VPN's network address to
+  BIND's configuration file:
+
+<pre><div class="code-title">/usr/local/etc/namedb/named.conf</div><span class="code-comment">// localhost, and any other public IPs of your server</span>
+acl localnetworks {
+  127.0.0.1;
+  ::1;
+  <strong>10.8.0.0/24;</strong>
+  203.0.113.41;
+  203.0.113.42;
+  2001:db8::2;
+  2001:db8::3;
+};</pre>
+</section>
+
+<section>
+
+  <h2>Generating the Server Certificates</h2>
+
+  <p>Finally, you need to generate a Certificate Authority and an SSL key pair. You'll distribute the CA to your
+  clients so they can verify the authenticity of your VPN server. These files can be generated using the Easy-RSA
+  package. Install it now if you didn't specify it in OpenVPN's build options earlier.
+
+<pre>cd /usr/ports/security/easy-rsa
+make install clean</pre>
+
+  <p>Copy the whole Easy-RSA package into OpenVPN's configuration directory.
+
+<pre>cp -r /usr/local/share/easy-rsa /usr/local/etc/openvpn/easy-rsa
+cd /usr/local/etc/openvpn/easy-rsa
+</pre>
+  <p><em><strong>EDIT (29 Nov 2017): In a production setup, it's never a good idea to do certificate management on a public-facing server.</strong>
+    Once you've verified everything works, you should move your Easy-RSA directory to a secure location away from the prying eyes of the internet. (Thanks
+    to <a href="https://twitter.com/DavidSommerseth">@DavidSommerseth</a> for reminding me to point this out.)</em>
+
+  <p>Easy-RSA is configured by setting options in the <span class="monospace">vars</span> configuration file:
+
+<pre><div class="code-title">/usr/local/etc/openvpn/easy-rsa/vars</div>set_var EASYRSA_DN           "cn_only"
+
+<span class="code-comment"># Elliptic curve cryptography is faster and arguably more secure than RSA.</span>
+<span class="code-comment"># I use EC in my setup, but stick to RSA if you need to support older</span>
+<span class="code-comment"># clients.</span>
+set_var EASYRSA_ALGO         ec
+set_var EASYRSA_CURVE        secp384r1
+
+<span class="code-comment"># generated certificates will expire after 10 years.</span>
+set_var EASYRSA_CA_EXPIRE    3650
+set_var EASYRSA_CERT_EXPIRE  3650</pre>
+
+  <p>Now you're ready to generate your certificate infrastructure:
+
+<pre>./easyrsa.real init-pki
+
+./easyrsa.real build-ca
+<span class="code-comment"># You will be prompted for a password when generating the CA. Keep it</span>
+<span class="code-comment"># somewhere safe, since you will need it when generating client certs.</span>
+<span class="code-comment"># You can put whatever you like for the Common Name. I use</span>
+<span class="code-comment"># "vpn.example.com CA". </span>
+
+<span class="code-comment"># relace "vpn.example.com" with your server's FQDN. </span>
+./easyrsa.real build-server-full vpn.example.com nopass <span class="code-comment"># change me!</span>
+<span class="code-comment"># enter password from previous step when prompted.</span>
+
+./easyrsa.real gen-dh
+</pre>
+
+  <p>Copy the generated files into a separate directory, as we specified in <span class="monospace">openvpn.conf</span>:
+
+<pre>mkdir /usr/local/etc/openvpn/keys
+cd /usr/local/etc/openvpn/keys
+cp ../easy-rsa/pki/ca.crt .
+cp ../easy-rsa/pki/dh.pem .
+cp ../easy-rsa/pki/issued/vpn.example.com.crt  . <span class="code-comment"># change me!</span>
+cp ../easy-rsa/pki/private/vpn.example.com.key . <span class="code-comment"># change me!</span></pre>
+
+  <p>Enable OpenVPN to start on boot:
+
+<pre><div class="code-title">/etc/rc.conf</div>openvpn_enable="YES"</pre>
+
+  <p>Finally, start OpenVPN!
+
+<pre>service openvpn start</pre>
+
+  <p>You can check for any startup issues in <span class="monospace">/var/log/messages</span>.
+  
+</section>
+
+<section>
+  <h2>Routing VPN Traffic to the Internet</h2>
+
+  <p>OpenVPN will create a secure virtual network for your VPN clients, but it's up to your firewall to
+  route traffic from your VPN interface out to the internet using <a href="https://en.wikipedia.org/wiki/Network_address_translation">Network Address Translation (NAT)</a>.
+  If you followed the <a href="freebsd-server-guide#pf">PF section of my FreeBSD Server Guide</a>,
+  you just need to make a few small tweaks to <span class="monospace">pf.conf</span>. I've highlighted the important changes in bold.
+
+<pre><div class="code-title">/etc/pf.conf</div># the external network interface to the internet
+<span class="code-comment"># public-facing interface</span>
+ext_if="vtnet0"
+
+<span class="code-comment"># your public-facing IP address -  VPN traffic will NAT out of this address</span>
+<strong>ext_ip="203.0.113.42"</strong> <span class="code-comment"># change me!</span>
+
+<span class="code-comment"># vpn interface</span>
+<strong>vpn_if="tun0"
+vpn_net = "10.8.0.0/24"</strong>
+
+<span class="code-comment"># port on which sshd is running</span>
+ssh_port = "55022"
+
+<span class="code-comment"># allowed inbound ports (services hosted by this machine)</span>
+inbound_tcp_services = "{auth, http, https, " $ssh_port ", <strong>openvpn</strong> }"
+inbound_udp_services = "{dhcpv6-client, <strong>openvpn</strong>}"
+
+<span class="code-comment"># politely send TCP RST for blocked packets. The alternative is</span>
+<span class="code-comment"># "set block-policy drop", which will cause clients to wait for a timeout</span>
+<span class="code-comment"># before giving up.</span>
+set block-policy return
+
+<span class="code-comment"># log only on the external interface</span>
+set loginterface $ext_if
+
+<span class="code-comment"># skip all filtering on localhost</span>
+set skip on lo
+
+<span class="code-comment"># reassemble all fragmented packets before filtering them</span>
+scrub in on $ext_if all fragment reassemble
+
+<span class="code-comment"># route traffic from VPN interface out to the internet</span>
+<strong>nat on ! $vpn_if from $vpn_net to any -&gt; $ext_ip</strong>
+
+<span class="code-comment"># block forged client IPs (such as private addresses from WAN interface)</span>
+antispoof for $ext_if
+
+<span class="code-comment"># default behavior: block all traffic</span>
+block all
+
+<span class="code-comment"># all traffic through VPN interface is assumed to be safe</span>
+<strong>pass quick on $vpn_if</strong>
+
+<span class="code-comment"># allow all icmp traffic (like ping)</span>
+pass quick on $ext_if proto icmp all
+pass quick on $ext_if proto icmp6 all
+
+<span class="code-comment"># allow incoming traffic to services hosted by this machine</span>
+pass in quick on $ext_if proto tcp to port $inbound_tcp_services
+pass in quick on $ext_if proto udp to port $inbound_udp_services
+
+<span class="code-comment"># allow all outgoing traffic</span>
+pass out quick on $ext_if</pre>
+
+  <p>Reload PF for these changes to take effect (you may want to do this from a serial console in case you
+  messed something up):
+
+<pre>pfctl -f /etc/pf.conf</pre>
+
+  <p>Tell the kernel to enable packet forwarding in order to support NAT:
+
+<pre>sysctl net.inet.ip.forwarding=1</pre>
+
+  <p>One last thing: since your server will now be forwarding packets, <a href="https://wiki.freebsd.org/10gFreeBSD/Router#Disabling_LRO_and_TSO">you must disable hardware offloading on your network card to avoid nasty issues</a>:
+
+<pre><span class="code-comment"># replace vtnet0 with your external network interface</span>
+ifconfig vtnet0 -tso -lro</pre>
+
+  <p>To make these changes permanent, make the following changes in <span class="monospace">/etc/rc.conf</span>:
+
+<pre><div class="code-title">/etc/rc.conf</div><span class="code-comment"># disable TSO and LRO on your primary NIC when routing packets</span>
+ifconfig_vtnet0="inet 203.0.113.42 netmask 255.255.255.0 <strong>-tso -lro</strong>"
+
+<span class="code-comment"># enable packet forwarding</span>
+gateway_enable="YES"</pre>
+  
+</section>
+
+<section>
+  <h2>Provisioning Your VPN Clients</h2>
+
+  <p>For clients to connect to your VPN server, they will need a client configuration file (usually with an
+  <span class="monospace">.ovpn</span> extension) and a certificate key pair signed by your VPN's CA. You'll
+  have to generate these files on your server and provide them to your clients out of band. I usually
+  just put the files in a tarball and email them, but you might have more stringent security requirements.
+  Proceed accordingly.
+
+  <p>The client configuration file will be the same for all clients, so let's start with that first. Create a
+  file called <span class="monospace">client.conf</span> in OpenVPN's configuration directory. Most of the
+  options in this file will mimic your configuration in <span class="monospace">openvpn.conf</span>.
+
+<pre><div class="code-title">/usr/local/etc/openvpn/client.conf</div>client
+
+dev tun
+proto udp
+
+<span class="code-comment"># FQDN of your VPN server</span>
+remote vpn.example.com 1194 <span class="code-comment"># change me!</span>
+
+<span class="code-comment"># let clients use any random port on their side</span>
+nobind
+
+ca ca.crt
+cert client.crt
+key client.key
+
+<span class="code-comment"># No need to set block cipher manually anymore - OpenVPN 2.4+ automatically</span>
+<span class="code-comment"># negotiates AES-256-GCM. Uncomment if you use older clients that default</span>
+<span class="code-comment"># to insecure ciphers.</span>
+<span class="code-comment"># cipher AES-256-CBC</span>
+
+<span class="code-comment"># keep trying to resolve remote hostname indefinitely</span>
+resolv-retry infinite
+
+<span class="code-comment"># reuse resources between invocations</span>
+persist-key
+persist-tun
+
+<span class="code-comment"># WLANs produce a lot of duplicate packets - mute this warning</span>
+mute-replay-warnings
+
+<span class="code-comment"># verify remote certificate</span>
+remote-cert-tls server
+
+<span class="code-comment"># log level 0-9</span>
+verb 3
+
+<span class="code-comment"># silence repeated messages</span>
+mute 10
+
+<span class="code-comment"># uncomment the following line if you're using LDAP authentication</span>
+<span class="code-comment"># auth-user-pass</pre></span>
+
+  <p>Now you need to create a client certificate. You'll need a different certificate for each device you
+  want to connect to the VPN, because a single certificate cannot be used for multiple simultaneous connections.
+  In this example, we'll create a certificate called <span class="monospace">macbook</span> for my $2000 <span class="monospace">ssh</span> machine.
+
+<pre>cd /usr/local/etc/openvpn/easy-rsa
+
+<span class="code-comment"># Generate a client keypair for "macbook" - you will need to provide the CA</span>
+<span class="code-comment"># password you specified last time.</span>
+./easyrsa.real build-client-full macbook nopass</pre>
+
+  <p>Note the <span class="monospace">nopass</span> option used here—since I'm additionally using password authentication
+  via LDAP, I don't see a need to encrypt the certificate with a password. If you aren't using password authentication, you probably
+  want to have your clients generate their own private key and send you a Certificate Signing Request. You can read about that
+  process in <a href="https://github.com/OpenVPN/easy-rsa/blob/master/README.quickstart.md">the Easy-RSA documentation</a>.
+
+  <p>Anyway, the <span class="monospace">macbook</span> key pair is now located in the <span class="monospace">pki</span> directory
+  on the server. Now we need to shuffle some filenames around and generate a tarball so I can get the configuration onto my MacBook.
+
+<pre>CLIENT=macbook
+SERVER=vpn.example.com <span class="code-comment"># change me!</span>
+
+mkdir /tmp/${CLIENT}
+cp pki/ca.crt /tmp/${CLIENT}/ca.crt
+cp pki/issued/${CLIENT}.crt /tmp/${CLIENT}/client.crt
+cp pki/private/${CLIENT}.key /tmp/${CLIENT}/client.key
+cp ../client.conf /tmp/${CLIENT}/${SERVER}.ovpn
+chmod 644 /tmp/${CLIENT}/*
+tar cvzf /tmp/${CLIENT}.tar.gz /tmp/${CLIENT}
+rm -rf /tmp/${CLIENT}</pre>
+
+  <p>A tarball with the server's CA certificate, the client key pair, and the client configuration file for <span class="monospace">macbook</span>
+  is now located at <span class="monospace">/tmp/macbook.tar.gz</span>. You can then <span class="monospace">scp</span> (or worse, email) this file to the client machine and
+  fire up your OpenVPN client. On macOS, I'm a big fan of <a href="https://tunnelblick.net">Tunnelblick</a>. Just double-click the <span class="monospace">.ovpn</span>
+  file and Tunnelblick will automatically import your VPN profile.
+  
+  <p>As of this writing, there is currently one small change to make in Tunnelblick: edit your VPN profile and change <em>OpenVPN version</em> to <em>Latest (2.4.4)</em>.
+  This allows you to use the more secure GCM cipher. In future versions of Tunnelblick, this step may be unnecessary.
+
+  <p>After that, you can connect to your VPN server and start browsing. You can verify your traffic is being tunneled through the VPN by checking your external public IP address
+  (I use <a href="http://icanhazip.com">icanhazip.com</a>). If you run into any issues, check the OpenVPN logs on your client and server. 
+  To troubleshoot, try pinging a public IP address (like <span class="monospace">8.8.8.8</span>), as well as your own server (<span class="monospace">10.8.0.1</span>).
+  If you can ping locally but can't ping out to the internet, it's most likely a firewall or routing issue.
+</section>
+
+<section>
+  <h2>Conclusion</h2>
+
+  <p>A VPN is a must-have tool to protect your privacy, especially when using a sketchy public network. It also provides a reliable and convenient way
+  to securely access your personal "intranet" from anywhere in the world.
+  
+  <p> Recent versions of OpenVPN have a very small resource footprint, making it
+  suitable for use on a VPS. When maxing out my server's internet connection with a speed test, OpenVPN delivered 85 mbps while using only
+  50% of a single CPU core. With typical traffic, system load is minimal.
+  
+  <p>As always, contact me via <a href="mailto:cullum@c0ffee.net">email</a> or ping me on <a href="https://twitter.com/cullumsmith">Twitter</a>
+  with any questions or issues you have.
+</section>

blog/self-hosting-guide/index.tmpl

@@ -0,0 +1,122 @@
+TITLE='A Guide to Self-Hosting Your Online Services'
+DESCRIPTION='Take charge of your data by self-hosting email, chat, file sync, and more.'
+DATE=2016-12-31
+__HTML__
+<p>In a post-<a href="https://en.wikipedia.org/wiki/PRISM_(surveillance_program)">PRISM</a> world, you've
+probably accepted the fact that the NSA, CIA, or some other
+three-letter agency will read your email, text messages, smartphone
+pictures, and basically anything else you send over the internet. And if it's not the government
+spying on you, it will be some monolithic corporation like Google or Facebook eager to catalog
+every minutia of your digital life so they can sell it to whatever advertising company comes along.
+
+<p>Many of the digital protocols in use today—such as email, XMPP, and CalDAV—were originally
+designed with self-hosting in mind. In ages past, universities, large companies, and even some nerdy
+individuals hosted their own mail servers and the like. It's only recently that we have traded our
+privacy for the walled-garden convenience of letting advertising companies handle all our data. Every
+online service costs some amount of money to operate, so <em>if you aren't paying for it, then you
+are the product.</em>
+
+<p>In this guide, I will share the steps I have taken to take back my family's digital privacy.
+By self-hosting online services like email, chat, file synchronization, calendar/contacts sync, and
+more, <em>you</em> can be the master of your data—and most of the time, your homegrown solution
+will work better than proprietary alternatives. All it takes is a little work, and I've already
+done the hard part for you.
+
+<p><strong>The downside:</strong> it takes time and effort to get this stuff up and running. It's
+fairly set-and-forget once you've configured everything, but you're essentially signing up to be
+your own Systems Administrator. Nerds and techies will probably view it as a fun side project, but
+it's definitely not for everyone.
+
+<section>
+  <h2 id="requirements">What You'll Need</h2>
+
+  <ul class="paragraph-list">
+    <li><strong>A domain name:</strong> you will need a personal domain name to access your digital world.
+    I use <a href="https://www.c0ffee.net/">c0ffee.net</a> (obviously), but you will need to
+    register your own at one of the numerous domain registrars. I've always been happy with
+    <a href="https://www.namecheap.com/?aff=108349">Namecheap</a>.
+
+    <li><strong>A hosting provider:</strong> you will need a server somewhere to host all your
+    services. For most people hosting email, chat, and maybe a blog for their immediate friends or
+    family, a VPS is more than adequate. If you plan to have 100+ users or want to store terabytes of
+    music or backups, a dedicated sever may be a more cost-effective option.
+
+    <p>I'm a <a href="https://www.freebsd.org/">FreeBSD</a> guy, so I use
+    <a href="https://arpnetworks.com/">ARP Networks</a> for my hosting.  But I have used
+    <a href="https://www.linode.com/">Linode</a>,
+    <a href="https://www.digitalocean.com/">DigitalOcean</a>, and
+    <a href="https://www.vultr.com/">Vultr</a>
+    in the past and been happy with them.
+
+    <p>If you have an awesome home internet connection and a static IP address, you may be able to
+    get away with using a server in your house. However, many ISPs block certain ports—almost all of them
+    block port 25 for example—making hosting a mail server impossible. In addition,
+    most major email providers will reject mail from residential IP addresses due to spammers. For the
+    smoothest experience, nothing is going to beat a dedicated server or VPS in a colocation facility.
+
+    <li><strong>Some DevOps skills:</strong> you will need to be familiar with Unix/Linux, as well
+    as some basics in networking. If you've ever installed Linux, set up a webserver, or built a package
+    from source, you probably know enough to make it through. But be careful, you may end up learning
+    enough to make this your career (like me)!
+  </ul>
+</section>
+
+<section>
+  <h2 id="security">Some Notes on Security</h2>
+
+  <p>Along the way, I will point out some common-sense security measures you can take to keep
+  government agents and attackers from pwning your system. However, only you can judge
+  the security requirements and risk tolerance for your circumstances. The advice I give you may
+  prevent a script kiddie from brute-forcing your password, but it's unlikely to prevent a state-sponsored
+  actor from exploiting a zero-day in Postfix to gain access to your system. Ultimately, as long as your
+  server is hosted off-site, you are trusting <em>someone</em> with your data.
+
+  <p>Friends of mine have often asserted that my self-hosting efforts are futile, because (1) the government
+  can probably crack most encryption protocols, and (2) most communication goes to someone else using Gmail
+  or Facebook, etc. To this I have the following replies:
+
+  <ol class="paragraph-list">
+    <li>Our current situation will never get any better if we continue to hand our private data to
+    governments and corporations on a silver platter. With NSA programs like
+    <a href="https://en.wikipedia.org/wiki/XKeyscore">XKeyscore</a>, our government has a search
+    engine for our private data in Gmail. At least by hosting my own services, I can make their unlawful
+    surveillance a little more difficult.
+
+    <li>I do not want my private emails or chat messages scraped in order to facilitate more effective
+    advertisements. I wouldn't let a random corporation go through my postal mail, email is no different.
+
+    <li>I do not want to be dependent on the whims of a corporation for the services I depend on. Consider
+    <a href="https://makeawebsitehub.com/the-google-product-murders/">this list</a> of discontinued Google
+    products. Google may have
+    <a href="https://googleblog.blogspot.com/2013/03/a-second-spring-of-cleaning.html">canned Google Reader</a>,
+    but my <a href="https://tt-rss.org/">Tiny Tiny RSS</a> instance is still chugging along.
+
+    <li>It is my hope that by documenting my efforts here, we may be one step closer to an automated,
+    open-source solution for average users to host their own online services.
+
+    <li>I actually enjoy tinkering with self-hosted software. It's a fun hobby, and it often provides better
+    features than the proprietary alternatives.
+  </ol>
+
+  <p>With that out of the way, let's get to the guide!
+</section>
+
+<section>
+  <h2 id="configuration">Configuring Your Own Digital Empire</h2>
+
+  <p>The following links will become available as I get time to write these blog posts. I'll take you through
+  how I've set up each of the services below. I'm running everything on a FreeBSD server, so the instructions will be from
+  a BSD perspective. They should work equally well for most Linux distros with some minor tweaks.
+  <ul>
+    <li><a href="/blog/freebsd-server-guide/">Configuring a FreeBSD Server: Initial Setup and Tuning</a>
+    <li><a href="/blog/dns-hidden-master/">DNS: Running BIND as a Hidden Master with DNSSEC</a>
+    <li><a class="disabled">NGINX: Configuring a Secure, Performant Web Server</a>
+    <li><a class="disabled">LDAP: Single-Sign-On for All Your Services</a>
+    <li><a href="/blog/mail-server-guide/">Email: A Modern Stack using Postfix, Dovecot, Rspamd, Solr, and LDAP</a>
+    <li><a class="disabled">Chat: Text, Voice, and Video Chat with Matrix</a>
+    <li><a class="disabled">File Sync: Keeping Files Synchronized Across Your Devices Using Syncthing</a>
+    <li><a href="/blog/openvpn-guide/">VPN: Secure, Private Browsing Using OpenVPN</a>
+    <li><a class="disabled">Music: A Self-Hosted Spotify Replacement Using Madsonic and DSub</a>
+    <li><a class="disabled">IRC: Stay Connected with ZNC</a>
+  </ul>
+</section>

blog/unifi-cloud-key-ssl-certificate/index.tmpl

@@ -0,0 +1,87 @@
+TITLE='Unifi Cloud Key: Custom SSL Certificate'
+DESCRIPTION='Eliminate annoying HTTPS warnings with your own valid SSL certificate.'
+DATE=2017-11-05
+__HTML__
+<p>On my home network, I have a <a href="https://www.pfsense.org">pfSense box</a> as a gateway for a few
+<a href="https://www.ubnt.com">Ubiquiti</a> switches and access points. Ubiquiti makes great networking
+gear for small- to medium-sized deployments. You can control all your Ubiquiti products using
+the Unifi Controller app, which you can run on any computer on your network.
+
+<p>If you don't have a dedicated server to use as the Unifi Controller, or you just want something with a
+smaller footprint, Ubiquity provides a small, POE-powered device called the <a href="https://www.ubnt.com/unifi/unifi-cloud-key/">Cloud Key</a>
+which you can use as the Controller for your network. It's kind of like a Raspberry Pi, but comes with all
+the Ubiquity controller software preinstalled.
+
+<p>To use the Cloud Key, you just plug it into your switch, figure out it's IP address, and point your web
+browser there. Of course, not knowing where it's going to be deployed, the Cloud Key just presents a self-signed
+HTTPS certificate by default—causing modern browsers to emit all kinds of draconian warning messages. I have a
+DHCP mapping and hostname configured for the Cloud Key in pfSense, so I can reach it from my home network by
+going to <span class="monospace">cloudkey.c0ffee.net</span>. I also have a wildcard SSL
+certificate from Comodo. So I thought to myself, "I'll just copy my certificate over to the Cloud Key, change a
+setting somewhere, and I can get rid of that stupid error message!"
+
+<p>Unfortunately, this was such a royal pain that I decided to document the necessary steps so that the next poor
+soul that attempts this doesn't waste as much of the his life in the process as I did.
+
+<section>
+  <h2>Parting the Clouds</h2>
+  
+  <p>In the instructions below, I'm going to assume you have a certificate pair for <span class="monospace">example.com</span>,
+  and your Cloud Key is located at <span class="monospace">cloudkey.example.com</span>. You will also need the root certificate (as
+  well as any intermediate certificates) for your certificate authority concatenated into a single file. The intermediate
+  certificate should be placed <em>before</em> the root certificate. I'm going to assume you named this file <span class="monospace">chain.crt</span>.
+
+  <p>First, copy the certificates to the Cloud Key. The root password should be the same one you use to log into the web interface.
+
+<pre>scp chain.crt example.com.{crt,key} root@unifi.example.com:</pre>
+
+  <p>SSH to your Cloud Key:
+
+<pre>ssh root@unifi.example.com</pre>
+
+  <p>Now, the fun begins.
+
+<pre>
+<span class="code-comment"># stop the unifi web service</span>
+service unifi stop
+
+<span class="code-comment"># backup the default certificate</span>
+mkdir backup
+cp -r /etc/ssl/private/ backup
+
+<span class="code-comment"># remove the default SSL bundle</span>
+rm /etc/ssl/private/cert.tar
+
+<span class="code-comment"># MAGIC - discovered through random forum posts, wailing, and gnashing </span>
+<span class="code-comment"># of teeth</span>
+openssl pkcs12 -export -in example.com.crt -inkey example.com.key -out example.com.p12 -name unifi -CAfile chain.crt -caname root
+keytool -importkeystore -deststorepass aircontrolenterprise -destkeypass aircontrolenterprise -destkeystore /usr/lib/unifi/data/keystore -srckeystore example.com.p12 -srcstoretype PKCS12 -srcstorepass aircontrolenterprise -alias unifi
+cp example.com.crt /etc/ssl/private/cloudkey.crt
+cp example.com.key /etc/ssl/private/cloudkey.key
+rm /etc/ssl/private/ssl-cert-snakeoil.key
+chown root:ssl-cert /etc/ssl/private/*
+chmod 640 /etc/ssl/private/*
+tar -cvf cert.tar *
+chown root:ssl-cert cert.tar
+chmod 640 cert.tar
+service nginx restart
+
+<span class="code-comment"># NOTE: if you have an ECC certificate like me, you must also complete</span>
+<span class="code-comment"># the following magic incantations.</span>
+<span class="code-comment"># (if you don't know what an ECC certificate is, just ignore this part.)</span>
+<span class="code-comment">#</span>
+<span class="code-comment"># echo "unifi.https.sslEnabledProtocols=TLSv1.2" &gt;&gt; /usr/lib/unifi/data/system.properties</span>
+<span class="code-comment"># echo "unifi.https.ciphers=TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384,TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256" &gt;&gt; /usr/lib/unifi/data/system.properties</span>
+
+<span class="code-comment"># finally, restart the unifi service</span>
+service unifi start
+</pre>
+
+  <p>After that, you should be able to access the Cloud Key using your existing SSL certificate. You should
+  change your "Controller Hostname/IP" in the Unifi controller settings to your FQDN (<span class="monospace">cloudkey.example.com</span>, in this case).
+  I also changed my "Device Name" in the Cloud Key settings to <span class="monospace">cloudkey</span> for consistency.
+  
+  <p>Now, join me in complaining to Ubiquiti that this isn't possible to accomplish in the Cloud Key's web interface.
+
+</section>
+

css/style.css

@@ -0,0 +1,241 @@
+body {
+   color: #333;
+   line-height: 1.4;
+   margin: 2em auto;
+   max-width: 38em;
+   padding: 0 1em;
+}
+
+h1,h2,h3,h4,h5 {
+   line-height: 1.2;
+}
+
+header {
+  margin-bottom: 2em;
+}
+
+header p {
+  margin-top: -1em;
+}
+
+nav {
+  display: inline;
+}
+
+nav a:before {
+  content: "‹ ";
+}
+
+footer {
+  padding: .5em 0;
+  display: flex;
+  justify-content: space-between;
+  align-items: center;
+}
+
+hr {
+   background: #333;
+   border: 0;
+   height: 1px;
+}
+
+a {
+   text-decoration: none;
+}
+
+a:hover {
+   text-decoration: underline;
+}
+
+ul {
+   list-style-type: square;
+}
+
+pre {
+  background-color: #f5f5f5;
+  border: 1px solid #ccc;
+  border-radius: 2px;
+  color: #333;
+  font-family: monospace;
+  line-height: 1.2;
+  margin: 0 0 10px;
+  overflow-x: auto;
+  padding: 8px;
+  white-space: pre;
+  word-wrap: normal;
+}
+
+footer .author {
+  font-style: italic;
+}
+
+.photo-panel {
+   margin: 2em 0;
+   overflow: auto;
+}
+
+.photo-panel ul {
+  display: inline-block;
+  list-style-position: inside;
+  margin: 0;
+  padding-left: 0;
+}
+
+.photo-panel img {
+  float: left;
+  height: 150px;
+  margin-right: 1.5em;
+  width: 150px;
+}
+
+.post-list {
+  margin-bottom: 10px;
+}
+
+.post-list .date {
+  width: 6em;
+}
+
+.paragraph-list li {
+  margin: 1em 0;
+}
+
+.disabled {
+  color: #ccc;
+}
+.disabled a:hover {
+   text-decoration: none;
+}
+
+.posted-on {
+  float: right;
+}
+
+.code-title {
+  border-bottom: 1px solid #333;
+  font-family: sans-serif;
+  font-size: 80%;
+  font-weight: bold;
+  margin-bottom: .8em;
+}
+
+.monospace {
+  font-family: monospace;
+}
+
+.blog img {
+  width: 100%;
+  margin: 1em 0 0 0;
+}
+
+.code-comment {
+  font-style: italic;
+  color: #888;
+}
+
+.license {
+  font-size: 80%;
+}
+
+.license img {
+  vertical-align: middle;
+}
+
+/* * resume * */
+.resume .section-heading {
+  border-bottom: solid 1px;
+}
+
+.resume .header {
+  margin-bottom: 2em;
+}
+
+.resume .name {
+  margin-bottom: 0;
+  text-align: center;
+}
+
+.resume .profession {
+  margin: .5em 0;
+  text-align: center;
+}
+
+.resume .homepage, .resume .date, .resume .university, .resume .location {
+  float: right;
+}
+
+.resume .education .date {
+  font-style: italic;
+}
+
+.resume .degree, .resume .university, .resume .employer, .resume .title {
+  font-weight: bold;
+}
+
+.resume .location {
+  font-style: italic;
+}
+
+.resume .description > ul {
+  padding-left:1.2em;
+  margin-top: 0;
+}
+
+.resume .summary .description {
+  font-size: 95%;
+}
+
+.resume .experience .description {
+  font-size: 95%;
+  margin: .25em 0 1em 0;
+}