Turnkey Moodle Upgrade Process - Frustrating

Firstly I just wanted to apologise for a tardy response...

TBH I'm not quite where to start in responding to you! :) I think first things first; TKL is no longer based on Ubuntu. It hasn't been since v11.x. As of v12.0 it has moved to Debian. We made that decision based on the fact that Debian is more stable and more secure (Ubuntu only has security updates for packages in the 'main' repo; whereas Debian does them all!). Hence I suspect why things broke badly when you added an Ubuntu repo...

Secondly as a seasoned Linux user (albeit RPM based rather than DEB based) you'd understand that it is not uncommon for packages to have security patches backported rather than versions updated. But as you also noticed, the TKL Moodle appliance is not installed from package management. The reasons for that are 2 fold. Firstly, when we built v11.0, the version of Moodle in Ubuntu 10.04 (the basis of TKL v11.x) repos was badly broken so we moved to upstream install. Then when we transitioned to Debian Squeeze (for v12.0) we stuck with upstream install as the Moodle version in Debian was earlier to what was in v11.x (and we didn't want to go backwards...).

I just read your thread over on SpiceWorks and I think another thing that may have been getting in your way a little is the default Debian style Apache config. Rather than a monolithic conf file (as i understand the case to be in RHEL et al) in Debian it is broken up and in various conf files in /etc/apache2.

I haven't actually tested it but IMO the upgrade.php method should work. I'm unfamilir with the intracies of Moodle, but often those upgrade.php type upgrades can be run from a web browser (but you'll first need to give www-data ownership of the /var/www/moddle directory tree). Otherwise run from commandline as root (www-data account has login disabled by default) although you'll need to change the permissions after running it as root will take ownership and Apache won't be able to run the php files properly after the upgrade... FYI the default TKL ownership settings can be found in the TKLDev build Main conf file.

Also FWIW as of v1.4 TKLBAM doesn't require a Hub/AWS account now although IIRC you'll need to download and apply the profile manually. I don't think that TKLBAM 1.4 is available in v12.x (although maybe? You could try apt-get install tklbam (although manually migrating may be easier than setting up TKLBAM v1.4 manually). Profiles can be found here. Note that they are not complete within themselves, i.e. the Moodle profile would also rely on the LAMP profile which in turn relies on the Core profile.

Finally, please don't ever be scared to post here... I have a SpiceWorks account and when I set it up I had intended to help out over there (as I noticed that there are quite a few TKL related threads) but in the interests of transparency I noted that I work for TurnKey and now they consider me a 'vendor' (which I suppose I am) but vendors can't post on any of the threads unless you pay a yearly subscription fee... I guess it's a way of encouraging organisations like us to pay to be on there, or push SpiceWorks users to preference software vendors that do pay. I guess it's a win-win for SpiceWorks and those vendors that do pay, but not so great for little guys like us that can't really justify the subscription fees... I also don't think that it gives the best outcomes for SpiceWorks users unless of course they use the software of paid up vendors...

Anyway let us know how you go and I'll help where I can.

Thanks for the reply Jeremy. I know I threw a bunch of info at you there in my OP. So how would you go about trying upgrade Moodle to 2.7 in TKL? I've been messing with it more today to no avail.

I looked and didn't see an obvious upgrade.php file in the web dirs for Moodle...

Thanks,

Jeff

FWIW I tweaked your post with the full url of the download.

Obviously make sure that you have a backup of your data before you do anything. I recommend TKLBAM but you can easily just do a DB dump and copy the /var/www/moodle and /var/www/moodledata directories if you'd rather. Regardless make sure you test your backup first!

Moodle recommend using a test server (that includes all your data) before you do it on your production server and that's probably not a bad idea either.

Unfortunately I don't have a real Moodle site to test on, so I just did this on a vanilla TKL Moodle:

cd /var/www
mv moodle/config.php config.php
rm -rf moodle/*
wget
http://downloads.sourceforge.net/project/moodle/Moodle/stable27/moodle-latest-27.tgz
tar -xvf moodle-latest-27.tgz
rm moodle-latest-27.tgz
chown -R root:root moodle
mv config.php moodle/config.php
php moodle/admin/cli/upgrade.php
chown -R www-data:www-data moodledata
chown root:www-data moodle/config.php

It all appeared to go well But after I did that Apache kept segfaulting (Chrome was reporting "No data recieved")... A bit of google and it seems that there is an issue with xcache on Wheezy (as included by default in TKL LAMP/Moodle appliances) and Moodle 2.7. So I removed that:

apt-get remove --purge php5-xcache
rm /etc/php5/conf.d/20-xcache.ini #need to remove this manually for some reason!?
service apache2 reload

Moodle now works but it's a bit sluggish (probably because there is no caching) so a bit more googling and I found that Moodle recommend opcache for 2.7. So I installed optcache:

apt-get install -y php-pear build-essential php5-dev
pecl install zendopcache-7.0.3

That installed it but it's not set up to be used by php. So let's do that...
You can note where it installed from the end of the text that the install spits out, but in case you missed it:

find / -name 'opcache.so'

The path mine installed to was:

/usr/lib/php5/20100525/opcache.so

Then you need to enable it. To make the config file:

vim /etc/php5/mods-available/opcache.ini

And put this in (note that the first line uses the file path as noted above):

zend_extension=/usr/lib/php5/20100525/opcache.so
opcache.memory_consumption=128
opcache.interned_strings_buffer=8
opcache.max_accelerated_files=4000
opcache.revalidate_freq=60
opcache.fast_shutdown=1
opcache.enable_cli=1

(<Esc>:wq to save and quit if you're not familiar with vim)
Then enable it with a symlink:

ln -s /etc/php5/mods-available/opcache.ini /etc/php5/conf.d/20-opcache.ini

Restart Apache:

service apache2 restart

Should be all good, just test that it's enabled:

php -v

Should give mention of

Zend Engine v2.4.0, Copyright (c) 1998-2012 Zend Technologies
    with Zend OPcache v7.0.3, Copyright (c) 1999-2014, by Zend Technologies

And with any luck you should be all good to go!

Also you can do a little extra tidying up:

apt-get remove --purge build-essential php5-dev

Yea - after my last reply I figured out that I was on v6 of Debian and not v7. (Sneezy versus Wheezy or whatever). I'm not "hip" w/ Debian lingo so apologies.

I tried updating to v7 on Friday but I think I messed up a prompt during the GRUB update because afterward it got stuck in a loop upon reboot. I'll try it out again today or tomorrow barring I have time and see where I can get. Thank you very much for your help! I'll update this thread with the results either way.

Sorry I totally missed that you're still on v12.x - doh!

You'll need to do something about that anyway as Debian 6 (aka Squeeze - the basis of v12.x) is officially EOL. Have a look at this blog post. v13.0 is based on Debian Wheezy (which has php5.4.x by default) so I suggest options 2 or 3. Once you've migrated/updated then follow my steps above.

To specifically answer your question: the root MySQL password should have been set (by you or whoever installed it) on firstboot. You can rerun the script to reset it though if you don't recall what it is. OTTOMh its:

/usr/lib/inithooks/bin/mysql.py

Jeremy - thanks for the reply. I ran into a problem where the default repos don't allow upgrade to php 5.4.4, which is required for Moodle 2.7+. I added deb http://ftp.us.debian.org/debian/ wheezy main non-free contrib to the sources.list and tried to update. In the process it is trying to update phpmyadmin, which requires db changes, which requires the default root admin password. I know I've come across this before but I can seem to find it in any of my notes. What is the default root mysql password for TKL?

Thank you for documenting and posting your process. I'm sure that others will benefit from it! It's sounds like its been a major PITA but we got there in the end! Yay!

Jeremy,

First I used this URL to reset the root MySQL pwd: http://dev.mysql.com/doc/refman/5.0/en/resetting-permissions.html. That was pretty straight-forward and easy.

I used this as a guide to upgrade Debian 6 to 7.5: (URL blocked due to spam detection..?). It's important to note that I had to modify both sources lists here: /etc/apt/sources.lists.d/security.sources.list & sources.list. I commented out the existing repo paths and added the ones from that referenced URL.

After that, the upgrade to Debian 7.5 (Wheezy) was fairly straight-forward. Some of the scripted tasks were a little bit misleading (ie: the grub update). I ended up skipping it and manually running 'update-grub' after the dist upgrade was completed.

With the Debian OS successfully upgraded, I tested to see if Moodle was still operating under 2.4.X (I hadn't updated it yet). It was throwing a MySQL error. I checked and the DB server wasn't running due to an error. A little interweb searching yielded this: http://forums.mysql.com/read.php?103,189835,237318#msg-237318. Apparently when MySQL upgraded, one of the directives in a cnf file was deprecated and no longer supported. I had to edit /etc/mysql/conf.d/force_utf8.cnf and add 'loose-' to the beginning of line 6. I know this isn't the best fix but it at least got the server up and running. It's still fussing about this line a little so I'll probably go back and look into a more permanent fix later.

With MySQL upgraded and working at this point, I tested my old Moodle site. It was working correctly now so I proceeded with your steps laid out above pretty much verbatim. It worked like a champ and took all of about 5 minutes. I didn't run into any issues that you hadn't already cited.

I did all this on a dev server (copy of my live production data from about a month ago). I'm having my Moodle admin check all the settings and content now to make sure we're good before upgrading the production site.

I wanted to thank you for your assistance with this. It was a huge PIA but it's all good now. I've put together a document internally for reference. I hope this post helps someone else out there who is possibly in the same or similar boat.

Thanks for posting as that's great in 2 ways! Firstly it's nice to get some positive feedback, but better still it's a solid hint that other (newer) webapps amy also benefit (or even require) the opcache upgrade.

From my understanding, once TKL appliance shift to a Debian Jesse base (after it is released as stable) then opcache will be the default and won't require any trickery!