ISG Script Updates for the Fall 2010 Term

General Information

Login script

It is recommended that course accounts

• 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 under rsh 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.

TODO: Explanation of availability on Solaris, how it works, how to override

Front end 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.

TODO: Make mention of possibility of specifying just linux-test.student.cs hopefully, and also have that as RST's default so courses don't have to do any work?

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.