Welcome to the Computer Science Department's network FAQ (a synopsis of Frequently Asked Questions). It addresses questions regularly asked of the CS systems staff and provides a summary of useful information regarding the Department's computing facilities.
In addition to this FAQ, important announcements such as system or network down-time are sent to your CS email address. Check your mail account on a regular basis to stay up-to-date with current system operations.
This file is available from within the department as ~info/faq.
To access it from the web, visit http://www.cs.colostate.edu/~info/faq.html
A variety of books have been published on the basics of the Unix operating system. These can be obtained from your favorite bookstore. Additionally, some great tutorials can be found by searching google for something like "linux tutorial" or "tcsh tutorial".
The department also offers cs155, which is a good way to learn Unix in a classroom environment.
The Unix "man" command provides access to the typical on-line Unix reference manual set on all our systems. More complete reference manual sets for most of our supported operating systems and various other technical books and manuals are available for perusal in the systems offices (rooms 478, 472, and 474).
Supplementary documents for various software packages found in /usr/local are often embedded in the source trees for the given software package. For instance, /s/bach/i/src/emacs contains supplementary documents for emacs.
If you are having trouble understanding how to use the systems, there is a lab-op available to help in each of the first floor labs.
If your troubles are due to hardware or software failures in the systems or network, you should file a trouble report at http://www.cs.colostate.edu/cgi-bin/trouble.pl . The program will prompt you for all the information required by the systems folks to solve the problem. If things are so messed up that you cannot log in or get a browser up, report the problem to a lab-op or locate a system administrator as described below.
The systems people are located on the fourth floor of the Computer Science Building, on the south side, in rooms 478, 472, and 474. You can also reach them by e-mailing sna@cs.colostate.edu, or by telephone at 491-5305. Faculty may obtain the administrators' home phone numbers from the file ~info/emergency.
Generally, we try to keep all systems up all the time. There is no regularly scheduled down time. However, sometimes we need to take systems or even the entire network down for maintenance. We try to schedule this at non- disruptive times. Down times are announced via email to your CS address.
The lab in room 120 is available 24-hours a day and can be accessed by computer science majors with a valid student id card. Hours are posted posted at the front of the other labs. Remote facilities are available at all times outside of scheduled maintenance.
A complete list of CS machines is given in the file ~info/machines. All users may log onto any machine in the file ~info/machines that is listed as general use. Additionally, researchers, instructors, and graduate students may also run jobs on most of the machines designated as r/t (research/teaching) machines, except for a few machines which won't allow logins because they are dedicated exclusively to particular research projects. (Students are also advised to seek advance permission before logging into machines in Department faculty offices.)
The "rup" command returns the current load average for most CS machines. For further information consult the rup(1) man page.
Please, do not reboot the lab machines as other users may be logged in and working remotely. Other users may also be running background jobs or upgrades may be in process on the machine. If a lab machine is not responsive, please tell the labop or contact the system administrators.
User files and home directories are shared among all department Unix systems via NFS (the Network File System protocol) and NIS (the Network Information System protocol). Put more simply, no matter which Unix machine you log into, you will find your same home directory and same set of files. User files are all located in directories of the form, /s/SERVER/DISK/CATEGORY/NAME, where
s | is a literal "s," a parent common to all servers, |
SERVER | denotes the machine acting as file server for the directory, |
DISK | denotes a unique disk partition [a-z] on the server, |
CATEGORY | connotes the type of directory, such as "fac" for faculty, "grad" for graduate, "under" for undergraduate, or "proj" for research project, |
NAME | is the name of the directory (the same as login name in the case of home directories). |
Directories having a CATEGORY of "nobackup," or "tmp" are not backed up and are available on a "use at your own risk" basis. All other categories are backed up nightly to tape.
You can also map these directories from Windows PCs. (See section 11 below.)
Computers are named after musical composers (e.g., mozart), mountains (e.g. snow-dome) or vegetables (e.g. lettuce), and printers after instruments (e.g., banjo).
Internet addresses ending with "cs.colostate.edu" are all components of our subnet, for example mozart.cs.colostate.edu. The "cs.colostate.edu" suffix can usually be omitted on references local to our subnet.
A (partial) list of software packages is given in the file ~info/software. Most locally supported software is installed in the /usr/local directory on each system. One can also get an idea of what is available by browsing both this directory, and /usr/local/bin.
On Linux machines, a list of installed software packages can be obtained with the following command:
rpm -qa
To get more information about a package, simply execute:
rpm -qi PACKAGE-NAME
On Solaris machines, a list of installed software packages can be obtained with the following command
pkginfo -l
Systems source code is generally stored in trees rooted at /s/*/*/src. Source trees for many of the utilities found in /usr/local are located in /s/bach/i/src. In general, the source directories are named after their binary counterparts.
We try to keep up with changes in operating system, third party, and public domain software as they are released. Our policy is to support the latest releases in a timely manner. In general we support only the latest version, as we do not have the resources to support multiple older versions for compatibility's sake. However, in cases where a software upgrade is predicted to cause trauma to the user community, we will run the new version concurrent to the old version for a limited time. All other routine upgrades are announced after the fact.
On most machines, use the following command:
uname -a
The Unix and Windows platforms have distinct password domains. This means that you will need to change your passwords separately for Unix and Windows:
In Unix, you can change your password using the "passwd" command on any department linux machine. The command assists you in choosing a secure password, thereby enhancing security for everybody. (Also see 4.08)
In Windows, press control-alt-delete and click "Change Password."
Send mail to sna@cs.colostate.edu to request that your shell be changed. The change cannot be performed with chsh because of incompatibilities among various machines' implementation of the NIS protocol. The available shells are listed below:
Send mail to sna@cs.colostate.edu to request that your finger information be changed. The change cannot be performed with chfn because of incompatibilities among various machines' implementation of the NIS protocol.
The default startup files (which are provided in the home directories of newly created accounts) may be copied from ~info/dot.files. These files provide a basic template which works in our environment, and may serve as a starting point for your own individual modifications.
Generally speaking, your account will remain active as long as you are either enrolled as a Computer Science major or as another major taking CS classes. Other student accounts are removed twice annually, at the beginning of the Fall and Spring semesters. E-mail will be sent to accounts about to expire, several weeks before they are disabled.
No. Your account is for your use only. Accounts used by anyone other than the designated user may be suspended or revoked.
telnet and rlogin are insecure. We've replaced them with ssh(1) and slogin(1).
Create a public/private key pair using the following commands, and leave the pass-phrase empty when ssh-keygen prompts for it:
cd ~/.ssh ssh-keygen -t rsa cat id_rsa.pub >> authorized_keys
WARNING: If you change your password because you think your account has been compromised, you should also run these commands again. (The attacker may have stolen your ssh keys.)
For further information see the man page for ssh-keygen.
The following are popular free versions of the SSH protocol suite:
No! PC hard drives should be regarded as temporary work space only. PC disks are scrubbed periodically without warning.
Store your data in your Unix home directory, a thumb drive, or CD/DVD. For information regarding CD/DVD burning, please see our media burning FAQ.
The CS Department systems group performs daily backups on all user-data stored on the three Department file-servers: bach, chopin, and parsons. Backups are performed every day in the very early hours of the morning, This means that if your data is lost on a given day, we can probably restore it to its state at midnight the day before.
WE DO NOT BACK UP DESK-TOP SYSTEMS. With desk-top Unix systems this is not a concern, because the network is architected such that user files are automatically stored on the servers. However, Microsoft systems (PCs) put some burden of data-integrity on the user. When using a PC, it is important to take one of three steps to make sure your data is backed up:
The tape-cycle for daily backups covers approximately the most recent three months. Additionally, an end-of-semester archive is performed three times a year, at the end of each semester, for long-term file recovery.
Backups are normally run each morning beginning at 1:00am. If the file was not on the system at that time, we CANNOT recover the file. Recovered files will be in the state they were in at the time of last backup. To request recovery of a file, run the trouble program, which will prompt you for all the information necessary to recover the file.
Note, the backup/recovery service is only for recovery of files in an emergency situation. It is not to be relied on as an archival service. There is no guarantee that your files will be recoverable.
Use secure FTP, which is included with any SSH client. Either type
sftp machine.cs.colostate.edu
from your UNIX/Linux machine, or use the Secure File Transfer feature included with your Windows SSH client (both available free for academic use from http://www.ssh.com).
Traditional FTP has been disabled on all except one machine on the Computer Science subnet and is not accessible from off campus. If you have to use FTP, then connect to
ftp.cs.colostate.edu
Alternatively, you can do one of the following:
Unless a special allocation has been approved for you through a Computer Science professor, allocations are as follows:
undergraduates: | 2500 Mbytes |
graduates: | 5000 Mbytes |
Please also note that total quota allocations exceed the size(s) of the disk(s). This means that if everybody uses their entire allocation, the disk will fill up. So please try to stay well below your personal allocation.
You will receive daily warning messages if you exceed your allocation. Failure to remedy the situation after several days of repeated warnings will result in the suspension of your computer account.
Enter the following commands:
cd; du -sk .
This du command returns an integer value representing the total number of blocks you are currently using in your home directory. The -k option requests output in 1024 byte blocks instead of the default of 512 byte blocks.
This command lists the usage for each of your subdirectories in 1K-byte blocks:
du -sk * .??* | sort -rn | more
First, run this command in the top level of your home directory. Then cd down into problem areas and run the same command again, to hone in on the problem directories or files.
Note: The Gnome Trash Can, .mozilla and .eclipse are often the culprits.
Right-click on the trashcan symbol on the far left of your Desktop. Select 'Empty Trash.'
First, bring up firefox. Go into edit/preferences/advanced and reduce the disk cache size. 10 or 15 megabytes is probably sufficient.
Next, go into edit/preferences/privacy and reduce your browsing history. The default is 90 days but 14 or 30 days will save a fair bit of space.
Next, go to tools/"clear recent history" check all boxes and click "Clear Now".
Finally, you may want to clean up the various SQLite databases that firefox maintains. To do this, first exit all firefox windows. WARNING: if you do not exit all firefox windows the following may corrupt your firefox configuration. Next, run the following command from a Linux Machine.
find ~/.mozilla/firefox -type f -name '*.sqlite' -exec sqlite3 {} VACUUM \;
To clean up Chrome, click the wrench icon on the far right of the toolbar and choose "Preferences" from the drop-down menu. On the "Under the Hood" tab, click the "Clear browsing data..." button and choose the data you want cleared. Generally the cache takes up the most disk space.
Currently Chrome does not offer an easy way to limit the amount of cache it stores on disk. To remedy this, you will need to run Chrome from a terminal or custom Gnome shortcut and pass the following options:
google-chrome --media-cache-size=15728640 --disk-cache-size=15728640
Where 5242880 represents the size of Chrome's cache in bytes. 5242880 (5 MB) should be reasonable, but you can tweak to your liking.
Eclipse regularly rolls its configuration files over into a new directory named something like ~/.eclipse/org.eclipse.platform_*
It should be safe to remove all but the latest of these directories. To do this, run the following script:
/usr/local/bin/clean_eclipse
The thunderbird mail client stores messages and indices locally in your ~/.thunderbird directory in order to improve performance. The following steps will reduce the amount of information stored locally.
Thunderbird also does not actually free the disk space for messages that your may have deleted until your directories are "compacted" and indices are rebuilt.
gzip can be used to compress/uncompress a file that is used rarely.
gzip --best filename gunzip filename.gz
You may also want to check the man pages for the gzip and tar commands.
See the systems folks in room 478.
We support the vendors' primary window manager on each hardware platform. Hence, the following window managers are supported on their respective platforms:
A variety of other window managers are also available on most machines, on a "use at your own risk" basis.
Generally speaking, Computer Science Department machines are shared resources. It is Department policy that they not be locked for exclusive use for long periods of time. They may be locked for brief periods (of five minutes or so) if you are called away briefly from your work-station, for instance.
Generally speaking user-based authorization -- see xauth(1) -- is more secure and preferable to host-based -- see xhost(1). Because your home directory is shared by all machines on our subnet, most of the setup for user-based authorization occurs automatically. If you are running your X session via anything other than the xinit command, you (and only you) are automatically authorized to display to your X display from an X client on any machine. No setup is required. If you are running X via xinit, you must do the following:
1) Before running xinit, create .Xauthority records manually using the following commands:
xauth add ${HOST}/unix:0 . $KEY xauth add ${HOST}:0 . $KEY
where ${HOST} is the name of the host on which you are running and $KEY is a difficult to guess key composed of an even number of 32 or fewer hexadecimal digits.
2) run xinit using the following command:
xinit -- /usr/bin/X11/X -auth $HOME/.Xauthority
If you have an Xserver running at home you can simply configure an ssh session to tunnel the X11 protocol, and start the remote X clients from the ssh session.
ssh -XC machine.cs.colostate.edu
If you don't have an X server, another option is to use VNC. For information on how to run VNC, see http://www.cs.colostate.edu/~info/vnc.txt.
All printers are available via the system V command set (lp, lpstat, etc).
To print a file, type:
lp -d PRINTER-NAME FILE-NAME
If you are printing a large file and it is not world readable, you may have to type this:
lp -c -d PRINTER-NAME FILE-NAME
The -c option allows lp to make a copy of the file.
See ~info/printers.
No. Printer paper, toner, and maintenance represent a substantial expense to the CS Department. So far we have managed to keep this expense within bounds through voluntary conservation. There will continue to be no hard limits on printing as long as people continue not to abuse the privilege. Here are some suggestions to minimize wasted paper:
The soft limits for undergraduates are 35 pages per print job and 75 pages per week. These are limits of excess, not allocations. You should try to keep your printing well below these limits.
CS Department printers are for bona fide department-related work only.
Use the following command:
man -t MANPAGE-NAME | lpr -P PRINTER
On Suns using CDE, you can print man pages from the Man Page Viewer. You can find this in the Desktop_Apps folder.
To cancel you print job, you need to check the job's status in order to get the job number.
To check on the status of your print job, type 'lpstat PRINTER-NAME'. You will get output that looks something like this:
lpstat banjo banjo-195 root 367 Apr 06 08:27 on banjo
To cancel your job, type cancel JOB
.
To cancel the job above, one would type:
cancel banjo-195 request "banjo-195" cancelled
By default, double-sided (duplex) printers use both sides of the paper. Since single-sided printing doubles our paper costs, it should only be selected when absolutely necessary. Single-sided printing may be selected as described below.
On Unix, use the -o sides=one-sided
option with the lpr
command. For instance:
lpr -Pbanjo -o sides=one-sided myfile
On Windows, go into the "Properties/Advanced/Printing Defaults" menu and select "Flip on Short Edge" or "Flip on Long Edge."
Setting the default printer is done as follows:
lpoptions -d <printer_name>
The CS Department's wireless network is configured as part of the campus wireless network. So once your machine is configured to work on the department's wireless, it should work most anywhere on campus. For further information on setting up wireless access, consult the ACNS Wireless Web Page.
Note: wireless authentication is based on your CSU EID, not your CS login.
Traveling personnel and those who use outside ISPs (e.g., cable-modems, AOL, and Earthlink) for remote access can benefit from the VPN client. The VPN client will ensure a secure connection between your computer and CSU. It will also authenticate your connection to use certain on-campus services, such as SMTP. For further information, see the ACNS VPN Web Page.
Your e-mail address is LOGIN@cs.colostate.edu where LOGIN is your CS department login. On our local subnet your e-mail address may be abbreviated to simply your login.
Mail addressed to you anywhere on our subnet gets routed to the department mail server, mail.cs.colostate.edu. You should configure your mail reader of choice to use the IMAP protocol to access your mail.
For incoming mail, use mail.cs.colostate.edu.
The outgoing server you will use depends on your location:
Another option is to forward your CS mail account somewhere else; see the next section for details.
Yes. Visit https://webmail.colostate.edu for a simple web-based interface.
Please note that mail.cs.colostate.edu is the mail server for all machines on the Computer Science subnet (*.cs.colostate.edu). Do not attempt to direct your mail to a different CS department machine, as it may cause your mail to be lost.
If, on the other hand, you'd like your mail to go to a remote machine outside of the Computer Science subnet, you may do so by creating a .forward file at the top-level of your home directory. To create the .forward file, log into any CS Department Unix machine (such as corn.cs.colostate.edu) and enter a command similar to the following:
echo "JoeSixpack@gmail.com" > .forward
where "JoeSixpack@aol.com" is the new target address.
After setting up a .forward, test it to make sure it is working correctly. If in doubt about any of this, send your address change request to sna@cs.colostate.edu.
By default, Pine will use a subdirectory of your home directory to store
various mail folders. This directory is usually called ~/mail
.
Pine can access your inbox and this directory entirely over IMAP, allowing
you to read email from multiple locations transparently.
The following steps are needed to do this:
~/.pinerc
in your favorite editor;
user-domain=
to
user-domain=cs.colostate.edu
smtp-server=
to:
smtp-server=mail.cs.colostate.edu
otherwise
inbox-path=
to
inbox-path={mail.cs.colostate.edu}inbox
folder-collections=
to
folder-collections=Main {mail.cs.colostate.edu}mail/[]
This will tell pine to access all mail folders in the ~/mail
subdirectory of your home directory via the IMAP server, enabling you to
see them even when running pine from outside the Computer Science department.
Setting this option does not always show up in the pine configuration menu,
which is the reason why editing ~/.pinerc
directly is recommended.
Also, please refer to the sample Pine config file in ~info/dot.files/.pinerc
for further information.
You need a ~/.mailcap
file in your home directory. This file contains lines pairing up content types with helper applications that know how to view them.
Copy ~info/dot.files/.mailcap
to your home directory. Currently, this will enable you to view Acrobat PDF files with acroread, postscript files with gv, and Word files with OpenOffice, from both Pine and from Thunderbird.
First, you must create a public_html subdirectory in your home folder with permissions of 711:
cd mkdir public_html chmod 711 ./public_html
Now anything placed under this directory will be accessible from the web using the ~ operator. For example,
http://www.cs.colostate.edu/~USERNAME/file
Would map to ~/public_html/file
.
If you are running into "Access Forbidden" errors, you probably have a
permissions problem. In general, permissions should be:
Note that PHP scripts do not need to be world-readable and are run using the permissions of their owner. This prevents other CS users from being able to see your PHP code.
Our web server also looks for files named index.html, index.php, etc. to determine the default page to be displayed when accessing a directory from the web. If you have an index.html in your ~/public_html/ directory, it will be displayed when visiting http://www.cs.colostate.edu/~USERNAME
All cgi scripts in user home directories are run using the suEXEC wrapper. This causes cgi scripts to run with the owner's permissions. The scripts must also reside under the following path to be recognized as cgi scripts
~/public_html/cgi-bin
and are referenced as
http://www.cs.colostate.edu/~username/cgi-bin/scriptname
cgi scripts do NOT need to have permission bits set in the group or other fields.
For further information, see the suEXEC documentation.
All php scripts in user home directories are run using the suPHP wrapper. This causes php scripts to run with the owner's permissions.
php scripts do NOT need to have permission bits set in the group or other fields.
suPHP requires that all php sessions be given a name that is unique to your page. A quick and easy to ensure that that your session names do not conflict is to base the session name on the directory that the script resides in
session_name(substr(str_replace("/", "_", getcwd()), 1, 512));
For further information, see the suPHP documentation.
For information on how to set up password protection for your web-pages, log onto a department Unix machine and consult the text-file, ~info/htpasswd
To map your Unix directory from a department Windows machine (i.e., a machine in the cs-win domain), right click on "My Computer", then select "Map network drive". Enter a path of "\\unix\LOGIN", where LOGIN is your Unix login.
Mapping your Unix directory from home involves a little more configuration work. For further information read the unix text-file ~info/offsite-samba.
To log in, visit the MSDNAA page. Your login is your CS email address, and your password should have been emailed to you during your first semester as a CS student. If you don't know or didn't receive your password, visit the password reminder page.
Every Windows machine should run a virus scanner, such as Mcafee or Norton Anti-Virus, and the virus definitions should be kept up to date.
Under the CSU campus site license, Symantec antivirus is available free of charge to CSU students, faculty, and staff. You can download a copy at ACNS's Site-Licensed Software page.
Spyware and Adware are applications that are installed onto a computer, often surreptitiously or as part of another useful application. Spyware tracks and reports a user's activities. Adware causes random popup adds to appear on the users system. No only are these activates annoying to users but these applications are often poorly written and so cause a wide range of other problems with the user's system.
There are several applications that aid in the removal of both Spyware and Adware. The two applications we recommend to try first are Spybot and AdAware. These two applications cover a slightly different set of issues and so it is recommended that both be run.
Spybot: http://www.safer-networking.org/en/download/index.html
AdAware: http://www.lavasoftusa.com/software/adaware/
There is a third tool that for people who are experiencing trouble with IE and have some understanding of the inner workings of windows. That is a program called HijackThis: http://www.spychecker.com/program/hijackthis.html
Warning: If after having this tool scan your system you are unsure of what to remove, it is best not to proceed.
Using the Apple Finder "Go" list, select "Connect to Server" and enter the following as the Server Address:
smb://smb.cs.colostate.edu
You will need to authenticate using your CS-WIN windows domain password.
To set up a printer using Mac OS X 10.6, first make sure the computer is connected to our network via ethernet cable. Then, go to System Preferences -> Print & Fax and click on the plus icon under the left-side pane of the dialog window. In the Add Printer dialog make sure the Default button is selected at the top and wait for the list to populate, select the printer you want to use and hit Add. In the Installable Options dialog that appears, make sure Duplex Unit is checked to allow double-sided printing. Hitting Continue will finalize installation and the new printer should now appear in the system- wide Print dialogs.
To print on both sides using a CS printer set up as described above, check the Two-Sided check box in the File -> Print dialog.
Note: These instructions will not work in 1st floor labs.
Using Mac OS 10.3, panther, one can now easily use SSL with mail. That is the good news. The bad news, the process of getting and retaining a local certificate is somewhat involved and has at least one known major pitfall.
To start, in the advanced settings for the IMAP account, there is a check box for SSL. Check it. Then, the next time you start email, follow the instructions here:
http://docs.info.apple.com/article.html?artnum=25593
And now, the big gotcha. If Mail.app is pointing to the inbox of the IMAP account whose certificate you are attempting to copy, Mail will freeze (apparently permanently). The fix is simple. Make sure to have Mail.app default to another folder, for example the inbox of a different email account. If you do this and then restart Mail.app, all will proceed smoothly and as described in the little instruction set from Apple given above.
Please see this ACNS guide: Configure Mac Mail to USE SMTP Authentication.
There are multiple reasons this can happen, but the two most common are:
Make sure the program isn't already running on your machine. Then check to see if you are logged in to any other workstations:
rusers -l | grep USERNAME
If you are logged in somewhere else, the best option would be to log back into the machine and close your application. To do this remotely:
ssh MACHINE pkill -f APPNAME
If your application still won't start at this point, you will need to remove its lock file. Where the lockfiles are stored depends on the application:
rm ~/.mozilla/firefox/*.default/{lock,.parentlock}
rm ~/workspace/.metadata/.lock
rm ~/.opera/lock
For other applications, you can use the find(1)
command to help
determine where the lockfiles are stored. Since lockfiles generally do not
contain data, using the -empty
flag can narrow the search.
find ~ -iname '*lock*' -empty find ~ -iname '*lock*' -type l ! -exec test -r {} \; -print
After physically plugging in the device, it should automatically be mounted. Run the command:
df -k
It will list the mount point in the last column. You can browse the USB by going into /media/USB\ MEMORY.
Please don't forget to unmount when you're done: Right click on the USB icon on your desktop and select 'Unmount Volume.' Removing the device without unmounting might corrupt your data files, and it will render the usb port un-usable for the next user.
Note: Be sure you are no longer in the /media/USR\ MEMORY
directory
or you will get a "Cannot unmount volume" error when attempting to unmount.
Note: You may need to re-format the device on a linux machine with a FAT16 partition. Devices formatted on a windows system may not mount correctly on Linux. But devices formatted on a Linux system will work on either. For further information see the unix text file, ~info/usb-stick-format
Note: If you are using a window manager other than Gnome or KDE, try starting Thunar. This file browser should automatically mount any attached USB thumb drives.
Yes, try /usr/local/xine/bin/xine or /usr/local/mplayer/bin/mplayer Don't forget to use headphones!
CUDA is available on the CS department Linux machines with newer nVidia GPU's. For more information about using CUDA, see the CUDA FAQ.
The CS Department network is designed such that much of the computing resources are on powerful workstations found in the labs and on desktops, and access to these machines is generally open to all users. This open distributed configuration gives desktop users access to state-of-the-art hardware while simultaneously providing a powerful compute cluster for background jobs. Generally speaking, users may run resource intensive jobs on any machine which they can log onto (see section 3.10), provided the jobs don't interfere with other users.
The privilege to run background jobs comes with a specific set of rules that must be followed and responsibilities which must be upheld. All long-running and/or background jobs should be run in a way that minimizes the impact on other users, and interactive users in particular. Scheduling priorities should be niced, memory constraints should be respected, and network and disk I/O loads should be kept within reason. If your jobs in any way annoy an interactive user, then you are doing something wrong.
If other users notify that your jobs are causing problems, it is your responsibility to resolve the situation quickly. Resolution involves terminating some or all of the jobs within a reasonable time-frame, and determining how to eliminate any interference before attempting to restart the jobs. Disputes over who's jobs are at fault, or lack of response from the owner of interfering jobs may be referred to the CS systems administration staff for resolution. Jobs that are interfering may be terminated by systems administration without notice. Repeat offenders may be banned from using certain machines.
See the following sections for hints on analyzing or minimizing the impact of your jobs.
It is mandatory social etiquette that all long-running and background jobs be run with a nice value of 19. To do this:
nice -n 19 COMMAND
Or, on an already-running job (where PID is the process ID):
renice +19 PID
An exception to this rule is made for the two computation servers, bacon and eggs. Since those machines are dedicated exclusively to the task of running resource intensive jobs, it would be pointless to nice any jobs running on them. Jobs may be run at the default priority on bacon and eggs.
For further information, consult the renice(1) and nice(1) man pages.
Note: If your job is multi-threaded, don't forget to renice the individual threads.
Typically, jobs should not use more physical memory than is available on the machine. Once a machine begins to swap or page because of a shortage of memory, problems will result. In calculating the fit of your job to available memory, accommodation should also be made for memory to be used by other users. The amount of physical RAM available on each machine is listed in the file ~info/machines.
A resource limit on virtual memory size can be set with the ulimit command in bash or with limit in tcsh. For example, in bash:
ulimit -v 2000000
or in tcsh:
limit vmemoryuse 2000000
will prevent a job from using more than about 2G of memory. This limit is set for the current login session only and the process will segfault if the limit is exceeded.
The CS department Unix clients share several NFS file servers. If a resource intensive job is performing many reads or writes to the NFS file servers, then performance will slow down for everyone.
If your job is performing many reads and writes or uses a large dataset, then you should consider keeping a copy on the local disk until the job has completed and then copy the data back to NFS. See section 15.06 for more information on using local, temporary disk space.
All Unix machines in the CS department have a local partition for temporary data storage located at:
/s/`hostname`/a/tmp
This space is not backed up and is provided on a "use at your own risk" basis. A copy of all important data should be kept in your Unix home directory.
Please remember to remove your temporary data after you are through so that others can use the space.
This space is regularly, automatically scrubbed and may be removed by systems staff at any time. Again, only temporary data should be stored in this location.
If your job is performing many reads and/or writes to the local disks, the I/O priority should be set to 7 with the ionice command. To do this:
ionice -n 7 COMMAND
Or, on an already-running job (where PID is the process ID):
ionice -n 7 -p PID
For further information, consult the ionice(1) man pages.
Instructions to install the ADT plugin in Eclipse:
Once Eclipse is relaunched, you will find the Android SDK manager in the Eclipse toolbar as well as listed under Window.
After you have successfully installed the ADT plugin, follow the next steps to point to the Android SDK directory:
Now you are all set to create an Android Project or an Android Virtual Device with the Device Manager, etc.
This is usually caused by a corruption in your local Eclipse space. The remedy is to back up your local eclipse settings and relaunch eclipse.
Once the problem goes away don't forget to remove your .eclipse_backup. Note: You will lose any custom plugins/settings you have currently installed.
The department supports openmpi. It is installed under
/usr/lib64/openmpi/bin/
.
You'll need to modify your various PATH environment variables accordingly.
In the bash shell, this can be done as follows:
export PATH=/usr/lib64/openmpi/bin/:${PATH} export LD_LIBRARY_PATH=/usr/lib64/openmpi/lib/:${LD_LIBRARY_PATH} export LD_LIBRARY_PATH=/usr/lib64/openmpi/lib/:${LD_LIBRARY_PATH}