Custom Query (196 matches)


Show under each result:

Results (25 - 27 of 196)

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19
Ticket Resolution Summary Owner Reporter
#148 wontfix add a Moodle autoinstaller geofft

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, 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.

#164 wontfix Zend Guard support ezyang

Zend Optimizer is an extension to PHP that improves the performance of PHP scripts and permits users to run scripts that have been obfuscated by Zend Guard. There is a fair bit of payware PHP software encoded by this, and users occasionally want to run them on Scripts (see for example RT #1298251).

Zend Optimizer is only available as a binary .so file for x86_64, and furthermore, it is only compatible with PHP 5.2 at the time of writing, so it's kind of not usable (right now) on recent releases of Fedora. However, because we allow loading arbitrary php.ini files, users can simply copy the .so file to a location in their web_scripts and then send zend_extension to that absolute path.

It may be worth scriptsifying the binary .so and placing it in extension_dir (in our case, /usr/lib64/php/modules), thus officially supporting Zend Optimizer through the "zend_extension=ZendOptimizer?.so" flag in a php.ini file. However, this leaves us with an unsatisfying upgrade story when we upgrade PHP.

#168 wontfix scripts-cert-test IP address ezyang

We should get a scripts-cert-test IP address so that we can serve the correct certificate when navigating to (this requires IP based virtual host, so the usual iptables trick doesn't work.)

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19
Note: See TracQuery for help on using queries.