Updating DokuWiki to weatherwax

Hi All,

I thought I should post this somewhere after I took the time to do it. I managed to update the Dokuwiki in turnkey linux from the old one to the new weatherwax.

It did this by first installing the current turnkey solution. And then sshing into the VM and executing the following instrucitons:

This got me to the new version... (It was not so simple, but I think I now follow what is going on...)

####### Turnkey linux update steps #######

# Update the version of dokuwiki in turnkey linux. Install the turnkey linux distribution as you normally would.

cd /usr/share/

# get the latest vesion

wget http://www.splitbrain.org/_media/projects/dokuwiki/dokuwiki-2013-05-10a.tgz

tar -zxvf dokuwiki-2013-05-10a.tgz

# copy media_attic media_meta into the place turkey stores the data

cp -r dokuwiki-2013-05-10a/data/media_* /var/lib/dokuwiki/data/.

chown -R www-data:root /var/lib/dokuwiki/data/media_*

# dokuwiki also needs these pages if they are not already there

cp -r dokuwiki-2013-05-10a/data/pages /var/lib/dokuwiki/data/.

chown -R www-data:root /var/lib/dokuwiki/data/pages

rm -r dokuwiki-2013-05-10a/conf/users.auth.php.dist dokuwiki-2013-05-10a/conf/acl.auth.php.dist # these conf settings are handled specially by turnkey

# very importantly in the new settings we have to change the default location of where the data directory is to /var/lib/dokuwiki/data which is where turnkey linux sets this up to be.

sed -i.bak "s@$.*savedir.*$\./data@\1/var/lib/dokuwiki/data@" /usr/share/dokuwiki-2013-05-10a/conf/dokuwiki.php

# set the correct permissions

chown -R root:www-data dokuwiki-2013-05-10a/conf/*

# remove the word block of the newer version since the turnkey version is sooo much more extensive

rm /usr/share/dokuwiki-2013-05-10a/conf/wordblock.conf

# copy over the remaining conf settings

mv -f /usr/share/dokuwiki-2013-05-10a/conf/* /etc/dokuwiki/.

# copy over the deleted files for the later cleanup

cp dokuwiki-2013-05-10a/data/deleted.files dokuwiki/deleted.files

# we have now handled the data and the conf settings

rm -r dokuwiki-2013-05-10a/conf dokuwiki-2013-05-10a/data

# copy over the rest of the new files into the installation

rsync -a dokuwiki-2013-05-10a/ dokuwiki/

# clean up

rm -r dokuwiki-2013-05-10a*

# remove all files that need to be deleted

cd dokuwiki

grep -Ev '^($|#)' deleted.files | xargs -n 1 rm -vf

rm -r deleted.files

Replies (3)

Firstly thanks for posting...

Reply 1 2013-10-11

But not to sound ungreatful, your process may have unwanted repercussions...

What you have done is overwritten an application that was installed by package management (see the DokuWiki appliance page) with upstream software. Whilst it has acheived your ends for now it is not good practice and not recommended. /usr/share should be handled exclusively by package management and should not be manually written to.

You may have a completely legitimate reason for wanting a newer version but doing that has implications (even if you do it the right way).

First thing to consider is why do you want a newer version? If it's for features or bug fixes then that is totally legitimate and reasonable reason. If it's to avoid security issues then not so much... Packages from the official Debian repos are 'frozen' at a particular version number but security fixes are backported (generally these are released quite soon after the security issues are made public). And that brings us to the reason why overwriting applications installed by package management with upstream source is a bad idea...

You server doesn't realise what you've done, it still thinks that you have the Debian package from the repos installed. So if a new (security bugfixed) version appears in the repos, your system will automatically install it (over the top of your new version). In a best case scenario, this will put DokuWiki back to an 'older' version and things will continue as normal (although you will be back where you started). But more likely if things have changed significantly between the versions it will break DokuWiki and it will display incorrectly; or worse still not work at all...

If you are using TKLBAM then a restore to a new server will acheive the same result.

So if you do wish to go ahead with a newer version of DokuWiki than what the TKL appliance comes with then I would highly recommend that you start with the LAMP appliance and install it as per upstream instructions. The LAMP appliance should be good to go, although you may need to install PHP-GD and Image MagicK (as per notes here - I don't think they are installed by default on TKL LAMP). You can install them with apt (search using apt-cache search; then install with apt-get install).

The other bonus of doing it that way, is that if you use TKLBAM, then your backup (whilst being a little larger than the default DokuWiki TKLBAM backup) should work perfectly on restore.

To minimise backup size it may be worth checking to see where DokuWiki stores it's cache and exclude that from your backup...

Thanks for illuminating response!

Reply 2 2013-10-11

Ahhh... Thanks for the detailed and very informative explanation. I am rather new to this side of things so thank you! (I am a developer by trade) I wanted a newer version for features and compatibility for newer plugins and templates.

I definitely don't want to cause any security issues!!

However, given the difficulty of doing what I did and your explanation above then maybe it is best to just work round the problems.

Using a fresh LAMP stack would also then be a good approach. In general is this the preferred way to do things? I can imagine if I am using something like DokuWiki, or Zurmo, or Redmine or something and then the application comes out with a really nice new feature that users want, what is the best approach to deliver this then during this time where we are waiting for catchup from the official Debian repos? Transition everything over to a LAMP stack and then back again once the official Debian repos are up to date?

It would seem to me somehow that in the overall setup that it would be nice to be able to more easily overlay the latest upstream application changes on a solution. This is all sort of happening to some degree I guess with the latest turnkey git "make" solutions in any case. It would be somehow nice if it could be made to work with the newer things as well?

Thanks again for the great response!

Actually just to update this

Reply 3 2013-10-12

Actually just to update this further. I thought the turnkey linux verison was Adora Belle.. It turns out that the version that turnkey linux is shipping is "Lemming" which is just two months shy of 4 years old!! There has been:

Release 2013-05-10a "Weatherwax"

Release 2012-10-13 "Adora Belle"

Release 2012-01-25c “Angua”

Release 2011-05-25c “Rincewind”

Release 2010-11-07a “Anteater”

and then finally the version shipping with the offical debian repos:

Release 2009-12-25c “Lemming”

All of the themes and plugins and basically anything from the dokuwiki site just are not working with such an ancient version of dokuwiku. Somehow this situtation then is non-optimal. Ie there is a nice turnkey way to install a dokuwiki which is virtually obsolete in the current eco-system. It seems somehow that the situation should be improved, and upstream versions should be worked into the system in a better way? Currently I note that the bitnami stacks are installing "Weatherwax"