<div dir="auto"><div><br><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">On Wed, Feb 26, 2025, 7:33 PM Kahunapule Michael Johnson <<a href="mailto:kahunapule@ebible.org">kahunapule@ebible.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Greetings from Maui!<br>
<br>
tldr: upgrade your Sword apps to always use https instead of http or ftp to access repositories ASAP.<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto">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.</div><div dir="auto"><br></div><div dir="auto">So you're basically completely safe.</div><div dir="auto"><br></div><div dir="auto"><div class="gmail_quote gmail_quote_container"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
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 <br>
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 <br>
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.<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto">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?</div><div dir="auto"><br></div><div dir="auto"><div class="gmail_quote gmail_quote_container"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
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, <br>
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 <a href="http://ftp.ebible.org" rel="noreferrer noreferrer" target="_blank">ftp.ebible.org</a> 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 <br>
in place that works for now, but it is not guaranteed to keep working.) For now, <a href="http://ftp.ebible.org" rel="noreferrer noreferrer" target="_blank">ftp.ebible.org</a> 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 <br>
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.<br>
<br>
In other words, the availability and reliability of the eBible.org https Sword repository should be improving. The anonymous ftp Sword repository at <a href="http://ftp.ebible.org" rel="noreferrer noreferrer" target="_blank">ftp.ebible.org</a> will become less reliable, and will eventually be discontinued. The ftp server at eBible.org (not <a href="http://ftp.eBible.org" rel="noreferrer noreferrer" target="_blank">ftp.eBible.org</a>) 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 <br>
<a href="http://ftp.eBible.org" rel="noreferrer noreferrer" target="_blank">ftp.eBible.org</a>.<br>
<br>
Any questions?<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto">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.</div><div dir="auto"><br></div><div dir="auto">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. </div><div dir="auto"><br></div><div dir="auto">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.</div><div dir="auto"><br></div><div dir="auto">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!</div><div dir="auto"><br></div><div dir="auto">--Greg</div><div dir="auto"><br></div><div dir="auto"><div class="gmail_quote gmail_quote_container"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
<br>
_______________________________________________<br>
sword-devel mailing list: <a href="mailto:sword-devel@crosswire.org" target="_blank" rel="noreferrer">sword-devel@crosswire.org</a><br>
<a href="http://crosswire.org/mailman/listinfo/sword-devel" rel="noreferrer noreferrer" target="_blank">http://crosswire.org/mailman/listinfo/sword-devel</a><br>
Instructions to unsubscribe/change your settings at above page<br>
</blockquote></div></div></div>