Installation of 2.0pr3 on webwork2.math.rochester.edu

This article has been retained as a historical document. It is not up-to-date and the formatting may be lacking. Use the information herein with caution.

This is a mildly edited version of the log I kept while installing Preview release 3 on webwork2.math.rochester.edu

Test that modperl is activated:

server-status and server-info are the natural ways to do this, but they are blocked from my home computer, so I was not able to check directly. (I temporarily changed the restrictions on these modules so that I could check that everything is functioning.)

Run tests to see if I need to add perl modules

perl -Mmodule -e 'print "installed!\n"'

=GD installed, DBI not installed DBD not installed Data::UUID not installed Date::Format and Date::Parse not installed Send::Mailer not installed Soap::Lite not installed=

Installing modules: perl -MCPAN -e shell

I let CPAN autoconfigure itself

Then type> install moduleName

Installed Date::Format, no problems. Looks like Date::Parse was installed as well.

Installed Data::UUID

Installation of DBI failed in testing. The module Test::More was missing.

Installed Test::More (and Test::Harness also)

Installed DBI successfully.

Installed Bundle::DBD::mysql, since that seemed the most reasonable. Could not get DBD::mysql to compile.

  I'll give up on that for now, since I don't need it unless I'm using mysql.

Installed Mail::Sender. I did not specify any defaults.

Installed SOAP::Lite accepted all defaults. Testing failed because MIME::Parser was not installed.

Installed MIME::Parser successfully

Installed SOAP::Lite --tests failed again since LWP was not available.

Installed Bundle::LWP (should have done this at the beginning -- most systems have this.)

     This one takes a bit of time, I accepted defaults.  MD5 is among the dependent files loaded.
     If I'd loaded this module first the downloads would have been quicker since it contains methods
     for downloading files.

Installed SOAP::Lite -- worked this time!

Getting connected with CVS

Following instructions I ended up downloading the webwork-anoncvs-helper file and installing it in ~/.ssh/webwork-anoncvs-helper .

I had to set the permissions to allow execution (chmod 700 webwork-anoncvs-helper)

I added the following aliases to my .cshrc file

alias   wwlog   tail -f /ww/logs/error_log    # allows me to read the apache error log
                                                                   # you can determine the apache error log location
                                                                   # from the apache httpd.conf file (search for ErrorLog)
alias wwcvs alias wwcvs env CVS_AUTH_SOCK=  CVS_RSH=~/.ssh/webwork-anoncvs-helper cvs    

I then tried to download webwork-modperl from the CVS server and install it in /ww/webwork .

At first it tried to use the login name (not mine) attached to an existing CVS in /ww/webwork directory. I removed that.

Can the CVS download page be rewritten to make it clear that you need to do the last two steps on the page (permissions and such like). If one skips the tarball section, you risk skipping these last two sections as well. Don't do it.

I changed the nesting of the sections in DirectorySetup. It now goes like this:

• Getting the distribution
  • Using CVS
    • Latest CVS
    • Released version from CVS
    • Released version + patches from CVS
  • Unpacking from tarballs
• Indicate the currently-installed version of WeBWorK
• System permissions

How does this suit you? -- Main.SamHathaway - 04 Mar 2004

Finally the command cd /ww/webwork wwcvs -d :ext:anoncvs@cvs.webwork.rochester.edu:/cvs/webwork/system checkout webwork-modperl did the trick and the file /ww/webwork/webwork-modperl was created.

Is there any point in keeping track of versions when the webwork-modperl directory is linked to the CVS?

Keeping track of the active version allows you to keep multiple versions on the machine at once, but avoid having the change the paths in httpd.conf (and other places) when upgrading (or downgrading). Perhaps the instructions should make this an optional step, i.e. only if you want to keep multiple versions on the machine at the same time. -- Main.SamHathaway - 04 Mar 2004

Next change groups and permissions

In setting groups and permissions, it seems that we need specifics on the permission level for some of the directories. In particular the lib directory has 700 permissions which cannot be right. It seems that setting this to 750 is a better choice. So

chmod -R 750 lib

chgrp -R wwdata lib

wwdata contains wwhttpd, the webserver and members of wwadmin. wwadmin contains the human administrators.

Explicitly setting the groups of lib and bin and doc are needed on this page.

Configuring apache:

After adding the snippet for server-info you need to restart the server before issuing the url.

Checking the status of the server works ok.

Now to build the test_course. Turns out I didn't set the WEBWORK_ROOT environment command. Need a note to make sure people go through this step. It's in misc config which comes later.

So I set WEBWORK_ROOT, but I got an error, couldn't find /ww/webwork/webwork2/bin/lib/CourseEnvironment.pm aha! I need to set= WEBWORK_ROOT to =/ww/webwork/webwork2 no bin at the end!!! I knew that!.

Now we are missing Time::HiRes -- CPAN module that can be difficult to install. Wish me luck.

Well using the CPAN module to install Time::HiRes didn't work at all. I had to resort to a manual install (make, make test, make install)

We were also missing Apache::Request. I had to install that by hand as well.

I also made a copy of global.conf.dist to global.conf and database.conf.dist to database.conf =I believe this should have been done before I created the =test_course.

This time when I ran make course I get some output indicating that directories have been created in webwork2/courses. (I had to change this to /ww/webwork/courses to conform to my setting for the apache config file.)

Trying to get to test course:

http://webwork2.math.rochester.edu/webwork2_courses/test_course   doesn't work
http://webwork2.math.rochester.edu/webwork2_courses/test_course/  matches alias
but then I get a permission denied.

Going back to http://webwork2.math.rochester.edu/webwork2/ I get a ur.template not readable. Fixed that.

Still not working and I realize that I should be using the url

http://webwork2.math.rochester.edu/webwork2/test_course/ instead.

I'm having much trouble getting the permissions to work correctly.

A lot got set to drw-wS--- I'm resetting them to 755. I believe that the initial determinination of permissions should be something like chmod -R 755 *; THEN chmod -g+ws files....

The notes broke down about this point. I had to reset permissions in a number of places in the courses and in the webwork2/htdocs/tmp file for example, in order to get things to work.

If the course is an existing course you also need to make sure that the names of the databases coincide with what is expected. For example in an older course I had to put this snippet in the course.conf file

$dbLayouts{gdbm}->{permission}->{source}="$courseDirs{auth_DATA}/permissions"; $dbLayouts{gdbm}->{password}->{source}="$courseDirs{auth_DATA}/password"; $dbLayouts{gdbm}->{user}->{source}="$courseDirs{DATA}/classlist-database"; $dbLayouts{gdbm}->{set_user}->{source}="$courseDirs{DATA}/webwork-database"; $dbLayouts{gdbm}->{problem_user}->{source}="$courseDirs{DATA}/webwork-database";

Because the naming scheme for the databases had been to use webwork-database rather than courseName_webwork_DB

A similar snippet can be useful in a course which is to be archived by changing the name. You want the name of the database file and the references to it NOT to change.

Adding global Users is a pain for a large number of courses.

-- Main.MichaelGage - 04 Mar 2004