Last century, this WWW site was on WWW space provided by TescoNET: http://homepages.tesco.net./~J.deBoynePollard/.
TescoNET provided "free" dial-up Internet access at the time. There was no subscription charge; TescoNET apparently making its money off the telephone charges. The WWW space was free also, albeit somewhat limited. As related in Holy Deluge of Microsoft Worms, Batman!, TescoNET service was limited in other ways, too There was no IMAP, and we customers got exactly one mailbox.
Eventually, TescoNET took itself out of the free dial-up business, switching to a different business model. It gave plenty of notice of this (a large fraction of a year, as I recall). Fortunately, I already had a replacement WWW site running; and had had for some time.
I had switched from dial-up to cable back in the days of NTL, which I had been a customer of since the days of Cable & Wireless.
I had kept the TescoNET WWW site going, because a lot of people were hyperlinking to it.
(You can find it still pointed to in books on filesystem forensic analysis, electronic mail, programming, and DNS.)
But my primary WWW site had quietly switched over to the WWW space that was part of the cable Internet package from NTL: http://homepage.ntlworld.com./jonathan.deboynepollard/.
Gradually, throughout TescoNET's notice period, I was able to put mirror meta-information on the old TescoNET pages, and eventually turn then into HTML redirects after some months. I also managed to persuade Google Web search to find the NTL site in preference to the TescoNET one. The transition was smooth. From what I could gather, almost no-one noticed the switchover.
Using the WWW space that came as part of the NTL cable Internet package lasted me for a long time, over a decade and a half. Virgin Media bought NTL, and it mucked things around a bit over the years. The NTL Usenet servers vanished; compulsory transparent HTTP proxying (which had "interesting" interactions with ORSC) went away, replaced by CleanFeed; the electronic mail was farmed out to Google, and then brought back in house again; the Virgin Media branded anti-virus software was discontinued. The bundled WWW space just kept on going. It needed zero support from Virgin Media's end; all they were doing was running a static HTTP server and a restricted-access FTP server for uploading sites to it. It didn't need much from me, either, other than paying Virgin Media its monthly cable Internet bill.
At the start of June 2016, with zero notice to me, this just up and died.
I erroneously attributed it to a problem with my employer's Virgin Media link, at first; this link has regularly gone down over the years, and I thought that my inability to see my own WWW site from work was just another such incident. I didn't think anything further of it until I noticed a fortnight later that it was still dead.
Virgin Media had decided that it was going out of the WWW site business, and just turned off my WWW site along with the WWW sites of all of the other Virgin Media customers who were happily doing as I was, including Robin D.H. Walker's much-consulted cable modem pages (http://homepage.ntlworld.com/robin.d.h.walker/) in amongst many others.
It was claimed in the press, that I found when I started looking around to see what was going on, that "mail" had been sent about this.
It had not.
I did not receive any notification, electronic or otherwise, about this.
Nor, indeed, had Virgin Media's own WWW site been updated.
In mid-June, its customer help pages were still merrily telling customers (who, like me, thought that perhaps the customer help information was a good place to look, for what was apparently a server outage) that everything was still hunky-dory.
This was to be a more rocky transition. The world noticed. People mentioned that the site had gone in questions on Stack Exchange; I got asked what was going on.
Fortunately, I've always also served my WWW site from my home machine. I don't point to the world to it, but I've always had a WWW server at home. Indeed, I've had several. For nearly two decades, it was an OS/2 Warp machine running my Internet Utilities for OS/2. The hardware died on that, and on the replacement eComstation so thoroughly messed up the HPFS volume containing the site files (giving everything an 8.3 name for some daft reason) that I haven't had the solid fortnight's spare time that it would take to hand-unpick the resultant tangle. Recently, it has been a PC-BSD machine running Bernstein publicfile under my UCSPI and service management toolset.
Backups in hand, for the first time this century I had to look at buying hosting and WWW service from third parties.
Needless to say, having been very thoroughly bitten both by Virgin Media's moves to and from Google Mail and by its discontinuance of its own anti-virus software, I did not simply unthinkingly go with the third party WWW space provider that Virgin Media was directing (unhappy) customers towards. (Virgin Media moving to Google Mail broke my Google account of the time. Virgin Media's recommendation to switch to F-Secure has proven to be money for old rope. One machine, no matter how much I configure it not to, still spins up its fans and discs, loudly, in the hush of night. Another insists that every Windows POSIX subsystem program that I run is a "rare program" and so must be a virus and blocked from running, whilst nonetheless exiting with a success code and breaking scripts. For extra laughs, it has a fallback position, after being told that it can run these "rare" programs — which are the ordinary Windows Services for Unix toolsets that I obtained from Microsoft — of blocking their Internet access. And all this whilst "protecting" me from reading my country's national newspapers, and scanning Thunderbird's local copies of mailboxes to smithereens.)
Setting things back up again took a while, because I decided to take the opportunity to make the nosh tools run on OpenBSD.
One of the new public WWW servers is an OpenBSD machine, running the nosh toolset's service manager and logging and tinydns and publicfile from a consolidated version of Bernstein toolsets.
(Whilst I was getting nosh running it very briefly ran Adam Sampson's freedt, which is still in the OpenBSD ports collection and still works today.
I was not happy about using dumblog for logging the activity of a public-facing HTTP server, though.)
A slight wrinkle was that OpenBSD 5.9 has a serious new kernel bug (not in 5.8) that affects anyone running virtual private servers in the way that they are nowadays commonly set up.
This delayed things somewhat; although on the bright side as a side-effect the nosh toolset gained a route-monitor service from the debugging that I had to do.
Even though I've tried to do it the hard way with OpenBSD, it is still a minuscule WWW site. The smallest shared hosting WWW services that I can buy are 1 to 2 orders of magnitude bigger, with PHP, MySQL databases, clip art libraries, disc space in the gigabinarybytes, and all sorts of things that I do not need.
I wanted some heterogeneity in my servers, though. I ended up buying the "Petite" package from Fuelled.
Bernstein's original httpd (from publicfile) has been IPv6-ready all of these years.
It can be used as-is with an IPv6-capable UCSPI-TCP server utility (like tcp-socket-listen and tcp-socket-accept in the nosh toolset).
However, Bernstein ftpd is not.
Within hours of the content DNS server going live, it was probed by the people at The OpenResolver Project.
They're fanatical about content DNS servers not acting as reflectors for queries from forged (victim) source IP addresses.
Bernstein tinydns does what they like right out of the box, and has done all along — lo! these many years.
It doesn't respond in any way to queries for parts of the DNS namespace that it hasn't been told about.
People also don't like silly query traffic to reach the ICANN root content DNS servers (where the definition of "silly" stretches to things like perfectly valid queries that are for top-level domain names that do not exist).
The best way to achieve this is to run an internal root content DNS server of one's own.
With some judicious use of location codes, one tinydns/axfrdns pair does two jobs simultaneously.
To the outside world, it is a simple content DNS server that only answers questions about part of the DNS namespace.
Internally, it is a private mirror of the root content DNS servers, serving up all of the delegations.
This is a fairly straightforward exercise in split-horizon DNS service using location codes.
Matt Palmer wondered a few years ago why there's no guide to setting up a root content DNS server.
It is because it's nothing more than one particular case of setting up a general-purpose content DNS server.
The only "special" thing is how one populates the data.
Contrary to popular belief, one can do that the old-fashioned way, with zone transfers, if one wants.
ICANN currently supplies publicly-reachable DNS/TCP content servers that serve up the root zone via zone transfer.
The rest is just a matter of copying the result into the data file and compiling it with tinydns-data.
The only truly special thing that I had to do, specific to my setting up split-horizon DNS service as aforementioned, was append the location code :lo to the end of each record.
This is a simple exercise in awk and sed.
cPanel doesn't serve up some of my OS/2 softwares.
They are just ordinary files, with names ending in .cmd.
Bernstein publicfile has no difficulty with them whatsoever.
cPanel's HTTP server sends "Forbidden" error messages to the reader.
I've probably hit one of the extraneous bells and whistles therein, which I suspect are for running server-side scripts or some such, that I do not need.
Addendum: Warren Doyle from Fuelled contacted me to tell me that ModSecurity had been sending them alert messages about .cmd files.
Apparently, ModSecurity had been protecting me from running command scripts on the server.
It wouldn't have been able to run these; they are written in REXX and are for OS/2.