Introduction
Here, we give a brief overview of the available resources and link to the specific pages with more in-depth information. First of all, let us explain some acronyms and jargon that you will encounter here throughout the pages.
MBS: Molecular Biophysics Stockholm is the name of our group consisting of the groups Delemotte, Hess and Lindahl.
LDAP: Lightweight Directory Access Protocol is a network protocol to access user directories. This is how all of our computers access the central user account directory that is hosted on a s.c. LDAP server. Your LDAP account gives you access to most of the group resources described on this page.
NFS: Network File System is a network protocol for file access. We use it to make the users’ home directories available on all of our computers. We also call this the Nethome server (after the configured access path /nethome/).
Cluster: our computer cluster consists of many servers (s.c. nodes in this context) that are connected by a network. Compute jobs on the cluster are scheduled by a workload manager (Slurm in our case).
Ceph: this is a software-defined storage system that we use to store large amounts of data. It can provide block storage as well as object and file storage. We call the file storage part CephFS.
SSH: Secure Shell Protocol is a network protocol for remote command-line access to computers. This is how you can access our computer cluster and even the workstations in our office at SciLifeLab. ssh is the name of the command-line tool you use to establish a connection.
VPN: Virtual Private Network is used to access resources on a network that are not accessible for the general public.
Zulip: this is a chat software that we use on a daily basis. You can find it at https://chat.biophysics.se.
Account types and authentication
There are a number of different accounts you will get when you join the group:
- MBS LDAP account: this one gives you access to our self-hosted services (cluster, Zulip, etc.)
- SciLifeLab account: this is a Google account and gives you access to Google services and the SciLifeLab VPN
- KTH/SU/KI account: your employer/university will provide you with an account to access other services (administration, procurement system, etc.). To access Eduroam WiFi for example you will have to follow instructions published by your employer/university and use the account provided by them.
- SSH key(s): these you can create yourself in order to simplify SSH login, see below.
Workstations
Previously, we have had a system with common administration of workstations, but this is being deprecated and going forward each user/team/PI will be responsible for installing and maintaining their own workstations.
We still include the documentation for the common environment below, but if you are starting out it’s important to be aware this will be removed in fall 2025.
Instructions for the old setup with centrally maintained workstations
The first thing you might encounter are the workstations in our office at SciLifeLab. They all run the same version of Ubuntu Linux (24.04 at the time of writing). You can log in at the display manager with your LDAP username and password and will land in a Xfce Desktop Environment. You can find a short introduction to that on the Xfce website.
If you have not worked (much) with Linux before now is your chance to learn đ There are plenty of tutorials online, or depending on the time of the year you can even find introductory courses at compute centers (check https://enccs.se/events for example). Many things are documented in the manual pages, just open a terminal and run “man <command>” to see the manual page for <command>. Another great resource is the Arch Linux Wiki. Even though we use Ubuntu Linux many things are the same, or at least similar enough to apply.
Each workstation has a label on it (either mbsXY.scilifelab.se or mbsXY.dyn.scilifelab.se) that tells you how the machine can be reached remotely over SSH. You will need to set up the SciLifeLab VPN before being able to access them remotely, and set up SSH key login. You can read below in the section First steps how to do that.
For these machines, home directories were shared and user accounts managed centrally. Because of that however, your desktop session will freeze if the connection to the file server is interrupted (a safety feature to avoid data corruption). If it happens don’t reset the machine, that does not help. Talk to people around you and check Zulip if someone is already aware of the problem and working on it. As soon as the connection to the file server is restored, your desktop session will respond again. For more information please have a look at the page File systems and networks.
Don’t use sudo. These workstations are configured identically and should remain that way in order to keep things maintainable. Therefore users do not have sudo permissions. If you’re wondering how to install software, please read the page Installing and managing software.
For the old setup, a print queue for the printers at SciLifeLab is already set up on the machines. In order for it to work you’ll have to uncomment two lines in the file $HOME/.bashrc and set your SciLifeLab username there. After that restart your desktop session (log out and back in) and you should be able to print. See instructions at the printers for how to get your documents.
# settings for SciLifeLab FMP printers; uncomment and set your username in the
# CUPS_USER variable (first part of your @scilifelab.se email address)
export PRINTER=”scilifelab_fmp”
export CUPS_USER=”bilbo.baggins”
Instructions for the new setup with individually maintained workstations
From mid-2025, the responsibility for workstations lies entirely with each group/PI. New users will not have centralized LDAP accounts, but you need to install computers with the operating system you want, set up local computer accounts and a local home directory. This also means your home directory is not backed up, and it will not be shared between workstations or with any cluster.
The person responsible for the workstation (ultimately the PI) is responsible for permissions, including sudo permissions and configuring software, printers, etc. You can find a lot of information at the SciLifeLab pages about the general IT environment, including e.g. printers.
Computer Cluster
General access to the cluster will end fall 2025, in parallel with moving workstations to be individually managed. For old users, you have the same home directory as on the workstations and you log in over SSH with your LDAP username and password (or SSH key if set up). There you have access to compute nodes for running jobs and storage space on CephFS. Before using the cluster please read the page Partitions.
Be aware that storage both in the home directories and the large CephFS partition will be discontinued in fall 2025, so you need to start planning other storage and move your data out. The Cryo-EM facility will maintain some storage for short-term data processing.
Zulip
This is one of the main ways to communicate within the group. You can access it at https://chat.biophysics.se. It is organized in so called streams, that you can subscribe to in order to participate in the conversations there. By default you are already subscribed to a couple of streams, like the Cluster and Workstations streams.
If you encounter a problem, please check if it has already been discussed on Zulip before starting a new topic. Important information for searching on Zulip: https://zulip.com/help/search-for-messages#searching-shared-history.
Often when you ask a question you have probably already tried to find a solution for some time before you reach out. So when you do, try to take a few steps back. Don’t just say “I’m trying to do this and it doesn’t work”. Give some context, like “I’m doing A, because I’m trying to achieve B”. And try to be specific, “doesn’t work” is usually not a helpful error description đ You could also add where you have looked for information and what you have tried so far to solve the issue. Don’t write a novel, but elaborate a bit. Most important, point to all the necessary input files, commands including parameters and error output. And show that you have at least read the error message even if all you can say is “I don’t understand the error message”. Wouldn’t you be much more motivated to help someone if you see that they have provided the necessary information, instead of you having to ask several follow-up questions and waiting for the answers?
Group Computers
A detailed list of available hardware, both workstations and cluster nodes you can find on the page List of group machines.
First steps
Set up SciLifeLab VPN on your laptop/home computer
To access your workstation from home, you have to set up SciLifeLab VPN. To this end, you need to install a software supporting VPN connections (e.g. Tunnelblick on macOS, OpenVPN on Linux) and activate a certain VPN configuration. A detailed PDF instruction and the file with the VPN configuration are available on the SciLifeLab intranet (to which your personal computer can’t connect without the VPN) or in this post in the Zulip workstations stream, which will be kept up-to-date.
The purpose of the SciLifeLab VPN is to identify you as an authorized user to grant you access to internal resources; it is not meant to increase the level of privacy as you would expect from a commercial VPN. Corresponding warnings from the VPN software when starting a VPN connection can be ignored. Note that you need your SciLifeLab account credentials for the VPN connection, not your MBS LDAP account.
Generate SSH key pair and use it to log in
As SSH keys seem to be the only way to log in remotely that the current and future Linux versions enable by default, please bring your laptop and a USB stick (or some other means to transfer your public key to your workstation) to the lab on your first day(s) in order to set up your login via SSH key. SSH key pairs consist of a private key to be stored on the computer from which you want to connect (e.g. your personal computer/laptop) and a public key to be registered on the computer you want to log on to (e.g. our cluster, your workstation).
To generate a SSH key pair, a sufficiently recent version of ssh needs to be installed on your computer. (Don’t worry; it is installed by default on all Linux distributions, macOS and recent Windows.) The currently recommended type of SSH encryption is ED25519. To generate an SSH key pair of that kind, type the command line:
$ ssh-keygen -t ed25519 -C "<comment>"<comment> is more or less a name of the SSH key pair. It’ll be very helpful later on as it is highly recommended to use different SSH key pairs (and different passphrases!) to log in to external HPC clusters or servers like GitLab. Technically, it’s, of course, possible to just create one SSH key pair and register the corresponding public key on all clusters and servers. However, this is equivalent to using the same password everywhere and therefore not recommended at all! On the other hand, some external clusters make it very cumbersome to register public keys (or allow just one public key per user). In situations like this, you may want to store the corresponding private key on both your workstation and your private computer/laptop such that you can connect both from work and from home. But always keep your private keys absolutely confidential and in a minimal number of places (see below)!
After typing the above command, you’ll be asked to specify a file to store your private key in (the public key will be stored in the same directory and have the same file name extended by the suffix .pub). More importantly, you’ll be asked to specify a passphrase. Although it is possible to not specify a passphrase, just don’t!!! If anyone gets a hold of your private key, they could immediately log in to our workstations and the cluster! Since the keys are stored in your home directory, technically, it is possible for an attacker to steal them, for example if you visit a malicious website that makes use of an unknown security vulnerability. So, please choose a strong passphrase (the same rules as for passwords apply)! For more detailed and up-to-date information on SSH key pairs, have a look at GitLab’s documentation.
After generating the SSH key pair, keep the private key on your computer inside the .ssh folder (don’t share with anybody! don’t send via email! etc.). To enable you to log in with the key, you have to append the contents of the public key (.pub) to the file /nethome/<USERNAME>/.ssh/authorized_keys. You can either do it manually, or use the command ssh-copy-id if available on your system.
$ ssh-copy-id -i $HOME/.ssh/<KEY_FILENAME>.pub <USERNAME>@login.tcblab.org For your convenience, we recommend that you set up a config file in the .ssh on your workstation/personal computer. For instance, if you want to log in to our cluster by typing ssh cluster, you need the following entry in config:
Host cluster
HostName login.tcblab.org
User <your_user_name_on_the_cluster>
IdentitiesOnly yes
IdentityFile <path_to_the_private_key_on_your_computer>Moreover, it is very inconvenient (and a technical problem in some cases) if you have to re-type your passphrase every time you log in or transfer data. To avoid this, you can add your SSH key to your key ring if this doesn’t happen automatically:
$ ssh-add <path_to_your_private_key>The flag provided to ssh-add may vary depending on your operating system. The above example is supposed to work on Linux.
If for some reason your ssh installation refuses to add your key to your key ring, you can re-use your SSH key in your current shell without re-typing the passphrase after issuing these two commands:
$ eval $(ssh-agent)
$ ssh-add <path_to_your_private_key>Set up Eduroam
If you want to connect to WLAN at SciLifeLab, you have to set up eduroam on your device beforehand. Access to Eduroam is provided by your employer, therefore we refer you to the respective instructions for employees of KTH, SU or KI.
What else?
SSH Proxy
Tired of using slow X-forwarding to access information thatâs only available within the university network, like journal articles? Use SSH as a proxy! You can use a machine in the biophysics network, e.g. login.tcblab.org. You can use the following command (the flag “-N” tells ssh to not start a shell on the remote host, hence you won’t see the usual shell prompt):
$ ssh -N -D 127.0.0.1:8080 USERNAME@login.tcblab.orgAll you have to do now is open your web browser and edit the network settings. In Firefox, that is Preferences -> Advanced -> Network -> Settings. There you select âmanual proxy configurationâ and in the field âSOCKS Hostâ you enter 127.0.0.1 and select port 8080. In Google Chrome, it is Setting -> search for ‘proxy’ -> Open your computer’s proxy settings. In Ubuntu 18, it should look something like this:
When you terminate the SSH session, youâll have to revert these settings. Or you can use the add-on ProxySwitcheroo or FoxyProxy to quickly switch between different profiles or even configure it to switch automatically based on the site you visit.
A very quick intro to git
Are you planning to join the GROMACS team and start coding? Then git and GitLab will become your most important and favourite tools. GitLab has excellent documentation, and the Atlassian tutorials are highly recommended as both an introduction to git and for further tips, tricks and explanations. For a detailed description of individual git commands, git-scm is a good resource, too.
Moreover, here is a quick cheat sheet of git commands that cover most of your needs in everyday life as a GROMACS coder:
COMMAND FUNCTION
# keep your local git up-to-date/in sync with the GitLab server
git pull origin main make sure your local version of main
is an up-to-date copy of the version
on the GROMACS GitLab server (remote)
git pull --rebase origin main rebase your current local branch on
the remote version of main
git rebase main rebase your current local branch on
your local version of main
# get an overview of the state of your local git
git status current state of your git
git log view the history of commits
git show double-check your most recent commit
git diff changes since the last commit,
can be used to compare branches
git branch overview of the branches in your git
# manage branches
git checkout change to an existing branch
git checkout -b create a new branch (Each GROMACS MR
corresponds to a new local branch.)
git branch -d <branch> delete a branch after merging it
git branch -D <branch> delete a branch that was not merged
(or for which git didn't notice it
was merged)
# save WIP
git stash save changes that cannot be staged
git stash apply recover changes saved by "git stash"
# create and upload commits
git add . stage changes in current branch
such that they can be committed
git commit -m "" commit changes (the commit message
will later be used as MR title)
git push origin <branch> upload your changes to the GROMACS
gitlab server
git push origin <branch> -f force-push, overwrites remote branch
(use carefully!)
# read Atlassian tutorial about git reset
git reset --mixed HEAD^ remove last commit, but keep the
changes you made (must be staged
again, though)
git reset --hard remove commits and don't save changes
(use carefully!)
# manage git settings
git config --global --edit open git-internal file storing your
mail address and user name,
uses nano as text editor
git config \
--global rerere.enabled true enable rerere ("reuse recorded
resolution") for git to remember the
resolution of merge conflicts
git config --list print list of git settings
COMBINATIONS:
# add new remote branch to your own git
$ git fetch origin
$ git checkout -b '<branch>' 'origin/<branch>'