Opened 8 years ago

Closed 7 years ago

#148 closed enhancement (wontfix)

add a Moodle autoinstaller

Reported by: geofft Owned by:
Priority: normal Milestone:
Component: autoinstallers Keywords:
Cc:

Description

Moodle is a highly popular open-source CMS for classes/the educational market. I've heard regular mumblings that MIT's considering a global install for replacing Stellar, although I don't know how likely that is. In the meantime, it has the potential to be highly useful for SIPB's IAP classes, ESP classes, etc. etc.

I tried installing Moodle 1.9.9+ weekly (as of today). Issues I noticed:

  • The README indicates it wants a cronjob to run every five minutes. I guess we could do that but there are a couple of issues with programatically adding cronjobs. I wonder if we can instead avoid it, since it goes against the scripts "if nobody's using your site, it costs no resources other than a couple megabytes of disk space" ethos. MediaWiki?, for instance, has a "job queue" for cleanup stuff like this.
  • Moodle recommends the GD extension (and can take advantage of mysqli, mbstring, curl, and xmlrpc if present). Adding an empty php.ini file makes the installer blow up, though. It works if I copy /etc/php.ini and add extension=gd.so, although that sucks. Let's fix ticket #2 instead.
  • It wants a directory outside the docroot, so we need the usual ~/Scripts thing that the e.g. Django installer does.
  • Once you have that directory outside the docroot writable, you don't need the Moodle directory itself writable; it spits a config.php back at you. We could probably even programatically generate that file from Wizard.
  • It seems not to actually let you use mysqli; changing it back to mysql works. I didn't actually debug what was wrong.
  • Once you get past the "installer", there are still a few steps like "accepting" the GPL and several screenfuls of creating tables that it wants you to do at first login that we should definitely do automatically.
  • Creating tables prints "SHOW TABLES" like a hundred times. What is up with that.
  • The new password requirement is unnecessarily onerous ("The password must have at least 8 characters, at least 1 digit(s), at least 1 lower case letter(s), at least 1 upper case letter(s), at least 1 non-alphanumeric character(s)") for a webapp. I would be tempted to bypass it for the initial user, which we probably can if we're automating that setup step, or get cert auth working as soon as we can.

Other than those minor points, it seems to work out of the box, so an autoinstaller should be simple.

Change History (6)

comment:1 follow-up: Changed 8 years ago by aseering

Creating tables prints "SHOW TABLES" like a hundred times. What is up with that.

Could this thing fall victim to the same issue that broke ESP's last attempt to install a webapp similar to this ("Claroline"), too many open file handles (from too many tables) in sql.mit.edu's backup script?

(Claroline used O(# registered classes) tables, which made things worse; I hope Moodle doesn't, but I haven't checked.)

comment:2 in reply to: ↑ 1 Changed 8 years ago by geofft

Replying to aseering:

Could this thing fall victim to the same issue that broke ESP's last attempt to install a webapp similar to this ("Claroline"), too many open file handles (from too many tables) in sql.mit.edu's backup script?

If this is specifically about sql.mit.edu, ... let's just say that I'm quite open to hearing bug reports about sql.mit.edu's backup script. :-)

comment:3 follow-up: Changed 8 years ago by geofft

Adam sent me the following unicast because he was having network trouble:

The problem, as I recall, was twofold: (1) Claroline created a ridiculous (and constantly-growing) number of tables, many of which remain empty or nearly-empty under typical usage; and (2) MySQL, when dumping, apparently simultaneously opens a file handle for each table in the database being dumped. As a result, ESP got an e-mail from some sql maintainer some time ago saying roughly "Hey, your database has more tables than MySQL has file handles, so your backups are failing."

ESP has stopped using Claroline so we don't care; your call on whether it's worth looking into in general, though.

Getting such an e-mail from sql as opposed to fixing the problem is kind of inappropriate. I've opened ticket #154 about addressing this, which will help us make sure it's not a problem.

In the common case, I expect most sites not to be big enough to trigger this. Anyway, for Moodle, I don't see immediate indications that Moodle's number of tables scales with the number of classes, although there do appear to be a couple of runtime things that do create tables.

comment:4 Changed 8 years ago by geofft

Apparently there's an underdocumented command-line installation mode. (Or maybe I'm just not finding the docs...)

comment:5 in reply to: ↑ 3 Changed 8 years ago by aseering

Replying to geofft:

Adam sent me the following unicast because he was having network trouble: (...)

Thanks for posting for me; I was having Web-access trouble on the wifi at a little motel... Back in town now.

In fairness to sql, the e-mail thread was longer than I implied above; and per my comment on #154, the solution wasn't necessarily simple. I agree that it'd be nice if sql behaved better in this case, though.

Incidentally, since "ESP classes" is cited as one possible Moogle user: ESP actually checked out Moogle a while ago and decided against using it. (I'm not sure why; the reason was UI rather than technical.) They're currently playing with some alternatives; let me know in personals if you're interested in their conclusion.

comment:6 Changed 7 years ago by adehnert

  • Resolution set to wontfix
  • Status changed from new to closed

We seem to be talking lately about making certain autoinstalls "unsupported" or conceivably even entirely punting them. Given that, I don't think we should be implementing autoinstallers for relatively unpopular apps like Moodle.

Note: See TracTickets for help on using tickets.