This page has instructions for various tasks you might wish to do to customize your environment or perform a few other common tasks under the Linux operating system running on the Shared Computing Cluster (SCC).
- Setting default project
- Changing your shell
- Setting up basic dotfiles
- Setting up a .forward file
- Sourcing files
- Adding items to your path
- Setting environment variables
- Loading modules
- Creating and using a .rhosts file
- Listing and killing stray processes
- Additional help/documentation
Each account on the system has an assigned default Project. Any computing resources you use will be applied to it. You can see the list of projects that you belong to by typing “groups” on the command line. The first one listed is your default project. Note that Projects are implemented as Linux groups.
Four ways to control your default project:
- When you submit a job you can override the default by using the
- For frequent use, you can include it in your .sge_request file in your home directory.
- You can change the project for the current session by typing
newgrp projectnameon the command line.
- You can permanently change your default project on your individual Research Computing User Information page. Your default project will be changed the next time the system configuration files are updated, generally overnight.
New accounts on the SCC are currently set to use the bash shell . You can switch to the tcsh or zsh shell on your individual Change Shell Form. You can run the command
printenv SHELL to see which shell you are using.
Dotfiles are files, generally in your home directory, with names starting with the dot/period (.) character. These files control such things as your Path, which is where the system looks to find programs to run when you type a command.
These files (such as .bashrc, .cshrc, or .login) are set to reasonable defaults for new accounts and you should be very careful in modifying them as it can lead you to be unable to log in to the system or cause other major difficulties using your account. If by any chance you delete or corrupt one of your dotfiles, you can run the command
/usr/local/bin/dotfiles to back up your existing dotfiles and install new dotfiles which should provide you with a good, basic working environment.
Here are some of the dotfiles that are likely in your home directory.
- bash users ->
.bashrc– This file is usually the one which is modified, for bash shell users, to change your path or set environment variables.
- tcsh users ->
.cshrc– This file is used just like its bash equivalent .bashrc for tcsh users. This file could also be named .tcshrc.
- zsh users ->
.zshrc– This file is used just like its bash equivalent .bashrc for zsh users.
- all users ->
.forward– This file is used to forward your email and is explained in Setting up a .forward file section.
- all users ->
.login– This file is executed upon login and is an alternative place to your .bashrc or .cshrc file for actions/changes you want taken every time you log in.
We regularly send email to
email@example.com so it is important that you read this mail either directly on the SCC or have it forwarded to where you do read email.
If you have a file in your home directory named
.forward, all email sent to that machine will automatically be forwarded to the email address in that file, such as
firstname.lastname@example.org as is set up by default for new internal BU accounts. External users will likely wish to set up an appropriate
.forward file by for example doing:
scc1% echo "email@example.com" > .forward
Sourcing a file basically means to run it as a script. It is done most often with dotfiles and files which set up basic environment variables and other things needed to run a given application.
In order to
source a file, such as your
.bashrc, you simply need to run the command:
scc1% source .bashrc
If you find yourself sourcing a given file almost every time you log in, you may want to add the appropriate
source command to one of your dotfiles, such as your
.cshrc. If you do this, the file will automatically be sourced every time you log in. However, if you wish to immediately take advantage of this change without logging out, you will have to either directly
source the original file or
.cshrc file you just changed.
Your path defines in which directories, when you type a command, the machine will look to find the command you typed. If the system returns a message saying “
command: Command not found“, that indicates that either the command doesn’t exist at all on the system or it is simply not in your path. For example, to run
exampleapp, you might need to directly specify the
exampleapp path (
/usr/sbin/exampleapp perhaps) or you need to have the directory
/usr/sbin in your path. If you didn’t have that directory in your path, you could add it to the end of your existing path by issuing the appropriate one of these commands based on your shell:
bash and zsh users -> scc1% export PATH=$PATH:/usr/sbin tcsh users -> scc1% set path=($path /usr/sbin)
Also, note that the order in which items appear in your path is important as, if two items have the same name, the one which is in the directory appearing earliest in your path will be executed. For example, maybe you have written a program and compiled it and named it test. Well, it turns out that a program named
test already exists on most systems in
/usr/bin/test. As such, if the directory
/usr/bin appears before your current directory (represented in your path by a
. symbol) in your path and you just type
test, you will run the version in
/usr/bin/test and not the program you wrote of the same name. To avoid this, you can either put the
. at the start of your path (not recommended) or you can specify the full pathname for your version of
test by running
/usr1/scv/aarondf/test or you can simply not reuse any command names already on the system (recommended). You can find out the full path to a given command you are running by using the command
which. In the example given above,
which test would likely return either
/usr1/scv/aarondf/test, depending on how your path was set up. You can add items to the front of your path by modifying the commands above so that the
$PATH (for bash and zsh users) or
$path (for tcsh users) appears after the directory you are adding or you can totally replace your path by leaving out the
/$path entirely (not recommended).
As with sourcing files above, you can add path changing commands to your dotfiles, such as your
.cshrc, so that you do not have to change your path manually every time you log in. In fact, this is generally a very good idea to do. A good practice is to put the most important directories towards the front of your path (examples:
/usr/local/bin) and your current directory (
. ) and application-specific directories towards the end of your path.
Unix uses environment variables to keep track of defaults for all sorts of purposes. For example, the variable
HOSTNAME is usually set to indicate the name of the system you are on, such as
scc1. All environment variables have names in ALL CAPS and you can get a list of all the environment variables you currently have set by issuing the command
printenv. You can set an environment variable by doing the following, based on your shell. This example command is changing the default editor.
bash and zsh users -> scc1% export EDITOR='/usr/local/bin/emacs' tcsh users -> scc1% setenv EDITOR /usr/local/bin/emacs
As with sourcing files above, if you find yourself setting a given environment variable almost every time you log in, you may want to add the appropriate
setenv command to one of your dotfiles, such as your
.cshrc. If you do this, the file will automatically be sourced every time you log in. However, if you wish to immediately take advantage of this change without logging out, you will have to
.cshrc file you just changed.
Modules are a relatively easy way to load a specialized software packager or particular version of a package that is available on the system but not set up for you by default. You can set a Module up to load automatically on login by adding it to your
.cshrc file (as appropriate for your shell) as explained here. Be warned, however, that if you do this you might end up somewhat confused later if you forget what you did and load a different module for the same package, which can cause issues.
.rhosts file on a given machine is used to allow trusted access to given host/user combinations without the need for a password. This has security advantages and disadvantages. The disadvantages are obvious: if a user gets access to your account on one machine, he may automatically have access to accounts on various other machines. On the other hand, using
.rhosts files reduces the number of times you need to type your password and this is a security advantage.
For security reasons, we do not allow the use of
.rhosts files into our systems from non-SCC systems. However, you can use an
.rhosts file to switch among the machines in the SCC without needing a password.
Creating a .rhosts file and using it to log in between SCC nodes
.rhosts file is a simple text file which you can create in any editor with a series of lines of the form “
remote_hostname username” specifying that a given username on a given remote system is trusted to automatically access the machine. This file must be named
.rhosts and must reside in your home directory. For example, assume the following was my (username:
.rhosts file on
Given this, I could run
ssh scc2 from
scc1.bu.edu to log in to
scc2 without needing to enter my password. Since one’s home directory is shared between all of the SCC nodes, I could in fact log into any SCC node from
scc1.bu.edu without needing my password.
Copying files between SCC nodes using a .rhosts file
Use the command
scp (secure copy) to copy files/directories from one system to another without needing a password. For example, given the
.rhosts file example above I could do the following:
Copy a file from my home directory on
scc1 to my home directory on
scc1% scp /scratch/testfile scc2:/scratch/.
man page on scp for more information and help. On the SCC, this is usually only needed for files in
/scratch since most other directories are shared among all of the SCC nodes.
Users often accidentally can leave background processes running and consuming resources. These stray processes should be eliminated. To get a list of all the processes you have running on a given machine, use the
scc1% ps -ef | grep your_login_name | more
and this will return a list of the form:
aarondf 7064 7062 0 11:49 ? 00:00:00 sshd: aarondf@pts/20 aarondf 7065 7064 0 11:49 pts/20 00:00:00 -tcsh aarondf 7110 7065 0 11:49 pts/20 00:00:00 ps -ef aarondf 7111 7065 0 11:49 pts/20 00:00:00 grep aarondf aarondf 7112 7065 0 11:49 pts/20 00:00:00 more
kill a given process by doing the command
kill -9 PID:
scc1% kill -9 84190
The “-9” is not always necessary but makes sure that you kill the process. You can, of course, only kill your own processes. If there are a large number of runaway processes of other people on the system, you can send mail to firstname.lastname@example.org and ask us to kill them.
If you have problems or questions on any of this, please send email to email@example.com.