User Maintenance

The 'Users' tab page is the default after selecting 'maintenance'.

The page lists all the users on the system (except the administrator), in the standard sortable list. Links allow editing and changing the password of each user, while the 'Create new user' link allows adding a user to the database.

Clicking the 'Edit' link for a user shows the user's details above the user list. The fields are:

• Username (required). Must be unique within the system, and contain only letters, digits and underscores
• Full name (required)
• Email address (optional). Note that this is not currently used by JCR
• Enabled. If this box is not ticked, the user will not be able to log in.

Click on the 'Save' button to update the user.

When adding a new user, the same fields are displayed, with the addition of 2 password fields. Passwords are mandatory, and must be at least 6 characters long. Again, click 'save' to add the user.

Clicking the 'Change password' link for a user brings up a page to do exactly that.

The administrator's password can be changed using the 'Change password' menu item on the main page.

Project Maintenance

The 'Projects' tab page lists all projects in the system, including completed projects. The list can be sorted in the usual way. For each project, links allow generation of a status report and deletion.

The status report is the same as the Status Report page visible to all reviewers of the project.

Deleting a project should be done with great caution. It will have the following effects:

• Deletes the project from the database, including all comments, status history, file selections etc.
• Deletes all file diffs generated for the project from the file system.

However, note that File Sets used by the project are not deleted - see under File Set Maintenance for details of deleting file sets.

File Set Maintenance

The 'File sets' tab page provides a project-centric view of all file sets in the system, with each item showing use of a file set in a particular project. Any unused file sets are also shown in the list, but without project details.

If the file set is not used by any project, a link is provided to delete it. Deleting a file set should be done with great caution. It will have the following effects:

• Deletes details of the file set from the database
• Deletes the directory containing the physical files from the file system.

Project Notes Template

If JCR finds a file with the path conf/projectNoteTemplate.txt under the JCR base directory, it uses this as a template (i.e. default contents) for the project notes field when creating a new project. It's useful to add sections for items you normally expect to see in the project notes, e.g. URLs for:

• Test coverage report
• Javadoc or other documentation generated from code
• Static analysis results.

The JCR installer provides a sample template.

External Scripts Page

JCR comes with a useful scripts for generating review tarballs, but it's likely you'll want to make your own scripts available. You do this by making them available via URL, creating a web page containing documentation and links to your scripts, then setting the jcr.assets.externalscriptspage property in the JCR config file. See the Config Page for more details.

Checking Disk Space

Because JCR typically stores 2 copies of all files for a project (for the original and modified versions), it can use a lot of disk space. It's worth making sure you're monitoring disk space on the box it runs on.

If you're using a RedHat-based distribution, you may have diskwatch (?) running via anacron. This will email root if disk usage passes configured limits. This should be enough. Otherwise, you might like to check out Nagios, which is my personal favourite for system monitoring.

Rotating Logs

The JCR log (typically log/jcr.log) will be rotated daily, and the last 14 days' logs will be kept (assuming the standard logging configuration in the config file).

However, stdout log doesn't rotate (if you're running JCR as a service). In theory there shouldn't be much written to it, but you should keep an eye on the size of this log, and periodically roll it by:

• Renaming the stdout log file
• Restarting JCR.

Backing Up

You should set up a backup regime that covers the following:

• JCR install directory (shouldn't change after you've finished installation and configuration)
• The database
• JCR base directory, containing all the project and fileset data. You may wish to exclude the log directory from the backup, and also perhaps prune the files backed up using mkBackupList.py (see below)
• Your SysV Init JCR script (if running as a daemon).

If using Postgres, you can dump the database using pg_dump. Here's a rough script you can use to back up named databases from root's crontab (make sure this dumps to a different filesystem than the one containing your databases!):

#!/bin/sh

# Backup postgres databases (timestamped)

BACKUP_DIR=/backup/postgres

# Add all the DB names you want to back up, as a space-separated list
DBS="jcr"

for db in $DBS; do
    outPath=$BACKUP_DIR/$db-`date +%Y%m%d`.dump
    su - postgres -c "pg_dump --blobs --format=t --file $outPath $db "
done

The JCR base directory gets large over time, with all those file sets and diffs. If backup space is limited, you might like to try the bin/backupjcr.sh script. This attempts to produce a list of all files under the base directory that are really required, by including only projects at or beyond review status. For each of these, the following files/directories will be added to the list:

• Project data directory (include java list, original file list and diff list)
• All files under project diff directory, so long as they are selected for review and have a status of 'changed'
• All files in the original file set for the project, so long as they are selected for review and have a status of 'removed'
• All files in the modified file set for the project, so long as they are selected for review and have a status of 'added'.

This list is then used as the input to tar, to produce a gzipped tarball in the backup directory, including the date in the filename. You'll have to adjust the paths in the shell script to suit your installation.

Note that this shell script is vulnerable to a temp file attack - please check it first to see that you either accept the risk or take steps to mitigate it.

Alternatively, you can use the bin/mkBackupList.py script. This produces the file list used by the bin/backupjcr.sh script. You need to pass the script the path to the site config file, e.g.:

bin/mkBackupList.py jcr.ini > ~/tmp/jcrBackupList

Note: All paths output by this script are relative to the JCR base directory.

Resetting the adminstrator password

Use the bin/resetAdminPassword.py script. You have to provide this with the path to the JCR config file, e.g.:

$ bin/resetAdminPassword.py jcr.ini
...
Enter new administrator password:
Confirm new password:
Password updated successfully
$