ISG Script and student.cs Environment Information for the Fall 2010 Term

This page is meant to give brief information to ISCs and instructors about programs and/or features of programs for course accounts that users of the accounts may not be aware of. Please contact TerryVaskor for more information about any of the following information.

General Information

Login script

It is recommended that course accounts that use the ISG tools and/or have many different users sharing the account

• have their default shells set to /xhbin/tcsh
• not have a /u/csXXX/.cshrc file, or at least a very minimal one; certainly not the default .cshrc
• have a /u/csXXX/.login file containing the following contents:

exec /u/isg/bin/login

The man page has more details about what this does. The most notable effects are setting values of PATH and MANPATH to include the isg utilities, and giving users their own default shell and configuration (at least on Solaris systems).

Personalized login and the move to SSH

SSH does not allow the passing of the REMOTEUSER variable to trigger the personalization behaviour of the login script. The SSH maintainers plan to push through a patch that will allow it; however, it will be a while before this ends up being released, and then more of a while before it is added to the Ubuntu distribution. Because of this, it may not be pushed to the Linux systems in the Fall term. The only known override is to push entries such as the following into /u/csXXX/.login before the call to exec, which only work for machines a single user uses:

if ( $REMOTEHOST == imac063.student.cs.uwaterloo.ca ) then
   setenv REMOTEUSER tavaskor
endif

However, this should work automatically on Solaris systems. If you have generated an ssh key on your account on the student.cs systems and are listed in the course account's /u/csXXX/.rhosts file, then your key should be copied over within the hour in a fashion that enables REMOTEUSER setting behaviour.

Documentation is available; more details will be forthcoming as the system is tested and documented more.

Round robin servers for interactive use and for testing

The Linux systems are being divided into two partially-overlapping sets of servers: one for interactive use, and one for testing (via Marmoset buildservers, RST, etc.). Both of these sets are available via front-end server names: linux.student.cs for interactive use, and linux-test.student.cs for autotest runs. Students should only be making use of linux.student.cs, and should always be specifying this round-robin name instead of specific server names so load distribution can be done.

Newsgroup post cancellation

There is now a cancel-news script which will allow cancellation of posts made to the course newsgroup. This can be used by course staff to remove problematic posts without having to go through CSCF/IST.

Local version of MOSS for plagiarism detection

There is now a version of MOSS running locally, so it is very strongly recommended that you make use of it instead of making use of the instance served from Stanford. If you make use of the ISG moss wrappers, you will use the new version automatically; see MossScript for more information regarding the use of these scripts. Otherwise, it can be accessed directly at /u/cs_build/bin/moss_for_linux.

Supplementary classlist files

Several utilities have had dependencies on additional term-specific information beyond what's available in .classlist._term_: .coursestaff._term_ to specify the roles of course staff and .exceptionlist._term_ to specify individuals not in the classlist who should be treated as enrolled students. Information about the formatting of these files is available at ClassListPerlModule.

Uses of this include setting root users in OnlineMarkUpload (so instructors can view any student's current marks) and controlling access for AssignmentSolutionPHPScript.

RST"> For Courses that use RST

Centralized public test system

The old test compile system via testcompRST has been phased out over the past few years in favour of public test runners, which run on each supported server and periodically check course accounts for testing requests to be serviced. Using these runners is strongly recommended; see RSTPublicTests for more details.

Specifying servers for the public tests and distrst

In an environment with multiple server types, only some of which may be supported for a course, both the public test runners and distrst (which spreads rst's work over all available servers) need to know which servers can be used to service requests. This is done by making use of the test_servers option in /u/csXXX/.rstrc.

In the near future, it's hoped that this can simply be something like

test_servers=( linux-test.student.cs )

which will be reasonably self-maintaining.

Unfortunately, all servers must be listed explicitly for the time being; because of this, the setting that should work for the fall will be:

test_servers=( linux008.student.cs linux012.student.cs linux016.student.cs mef-linux014.student.cs mef-linux018.student.cs mef-linux000.student.cs mef-linux004.student.cs mef-linux002.student.cs mef-linux010.student.cs )

although it appears that all of these servers may not yet be ready as of Tuesday, Sept. 7. A safe conservative subset for initial testing is

test_servers=( linux008.student.cs linux012.student.cs )

For Courses that use MarkUs

Submission filtering tests

Unfortunately, MarkUs does not support flexible filtering at the point of submission like the submit tool does. However, being able to filter before testing allows the tests to report more meaningful information to the students. To accomodate this, a new BitterSuite language has been added: BitterSuiteFilter. It will perform filtering actions on the files, and effectively remove any files that violate the conditions from BitterSuite's view.

For Courses that use Submit

Centralized file_filter

The use of the centralized SubmitFileFilter is strongly recommended. The main feature it adds is a log of every file submission test, including file size, md5sum, and exit code of the filter process. In addition, if you do not override the default behaviour, it can be used to impose maximum file sizes, reject binaries, and set limits on the number of files that may be submitted. See the file_filter man page for more details.

Centralized final_scripts

Fairly recent changes to submit allow scripts to be run immediately after all files have been copied to the course account, but before the submit process quits. Three centralized final_scripts are documented at FinalFilterScripts.

Two in particular are strongly recommended: SubmitSubversionHook to retain a subversion archive of all submissions that have been made for each student, and SubmitPermissionsHook to restrict permissions on the submission directory so course staff do not accidentally modify it. The other final script is SubmitPublicTestHook, which will automatically run a public test for the student after every submission.

See the man pages for more information.