Webwork administration

Adding a new course

Canvas

1. If you are copying an existing course, browse to that course on webwork.math.ucsb.edu and use the Hmwk Sets Editor to export all homework sets.
2. Browse to webwork.math.ucsb.edu, click Course Administration, and log in.
3. Click Add Course. Set the Course ID and Course Title according to the existing pattern (math-<course#>-<section>-<term>-<instructor_name>).
4. Enter a user ID and password for the course instructor to use to log into the course. (Canvas does not handle admin access for courses the same way Moodle does, so a separate account is required.)
5. If you are copying an existing course, select it in the "Copy templates from" dropdown list.
6. Click Add Course.
7. Make the instructor aware of their course username/password, and link them to the Canvas homework instructions.

Upgrades

• Check the latest release notes for update information.
  • Usually the upgrade process will be a simple "git pull" in /opt/webwork/webwork2
  • Use "sudo -u wwadmin -s" first to get correct file ownership
  • Check the release notes for any configuration changes needed
• Update PG and the problem library by running "git pull" in the following directories:
  • /opt/webwork/pg
  • /opt/webwork/libraries/webwork-open-problem-library
• After the update, run "sudo apachectl configtest" to check for missing perl modules or other errors. Correct these before moving on.
• Restart the web server with "sudo systemctl restart httpd"
• Run "/opt/webwork/webwork2/bin/upgrade_admin_db.pl" to do any needed database schema updates on the admin course.
• Log in to the admin course and click Upgrade Courses to upgrade the database schema for other courses.

Backups

• Webwork is backed up using Bacula -- see BackupOverview for details on how to perform restores.
• Before each backup the database is dumped to /var/backup/. The database is write-locked during these dumps, so they're guaranteed to be internally consistent. These are compressed SQL files that can be piped to the mysql client to re-create the database. The last three days of backups are kept; older versions can be retrieved by restoring them from Bacula.
• From the Aristotle console, it's possible to create a snapshot of the webwork.math.ucsb.edu's storage by going to Volumes, then clicking the three dots next to each webwork volume and choosing "Manage snapshots."
  • This is good practice before upgrades, since it's a convenient way to unwind them.
  • If it's necessary to roll back to a snapshot, it can be converted to a volume and attached to either the current webwork instance, or a new one.

Troubleshooting

Note: This deals with troubleshooting server issues. For end user issues see WebWork.

Hung httpd processes

Sometimes a badly-coded problem will cause web server processes to hang if a student tries to submit an answer. Since the intuitive response to a timeout is to try again, this can fairly quickly consume all of the available server processes.

Symptoms:

• Slow server response, or timeouts.
• High load average.
• httpd processes with large amounts of accumulated CPU time.
• Large numbers of processes stuck in the writing state on the LibreNMS Apache scoreboard. If the problem has been going on long enough there may also be processes stuck in the graceful shutdown state.

Solution:

• View the Apache server status page (must be accessed on campus or via VPN) to see what request each process is serving. The request URLs for the stuck processes will tell you which course and homework assignment is causing the problem.
• Use SIGKILL (kill -9) to terminate the stuck httpd processes. Apache will automatically launch fresh worker processes to replace them. A relatively efficient way to do this is to run top (I like htop) as root and sort by CPU time. You can also get the PID numbers from the Apache server status page. Be careful not to kill the mysqld process by accident!
• Notify the professor of the course with the bad problem so they can remove it from the homework set.

Database errors

• Unless an upgrade is in progress, these almost always indicate the database server has stopped running.
• This can happen if the server runs out of memory.
• Log into the server and try systemctl start mariadb
• You can also reboot the server, which should clear the problem.
  • Important: Either use reboot from the command line or, if it's unresponsive, "Restart" in the Aristotle instance menu. Do NOT select "Terminate" as this will delete the entire instance, instead of just shutting it down.
• If the server appears to have run out of memory it may be necessary to reduce MaxRequestWorkers in /etc/httpd/conf.modules.d/00-mpm.conf. If a memory leak is suspected, reducing MaxConnectionsPerChild may also help. Consult the MPM configuration documentation for more information.