Example post

sup guys

Test post number 3






Wercing with better Markdown

For a while now, I've been running a few sites on werc, the sane web anti-framework. While it's a very nice, minimal, and visually attractive setup, I've run into a few problems, one being the default markdown processor. While there isn't really a problem with the default markdown rendering script, it lacks several popular features of GitHub's markdown implementation, which many take for granted. One such feature is the ability to specify blocks of code.

Werc's documentation isn't very thorough, but I doubt it will ever be improved (RIP Uriel). After a bit of digging around, I found that werc has an option to specify a different markdown renderer (actually, in theory, it is formatter-agnostic and doesn't require markdown specifically) in the main configuration for a werc instance, in $werc/etc/initrc.local.


This specifies, which is in $werc/bin/contrib. Werc will run the executable specified, passing the markdown file to be rendered as an argument.

The markdown processor I'd like to use is called Blackfriday. It's a Go library with several extensions and a wide array of possible configuration options. Since Werc instances are often executed through cgd, Go is likely already on the server. Since the package is a library, a simple executable has to be made.

First, grab the Blackfriday package:

$ go get -u

The program to be made is very simple. All it does is read the file specified as an argument, run it through the markdown processor, and output the rendered html. The library has several extensions, the use of which won't be covered here. The example just enables the library with a set of sane defaults. Save the following as a go file:

package main

import (

func main() {
    input, _ := ioutil.ReadFile(os.Args[1])
    out := os.Stdout

If you'd like to test it, you can run the following, which should output html rendered from

$ go run md2html.go

Build and place the executable in the proper directory:

$ go build md2html.go

$ mv md2html $werc/bin/contrib

After that, you should be all set. The code included here is just a starting point and can be modified based on your needs.


Effective SSH Tunneling

In several years of using unix-like operating systems, I just recently needed to use an SSH tunnel for the first time. I've been working with a pfSense appliance in an environment where I couldn't access the appliance from the outside due to it being on a local area network behind a NAT firewall. Because of the nature of the project, I'm only able to get physical access for a short time each day, which isn't enough to get anything done. I needed to be able to manage the system from home.

After a quick search, I found the command needed to bypass a NAT firewall with an OpenSSH tunnel, given you have another system, a server for example, that has a public IP address. First, this must be allowed in the outside system's sshd configuration.

Edit /etc/ssh/sshd_config

Uncomment or add the line GatewayPorts yes

Save the file and restart the OpenSSH daemon.

After this, you're done configuring the host system. Next, you'll open your ssh tunnel. In my case, I wanted to bind ports 7022 and 7081 on to ports 22 and 443 (ssh and https) on my pfSense system. This is done like this:

ssh -f -R 7022:localhost:22 -R 7081:localhost:443 -N

The -f flag forks the session to the background. The -N flag means that no command will be executed upon connection. The -R enables a remote tunnel, and more than one can be used if forwarding more than one port, as done in the example.

The tunnel works as expected, making ports 22 and 443 of the pfSense appliance accessible from ports 7022 and 7081 of However, upon trying to access it later, I find that the tunnel no longer works. This is due to a lack of activity on the connection causing it to close. This brings us to autossh, a tool designed to automatically monitor and relaunch SSH sessions. No configuration of anything on the local system is really necessary.

Install autossh from source or from your operating system's package manager. Using autossh, the command is as follows:

autossh -M 20000 -f -N -R 7022:localhost:22 -R 7081:localhost:443 -C

This command performs the same function, except that it monitors the SSH session (monitoring on port 20000, as specified by -M 20000) in order to restart it in the event of the connection being closed. The same syntax is used as far as the specification of the tunnels goes (-R remoteport:localhost:localport).

You're now left with a persistent SSH tunnel running to bypass the NAT that the local system resides behind. Optionally, one can add the autossh command to be initiated at boot by the init system on the local system.