Custom Query (196 matches)

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.

LDAP replication authenticates over SSL certs. The problem with SSL certs is that they expire (also we have our own one-off CA for signing these certs). It would be great if we could use this nifty Kerberos thing for authenticating our LDAP servers to each other.

Last time we had an outage due to an expired cert, I got really really close to making GSSAPI authentication work, but it turns out that you can't modify an existing LDAPS replication agreement to turn into an LDAP-with-GSSAPI one, so you need to remove the replication agreement and create a new one, and for various complicated reasons I think the only way that we're really comfortable doing them is tearing down _all_ of the replication agreements at once, making GSSAPI work, and re-configuring replication anew with GSSAPI. This is a bit annoying.

We should first test that it will actually work, by setting up LDAP on two or three VMs and trying GSSAPI auth (with, like, ZONE realm principals).

Once we're comfortable with doing so, we should do this at a time (like, oh, early on a Sunday morning) when we can temporarily turn off account registrations and Pony so we don't have to deal with things needing to be replicated while we're breaking and recreating replication.

See the scripts-team thread "Re: failed scripts account setup" and zlogs of -c scripts -i ldap from May 2, 2010 for more background.

MySQL supports ​two major replication formats: statement-based, where the query is logged and replayed, and row-based, where the changed data is logged and replayed. Statement-based is much older and presumed more stable, and the default in 5.x; ​row-based handles a couple of nondeterministic queries that statement-based replication can't. MySQL 5.1.8 also introduced ​mixed-format logging, which uses statement-based replication where it can and row-based where necessary. 5.1.12 made mixed replication the default, until it was ​reverted in 5.1.29 on the grounds that 5.1 should be compatible with 5.0. We should decide on our own whether we want to use mixed replication (I think there's no compelling need to switch to row-based replication for everything). Among other obvious benefits, more reliable replication means that backups are more likely to match what you see on the primary.

Relatedly, MySQL used to permit users to set a session variable, ​`binlog_format`, to switch logging types for the duration of that session. However, this ability was ​restricted to users with the SUPER privilege (which has always been required for setting that as a _global_ variable), because someone claimed that DBAs might write code that required row-based replication and didn't want a mere user to be able to switch to statement-based replication and foil the DBA's plans. While I question the validity of such a possibility, we certainly don't have DBAs, so it might be worth locally reverting that patch so that users and applications have the option of switching to row-based replication if they prefer it. This would be especially important if we go through autoinstalled apps to see what, if anything, wouldn't work properly statement-based replication.