<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p><br>
</p>
<div class="moz-cite-prefix">On 2/26/25 17:12, Greg Hellings wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CAHxvOV+zDKLB6K442+SU9L7VEkeb0eC940E8fmQ15trR3sdcFA@mail.gmail.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<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"
moz-do-not-send="true" class="moz-txt-link-freetext">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>
</blockquote>
<p>Awesome!</p>
<p><br>
</p>
<blockquote type="cite"
cite="mid:CAHxvOV+zDKLB6K442+SU9L7VEkeb0eC940E8fmQ15trR3sdcFA@mail.gmail.com">
<div dir="auto">
<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>
</blockquote>
<p>So far, I have been using Plesk to set up virtual hosts. I have
25 sites (and some aliases for those), some of which are much more
important than others. Plesk lets me share one IP address with all
sites except any site that has an anonymous ftp service associated
with it. The only site I have that has an anonymous ftp service
associated with it, of course, is the ftp.eBible.org Sword
repository. So I had to assign 2 IP version 4 addresses to the
server. For a long time, I was running 2 servers with every site
on them for redundancy. I had stopped doing that because the sites
grew too large for one of the servers I was renting, and I thought
I had a workable fast backup/restore plan, unlike when I had
extremely slow and expensive Internet in Papua New Guinea. (I have
some serious space in audio and video Bibles.) So that is 2
servers x 2 IP addresses = 4 IP addresses. But that configuration
was unstable, so I went to just one IP address per server by
fighting my old ally, Plesk, using manual ProFTP configuration
(and a cron job to slap my configuration back whenever Plesk
rewrites it). That is not a really good long-term solution,
though.<br>
</p>
<blockquote type="cite"
cite="mid:CAHxvOV+zDKLB6K442+SU9L7VEkeb0eC940E8fmQ15trR3sdcFA@mail.gmail.com">
<div dir="auto">
<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>
</blockquote>
That would be useful. That could be a way to escape my dependence on
and fight with Plesk.<br>
<blockquote type="cite"
cite="mid:CAHxvOV+zDKLB6K442+SU9L7VEkeb0eC940E8fmQ15trR3sdcFA@mail.gmail.com">
<div dir="auto">
<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. <br>
</div>
</div>
</blockquote>
I have looked at alternatives in the past, but it may be worth
looking again. When I last looked, AWS was more expensive at my
traffic levels and site counts than using a rented dedicated server.
Another alternative might be hosting at my house when (if?) Hawaiian
Telephone makes good on its promise to bring fiber Internet to my
neighborhood. (It is actually available about a half mile away,
right now, but I haven't seen them working on it around here.)<br>
<blockquote type="cite"
cite="mid:CAHxvOV+zDKLB6K442+SU9L7VEkeb0eC940E8fmQ15trR3sdcFA@mail.gmail.com">
<div dir="auto">
<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>
</blockquote>
<p>Thank you, Greg. I may take you up on that...</p>
<div class="moz-signature">-- <br>
<meta http-equiv="CONTENT-TYPE" content="text/html; charset=UTF-8">
<title>signature</title>
<p><font color="#000000">Peace,<br>
<b><big><i>Michael Johnson</i></big></b></font><b><br>
<font color="#000070">
26 HIWALANI LOOP • MAKAWAO HI 96768-8747</font></b><font
color="#000070"> • USA<br>
<a href="https://mljohnson.org/">mljohnson.org</a> • <a
href="https://eBible.org">eBible.org</a> • <a
href="https://WorldEnglish.Bible">WorldEnglish.Bible</a> • <a
href="https://PNG.Bible">PNG.Bible</a><br>
Signal/Telegram/WhatsApp/Telephone: +1 808-333-6921<br>
Skype: kahunapule • Telegram: @kahunapule • <a
href="https://www.facebook.com/kahunapule">Facebook:
fb.me/kahunapule</a></font></p>
</div>
</body>
</html>