Being an old experienced technologist comes with a particular set of challenges. The primary one is: things change. Yes, that is a common trope among the aging. As in society, though, changes in technology, for those of us versed in the subject, do not come easily. We know how things work. They worked just fine before you touched them. Stop fixing things that ain’t broke. Etc.
And so, DreamHost, my web hosting provider for lo these many years, to use a technical term, broke my shit. To be fair, not all of it, and not the most important stuff, but it’s not perfect…. and I have to spend time away from my cornucopia of projects to deal with it.
What Are You On About Now?
Before continuing, I need to explain some technical stuff so that you can follow along, if you’ve made it this far. Hopefully, even if nothing in these explanations stick, you might get a sense of how the Internet works.
The first question is the most basic: what is a domain? And its related cousin, what is a subdomain? At its most basic, a domain is a name given to an Internet address, though this is somewhat simplified. Domains are registered with a central domain registry which ensures that unique domain names are assigned to legal entities, both personal and corporate. This central registry makes sure that Microsoft owns microsoft.com. It makes sure that I own mill6.online. The ownership comes with an annual fee, usually nominal. This ownership is only one part of the puzzle. The other part is that these domain names need to be translated to Internet addresses so that the browser on your computer (or phone or tablet or Roku box or…) knows which other computer to communicate with. To that end, there are numerous computer servers, called DNS servers (for Domain Name Service), which handle the mapping of these domain names to specific computer servers located at specific Internet addresses around the world. Your Internet provider, such as Xfinity or Verizon or whatever, have DNS servers that they provide to you when you connect to the Internet through them.
Note that I said specific Internet (or static IP) addresses. In order to host your own web service, you need a computer which sits at a specific Internet address. The reason why people like me sign up with a Web Hosting Provider is that their computers are allocated specific Internet addresses. When you hook up to the Internet via Xfinity etc., you are given an Internet address from a pool of available addresses and they change routinely, especially if the power goes out. All it takes is for you to reboot your computer or cable modem or something happens at the Internet provider’s facility for you to be given a new IP address. Because of this, when using a typical Internet provider, you cannot run your own web service at your home. Xfinity/Comcast do not provide their customers with specific IP addresses. Comcast for Business, however, does.
So instead of running my own machines for my own web servers, I use DreamHost. They have their own server farm and they do all of the hardware maintenance. Their systems have static IP addresses. Their systems have most of the software you need to host blogs, run e-commerce systems, design web sites, etc. You manage the content; they take care of the hardware and security concerns.
To recap: someone who wants to run their own web site needs to register a domain and find some computers to run the software that will provide content or services for users who visit your web site. The computers can be provided by a Web Hosting Provider or, using enhanced or business-oriented Internet provider services, you can run your own computers and manage your own software.
But, what are subdomains? Subdomains allow you to run multiple services under the primary domain. For instance, I could run a dice service under dice.mill6.online while my blog remains at mill6.online. If you enter mill6.online into your browser address, you’ll get the blog. If you enter dice.mill6.online, you will get a web page which provides access to a random number generator… if such a thing were available. Subdomains allow people or corporations to house multiple types of services under the single umbrella domain. Think of each subdomain as a separate application under an application suite: like Word or Excel under the umbrella Office 365.
If you’ve come this far down the rabbit hole, buckle up, Alice. I need to talk about the software used by web servers to provide this content. Most, if not all, web content is provided by server processes called, colloquially ,”web servers” or HTTP Servers. Server, server, server. Yeah, the term gets overused.
A server process is a piece of software that runs in the background. It has no user interface. You can only communicate with it, once it is launched, by sending messages to it via other computer programs. These types of processes are also referred to as “daemon” processes, in that it seems like your computer is possessed by something you can’t directly control. I shit you not. To stop a daemon, or server, process on Linux or BSD or macOS or other Unix-like systems (Yes, macOS is Unix-like under the hood.), you can use a program called “kill”. If the process doesn’t die, but stops interacting in the usual manner, it can become a “zombie process”. Who said computers weren’t fun?
Your computer’s browser, when you try to access a web site, communicates with a DNS server to convert the www.pianosandcats.com address to an IP address. Next, it communicates with the computer at that address using the HTTP protocol, or HyperText Transfer Protocol. I won’t go into the nitty-gritty of the protocol, which is amazingly, or almost stupidly, simple, but at this point you need to know that the server process running on the web site’s computer is an HTTP Server and all it does (mostly) is listen for communications from the outside world, receive the HTTP-encoded request to get a page, or an image, or a CSS file, etc. and send that information to your (and other people’s) browser so that you can see a photo of a cat playing a piano. Easy-peasy… until we software people complicated things.
Modern web sites allow web pages to be fully interactive. You can stream videos. You can resize elements. You can edit stuff. The modern web is a network-aware application platform that is almost as fully-featured as a native Windows, macOS, or Linux app. Explaining how all of this works will get us to a level of rabbit hole that would drive even the Mad Hatter bat-shit crazy. However, there is one element of this ecosystem that you will need to understand before I continue with my story.
While most web-based services use the basic mechanics of the HTTP Protocol to deliver content, some use the protocol to pass encoded messages through the HTTP Server to code modules working in tandem behind the scenes… and this is the area I play in. I write web service code to provide features and services that run-of-the-mill web browsing does not use. My language of choice for these endeavors is Ruby.
Most, if not all, HTTP Servers do not directly support running Ruby-language modules out of the box. Other bits of software need to installed on the web site computers and they need to be maintained by the people who maintain the hardware. And all of that falls under the purview of your Web Hosting Provider, aka DreamHost.
The Storm
The calm before the storm occurred three months ago. I received a message from the DreamHost Support Gurus that two of my personal web subdomains, which were running Ruby-based services, needed to change to a new way of doing things. They had been providing a software package called Passenger to allow us Ruby aficionados to write special web service code. Changes in hardware and software management policy was prompting a change in how Ruby service developers were to provide these services.
I had a three-month window. I began work on this two weeks before the deadline. (They say with age comes wisdom. Meh.) I did not suspect issues and, to be fair, it’s all running fairly smoothly now once I figured things out. Except however, that HTTP data uploads are now capped to a maximum limit where they weren’t before. For most of my services, this is not a problem. For my Git/LFS service (LFS = Large File Storage), however, this is an issue, albeit a manageable one. Data uploads are now capped at 2.5MB, which means the largest file I can store is 2.5MB in size. Unfortunately, I have 10MB files I’d like to store. As Inspector Jacques Clouseau of the Sirté would say, “Not any more.” And DreamHost has told me as of three days ago that they are no longer looking into this limitation. I’m the one who needs to consider a change in platform.
New Tricks
Again, to be fair, DreamHost’s VSP service was never meant to host the sort of software packages I’m developing. I pushed the system to a limit and changes in their system management policy imposed a new limit that my services are not compatible with.
I’m left with three choices: get a static IP and host my own web site and services on my own computer(s), change DreamHost plans and sign up for a service plan that gives me more control (and more management headaches) of the software installed, configured and used (this was their suggestion), find another WHP. All signs point to learning new and up-to-date IT information, configuration and techniques.
I think I’m going to opt for the new DreamHost service plan. It will allow me to use their computers to work in an environment with more control. I think it’ll serve as a natural evolutionary path to hosting my own micro data server.
Stay tuned. Should be fun.