Installation Manual for 2.16 on RHEL8

From WeBWorK_wiki
Jump to navigation Jump to search

These instructions cover the installation of the RedHat Enterprise Linux 8 operating system and WeBWorK 2.16 from scratch.

If you are just upgrading WeBWorK, especially if you already have existing WeBWorK courses, see Upgrading WeBWorK from 2.15 to 2.16.

Contents

Notation

First some short comments on notation we will be using. We will use <key> to indicate that you should press a specific key (e.g. <Enter>, <Tab>, <F12>, etc.). Sometimes we will also use e.g. <wwadmin password> to indicate you have to enter the wwadmin password.

^ will indicate the <Ctrl> key so e.g. ^X is really shorthand for <Ctrl> <X>, i.e. press the Ctrl key and hit the X key.

Code blocks that begin with # must be run with root privileges (via either a root shell or sudo). Code blocks that begin with $ may be run as a standard user. You are not intended to type the # or $ characters as part of the provided commands.

Installing the RedHat Enterprise Linux 8 Operating System

Follow the procedure outlined here: https://developers.redhat.com/rhel8/install-rhel8-vbox# TL;DR The installation steps are:

  1. Boot up your server/virtual machine with the Install DVD (or the .iso image file in case of VM)
  2. Select software to be installed. Choose the Workstation base environment, add Development Tools, Graphical Administration Tools, and Container tools. Note: Do not select Server with a GUI.
  3. Choose the disks/partitions to use for installation.
  4. Disable kdump to save memory.
  5. Configure and enable the network connection so that networking starts at boot. Optionally set the host name.
  6. Set the root password
  7. Create your regular user ID (wwadmin) and check the box to make your user (wwadmin) an administrator so you can use sudo.
  8. Start the installation and reboot when finished (remove the DVD when the system restarts)

Continue Installation

  1. After rebooting, accept the license agreement and (optionally) register with your access.redhat.com credentials.
  2. Open a terminal window (Click on Activities in the upper-left, then select the Terminal program)
  3. If you skipped registration, you must complete your registration on the command-line instead: # subscription-manager register --auto-attach
  4. Confirm that registration was successful # yum repolist
  5. Update system software: # yum update
  6. Reboot for changes to take effect

Test Browser, Network and Keyboard

After reboot and login, click on Activities and then find the Firefox icon at the left of the screen.

Go to http://webwork.maa.org/wiki/Installation_Manual_for_2.16_on_RHEL8 where you can view this document and, if you want, copy commands that you need (see below).

Terminal Window Notation and Use

Before installing and configuring additional software, we need to talk about terminal windows.

To open a terminal window select Activities (the RedHat icon on the upper-left side) and type Terminal. The next time you select Activities, the terminal icon might be displayed.

In a terminal window some commands will have to be run as root whereas others should be run as a regular user. We will use # to indicate that the command is to be run as root e.g. 

# perl -MCPAN -e shell

and $ to indicate that the command is to be run as a normal user e.g. 

$ cp .bashrc .bashrc.bak1

To execute the above commands you have to hit <Enter>. We'll just assume this. After executing a command, often the system will respond with text (sometimes a lot of text!) which we will usually not repeat below. We only give the commands that you should execute.

The bash shell which you will be using has a number of very convenient features.

One is command and file name completion. If you are typing (e.g. ch) and hit <tab> bash will complete the command or filename if it is unambiguous (or more precisely it will complete as much as possible). If there are multiple possibilities (as in the case of ch) nothing will happen (except you may hear a beep) and you can type more letter(s) and hit <tab> again. Or you can hit <tab> a second time and you will see a list of all possible completions. E.g. entering ch<tab><tab> gives a list of possible completions and ch<tab>gr<tab> (or chgr<tab>) gives chgrp, the change group command. This is very fast and convenient and it also leads to fewer typing errors.

Another useful shortcut is the command history. Using the up and down arrow keys will bring up previous commands which can be edited and then executed. If you are repeating a command or entering a command which is similar to a previous one, this is very useful. Using ^r will allow you to search through your previous commands instead of cycling through your history with the up and down arrows.

You can copy commands from these instructions (with copy from the Edit dropdown list or ^C) and paste them into a terminal window (with paste from the Edit dropdown list or <Shift> <Ctrl> <V>. Note that <Shift> <Insert> also works). This is an excellent way to use these instructions since it is fast and insures commands are entered correctly (just be careful to read before you run the command and replace things like database_password with the correct code in the few places such things occur).

Running commands as root

To gain root access you have to use the sudo command with the <wwadmin password>. This is the password you set for the first user which we called the WeBWorK administrator <wwadmin> while installing RHEL8.

To run commands as root use the sudo command 

$ sudo <command>
[sudo] password for wwadmin: <wwadmin password>

After you enter the password the command is executed. For a certain period (maybe 5 minutes) you can execute additional sudo commands without reentering <wwadmin password>.

You can also use sudo to become root and get the root prompt #. To do this run 

$ sudo su
[sudo] password for wwadmin: <wwadmin password>
#

When you want to exit the root prompt and return to being a regular user, do the following 

# exit
exit
$

Accessing Your Server Remotely

At this point you can login your server from a remote location using SSH (non secure telnet and FTP are not allowed but secure SSH and SFTP are) but you may have to reboot your server for SSH access to take effect.

You can do almost all (all if you are a unix expert) of the remaining installation from a remote location if you wish.

RHEL Software Packages

We are going to need a couple 'unofficial' packages, which are provided by Fedora Project under the name Extra Packages for Enterprise Linux (EPEL).

Enable the EPEL:

  1. sudo bash start a root shell
[sudo] password for wwadmin: <wwadmin password>
  1. ARCH=$( /bin/arch ) make sure we have the right architecture for pre-built packages
  2. subscription-manager repos --enable "codeready-builder-for-rhel-8-${ARCH}-rpms" enable EPEL repos
  3. yum install https://dl.fedoraproject.org/pub/epel/epel-release-latest-8.noarch.rpm

Install packages from RHEL/EPEL distributions:

  1. # yum -y install dvipng gd-devel texlive-latex httpd-devel mysql-server mysql-devel netpbm-progs ImageMagick dvisvgm nodejs

If prompted, you can always accept the default (hit <Enter>). When the process finishes, enter 

# exit

to return to a regular user.

Editing Files

You can use your favorite editor but we will give instructions assuming you are using the graphical editor gedit. If you are editing files remotely, the terminal mode editor nano is available.

Installing Custom Perl (perlbrew)

RHEL8 does not support some of the necessary perl modules for WeBWorK by default.

Install perlbrew

  1. $ sudo bash become root
  2. # curl -k -L https://install.perlbrew.pl > perlbrew_install.sh fetch the install script
  3. # chmod u+x perlbrew_install.sh make it executable
  4. # export PERLBREW_ROOT="/usr/local/perlbrew" tell the system where to put our custom perls
  5. # ./perlbrew_install.sh run the script
  6. # source /usr/local/perlbrew/etc/bashrc tell your shell about perlbrew so you can use it

In order to be persistent, the last line needs to be added to the `.bashrc` file for the wwadmin user: /home/wwadmin/.bashrc; and should also be added for the root user as well. Instead of adding to each users' .bashrc separately, in RHEL the command can be added to /etc/bashrc, where it will be applied to all users when they log in.

Install Custom perl-5.20.3

If you exit'ed the root shell, you'll again need to sudo bash and make sure that perlbrew has been activated. (If perlbrew does not work, re-run source /usr/local/perlbrew/etc/bashrc and check that you properly added it to your .bashrc or /etc/bashrc file.)

Installation of a new perl version is time consuming. You may add several optional flags to speed up the process.

  1. # export PERLBREW_ROOT=/usr/local/perlbrew just in case you exited your root shell after the previous step
  2. # export CFLAGS='-m64 -mtune=nocona'
  3. # export PERLBREW_CONFIGURE_FLAGS='-des -A ccflags=-fPIC'
  4. # perlbrew -n -j4 --thread install 5.20.3 -Duseshrplib the -n flag skips all tests, and -j# sets the number of parallel threads to use
  5. # perlbrew switch perl-5.20.3 once the perl is built, tell the system which perl you want to use
  6. # perlbrew install-cpanm install cpanminus through perlbrew so that modules are installed for the chosen, active perl

Installing Perl Modules

With cpanminus now installed, we can begin importing the necessary modules from CPAN.

Caveat: the latest version of SQL::Abstract (v2.000001) does not work with WeBWorK -- so we must install an older version (1.87) instead. For some reason, the dependency on Hash::Merge fails during SQL::Abstract installation, so install it separately beforehand. 

# cpanm Hash::Merge
# cpanm ILMARI/SQL-Abstract-1.87.tar.gz
# cpanm Archive::Zip Array::Utils Benchmark Carp CGI CGI::Cookie Data::Dumper Data::UUID \
Date::Format Data::Dump Date::Parse DateTime DBD::mysql DBI Digest::MD5 Digest::SHA Email::Address::XS \
Email::Sender::Simple Email::Sender::Transport::SMTP Email::Simple Errno File::Copy File::Find \
File::Find::Rule File::Path File::Spec File::stat File::Temp GD Getopt::Long Getopt::Std HTML::Entities \
HTML::Scrubber HTML::Tagset HTML::Template HTTP::Async IO::File IO::Socket::SSL Iterator Iterator::Util \
JSON JSON::MaybeXS Locale::Maketext::Lexicon Locale::Maketext::Simple LWP::Protocol::https MIME::Base64 \
Net::IP Net::LDAPS Net::OAuth Net::SMTP Net::SSLeay Opcode PHP::Serialization Pod::Usage Pod::WSDL \
Scalar::Util SOAP::Lite Socket Statistics::R::IO String::ShellQuote Template Text::CSV Text::Wrap \
Tie::IxHash Time::HiRes Time::Zone URI::Escape UUID::Tiny XML::Parser XML::Parser::EasyTree XML::Simple \
XML::Writer XMLRPC::Lite mod_perl2 Apache2::Request

You may encounter issues with the XMLRPC::Lite module not installing because of a failed test. You can forcibly install it as follows: 

# cpanm --force XMLRPC::Lite

Testing Perl Modules

Don't stress out over this section -- we will later install a script that will check for all necessary modules. Do not feel the need to check that all the modules are properly installed at this point.

To test if a Perl module is installed and working on your system, issue the following command, replacing Module with the name of the module: 

$ perl -MModule -e 'print "installed!\n"'

If the module is installed you will see installed!. If not you will see at lot of gibberish. E.g. at this stage in our installation process CPAN is installed and MXML::Parser::EasyTree is not so 

$ perl -MCPAN -e 'print "installed!\n"'

yields 

installed!

and 

$ perl -MStatistics::R::IO -e 'print "installed!\n"'

yields 

Can't locate Statistics/R/IO.pm in @INC ...

You can check the version of an installed module by the following command, replacing Module with the name of the module: 

 perl -MModule -e 'print "$Module::VERSION\n"'

For example for the GD.pm module 

 perl -MGD -e 'print "$GD::VERSION\n"'

Apache 2 and mod_perl

We first need to enable the MPM-prefork module (and disable the MPM-event module) 

# nano /etc/httpd/conf.modules.d/00-mpm.conf

Uncomment the mpm_prefork_module statement and comment out the mpm_event_module 

LoadModule mpm_prefork_module modules/mod_mpm_prefork.so
#LoadModule mpm_event_module modules/mod_mpm_event.so

Next we add configuration files that will add the mod_perl and Apache request modules. 

# nano /etc/httpd/conf.modules.d/02-perl.conf

Add the line LoadModule perl_module modules/mod_perl.so and save the file. 

# nano /etc/httpd/conf.modules.d/apreq.conf

Add the line LoadModule apreq_module modules/mod_apreq2.so and save the file.

Then we configure Apache with our basic server info 

# nano /etc/httpd/conf/httpd.conf

Uncomment and change the server name: 

ServerName yourserverhost.edu

And finally, we need to make sure that the shared libraries have been properly identified 

# ldconfig -v

You should now be able to start up the httpd service 

# systemctl start httpd

Now we have to set your server's fully qualified domain name. Note that if your network was set up automatically via DHCP, your server's fully qualified domain name should already be set up. You can check by running the hostname commands below.

Run the command 

sudo hostnamectl set-hostname webwork
[sudo] password for wwadmin: <wwadmin password>

where of course you should replace webwork by whatever your server's name is.


You can check these settings by running the commands 

$ hostname --fqdn

and 

$ hostname

The first gives the server's fully qualified domain name (e.g. webwork.mydepartment.myschool.edu) and the second the server's name (e.g. webwork).

Note that if your server can not find its fully qualified domain name, certain tools may not start.

Now restart Apache 

$ sudo systemctl restart httpd
[sudo] password for wwadmin: <wwadmin password>

and test your server by connecting to "http://localhost/" and/or connecting to your server from a browser on a remote machine. You should see the Red Hat Enterprise Linux Test Page indicating that Apache is running.

If you have problems now or in the future, a good first thing to do is to look at the Apache error log which is located at /var/log/httpd/error_log. In the directory /var/log/httpd/ you can "less" through the error log (less error_log), look at the last few entires (tail error_log) or run the command tail -f error_log which will display new error messages as they are appended to the file. Use ^C to break out of tail -f .

Checking MySQL

First check that MySQL is running by 

$ sudo mysql
[sudo] password for wwadmin: <wwadmin password>


You should see something very similar to 

Welcome to the MySQL monitor.  Commands end with ; or \g.
Your MySQL connection id is 9
Server version: 8.0.21 Source distribution
...

Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.


Enter exit to exit 

mysql> exit
Bye
$

Checking Apache

Now connect to "http://localhost/" using a browser on your machine and/or to your server from a browser on a remote machine. You should see the Red Hat Enterprise Linux Test Page indicating that Apache is running.

This is also a good time to check that you can login your server from a remote location using SSH if you have not yet done so (non secure telnet and FTP are not allowed but secure SSH and SFTP are).

MySQL Security and Performance Issues

As initially set up, MySQL is an open system. There are anonymous accounts with full privileges for some databases and other issues. We will fix that now. Run the command 

sudo mysql_secure_installation
[sudo] password for wwadmin: <wwadmin password>

You can setup the VALIDATE PASSWORD plugin if you wish. I chose not to.

Next you will be asked to enter a New password for the MySQL "root" user. Enter your chosen MySQL root password. You have to enter a password but it will not be used. In Ubuntu systems running MySQL 5.7 (and later versions), the root MySQL user is set to authenticate using the auth_socket plugin by default rather than with a password.

You almost certainly want to answer 'Y' to all questions except possibly for the first one which asks if you want to set up a VALIDATE PASSWORD plugin. Now test that all is well: 

$ sudo mysql 
[sudo] password for wwadmin: <wwadmin password>

You should see 

Welcome to the MySQL monitor ...
mysql>

Now let's check the MySQL users. There are four accounts. To see the accounts, do the following 

mysql> SELECT user,authentication_string,plugin,host FROM mysql.user;

You will see a table with four users (root, mysql.session, mysql.sys and debian-sys-maint). You should see that one of the four users has a valid password (which will be displayed in encrypted form) and root is authenticated by a socket. You can ignore the mysql.session and mysql.sys users.

Now exit MySQL 

mysql> exit
Bye
$

This last step is optional since currently most of WeBWorK's MySQL tables are now creating using the MyISAM engine (by default -- this can be changed in the config files) rather than the MySQL default engine. Now we change MySQL's default engine. The default engine is InnoDB as of MySQL 5.5.5 (MyISAM before 5.5.5) but (at least on some hardware) InnoDB seems to be 50-100 times slower than MyISAM. So we will change the default MySQL engine from InnoDB to MyISAM. Note that this change only applies to new tables, tables already constructed will continue to use InnoDB. But we haven't created any WeBWorK tables so we don't have to change the engine for any existing tables. Note: There is a report of a problem using MyISAM by a French speaking professor who changed MySQL's default character set to utf8 (see http://webwork.maa.org/moodle/mod/forum/discuss.php?d=3174). If you change MySQL's default character set, you should research what is the best engine to use.

To change the default MySQL engine from InnoDB to MyISAM do the following: 

$ cd /etc/my.cnf.d
$ sudo cp mysql-server.cnf mysql-server.cnf.bak1
[sudo] password for wwadmin: <wwadmin password>
$ sudo gedit mysql-server.cnf

Search for [mysqld] and add the line 

default-storage-engine = myisam

Then save the file and quit. Restart Mysql 

$ sudo systemctl restart mysqld
[sudo] password for wwadmin: <wwadmin password>

and log into mysql 

$ sudo mysql 
[sudo] password for wwadmin: <wwadmin password>

You will see 

Welcome to the MySQL monitor ...
mysql>

If you show MySQL engines, you should see that MyISAM is listed as the default engine. 

mysql> SHOW ENGINES\G

Now exit 

mysql> exit
Bye
$

Congratulate yourself. You are now ready for the next and hopefully easy part, installing WeBWorK.

Downloading the WeBWorK System Software and Problem Libraries

We are finally at the point where we can start downloading and installing WeBWorK. We will use Git to download WeBWorK from Github. This is easy and it will also make it easy to update the system in the future. Note that the following are rather long commands; it is much easier to copy (^C) them from this document and paste (<Shift> <Ctrl> <V>) them in a terminal window 

$ cd /opt
$ mkdir webwork
$ sudo chown wwadmin:wwadmin webwork
[sudo] password for wwadmin: <wwadmin password>
$ cd webwork
$ git clone https://github.com/openwebwork/webwork2.git
$ git clone https://github.com/openwebwork/pg.git
$ git clone https://github.com/openwebwork/webwork-open-problem-library.git
$ mkdir courses
$ mkdir libraries
$ mv webwork-open-problem-library libraries

Important Note. The above commands retrieve the main branch which gives the latest stable release of the software package (webwork2, pg, etc) with bug fixes. If a stable release newer than 2.16 exists, that will be downloaded and these instructions may be a little out of date. So it is a good idea to check before downloading. The best way to do that is to look at https://github.com/openwebwork/webwork2/blob/main/VERSION and https://github.com/openwebwork/pg/blob/main/VERSION.

The first and second download gives you the latest released versions. The third download contains the WeBWorK Open Problem Library (OPL) which is the new name for the original National Problem Library (NPL). The NPL has been renamed to reflect its growing international content. Your system will be loaded with many thousands of WeBWorK problems (over 30,000 currently).

The main information page about WebWork downloads is available at http://webwork.maa.org/wiki/Category:Release_Notes

The main information page about the OPL is available at http://webwork.maa.org/wiki/Open_Problem_Library

Installing WeBWorK

Note the the instructions below assume you are installing WeBWorK from scratch. If you are just upgrading WeBWorK, especially if you already have existing WeBWorK courses, see Upgrading WeBWorK.

Set Up Model Course

Now pull the model course from webwork2 into courses 

$ cd /opt/webwork/webwork2/courses.dist
$ cp *.lst /opt/webwork/courses/
$ rsync -a modelCourse /opt/webwork/courses/

Setting Permissions

The PG installation directory and files should be owned by wwadmin and not writable by other users: 

$ cd /opt/webwork/pg
$ chmod -R u+rwX,go+rX .

Most WeBWorK directories and files should also be owned by wwadmin and not writable by other users: 

$ cd /opt/webwork/webwork2
$ chmod -R u+rwX,go+rX .

Certain data directories need to be writable by the web server. These are DATA, courses, htdocs/tmp, logs, and tmp. It is convenient to give WeBWorK administrators access to these directories as well, so they can perform administrative tasks such as removing temporary files, creating and editing courses from the command line, managing logs, and so on. We will add our user, wwadmin, to the apache group. Run the command 

$ sudo usermod -a -G apache wwadmin
<wwadmin password>

If there are other users who will also be administering WeBWorK files, now is a good time to add them. To do this

  1. Open Activities, type Settings and open Settings
  2. Click on Details
  3. Click on Users
  4. Click the "Unlock" icon and enter the <wwadmin password>
  5. Click the "Add User..." button and create the new account
  6. And remember to add the new account to the apache group as above.

You can check that this succeeded in a terminal window by entering 

$ id wwadmin

and then you should see apache listed under groups.

Now we make the WeBWorK directories that need to be writable by the web server have apache as their group. The following are rather long commands; you might want to copy them and paste them into your terminal window rather than typing them. 

$ sudo bash
[sudo] password for wwadmin: <wwadmin password>
# cd /opt/webwork/webwork2/
# chgrp -R apache DATA ../courses htdocs/tmp htdocs/applets logs tmp /opt/webwork/pg/lib/chromatic
# chmod -R g+w DATA ../courses htdocs/tmp htdocs/applets logs tmp /opt/webwork/pg/lib/chromatic
# find DATA/ ../courses/ htdocs/tmp logs/ tmp/ -type d -a -exec chmod g+s {} \;
# exit
$

Configure SELinux

We need to make sure that httpd has write-access to certain filesystems 

$ sudo bash
[sudo] password for wwadmin: <wwadmin password>
# semanage fcontext -a -t httpd_sys_content_t '/opt/webwork(/.*)?' 
# semanage fcontext -a -t httpd_sys_rw_content_t '/opt/webwork/courses(/.*)?'
# semanage fcontext -a -t httpd_sys_rw_content_t '/opt/webwork/webwork2/logs(/.*)?'
# semanage fcontext -a -t httpd_sys_rw_content_t '/opt/webwork/webwork2/htdocs/tmp(/.*)?'
# setsebool -P httpd_can_sendmail 1
# setsebool -P httpd_can_network_connect on
# restorecon -vFR /opt

We also want to allow httpd to send pings during startup, which means we have to tell SELinux that's okay too. Anywhere (preferably in your home directory) create a new file called my-ping.te. Paste the following into the empty file: 

module my-ping 1.0;

require {
       type httpd_t;
       class icmp_socket create;
       class rawip_socket { create getopt setopt write read };
       class capability net_raw;
}

#============= httpd_t ==============
allow httpd_t self:capability net_raw;
allow httpd_t self:icmp_socket create;
allow httpd_t self:rawip_socket { create getopt setopt write read };

Exit and save the file, then compile and install the policy: 

# checkmodule -M -m -o my-ping.mod my-ping.te
# semodule_package -o my-ping.pp -m my-ping.mod
# semodule -X 300 -i my-ping.pp

Compile color.c

$ cd /opt/webwork/pg/lib/chromatic
$ gcc color.c -o color

You may see some warning messages which you can safely ignore.

Configuring the Shell

To make working with WeBWorK easier, there are a couple of changes you can make to your shell environment.

Add the WeBWorK bin directory to your path. This will allow you to run WeBWorK command-line utilities without typing the full path to the utility. Goto your home directory and backup your .bashrc file 

$ cd
$ cp .bashrc .bashrc.bak1

Now edit .bashrc 

$ gedit .bashrc

After the last line add the three lines: 

export PATH=$PATH:/opt/webwork/webwork2/bin
export WEBWORK_ROOT=/opt/webwork/webwork2
export PG_ROOT=/opt/webwork/pg

Then save the file and Quit.

(Alternatively, these edits can be done on /etc/profile, which will apply to all users)

Close your Terminal Window and open a new one so the above changes take effect. You can check that they have by 

$ echo $PATH
$ echo $WEBWORK_ROOT
$ echo $PG_ROOT

Checking Module Dependencies

WeBWorK includes a script called check_modules.pl (in the directory /opt/webwork/webwork2/bin) that verifies that the needed programs and Perl modules are installed on your system. Run this script to make sure you have installed the required programs and Perl modules. 

$ check_modules.pl apache2

Scroll up and look through the listing. It should find everything. If something is missing (flagged by **), look back through these instructions to find where it should have been installed and install it.

You may see some warning messages like 

Prototype mismatch: sub main::from_json: none vs ($@) at (eval 188) line 2.
Prototype mismatch: sub main::to_json: none vs ($@) at (eval 188) line 2.

This seems to be a known bug in libjson-perl and can be safely ignored.

Now we check that all necessary LaTeX packages have been installed. Run the commands 

$ cd
$ pdflatex /opt/webwork/webwork2/bin/check_latex.tex

and look for missing packages.

Configuring WeBWorK

Making Copies of the Distribution Configuration Files

Before configuring the system, you must make local copies of the site.conf and localOverrides.conf configuration files, located in /opt/webwork/webwork2/conf/ . 

$ cd /opt/webwork/webwork2/conf
$ cp site.conf.dist site.conf
$ cp localOverrides.conf.dist localOverrides.conf

System Configuration

Most WeBWorK configuration is done in the files /opt/webwork/webwork2/conf/site.conf and /opt/webwork/webwork2/conf/localOverrides.conf. These files provide system-wide configuration settings, and defaults for course settings. Any setting in these files can be overridden in the course.conf file for a particular course. To override a setting for a course, just put the new setting (using the same syntax as is in localOverrides.conf) in the course.conf file. An instructor can only edit the course.conf file herself (for her own course) if she has "admin" privilege which by default instructors do not have. But most things instructors may want to customize and many others (language, timezone, permissions, display modes, email, ...) can be set using the Course Configuration page from within the course and such setting override those in the configuration files.

Actually there are three main configuration files, site.conf, defaults.config and localOverrides.conf. The reason there are three configuration files is to make upgrading WeBWorK easier.

  • site.conf: This file contains global variables which are required for basic configuration. It will not be overridden when you update WeBWorK but its distribution version, site.conf.dist will be.
  • defaults.config: This file contains initial settings for many customizable options in WeBWorK. Do not edit defaults.config. It will be overridden next time you upgrade.
  • localOverrides.conf This is where you should add all local customizations. It will not be overridden when you update WeBWorK but its distribution version, localOverrides.conf.dist will be.

There are several options that must be set for WeBWorK to work with your system. The rest of the file consists of customization options.

Edit the site.conf file

Now edit site.conf 

$ cd /opt/webwork/webwork2/conf
$ gedit site.conf

First we have to add information about the Apache2 server setup. Search for server_root_url and edit the line so that it reads: 

$server_root_url   = "http://yourserver.yourschool.edu";

where of course you should edit yourserver.yourschool.edu appropriately. If you are running a secure server (i.e., using ssl), the url should start with https but you should wait to make that change until after WeBWorK is up and running and you set up ssl.

We need to set a password that WeBWorK uses when it communicates with the MySQL database. Note that this is not the same as the <mysql root password> which is the unused password we set when securing MySQL. Search for database_password and replace the line 

$database_password = "passwordRW";

by 

$database_password = "database_password";

where of course you should replace 'database_password' with your own password. Remember this password as we will need it below.

WeBWorK sends mail in three instances. The PG system sends mail to report answers to questionnaires and free-response problems. The mail merge module is used to send mail to course participants, i.e. to report scores. The feedback module allows participants to send mail to course instructors.

To send mail, WeBWorK needs the address of an SMTP server. Normally you will use the address of your school's SMTP server. If the local machine is running an SMTP server, use localhost. IMPORTANT: Our instructions above did not install an SMTP server so you will have to install and configure one if you do not use your school's SMTP server. When connecting to the SMTP server, WeBWorK must also send an email address representing the sender of the email (this has nothing to do with the From address on the mail message). Edit the lines 

$mail{smtpServer} = ;  # e.g. 'mail.yourschool.edu' or 'localhost'
$mail{smtpSender} = ;  # e.g.  'webwork@yourserver.yourschool.edu'

entering the appropriate information. Be sure to use single quotes and NOT double quotes around email addresses otherwise Perl will treat @ as an array variabe.

WeBWorK uses the DateTime module. DateTime is supposed to be able to determine the local timezone itself without you having to enter it but this often fails so it is best to just set it here. For is a list of timezones recognized by DateTime go to http://search.cpan.org/dist/DateTime-TimeZone/ . These timezones are more refined than standard timezone usage in that they include switches to daylight savings time (e.g. some parts of a time zone may make the switch and others may not). For example if your server is in the eastern US, on the list you will see DateTime::TimeZone::America::New_York and you should enter $siteDefaults{timezone} = "America/New_York"; which is the default. Read the documentation in this section of the the site.conf file for more information on selecting timezones and formatting dates.

Search for $siteDefaults{timezone} and enter your local timezone if it is not correct.

Note: Some servers will need to set a value of $server_apache_version in site.conf. This setting is needed when the Apache settings disable the display of the Apache version number in Apache banner of the HTTP headers, typically by setting ServerTokens Prod in the Apache cponfig, as many security teams will recommend. In such cases, without a setting for this variable, WeBWorK will fail to detect that you are using Apache 2.4 and users will run into error pages reporting Can't locate object method "remote_addr" via package "Apache2::Connection" at /opt/webwork/webwork2/lib/WeBWorK/Authen.pm which will also appear in the Apache error.log file. The fix is to search for $server_apache_version, uncomment the line, and set a suitable value (currently "2.4" should work, and a fix to support settings like "2.4.29" is pending).

Then save the file and Quit.

The defaults.config file

If you want WeBWorK questionnaires or similar things from different courses to be mailed to a central person or persons (e.g. the WeBWorK administrator), in defaults.config, you will see the lines 

$mail{allowedRecipients}     = [
   #'prof1@yourserver.yourdomain.edu',
   #'prof2@yourserver.yourdomain.edu',
];

But we are not supposed to edit the defaults.config file, so if we want to do this, we will copy this to localOverrides.conf and edit it appropriately. Note that we should move this setting to the site.conf file.

Edit the localOverrides.conf file

$ cd /opt/webwork/webwork2/conf
$ gedit localOverrides.conf

As we said above, if you want WeBWorK questionnaires or similar things from different courses to be mailed to a central person or persons (e.g. the WeBWorK administrator), in localoverrides.config, add and then edit the lines 

$mail{allowedRecipients}     = [
   #'prof1@yourserver.yourdomain.edu',
   #'prof2@yourserver.yourdomain.edu',
];

removing the # and using the professor(s) actual email address(es). In order to have professors from individual courses receive such email, this should be set in course.conf (which you find in the course directory) to the addresses of professors of each course. Note that the settings in course.conf override the settings in site.conf, default.conf and localOverrides.conf so if in addition you want e.g. the WeBWorK administrators to receive copies, you have to add them as well.


Then save the file and Quit.

After you have used WeBWorK for awhile, you may want to change the default header files in defaults.config. Search for $webworkFiles{screenSnippets}{setHeader} and $webworkFiles{hardcopySnippets}{setHeader} in localOverrides.config. Settings in the conf and config files affect all WeBWorK courses. You can override any setting in these conf and config files for an individual course by putting the local setting in course.conf.

Also now there are several versions of the classlist editor, homeworkset editor, library browser and pgproblem editor. Which ones are available in a course is determined by the settings for %showeditors in localOverrides.conf. As above, if you want to customize what is available for an individual course (e.g. one professor may want to try out the new editors and others may not), copy the %showeditors structure to course.conf and then edit it to make available the desired editors.

Set up the webwork database

WeBWorK uses a single database, called webwork, for all courses. We will create the webwork database now.

To do this do the following (before you just copy, paste and hit <Enter> notice that you have to replace database_password with the password you set when editing site.conf above): 

$ sudo mysql 
[sudo] password for wwadmin: <wwadmin password>

mysql> CREATE DATABASE webwork;
mysql> CREATE USER 'webworkWrite'@'localhost' IDENTIFIED BY 'database_password';
mysql> GRANT SELECT, INSERT, UPDATE, DELETE, CREATE, ALTER, DROP, LOCK TABLES ON webwork.* TO 'webworkWrite'@'localhost';
mysql> exit
Bye
$

where, as we said, replace database_password with the password you set when editing site.conf above.

You may also want to include a read-only database user, in which case you should perform the following commands before exit'ing 

mysql> CREATE USER 'webworkRead'@'localhost' IDENTIFIED BY 'readonly_password';
mysql> GRANT SELECT ON webwork.* TO 'webworkRead'@'localhost';

Javascript Modules

WeBWorK's Javascript dependencies are now handled with npm. Perform the following to make sure that the necessary Javascript libraries are installed. 

$ cd /opt/webwork/webwork2/htdocs
$ npm ci

Configuring Apache

WeBWorK ships with an Apache config file that needs to linked into your Apache configuration process. The file is named webwork.apache2.4-config.dist and located in the conf directory. First, copy the file to webwork.apache2-config: 

$ cd /opt/webwork/webwork2/conf
$ cp webwork.apache2.4-config.dist webwork.apache2.4-config

and now link it into your Apache configuration process 

$ sudo su
[sudo] password for wwadmin: <wwadmin password>
# ln -s /opt/webwork/webwork2/conf/webwork.apache2.4-config /etc/httpd/conf.d/webwork.conf

The default multi-processing module (MPM) for Apache is the event module but WeBWorK uses the prefork module. So we disable the event module and enable the prefork module. 

# nano /etc/httpd/conf.modules.d/00-mpm.conf

Uncomment the line 

 LoadModule mpm_prefork_module modules/mod_mpm_prefork.so

Comment out the line 

 #LoadModule mpm_event_module modules/mod_mpm_event.so

Next we will make a few changes to Apache's default configuration. We need to edit two files and we will save copies of the original files. 

# cd /etc/apache2/
# cp apache2.conf apache2.conf.bak1
# exit
$ cd /etc/apache2/
$ sudo gedit apache2.conf

Search for the line 

Timeout 300

and replace it by 

Timeout 1200

Then save the file and quit. 

$ sudo su
[sudo] password for wwadmin: <wwadmin password>
# cd /etc/apache2/mods-available/
# cp mpm_prefork.conf mpm_prefork.conf.bak1
# exit
$ cd /etc/apache2/mods-available/
$ sudo gedit mpm_prefork.conf

Search for the lines 

    MaxRequestWorkers        150
    MaxConnectionsPerChild   0

Which occur under <IfModule mpm_prefork_module> and replace them by 

# For WeBWorK a rough rule of thumb is 5 MaxRequestWorkers per 1 GB of memory
      MaxRequestWorkers        5
      MaxConnectionsPerChild   50

where you should set MaxRequestWorkers depending on the amount of memory your server has using the above rule of thumb. Note that for very busy servers, you should observe you memory usage and adjust the above settings as necessary. Also make sure MaxSpareServers is not set too high.

Then save the file and quit.

Finally we copy WeBWorK's icon file favicon.ico to Apache's www directory. 

$ sudo cp /opt/webwork/webwork2/htdocs/favicon.ico /var/www/html
[sudo] password for wwadmin: <wwadmin password>

Now stop and start Apache. We do it this way to make sure the MPM gets changed. 

$ sudo apache2ctl stop
$ sudo apache2ctl start

Test your configuration

  1. Test the /webwork2 location by visiting http://yourserver.yourschool.edu/webwork2. You should see the WeBWorK home page with no courses listed. Actually the directory /opt/webwork/courses/ does contain the modelCourse but the modelCourse is not a real course so you will get an error message if you try to log into it. It will be used a as model for setting up other courses. For this reason /opt/webwork/courses/modelCourse/ contains a file named hide_directory and so the modelCourse is not visible.
  2. Test the /webwork2_files location by visiting http://yourserver.yourschool.edu/webwork2_files. You should see the "WeBWorK Placeholder Page".
  3. You cannot test the /webwork2_course_files location until you have created a course.

If Something is Wrong

If something is wrong one of the first things to check is that the config files have been edited correctly (e.g. one time a wrapped line in localOverrides.conf caused me problems, another time it was a missing single quote). A quick way to check this is to do a diff between the edited and distributed versions and check that diff reports the changes you made and only those. Another thing is to look at the Apache error log which is located at /var/log/apache2/error.log. 

$ cd /etc/apache2/
$ diff apache2.conf apache2.conf.bak1
$ cd /opt/webwork/webwork2/conf/
$ diff site.conf site.conf.dist
$ diff localOverrides.conf localOverrides.conf.dist
$ diff webwork.apache2.4-config webwork.apache2.4-config.dist
$ less /var/log/apache2/error.log

If something is wrong and you fix it, you will have to restart Apache for the changes to take effect 

$ sudo service apache2 restart
[sudo] password for wwadmin: <wwadmin password>

Create the admin Course

Course Administration gives information about creating courses. Here we will give explicit instructions for doing this. (You may need to become root or use sudo to execute some of these commands.) 


$ umask 2
$ cd /opt/webwork/courses
$ /opt/webwork/webwork2/bin/addcourse admin --db-layout=sql_single --users=adminClasslist.lst --professors=admin


Make the course admin and its subdirectories owned by the Apache server. 

$ sudo chown -R www-data  admin 
[sudo] password for wwadmin: <wwadmin password>
$ exit

Now goto http://yourserver.yourschool.edu/webwork2 and should see the WeBWorK home page with Course Administration listed at the top. Click on it and login with Username admin and Password admin . This first thing you should do is register your new WeBWorK installation. It's quick and easy, just click on Register. The next thing you should do is click on User Settings and change admin 's password to something more secure than admin .

Unless you choose otherwise, users with admin privileges in the admin course (i.e. WeBWorK administrators) will automatically be added to new courses with admin privileges and the same password as in the admin course. Initially the only such user is admin (hopefully you are not confused by the fact that the course admin has a user named admin). It's usually convenient make yourself a WeBWorK administrator. To do this (assuming you are logged in as admin to the admin course at http://yourserver.yourschool.edu/webwork2/admin )

  1. Click on Classlist Editor in the left panel
  2. Click the Add tag and click Take Action!
  3. Enter the appropriate information (you can use your Login Name as the Student ID if you want and also you can leave the last three items blank) and click Add Students
  4. Click on Classlist Editor in the left panel again
  5. When you enter a new student, by default their Student ID is used as their password. We'll change this now.
  6. Select yourself with a check mark and click the Password tag and click Take Action!. (Note as a safely mechanism you can not change the password for the user you are logged in as, currently admin, this way)
  7. Enter the password and then click Take Action!
  8. Finally give yourself admin privileges by selecting yourself with a check mark, clicking the Edit tag and then clicking Take Action! (or by just clicking on the "pencil" next to your login name which is a much faster way to edit classlist data for a single user)
  9. Now at the far right change Permission Level from student to admin
  10. Then click Take Action!

At some point you will probably want to hide the admin course so that it is not listed on the WeBWorK home page. As we noted above the modelCourse, which is already hidden, is not a real course so you will get an error message if you try to log into it. This is a good reason to hide it. The modelCourse is very useful as a model (hence its name) for setting up other courses. The admin course is used for administering WeBWorK and even though regular users can not log into it (you did change the admin password, didn't you!!), it a little bit cleaner and safer to hide it from prying eyes. To hide (or unhide) a course select Hide Inactive courses in the admin course and follow the directions. When hidden a course will not show up in the courses list on the WeBWorK home page. It will still appear in the Course Administration listing. If you do this you will still be able to access the admin course using the URL http://yourserver.yourschool.edu/webwork2/admin but you will not see a link for it on the WeBWorK home page http://yourserver.yourschool.edu/webwork2 .


Now goto http://yourserver.yourschool.edu/webwork2 and no course will be listed.

Checking for and Installing Hotfixes

The following commands show you how to check for and install bug fixes. Important Note: These commands check and retrieve the main branch which gives the latest stable release of the software package (webwork2, pg, etc) with bug fixes. If a stable release newer than 2.16 exists for webwork2 and/or pg, that will be checked and retrieved which is probably not what you want. Please check before updating. The best way to do that is to look at https://github.com/openwebwork/webwork2/blob/main/VERSION and https://github.com/openwebwork/pg/blob/main/VERSION.

To check if there are bug fixes, do the following.

Updating the webwork2 code

First we check for updates to the webwork2 code: 

cd /opt/webwork/webwork2/
git remote show origin

This will print several lines of data, but the last line will tell you if your copy is up to date or out of date. If it is out of date, run 

git pull origin

and restart httpd.

Updating the pg code

Now check for updates to the pg code: 

cd /opt/webwork/pg/
git remote show origin

This will print several lines of data, but the last line will tell you if your copy is up to date or out of date. If it is out of date, run 

git pull origin

and restart httpd.

Restart httpd

Important: After updating either webwork2 or pg, you have to restart apache2 

$ sudo systemctl restart httpd
password:<wwadmin password>

Updating the OPL

The following assumes you have already installed the OPL. For that see #Install the Open Problem Library below. Now check for updates to the Open Problem Library: 

cd /opt/webwork/libraries/webwork-open-problem-library
git remote show origin

This will print several lines of data, but the last line will tell you if your copy is up to date or out of date. If it is out of date, run 

git pull origin

Then rerun the OPL-update script. Updating the OPL is pretty much risk free since changes usually involve only a relatively small number of individual problems and the vast majority of problems remain unchanged. Updating the OPL does not require restarting apache2. 

$ OPL-update

Updating Javascript

cd /opt/webwork/htdocs/
npm install

Updating Javascript libraries is usually very safe and does not require restarting httpd.

Starting and Stopping System Services

If you make changes to the system, you will have to restart apache2 before the changes take effect. On rare occasions you may need to restart MySQL.

Starting and Stopping Apache

You have to run these commands as root.

To start or restart (i.e. stop and then start) the apache2 webserver run the command 

$ sudo systemctl restart httpd
[sudo] password for wwadmin: <wwadmin password>

To stop the Apache webserver run the command 

$ sudo systemctl stop httpd
[sudo] password for wwadmin: <wwadmin password>

Stopping and then starting Apache should definitely kill all apache2 child processes.

Starting and Stopping MySQL

You have to run these commands as root.

To start the MySQL server run the command 

$ sudo systemctl start mysqld
password:<wwadmin password>

To stop the MySQL server run the command 

$ sudo systemctl stop mysqld
[sudo] password for wwadmin: <wwadmin password>

To restart the MySQL server run the command 

$ sudo systemctl restart mysqld
[sudo] password for wwadmin: <wwadmin password>

Install the WeBWorK Problem Libraries

Before we create a real course we will install the WeBWorK Problem Libraries.

Fix the modelCourse

Unfortunately in the 2.16 distribution someone tried to make setting up the libraries easier but they made mistakes so we have to remove two incorrect links. Do the following: 

$ cd /opt/webwork/courses/modelCourse/templates/
$ rm Contrib
$ rm CAPA

We will set up the correct links below.

Install the Open Problem Library

The Open Problem Library consists of both WeBWorK problems and methods for searching and selecting problems. Also it contains as sub libraries many of the other standard libraries. We have to load a database for searching it.

Run the OPL-update script. 

$ OPL-update

This has to convert a lot of data for over 37,000 problems so please be patient; it can take a long time.

If at some time in the future you want to upgrade the Problem Library, the process is easy, see Updating the OPL. Note that this is something you should do fairly often so that your library is up to date with new problems and bug fixes for old ones.

Finally we put a link to the Open Problem Library in the modelCourse so that when we create courses copying templates from the modelCourse, the OPL will be available. 

$ cd /opt/webwork/courses/modelCourse/templates/
$ ln -s /opt/webwork/libraries/webwork-open-problem-library/OpenProblemLibrary Library

Set up the access to the Contrib directory

The Contrib directory contains contributions to the OPL that may not have been formally accepted into the main collection of OPL problems. This may be because the contribution is recent and has not yet been reviewed or because the problems are not properly tagged as is the case with the CAPA problem collection. It also contains the original versions of problems that have been accepted into the OPL (the idea being that the original authors maintain control of problems in the Contrib directory but problems in the OPL are controled by the editors). This step creates a button in the Library Browser which gives a direct link to the Contrib directory.


Put a link to the Contrib directory in the modelCourse so that when we create courses copying templates from the modelCourse, the Contrib directory will be available. 

$ cd /opt/webwork/courses/modelCourse/templates/
$ ln -s /opt/webwork/libraries/webwork-open-problem-library/Contrib Contrib

If you just want to do this for individual courses, not all courses then don't put the link in the modelCourse above, and then do the following. Note we don't have any individual courses yet. But for example after creating myTestCourse below, to set up access to the Contrib directory from myTestCourse, do the following 

$ cd /opt/webwork/courses/myTestCourse/templates/
$ sudo $ ln -s /opt/webwork/libraries/webwork-open-problem-library/Contrib Contrib
[sudo] password for wwadmin: <wwadmin password>

Set up the Rochester and Union Libraries

This step is optional. It creates buttons in the Library Browser which give direct links to the Rochester and Union libraries. If you don't do this, you can find these libraries and others under the OPL Directory button.

First we need to edit localOverrides.conf one last time 

$ cd /opt/webwork/webwork2/conf
$ gedit localOverrides.conf

Search for courseFiles{problibs} and scroll down several lines to the lines 

#       rochesterLibrary => "Rochester",
# 	unionLibrary     => "Union",

Uncomment these lines (i.e. remove the #) so they become 

      rochesterLibrary => "Rochester",
      unionLibrary     => "Union",

Then save the file and quit.

We next put links to the Rochester and Union Libraries in the modelCourse so that when we create courses copying templates from the modelCourse, these libraries will be available. Skip this step if you usually only want to use Open Problem Library. Note that the Rochester, Union and other libraries are contained in the OPen Problem Library and are accessible from there under the OPL Directory button in the Library Browser. This step simply creates buttons in the Library Browser so that you can access the Rochester and Union libraries directly. 

$ cd /opt/webwork/courses/modelCourse/templates/
$ ln -s /opt/webwork/libraries/webwork-open-problem-library/OpenProblemLibrary/Union unionLibrary
$ ln -s /opt/webwork/libraries/webwork-open-problem-library/OpenProblemLibrary/Rochester rochesterLibrary

If you want to put another library into the modelCourse, just do the analogous thing. If you just want the additional library in a particular course, add the link in the templates directory of that course. If you look in the directory /opt/webwork/libraries/webwork-open-problem-library/OpenProblemLibrary/ you might find other libraries that are not yet listed in global.conf and these can be added in the same way as the Rochester and Union libraries. Finally if you add a library with non standard symbols in the name (e.g. uva-statLibrary) you have to use single quotes when adding it to global.conf, e.g.
         'uva-statLibrary' => "UVA-Stat",
It's easier to just avoid such names.

Install and Set Up the CAPA Library

This step is optional. It installs and sets up the CAPA Library, which is a library of physics problems.

Note: We are in the process of integrating the CAPA problems into the main distribution so some of the details below may change.

Move the CAPA graphics files to the required locations and set the group. 

$ cd /opt/webwork/libraries/webwork-open-problem-library/Contrib/CAPA                                                                        
$ mv CAPA_Graphics /opt/webwork/webwork2/htdocs/
$ sudo chgrp -R apache /opt/webwork/webwork2/htdocs/CAPA_Graphics
  [sudo] password for wwadmin: <wwadmin password>
$ sudo chmod -R g+w /opt/webwork/webwork2/htdocs/CAPA_Graphics

We need to edit localOverrides.conf again 

$ cd /opt/webwork/webwork2/conf
$ gedit localOverrides.conf


Now search for the lines 

$pg{specialPGEnvironmentVars}{CAPA_Tools}             = "$courseDirs{templates}/Contrib/CAPA/macros/CAPA_Tools/",
$pg{specialPGEnvironmentVars}{CAPA_MCTools}           = "$courseDirs{templates}/Contrib/CAPA/macros/CAPA_MCTools/",
$pg{specialPGEnvironmentVars}{CAPA_GraphicsDirectory} = "$courseDirs{templates}/Contrib/CAPA/CAPA_Graphics/",
push @{$pg{directories}{macrosPath}},
  "$courseDirs{templates}/Contrib/CAPA/macros/CAPA_Tools",
  "$courseDirs{templates}/Contrib/CAPA/macros/CAPA_MCTools";

and replace these six lines by 

################################################################################
#Locations of CAPA resources. (Only necessary if you need to use converted CAPA problems.)
################################################################################
$pg{specialPGEnvironmentVars}{CAPA_Tools}             = "$courseDirs{templates}/Contrib/CAPA/macros/CAPA_Tools/",
$pg{specialPGEnvironmentVars}{CAPA_MCTools}           = "$courseDirs{templates}/Contrib/CAPA/macros/CAPA_MCTools/",
$pg{specialPGEnvironmentVars}{CAPA_GraphicsDirectory} = "$webworkDirs{htdocs}/CAPA_Graphics/";
$pg{specialPGEnvironmentVars}{CAPA_Graphics_URL}      = "$webworkURLs{htdocs}/CAPA_Graphics/";



Then save the file and Quit.

There is one final step that is needed. We have to put a link in the templates directory of every course that needs access to the CAPA Library. If you want to have every course you create have access to the CAPA Library (unlikely unless you are in a physics department) put the link in the modelCourse. 

$ cd /opt/webwork/courses/modelCourse/templates/
$ ln -s /opt/webwork/libraries/webwork-open-problem-library/Contrib/CAPA/   capaLibrary

More likely if you just want to do this for individual courses, not all courses then don't put the link in the modelCourse above, and then do the following. We don't have any yet. But for example after creating myTestCourse below, to set up access to the CAPA Library from myTestCourse, do the following 

$ cd /opt/webwork/courses/myTestCourse/templates/
$ sudo ln -s /opt/webwork/libraries/webwork-open-problem-library/Contrib/CAPA/   capaLibrary
[sudo] password for wwadmin: <wwadmin password>


and do the analogous thing for every course that needs access to the CAPA Library. Then to gain access to the CAPA Library from the course, simply go to the Library Browser and click on the CAPA button.

Create Your First Actual Course

Since we have edited site.conf and localOverrides.conf and these are critical files, it would be a good idea to run 

$ cd /opt/webwork/webwork2/conf
$ diff site.conf site.conf.dist
$ diff localOverrides.conf localOverrides.conf.dist

and check that you haven't made any mistakes (e.g. by introducing an inadvertent line break, etc). If there are any mistakes, correct them. Remember that any time you change either of these files you must restart the Apache webserver in order for these changes to take effect.

Since we have edited global.conf and haven't restarted Apache we do so now. 

$ sudo apache2ctl graceful
password:<wwadmin password>

Now log into the admin course ( http://yourserver.yourschool.edu/webwork2/admin or, if you have not hidden the admin course, click on Course Administration on WeBWorK's home page http://yourserver.yourschool.edu/webwork2/ ) as yourself or admin and

  1. click on Add Course
  2. For Course ID enter myTestCourse
  3. For Course Title enter My Test Course
  4. Enter your institution
  5. Leave Add WeBWorK administrators to new course checked
  6. Add an additional instructor if you wish
  7. Copy templates from: modelCourse (the default action)
  8. Click on Add Course
  9. Click Log into myTestCourse

and log in either as admin or yourself (if you added yourself as an additional instructor above).

At some point you will probably want to "hide" myTestCourse from general view but you already know how to do that.

Test that Things are Working Properly

We will test out a few important parts of WeBWorK. If you run into problems, you should look at the Apache error log which is located at /var/log/apache2/error.log.

Click on Hmwk Sets Editor on the Main Menu. Then select Import, select setDemo.def from the from drop down list and select all current users from the assigning this set to drop down list. Then hit Take Action!

Now click on Homework Sets on the Main Menu and click on Demo. Then look at the problems. Mathematical equations should be typeset. If not, edit the file Constants.pm in the directory /opt/webwork/webwork2/lib/WeBWorK. Change the line $WeBWorK::PG::ImageGenerator::PreserveTempFiles = 0; to ...::PreserveTempFiles = 1;. Then restart Apache and view the first couple problems or some new ones. Then look in the directory /opt/webwork/webwork2/tmp/. cd to one of the ImageGenerator.../tmp/ directories and look at the error and log files there. When you fix the problem remember to edit ...::PreserveTempFiles = 1; back to 0 and restart Apache or you will be saving a lot of unnecessary files. Another useful trick is to try downloading a hard copy of an assignment and then (assuming there are errors) looking at the various log files that are linked to on the output page.

Continue looking at problems to see if everything is working properly.

Next click on Problem List to bring back the Problem List Page and click on Download PDF .... The page is a little complicated because you are a professor (students see a very simple page) but you can just scroll to the bottom and click on Generate hardcopy for selected users and selected sets. If you get an error (you shouldn't) just click Download Hardcopy to get what was generated. Also you can see links to various informational files that are available if you run into problems (normally these files are removed if there are no errors). If you want to preserve these tmp files, set $WeBWorK::ContentGenerator::Hardcopy::PreserveTempFiles to 1 in the file Constants.pm in the directory /opt/webwork/webwork2/lib/WeBWorK and then restart Apache. Remember to set this back to 0 after debugging.

Another thing to do is to use Email on the Main Menu. Again this page is a little complicated because you can do a lot of things with it (including mail merge) but at this point just select yourself in the list to the right and hit Send Email at the bottom. You should receive two emails. One is the message you just sent and the other is an email with subject "WeBWorK email sent" giving information on your mailing.

As a final test click on Library Browser on the Main Menu. Click Open Problem Library (actually it should already be selected so it will greyed out) and select a Subject, Chapter and Section and then hit View Problems. The first 20 of your selected problems will be displayed. You can also test that you can access any additional Problem Libraries that you installed.

If all the above tests work, you can be pretty confident that WeBWorK is working properly.

Go back to Hmwk Sets Editor on the Main Menu. Then select Import, select setOrientation.def from the from drop down list and select all current users from the assigning this set to drop down list. Then hit Take Action!. Then go through the Orientation problems. This is a good first set to use for introducing students to WeBWorK.

If you are new to WeBWorK, you should probably add a regular student to myTestCourse and log in as that student to see what the student interface looks like. It's much simpler than the professor interface. Click on Classlist Editor on the Main Menu. Then select Add and hit Take Action!. Add one student, say Jane Smith, with Student ID 1234 and Login Name jsmith. Jane Smith's initial password will be her Student ID 1234. Now login as Jane Smith and play around a little.

Where to go From Here

You should play around with myTestCourse e.g. click on Library Browser and browse the Problem Library.

Look at A day in the life of a WeBWorK instructor.

Read Course Administration for more information about creating courses.

Under Categories below click on Administrators to see a listing of other WeBWorK documentation for system administrators.

-- Main.AndrewParker - 17 May 2021

Retrieved from "https://webwork.maa.org/mediawiki_new/index.php?title=Installation_Manual_for_2.16_on_RHEL8&oldid=22755"