Thayer School and Computer Science offer several different options for using Linux. The Dual-Boot Computer Labs in MacLean M210, Cummings 115 and Cummings C011 provide full graphical clients, and several compute servers provide ssh and sftp access for long-term computations, remote access, and file transfer.
User Name and Password
All Linux systems use ThayerFS, so you should authenticate with your NetID and password. Be sure to use all lower-case characters for your NetID on linux systems - they will not recognize it otherwise. See NetID Username and Managing Passwords for details about these credentials.
Dual-Boot Computer Labs
The Dual-Boot Computer Labs are located in MacLean M210, Cummings 115 and Cummings C011. These workstations are for interactive sessions only - after 30 minutes of idle time, other users will have the option of logging off your idle session. If you are running long-term computations or simulations, please use one of our compute servers listed below.
Linux Compute Servers
If you use these servers, please make sure you read and understand Compute Server Etiquette
Thayer School and Computer Science also operate and maintain several high-end compute servers. These servers are available to all Thayer and CS users, and are a much better choice for intensive computation as they have faster processors and more memory than Computer Lab systems. You can access the servers via an ssh session, using the same authentication as other Thayer and CS systems.
Names of these servers are:
Note: In order to reach our linux systems from off campus, you must connect to the Dartmouth VPN first.
The simplest way to connect to our Compute Servers is to use ssh. For more information about how to use and/or install ssh, see this page: Secure Shell and Secure FTP
If you need to use graphical applications, and your system has an X Server ( X11 for Windows and Mac), you can add the -X option to ssh to display the graphics on your machine. For example:
ssh -X firstname.lastname@example.org
If you are using PuTTY, you need to make sure your X Server is running and then enable it in your PuTTY connection configuration by checking the "Enable X11 Forwarding" checkbox under Connection->SSH->X11.
Another method that can be used to run a full graphical desktop remotely is FastX. This allows you to disconnect from and reconnect to open sessions, and can be much faster that X11 forwarding, especially over slower connections. For more information about downloading and setting up FastX, see this page: FastX
Cluster Usage Checking
To determine the usage of our linux compute clusters, we have developed two tools. This information is useful in determining on which compute server you may wish to run your job(s).
- Web-based tool
The web-based cluster usage tool is at: http://cluster-usage.thayer.dartmouth.edu/ (VPN required)
- Command-line tool
From any ThayerFS linux client, you can use the following command:
This will print a table showing current utilization of the compute cluster.
Thayer Shares and DartFS
All Linux Computer Lab clients and compute servers communicate with ThayerFS and Jumbo using kerberized NFS4. Once you log in, you are in your home directory, which is located at the following path:
The other ThayerFS shares are all located under /thayerfs:
The Jumbo shares are all located under /jumbo:
DartFS shares (including DartFS home directories) are all located under /dartfs and /dartfs-hpc, identical to IT&C Research Computing systems:
/dartfs-hpc/rc/home/q/d12345q /dartfs-hpc/rc/lab/F/Foobar /dartfs/rc/lab/F/Foobar
If you are new to Linux and would like a basic introduction the the filesystem and commands, please see our Linux Basics page.
All Linux Computer Lab clients and compute servers run Ubuntu Linux version 22.04 (jammy).
A full complement of standard linux utilities, libraries and compilers are installed on all computers. In addition, there are several Engineering applications available in /thayerfs/apps. These are available via the "Thayer Apps" menu or at the command line. Here is a current list of these applications:
- Matlab / Simulink
- Synopsys Sentaurus PCM Studio
- Synopsys Sentaurus Workbench
- Tecplot 360
- Oregano (spice GUI)
- Xilinx Vivado / Vitis
To load different versions of these applications or use other non-standard applications or libraries, we use environment modules. For more information about this, please see our Modules page.
The Thayer School linux clients have several tools available to create and compile LaTeX documents. For more information, please see our LaTeX page.
Open Source Compilers
Currently, our linux systems have the following open-source compilers installed:
- gcc 7.5.0 (/usr/bin/gcc) - C compiler
- g++ 7.5.0 (/usr/bin/g++) - C++ compiler
- gfortran 7.5.0 (/usr/bin/gfortran) - Fortran 90/95 and Fortran 2003 compiler
Another Fortran 95/2003 compiler is G95, available at: http://www.g95.org/. This is not currently installed on our systems, but can be downloaded and used from within any directory to which you have access.
MPI (Message Passing Interface)
We have installed OpenMPI ( http://www.open-mpi.org/) on our linux systems for use with MPI software. MPI allows many processes spread across multiple CPUs and multiple systems to pass messages and data between them to work on parallel computations. For more information about our MPI implementation, please see our Linux MPI page.
Due to limitations with our current authentication infrastructure, all users default to the bash shell. If you would like default startup scripts for this shell, you can copy them into your home directory with the following command:
This will copy the following files into your home directory:
.bash_logout .bashrc .profile
If you would prefer a different shell - csh, tcsh or ksh - you should add a line to the end of your .bashrc file to execute this shell. For example, if you prefer tcsh, add the following as the last line in your .profile file:
All Linux computers use kerberized NFS4 to communicate with ThayerFS, Jumbo and DartFS, which require the use of Kerberos 5 for authentication and authorization. When you log into one of the Linux clients or compute servers, you will get a kerberos ticket which expires in ten hours. By default, however, a program is run at each login that will automatically renew this ticket up to a maximum of thirty days. At the end of the thirty days, your session will not end, but you will no longer have access to ThayerFS, Jumbo or DartFS in that session. You can check the current status of your Kerberos tickets with the 'klist' command:
$ klist Ticket cache: FILE:/tmp/krb5cc_12345 Default principal: d12345q@KIEWIT.DARTMOUTH.EDU Valid starting Expires Service principal 09/01/2017 11:00:00 09/01/2017 21:00:00 krbtgt/KIEWIT.DARTMOUTH.EDU@KIEWIT.DARTMOUTH.EDU renew until 10/01/2017 11:00:00
The first line shows the status of the current ticket, and the "renew until" line shows the final thirty-day renewal limit of your ticket.
To renew a ticket manually, you can type the command 'kinit -R'. If you are nearing the renewal limit or have already passed it, you can obtain a new ticket with a new thirty-day renewal limit by simply typing the command 'kinit' - you will be prompted for your password.
To initiate a long-running process, you will need to use the 'krenew' utility. If your process can run detached without need for stdin or stdout, it can be run with the following command:
$ krenew -b foo
where 'foo' is the name of your long-running process. This process will be run in the background, and krenew will automatically renew kerberos tickets for this process for up to thirty days. At final expiration of the kerberos tickets after thirty days, the process will be terminated.
If your long-running process needs stdin and/or stdout, we recommend using the 'screen' utility. Screen is a terminal muliplexer which gives you a persistent terminal session which can be detached and re-attached over logouts and logins. To start a screen session, simply type:
This session behaves like a normal shell, where commands can be run as usual. However, you can also "detach" your screen session, log out of the client, and then log back in later and resume the session. To detach a screen session, type Ctrl-A, followed by the d key. This will detach your screen session and drop you back to your original shell - anything that was running in the screen session will continue to run. You can then log out of the client if you wish. To resume a screen session, type:
$ screen -r
If you have multiple screen instances, they will be displayed, and you will need to select the one to which you'd like to connect. When you are done with a screen session, simply type "exit" or Ctrl-D, and the screen session will terminate.
So, from within this screen session, you can initiate your long-running process:
$ foo < input > output
where 'foo' is the name of your long-running process. Be sure to not use an ampersand (&) to background the process - this will break the automatic credential renewal. This process will interact normally with stdin and stdout, and the krenew that is run when you initiate a new screen will automatically renew kerberos tickets for this process for up to seven days. At final expiration of the kerberos tickets after seven days, the process will be terminated.
Be sure to terminate any old screen processes when you are done with them - many times, old screen processes are left with Matlab running, using up our available licenses.
To terminate old screen processes, connect to them using 'screen -r' terminate any programs running in them, and then type 'exit' or Ctrl-D to exit the screen process.
For more information about krenew or screen, you should read their man pages:
$ man krenew
$ man screen
There is also a nice page about both beginning and advanced features of screen here: https://developer.ibm.com/articles/au-gnu_screen/
By default, core dumps are disabled on our systems. To enable core dumps in a shell, use the following command:
$ ulimit -c unlimited
This will allow core dumps in that shell. Then, once you have run a program that produces a core dump, the dump will be located in this directory:
In this directory, there will be a core dump for your program with the full path. These files can be copied elsewhere if needed and will be cleaned up when the machine is rebooted.
To see all core dumps for your user account, you can use this command:
$ ls -al /var/lib/apport/coredump/*$UID*