There are two types of reservations, shared and exclusive. A shared reservation indicates that you are using the machine, and others can also do so without interfering with you. An exclusive reservation means that no one else should use the machine, and that the person with the exclusive reservation may reboot the machine at any time. You should get an exclusive reservation if you are doing the following types of work:
Shared reservations should be used if you want to pin down a machine for something use as a debugging console, or user level development on a lab machine.
You can change or delete a reservation by submitting a new request. You can only change requests that were made in your name.
The use of time period blocks are an artifact of the scheduler originally being written as a demonstration scheduler for DARTNET. The blocks roughly correspond to the blocks DARTNET was being scheduled in at the time.
The scheduler is a good tool for making sure that the machines are allocated fairly in times of high use. Use common sense and courtesy in its use. If you want to try a ten minute test and the machines are all idle, you probably do not need a reservation. If you want to guarantee that the machine isn't rebooted while you video conference from there, make the reservation. On the other hand if you made an exclusive reservation two minutes before you plan to use a machine, log on and find someone using the machine, let them know you have reserved the machine before rebooting it.
An exclusive reservation gives you the right to reboot the machine and to have anyone else who is logged onto the machine log out. (Rebooting the machine is a pretty good way to remove all users, actually.)
The scheduler is maintained by Ted Faber. Contact him if you have comments about it.
N.B.: restoring the FAST kernel is as simple as myri_configure FAST && reboot
Again, restoring the system state is tempered with common sense. If you have a long suite of experiments to run using a non-standard network configuration, its acceptable to note the change to the atomic-lab-users mailing list (described below) and leave things set up. Again, the important point is that people who may want to use the machines know how they are configured, and how to restore them to a default configuration.
When you're remote, there's a second important rule:
What do these rules really mean?
To Leave Your Machines Like You Found Them, you need to make sure that you can reboot your machines with the current default kernels. If you're remote, you should be sure that you're not going to hang the machine in some horrible way that prevents you from Leaving Them Like You Found Them. Remember, you can't physically go to the console and power cycle the thing if it hangs when you're remote. Therefore either
If these options fall through, you should be prepared to drive from where you are to ISI in order to power cycle/reboot the machine before your reservation expires. Simply extending your reservation to cover until the next time you plan to be in is considered antisocial.
To Be Secure in All Lab Access, you need to be aware that each su1 command requires you to type in the root password. Since there have been snooping attacks between campus and ISI before, this means you must insure that your network connection is encrypted. The best way to do this is to use the secure shell (ssh) to log in to your machines. Note that S/Key is not sufficient here, since it does not encrypt the connection after you've logged in.
Some documentation on ssh is available at http://www.isi.edu/action/secure-shell.html. ssh is supported on darkstar and zephyr, as well as on the FreeBSD lab machines. If you are using one of the suns that does not support ssh, use ssh to connect to darkstar or zephyr, then rlogin to the lab machine of your choice.
Finally, if your terminal is in a public or only moderately secure place, make sure you lock it (perhaps with xautolock or xlock) before leaving it unattended.
This section contributed by John Heidemann
Software for which a FreeBSD package (or port) exists and is adequate will be installed using that package (or port). Other shared software will be added in ~d7share/bin.FreeBSD. A list of the current packages (ports) installed on all machines is available by the command ~d7share/bin.FreeBSD/lab_check. Ted Faber checks these regularly to make sure that lab configurations are in synch. To get a package added please contact either Ted Faber or Anne Hutton. If they are unavailable, and you have superuser access to idn You can use the script ~d7share/bin.FreeBSD/lab_install to install new packages across machines. Please send mail to the above if you do so.
Please contact Ted Faber or Anne Hutton if you need one of the packages reconfigured (e.g., you want sudo privleges.
The lab is primarily funded by LSAM, so if contention gets high, LSAM projects have priority. We have never had to prioritize machine access in this manner because everyone has been reasonable and considerate. Hopefully that will continue to be the case.
The new source tree will be primarily composed of symbolic links to the
tree in
~atomic/4.1.3-sys.
The utility
newtree
found in
~faber/bin/newtree
will make such a tree. It takes two arguments, the first being the tree to
mirror and the second being the location to place the links. For example,
to make a new tree in a subdirectory called
source
in my home directory, the line:
When you want to make changes to a file, first delete the symbolic link and then copy the file from the main source tree (~atomic/4.1.3-sys). This ensure that your changes are only visible to you. Even in your copied files you should protect your changes by #ifdefs to prevent such changes from propagating in unwanted ways. See below for how to define the macros used to protect your code. This is a necessary precaution since potentially any code may someday be integrated into the main source tree.
In some cases you will want to modify sources that are not in ~atomic/4.1.3-sys. That tree is pruned somewhat to make kernel compilation quicker, and so is not complete. The full source is in /nfs/atom/4.1.3-sys and you can put additional symbolic links to that directory in place by hand if you need them. Again, only write to copies of the files, never to the files in the main tree.
To be sure that your source tree is correct, it is a good idea to configure and build the GENERIC kernel.
See the config(8) manual page for the format of the configuration file. Note the option keyword which you will use to define macros in the #ifdefs surrounding your changed code.
The default ISI reboot sequence checks for a file called /vmunix-new, and if it is detected, installs it as the new kernel (storing the current kernel in /vmunix.prev) and reboots. Using this fact, you can make a hard link from a copy of your kernel in the root directory to /vmunix-new, and reboot the system (using reboot(8)) to install your kernel. Be sure that the kernel is readable, writable and executable by the owner, readable and executable by group and others, (protection bits 0755) and is owned by the root user and the wheel group.
If your kernel is named /vmunix.something the /usr/atomic/myri_configure command can be used to link your kernel to /vmunix-new. Simply run /usr/atomic/myri_configure something as the superuser. Myri_configure is documented in /usr/atomic/man and if you add that to your MANPATH, you should be able to see the page.
The preferred method of rebooting the system is the reboot(8) command. Using the boot monitor does not sync disks. Do not use fastboot(8) either. The time savings from not running fsck(8) is minimal, and it can cause a lot of trouble. If the system is hung up, and using reboot(8) is impossible, press the Stop and letter A keys on the console simultaneously to get the boot monitor's ok prompt and run the boot command. The console does not respond to that, power cycle it.
The other trouble you can get into is beyond the scope of this document. Note that the commands from the boot prompt are documented on the boot(8) man page.