View source for Installation of 2.0pr3 on webwork2.math.rochester.edu

{{Historical}}

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

<code>perl -Mmodule -e 'print "installed!\n"'</code>

=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:
<code>perl -MCPAN -e shell</code>

I let CPAN autoconfigure itself

Then type> <code>install  moduleName</code>


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 <code>~/.ssh/webwork-anoncvs-helper</code> .

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

I added the following aliases to my .cshrc file
<pre>
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    
</pre>

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

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
<nowiki>
cd /ww/webwork
wwcvs -d :ext:anoncvs@cvs.webwork.rochester.edu:/cvs/webwork/system checkout webwork-modperl
</nowiki>
did the trick and the file 
<code>/ww/webwork/webwork-modperl</code> 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 <code>WEBWORK_ROOT</code> environment command.  Need
a note to make sure people go through this step. It's in misc config which comes later.
   
So I set <code>WEBWORK_ROOT</code>, but I got an error, couldn't find <code>/ww/webwork/webwork2/bin/lib/CourseEnvironment.pm</code>
aha! I need to set= WEBWORK_ROOT <code>to =/ww/webwork/webwork2</code>     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
<code>=I believe this should have been done before I created the =test_course</code>.

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:
<pre>
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.
</pre>
Going back to <code>http://webwork2.math.rochester.edu/webwork2/</code>  I get a ur.template not readable.
Fixed that.

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

<code>http://webwork2.math.rochester.edu/webwork2/test_course/</code> instead.

'''<code>I'm having much trouble getting the permissions to work correctly.</code>'''

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

<nowiki>

$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";

</nowiki>

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

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

[[Category:Installation Experiences]]