Update installation manuals online for bibledit-web.



















I wonder whether it is better that the site stores no data at all in a file system,
but only in a database. When generating the changes, we could just mail them out, and store nothing.
When storing the exported Bibles, we could just store them in a temporal directory, and link to that, no more.
And the git repository could be stored again in the database before and after use. The directory it uses would be in /tmp.




























































Add downloadable files. Let this backup tarball also include all downloadable files in /var/lib/bibledit-web, so that a restore can be made complete.
Also add the git repository on the web server. So that a restore makes this complete as well.
Test download.



















































































Producing a sword module.
Use usfm2osis.pl
If all .usfm files are in one folder data, do this:
perl usfm2osis.pl Bible data/*.usfm
This produces a file Bible.osis.xml.
Then make it a Sword module:
osis2mod . Bible.osis.xml
To write it to the proper place:
osis2mod ~/.sword/modules/texts/bibledit/ndebele Bible.osis.xml

osis2mod is conservative with file permissions.  
Be sure the files have proper permissions before you deploy.
I only mention this because I often forget to grant read access to files
before deploying a module for testing and the result is only
chapter/verse numbers.















CONFIGURING TOO EARLY:

Looking further at the autotools configuration done in bibletime-web
0.2, other things that need to be settable per-installation, not at
build time, are apparently also being configured and defined at build
time.  These include the database server location, database admin user,
database admin password, database name, database user, database
password, bibledit admin user and password. Some of these seem to be handled in
database/credentials.php and this is created by setup.php, but in that
case, why is the checking of MySQL at build time being done?

Why the code needs the mysql admin username and pw is a question in
itself -- wouldn't it be more secure to prompt for these when needed,
which hopefully is just for a one-time initial database setup, done at
(package) install time, not build time?

Since (at least in theory) one could set up multiple instances of
bibledit-web on a single server, each with their own database and each
with their own apache virtualhost, doing too much at build time seems to
me to reduce overall flexibility and capability.

Unless I am misunderstanding what the code does, I don't see how this
software can readily be packaged until many or all of these things are
moved from being defined and checked at build time to being settable in
a configuration file accessed (and checked, if appropriate) at run time.

DATABASE CREATION:

I think the setup.php code that creates the bibledit-web database
probably will need to be made usable as a script to be run at package
installation time, or maybe at first web login to bibledit-web.  Asking
users to point a browser at a URL just to do something non-interactive
seems unfriendly.  The web server needing to be able to delete the
bibledit-web php files (auto-deleting setup.php after running it) looks
like a security weakness; only the server admin should be able to edit
or delete those files, once installed.


SECURITY:

There is too much chmod -R 0777 going on (both in the Makefiles and then
also in some PHP code) than can be considered safe or secure for an
Internet-facing web server.  World writable files and directories are
almost never needed, and almost always a security risk.  Why would every
user on the web server machine need full access to all of these
bibledit-web files and directories?  Installed on a shared web hosting
server, this could quite easily allow other customers on that server to
do anything they like with your site, including add their own code, run
spambots as you, hand out malware to every unsuspecting user who uses
the bibledit-web site, etc.

I'm not sure that suggesting or assuming a MySQL root pw of "root" is
wise, either :)  If you are going to do setup from PHP, why not have
setup.php prompt for all the database info (host, dbname, adminuser,
adminpw, username, pw) and write some of it (hopefully not the
adminuser/adminpw!) to a config file?  It can do some of that already.

All uses of system() and exec() should probably specify a full path, so
users can't persuade your code to execute *their* chmod instead of the
system one, for instance.

I'd suggest you try to do a detailed security review as soon as
practical.  It seems odd to be using 1024bit ssh keypairs, but also
doing things like "chmod 0777" and assuming a dba password of "root".






DATABASE CREATION vs DATABASE USE:

I am rather alarmed to find that the bibledit-web code seems to make no
distinction between the database user/pw needed to create the bibledit
database and its tables, at install time, and the one used at runtime to
work with those tables.  Am I understanding this correctly?

By default, this leads to the bibledit-web database code using the
all-powerful DBA user (root) at run-time, and storing that username and
*password* in plain text in a configuration file.  Worse still, the
default password is "root", and (even worse!) that configuration file is
set to mode 0777, so absolutely any user on the server can read it, and
then use it to do absolutely anything they want with any MySQL database
on that database server.

I believe this is a significant security issue.  On my web servers
(servers I admin, not servers I own!), a single MySQL server instance
can contain databases for 100-200 independently owned web sites... the
bibledit-web 0.2 installation in effect gives *every* user on the server
full access to *every* *single* *one* of those databases! (I didn't
install bibledit-web on a production server, so no harm done, I'm just
pointing out how bad this would be in production use!).

I think the right solution is for the code to distinguish very clearly
between (a) the DBA username and pw, and (b) the runtime
bibletime-specific user and pw.  (a) is prompted for and used only once,
at install time, to create the bibledit database and the runtime user
and pw. It is never stored anywhere on disk.  (b) is then used to create
the tables, and then to access the information in database, by
bibledit-web at runtime.  It is stored in a config file (readable only
by the user running the bibledit virtualhost, but not by others!).





  








It would be helpful if bibledit-xiphos and bibledit-bibletime
show their version number somehow. Perhaps on the main window.
Or under the settings window.
















Should we upgrade bibledit-gtk to libgtkhtml-4.0-0 and libgtkhtml-editor-4.0-0? 
These might be of a better quality than the current library.






We may probably better use WebKit(2) in editing mode, and then even set parts non-editable,
or set everything editable.
Does navigation still work then? That is, are there sufficient signals available from the WebKit API to update our navigation controls in Bibledit?
We could even use this in Bibledit-Web, when we set parts of html5 editable.


