mrverrall

As an advocate of upgrading; here is a list of the 50 current known security vulnerabilities for Moodle 2.5.6... https://web.nvd.nist.gov/view/vuln/search-results?adv_search=true&cves=on&cpe_version=cpe:/a:moodle:moodle:2.5.6

For me GIT makes things much easier and basically combines your steps 2-5 into one. It generally makes moodle upgrading faster and more robust, the only barrier is learning GIT I suppose.

Hi, just edit your new url to the form, co.uk/?csid= That is, add a forward slash between the domain and the GET params (the '?' and what is after it) Cheers, Paul

[citation needed] Specifically, https://tools.ietf.org/html/rfc1034#section-3.6.2 and clarification at https://tools.ietf.org/html/rfc1912#section-2.4

Hi RabbieBurn, I've just cleared out some prior responses to keep things neat and clear here. What you ask id entirely possible. All you need to do is *uncheck* the following option, Site administration / Plugins / Activity modules / Forum / Use email address in reply The confusion (for me too) comes when this is checked so as to use users real email addresses, but is then overridden by a users preference to keep their email address private at user level. Cheers, Paul

I'm surprised anyone is using Moodle 1.9.11+ !!! Hope you get it sorted.

To the best of my knowledge it should apply to any HTTPD as it is PHP setting the cache-control header and the users browser acting on it, IIS is just the piggy in the middle.

Fixed

Unfortunately that information is WILDLY out of date! HTTPS/SSL caching was addressed in Moodle 2.3, specifically https://tracker.moodle.org/browse/MDL-32683 Regarding SSL client caching some interesting background information to he found here, https://blog.httpwatch.com/2009/01/15/https-performance-tuning/ specifically 'Tip #3'. Basically you are fine if you have a modern browser (Better than Firefox 3 or IE6) and a Moodle version above 2.2 I'll see what I can do about getting those pesky moodle docs updated.

I don't think this is true. You'll get a sight overhead for the actual encryption, but both client and httpd should continue to cache just the same as always.

Yeah, I agree for sure usage patterns will be different. In the context of system resources what I think we really care about is how many users are likely to be clicking stuff at any one time and I think it is safe to say in either usage context that this is actually going to be much much lower than the total users logged in at any one time. Here we graph not only the users logged in, but more importantly the number with near 'lastaccess' times in the user table. The latter is much more informative when you are deciding what resources to throw at your system. Interestingly what I have tended to find when inheriting the maintenance of schools existing moodles is once I start graphing their system resources it's fairly apparent that at some point they have decided to throw lots of RAM at the server without actually configuring anything to use it, the moral of the story being to understand your systems real resource usage and take care it it's configuration. RAM is great, but worthless if unused Sorry to take us off topic

I think people wildly over estimate their concurrency. The largest setup I'm involved with is too complex to define in terms of the 4 criteria listed here, but I can give some statistics regarding concurrency, Over the last Month we saw ~14k unique users log in. Over the last 24 hours 8k unique user logins. In terms of concurrency, defined as users with activity within 5 mins of each other, our absolute max is just below 300 users. I just thought that might be interesting.

Not related to performance, but you say you are running Moodle 2.7.3+ The current 2.7 branch release is 2.7.5 and included a critical security fix whereby access to system files could be gained, e.g. config files or moodle user uploads assignments etc. See https://moodle.org/mod/forum/discuss.php?d=279956 for details. I'd suggest you patch up asap if you plan on putting this into production use! Cheers, Paul

I would start by looking at the 'More' theme that is already built into Moodle and then using the Custom CSS options in-site to further customise as you can get some good mileage here (I'm assuming as you are looking at theming yourself you know your way around CSS). This is especially useful if you are just looking to bring Moodle on-theme rather than overhaul the entire thing. Moodle themes also work on a hierarchy system, so if you find a base you like you can easily extent it to suit you needs with minimal development.

For the php.ini it would be the memory_limit value. However on reflection this would not be an issues unless you have actually run into actual errors so you can probably leave this alone. One value you should definitely change though is the 'realpath_cache_size' as this will help with php's handling of the large number of files included in moodle. A value of 1M should be plenty (the default I think is only 16K). The big win for PHP will be in implementing the Opcache. I use APC and as Moodle is quiet large I find I need an apc.shm_size of ~410M to contain it comfortably. This gets pre allocated as a block of memory regardless of if it's used and so won't be available to other applications. You will want to keep this value as just-enough to stop the cache filling and purging (which it will do when it gets full). As for MySQL I'm not going to be much help as I tend to use PostgreSQL where I have a choice. When I do have to work with MySQL I use a tool like MySQLTuner-perl by major to guide me; unfortunately that tool is Linux only but you might be able to find an equivalent for Windows if you do some Googling. One principal that is sure to apply though is that it's not going to be as simple as telling it to 'use all the ram' and you almost certainly won't want it to. It's generally best to set up your daemons to use just enough ram to get their job done efficiently and will not be a one size fits all (unfortunately). Something else I forgot to mention is to check that your HTTPD (Apache, ISS or whatever you are using) is handling your connections efficiently, You want to be able to accepts enough connections and to be able to folk enough php workers to accommodate them, otherwise it may be queueing requests.

A few things spring to mind. Firstly have you configured PHP and your Database (I'm assuming MySQL) to actually use the RAM you have? These processes won't just use what you have but will instead will limit themselves to what you've told them they can have in their configs. If you're just running default configs then these values are likely to be low. Secondly you should make sure you have a PHP OpCache enabled, this will store your compiled PHP code in memory rather than hitting the disks and CPU every time a page loads. If you are running php 5.5 or above you can use the built in PHP cache, first check it is enabled by looking at [your_moodledomain]/admin/environment.php, and then make sure it is configured properly (PHP: Runtime Configuration - Manual). If you're running PHP 5.4 you should look at PHP APC as a Opcache (PHP: APC - Manual). You may also want to further limit your disk I/O by setting up a ramdisk for Moodle disk caches, check out the config options here for moodle here: Official Moodle git projects - moodle.git/blob - config-dist.php. You'll loose the content these folders on a reboot so make sure you only use them for cache folders. Further tweaks may include, X-Sendfile, memcached for sessions, hardware optimisations for disk IO (e.g. raid configuration, read/write cache rations etc), and probably a bunch of things I've forgotten. Most of this is just standard web/database server administration and not Moodle specific so don't get bogged down looking for advice on 'slow Moodle', look at your services in general, look for bottlenecks and see if there are solutions

Users emails need to be unique in Moodle. You could however use the oft forgot + syntax to alias each user to a single mailbox... e.g. [email protected]

Obviously if you already have some local email infrastructure you could just use that

I agree with you that it's a bit of a bodge. Personally I would rather set up a simple local SMTP server to easily route the email output form moodle how I want, especially when the alternative is to edit the core moodle files and maintain those changes through all future updates. The SMTP relay solution also means that email still works in Moodle where you want users to have real email addresses (e.g. for admins and teachers) while still canning all email traffic for students.

Rather than configure moodle to use you ISP's upstream SMTP server you could run a local SMTP relay (e.g. exim on Linux) and configure that to 'blackhole' (or maybe deliver elsewhere) emails from moodle, perhaps with a custom domain, e.g. [email protected]

Let's kill this fallacy here. There weren't any 'CLEO's adaptations', zero customisations, nada code changes, CLEO runs on a stock 1.9 Moodle code base. Sure there are plugins on top of this, but that will always be the case with any old deployment, and again these (with the exception of MIS tools) are all standard and freely downloadable. I guess my point is, if you are happy with PHP/MySQL applications, do not be scared to take your Moodle back from County. It is totally achievable to take their dumps, and using the standard Moodle downloads upgrade this to a modern Moodle. If you have 'nightmare' issues with 'adaptations' you are probably doing something wrong. If you've hired a professional to do this and they have issues you should probably start to question your choices, especially if they try to use this as an excuse to bill you more! The only gottchas I can think of are, * you'll need to via via Moodle 2.2 to upgrade to anything newer * the lack of MIS import tools for 2.x (Do people use these still?) * the nanogong audio assignment plugin is not 2.x compatable (again this was only ever lightly used by some schools), * there is DB entry in the config table setting a 'alternative login url', just null this. * themes in 1.9 are not compatible with 2.x. that said Moodle 2.7 comes with a theme called 'More' that is super easy to brand as your school, you can see some examples in North West Moodle User Group forums (North West Moodle Users Group) Other than those it should be plain sailing. At LUNS we migrate and upgrade CLEO Moodles onto our hosting platform, but I'm also I'm thinking now that there could be a use in us offering a migration service, i.e. we take your CLEO 1.9 Dump and pass you back a Moodle 2.x dump back. I have no idea what people would pay for this (it's about a mornings work at a guess).

Hi Elliot, The answer depends of what 'CLEO backups' you mean which will impact how you migrate your data. The simple option: BT Lancashire services can provide a file and database dump of your existing site which can be used to replicate a Moodle 1.9 install locally which can then be upgraded to the latest 2.x version quite easily. There are no LUNS customisations to overcome specifically, but there can be a few issues with the database structure due simply to the number of upgrades and patches the CLEO deployment has been through in the past. You will also want to have all the modules that were used in CLEO, again nothing bespoke, it's just a case of finding them online. Other glitches can occur, but are variable on a site by site basis but are generally simple to debug and resolve if you have a little php/mysql experience (I assume so if you are doing this in-house), most likely it will be fine. The only thing you will miss on Moodle two is the MIS imports tool which isn't openly available on Moodle 2 (but is still an option on LUNS hosting). The painful option: You can download backups of each of your courses through the Moodle interface and import into your own moodle along with a matching export of users. The target site will also *NEED* to be a 1.9 release of Moodle, but this can be upgraded later once the data is migrated. I wouldn't recommend this route as it is hugely labour intensive. I'm not saying it's not possible, and I have clients who have done this (for whatever reason). Alternatively you can look at getting this migrated upgraded and hosted by another provider, I know that LUNS are happy to take back hosting of CLEO moodles Paul

Even when I read back what I wrote it makes no sense to me either. Thanks for the corrections.

Wow people still use this? Good to know

Always happy to help