Does anyone know if there is any tools for the management of multiple moodle sites? I currently run 10 installations over 8 servers for a number of our UK centres with a VPN between all sites and would love to have access to a tool to quickly manage versions and modules/blocks on all sites from one place.
Does this exist or is it wishful thinking?
If not would it be possible to have a simple page that would:
1. Enter multiple sites connection info (one off)
2. browse for 3rd party mod or block folder
3. select mod or block folder for receiving site
4. submit (rsync uploaded files to all sites on your list)
5. curl sites admin page to install tables/block/mod
6. confirm installation
Maybe keep a record of 3rd party mods for easy removal?
If there is nothing like this then maybe I will dig out my dusty php books and see what can be done with little coding knowledge.
hi Simon,
I manage a similar number of sites, although not across quite as many servers. Some users (like Dan P) manage crazy numbers of sites - like 1000!
I'd be hesitant to do what you've suggested (a PHP-based solution built with "little coding knowledge"), particularly if it is going to be storing config data and remotely hooking into the backend of your sites and using shell tools.
A number of people on this forum use their SCM tools (Git et al.) with deployment scripts to achieve something similar. I personally do this - with Git taking the feed from Catalyst then merging it with some select bits of Contrib code and some local tweaks common to all my installations, then I merge it with any local customisations. Once you get familiar with it, a tool like Git can do most of this.
I'd be interested to hear where you end up with this. I've recently been toying with the idea of rolling my own Debian/Ubuntu packages (in conjunction with the Git repo) to deploy my code.
Hope this helps you on the path...
MC
I manage a similar number of sites, although not across quite as many servers. Some users (like Dan P) manage crazy numbers of sites - like 1000!
I'd be hesitant to do what you've suggested (a PHP-based solution built with "little coding knowledge"), particularly if it is going to be storing config data and remotely hooking into the backend of your sites and using shell tools.
A number of people on this forum use their SCM tools (Git et al.) with deployment scripts to achieve something similar. I personally do this - with Git taking the feed from Catalyst then merging it with some select bits of Contrib code and some local tweaks common to all my installations, then I merge it with any local customisations. Once you get familiar with it, a tool like Git can do most of this.
I'd be interested to hear where you end up with this. I've recently been toying with the idea of rolling my own Debian/Ubuntu packages (in conjunction with the Git repo) to deploy my code.
Hope this helps you on the path...
MC
Hi Myles,
I must admit, the php with little skills route is a bit daunting epsecially in a broad production environment. Think I will hold off and look at some of the other tools you mentioned.
Lots of ways to approach it and you have given me plenty to look at
Many thanks, I will let you know where it all leads
First test is to make a single simple add module page for a test moodle site for our head moodle admin (who has no clue about the sysadmin side) so he can easily add and remove blocks and modules. I have been burned a few times with his insistence to install "useful" blocks and the like only to find a knock on effect later. Thank heavens for backups :P
SB
I must admit, the php with little skills route is a bit daunting epsecially in a broad production environment. Think I will hold off and look at some of the other tools you mentioned.
Lots of ways to approach it and you have given me plenty to look at
Many thanks, I will let you know where it all leads
First test is to make a single simple add module page for a test moodle site for our head moodle admin (who has no clue about the sysadmin side) so he can easily add and remove blocks and modules. I have been burned a few times with his insistence to install "useful" blocks and the like only to find a knock on effect later. Thank heavens for backups :P
SB
Heh, don't quite have 1000 installations yet, 540 at the moment.
Crucially the Moodles we host are all based on the same shared codebase (with the samethird-party modules either in for everyone or not). This is the only viable way we can manage upgrades for so many sites with a small team.
So we do have custom site management tools (basically php frontend scripts which drive a database backend which drives the perl scripts on the servers to do the real work), but I doubt it'd be useful outside of our specific environment (and I'm afraid I doubt we'll ever release them).
The basic stuff which makes it tick is use of apache's mod_vhost_alias & then just individual management of each vhosts config.php.
Initially we used unionfs as a way of allowing customisations on top of the shared codebase, it was quite a neat solution, but back then we encountered some bugs which caused kernel panics (so I was quickly put off that ;)).
Crucially the Moodles we host are all based on the same shared codebase (with the samethird-party modules either in for everyone or not). This is the only viable way we can manage upgrades for so many sites with a small team.
So we do have custom site management tools (basically php frontend scripts which drive a database backend which drives the perl scripts on the servers to do the real work), but I doubt it'd be useful outside of our specific environment (and I'm afraid I doubt we'll ever release them).
The basic stuff which makes it tick is use of apache's mod_vhost_alias & then just individual management of each vhosts config.php.
Initially we used unionfs as a way of allowing customisations on top of the shared codebase, it was quite a neat solution, but back then we encountered some bugs which caused kernel panics (so I was quickly put off that ;)).