Wiki.js fails to render inline equations

I have been playing with Wiki.js, I happened to notice that some math was not getting rendered correctly. Wiki.js uses Katex to render Latex (like) math expressions. I wanted to produce an unordered list of equations like this,

  • \braket{v_i|v_i} = 1 because we are dealing with a unit vector
  • \braket{v_1|v_2}=\braket{v_2^*|v_1^*}
  • \braket{v_1\vert(a\vert v_2}+b\ket{v_3})=a\braket{v_1\vert v_2}+b\braket{v_1\vert v_3}

The markdown to do this looks like

* $\braket{v_i|v_i} = 1$ because we are dealing with a unit vector
* $\braket{v_1|v_2}=\braket{v_2^*|v_1^*}$
* $\braket{v_1\vert(a\vert v_2}+b\ket{v_3})=a\braket{v_1\vert v_2}+b\braket{v_1\vert v_3}$

On the preview pane it looked fine but on the actual wiki page it was being rendered like this

  • \braket{v_i|v_i} = 1 because we are dealing with a unit vector
  • \braket{v_1|v_2}=\braket
  • \braket{v_1\vert(a\vert v_2}+b\ket{v_3})=a\braket{v_1\vert v_2}+b\braket

It turns out that there needs to be text after the closing $ symbol. Adding just a “.” to the end of each line fixed it and the rendering worked fine.

JUNOS DHCPv6 DNS Search List

I have been looking at the DHCPv6 server in JUNOS 15.1X49-D160.2. It is easy enough to setup Note: Step 5 is wrong, the first two instructions should have dhcpv6 as the last argument e.g.

set security zones security-zone untrust interfaces ge-0/0/0.0 host-inbound-traffic system-services dhcpv6

It would be nice to configure the DNS Search List option. The option code for this is 24. So I tried this

set access address-assignment pool my-pool family inet6 dhcp-attributes option 24 array string [ "" "" ]

but it didn’t work. There appears to be no examples of how to do this correctly so after reading RFC3315 section 8 and RFC1035 section 3.1 I realised it had to be in uncompressed wire format like this

set access address-assignment pool my-pool family inet6 dhcp-attributes option 24 array hex-string [ "0773696e6f64756e03636f6d00" "04697076340773696e6f64756e03636f6d00" ]

which IMHO is not the easiest way to configure things.

Comparing drill output

I wanted to compare the output of multiple drill queries. After a bit of trial error, I came up with this sed to remove the parts of drlll’s output that change from query to query.

drill | grep -v "Query time" | grep -v WHEN 
        | sed 's/t[[:digit:]]{1,}t|,sid.{1,}$//'

FreeBSD with new xorg 1.12.X

A while ago I switched my FreeBSD desktop to the new xorg 1.12.X. In ports this requires adding WITH_NEW_XORG=yes to /etc/make.conf.

I only found out today that for packages you need to add a file called /etc/pkg/FreeBSD-new-xorg.conf containing:

FreeBSD_new_xorg: {
 url: "pkg+${ABI}/new_xorg",
 mirror_type: "srv",
 signature_type: "fingerprints",
 fingerprints: "/usr/share/keys/pkg",
 enabled: yes

Re-installing everything to see if it is more stable

Patch to APC PowerChute Network Shutdown for Ubuntu

The following patch fixes the install script for Ubuntu 13.04

--- 2013-09-25 16:07:54.772107691 +0000
+++ 2013-09-26 12:05:46.214115186 +0000
@@ -1,4 +1,4 @@
 # PowerChute Network Shutdown v.3.0.1
@@ -22,6 +22,7 @@
@@ -288,6 +289,11 @@
 # We're a Linux derivative, decide which one.
 if [ -f /etc/vima-release ] || [ -f /etc/vma-release ]; then
+ elif [ -x /usr/bin/lsb_release ]; then
+ /usr/bin/lsb_release -i | grep Ubuntu > /dev/null
+ if [ $? -eq 0 ]; then
+ fi
 grep XenServer /etc/redhat-release > /dev/null 2>&1
 if [ $? -eq 0 ]; then
@@ -368,6 +374,11 @@
+ STARTUP=/etc/init.d/PowerChute
+ PCBE_STARTUP=/etc/init.d/PBEAgent
+ PCS_STARTUP=/etc/init.d/pcs
+ ;;
@@ -563,6 +574,9 @@
 /etc/rc.d/init.d/PowerChute stop
+ /etc/init.d/PowerChute stop
+ ;;
 /etc/rc2.d/S99PowerChute stop
@@ -977,6 +991,10 @@
 cp Linux/ notifier
 cp Linux/ shutdown
+ cp Linux/ notifier
+ cp Linux/ shutdown
+ ;;
 cp Solaris/ notifier
 cp Solaris/ shutdown
@@ -1057,6 +1075,14 @@
 rm -f /etc/rc.d/rc4.d/*99PowerChute
 rm -f /etc/rc.d/rc5.d/*99PowerChute
 rm -f /etc/rc.d/rc6.d/*99PowerChute
+ elif [ $OS = "$LINUX_UBUNTU" ] ; then
+ rm -f /etc/rc0.d/*99PowerChute
+ rm -f /etc/rc1.d/*99PowerChute
+ rm -f /etc/rc2.d/*99PowerChute
+ rm -f /etc/rc3.d/*99PowerChute
+ rm -f /etc/rc4.d/*99PowerChute
+ rm -f /etc/rc5.d/*99PowerChute
+ rm -f /etc/rc6.d/*99PowerChute
@@ -1069,6 +1095,14 @@
 elif [ -f /sbin/chkconfig ]; then
 chkconfig --add PowerChute
 chkconfig PowerChute on
+ elif [ $OS = "$LINUX_UBUNTU" ] ; then
+ ln -s /etc/init.d/PowerChute /etc/rc0.d/K99PowerChute
+ ln -s /etc/init.d/PowerChute /etc/rc1.d/K99PowerChute
+ ln -s /etc/init.d/PowerChute /etc/rc2.d/S99PowerChute
+ ln -s /etc/init.d/PowerChute /etc/rc3.d/S99PowerChute
+ ln -s /etc/init.d/PowerChute /etc/rc4.d/S99PowerChute
+ ln -s /etc/init.d/PowerChute /etc/rc5.d/S99PowerChute
+ ln -s /etc/init.d/PowerChute /etc/rc6.d/K99PowerChute
 ln -s /etc/rc.d/init.d/PowerChute /etc/rc.d/rc0.d/K99PowerChute
 ln -s /etc/rc.d/init.d/PowerChute /etc/rc.d/rc1.d/K99PowerChute
@@ -1120,6 +1154,14 @@
 if [ -f /sbin/chkconfig ]; then
 chkconfig PowerChute off
 chkconfig --del PowerChute
+ elif [ $OS = "$LINUX_UBUNTU" ] ; then
+ rm -f /etc/rc0.d/*99PowerChute
+ rm -f /etc/rc1.d/*99PowerChute
+ rm -f /etc/rc2.d/*99PowerChute
+ rm -f /etc/rc3.d/*99PowerChute
+ rm -f /etc/rc4.d/*99PowerChute
+ rm -f /etc/rc5.d/*99PowerChute
+ rm -f /etc/rc6.d/*99PowerChute
 rm -f /etc/rc.d/rc1.d/K99PowerChute
 rm -f /etc/rc.d/rc2.d/S99PowerChute

Juniper SRX mucking with DNS

I was getting some strange DNS answers on the servers in a trust zone on my SRX. All the servers are statically NAT’d to external IP’s and run their own caching resolvers but when I tried to query for the servers A RR I kept getting the internal IP address. No name server either internal or external was serving that A RR. Eventually I realised that it was the SRX changing the answer section of the DNS response. I don’t know if it is on by default, or if I switched it on by mistake but it was the DNS Application Layer Gateway (ALG) trying to help by making use of what it knew about the static NATs. Switching DNS ALG off solved the issue. For a detailed description of what the ALG does see the Junos OS Security Configuration Guide.

FreeBSD svn and passwords

I have been getting the message about storing un-encrypted svn passwords for ages on FreeBSD and Ubuntu. I finally thought I would look into how you store encrypted passwords.

ATTENTION! Your password for authentication realm:
<> Sinodun Projects Subversion Repository
can only be stored to disk unencrypted! You are advised to configure
your system so that Subversion can store passwords encrypted, if
possible. See the documentation for details.
You can avoid future appearances of this warning by setting the value
of the 'store-plaintext-passwords' option to either 'yes' or 'no' in

Lots of goggling later the best I could find was an article about gnome-keyring-daemon and subversion which mentions the need for A quick search found this was missing on my system. A moment of dumbness later I remembered make config and found the port config option needed.


re-installing the port unfortunately broke svn with the following message:

svn: E175002: OPTIONS of '': SSL handshake failed: SSL disabled due to library version mismatch (

Thanks to this that was quickly fixed by rebuilding neon:

sudo portupgrade -f neon*

Flush DNS cache on Ubuntu

This weekend I came across several pages on the web suggesting ways to flush the DNS cache on Ubuntu. I will not point to the offending pages here but they are easy to find with Google. Most of them are wrong in several ways.

  1. Ubuntu doesn’t install a DNS cache by default
  2. Most of the pages say something along the lines of to flush the DNS cache you need to restart the nscd deamon.
  3. See 1
  4. As a result of 1 – They tell you to install nscd so that you can then restart nscd!
  5. I redirect your attention to issue 1.

If you really want a local cache then I would suggest installing unbound which will work better and give you DNSSEC as well.

Ubuntu, efi booting and Nvidia

I have just set up a Ubuntu 12.10 workstation on a new motherboard (ASUS P8Z77 WS) which has efi instead of the traditional BIOS and installed a NVidia Quadro 600 graphics card.

You can ignore the efi and install your OS as standard if you want. The efi provides BIOS compatibility. However, that would be too easy!

efi booting

Getting the Ubuntu DVD to install in efi booting mode is easy. With the DVD in the drive the efi sees both a efi and regular version of the DVD. Just set the boot order to start with the efi version of the DVD, you get a text display with several options including one to install Ubuntu. At the end of the install Grub2 is installed and configured to support efi booting. You may need to update the efi firmware to get the newly installed Ubuntu to boot.

Nvidia drivers

There is some mention on the web that the nvidia drivers may not work with efi booting. If you rely on Ubuntu to do the correct thing when you apt-get install nvidia-current then you might think that is correct. However, after a bit of investigation, they work fine for me. The major problem is that the Nouveau display driver is getting control of the card before the nvidia one does. You can see which driver is loaded by using

lspci -v

You will get output like this (This example is after fixing things, the “Kernel driver in use” line shows nouveau by default)

04:00.0 VGA compatible controller: NVIDIA Corporation GF108GL [Quadro 600] (rev a1) (prog-if 00 [VGA controller])
 Subsystem: NVIDIA Corporation Device 0835
 Flags: bus master, fast devsel, latency 0, IRQ 16
 Memory at f6000000 (32-bit, non-prefetchable) [size=16M]
 Memory at e8000000 (64-bit, prefetchable) [size=128M]
 Memory at f0000000 (64-bit, prefetchable) [size=32M]
 I/O ports at e000 [size=128]
 [virtual] Expansion ROM at f7000000 [disabled] [size=512K]
 Capabilities: <access denied>
 Kernel driver in use: nvidia
 Kernel modules: nvidia, nouveau, nvidiafb

You can remove the offending Xorg driver like this:

sudo apt-get --purge remove xserver-xorg-video-nouveau

However that doesn’t actually remove the nouveau kernel module. A quick fix is to:

sudo rm -rf /lib/modules/3.5.0-18-generic/kernel/drivers/gpu/drm/nouveau

and then rebuild the initramfs

sudo update-initramfs -u

This final command is important as it removes the offending driver from the boot ram disk.