Table of Contents

1 Setting up a Gopher Server

Hey folks! In this post I'm going to talk a bit about setting up my Gopher server and some of the choices I made in doing so.

I hope this is helpful to anyone who stumbles onto this article!

Disclaimer: I'm only a few weeks into learning about Gopher and the so-called "indie-net", so this article may not represent the better part of community knowledge, or "best practices".

2 Basics

I'll just rattle these off quickly so that we don't need to spend too much time on them:

  • Server: Ubuntu VPS
  • Gopher Server: Motsognir

I won't cover the basics of setting up Motsognir or a basic Gopher map, as others have already done a great job covering these topics.

Checkout the following WWW links on the topic: https://gopher.zone/ https://usermanual.wiki/Document/manual.488145643/help

3 CGI

Because Gopher is a pretty simple protocol spec, I wanted to not serve static gopher maps and instead implement everything as a CGI script. This allows me to be pretty flexible with the formatting and configuration of the site:

  • Can provide a 'plain' non ANSI escape sequence cluttered version of the site for users who prefer the minimalism of uniform text/chars
  • Can provide interesting tidbits like Last Modification date of the site and # of uniq visitors
  • Silly stuff like intermediate http requests (server side) to my git server so that I can serve all of my git website natively in Gopher

The CGI source is actually available to view live, see: gopher://chate.io/0/foobar.txt

Note: The Gopher server Gophernicus actually offers what I think is an even cooler way of doing this, with what it calls moles. Check it out: https://github.com/gophernicus/gophernicus

I may move over to gophernicus at some point, but for now I'm enjoying the ease of use of Motsognir.

On that topic, to get all the CGI stuff working correctly I had to set the following values in the Motsognir config file. The config file is awesome, and well documented, but as a newcomer to the protocol it was somewhat confusing to get it configured right, so I've provided the following:

GopherCgiSupport=1 SubGophermaps=1 DefaultGophermap=

I'd encourage reading the comments for each of these settings for a clearer understanding of what they're doing, but I leave this exercise to the reader.

3.1 Footguns and Hangups

A few things I learned trying to always dynamically generate my gophermap:

  • Clients can be finnicky and the protocl spec seems to be not super well agreed upon by client implimenters
    • Some clients will not correctly parse info lines if there is a " " after the i
    • Some clients will seemingly ignore info lines
    • Some clients don't mind if you don't have a "." char at the EOF, others seem to really care
      • Apparently the "." at EOF is part of the spec, so it really should be there
    • Some clients will automagically parse out any ANSI escape sequnces, others will interpret them correctly, and others will barf them to the screen literally
      • To my knowledge there is nothing in the spec for handling this, so client implementers can't be blamed
    • Some gopher servers will helpfully auto fill lines in a map that don't contain <TAB>$host<$TAB>$port. I learned that motsognir will do this on a statically served map, but (in hindsight, obviously), not a dynamically generated one, so make sure you're filling that out

3.2 Helpful Patterns

A few helpful patterns I've employed while writing my CGI scripts:

  • Establish an interface for printing your gopher map. I use a function that takes 3 args: $gophermenutype, $string, $rest.

    The idea being that you call the function this way: gprint("1","Some Dir","\t$path\t$hostname\t$port");

    This function will then, depending on what/if it gets a CGI query parameter, will either randomly colorize the output or not, allowing the site to be easily rendered one way or another.

  • As with stuff on WWW, make sure your CGI scripts are executing quickly, otherwise the client will be left waiting

Created: 2022-01-21 Fri 15:49