Koozali.org: home of the SME Server
Obsolete Releases => SME 8.x Contribs => Topic started by: varuna on July 22, 2013, 09:46:01 AM
-
Hi everyone,
Moodle (acronym for Modular Object-Oriented Dynamic Learning Environment) is a free software e-learning platform, also known as a Learning Management System, or Virtual Learning Environment (VLE). As of June 2013 it had a user base of 83,008 registered and verified sites, serving 70,696,570 users in 7.5+ million courses with 1.2+ million teachers. [wikipedia]
The latest version of Moodle is 2.5 (as of today) and the latest version of SME Server is 8.0 (as of today). Moodle requires PHP 5.3.3 (built in to SME8.0 ) and MySQL 5.1.33 (SME8 has 5.0.95).
There exists a problem as the latest mysql (5.5.32) does not work properly and fails to load up in SME8.
We have made an rpm that includes the latest Moodle 2.5 and figured out a way in getting MySQL to start.
The below steps is how we did this.
We first enable the InnoDB property of mysqld service.
/sbin/e-smith/db configuration setprop mysqld InnoDB enabled
Expand configuration to register
/sbin/e-smith/expand-template /etc/my.cnf
Then we fetch the latest MySQL 5.3.3 from the atomic repository as so:
/sbin/e-smith/db yum_repositories set atomic repository Name 'Atomic EL5' MirrorList 'http://www.atomicorp.com/mirrorlist/atomic/centos-5-$basearch' GPGCheck yes GPGKey 'https://www.atomicorp.com/RPM-GPG-KEY.art.txt' Visible no
Signal event now to register the yum command in accepting the added repository above:
/sbin/e-smith/signal-event yum-modify
Finally we yum install the MySQL with the command:
/usr/bin/yum -y --enablerepo='atomic' install mysql
At this point, MySQL still fails to start up properly. For are going to be adding a template that is related to InnoDB.
We first make the directory of the file we want to expand: (read SME Developer Manual to understand the logic behind why we do this)
/bin/mkdir -p /etc/e-smith/templates-custom/etc/my.cnf/
The template that we want to expand to form my.cnf: call it 009innodb and have the following contents:
{
my $innodb = $mysqld{InnoDB} || 'disabled';
return "skip-innodb" unless $innodb eq 'enabled';
# innodb is enabled. We'll use the MySQL-AB-recommended innodb
# defaults for small to medium sites, from the my-medium.cnf file
# distributed with MySQL
$OUT .= "innodb_data_home_dir = /var/lib/mysql/\n";
$OUT .= "innodb_data_file_path = ibdata1:10M:autoextend\n";
$OUT .= "innodb_log_group_home_dir = /var/lib/mysql/\n";
$OUT .= "innodb_buffer_pool_size = 16M\n";
$OUT .= "innodb_additional_mem_pool_size = 2M\n";
$OUT .= "innodb_log_file_size = 5M\n";
$OUT .= "innodb_log_buffer_size = 8M\n";
$OUT .= "innodb_flush_log_at_trx_commit = 1\n";
$OUT .= "innodb_lock_wait_timeout = 50\n";
}
We then copy this file to the template directory to be expanded:
cp /path/to/009innodb /etc/e-smith/templates-custom/etc/my.cnf/009innodb
Naturally, we finally expand this template to form my.cnf file:
/sbin/e-smith/expand-template /etc/my.cnf
All of the changes need to be registered in as post-upgrade and mysqld service would need to be restarted for the changes to take effect. Maybe a reboot command would be nice as well.
/sbin/e-smith/signal-event post-upgrade;
/usr/bin/sv t mysqld
The final step that we would want to do is install Moodle 2.5 over this.
We have made an RPM that installs the moodle directory in /opt/moodle/ . We would run the rpm installation command as:
rpm -i --nomd5 /path/to/moodle-2.5.0-01.noarch.rpm
You can find this RPM in my sourceforge.net project:
https://sourceforge.net/projects/moodle25forsmeserver80/
So this is how we did this. MySQL works well and seems to be compatible with Moodle. SME9 should support a much newer version of mysql that Moodle would support. What we did above is set up MySQL and play with SME8's default settings to make this work.
This is a good intermediate solution in my opinion before SME9 is released. Both moodle and SME8 seems to function as intended.
Thanks,
Varuna
-
interesting, thanks !
do you believe we can update moodle to the last version ?
-
I have tried to upgrade SME's MySQL to a 5.5 version or better with disastrous results. Somebody refered me to this post and I thought I'd try your solution. But I'm a little confused about what your target version upgrade is. I see:
There exists a problem as the latest mysql (5.5.32) does not work properly and fails to load up in SME8.
But later in the instructions you say,
Then we fetch the latest MySQL 5.3.3 from the atomic repository as so:
Is that a typo? Aren't you trying to upgrade to 5.5? Or is 5.3.3 enough for your purposes?
Please explain.
-
LANMonkey
It took 2 minutes to configure the atomic repo & go part way through the install to see what packages would be installed.
Here is part of the log, showing that mysql will be upgraded to 5.5.33-20
Package Arch Version Repository Size
================================================================================
Updating:
mysql i386 5.5.33-20.el5.art atomic 7.6 M
Installing for dependencies:
libXaw i386 1.0.2-8.1 base 324 k
libXmu i386 1.0.2-5 base 62 k
libaio i386 0.3.106-5 base 19 k
libedit i386 3.0-2.20090923cvs.el5.art atomic 80 k
mysql-libs i386 5.5.33-20.el5.art atomic 1.1 M
mysqlclient15 i386 5.0.90-2.el5.art atomic 1.4 M
t1lib i386 5.1.2-2.el5.art atomic 194 k
Updating for dependencies:
mysql-server i386 5.5.33-20.el5.art atomic 13 M
php i386 5.4.21-27.el5.art atomic 3.2 M
php-cli i386 5.4.21-27.el5.art atomic 3.1 M
php-common i386 5.4.21-27.el5.art atomic 1.1 M
php-devel i386 5.4.21-27.el5.art atomic 3.1 M
php-gd i386 5.4.21-27.el5.art atomic 216 k
php-imap i386 5.4.21-27.el5.art atomic 93 k
php-ldap i386 5.4.21-27.el5.art atomic 66 k
php-mbstring i386 5.4.21-27.el5.art atomic 1.2 M
php-mysql i386 5.4.21-27.el5.art atomic 171 k
php-pdo i386 5.4.21-27.el5.art atomic 126 k
php-xml i386 5.4.21-27.el5.art atomic 221 k
Transaction Summary
================================================================================
Install 7 Package(s)
Upgrade 13 Package(s)
Total download size: 36 M
Is this ok [y/N]:
*************************************************
Another approach for yourself or other users wanting newer packages eg mysql, php etc, is to start using sme9.
I know you'll say, oh it's still beta & risky, but probably it's a safer option to use the sme9beta2 or beta3 OS software, than it is to upgrade sme8 with newer key packages which may or may not cause problems in time.
Keep in mind sme9 is using well proven CentOS 6 packages, so it's only the sme server specific additions & code that are really in beta stage.
Historically sme betas for past releases have been very good & most functions are operating once beta 2 or 3 is reached.
I know of people who used sme betas in production for 2 years without any real problems before the final release happened.
Try sme9 for yourself & see, it could be an easier, safer & better outcome.
I think the only real issues with sme9 beta 2 are installer based, note that beta 3 is almost released, an iso is in the hands of developers for testing, or it can be downloaded if you are in a hurry to get it, search the dev mail lists or ask here for the location.
Also see http://forums.contribs.org/index.php/topic,50337.0.html
-
I am using SME 9 alpha 3. When I check the version of MySQL on this SME, I find:
mysql Ver 14.14 Distrib 5.1.69, for redhat-linux-gnu (i386) using readline 5.1
This is not as late a version as I need.
I tried the above procedure and when I got to:
Finally we yum install the MySQL with the command:
/usr/bin/yum -y --enablerepo='atomic' install mysql
The procedure was halted with errors:
....
--> Finished Dependency Resolution
Error: Package: php-imap-5.4.23-29.el5.art.i386 (atomic)
Requires: libc-client.so.1
Error: Package: php-common-5.4.23-29.el5.art.i386 (atomic)
Requires: libcurl.so.3
You could try using --skip-broken to work around the problem
You could try running: rpm -Va --nofiles --nodigest
The last time I tried to install a later version of MySQL, I had similar problems with PHP packages:
http://forums.famillecollet.com/viewtopic.php?pid=5320#p5320
-
I am using SME 9 alpha 3. When I check the version of MySQL on this SME, I find:
...
The procedure was halted with errors:
...
maybe trying with EL6 /RHEL6/CentOs6/SME9 repo instead of EL5/RHEL5/centOs5/SME8 repo would help ??
/sbin/e-smith/db yum_repositories set atomic repository Name 'Atomic EL5' MirrorList 'http://www.atomicorp.com/mirrorlist/atomic/centos-5-$basearch' GPGCheck yes GPGKey 'https://www.atomicorp.com/RPM-GPG-KEY.art.txt' Visible no
-
maybe trying with EL6 /RHEL6/CentOs6/SME9 repo instead of EL5/RHEL5/centOs5/SME8 repo would help ??
/sbin/e-smith/db yum_repositories set atomic repository Name 'Atomic EL5' MirrorList 'http://www.atomicorp.com/mirrorlist/atomic/centos-5-$basearch' GPGCheck yes GPGKey 'https://www.atomicorp.com/RPM-GPG-KEY.art.txt' Visible no
That did it. I applied,
/sbin/e-smith/db yum_repositories set atomic repository Name 'Atomic EL6' MirrorList 'http://www.atomicorp.com/mirrorlist/atomic/centos-6-$basearch' GPGCheck yes GPGKey 'https://www.atomicorp.com/RPM-GPG-KEY.art.txt' Visible no
Installation went ahead, I check the version and I see,
mysql Ver 14.14 Distrib 5.5.33, for Linux (i686) using readline 5.1
-
Previous message deleted.
Other's hoping to upgrade their MySQL using the above instructions, make sure you do ALL of the instructions, including the template and its expansion.
-
I also managed to install this upgrade for MySQL on my regular 8.0 server. Since making this installation I am having errors when my upgrades run.
My email messages from Cron <root@finch> /sbin/e-smith/do_backupwk say,
Backup terminated: pre-backup failed - status: 256
I check my logs /var/log/messages for messages and find when searching "backup",
Dec 21 10:00:02 xxxxx esmith::event[6488]: S20mysql-dump-tables=action|Event|pre-backup|Action|S20mysql-dump-tables|Start|1387648802 266242|End|1387648802 852948|Elapsed|0.586706|Status|256
Can I confirm that this upgrade is the problem? If it is the problem, how do I correct it?
Is there a way to uninstall this upgrade?
-
Try running the "pre-backup" event manually to see if there are any informative error messages:
/etc/e-smith/events/actions/mysql-dump-tables
-
Try running the "pre-backup" event manually to see if there are any informative error messages:
/etc/e-smith/events/actions/mysql-dump-tables
OK. I ran,
/etc/e-smith/events/actions/mysql-dump-tables
And got,
mysqldump: Got error: 1044: Access denied for user 'root'@'localhost' to database 'information_schema' when using LOCK TABLES
I did a quick search on Google for that error and found a discussion at MySQL forums here:
http://forums.mysql.com/read.php?10,108835,108835#msg-108835
They say,
You must grant "LOCK TABLES" to your user.
GRANT SELECT,LOCK TABLES ON database.* TO 'username'@'localhost';
So I tried,
GRANT SELECT,LOCK TABLES ON information_schema.* TO 'root'@'localhost'
and got back,
ERROR 1044 (42000): Access denied for user 'root'@'localhost' to database 'information_schema'
which seems kind of an odd thing to issue to root who issued the command in MySQL. Searching the forums here for "mysqldump 1044" doesn't pull anything up.
-
I think the 'root' account in your mysql is skeewonky.
You should be able to enter the command 'mysql' (with no other arguments) and get a mysql client prompt -- can you?
What is the root password stored in ~/.my.cnf (note the dot)? Do you enter it why you run mysql at the command prompt?
-
I think the 'root' account in your mysql is skeewonky.
You should be able to enter the command 'mysql' (with no other arguments) and get a mysql client prompt -- can you?
What is the root password stored in ~/.my.cnf (note the dot)? Do you enter it why you run mysql at the command prompt?
Yes, I can just type "mysql" and log into mysql as root. There is a password in ~/.my.cnf that is huge and I have never used it. I might add that I did some things to password functions when I installed MariaDB as linked here:
http://forums.contribs.org/index.php/topic,50433.msg253660.html#msg253660
And here is the link:
http://wiki.contribs.org/User_talk:Mmccarn#Install_mariadb_.27alongside.27_mysql
You might note that I had some confusion about some procedures setting root that I mention in the thread containing the link.
-
What is the root password stored in ~/.my.cnf (note the dot)? Do you enter it why you run mysql at the command prompt?
You don't need to use it. It's used implicitly by mysql. The whole point of /root/.my.cnf is to make it possible for root to run the mysql command without supplying the root password.
-
Yes, I can just type "mysql" and log into mysql as root. There is a password in ~/.my.cnf that is huge and I have never used it. I might add that I did some things to password functions when I installed MariaDB as linked here:
Well you shouldn't have done, or you shouldn't have done that without first verifying on a test install.
You will have to reset the mysql root password before backup will start to work again.
-
I have reset the password according to instructions here:
http://wiki.contribs.org/MySQL#Resetting_the_MySQL_root_password
cd /var/service/mysqld
sv d .
expand-template /root/.my.cnf
expand-template /var/service/mysqld/set.password
/usr/libexec/mysqld --bootstrap --user=mysql --skip-grant-tables < ./set.password
sv u .
But when I run,
/etc/e-smith/events/actions/mysql-dump-tables
I am still getting the same errors:
mysqldump: Got error: 1044: Access denied for user 'root'@'localhost' to database 'information_schema' when using LOCK TABLES
-
From that same MySQL manual page, I disable the InnoDB engine,
db configuration setprop mysqld InnoDB disabled
expand-template /etc/my.cnf
sv t /service/mysqld
And now the error returned when I manually run mysql-dump-tables is,
ERROR 2002 (HY000): Can't connect to local MySQL server through socket '/var/lib/mysql/mysql.sock' (2)
From the manual page again, I restore the InnoDB tables,
db configuration setprop mysqld InnoDB enabled
expand-template /etc/my.cnf
sv t /service/mysqld
and once again I get error 1044.
mysqldump: Got error: 1044: Access denied for user 'root'@'localhost' to database 'information_schema' when using LOCK TABLES
I tried scheduling a backup through the server-manager after disabling InnoDB and I am getting reports again about successful backups. But, the user preferences in the email are not available. I get a little report at the top of the mail display,
The preferences backend is currently unavailable and your preferences have not been loaded. You may continue to use the system with default settings.
So disabling InnoDB appears to disable the default settings in Horde. Horde is still otherwise working OK.
It looks as though InnoDB might play a role. How to fix the user preferences in Horde? What else in SME uses the InnoDB tables that might be effected?
-
Try adding the "-x" option to mysqldump:
for db in $(mysql -BNre "show databases;"); do mysqldump -x --add-drop-table -QB "$db" -r /home/e-smith/db/mysql/"$db".dump || exit 1; done
I had to do this when adapting /etc/e-smith/events/actions/mysql-dump-tables to backup mariadb:
http://wiki.contribs.org/User_talk:Mmccarn#.2Fetc.2Fe-smith.2Fevents.2Factions.2Fmariadb-dump-tables
-
OK. I copied and pasted that code into my PuTTY command line and entered it and PuTTY promptly exited. I logged back in and looked in the directory that was the target for the dump and found "information_schema.dump. That was the only .dump file there.
-
I have also installed this database on SME 9.0 Beta 2. Logged on to this server, I run,
/etc/e-smith/events/actions/mysql-dump-tables
and get an entirely different error,
mysqldump: Couldn't execute 'SELECT /*!40001 SQL_NO_CACHE */ * FROM `PARAMETERS`': Cannot load from mysql.proc. The table is probably corrupted (1548)
But if I schedule a backup through the server-manager, I get the same errors that I get in SME 8.0,
Backup terminated: pre-backup failed - status: 256
-
I did a little research on the error I get when running mysql-dump-tables in SME 9.0 Beta 2 and made some progress
mysqldump: Couldn't execute 'SELECT /*!40001 SQL_NO_CACHE */ * FROM `PARAMETERS`': Cannot load from mysql.proc. The table is probably corrupted (1548)
and found this tip here:
http://dba.stackexchange.com/questions/956/resolving-issue-with-mysql-proc-after-upgrading-mysql-from-5-0-to-5-1
On SME 9.0 Beta 2, I tried running,
mysql_upgrade --force
/usr/bin/sv t mysqld
And now I get no errors back when I run, " /etc/e-smith/events/actions/mysql-dump-tables"
On SME 8.0, I tried doing the same thing, but continue to get the same errors back when I run mysql-dump-tables:
mysqldump: Got error: 1044: Access denied for user 'root'@'localhost' to database 'information_schema' when using LOCK TABLES
So since I am getting no errors back when I run mysql-dump-tables in SME 9.0 Beta 2, I assume the problem is solved there. I wanted to try running a scheduled backup, but for some reason, I cannot access my user share on my Windows Home Server from this Beta machine.
-
Try adding the "-x" option to mysqldump:for db in $(mysql -BNre "show databases;"); do mysqldump -x --add-drop-table -QB "$db" -r /home/e-smith/db/mysql/"$db".dump || exit 1; done
I had to do this when adapting /etc/e-smith/events/actions/mysql-dump-tables to backup mariadb:
http://wiki.contribs.org/User_talk:Mmccarn#.2Fetc.2Fe-smith.2Fevents.2Factions.2Fmariadb-dump-tables
I completely misunderstood this instruction. I thought the poster was recommending a command line to test the installation. No, the poster was talking about actually altering the file /etc/e-smith/events/actions/mysql-dump-tables. I did this as instructed and ran that script - which is what I had been doing - /etc/e-smith/events/actions/mysql-dump-tables and only got the following error message:
-- Warning: Skipping the data of table mysql.event. Specify the --events option explicitly.
I tried scheduling a backup and the backups are working.
[PROBLEM SOLVED]
-
I'm back again for this fix. An update or something has replaced the mysqldump script with one without the "-x".
-
I have tried all of the above fixes, but I am still having problems. To review, I've done the following,
Added the "-x" in the code below in mysqldump:
for db in $(mysql -BNre "show databases;"); do mysqldump -x --add-drop-table -QB "$db" -r /home/e-smith/db/mysql/"$db".dump || exit 1; done
Tried restoring the password as outlined here:
http://wiki.contribs.org/MySQL#Resetting_the_MySQL_root_password
cd /var/service/mysqld
sv d .
expand-template /root/.my.cnf
expand-template /var/service/mysqld/set.password
/usr/libexec/mysqld --bootstrap --user=mysql --skip-grant-tables < ./set.password
sv u .
I also have tried enabling and disabling the InnoDB tables as described above.
I am now getting this error when running the /etc/e-smith/events/actions/mysql-dump-tables script:
"mysqldump: Couldn't execute 'show create table `atkin_relations_reord_vw_2`': View 'connectivity.atkin_relations_reord_vw_2' references invalid table(s) or column(s) or function(s) or definer/invoker of view lack rights to use them (1356)"
There appears to be another problem with root again.
Any ideas, anyone?
-
I assumed this was another problem with root. It is not, I deleted the offending views and this problem is gone.