Booktype is a web application for writing, editing, and publishing books that keeps collaboration in mind every step of the way.

Here's the promo blurb from Sourcefabric (source):

Booktype is a free, open source platform that produces beautiful, engaging books formatted for print, Amazon, iBooks and almost any ereader within minutes. Create books on your own or with others via an easy-to-use web interface. Build a community around your content with social tools and use the reach of mobile, tablet and ebook technology to engage new audiences.

There's an open demo here.

Compared to Sourcefabric's other open projects, the documentation is disappointing: https://github.com/sourcefabric/Booktype/blob/master/INSTALL. Booktype relies on Django and either sqlite3 or postgres.
 What little I know about Django I picked up from working toward a patch solution for this; I find patching appliances that are reliant on postgres quite a challenge. Keeping all this in mind: I couldn't get this build on a TKL LAPP stack or a Django appliance. I have in the past, but couldn't recreate the process.

I did have success, however, building a patch for Core 12RC that uses Apache2 and mod_wsgi.

This patch disables default apache site, and relies on sqlite3 where Postgres is recommended (but not documented).

It has a cludge of an inithook to set the superuser password and email for Booktype. I'll elaborate more very soon.

There's discussion here with a particularly helpful post if this patch were to be revised with a more elegant inithook in mind.

Forum: 

I have built and revised this so much I know longer have build notes that make sense. Here's the conf script with elaboration:

#!/bin/bash -ex

#overlay: /etc/confconsole/services.txt
#overlay: /usr/lib/inithooks/firstboot.d - runs booki.env followed by django-admin createsuperuser

#Set Hostname
HOSTNAME=booktype
echo "$HOSTNAME" > /etc/hostname
sed -i "s|127.0.1.1 \(.*\)|127.0.1.1 $HOSTNAME|" /etc/hosts

#install function; unnecessary in this case
install()
{
    apt-get update
    DEBIAN_FRONTEND=noninteractive apt-get -y \
        -o DPkg::Options::=--force-confdef \
        -o DPkg::Options::=--force-confold \
        install $@
}

#Install from Repos
install libapache2-mod-wsgi \
    python-django \
    python-dev \
    python-django-south \
    sqlite3 \
    git-core \
    python-setuptools \
    python-pip \
    redis-server \
    libxml2-dev \
    build-essential \
    libxslt-dev \
    python-imaging

#Python imaging might need more for graphics to publish. Don't know what, however.

#Easy Install; other easy_install candidates are handled with apt above
easy_install lxml

#Pip
pip install unidecode

#Clone Source (git)
git clone https://github.com/sourcefabric/Booktype.git /opt/booktype/

#create the thing at /var/www/booktype, with settings.py configured for sqlite.
/opt/booktype/scripts/createbooki --database sqlite /var/www/booktype

#hard to script for me; I try to avoid changing directories in scripts, but I couldn't find a way around it.
#straight from the docs, except loaddata is done before createsuperuser.

cd /var/www/booktype
. ./booki.env
django-admin syncdb --noinput
django-admin migrate
django-admin loaddata documentation_licenses
cd ~

a2dissite default
a2ensite booktype
service apache2 reload
chown -R www-data:www-data /opt/booktype/
chown -R www-data:www-data /var/www/booktype/
L. Arnold's picture

I am interested both in integrating the PIP commands into TKLDEV and moreover I am interested in the BookType App.  Seems very interesting.

Might be a good time to get it out for V14 release ??

Sorry to hijak the forum post on other questions a while back.  I can't see the posts but expect they were also about PIP then.  I went through this before building a "home brew" Odoo.  Happy so far w/ TKLDEV ISO but trying to get one more piece in to link w/ ODOO.  My homebrew mod of ISO works well but need PIP in tkldev.

I will read more about Booktype and related apps.

 

L. Arnold's picture

Rik et al:

I understand the .conf script to be for building new Patches...  I am wondering thoughts on how to "move" patches from TKL Generations to new ones.

If one builds, say a 11.1 Patch, then applies the same patch to 11.2 or 11.3 or perhaps 11.3 then runs a TKLBAM Restore will the full old Dataset also move forward?

I ask because I would like to be building more patches for my own use but worrry about getting them stranded when the systems update generationally.

Also, as I noted in a different post/comment:  Is there a way to load a "Patched ISO" to the TKL Hub?  Would seem to speed the testing process.

thanks for your work here and elsewhere.

Jeremy Davis's picture

But in practice it will depend. You may have to tweak TKLBAM to ensure all the data is included. But it should be relatively straight forward.

Where it becomes problematic is when you move from a patched appliance to an official appliance. In that instance I would probably recommend a manual migration. Although perhaps TKLBAM would work ok?

Also FYI it's generally not required to update from one minor version to the next (ie from 11.2 to 11.3) These updates are more for new users that don't want to wait for all the security updates to download. If your appliance is up to date (ie all updates downloaded and installed) then there is generally no advantage to going to the new version. Issues such as the udev bug make doing a full upgrade a bit of a pain though.

L. Arnold's picture

(I misread "required" for "recomended"...  so strke all this.

I thought that was protocol.  I have had a few problems with it to be sure, but not consistently.  I was thinking the new features  (like being able to move a server to the Hub Cloud made it possible to do this.  Seems to be built into the hub.

I have not been able to Move Magento, but I have been able to move Joomla.  Both have had upgrades along the way but I think the base Ap software are manual upgrades (or internal ones anyway).

Will see if we can do some "Gen same to Gen same l" migrations on problem sets..

I do think though that the 11.x to 11.x word would be that you "can do that" and more difficult 9.x to 10.x or perhaps 11.x to 12.x which will be unfortunate once 12.x shows up.

Jeremy Davis's picture

But as you suggest going between major version (ie v11.x to v12.x) may involve a bit more effort. This will especially be the case when the software itself has had major updates. Often between major software updates things like DB schemas can change significantly - to the point of the software not working until the DB is updated. Often there are 'migration' scripts available from upstream which will help you out there (by changing the DB layout to be compatible with the new version).

Works perfectly. Couldn't go more smoothly.

Add new comment