Courselab
Waldemar Fischer
In order to get access to courselab you must first get access to the OIT Nobel System. This page will guide through getting access to Nobel. You will need to set your Unix shell which you can do by reading "see Unix: How do I enable/change the default Unix shell on my account?". Here is the direct link to update your Unix shell. After your shell has been set you will need to ssh to Nobel by using the following SSH command:
If you are unable to ssh to Nobel you will need to reach out to OIT at help...@princeton.edu or via Service Portal. If you attempt to login and get an error message that mentions "nologin" it's because you haven't enabled Unix access and set a shell with OIT.
The list of COS courses that have requested use of these machines can be updated by a course instructor using the ADM site. We get periodic updates of the enrollment rosters from the Registrar for these COS courses, and these students are authorized to use these machines. Notes:
Accounts on the courselab machines are removed at the end of the semester. If you would like to keep your files please make sure you copy your files off the lab machines before the end of the semester.
The Unix shell on these machines is the same one that is used when a user logs in to an OIT Unix machine (e.g., hats). As a consequence, if you have not enabled your OIT account to be able to access the Unix machines (and set a shell), you will also not be able to login to the courselab machines. To enable Unix access and specify a particular shell (/bin/bash is a good choice if you don't otherwise have a preference), see this OIT KnowledgeBase article: Unix: How do I enable/change the default Unix shell on my account?
Important: Once you "Enable your Unix Account" with OIT, it may take up to 24 hours before your account is ready for use. If you have several unsuccessful login attempts in quick succession, your IP address may get banned for an hour or more as such failed attempts may be interpreted as a brute-force attack by our intrusion-prevention mechanisms.
In order to have access to the REST interface of the Tango server, clients will first have to obtain a key from the Tango server. This key is a unique identifier of the client and it must be supplied with every HTTP request to the Tango server. If the Tango server fails to recognize the key, it does not entertain the request and returns an error message as part of the response body.
A request to open consists of the client's key and an identifier for every lab, which is likely to be a combination of the course name and the lab name (i.e. courselab for autograding jobs). open checks if a directory for courselab exists. If a directory for courselab exists, a dict of MD5 hashes corresponding to every file in that directory is returned. If the directory does not exist, it is created and a folder for output files is also created within the courselab directory. Since no files exist in the newly created directory, an empty dict of MD5 hashes is returned.
After receiving a list of MD5 hashes of files that exist on the Tango server, the client can choose to upload files that are different from the ones on the Tango server via successive upload commands. For each upload, the client must supply a filename header that gives the name of the file (on the local machine) to be uploaded to Tango. One of these files must be a Makefile, which needs to contain a rule called autograde (command to drive the autograding process).
After uploading the appropriate files, the client uses this command to run the job for the files specified as files in the courselab and on an instance of a particular VM image. Each file has localFile and destFile attributes which specify what the file is called on the Tango server and what it should be called when copied over to a VM (for autograding) respectively. Exactly one of the specified files should have the destFile attribute set to Makefile, and the Makefile must contain a rule called autograde. Clients can also specify an optional timeout value (timeout) and maximum output file size (max_kb). This command is non-blocking and returns immediately with a status message. Additionally, the command accepts an optional parameter, callback_url. If the callback_url is specified, then the Tango server sends a POST request to the callback_url with the output file once the job is terminated. If the callback_url is not specified, the client can then send a poll request for the output_file to check the status of that job and retrieve the output file from the Tango server if autograding is complete.
Return a list of jobs. If deadjobs is set to 1, then return a list of recently completed jobs. Otherwise, return the list of currently running jobs. Note: This isn't strictly an admin request, since clients might find it useful to display jobs status, as we do in the Autolab front end.
Returns a JSON object that provides info about the current state of a pool of instances spawned from some image. The response gives the total number of instances in the pool, and the number of free instances not currently allocated to any job.
Tango will maintain a directory for each of the labs in a course, which is created by open. All output files are stored within a specified output folder in this directory. Besides the runtime job queue, no other state is necessary.
e59dfda104