Remote Editing

The most commonly used procedure to modify files that are located in the scicore cluster is to connect to the cluster via ssh and use an editor that is already installed in the software stack (Emacs, vim, nano, etc…). This works fine most of the time, but it has some drawbacks. Some editors have steep learning curves, may not be user-friendly, or may have problems with X11 tunneling.

For those reasons, sometimes users find it more suitable to move files down to their local computer, edit them on their editor of choice, and upload them again to the cluster. This procedure is also not free of problems. For example, the different encoding of Windows machines could be reinterpreted as strange characters in Linux.

A better alternative can be remote editing.

What is remote editing?

“Remote editing” refers to creating and modifying files that live on the cluster from an editor that runs on your local computer. Your editor connects over SSH to open files, save changes, and (optionally) run tools on the remote machine.

This is an alternative to using terminal editors installed on the cluster, such as Emacs, vim, or nano.

Why use remote editing?

In general, modern editors/IDEs are more powerful than those installed in the cluster by default. These advanced editors usually have a more comfortable GUI with tabs, mini-maps, outlines, and integrated terminals. They provide language servers with code completion, go-to-definition, and linting. They also have Git and debugging integrations, among many other capabilities.

Which editor should be used?

There are many options regarding modern editors. Two of the most used ones are Sublime and Visual Studio Code (VS Code). The first one is proprietary, hence not free. While the second one is a common choice for a free multi-platform editor.

Important

Some editors (notably VS Code with Remote-SSH), despite running the UI locally on the user’s desktop, also launch a server on the remote host (in this case, the scicore login node). This server is a Node.js process tree that spins up the VS Code server itself, language servers, file watchers, Git status polling, extension daemons, etc… When multiplied by several dozens of concurrent users, this consumes a lot of resources on the login node, becoming extremely detrimental for all users in general.

Therefore, running VSCode instances on the login node is forbidden and such processes will be automatically killed.

Info

To keep using VS Code as remote editor in the cluster, users must access the dedicated login node: vscode.scicore.unibas.ch

You can download VS code from https://code.visualstudio.com/.

Warning

VS Code is supposed to be installed on the user’s laptop/workstation. SciCORE doesn’t provide support for applications on these workstations. Please get in touch with ITS for support on these devices.

Method 1: Setting VS Code up as remote editor

Once installed, click on the Marketplace icon on the left pane to install the necessary extensions.

Search for the keyword remote in the search bar, and once the results show up, click on the button install of Remote-SSH and Remote Explorer. This will install those extensions locally on your copy of VS Code.

Info

Installing Remote-SSH might automatically trigger the installation of Remote Explorer and Remote-SSH: Editing Configuration Files. VS Code is clever enough to install dependencies and packages that are commonly used together.

A short video will show how Remote-SSH works:

After the plugin installation, click on the new Remote Explorer icon on the left pane.

Once you click on remote explorer, it will open a new pane. Right Click on SSH and click on New Remote. This will ask you to enter the ssh connection command. Use <username>@vscode.scicore.unibas.ch, with your scicore username.

Info

Note that you don’t need to add ssh to the command above. It is enough to put your login and the address of the server. Nevertheless, you could add ssh and any options you would like/need to use for accessing other servers. That might include X11 tunneling or using a specific SSH key.

This will ask you to save the config file. We recommend that you select the path under C:\Users\... for Windows, or the equivalent in other systems.

The server name (e.g. vscode.scicore.unibas.ch) will appear under SSH. Click on the arrow in front of the server to connect to the server. Now you have to enter the password for the given username to complete the connection.

Click in the Explorer icon (first one on the top left pane) to open a folder in the remote computer (this could be directly your home directory). After introducing your password again, you will see a file manager on the left pane where you can choose directories and files to work with in the editor.

Method 2: Local editing of remote files

This method allows you to edit remote files locally by mounting your remote directory as a network drive. It provides high flexibility, additional capabilities, and eliminates load on the login nodes caused by heavy editors (e.g., VS Code).

Advantages

• No stress on cluster login nodes.
• Compatible with any local editor.
• Fully benefits from local resources (CPU, GPU, AI-assisted tools, etc.).
• Simple file synchronization: changes are applied directly to the remote filesystem.
• Drag & Drop for moving files from/to remote folder.

How It Works

1. Mount a network drive pointing to your remote home (e.g., /scicore/home/...).
2. The mounted drive appears as a local directory on your computer.
3. Open and edit files with your preferred local editor.
4. All edits are automatically reflected on the remote system.

Limitations

The integrated terminal of your editor cannot execute commands on the remote host. As a result, part of the integrated development environment experience is lost. Some IDE features requiring direct SSH access (e.g., remote debugging, environment detection) may not work.

Recommendation

Use this method if you primarily need to edit code or documents and prefer your local development environment. Combine it with a separate SSH terminal session for command-line work on the cluster.

This method is an alternative that provides flexibility and additional capabilities, while placing zero load on the login nodes from editor activity. It is recommended for all users, especially those who rely on advanced editor features such as AI-assisted coding.