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