<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p>Hi Greg,</p>
<p>when configuring SWORD for my Android build (based on CMake) I
currently do not see CURL being detected automatically and
therefore there is no CURL in my Android SWORD build:</p>
<p>-- Configuring your system to build libsword.<br>
-- SWORD Version 1009000000<br>
-- <br>
-- SEARCHING FOR SYTEM PACKAGES<br>
-- System regex.h: Yes<br>
-- <br>
-- CONFIGURING SOURCE LIST<br>
-- ZLib: system
/opt/Android/SDK/ndk/r27c/toolchains/llvm/prebuilt/linux-x86_64/sysroot/usr/lib/aarch64-linux-android/21/libz.so<br>
-- bzip2: no<br>
-- xz: no<br>
<b>-- cURL: no</b><br>
-- CLucene: no<br>
-- PkgConfig: yes<br>
-- ICU: no<br>
-- Regex.h: system
/opt/Android/SDK/ndk/r27c/toolchains/llvm/prebuilt/linux-x86_64/sysroot/usr/include<br>
-- Building Static library.<br>
-- Setting link libraries to
/opt/Android/SDK/ndk/r27c/toolchains/llvm/prebuilt/linux-x86_64/sysroot/usr/lib/aarch64-linux-android/21/libz.so<br>
<br>
Best regards,<br>
Tobias<br>
</p>
<div class="moz-cite-prefix">On 2/28/25 18:25, Greg Hellings wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CAHxvOVJ32HbAKjw=mFSk6B6i9jYB4AWdScAZjX6Fs_FTJOZvWw@mail.gmail.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<div dir="ltr">
<div>This is all wonderful, but it's really just efficiency
improvements. I've been testing locally with nginx, and the
only setting I need is to set `autoindex on;` in the location
that points to the Sword repo. Everything works fine, then. I
have tested in the past with Apache (although it has been a
very long time since I've touched it) and it works fine there.</div>
<div><br>
</div>
<div>There's nothing currently stopping us from swapping to HTTP
or HTTPS client-based access anywhere that is built against
curl. Which is every Linux distro I've seen, MacOS CLI
distributions, and the Xiphos Windows builds. Also, I'm pretty
sure all the known mobile apps support it, as well.</div>
<div><br>
</div>
<div>--Greg</div>
</div>
<br>
<div class="gmail_quote gmail_quote_container">
<div dir="ltr" class="gmail_attr">On Fri, Feb 28, 2025 at
10:05 AM Troy A. Griffitts <<a
href="mailto:scribe@crosswire.org" moz-do-not-send="true"
class="moz-txt-link-freetext">scribe@crosswire.org</a>>
wrote:<br>
</div>
<blockquote class="gmail_quote"
style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div>
<p>Hey guys,</p>
<p>We did some work in the past to make this transition
begin to happen automatically without user actions. I
think there was an outline in here a year or so back.
Basically, the path forward was:</p>
<p>1) to standardize a location in a SWORD repository for
.zip package. This has many benefits beyond helping us
get to HTTPS everywhere. It conceptually allows reading
directly from the zip file by the engine. It could
facilitate the engine itself building the zip packages
from an exploded tree. All transports, including the
dominant FTP transport right now could look to see if
there is an available single .zip package for download
instead of downloading each individual file for a module
during a remote install, and I am sure more ideas people
will imagine in the future... but simply this step was to
standardize the location of .zip package which each
represent a zip of a single package based at the root of a
sword module repo, e.g.,</p>
<p>KJV.zip:<br>
mods.d/kjv.conf<br>
modules/texts/ztext/kjv/nt.bzs <br>
modules/texts/ztext/kjv/ot.bzs <br>
modules/texts/ztext/kjv/ot.bzv <br>
modules/texts/ztext/kjv/nt.bzv <br>
modules/texts/ztext/kjv/ot.bzz <br>
modules/texts/ztext/kjv/nt.bzz <br>
</p>
<p>This location decided on was pretty straighforward, at
the root of the sword module repo, packages/</p>
<p>You'll notice this if you have a look at the crosswire
repo here:</p>
<p><a href="https://crosswire.org/ftpmirror/pub/sword/raw/"
target="_blank" moz-do-not-send="true"
class="moz-txt-link-freetext">https://crosswire.org/ftpmirror/pub/sword/raw/</a></p>
<p>The latest version of the engine does use this now and
tries to downoad a package if available, before it falls
back to the previous behavior of downloading each
individual file.</p>
<p>2) Support 'chained' transport providers in the engine,
allowing multiple transports to the same repository. This
has been completed and the first use of this concept is
the recognition of a new HTTPSPackagePreference option in
installmgr's configuration file.<br>
</p>
<p>The value of the property is: existing repo
name|hostname|repository_path<br>
</p>
<p>You can see this added for the CrossWire repository in
the master repo list registry at:</p>
<p><a
href="https://crosswire.org/ftpmirror/pub/sword/masterRepoList.conf"
target="_blank" moz-do-not-send="true"
class="moz-txt-link-freetext">https://crosswire.org/ftpmirror/pub/sword/masterRepoList.conf</a>
<br>
</p>
<p>HTTPSPackagePreference=CrossWire|<a
href="http://crosswire.org" target="_blank"
moz-do-not-send="true">crosswire.org</a>|/ftpmirror/pub/sword/raw<br>
FTPSource=CrossWire|<a href="http://ftp.crosswire.org"
target="_blank" moz-do-not-send="true">ftp.crosswire.org</a>|/pub/sword/raw</p>
<p>This tells installmgr that if a user requests a package
install from "CrossWire" then chain 2 transport provider
attempts together and prefer the HTTPS transport first.<br>
</p>
<p><br>
</p>
<p>The hope is that this path forward will see the vast
amount of SWORD frontends begin to start using HTTPS
instead of using FTP, to facilitate a smooth transition
from FTP to HTTPS. The idea is that if a repo owner sets
everything up correctly, and a user has the latest
software and latest configuration information from our
registry of known SWORD repos ( <a
href="https://crosswire.org/ftpmirror/pub/sword/masterRepoList.conf"
target="_blank" moz-do-not-send="true"
class="moz-txt-link-freetext">https://crosswire.org/ftpmirror/pub/sword/masterRepoList.conf</a>
), everything will flow over HTTPS instead of FTP and once
we see FTP traffic drop to very low levels, a repo owner
could choose to discontinue support for FTP if they
desire.</p>
<div>Michael, I am glad you have your server back up and
running well again. Thank you for all that you do to
distribute the Word of God to a needing world.</div>
<div><br>
</div>
<div>Troy</div>
<div><br>
</div>
<div><br>
</div>
<div>On 2/27/25 9:45 PM, Michael Johnson wrote:<br>
</div>
<blockquote type="cite">
<p>Hi David,</p>
<p>Yes, under eBible.org, where it says "HTTP access", it
should say "HTTPS and HTTP access". Also, any repository
that also supports HTTPS and/or HTTP access should
explicitly say so. As Greg mentioned, mobile often
blocks FTP. FTP may not be dead, yet, but it is in
hospice care. HTTP likewise can cause problems with
mobile platforms, where the major app stores now require
use of HTTPS instead of insecure HTTP in most cases. I
still support insecure HTTP connections to eBible.org
except for at <a href="http://shop.eBible.org"
target="_blank" moz-do-not-send="true">shop.eBible.org</a>
and <a href="https://eBible.org/cgi-bin/contact.cgi"
target="_blank" moz-do-not-send="true">https://eBible.org/cgi-bin/contact.cgi</a>
but there may come a day when HTTP goes away, too.<br>
</p>
<div>On 2/26/25 22:03, David Haslam wrote:<br>
</div>
<blockquote type="cite">
<div style="font-family:Arial,sans-serif;font-size:14px">Hi
Michael,</div>
<div style="font-family:Arial,sans-serif;font-size:14px"><br>
</div>
<div style="font-family:Arial,sans-serif;font-size:14px"><i>Does
anything need to be changed here?</i><br>
<a
href="https://wiki.crosswire.org/Official_and_Affiliated_Module_Repositories#eBible.org"
target="_blank" moz-do-not-send="true">Official and
Affiliated Module Repositories - CrossWire Bible
Society</a><br>
</div>
<div style="font-family:Arial,sans-serif;font-size:14px"><br>
</div>
<div style="font-family:Arial,sans-serif;font-size:14px"><u>Everyone</u>:
Except for the note under <b>AndBibleExtra</b>,
there's no mention of <b>https</b> !<br>
<i>Do we need to make any wider changes to be future
proof?</i></div>
<div style="font-family:Arial,sans-serif;font-size:14px"><br>
</div>
<div style="font-family:Arial,sans-serif;font-size:14px">
<div> Best regards,<br>
<br>
David </div>
<div
style="font-family:Arial,sans-serif;font-size:14px"><br>
</div>
<div> Sent with <a href="https://proton.me/mail/home"
target="_blank" moz-do-not-send="true">Proton Mail</a>
secure email. </div>
</div>
<div style="font-family:Arial,sans-serif;font-size:14px"><br>
</div>
<div> On Thursday, February 27th, 2025 at 7:13 AM,
Michael Johnson <a
href="mailto:kahunapule@eBible.org" target="_blank"
moz-do-not-send="true"><kahunapule@eBible.org></a>
wrote:<br>
<blockquote type="cite">
<p><br>
</p>
<div>On 2/26/25 17:12, Greg Hellings wrote:<br>
</div>
<blockquote type="cite">
<div dir="auto">
<div><br>
<br>
<div class="gmail_quote">
<div class="gmail_attr" dir="ltr">On Wed,
Feb 26, 2025, 7:33 PM Kahunapule Michael
Johnson <<a
href="mailto:kahunapule@ebible.org"
rel="noreferrer nofollow noopener"
target="_blank" moz-do-not-send="true"
class="moz-txt-link-freetext">kahunapule@ebible.org</a>>
wrote:<br>
</div>
<blockquote
style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"
class="gmail_quote">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">
<div dir="auto">
<div dir="auto"><br>
</div>
<div dir="auto">
<div class="gmail_quote">
<blockquote
style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"
class="gmail_quote"> <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 <a
href="http://ftp.eBible.org" target="_blank"
moz-do-not-send="true">ftp.eBible.org</a> 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">
<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">
<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">
<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>-- <br>
<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/"
rel="noreferrer nofollow noopener"
target="_blank" moz-do-not-send="true">mljohnson.org</a>
• <a href="https://eBible.org"
rel="noreferrer nofollow noopener"
target="_blank" moz-do-not-send="true">eBible.org</a>
• <a href="https://WorldEnglish.Bible"
rel="noreferrer nofollow noopener"
target="_blank" moz-do-not-send="true">WorldEnglish.Bible</a>
• <a href="https://PNG.Bible"
rel="noreferrer nofollow noopener"
target="_blank" moz-do-not-send="true">PNG.Bible</a><br>
Signal/Telegram/WhatsApp/Telephone: +1
808-333-6921<br>
Skype: kahunapule • Telegram: @kahunapule • <a
href="https://www.facebook.com/kahunapule"
rel="noreferrer nofollow noopener"
target="_blank" moz-do-not-send="true">Facebook:
fb.me/kahunapule</a></font></p>
</div>
</blockquote>
<br>
</div>
<br>
<fieldset></fieldset>
<pre>_______________________________________________
sword-devel mailing list: <a href="mailto:sword-devel@crosswire.org"
target="_blank" moz-do-not-send="true"
class="moz-txt-link-freetext">sword-devel@crosswire.org</a>
<a href="http://crosswire.org/mailman/listinfo/sword-devel"
target="_blank" moz-do-not-send="true"
class="moz-txt-link-freetext">http://crosswire.org/mailman/listinfo/sword-devel</a>
Instructions to unsubscribe/change your settings at above page
</pre>
</blockquote>
<div>-- <br>
<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/" target="_blank"
moz-do-not-send="true">mljohnson.org</a> • <a
href="https://eBible.org" target="_blank"
moz-do-not-send="true">eBible.org</a> • <a
href="https://WorldEnglish.Bible" target="_blank"
moz-do-not-send="true">WorldEnglish.Bible</a> • <a
href="https://PNG.Bible" target="_blank"
moz-do-not-send="true">PNG.Bible</a><br>
Signal/Telegram/WhatsApp/Telephone: +1 808-333-6921<br>
Skype: kahunapule • Telegram: @kahunapule • <a
href="https://www.facebook.com/kahunapule"
target="_blank" moz-do-not-send="true">Facebook:
fb.me/kahunapule</a></font></p>
</div>
<br>
<fieldset></fieldset>
<pre>_______________________________________________
sword-devel mailing list: <a href="mailto:sword-devel@crosswire.org"
target="_blank" moz-do-not-send="true"
class="moz-txt-link-freetext">sword-devel@crosswire.org</a>
<a href="http://crosswire.org/mailman/listinfo/sword-devel"
target="_blank" moz-do-not-send="true"
class="moz-txt-link-freetext">http://crosswire.org/mailman/listinfo/sword-devel</a>
Instructions to unsubscribe/change your settings at above page
</pre>
</blockquote>
</div>
_______________________________________________<br>
sword-devel mailing list: <a
href="mailto:sword-devel@crosswire.org" target="_blank"
moz-do-not-send="true" class="moz-txt-link-freetext">sword-devel@crosswire.org</a><br>
<a href="http://crosswire.org/mailman/listinfo/sword-devel"
rel="noreferrer" target="_blank" moz-do-not-send="true"
class="moz-txt-link-freetext">http://crosswire.org/mailman/listinfo/sword-devel</a><br>
Instructions to unsubscribe/change your settings at above page<br>
</blockquote>
</div>
<br>
<fieldset class="moz-mime-attachment-header"></fieldset>
<pre wrap="" class="moz-quote-pre">_______________________________________________
sword-devel mailing list: <a class="moz-txt-link-abbreviated" href="mailto:sword-devel@crosswire.org">sword-devel@crosswire.org</a>
<a class="moz-txt-link-freetext" href="http://crosswire.org/mailman/listinfo/sword-devel">http://crosswire.org/mailman/listinfo/sword-devel</a>
Instructions to unsubscribe/change your settings at above page
</pre>
</blockquote>
</body>
</html>