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.
It is recommended that course accounts that use the ISG tools and/or have many different users sharing the account
/xhbin/tcsh
/u/csXXX/.cshrc
file, or at least a very minimal one; certainly not the default .cshrc
/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).
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.
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.
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.
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
.
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.
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.
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 )
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.
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.
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.