Update bibledit-web helpfiles.
Release bibledit-web




 











Since there is nothing at http://download.savannah.nongnu.org/releases/bibledit/source/web/bibledit-web-0.5.tar.gz
why not tell people to use the Savanah repostitory? Won't that be a rather permanent way of getting the newest version.


Using the brand new install of Ubuntu 11, and doing everything right from top to bottom, I still get an error message about installing Java following
apt-get install make git-core curl default-jre zip unzip libzend-framework-php!!!!


Now using Ubuntu 10 longterm support.
Used 
sh /usr/sbin/quickinstall.sh
to install #1 Apache, PHP, Mysql
did 
sh /usr/sbin/quickinstall.sh
and #3 for updates, but I think they were already installed in #1.

Did apt-get install default-jre right away to see if it will install.
It installed! Ubuntu 11 was the problem. It works with Ubuntu 10! OR perhaps the difference could be that I used the quickinstall.sh to install the same three that are part of Linux Apache Mysql PHP (LAMP).


Here are a few more of my notes:


Get the latest version of BE-web by doing this in the server terminal:
git clone git://git.savannah.nongnu.org/bibledit.git

Tried to ./configure in /bibledit/web/
but it says PHP is not installed. Used tasksel, and it says LAMP is installed.
Tried various things, and finally:
apt-get install php5-common libapache2-mod-php5 php5-cli
(Perhaps I should have used tasksel initially instead of quickinstall!)

Using apt-get worked THEN it ./configured!
You haven’t told how to get a backup into a VPS server.
I had to apt-get install wget.
But then where to put it so that I can wget it!
Could not download it from box.net or eyeos, but downloading it from bahasakita.net worked. Remove the ?attredirects=0&d=1 from the end of the file name and use http: not https:
The mysql commands worked fine.
There is just a file that is left over from a bad download, and it has a weird name that can’t seem to be deleted from the ssh terminal. Aha!
Delete it by using a wild card and then you are asked for each one:
rm bahasakita.bak.*


Contrary to the note in the Administration > Backup/Restore  page the send/receive parameters seem to have been restored when I restored the database.
By the way, I would change the name of Admin > Backup to Backup and Restore.


Mail now works! How often does mail with changes get sent? Is there a setting for this? The mail makes it sound like I will see the changes in colors within the text of the e-mail itself. My email did not show the changes. But I DO see them when I click on the links at the top of the e-mail. Please tell me if I am seeing things as intended within my e-mail. 


This is terrific. I am going to have my partner enroll in these e-mails!


I have two small suggestions, one was mentioned before:
*How about making it so that the Translation top line link went directly to the editing page? The Styles link can be moved to Management. 
*It would be nice if the initial screen gave the log-in blanks as well as the Help link. It would save moving the mouse and clicking. And because BE seems to time out quickly, this would save effort multiple times per day. (How long is the time out delay? I use Lastpass and have it set to automatically log me on. )




















LinkedWeb.
To count the verses in each chapter in the preprocessing phase.
Each chapter links to all the verses.
Each verse links back to the start of the chapter.
Very important for the cell phone.
More important is that each chapter needs to go into its own file,
so that there is less memory on the cell phone.























To have a module to daily export a GoBible. 


I am wondering if you would be willing to add Sword and GoBible exports from the GTK version to the exports that are in the Web version. 
Also, how about PDF book exports as well?




Also, I was pleased to see that I would be able to edit in the Web version using my Nook that has been rooted to become an Android 3.0 tablet. 
By enlarging the font with a gesture and turning the unit to the side, I was able to get the pages (both editable and the HTML exports) to reformat to fit the screen. 
However the verse editing window would not reformat. 
I wonder if you might be willing to make that window also variable in size. 
I think a tablet would make a good device for an MTT. 
I am using the MessageEase keyboard, and find that I am accurate at entering text with that, more than other keyboards.



It would be nice to put the log-in window directly on the front page, so one does not have to do the extra click just to log in.




Where your instructions say:
Test the web server. Open the site in the browser. It should say something like

It works!

I suggest that you change it to

Test the web server by opening a browser and typing in this address:

http://localhost/

 It should say something like

It works!

Where it mentions this link: http://site.org/bibledit/setup.php
There should be the option given that if they are doing this on their local computer that the address will be
http://localhost/bibledit/setup.php




To add to the problem, when I try to sign up for a new account, and I put in my e-mail address, no e-mail gets sent.











Windows: http://www.wampserver.com/
Or: http://www.apachefriends.org/en/xampp-windows.html
Easiest: EasyPHP.


















Where help is needed: 
Would need to write the software for the project under the GPL, stated in each source file.
Could fully adapt the software to run on Windows, and describe how to install it, 
and create a Windows installer and describe how to do that through open source tools. 
Same for Macintosh. 
Would communicate through bibledit-development.
Could write manuals for how to work with Bibledit-Web. 




































Producing a sword module for Katana.
Use usfm2osis.pl
If all .usfm files are in subdirectory ndebele, do this:
perl usfm2osis.pl Bible ndebele/*.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, and the location of the
webroot of the web server.  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.

LACK OF $(DESTDIR):

I've also found what seems to be the same kind of issue I found earlier
in the bibledit-gtk Makefiles, where an install-data-local target does
not use $(DESTDIR).  This time the issue is in web/Makefile.am where the
four lines under the install-data-local: target need $(DESTDIR) before
$(WEBROOT).

Fixing that still leaves it installing directly into the root of the
default host, /var/www/, which is not allowed, but that's a different
issue, more related to the "configuring too early" problem noted above.

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".

INSTALLATION HELP:

The help button points to help/001ubuntu1004server.php but this is
specifically for 0.1, and the codebase is 0.2.  Are there any
differences?  Also, this file says in part:

  If the site is "site.com", then this will be something like:
  http://site.org/bibledit/setup.php

You can use either site.org or site.com, but they need to match :)
Using example.com is common for this kind of text, incidentally.

SUMMARY:

As far as I can see, the bibledit-web 0.2 codebase pretty much requires
that it be built from source, locally for each individual installation.
 That is the exact opposite of what packaged software does (build it
once, then distribute the resulting compiled binary package around the
world) :)  Since bibledit-gtk doesn't require this
unique-per-installation build, I'm not sure why bibledit-web does, or
what the benefit of this approach is.  I rather suspect that in trying
to make things "friendly" for people installing it from source, the
software has been made hard or impossible to install as a package.

Hoping we can find a good approach to packaging bibledit-web,




I now have a hacked-up bibledit-web 0.2 package that more-or-less does
what the source install does, and installs on a test virtual server.
But it's much too rough to release, it breaks many rules, and won't even
build in a PPA, never mind in the official builders.

A few more comments and questions arising from this:

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!).

I have not checked whether this issue is fixed in the latest git
development code; I probably should :)

LIBRARIES:

Is there a list somewhere of what libraries are needed by bibledit-web,
or are incorporated as copies (or modified copies) within it?  So far I
have found:

 * jquery
 * jwysiwyg (a plugin for jquery)

Are there any more?  At least the non-modified ones have to be packaged
separately, if packaged versions of them don't already exist.  
