Custom Query (196 matches)

Most of our software supports upgrading by switching to a newer tag, updating, and possibly running an upgrade databases script. If we install a SVN (or whatever VCS) working copy rather than extracting a tarball, users can upgrade their own installs easily. Our auto-upgrade process should also become easier.

For SVN, we can merely generate a tarball with the .svn directories and keep our existing auto-install (and to some extent, auto-upgrade) infrastructure. I suspect this will work with all other VCSes.

There are also packages such as Django that very much recommend installing HEAD rather than a tarballed release, so having an infrastructure that will deal with VCSes will make it easier to support such packages.

The phpMyAdmin installation(s) in the sql locker are old and somewhat screwed up. geofft was going to fix this but he went to sleep, so I’m recording the necessary steps here as a reminder.

• svn co https://phpmyadmin.svn.sourceforge.net/svnroot/phpmyadmin/tags/STABLE/phpMyAdmin
• Copy config.sample.inc.php to config.inc.php.
  • Set $cfg['blowfish_secret'] to a secure random value.
  • Set $cfg['Servers'][$i]['host'] = 'sql.mit.edu'
  • Set $cfg['Servers'][$i]['extension'] = 'mysqli'
  • Set $cfg['ForceSSL'] = TRUE
• Copy /etc/php.ini to php.ini.
  • Add the mcrypt and mysqli extensions.

The patches and .htaccess redirect are then unnecessary, and future upgrades will be as simple as svn up. (Example: <​https://andersk.scripts.mit.edu/phpMyAdmin/>.)

It's poor that users outside MIT or who otherwise haven't installed the MIT CA to be trusted get warnings when they visit scripts pages. We can get a cert for <$20/yr for scripts.mit.edu, and for $200/yr (maybe less) for *.scripts.