I am currently running Moodle v2.3.2 and I am upgrading to v2.9, however, I'm having issues updating the plugins. In CentOS I've followed all of the examples provided in the MoodleDocs but these changes are not registering on the installation page. Any ideas?
Do you have command line access to your server?
Does server meet requirements for version of PHP?
Please see:
https://docs.moodle.org/23/en/Converting_your_MySQL_database_to_UTF8
Doc linked above shows how to use vim and sed, but on CentOS the nano editor could be used as well - search/replace function in that editor works well and the interface might be a little more user friendly than vim.
Get the DB converted to UTF8 first ...
The unsupported_db_table_row_format can be fixed via command line once you get the 2.9 code and a config.php file from the 2.3 site is at the moodle code root. Can run the following command even before attempting the upgrade because it reads information it needs from the config.php file.
As root user:
cd /pathtomoodlecode/admin/cli/ (on standard CentOS, more than likely path is /var/www/html/ and the moodle code could be in 'moodle'. The script below is found in moodlecode/admin/cli/
php mysql_compressed_rows.php
As far as the php extensions missing and recommended, acquiring them dependent upon the yum repos you've installed.
yum repolist as root user will show what repos are configured and enabled.
You can install the missing php extensions via this command (in general and as an example):
yum install php54w-intl *IF* webtatic's repo being used.
Odd that you have PHP 5.4.4 with zend-opcache NOT enabled as zend-opcache comes as part of the 5.4 -> PHP packages now and that's normally enabled by default.
If you upgraded the PHP did you also check to see if there is a php.ini.rpmsave file in /etc/?
That's the new ini file for your new version of PHP. Probably best to use it. (don't erase the old one, however, just rename it to something like php.ini.old. That way, you can check whatever tweaks you may have done before and forgot so you can add similar to the new config.
Changing .ini files like that will require apache service to be restarted.
'spirit of sharing', Ken
Hi Ken,
Yes I currently have command line access to the server. As far as I am aware the server does meet the requirements for the recommended version of PHP. As for the Latin1 to UTF-8 conversion... will I able to use the same commands that are provided in the MoodleDoc to perform this conversion? I believe in this case the path for the Moodle is /etc/admin/cli - though I have not yet had a chance to verify this. I have used the "yum install..." command to install the php_intl, soap, and zip (I think). Also, how do I go about restarting the apache service? I have tried the httpd service restart Thanks so much for your help and advice! It is much appreciated.
Knowing what version of CentOS would help ... two things:
cat /etc/redhat-release
and
uname -an
Let's make sure about PHP ...
php -v
Will show the version of PHP (at least the command line) which should match what Apache will use.
php -m
Shows the php extensions installed.
At the bottom of the above command output, one should see:
Zend OPcache
zip
zlib
[Zend Modules]
Xdebug
Zend OPcache
The versions of the extensions need to match the executable php.
And may as well check MySQL/MariaDB
mysql -V
On a typical CentOS machine, web root is usually: /var/www/html/
The moodledata directory is in /var/www/ but could be located on the largest partition.
moodledata should also have user:group set to apache:apache (the user:group httpd runs under) and be writeable to both.
To assure that:
cd /var/www/
If you can ls moodledata there, execute:
chown apache:apache moodledata -R
The code for Moodle could be inside html or in a directory 'moodle' ... depending upon what method used to acquire the code the first time.
Would also help to know what repos the system is set to use. Why? Version 5/6 of CentOS repos that point to CentOS may not supply the versions of PHP nor MySQL/MariaDB needed to reach 2.9.
What does: yum repolist
show?
To restart any service running:
/sbin/service [nameofserver] restart
On CentOS, apache is really httpd daemon. So to restart it:
/sbin/service httpd restart
Check for the existence of a php.ini.rpmsave file in /etc.
ls /etc/php* will show all files/directories that reside in /etc/ and begin with php
If php.ini.rpmsave exist, that's the one you should be using for your upgraded php.
AS root:
cd /etc/
mv php.ini php.ini.old
cp php.ini.rpmsave php.ini
To edit php.ini
nano php.ini
Set time zone as desired. There will be more edits required to get Moodle 2.9 to function as desired.
[ctrl][w] put in search term: timezone [ENTER]
Once the time zone entered, save the file:
[ctrl][w]
Save with same file name ... php.ini
Exit: [ctrl][x]
As far as those commands on the Moodle docs page ... yes, you should be able to use them ... but I'll say that vim is very user unfriendly. nano is already installed or should be.
To see what Moodle code you have, change into the moodle code directory ... typically that is /var/www/html/ and type: fgrep '$release' version.php
Might also check the ownership/permissions on files in /var/www/html/ [moodlecode]
From /var/www/html/
ls -l
All files/folders should belong to user 'apache' and group 'apache'.
Still in /var/www/html/ where you can see the Moodle code files ... hint: that's the same directory where the version.php file is located.
chown apache:apache * -R
'spirit of sharing', Ken
So to answer your questions...
1. Linux----------- 3.19.8-100.fc20.x86_64 #1 SMP Tue May 12 17:08:50 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux
2. Failed loading /full/path/to/opcache.so: /full/path/to/opcache.so: cannot open shared object file: No such file or directory
3.
PHP Warning: PHP Startup: Unable to load dynamic library '/usr/lib64/php/modules/php_intl.dll' - /usr/lib64/php/modules/php_intl.dll: cannot open shared object file: No such file or directory in Unknown on line 0
PHP Warning: Module 'zip' already loaded in Unknown on line 0
PHP 5.5.26 (cli) (built: Jun 11 2015 08:23:07)
Copyright (c) 1997-2015 The PHP Group
4. [PHP Modules]
bz2
calendar
Core
ctype
curl
date
dom
ereg
exif
fileinfo
filter
gd
gettext
hash
iconv
imap
json
libxml
mbstring
mhash
mysql
mysqli
mysqlnd
odbc
openssl
pcntl
pcre
PDO
pdo_mysql
PDO_ODBC
pdo_pgsql
pdo_sqlite
pgsql
Phar
posix
readline
Reflection
session
shmop
SimpleXML
snmp
soap
sockets
SPL
sqlite3
standard
sysvmsg
sysvsem
sysvshm
tokenizer
wddx
xmlreader
xmlrpc
xmlwriter
xsl
zip
zlib
[Zend Modules]
5. mysql Ver 15.1 Distrib 5.5.43-MariaDB, for Linux (x86_64) using readline 5.1
6. [root@---- www]# chown apache:apache moodledata -R
chown: cannot access ‘moodledata’: No such file or directory
[root@---- www]# ls -a
. .. cgi-bin html usage
7. [root@---- ~]# yum repolistLoaded plugins: langpacks, refresh-packagekit
repo id repo name status
dbbackup-yum1.tummy.com Tummy DBBackup Repo 1
fedora/20/x86_64 Fedora 20 - x86_64 38,597
software.virtualmin.com_gpl_universal added from: http://software.virtua 55
updater-wrapper-yum1.tummy.com Tummy Updater Wrapper Repo 1
updates/20/x86_64 Fedora 20 - x86_64 - Updates 22,459
virtualmin/20/x86_64 RHEL/CentOS/Scientific 20 - x86_64 6
virtualmin-universal Virtualmin Distribution Neutral Pa 55
yum1.tummy.com Tummy-Auth Repo 2
repolist: 61,176
Redirecting to /bin/systemctl restart httpd.service
Job for httpd.service failed. See 'systemctl status httpd.service' and 'journalctl -xn' for details.
/etc/php.ini.old /etc/php.ini.save
10. /etc/php.d:
bz2.ini imap.ini pdo_sqlite.ini sysvsem.ini
calendar.ini json.ini pgsql.ini sysvshm.ini
ctype.ini mbstring.ini phar.ini tokenizer.ini
curl.ini mysqlnd.ini posix.ini xml.ini
dom.ini mysqlnd_mysqli.ini shmop.ini xmlreader.ini
exif.ini mysqlnd_mysql.ini simplexml.ini xmlrpc.ini
fileinfo.ini odbc.ini snmp.ini xml_wddx.ini
ftp.ini pdo.ini soap.ini xmlwriter.ini
gd.ini pdo_mysqlnd.ini sockets.ini xsl.ini
gettext.ini pdo_odbc.ini sqlite3.ini zip.ini
iconv.ini pdo_pgsql.ini sysvmsg.ini
/etc/php-zts.d:
bz2.ini imap.ini pdo_sqlite.ini sysvsem.ini
calendar.ini json.ini pgsql.ini sysvshm.ini
ctype.ini mbstring.ini phar.ini tokenizer.ini
curl.ini mysqlnd.ini posix.ini xml.ini
dom.ini mysqlnd_mysqli.ini shmop.ini xmlreader.ini
exif.ini mysqlnd_mysql.ini simplexml.ini xmlrpc.ini
fileinfo.ini odbc.ini snmp.ini xml_wddx.ini
ftp.ini pdo.ini soap.ini xmlwriter.ini
gd.ini pdo_mysqlnd.ini sockets.ini xsl.ini
gettext.ini pdo_odbc.ini sqlite3.ini zip.ini
iconv.ini pdo_pgsql.ini sysvmsg.ini
Did I miss anything?
@Rick ... could be wrong, but ... sorry, but don't think CPanel or anything additional is going to help here ... only make it worse ... considering ...
This:
3.19.8-100.fc20.x86_64
indicates it's not a CentOS server but Fedora.
This:
/full/path/to/opcache.so
indicates some mis-understanding of something read concerning the loading
of opcache.so (which is linux), but the /full/path/to/ wasn't a literal
in whatever was followed to install php-opcache. The so's in typical
RedHat Flavored Linux server are in '/usr/lib64/php/modules/'
HINT: whenever someone writing directions shows something like:
/full/path/to/ they don't mean it literally. Cannot use that.
Operator has to 'translate' that to the actual full path to whatever.
This(these):
Unable to load dynamic library '/usr/lib64/php/modules/php_intl.dll
indicate a php.ini for Windows not Linux. Windows uses .dll's
and Linux uses .so's. Don't think Fedora places the php.ini in a different location as well.
The repo list confirms #1 above:
fedora/20/x86_64 as you can see says "Fedora 20 - x86_64"
but there is also added to the repos VirtualAdmin
Fedora is getting updates from Fedora 20 - x86_64 - Updates
Virtualmin is being pulled from RHEL/CentOS/Scientific 20 repos
Tummy-Auth Repo?????
IMHO, you've got one messed up server!!!
These forums are for the purpose of installing Moodle on various systems
and not for learning about those systems.
So strongly suggest, we take this conversation off this list ...
for one reason, hosting provider will be criticized.
I'll PM you one of my real email addresses so we can communicate
directly so check messages on this system and we can begin what
will be a long discussion.
'spirit of sharing', Ken
Yep, you might be right Ken. I was just fishing a little. Your support is probably what is needed for this particular installation.
Didn't mean to suggest you've not be helpful on these forums, quite the opposite in fact. The key thing shared so far is Virtmin - which is typically Linux and used for the purpose of hosting multiple apaches by different domains on the same physical server. It's something hosting providers don't normally setup for clients/customers. And, it's not really needed IF one reads up on virtual apaches/DNS.
There is also some confusion in reading Moodle.org docs ... easy to do when directions might really have 2-3 sections ... IF on Ubuntu, IF on Windows, IF on whatever. Easy to loose your place if distracted with other duties in the middle of config or not realize one is looking at Windows vs Linux/Others. I, for one, am NOT very good at 'multi-tasking'.
Will say this ... anyone who begins hosting open sourced apps on Linux platform is 'bold' (and I think headed in the right direction considering the state of finances of public education ... at least in my small corner of the world). But, that has always meant learning something new. Exciting and rewarding when one gets things to work, but very frustrating when things don't work. For those that don't have a high 'failure quotient' nor toleration for new learning, probably best to stick with what might be more familiar ... even if NOT the best.
Comment: this must not be that pressing cause I've not heard back via PM or EMail. But, that could also indicate one technical person wearing too many hats at the entity location - something else with which some public education entities struggle.
'spirit of sharing', Ken
All of your points are well taken. Let's see where this goes.
Ok, just saw something ... can't say it will fix all the server ills, but might get you down the path ONE more step.
At the very minimum, there's no php.ini file at /etc/
I see your listing there shows a php.save file.
If that was the php.ini.rpmsave file then we need to copy it
to php.ini:
from /etc/ as root user:
cd /etc/
cp -p php.save php.ini
That copies the php.save file to another file called php.ini and preserves
the ownership/permissions on the file.
Now php should be able to find it's initialization file to be able to
communicate with Apache even though there still might need to be edits/changes
to php.ini. (we might see more errors)
Restarting apache on Fedora is a little different:
Use apachectl (apache control)
apachectl restart
OR
/sbin/service httpd restart
And, your server docs are over at Fedora. Example:
https://docs.fedoraproject.org/en-US/
Anything you see at moodle.org for directions is mostly Ubuntu ... not the same ... or CentOS ... not the same ... or Widnows ... not the same.
You have to translate what you see in Moodle.org docs into Fedora 'lingo'.
The offer via PM still stands (for now) so we can cuss/discuss issues and not torture all in Moodle forums.
'spirit of sharing', Ken
PM's are more than welcome and I appreciate the offer. Feel free to email me at djearhar@svsu.edu - this is probably the best way to keep in touch with me.
I am not sure about the characteristics of your server, but might you have access to tools like cPanel or Plesk? I have cPanel, and this is how I usually turn on some of the php extensions, like "intl."
Might you be able to describe your server? Is it a dedicated, VPS, or hosted server, for example? What server company do you use?
Unfortunately Rick, I don't have CPanel or anything like that. The hosting company that we go through is a local company that does a variety of things other than hosting - ie. technical assistance (this case being the exception), firewall configurations, VM setups, and etc.
Okay, now we know. Follow Ken's guidance.