Apparently the update process uses IPv6. Never heard of it.
So from wikipedia: "IPv6 is intended to replace IPv4, which still carries the vast majority of Internet traffic as of 2013.[1] "
If a server has yet to be updated with IPv6, is there anyway round this, and still be able to get updates?
-Derek
Have been well aware of IPv6 for some time now - IPv4 will run out of ip addresses (if it hasn't already).
But automatic update of plugins???? Sorry, haven't read anything about that. Reference please!
Hmmmm ... that would reduce Moodle server admin 'duties' I guess ... and supposedly make Moodle more secure.
Heck, would one set the operating system upon which a Moodle runs to 'autoupdate'?
Curious mind ...
'spirit of sharing', Ken
Ken, thanks.
Here is all I know: I work with several Moodle installs, all very different. One of the programmers for one of the systems I asked replied:
Unfortunately this is an infrastructure issue on our side and our server guys are working on it.
Since Moodle 2.4, updates are now coming from their Cloudflare CDN which uses IPv6. Our servers doesn't support this yet. We're in the process of pushing this forward.
In the mean time we'll have to install the plugin updates manually.
I'll keep you posted.
That's it, all I know, and it never occurred to me it may be not right. This is probably the wrong forum to ask.
-Derek
I just updated a couple of 2.4's and ran into an issue when getting updates for plugins.
See:
https://moodle.org/mod/forum/discuss.php?d=228425#p991926
Ever seen that error about 'Something must be wrong with the Internet' when CloudFlare hickups? Well, there's another one now for updates to mods/blocks/etc. for Moodle .... and it says something to the same affect ... a big 'Oops!' and then some suggestions. Hmmmm ... nothing like a sense of humor, huh?
Could be an issue with certificates?
'spirit of sharing', Ken
I have also been experiencing a failure of the auto plugin update since about the time I went to 2.4.3, a month ago. Tried today again to update a plug in. Here is what I got from the mdeploy.log
2013-05-26 10:01:53 === MDEPLOY EXECUTION START ===
2013-05-26 10:01:53 Successfully authorized using the passphrase file2013-05-26 10:01:53 Plugin upgrade requested2013-05-26 10:01:53 Downloading package https://moodle.org/plugins/download.php/3074/block_navbuttons_moodle25_2013052200.zip2013-05-26 10:01:53 Package downloaded into /var/www/vhosts/fofcom.com/httpdocs/moodledata/mdeploy/var/d4c3dfa15e186ab036bc73a6ae59f556.6.zip2013-05-26 10:01:53 MD5 checksum ok2013-05-26 10:01:53 Current plugin code location: /var/www/vhosts/fofcom.com/httpdocs/WZC/blocks/navbuttons2013-05-26 10:01:53 Moving the current code into archive: /var/www/vhosts/fofcom.com/httpdocs/moodledata/mdeploy/archive/navbuttons_1369580513.02013-05-26 10:01:53 exception 'zip_exception' with message 'Invalid structure of the zip package' in /var/www/vhosts/fofcom.com/httpdocs/WZC/mdeploy.php:1288Stack trace:#0 /var/www/vhosts/fofcom.com/httpdocs/WZC/mdeploy.php(771): worker->unzip_plugin('/var/www/vhosts...', '/var/www/vhosts...', '/var/www/vhosts...', '/var/www/vhosts...')#1 /var/www/vhosts/fofcom.com/httpdocs/WZC/mdeploy.php(1399): worker->execute()#2 {main}
All is good until the Zip Exception. Actually can see the downloads in the archive folder. They are the same I would obtain with a manual download. Got the funny OOPS message Ken refers to. So doesn't it seem like, at least in this instance, that the mismatch is internal to the deployment code not a function of an ip address or even server security or user rights?
Sure would like some help in understanding this.
Rod Wolford
@Rodney ...
771 of latest build mdeploy.php has the following comment and code:
// Unzip the plugin package file into the target location.
$this->unzip_plugin($target, $plugintyperoot, $sourcelocation, $backuplocation);
Can't see the full paths shown in your stake trace:
#0 /var/www/vhosts/fofcom.com/httpdocs/WZC/mdeploy.php(771): worker->unzip_plugin('/var/www/vhosts...', '/var/www/vhosts...', '/var/www/vhosts...', '/var/www/vhosts...')
mdeploy.php also has this comment:
* CLI usage example:
* $ sudo -u apache php mdeploy.php --upgrade \
* --package=https://moodle.org/plugins/download.php/...zip \
* --dataroot=/home/mudrd8mz/moodledata/moodle24
Package:
https://moodle.org/plugins/download.php/3074/block_navbuttons_moodle25_2013052200.zip
Out of curiosity, downloaded the zip directly and unzipped:
Don't know if significant but:
Ken-Tasks-MacBook-Pro:test ktask$ unzip block_navbuttons_moodle25_2013052200.zip
Archive: block_navbuttons_moodle25_2013052200.zip
0056e712ac22025a8ed323e8763ffe5f689ca358
creating: davosmith-moodle-navbuttons-0056e71/
inflating: davosmith-moodle-navbuttons-0056e71/COPYING.txt
inflating: davosmith-moodle-navbuttons-0056e71/README.txt
inflating: davosmith-moodle-navbuttons-0056e71/activityready.php
Seems to me that mdeploy has to take davosmith-moodle-navbuttons-0056e71 and turn it into navbuttons - the error reported 'Invalid structure of the zip package'
Is this just an issue with this particular package … am wondering?
'spirit of sharing', Ken
I may have discovered another glitch concerning the new auto-update feature in Moodle 2.5.
When attempting to install a Mod (Questionnaire) using drag & drop , I receive this error message:
"PHP is missing a temporary folder."
This might be because the sandbox installation I'm trying 2.5 out on is an upgraded Bitnami 2.4.3 installation in a Mac version 10.7.5 installation. (Reported possible drag & drop bug last night.)
The workaround I found was to use Dropbox. By parking the zipped mods (etc.) in a Dropbox sub-folder, and by making the Moodle folder (mods in this case) writable by everyone (777), the new mod installation worked like a CHARM!
BLESSED BE THE MOODLE DEVELOPERS FOR ADDING THIS GREAT FEATURE!
Now that I've paid homage, I have a serious question.
Everything I find on the web about setting permissions for web-based applications says about the same thing:
"On shared hosts, files should never be owned by the webserver process itself (sometimes this is www, or apache, or nobody user)." (From Wordpress Codex)
My question is what are "safe" settings for the sub-folders in a Moodle installation so that this wonderous new auto-update feature will work, but without putting Moodle at risk?
Thanks for listening. Community wisdom will be greatly appreciated.
Dr. Bob Blomeyer
files should never be owned by the webserver process itself
Well, yes. If you do not allow the web server process to modify your files, then it may be more difficult for a an attacker / malicious software to infect your files. But then, you have to do all the files modifications on your own - thence you can't use this auto-update or auto-install features.
This is not Moodle specific. All web applications face the same issue. Even Wordpress does - as long as you are able to upgrade it via the web interface, the web server process has write access to the code.
It also depends on the overall infrastructure of your hosting. Some providers run web server using a single user account. In that case, a vulnerability in a single application makes all other clients vulnerable, too. There are alternative approaches and you should ask your hosting company how they have this done.
There are other aspects, too. For example, outdated Moodle (old version, not upgraded) without the write access is still more insecure than up-to-date Moodle with the write access. Simply because all security holes in old versions are known and published. Again, this applies to almost any software. The problem with shared hosting is that you can have your Moodle up-to-date but if another client runs some outdated app there and your accounts are not 100% separated, you may be affected by that, too.
I know an admin who keeps his Wordpress and Moodle code read-only. Every time he wants to install or upgrade an add-on, he modifies the folders permission just for that moment, performs the install/upgrade and sets permissions back to read-only. That sounds like a good compromise.
