Getting Started

Managing your password

CAC has a Password Policy in effect. The first time that you login to the cac.cornell.edu domain, you will be required to change your password. Each password must have at least eight characters and must contain at least three of the following four elements: (1) uppercase letters (2) lowercase letters (3) special characters (4) digits. Your password can be set or changed on any of the CAC login nodes, and the password will be updated on all CAC resources. Passwords expire every six months. Do not share your password. There are more detailed instructions below.

Rules for creating passwords

Rules for creating passwords

Change a password at first login

Changing password at first login

Change password at any time

Changing password any time

Locked Accounts

There have been instances in which user accounts have been locked. Some common causes of locked accounts and the solutions are:

• Mistyping your password several times in a row.

Solution: Wait about a 1/2 hour and then try again. Be sure that your caps lock key is not on!

• Trying to login to a Windows login node by using SSH when you have a new or expired password.

Solution: Login to a Windows login node using Remote Desktop Connection or SSH to a linux login node.

• Failing to log off all other sessions connected to login nodes.

Solution: Log off all remote connections. Disconnecting the sessions is not enough.

• Failing to disconnect locally mapped drives to the CAC file server before changing your password.

Solution: Disconnect all locally mapped drives, wait a 1/2 hour until account is unlocked, and then re-map the drive with the new password.

If you can't log on or can't wait you can submit a Password Reset ticket on our issue tracking system

Checking your CAC project

Cornell University users can view their account limits at CAC Account Limits.
Partner Program members should contact Paul Redfern at red@cac.cornell.edu if they need information on their membership limits.

Using CAC resources

Connecting to CAC

There are two types of login nodes:

• Linux login nodes: linuxlogin.cac.cornell.edu as well as the head nodes for the various Linux-based private clusters.
• Windows login node: winlogin.cac.cornell.edu

Connect to Linux

These instructions are written primarily for users trying to log in to a CAC login node, taking linuxlogin as an example; however, the same methods should work for nearly any remote Linux machine. Note: If you are trying to connect to a Red Cloud Linux instance, please see the specific connection instructions in the documentation first. There are also troubleshooting steps to help you if you get stuck.

There are three distinct ways to connect to a remote Linux machine:

1. Use SSH to open a Linux shell on a login node, which provides a text-only interface.
2. Use SSH together with X-Windows, which sends any interactive graphics back to your machine window-by-window through an SSH tunnel.
3. Use VNC to get a remote desktop with multiple text and graphics windows. This is not as straightforward as it sounds, due to the need to set up a secure tunnel for the remote desktop first.

These instructions are intended mainly for users of personal computers and workstations. However, much of the material carries over to mobile computing platforms such as tablets and smartphones. You will have to locate and download an app to enable SSH or VNC connectivity; even a browser plug-in may suffice.

Whichever method you choose, at your first login, you will be challenged for a new password (this does not apply to Red Cloud resources). Find help at Change a Password at First Login.

Using Secure Shell

For basic command-line access, a Secure Shell (SSH) client will give you a remote command shell on one of the login nodes.

• Nearly all Unix/Linux varieties (including Mac) already have a built-in SSH2 implementation, required by our clusters.
• If you are coming from a Microsoft Windows machine, an SSH2 client must first be installed, as described below.
• The non-secure predecessor of SSH, telnet, is disabled for security reasons.

Linux users:

To connect to the CAC general login node with ssh, you simply open a terminal window and type

localhost$ ssh <your_CAC_username>@linuxlogin.cac.cornell.edu

Mac users:

macOS is built on a version of Unix, so ssh is available directly from the Terminal application.

• One option is to use the shortcut cmd-space to open Spotlight and then type "Terminal" to open a Terminal window.

Otherwise:

• Navigate in the Finder to the Applications folder and Utilities sub-folder.

  

• Then double-click on the Terminal application to see a Bash command-line.

  

• As in Linux, simply type "ssh <your_CAC_username>@linuxlogin.cac.cornell.edu" into this window.

Windows users:

Secure Shell (ssh) clients work nicely as long as they support the SSH2 protocol. As mentioned, telnet is disabled for security reasons. A popular client for Windows is the free PuTTY client.

• The simplest installation is to download the Windows installer (having the file extension .msi) and run it. This installs PuTTY into your Start menu.
• To connect, start PuTTY, then type in a host name such as linuxlogin.cac.cornell.edu, and click "Open".

  

• Tip for advanced users: a slight inconvenience of PuTTY is that in order to use passwordless SSH, your private key must first be converted into PuTTY's special "PPK" format using PuTTYgen.

When choosing an SSH client, one consideration is how well other SSH-related tools are integrated, such as SCP (secure copy) and SFTP (secure file transfer protocol). With PuTTY, you can use the separate PSFTP client or PSCP command to transfer files back and forth. But PuTTY is just one choice; other clients for Windows exist.

• MobaXterm has a free Home Edition. It gives you not just SSH, but integrated SFTP/SCP, X-Windows, VNC desktop, and quite a few other useful connectivity tools, all within one convenient client.
• Token2Shell is a non-free commercial product available from the Microsoft Store. It provides SSH along with SFTP/SCP; however, it does not have X-Windows or VNC.

A completely different approach is to create a self-contained Linux environment within Windows and use the usual Linux commands.

• Windows Subsystem for Linux (WSL), free from Microsoft, allows you to run Ubuntu or another popular Linux distro within Windows 10 or Windows Server 2019. This allows you to use command-line SSH, SFTP, and SCP plus many other useful Linux tools. WSL does not come with an X server, but if you install one for Windows (see below), you can even install and run a VNC client for Linux in WSL.
• Cygwin/X is free and open-source. It includes an xterm within which you can run OpenSSH commands such as SSH, SFTP, and SCP. Unlike WSL, it includes an X server. While it does not provide a VNC client, plenty of native-Windows VNC clients are available (see below).

Using X-Windows

X-Windows (also called X11) is the longstanding Unix mechanism for displaying interactive graphics in a window. Your "X server" software runs locally, but it is capable of displaying windows that have been generated either locally or remotely. An "X client" on a remote machine can create X-Windows for local display, but it is necessary first to establish a shell on that machine using SSH.

Appropriate use:

Among other things, X-Windows gives you the ability to display a GUI that originates on a login node. However, this ability does NOT imply that you are permitted to run compute-intensive, GUI-driven applications on these machines. On linuxlogin, such usage is contrary to CAC policy. On other shared resources, it is disrespectful toward other users because the login node may become unresponsive through your actions.

Linux users:

The standard way to use X-Windows is to tunnel the X-Windows protocol through an ssh connection. If you open your ssh session with the -X option, it will automatically set up the necessary tunnel and environment variables.

localhost$ ssh -X <your_CAC_username>@linuxlogin.cac.cornell.edu
linuxlogin$ echo $DISPLAY
localhost:11.0
linuxlogin$ gs  # on another system, you want to might try a different X-capable client, like xterm

If all goes well, you should see a valid setting for your DISPLAY environment variable, then have a blank window presented to you by gs (Ghostscript, the PostScript and PDF previewer). If not, check the target system to make sure xorg-x11-xauth has been installed. Note, if gs is not installed on the machine you're logging into, you can try another X client such as xterm, xclock, xlogo, emacs, etc.

The -Y option is much like -X, but it uses a trusted version of X-windows forwarding.

cluster-login-node$ ssh -Y compute-1-37

When you're working on a cluster, the trusted (-Y) version is necessary for forwarding X11 connections in two steps: from a compute node to the login node, then back to your client machine.

Mac users:

In order to use X-Windows on a Mac, an X11 server needs to be installed on the system. The recommended X11 server for use on a Mac is provided by the XQuartz project. XQuartz used to be included with Mac OS X installations (versions 10.5 through 10.7), but is no longer included and must be downloaded and installed manually. After installing XQuartz, be sure to restart your Mac before using X11.

Once XQuartz is installed you should start ssh with the -X or -Y option, which will cause the X11 server to start automatically on your Mac. You can then try the "gs" test in the shell, as described above for Linux.

Windows users:

A few of the SSH clients mentioned above come with a bundled X server. Otherwise, along with your SSH client (e.g., PuTTY), you will generally need to install an X-Windows server on your Windows machine.

• VcXsrv - Open Source, and still being actively maintained. Works with Windows 10. Note that freeware solutions like this one can often work very well, but as always, the installation and use of such packages comes with no guarantees.
• Xming - Open Source/Proprietary. Even though the public domain release of Xming is quite old, it still works fine with Windows 10. For a donation, you can download a more up-to-date "website release" with improved performance for graphics (GLX) and other enhancements. As described at the author's website, there are two pieces to download:

  

  • Xming or Xming-mesa (public domain release). There are two links together, one for Xming, one for Xming-mesa. Either will work, but Xming-mesa has some newer features that might come in handy some time.
  • Xming-fonts (public domain release)

If you purchase the website release of Xming, remember to install the Xming-fonts, as well.

Here are some other X-server possibilities for Windows:

• Cygwin/X - Open Source. Cygwin is much more that just an X-Windows server. It actually creates an entire Linux-like environment within Windows.
• X410 - Commercial product from the same company that produces Token2Shell, available from the Microsoft Store.

Here is how to start a X-Windows-capable session using PuTTY and either VcXsrv or Xming.

1. Start VcXsrv or Xming from the Start menu. It will appear briefly and disappear except for an X in the application tray. (Note, the first time you start VcXsrv, you will need to do a few configuration steps.)
2. Start PuTTY.
3. In the window that appears, type a host name, e.g., linuxlogin.cac.cornell.edu.
4. Use the tree menu on the left to set X11 forwarding. It's in the Connection > SSH branch.

   

5. You can return to the Session category and Save this session's configuration for future use. Give it a logical name like linuxlogin.
6. Click Open, and it will connect to the CAC general login node.
7. Note for PuTTY 0.61 and above - If an "Access denied" message appears in your terminal window for no good reason, you can prevent this annoyance in future sessions by going to the "GSSAPI" area in the "Auth" section of the SSH branch, and unchecking the "Attempt GSSAPI authentication" box there.

Whichever Windows client and X server you choose, you should test your X-Windows setup by typing the command for Ghostscript, which is a PostScript and PDF previewer:

linuxlogin$ gs  # on another system, you want to might try a different X-capable client, like xterm

A blank window should appear on your screen. You can stop it by typing Ctrl-c in the terminal window.

If this test fails, check to make sure xorg-x11-xauth has been installed on the target system. Also, if you are using a Linux-like shell in Windows (WSL or Cygwin/X), there are a couple of other things to check:

• Make sure you have specified ssh -X or ssh -Y as necessary.
• Type echo $DISPLAY in your shell to make sure this environment variable is set locally; if not, enter the following command (which you can add to your .bashrc)

export DISPLAY=localhost:0.0

Using VNC

VNC lets you see a whole Linux desktop on a remote computer from your local computer. Connecting to Linux via SSH and X-Windows is efficient in that it uses a lot less of the remote computer's resources, but VNC can be much faster if you are doing visualization on the remote computer from off campus.

TigerVNC server has been installed on linuxlogin so you can try VNC there. If you would like to use VNC on a private cluster managed by CAC, please ask your PI to request the VNC installation. Note, a Linux desktop manager is a required part of a VNC installation; GNOME is often a good choice (as is xfce, for those who prefer a minimal desktop).

For security reasons, CAC requires all VNC connections to be tunneled inside ssh. You will therefore need to be able to connect to the remote computer using SSH. The firewalls running at CAC for all login nodes (e.g., linuxlogin) commonly block all incoming ports except for ssh, so VNC connections must be made over a ssh tunnel as described below.

Appropriate use

VNC gives you the ability to establish a remote desktop on a login node, but this ability does NOT imply that you are permitted to run compute-intensive, GUI-driven applications on these machines. On linuxlogin, such usage is contrary to CAC policy. On other shared resources, it is disrespectful toward other users because the login node may become unresponsive through your actions.

Here is a good example of how to use VNC appropriately. By following these steps you can run (say) Abaqus in GUI-driven mode on a compute node that has been allocated to you through an interactive batch job.

1. Open a VNC connection to the login node through an ssh tunnel using the instructions below, in order to gain access to a Linux desktop. Make sure two terminal windows are available on this desktop.
2. In one of the terminal windows, submit an interactive job to the queue of your choice.
3. Once the job starts, you will be given a command prompt on your assigned machine. Note the result of "hostname". There is no need to enter further commands at this prompt (except to exit the job).
4. Go to the other terminal window and open a second ssh connection to the compute node using "ssh -Y <userid>@<hostname>"
5. This new ssh session will tunnel X-Windows from the compute node back to the VNC desktop. Therefore (if Abaqus is on your path), you can now open the Abaqus GUI using "abaqus cae -mesa".

Local setup for all platforms

• Install a local VNC client on your local machine if one isn't installed already. For Linux, TigerVNC is a popular choice. On Mac, you can use the built-in Screen Sharing app. For Windows, TightVNC works well, but so do others.

Starting your remote VNC server (do these steps from an ssh shell)

• Use ssh to log in to the remote Linux computer.
• Set the password for your VNC server using the vncpasswd command.
• Start the VNC server using the vncserver command like this:

 vncserver -geometry 1600x900 -localhost

The geometry numbers 1600x900 (or other numbers of your choosing) specify the size of the desktop in pixels.

• You will need to get the display number from the output of the vncserver command:

 New 'linuxlogin.cac.cornell.edu:1 (shl1)' desktop is linuxlogin.cac.cornell.edu:1
 Starting applications specified in /home/fs01/shl1/.vnc/xstartup
 Log file is /home/fs01/shl1/.vnc/linuxlogin.cac.cornell.edu:1.log

• vncserver is running on port 5900 + display number. In the above example, the display number is :1, therefore vncserver is running on port 5901.

Set up your ssh tunnel (Do these steps on your local computer)

Let's say the port number on linuxlogin is 5901 (as above), and your CAC userid is uid12. Here's what to do to start ssh port forwarding, or tunneling, to that port.

• From Linux, if you are still in the same ssh session you used to start vncserver, type ~ then C to get to an ssh> prompt, then enter:

 -L 10000:localhost:5901

Or you can type the following full command into a local terminal, which opens another ssh session including the tunnel:

 ssh -L 10000:localhost:5901 uid12@linuxlogin.cac.cornell.edu

• From macOS, open a Terminal and follow one of the Linux methods shown above.
• From Windows, ssh clients such as PuTTY can do port forwarding (tunneling); see VNC Tunnel Windows.
• Leave this ssh session running on your local client computer. (It can run in the background.)

Connect your VNC client

• Launch your VNC client program. Connect it to localhost:10000. When prompted, type in your VNC server password.
• A nice GNOME desktop should appear!
• If a pop-up asks you to authenticate, just cancel it. See this link for how to prevent the annoying "Authenticate" pop-up from appearing in your future vncserver sessions.

To disconnect your client

• Close the VNC client program.
• Disconnect the ssh forwarding session (i.e., kill it).

To reconnect your client

• Restart port forwarding with ssh, using the same remote port number as before.
• Again connect the VNC client to localhost:10000.

When you are all done

• It may not be possible to to log out from the Linux desktop. But even if this appears to work, it will leave the VNC server running.
• When you are finished with your session, shut down all your applications in the desktop, disconnect (close) it, and type this command into a separate ssh session to shut down the VNC server completely:

 vncserver -kill :<display number>

Passwordless SSH

An alternative to password-based authentication is public key authentication (PKA). SSH has a well-established mechanism for making use of a public/private key pair.

Note: setting this up for yourself is completely optional! On CAC private clusters where an SSH key pair is required for intra-cluster communications, one will be created for you when first log in to the head node, and you never need to worry about it.

How it works

• When you connect via SSH, instead of entering a password, you provide the name of an identity file on your computer. This is your private key, part of a public/private key pair.
• The computer you are connecting to must already have the matching public key stored in a special location. On Linux systems, it should be found among the list of public keys in the file ~/.ssh/authorized_keys.
• Upon receiving your initial SSH request, the remote computer encrypts a message using one of the public keys in ~/.ssh/authorized_keys. It sends the encrypted message to your computer.
• Your local SSH client attempts to decrypt this message using the private key file you specified. The decrypted message is then sent back to the remote computer.
• The remote computer checks whether your client succeeded in decrypting the message. If so, you have proven your identity. If not, it tries the next public key until all are exhausted.

Clearly, if you want to make use of this mechanism, you will need to set up a public/private key pair!

Create an SSH key pair

Your ssh key pair will only need to be created once. You will not need to repeat this step. You can complete this step from linuxlogin.cac.cornell.edu, the general Linux login node, or from the login node of a private cluster. (If this is your first login to a CAC login node, it will ask you to change your password; this will become your password for connecting to CAC login nodes in the future.) The steps to create your key pair are as follows:

mkdir .ssh
chmod 700 .ssh
cd .ssh
ssh-keygen (and take all default options)
cat id_rsa.pub >> authorized_keys

As a final step, you need to copy the private key, id_rsa, to the computer that you will be logging in from.

Linux and macOS users:

You'll want to put the private key in the ~/.ssh directory. You may wish to call this key id_rsa for convenience, BUT be careful not to overwrite an existing key with that name. Let's say you decide instead to call your new private key cac_id_rsa on your local computer, just to be safe. You MUST change permissions on this key to keep it private:

chmod 600 ~/.ssh/cac_id_rsa

Now you're ready to use passwordless SSH to connect to linuxlogin. From a terminal in macOS or Linux, you do the following:

ssh -i ~/.ssh/cac_id_rsa <your_CAC_username>@linuxlogin.cac.cornell.edu

Windows users:

The way to proceed in Windows depends on the SSH client you are using. Here, we cover PuTTY as an example. The first step is to use PuTTYgen to convert the SSH private key for use with PuTTY and plink.

• Run "C:\Program Files (x86)\Putty\puttygen.exe".
• Select Import Key from the Conversions menu and enter C:\Users\<your_local_username>\.ssh in the address bar, assuming this is where you placed your private key in your home directory. Then, select the id_rsa file and click on the Open button.

• Click on the "Save Private Key" button.

• Click on "Yes" when asked to save the private key without a passphrase.
• Save the private key as private.ppk in the .ssh directory inside your home directory.

• Close (choose File, then Exit)
• To confirm you have converted the ssh private key successfully, do:

"C:\Program Files (x86)\Putty\plink.exe" -i %USERPROFILE%\.ssh\private.ppk <your_CAC_username>@linuxlogin.cac.cornell.edu

It may notify you that "The server's host key is not cached in the registry." Type "y" to "store the key in cache."

• If everything was done correctly, you should now be logged into linuxlogin without being prompted for a password. Type exit to log out.

In PuTTY, you will want to update your Saved Session for linuxlogin to use the new key. Load the linuxlogin session. Navigate to "Connection > SSH > Auth", browse to %USERPROFILE%\.ssh and open the id_rsa file. Go back to Session and click Save. Now you won't need to enter a password for linuxlogin ever again!

Connect to Windows

Using Remote Desktop Connection (RDC) to connect to a Windows Server

This method of connecting to a Windows Server is preferred because it provides you with a fully functional Windows desktop.

Remote Desktop sessions do not expire unless you log out, but they will end when machines are shelved or rebooted.

• If you use a Windows machine:
  Use the Remote Desktop Connection to connect. This software is pre-installed on Windows Desktops. To run it, find Windows Accessories in your list of apps, then click Remote Desktop Connection.
• If you use macOS:
  Search from Microsoft Remote Desktop at the App Store. it works just like the Remote Desktop Connection in Windows. You can also use rdesktop (see below). Tip: if authentication fails, make sure your software updates are current.
• If you use Unix or Linux (or Mac):
  You can access the Windows machines by using the cross-platform rdesktop client. If you are running Linux, typically it is part of the distribution. If you prefer to build it yourself, it is available for download from rdesktop.

Home Directory Access

Users of CAC's storage services have a "storage03" directory which can be accessed from both Linux and Windows systems:

Note, private clusters often have their own file servers, so users of private clusters may find that the linuxlogin path is not the same as their home directory on their private clusters. Also, Red Cloud users do not automatically have storage privileges on storage03, unless such storage is included in their CAC project.

In Linux, it is generally safe to refer to your home directory as either ~, ~<username>, or $HOME, so you never need to specify the exact mount point. On CAC's Windows systems, you can map your home directory to a letter drive (such as H:) using the "Map Network Drive" feature; however, it is often preferable to use the full UNC path to the network share, as given above.

You can mount your CAC home directory on your local machine, as long as your machine is connected to either the Cornell campus network or CU VPN.

Linux users

You mount your storage03 directory via SMB/CIFS like this:

sudo mount -t cifs //storage03.cac.cornell.edu/<username> /mnt/pt -o user=<username>,domain=CTC_ITH,uid=<localid>,vers=2.1

where <username> is your CAC user name, <localid> is your local user name, and /mnt/pt is the name of a directory you have created ahead of time to be the mount point on your local filesystem. Enter the password for CAC account when prompted. See man mount.cifs for available options for the mount command.

If you see errors, such as "missing codepage or helper program," then you have not installed the mount and umount packages for CIFS on your local machine. If problems persist, send your initial command and the results of dmesg | tail to CAC Help.

macOS users

• In the Finder, either select Connect to Server... from the Go menu or use the shortcut cmd-K.
  
  
• Enter smb://storage03.cac.cornell.edu/<username> in the Server Address field as shown below. You may need to use smb://<username>@storage03.cac.cornell.edu/<username>.
  
  
• Enter your CAC user name and password to log in. You may need to use <username>@tc.cornell.edu in place of your username.

Windows users

• In a File Explorer window, right-click on "This PC"
• Choose "Map Network Drive..." from the menu that appears
• Select "H:" from the drop-down menu (if you are already using this drive letter, select another letter)
• Folder: \\storage03.cac.cornell.edu\<username>
• Then:

-Check "Connect using different credentials". This will allow you to enter the domain associated with CAC and your username at CAC, rather than those associated with your own machine.

-User name: CTC_ITH\<username>

-Password: your CAC password

• Troubleshooting: If you have already mapped the drive and subsequently have problems, disconnect the drive and remap it.

File transfer

A single, central file server, storage03.cac.cornell.edu, provides access to much of CAC's file storage for individual users. It serves the bulk of the home directories on linuxlogin as well as many private clusters. Here we look at various clients that can be used to transfer (i.e., copy) files to and from this server, mainly via linuxlogin.

Linux and macOS users

Secure Copy

Secure copy is a standard tool to copy files to and from remote hosts.

localhost$ scp localfile.dat username@linuxlogin.cac.cornell.edu:remoteinput.dat
localhost$ scp username@linuxlogin.cac.cornell.edu:results.dat localresults.dat

Secure FTP

FTP is disabled for security reasons, but sftp's interface is nearly identical.

Samba Client

This technique only works from Cornell campus locations or via a Cornell VPN connection. Type

smbclient //storage03.cac.cornell.edu/<user name> -U ctc_ith\\<user name>

(Note, the shell interprets \\ as a single backslash.) Enter the password for your CAC account when prompted. You will see the smb:\> prompt. Now you can start transferring files between your local machine and your CAC home directory, using commands similar to the sftp client. Type help for more instructions.

 -bash-4.1$ smbclient //storage03.cac.cornell.edu/<user name> -U ctc_ith\\<user name>
 Enter ctc_ith\<user name>'s password: 
 Domain=[CTC_ITH] OS=[Unix] Server=[Samba 3.6.23-24.el6_7]
 smb: \> help

Windows users

Secure Copy

The individual who created PuTTY provides a secure copy client called pscp. From the command prompt, type:

cmd> pscp localfile.dat username@linuxlogin.cac.cornell.edu:remoteinput.dat
    <enter your username's password when prompted>
cmd> pscp username@linuxlogin.cac.cornell.edu:results.dat localresults.dat

Secure FTP

FTP is disabled for security reasons, but psftp's interface is nearly identical. From the command prompt, type:

cmd> psftp username@linuxlogin.cac.cornell.edu
    <enter your username's password when prompted>
psftp> put localresults.dat results.dat
psftp> quit

Linux Usage Tips

Linux shells

• /bin/sh is the default login shell.
  • Edit $HOME/.profile to change interactive variables.
  • The $HOME/.bashrc file will not be run for non-interactive shells.
• /bin/bash
  • Edit $HOME/.profile to change interactive variables.
  • The $HOME/.bashrc file will be run for non-interactive shells.
• /bin/csh and /bin/tcsh
  • Edit $HOME/.login to change interactive variables.
  • The $HOME/.cshrc file will be run for non-interactive shells.

The change shell command, chsh, will not permanently change your shell. You must send a request instead. Contact Support

The default login shell on linuxlogin is sh. Be aware that in CentOS, /bin/sh is a soft-link to /bin/bash, so you are really using a variant of bash. Accordingly, you will find that "man sh" brings up the man page (the help document) for bash. In a way, then, you can think of your login shell as being bash, too.

There are slight differences between sh and bash, however. The "Invocation" section of the man page states: "If bash is invoked with the name sh, it tries to mimic the startup behavior of historical versions of sh as closely as possible." Therefore, you will find that ~/.profile is run at login, because this behavior is common to both sh and bash; but any interactive sh shells you start thereafter will not run ~/.bashrc as you might expect from bash. The way to get sh to do this is to "export ENV=~/.bashrc" beforehand (perhaps as part of your .profile).

Let's say you simply prefer to have bash as your default shell and be done with it. There are two ways to accomplish this. First, you can "export SHELL=/bin/bash" in your .profile; then all subsequent interactive shells will truly be bash. Second, you can enter "chsh -s /bin/bash", which forces all login and interactive shells to be bash (because you have changed your default shell). The problem with the second method is it may well wreck your batch environment, too, because the scheduler sets it up under the assumption that the login shell is sh.

The relationship between the csh and tcsh shells is similar to the one between sh and bash. For instance, your csh shells are automatically endowed with the tcsh-style ability to retrieve history through the up- and down-arrow keys. The best way to make tcsh into your everyday working shell is to run it on top of sh after you log in (again, you can do this as part of your .profile).

References

• "man bash" from the command line.
• Advanced Bash Scripting Guide, one of the Linux Documentation Project guides
• Bash FAQ
• Bash Pitfalls

Compiling and linking code on Linux

Compiling Code Linux

Linux FAQ

How do I determine my program's dependencies on shared library (.so) files?

• ldd - see the man page.

If your program cannot find all the .so files it needs, you may need to add paths to the LD_LIBRARY_PATH shell variable.

How do I display an image file (such as jpeg or gif)?

• display mypic.jpg - uses one of the many ImageMagick tools - see "man ImageMagick" for help on this and various file format converters.
• firefox mypic.jpg - any decent Web browser can handle it.

Note, the image will show up only if you have X11 forwarding enabled.

How do I use revision control?

• Git, Subversion, and CVS are examples of revision control (or version control or source control) software. These tools help you collaborate with others by allowing you to save and track successive versions of your source code as you modify it. Git is often used in conjunction with GitHub. Git is installed on linuxlogin: see the git man pages for for details. To check the installed version, type git --version.

More information on Linux nodes at CAC

For more detailed instructions on how to use the Linux node, see here

Windows Usage Tips

Windows Usage Tips

More information

The CAC Web site is here . There are many useful documents on the Support page at CAC documentation.

Acknowledging CAC

When you publish a paper, make presentations, or are interviewed by the Cornell Chronicle, national news media, etc., please acknowledge the Center by including:

"This research was conducted with support from the Cornell University Center for Advanced Computing."

Alternatively, the full acknowledgement is:

"This research was conducted with support from the Cornell University Center for Advanced Computing, which receives funding from Cornell University, the National Science Foundation, and members of its Partner Program."

FAQ/Troubleshooting

1. Account FAQ
2. Login FAQ
3. If you have more questions, see here