Running a Pandoc build on Vercel
For the last year or so I have been maintaining my CV/Resume as a series of Markdown files stored in git. These files are then combined into a full document and output into html, pdf, docx using pandoc.
I was performing the build and publication of updates to the document manually, but as is typical of a software engineer I wanted something with a bit less friction which didn’t prevent me from making changes due the amount of work involved.
Enter Vercel - automated serverless static website publishing triggered from git commits. The process is pretty simple:
- Tell Vercel what repository and branch to monitor (in my case, GitHub)
- Tell it how to build
- Tell it where the output goes
- Setup a custom domain
Vercel has a lot of build presets, but unless you are doing something very basic you will need to override the standard build settings. This is certainly the case with Pandoc. Vercel runs on AWS and the build images are Amazon Linux 2 and use yum package management but the repositories and standard build image is very light. The suggestion to use EPEL is fair but it contains an outdated version of Pandoc.
This is how I got everything to hang together and build on Vercel. First, setup the EPEL repository as it does contain some packages we need. Then install some dependencies. In my case I am using wkhtmltopdf to generate the PDF.
yum install https://dl.fedoraproject.org/pub/epel/epel-release-latest-7.noarch.rpm
yum install wkhtmltopdf
Now we need to install a recent version of Pandoc manually from their release repository, as the version in EPEL is only 1.x at the time of writing.
yum install wget
mkdir pandoc
wget -qO- https://github.com/jgm/pandoc/releases/download/2.11.1.1/pandoc-2.11.1.1-linux-amd64.tar.gz | \
tar xvzf - --strip-components 1 -C ./pandoc
export PATH="./pandoc/bin:$PATH"
wkhtmltopdf requires an X server, so in this case we can run it when we run wkhtmltopdf by wraping it in a shell script that starts the virtual X server prior to wkhtmltopdf being called and create a symlink so the shell script is run when wkhtmltopdf is invoked.
printf '#!/bin/bash\nxvfb-run -a --server-args="-screen 0, 1024x768x24" /usr/bin/wkhtmltopdf -q $*' \
> /usr/bin/wkhtmltopdf.sh
chmod a+x /usr/bin/wkhtmltopdf.sh
ln -s /usr/bin/wkhtmltopdf.sh /usr/local/bin/wkhtmltopdf
Now all the pieces are in place you can run a pandoc build to generate your document.
Running IBM’s Really Small Message Broker on Windows
Since getting a CurrentCost CC128 “smart” electricity meter a few weeks ago the hacker in me has had a resurgence and I have started writing hobby-code again on top of my day job. There seems to be a small industry of software for interacting with these smart meters, and publishing and recording the data to various sources such as Pachube that allow you to share your electricity consumption data with others. At the consumer/home level things seem to still be targeting tinkerer’s like myself, rather than the general consumer. Most of the tools seem to be centered around the linux and java community, which is all well and good, but why can’t us Microsoft .Net folks get in on some of the action.
Microsoft’s Windows Home Server is a perfect platform to act as a hub for this type of stuff. It’s designed to be always on, with an add-in model that allows extensions, so I decided to embark on using my HP MediaSmart EX470 to publish the CC128 sensor data in a variety of ways.
As part of IBM’s work surrounding telemetry and sensor messaging they have made, freely available, what they are calling a “nano broker”, the Really Small Message Broker (RSMB). This broker talks the Message Queue Telemetry Transport (MQTT) protocol, designed again, by IBM (the brainchild of Andy Stanford-Clark, IBM Master Inventor and illustrious enough to have his own wikipedia page). The idea is that you can publish data on a specific Topic to the RSMB via MQTT, and the RSMB will then distribute that data to any “client” that is subscribed to that topic. Being IBM, the code is primarily targeted at the linux community, however they are also nice enough to provide a Windows console application binary.
Getting a console application to run when Windows Home Server boots is not as simple as putting it in the Start menu, or in one of the myriad of “Run” registry sections. Fortunately, Microsoft provides two executables, instsrv.exe (service installer) and srvany.exe (run any program as a service) as part of the Windows Server 2003 Resource Kit, and these can be used to run any program as a service, which means that you can get IBM’s RSMB running at server boot without having to have a user logon session.
The following steps will allow you to run the RSMB on Windows Home Server so that it starts up at server boot. These instructions assume you have installed the Windows Server 2003 Resource Kit in the standard location, and you have unzipped the RSMB to C:\RSMB. Alter the instructions for your paths if they vary. You’ll have to do all this by logging onto the server using the remote desktop client, not the standard windows home server console.
1. Use InstSvc.exe to install an SvrAny.exe based service.
32bit Windows Server (ie, HP MediaSmart EX470 etc)
"C:\Program Files\Windows Resource Kits\Tools\instsrv" RSMB "C:\program files\Windows Resource Kits\Tools\srvany.exe"
64bit Windows Server
"C:\Program Files (x86)\Windows Resource Kits\Tools\instsrv" RSMB "C:\program files (x86)\Windows Resource Kits\Tools\srvany.exe"
2. Alter the registry to let SrvAny.exe know that it should run the broker.
Note the important part here is setting the AppDirectory, without which the RSMB will mysteriously start and then immediately stop because it can’t find it’s Messages file.
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\RSMB\Parameters] "Application"="C:\\rsmb\\broker.exe" "AppDirectory"="C:\\rsmb\\"
That’s all there is to it. If you go into Computer Manager and the services browser, you should be able to start the RSMB service and the broker will be running silently in the background. You can check this out by looking at Task Manager, Processes Tab, where you will see both the SrvAny.exe and Broker.exe processes. You can also run netstat -an in a powershell or cmd.exe window to check that the server is listening on port 1883.
The only thing that you should do on top of this is to change the service to run with a non administrative account with locked down settings (read/write access to the RSMB folder and the ability to listen to connections on port 1883 should do the trick).
Updated to WP 2.7 in preparation for server move
Thats all 
Nothing fancy.
Looks like I messed up doing the upgrade by copying over old images etc. So be it, I’ll be starting a-fresh on the new server.