Hello, I have a production site that is running fine but I want to set-up a new dev site on another server. My moodledata folder and database are large and I don't have resources on the dev server to store it.
I'm interested in creating a dev site with the same code and essential elements of the database (minus logs/cache etc), but a fresh moodledata folder. is this advisable?
One can certainly migrate a copy of production site to dev, but without moodledata/filedir then one would end up with many many many links to files (PDF/video's/audio's/images in quizzes/test, etc.) broken.
One can also truncate on dev site the largest tables of the cloned production server DB ... like moodle's log store (a who done it) ... on dev.
But 1/3 migration to dev would be good practice on trouble shooting issues me thinks but is that the purpose of dev?
Alternative ... stand up a new dev server with same version of code. That will create a db for it and a moodledata/filedir with no issues/orphaned metadata or physical files in moodledata/filedir/ Install same plugins present on production in dev.
Make course backups ... user or no user or other resources ... and restore to new dev server.
Set dev server to no mail. Cert for dev may not be valid but can run one self-signed to stop moodle from complaining about not https.
dev server to be internal to a private network only or opened to outside world? Reason asked ... dev servers can be found rather easily if on public internet ... so one shouldn't ignore updates to the OS and to the Moodle or risk eventual compromise due to lack of admin. If totally inside ... no outside access ... then one could be a little more lax ... but then again, that depends upon how 'wild west' the internal network is.
Suggestions above not the only way am sure ... so if above will not work for ya, then need more info on what one expects to be able to do with dev.
'spirit of sharing', Ken
Ken, thanks for the reply. I already currently have a dev set-up similar to what you suggested - stood up a new site with the same codebase. It just seems like too much work to try and re-set everything up in terms of plugins, authentication, integrations etc. I'd much rather try bring the PRD database over. Broken links shouldn't be too big of a deal in a new dev site. It's mostly just needed to have a site to test new plugins/updates in an as close to prd environment as possible. It's on a local network with no internet access.
'terms of plugins, authentication, integrations' ...
Well ... let's play devils advocate here .... for a total crash/disaster recovery kinda thing ... and it's finally decided that one needs to 'rebuild' ... how about those plugins, authentications, integrations? Gee, how many plugins does the site have?
One will still have to edit the PRD DB at the dev site ... each time you do that, correct? Unless you've found a way to export only tables that wouldn't require any change to them due to site url changing - broken links would be in admin area of the dev moodle using prd db. So one has to work to work, so to speak ... almost any way one looks at it.
Do you do updates and upgrades the 'old' way or via git?
'spirit of sharing', Ken
We have 58 "additional" plugins, so a lot to configure 1 by 1. I understand there will be work to do setting up a dev site properly (turning of email, etc).
Not particularly worried about dev for recovery - prd is on virtual servers that have snapshots taken daily. I do version control via git.
I just did a small test site, migrated the DB and the code folder with a new data folder and it worked OK, minus the broken links as you said.
Wow! 58!! Got linux?
Suggestion ...
On your dev instance, install moosh.
There is a moosh command that will check on plugins ... latest versions in Moodle plugins.
Script:
checkaddons
contains:
#!/bin/bash
#
echo 'Add-on listing: ';
cat ./addons.txt;
echo '---------------------';
for i in `cat ./addons.txt`
do
echo "Addon in que: $i";
moosh -n plugin-list |grep $i
done
addons.txt is a simple text file listing the short names of the plugins ... can be seen when visiting the plugins page of the Moodle Admin interface.
Looks like:
mod_hvp
mod_questionnaire
mod_customcert
When the script is run, output looks like:
Add-on listing:
mod_hvp
mod_questionnaire
mod_customcert
---------------------
Addon in que: mod_hvp
mod_hvp,2.7,2.8,2.9,3.0,3.1,3.2,3.3,3.4,3.5,3.6,https://moodle.org/plugins/download.php/18393/mod_hvp_moodle36_2018113000.zip
Addon in que: mod_questionnaire
mod_questionnaire,1.9,2.0,2.2,2.3,2.4,2.5,2.6,2.7,2.8,2.9,3.0,3.1,3.2,3.3,3.4,3.5,3.6,https://moodle.org/plugins/download.php/18487/mod_questionnaire_moodle36_2018050108.zip
Addon in que: mod_customcert
mod_customcert,2.9,3.0,3.1,3.4,3.5,3.6,https://moodle.org/plugins/download.php/18626/mod_customcert_moodle36_2018120301.zip
With that info, one could 'collect' all the plugins using wget to a 'addons' directory anywhere on dev system.
Example:
[root@server addons]# cat addonslisting.txt
https://moodle.org/plugins/download.php/18394/mod_bigbluebuttonbn_moodle36_2017101016.zip
https://moodle.org/plugins/download.php/18393/mod_hvp_moodle35_2018113000.zip
https://moodle.org/plugins/download.php/18420/mod_questionnaire_moodle36_2018050107.zip
wget -i ./addonslisting.txt
Will get the zips downloaded to the directory where executed.
You can then update/install those plugins manually ... at first ... once built could use Moodle's mdeploy to acquire in dev system.
in the 'spirit of sharing' ... and reducing the load on admin op.
Ken
Ken, thanks so much for sharing your expertise. I do run CentOS Linux. As you may have surmised I have recently taken over Moodle admin at a school some months ago and and am still learning (every day). I inherited a pretty well set-up situation so it's a good place to learn and see how to build without starting from scratch.
The codebase is managed through a Git repo and all the "extra" plugins are submodules. So to deploy my codebase, in theory, I just clone the repo and pass -recurse--submodules with the command. In practice, I have struggled a bit with submodules and have had to do some finagling on individual submodules to get them initialized and pointing to the intended commit, but am getting more comfortable with them now.
In any case, I was able to get my new DEV instance up and running with no issues. I just use the administration->plugins->plugins overview screen to check for updates and new versions.
