Linux and department servers: Difference between revisions
Removed hydras |
→Getting Access: (ssh): changed hydra example to leviathan |
||
| Line 45: | Line 45: | ||
<ul> | <ul> | ||
<li>For Macs (and Linux), open up a <code>terminal</code> and type | <li>For Macs (and Linux), open up a <code>terminal</code> and type | ||
<syntaxhighlight lang="bash">ssh andrew_id@ | <syntaxhighlight lang="bash">ssh andrew_id@leviathan1.stat.cmu.edu</syntaxhighlight> | ||
you will then have to type in your password (if you don’t know it or don’t know it or have never accessed the server before - email [mailto:remarks@stat.cmu.edu remarks@stat.cmu.edu]). | you will then have to type in your password (if you don’t know it or don’t know it or have never accessed the server before - email [mailto:remarks@stat.cmu.edu remarks@stat.cmu.edu]). | ||
| Line 71: | Line 71: | ||
* Make sure there is a <code>~/.ssh</code> folder on the server. If not, make a .ssh folder. | * Make sure there is a <code>~/.ssh</code> folder on the server. If not, make a .ssh folder. | ||
* Next, upload the public key to remote server. This command will upload the public key to all the hydras and ghidorahs since they share a file system. | * Next, upload the public key to remote server. This command will upload the public key to all the hydras and ghidorahs since they share a file system. | ||
ssh-copy-id andrew_id@ | ssh-copy-id andrew_id@leviathan1.stat.cmu.edu | ||
* To ensure the permissions of the <code>~/.ssh</code> directory are updated, log into the hydras and run: | * To ensure the permissions of the <code>~/.ssh</code> directory are updated, log into the hydras and run: | ||
chmod 700 ~/.ssh | chmod 700 ~/.ssh | ||
Revision as of 05:40, 27 March 2026
The department has two sets of servers, the Leviathans and the Hydras, that can help you run large analyses and gain a better understanding of common command line structure for more high scale computing. One can also view the department servers a bit more as a “sandbox” or “playground” as there are very few constraints and it’s okay to not run as polished code as you might on the PSC or Azure.
[Request: Windows users (and all users) - if you see comments that are outdated / less helpful than expected please contribute.]
What resources exist
- The department provides 11 leviathan servers (named {
leviathan1, ...,leviathan11}.stat.cmu.edu - Each Leviathan has 16 CPU cores and 128 GB of RAM. The Leviathan CPUs are much faster than the former Hydra CPUs.
- The Hydras and Leviathans all share the same data file system. This allows you to upload a file to any of the servers and then have it on all of them.
- OpenMPI is installed
- This allows MPI based parallelization to be used
- Note that the hydras ARE NOT network connected, so MPI can only be used within a single hydra. It cannot communicate across multiple hydras.
- If you need to run something in parallel across multiple nodes, you should use PSC instead.
See What resources when for guides to help decide which resource you should be using.
Using the servers respectfully
Because the servers are a shared department resource it is important to use them respectfully. There are many servers and multiple cores (CPUs) per server. To be respectful of other users:
- Check the current usage of the server you're on before using it.
- Do not use all the cores on a server, and do not use all the servers at the same time, so others can get work done.
- If you have a long-running job, deprioritize it so others can run too.
Each of these is easy to check.
Checking current usage
To check which servers are currently being used and which are open, see the Grafana dashboard for the hydras and for the Leviathans. It lists them all and their current usage.
When you're logged in to one node, you can use the top command. top displays the current usage of the server’s resources with a list of jobs run. It also tells you the percentage of the cores that are being used and the amount of RAM (memory) that is available. See howtogeek resources on how to interpret it all (the documentation is very clean, so we encourage you to read up ther
Limiting the cores you use
We recommend that when using parallel processing, use fewer than the total number of cores on the server. Most parallel processing packages let you choose the number of cores to use; the hydras have 12, so pick something smaller.
Deprioritize when possible
nice/renice allows you to lower the priority of your jobs, so the operating system lets other processes run first. See howtogeek resources on the basics. nice sets the priority, and renice updates your priority. On the department servers, everyone starts at the same priority, and you can only deprioritize your jobs -- you can't make them higher priority than everyone else.
nice -20 Rscript some-big-script.R
renice -n 20 processid # get the process ID from topIntroduction to connecting to the server and useful Linux commands
The department servers all run Linux, and require you to use a command line to interact with it (as compared to Rstudio and other GUIs).
Getting Access: (ssh)
To get onto the server and type code you’ll need to access it through ssh.
- For Macs (and Linux), open up a
terminaland typessh andrew_id@leviathan1.stat.cmu.edu
you will then have to type in your password (if you don’t know it or don’t know it or have never accessed the server before - email remarks@stat.cmu.edu).
- For Windows, there's a few options (with different pros and cons). Makeuseof provides an overview and introduction to how to get started on a few approaches, including PuTTY and Windows PowerShell. Again, make sure to email remarks@stat.cmu.edu to check that you have an account / or what your password is if you forgot.
If you’re accessing the servers a lot, you might also look into aliases and password storing for the ssh commands. - Mac/Linux: scotch.io - Windows: Powershell: microsoft, PuTTY: makeuseof
Passwordless ssh
To get on the server without typing in the password, you need to first generate a SSH key pair. This creates a private key that identifies your laptop, and a public key that the servers can use to recognize your private key.
- For Linux or Mac, open up a terminal and check whether you already have a key pair: run
ls ~/.sshand see if you have any files with names startingid_. If you do, you already have a key pair, and you can skip to thessh-copy-idstep below. - Next, generate a key pair (both public and private key). There are different types of keys (RSA, ECDSA, and Ed25519). The
-toption specifies the type of key pair.
ssh-keygen -t ed25519
- A prompt for what to name the key pair and what folder to place it in should appear. The username should be the username for your local computer and
id_ed25519is the key pair name. You can change it. The local key should be stored in the~/.sshfolder on your local computer.
Generating public/private ed25519 key pair. Enter file in which to save the key (/home/username/.ssh/id_ed25519):
- Hit Enter to accept the default name and location, or enter the folder and name manually.
- A prompt for a passphrase should appear. This is for securing the local key (on local computer) and is optional.
Enter Passphrase (empty for no passphrase):
- Make sure there is a
~/.sshfolder on the server. If not, make a .ssh folder. - Next, upload the public key to remote server. This command will upload the public key to all the hydras and ghidorahs since they share a file system.
ssh-copy-id andrew_id@leviathan1.stat.cmu.edu
- To ensure the permissions of the
~/.sshdirectory are updated, log into the hydras and run:
chmod 700 ~/.ssh chmod 600 ~/.ssh/authorized_keys
You should now be able to SSH into the server without being prompted for a password.
File sharing (scp +)
There is also command line code to copy files from your personal computer to the server. This is done with a SCP (secure copy) tool. There are also GUIs (graphical user interfaces) that allow you to “drag and drop” files from your computer to the server (and visa-versa). Currently, a lot of students use GUIs to deal with file sharing.
Command line scp
You can file share either by using scp, for example
- Mac/Linux: This command is very similar to
cp(the file copier).- Copy from server
scp username@from_host:path/to/file.txt /local/directory/
scp -r username@from_host:path/to/folder/ local/directory/
- Copy to server
scp local/file.txt username@to_host:/remote/directory/
scp -r local/directory/ username@to_host:/remote/directory/
scpreferences: haydenjames.io - Copy from server
- Windows: Again, this process is a bit more complicated.
GUI “drag-and-drop” file sharing
A lot of students use GUI interfaces to transfer files instead of scp command line. These tools allow you to “drag and drop” files from one location to another after the connection is set up.
Some examples include:
- Mac:
- Linux:
- Windows: lots of options - thegeekstuff
Basic CLI (Linux command line): bash
Understanding the basic Linux command line is important to be able to navigate when you are actually on the server. Below are some based commands to move around the file system, manipulate files, and view storage structure.
| command | translation |
|---|---|
pwd
|
print the current working directory |
cd _dir_
|
change directory |
rm _file_
|
remove / delete file |
mv _file_ _dir_
|
move file (can change name) |
cp _file_ _dir_
|
copy file |
ls _dir_
|
list files in directory |
use man _command_ to get a listing / manual of the command.
Additional resources that capture more information on the command line and are still geared to statistical computing can be found here: UCB 2015 reproducible DS lecture notes.
TODO: add information about sed, chmod, and a link to bash files.
Text editors
There are multiple options to view code on the server side. They include:
- vim
- … [to be added later]
Running jobs
We have included thoughts about running jobs in two places.
- The first looks at tools that allow you to keep running jobs on the server when you close the connection to the server (turn off your laptop, etc.). These tools are call terminal multiplexers.
- The second set of tools focus on how to run your R analysis or Python analysis code on the server.
Server specs
Generally speaking, our servers have multiple CPU cores, but no GPU cores. For deep learning tasks that need GPUs, consider using the GPU cluster.
To examine the specs yourself, use
cat /proc/meminfo
cat /proc/cpuinfoto see some information.