[sword-devel] Downgrading eBible.org ftp repository service; upgrading https service
Greg Hellings
greg.hellings at gmail.com
Wed Feb 26 22:12:54 EST 2025
On Wed, Feb 26, 2025, 7:33 PM Kahunapule Michael Johnson <
kahunapule at ebible.org> wrote:
> Greetings from Maui!
>
> tldr: upgrade your Sword apps to always use https instead of http or ftp
> to access repositories ASAP.
>
While technically any network acess other than anonymous FTP support is
optionally supported only with a build dep, in reality there is no need to
support anything other than HTTPS. Every Linux distribution, and Windows
build of note has libcurl, the Brew version is also built against it, and
the HTTP(S) support was added because mobile often blocks FTP.
So you're basically completely safe.
> As many of you are probably aware, the last week was not a model of
> reliability for the eBible.org repository, or for the rest of the
> eBible.org site. On the 19th of February, the eBible.org server hardware
> failed. Exactly what failure, I don't know, because it was in a data center
> over 4,000 miles from my house. I just knew that it wouldn't talk to me in
> any of the 3 ways I can normally access the leased dedicated server. No
> worries, because I have a fast backup, right? I allocated a new dedicated
> server
> from the same company (Ionos) and attempted to restore from a backup. That
> failed with about 80 error messages. Next plan: restore from a mirror image
> of the server in my home office. That actually worked, but it took more
> than 3 days to get all of the data there (about 300 GBytes), plus time to
> get all of the configuration right. In the mean time, my other leased
> server (the one that didn't crash, hosting 24 other sites) gave early
> warning signs that it was not going to be in service much longer. Then
> everything worked except that I forgot a couple of tweaks I had to do to
> make the ftp server compatible with Sword. I fixed that, and things were
> still not OK. EBible.org availability kept going up and down like a yo-yo,
> mostly because the remote control software I was using was not designed to
> handle multiple IP addresses per server and anonymous ftp sites. Also, the
> cost of allocating multiple IP v4 addresses has gone up. Anonymous ftp is
> pretty much obsolete. I will be dropping it, but slowly.
>
A Herculean effort, but I'm glad for you that your recovery was successful!
I'm curious why you need 4 separate addresses? What is the need, there?
> I am upgrading eBible.org (and my other sites) to have a hot standby
> server, with both primary and standby servers in a data center with high
> reliability power and fast Internet connections. Normally, the load will be
> split between the two with some sites on one, and some on the other. If one
> fails, I can switch the DNS (with a short TTL) to the other in less than an
> hour after I notice the problem and am in a position to do anything about
> it. Then I can recover or replace the dead server, as appropriate,
> with data from the working server. (If two die, then I'm back to restoring
> from a very long distance and a slower Internet connection, again.) The
> good news is that this will provide higher availability for the https
> repository on eBible.org. The bad news is that I'm no longer going to try
> to swim upstream by maintaining a separate IP v4 address for
> ftp.ebible.org on those servers. This means that I can't use Plesk to
> maintain an anonymous ftp service on eBible.org, any more, reliably. (I
> have a manual hack
> in place that works for now, but it is not guaranteed to keep working.)
> For now, ftp.ebible.org points to another machine in a nice data center
> that just does anonymous ftp for the sword repository, but that is a rather
> expensive solution for an obsolete protocol, and I'll be replacing that
> with an ftp server in my home office, meaning that I don't have to pay
> nearly as much to operate it. It also means that whenever my Internet goes
> down, which it does whenever Hawaiian Electric's service goes down, even
> though I have battery backups, that service will go down. Extended outages
> can and do happen on this island. Internet could also go down if an
> undersea cable gets cut. My home internet connection is about 10% of the
> speed of the data center's Internet connection, so that might be noticeable
> with heavy use.
>
> In other words, the availability and reliability of the eBible.org https
> Sword repository should be improving. The anonymous ftp Sword repository at
> ftp.ebible.org will become less reliable, and will eventually be
> discontinued. The ftp server at eBible.org (not ftp.eBible.org) actually
> works right now, but could stop working at any time, probably associated
> with a software upgrade or security patch or with a server migration. The
> best address to use for anonymous ftp access to the Sword repository is
> ftp.eBible.org.
>
> Any questions?
>
Would you like a hand building up some DR or deployment automation so you
can avoid needing to remember settings? IT automation is one of my primary
skillsets, so if you'd like any sort of help setting it up, let me know.
For instance, it's not too hard to put together automation scripts to run
on a provisioned box to stand up the web server, ftp server, etc so that
you don't need to manually edit files and the like.
Alternatively, have you considered an alternative way to host the data? You
could probably build a Container image with all the files in it and host
that on something like Amazon Container Service or any of the many cloud
Kubernetes hosts around. A container image would also make it easy for
someone to grab the whole collection and make it available in an offline
context the way they can with the old CD images Troy used to distribute.
Or even put the files into an object storage container if you're dedicated
to eliminating FTP access eventually. With just a small shell script you
can push the needed files and their indexes into an S3, Ceph, etc object
storage service and then you wouldn't need to run a dedicated server with
them to manage uptime. All of those services offer ways to expose the files
over HTTPS.
As I said on Facebook, I'm happy to lend a hand if there's anything I can
do to help smooth your infrastructure! I can even host an emergency mirror
if need be, as I have pretty reliable Internet and electric when my
neighbors don't drive into the electric poles. This year I'm dedicating
some of my time to working on home electric backups!
--Greg
>
> _______________________________________________
> sword-devel mailing list: sword-devel at crosswire.org
> http://crosswire.org/mailman/listinfo/sword-devel
> Instructions to unsubscribe/change your settings at above page
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://crosswire.org/pipermail/sword-devel/attachments/20250226/da319681/attachment.htm>
More information about the sword-devel
mailing list