Yes, that is the actual gophermap for that menu.
Hosting your own Gopher server is a bit different than hosting your own web server. While the same general principles apply (files in a folder on your machine get served out to the wider internet), there's different features to look out for and setup is a little different. Here's some things I wish I knew going into hosting a Gopher server.
Gopher is an extremely lightweight protocol, and the server packages are too. This makes Gopher rather ideal for revitalizing old machines, both as something to browse and as something to host. Somnolescent hosts our Gopher server on a Raspberry Pi 4, and I don't imagine there's much out there post-1995 in the consumer PC realm that isn't up to the task. Any VPS host will be more than enough, certainly.
Most Gopher server packages expect to be run over some form of Linux or POSIX-compliant OS, though some will work on Windows as well. If your server package needs an interpreter like Python, make sure your server can run the specific version of Python the package needs; some need Python 2, others need Python 3. Pituophis, our in-house Gopher server software, uses Python 3.
Much like clients, server packages have several key features you should be on the lookout for. Some of these are pretty much necessary and will make your life maintaining your server much easier, while others are simply nice to have and might tip your decision towards a specific server package.
The Bucktooth server established a more efficient replacement for the traditional gopherd .link/.name system of customizing a Gopher menu. These are called gophermaps. These are highly-simplified, plain text representations of the source code of a menu. Many servers today support these.
Somnolescent "The glow of the bulb will guide us all" -------------------------------------------------------------- 0About Somnolescent somnolescent.info 0The Somnolescent Manifesto manifesto.txt 1Who are the Somnolians? somnolians/ 1Somnolescent Recaps recaps/ The cult at a glance, who's responsible, and what we're up to hSomnolescent on the Web URL:http://somnolescent.net/ Many handmade sites and blogs to peek at...
Globbing is another server feature originally established by Bucktooth. Globbing allows gophermaps to feature wildcards as selectors, listing potentially hundreds of files and other menus all at once as long as their filenames match the wildcard. Thankfully, globbing is also a fairly common feature among new server packages.
Yes, that is the actual gophermap for that menu.
And for the trifecta of Bucktooth-originating server features, gophertags are text files that give the directory they're in a user-specifiable name when a menu is listed as part of a glob. Any server that supports globbing should also support gophertags.
Seeing as most web browsers provide no Gopher access whatsoever, you might want to deliver your Gopher content over HTTP as well. For servers that support this, it tends to be a major selling point—two good examples are GoFish and PyGopherd.
PyGopherd's Gopher/HTTP gateway, accessible in any browser without needing a proxy or client.
Some server packages allow the execution of standard CGI scripts, majorly extending Gopher's functionality on the server end. Gophernicus can execute not just CGI scripts, but PHP ones as well.
I'm including this at the end because I actively recommend against serving "secure" Gopher, or Gopher over TLS. Reason for this is simple: it breaks compatibility with a large number of clients for ultimately no benefit. Implementations of Gopher over TLS often use the exact same port as normal, clearnet Gopher, a mistake so incredibly thick that even the orchestrators of HTTPS didn't make it. There's a case to be made about not sending passwords and bank details over the clear, I'm well aware, but Gopher deals in neither of these. You're browsing text documents and pictures. This isn't worth ruining 30 years of software support for.
We live in a weird world where technically-minded people have it out for the clearnet. I'm really not concerned that someone might be able to see what Gopher servers I'm looking at, and neither should you. You should operate under the expectation that all internet communication is insecure and traceable and I'd highly advise you not to use Gopher over TLS, even if your server package supports it. To quote Farhad Anklesaria, one of the chief Gopher protocol architects:
Gopher was originally designed as an essentially anonymous document retrieval protocol to facilitate easy access to information rather than limited access. Various kinds of restrictive mechanisms have been implemented at the server end (for example, access restriction by source IP address); however if you have sensitive information, we emphasize that putting it under a Gopher's nose is not a good idea.
The setup of your server package of choice will depend on which one you pick, of course. A rather popular language to write Gopher servers in is Python, in which case a single command invoking the Python interpreter and the location of the main script is all that's needed to launch the server. Bucktooth uses one of a few shell scripts that walks you through setup depending on the service daemon you have installed (inetd, xinetd, or launchd are options), which nets it points in the user-friendly category. For others, follow the instructions given.
I've occasionally run into trouble trying to run server packages on reserved ports, that is, those under port 1024. Gopher's traditional port 70 is one of these ports, and Linux especially prevents you from running software that uses that port to serve content. Running your server package as sudo solves those problems generally; Bucktooth will ask to be run as sudo during its initial setup so that it can set itself to respond on port 70, and Python scripts definitely work on 70 run as sudo.
It's also a good idea to look into a way to run your server package automatically. I was ultimately unsuccessful at getting a Python script loaded at startup through any kind of plist, back when I was trying to run a server on MacOS, but a cron job worked first try. I set mine at @reboot so I can simply restart the Raspberry Pi to restart the server package and hopefully clear up any issues.
You've either set up your Gopher server on a home or otherwise local network on a computer you personally have access to, or you have it running on a VPS through a hosting company. If the latter, you should already be able to access your server in a Gopher client using your existing domain name once the server's live. Remember to specify the protocol at the start of the URL and the port if necessary.
If it's the former, you'll have to do some additional setup to get the server accessible on the wider internet. Much of this will depend not only on your home router, but also what your ISP lets you do. I have an incredibly lax ISP and a router from 15 years ago, so I'm able to host servers out of my home and port forward them without much trouble. (Of course, the caveat with hosting out of your home is that your home IP address is exposed, but at best, that lets someone know what town you're in, not your literal address. Don't be too concerned.)
Port forwarding is a setting on many routers that allows incoming traffic to be directed to one of the devices on the network. The basic setup involves picking a port or range of ports to allow access into and then forwarding those requests to an internal IP on the network. To find your server's internal IP, you can either check in the "attached devices" section of your router's settings, or more locally, run ipconfig on a Windows machine or ifconfig on a Linux machine. Both will give you a list of network devices attached to your machine. If your server's connected over Wi-Fi, you're looking for a wlan or a "wireless LAN adapter", and if it's a wired connection, look for an eth0 or an "Ethernet adapter".
ipconfig (Windows) |
ifconfig (Linux) |
|---|---|
Ethernet adapter Local Area Connection: Connection-specific DNS Suffix . : Link-local IPv6 Address . . . . . : fe80::e866:2e3:8461:c537%12 IPv4 Address. . . . . . . . . . . : 192.168.1.12 Subnet Mask . . . . . . . . . . . : 255.255.255.0 Default Gateway . . . . . . . . . : 192.168.1.1 |
wlan0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 192.168.1.17 netmask 255.255.255.0 broadcast 192.168.1.255
ether dc:a6:32:4e:da:1d txqueuelen 1000 (Ethernet)
RX packets 27979 bytes 2372463 (2.2 MiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 12148 bytes 2303406 (2.1 MiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 |
The machine on the left has an internal IP of 192.168.1.12, and the machine on the right has an internal IP of 192.168.1.17.
Routers may assign different internal IPs to machines on your network on reboot, so if possible, look into a setting called address reservation. This allows your router to reserve certain internal IPs for certain MAC addresses.
My router's address reservation settings, ensuring the Gopher server ("Filebase") always gets the IP the router's port forwarding on.
Now in your port forwarding settings, set port 70 to the internal IP of the machine running your server. Remember, in our case, it's 192.168.1.17.
My router's port forwarding settings, which forwards incoming port 70 connections to 192.168.1.17.
To test this, you can try to connect to your external IP, which is what you traditionally think of as an IP address. (You can find your external IP either by Googling "what is my ip" or going to an IP lookup site like this one.) To test, visit gopher://[your external ip]; in my case, it'd be gopher://24.238.84.33.
This is a real, working address, by the way. You can technically visit Somnolescent's Gopher server like this, no problem.
If you can connect, your server is live online and you can get it going with a domain name. If you can connect to your internal IP but not your external one, there's a problem with your router. If you can't connect to either, there's a problem with your server.
If you have a domain name, it's remarkably simple to forward requests from that domain name to your external server. This does require you to be able to edit DNS records, so the exact process depends on who you bought the domain from. Our domain (and hosting) is through DreamHost, so I'll be demonstrating with them.
In the DreamHost "Manage Domains" panel, each domain and subdomain you own has a "DNS" option. Clicking that will show you all the DNS records active for that domain. Many records are already set by DreamHost for services like email, MySQL, and FTP, but you can also add your own custom records. (This is how Google verifies webmasters for their search console.)
Very conveniently, heavily cropped screenshot of this, but you get the idea.
In my case, I'll be adding a Type A (host address) record for my external IP to gopher.somnolescent.net. Now, any time someone accesses that subdomain, it'll act like they instead accessed 24.238.84.33. This is what happens in the background every time you visit a website; that domain name gets translated into the IP address of a computer network, which forwards your request to the relevant server on that network, which processes the data and sends it back whence it came.
The information I've provided above is provided as-is. Errors may be present. You can contact me at mariteaux@somnolescent.net for corrections.
Last updated 7/17/2020.