Plan for yearly website review / maintenance

[jimallman]

In brief, this might include:

1. Confirm that database backups are working correctly (actually test a backup)
2. Check the working version of all major components for security issues or end-of-life status
   • MySQL (all packages used, incl. multi-byte string handling)
   • PHP
   • Apache
   • PHPMyAdmin (if used)
3. Upgrade these as needed, check for compatibility issues and new bugs; fix as needed.

Depending on how the initial steps go, this might be pretty quick (less than a day) or more of a slog, esp. if bug fixes are needed. Hopefully a week of work at most, if the site needs major surgery. The most likely "worst case scenario" would be major security problems with PHP, forcing an upgrade to it and other components, and requiring related code changes in the FCDB site.

[dleehr]

Particularly, when a major component version ceases to receive security updates (CentOS 5, PHP, MySQL, etc), this will require a non-trivial amount of work to bring up to date

[pdpolly]

I like Jim's outline of review and maintenance, which is very much what we have been anticipating.

Dan's warning is an important one. If a major component like PHP or mySQL is deprecated, we will then need to find funding to re-write code to bring it up to date. However, I don't anticipate such deprecations happening without some reasonable advance notice from PHP or mySQL developer groups. That would allow time to plan the work without having to worry about database actually functioning in the meantime. I guess such a major overhaul would be combined with an upgrade of other features or to the user interface graphics, etc.

[jimallman]

I don't anticipate such deprecations happening without some reasonable advance notice from PHP or mySQL developer groups.

Yes, there's usually plenty of advance notice in these cases. Whereas a sudden "zero-day" security exploit will lead to fixes and shared expertise about how to apply them.

[jimallman]

I guess such a major overhaul would be combined with an upgrade of other features or to the user interface graphics, etc.

My two cents: This might make sense from a budgeting standpoint. But it's often less confusing (for developers and testers) to update just the codebase while keeping the site features frozen. Then modify other aspects of the site in a separate effort, so that there are never too many moving parts to keep track of.

[jimallman]

Other thoughts for annual review of the site:

• Review the list of higher taxa in L_HigherTaxa and their display order, in light of the current balance of calibrated nodes. For example, an influx of new calibrations within Plantae might prompt the addition of new "landmark" taxa in this list.
• Review the list of countries for accuracy; add, remove, rename countries as needed.
• Import the latest NCBI taxonomy and refresh all site data accordingly.

[rvosa]

I would strongly recommend that the configuration and installation is automated and rather fully specified. For example, for supersmart we are using puppet to manage all dependencies (including downloading databases - as per #14), here is the puppet manifest we use: https://github.com/naturalis/supersmart/blob/master/conf/manifests/default.pp - it is run by travis/CI continuously. This makes replication much easier than all the textual install instructions, which will go out of sync.

(Also, it would be good to consider using a virtualization or container system, such as vagrant or docker, to package everything up.)