HPCwiki - User contributions [en]

SACCT

2026-04-14T05:33:28Z

Honfi001:

The command [http://slurm.schedmd.com/sacct.html sacct] is meant to show your usage of Anunna.

For instance at the login screen the command: sacct -a gives the following result:

<syntaxhighlight lang="bash">
user001@login200:~$ sacct -a
</syntaxhighlight>[[File:sacct capture.jpg]]

It is a standard view to see all the users jobs of that day.
Better is to modify this command with special parameters to see what you are using from Anunna.<syntaxhighlight lang="bash">
user001@login200:~$ sacct -P -X --delimiter=',' -S 2026-01-01 -E 2026-02-01 \
--format=comment%15,User,Partition%20,JobID,JobName,ncpus,nnodes,NodeList,Start,alloccpus,cputime%12,cputimeraw,state > usage_report_$(date -I).csv

</syntaxhighlight>The csv-file can be uploaded in Excel. This gives you the next overview.
Cputimeraw is the time of cpu-usage in seconds. The parameters "-S 2026-01-01 -E 2026-02-01" give you the start date and the end date of period you want to present.

[[File:sacct uitgebreid.jpg]]

SACCT

2026-04-14T05:32:15Z

Honfi001:

The command [http://slurm.schedmd.com/sacct.html sacct] is meant to show your usage of Anunna.

For instance at the login screen the command: sacct -a gives the following result:

'''[test001@nfs01 ~]$ sacct -a'''

[[File:sacct capture.jpg]]

It is a standard view to see all the users jobs of that day.
Better is to modify this command with special parameters to see what you are using from Anunna.<syntaxhighlight lang="bash">
user001@login200:~$ sacct -P -X --delimiter=',' -S 2026-01-01 -E 2026-02-01 \
--format=comment%15,User,Partition%20,JobID,JobName,ncpus,nnodes,NodeList,Start,alloccpus,cputime%12,cputimeraw,state > usage_report_$(date -I).csv

</syntaxhighlight>The csv-file can be uploaded in Excel. This gives you the next overview.
Cputimeraw is the time of cpu-usage in seconds. The parameters "-S 2026-01-01 -E 2026-02-01" give you the start date and the end date of period you want to present.

[[File:sacct uitgebreid.jpg]]

Tutorials

2026-03-25T10:37:06Z

Honfi001: /* Apptainer */

== Tutorials ==

=== Modules ===
[[Create Your Own Modules]]

=== Apptainer ===

* [[Tutorials/Apptainer-Introduction|Introduction]]
* [[Tutorials/Apptainer-PullingImages|Pulling Images]]
* [[Tutorials/Apptainer-FakerootAndOverlays|Fakeroot and overlays]]
* [[Tutorials/Apptainer-FakerootAndSandbox|Fakeroot and sandbox]]
* [[Tutorials/Apptainer-DefinitionFiles|Definition Files]]
* [[Tutorials/Apptainer-GPUs|GPUs]]

Tutorials

2026-03-25T10:36:07Z

Honfi001:

== Tutorials ==

=== Modules ===
[[Create Your Own Modules]]

=== Apptainer ===

* Introduction
* [[Tutorials/Apptainer-PullingImages|Pulling Images]]
* [[Tutorials/Apptainer-FakerootAndOverlays|Fakeroot and overlays]]
* [[Tutorials/Apptainer-FakerootAndSandbox|Fakeroot and sandbox]]
* [[Tutorials/Apptainer-DefinitionFiles|Definition Files]]
* [[Tutorials/Apptainer-GPUs|GPUs]]

Tutorials/Apptainer-GPUs

2026-03-25T10:33:38Z

Honfi001:

= Running Apptainer with GPUs =

Apptainer can pass through GPU hardware from the host into a container, allowing you to run GPU-accelerated workloads (such as deep learning inference or training) inside a fully contained environment. This page covers how to use both NVIDIA and AMD GPUs on the Anunna cluster.

'''Important:''' Before you begin, make sure the following are in place:

* Your <code>.sif</code> image files should be stored on '''Lustre''' (e.g. in your scratch space), not in your home directory.
* Set your Apptainer cache to Lustre, since these images can get quite large:

<syntaxhighlight lang="bash">
export APPTAINER_CACHEDIR=$myScratch/Apptainer
</syntaxhighlight>

== How GPU Passthrough Works ==

Apptainer does not include GPU drivers inside the container. Instead, it '''binds''' the GPU drivers and libraries from the host system into the container at runtime. This means:

* The container must include software built for the correct GPU framework (CUDA for NVIDIA, ROCm for AMD).
* The host must have the matching GPU drivers installed (which Anunna already has on the GPU nodes).
* You tell Apptainer to enable GPU access using a flag: <code>--nv</code> for NVIDIA or <code>--rocm</code> for AMD.

== NVIDIA GPUs (<code>gpu</code> partition) ==

To use NVIDIA GPUs, you need to:

# Request a node on the <code>gpu</code> partition.
# Use the <code>--nv</code> flag when running your container.

The <code>--nv</code> flag tells Apptainer to:
* Make the <code>/dev/nvidiaX</code> device entries available inside the container.
* Locate and bind the CUDA libraries from the host into the container.
* Set <code>LD_LIBRARY_PATH</code> so the container uses the host's GPU libraries.

=== Example: Transcribing Audio with Whisper (NVIDIA) ===

[https://github.com/openai/whisper OpenAI Whisper] is a speech recognition model that benefits greatly from GPU acceleration. Let's build a container that runs Whisper on an NVIDIA GPU.

==== The Definition File ====

Create a file called <code>whisper_nvidia.def</code>:

<syntaxhighlight lang="bash">Bootstrap: docker
From: pytorch/pytorch:2.6.0-cuda12.4-cudnn9-devel

%post
apt-get update
apt-get install -y ffmpeg git
pip install openai-whisper
apt-get clean

%environment
export LC_ALL=C

%runscript
exec whisper --device cuda"$@"

%help
Whisper speech recognition container (NVIDIA GPU).
Usage: apptainer run --nv whisper_nvidia.sif <audio_file> [options]</syntaxhighlight>

A quick walkthrough of what is happening here:

{| class="wikitable"
|-
! Section !! Purpose
|-
| <code>Bootstrap / From</code> || Uses the official PyTorch Docker image, which already includes Python, PyTorch, CUDA, and cuDNN.
|-
| <code>%post</code> || Installs <code>ffmpeg</code> (required by Whisper for audio decoding), <code>git</code>, and the Whisper package itself.
|-
| <code>%environment</code> || Sets the locale to avoid encoding warnings.
|-
| <code>%runscript</code> || Makes <code>whisper</code> the default command, passing through any arguments.
|-
| <code>%help</code> || Provides usage information (accessible via <code>apptainer run-help</code>).
|}

==== Building the Image ====

Request a compute node and build:

<syntaxhighlight lang="bash">
module reset
module load utilities Apptainer
apptainer build whisper_nvidia.sif whisper_nvidia.def
</syntaxhighlight>

==== Running Whisper ====

Once built, run Whisper on the sample audio file. First, request a GPU node:

<syntaxhighlight lang="bash">
srun --partition=gpu --gres=gpu:1 --pty bash
</syntaxhighlight>

Then load Apptainer and run:

<syntaxhighlight lang="bash">
module reset
module load utilities Apptainer
apptainer run --nv whisper_nvidia.sif /lustre/shared/hpcCourses/Whisper/audio.mp3 --model base
apptainer run --nv whisper_nvidia.sif /lustre/shared/hpcCourses/Whisper/audio.mp3 --model large

</syntaxhighlight>

The <code>--nv</code> flag is what makes the GPU visible to the container. Without it, PyTorch would not detect any CUDA devices and Whisper would fall back to CPU (much slower).

You can verify GPU access from inside the container with:

<syntaxhighlight lang="bash">
apptainer exec --nv whisper_nvidia.sif python -c "import torch; print(torch.cuda.is_available())"
</syntaxhighlight>

This should print <code>True</code>.

== AMD GPUs (<code>gpu_amd</code> partition) ==

To use AMD GPUs, you need to:

# Request a node on the <code>gpu_amd</code> partition.
# Use the <code>--rocm</code> flag when running your container.

The <code>--rocm</code> flag tells Apptainer to:
* Make the <code>/dev/dri/</code> and <code>/dev/kfd</code> device entries available inside the container.
* Locate and bind the ROCm libraries from the host into the container.
* Set <code>LD_LIBRARY_PATH</code> so the container uses the host's ROCm libraries.

=== Example: Transcribing Audio with Whisper (AMD) ===

The same Whisper workflow, but using an AMD GPU with the ROCm stack.

==== The Definition File ====

Create a file called <code>whisper_amd.def</code>:

<syntaxhighlight lang="bash">
Bootstrap: docker
From: rocm/pytorch:rocm7.2_ubuntu24.04_py3.13_pytorch_release_2.10.0

%post
apt-get update
apt-get install -y ffmpeg git
pip install openai-whisper
apt-get clean

%environment
export LC_ALL=C

%runscript
exec whisper --device cuda "$@"

%help
Whisper speech recognition container (AMD ROCm GPU).
Usage: apptainer run --rocm whisper_amd.sif <audio_file> [options] --model <model_size>
</syntaxhighlight>

The structure is identical to the NVIDIA version. The only difference is the base image: instead of <code>pytorch/pytorch</code> (which includes CUDA), we use <code>rocm/pytorch</code> (which includes ROCm). PyTorch's API is the same regardless of the backend — <code>torch.cuda.is_available()</code> returns <code>True</code> on ROCm as well, since ROCm maps onto the CUDA API.

==== Building the Image ====

<syntaxhighlight lang="bash">
module reset
module load utilities Apptainer
apptainer build whisper_amd.sif whisper_amd.def
</syntaxhighlight>

==== Running Whisper ====

Request an AMD GPU node:

<syntaxhighlight lang="bash">
srun --partition=gpu_amd --gres=gpu:1 --pty bash
</syntaxhighlight>

Then load Apptainer and run:

<syntaxhighlight lang="bash">module reset
module load utilities Apptainer
apptainer run --rocm whisper_amd.sif /lustre/shared/hpcCourses/Whisper/audio.mp3 --model base
apptainer run --rocm whisper_amd.sif /lustre/shared/hpcCourses/Whisper/audio.mp3 --model large </syntaxhighlight>

Note that even though we are on an AMD GPU, the <code>--device cuda</code> flag is correct. PyTorch's ROCm backend uses the same <code>cuda</code> device name for compatibility.

Verify GPU access:

<syntaxhighlight lang="bash">
apptainer exec --rocm whisper_amd.sif python -c "import torch; print(torch.cuda.is_available())"
</syntaxhighlight>

== Summary ==

{| class="wikitable"
|-
! !! NVIDIA !! AMD
|-
| '''Partition''' || <code>gpu</code> || <code>gpu_amd</code>
|-
| '''Apptainer flag''' || <code>--nv</code> || <code>--rocm</code>
|-
| '''Base image''' || <code>pytorch/pytorch</code> (includes CUDA) || <code>rocm/pytorch</code> (includes ROCm)
|-
| '''PyTorch device''' || <code>--device cuda</code> || <code>--device cuda</code> (same API)
|-
| '''Host devices bound''' || <code>/dev/nvidiaX</code> || <code>/dev/dri/</code>, <code>/dev/kfd</code>
|}

The key takeaway: the only things that change between NVIDIA and AMD are the '''base container image''', the '''Apptainer flag''', and the '''Slurm partition'''. Your application code stays the same.

Tutorials/Apptainer-GPUs

2026-03-25T09:42:06Z

Honfi001: Created page with "= Running Apptainer with GPUs = Apptainer can pass through GPU hardware from the host into a container, allowing you to run GPU-accelerated workloads (such as deep learning inference or training) inside a fully contained environment. This page covers how to use both NVIDIA and AMD GPUs on the Anunna cluster. '''Important:''' Before you begin, make sure the following are in place: * Your <code>.sif</code> image files should be stored on '''Lustre''' (e.g. in your scrat..."

= Running Apptainer with GPUs =

Apptainer can pass through GPU hardware from the host into a container, allowing you to run GPU-accelerated workloads (such as deep learning inference or training) inside a fully contained environment. This page covers how to use both NVIDIA and AMD GPUs on the Anunna cluster.

'''Important:''' Before you begin, make sure the following are in place:

* Your <code>.sif</code> image files should be stored on '''Lustre''' (e.g. in your scratch space), not in your home directory.
* Set your Apptainer cache to Lustre:

<syntaxhighlight lang="bash">
export APPTAINER_CACHEDIR=$myScratch/Apptainer
</syntaxhighlight>

== How GPU Passthrough Works ==

Apptainer does not include GPU drivers inside the container. Instead, it '''binds''' the GPU drivers and libraries from the host system into the container at runtime. This means:

* The container must include software built for the correct GPU framework (CUDA for NVIDIA, ROCm for AMD).
* The host must have the matching GPU drivers installed (which Anunna already has on the GPU nodes).
* You tell Apptainer to enable GPU access using a flag: <code>--nv</code> for NVIDIA or <code>--rocm</code> for AMD.

== NVIDIA GPUs (<code>gpu</code> partition) ==

To use NVIDIA GPUs, you need to:

# Request a node on the <code>gpu</code> partition.
# Use the <code>--nv</code> flag when running your container.

The <code>--nv</code> flag tells Apptainer to:
* Make the <code>/dev/nvidiaX</code> device entries available inside the container.
* Locate and bind the CUDA libraries from the host into the container.
* Set <code>LD_LIBRARY_PATH</code> so the container uses the host's GPU libraries.

=== Example: Transcribing Audio with Whisper (NVIDIA) ===

[https://github.com/openai/whisper OpenAI Whisper] is a speech recognition model that benefits greatly from GPU acceleration. Let's build a container that runs Whisper on an NVIDIA GPU.

==== The Definition File ====

Create a file called <code>whisper_nvidia.def</code>:

<syntaxhighlight lang="bash">
Bootstrap: docker
From: pytorch/pytorch:2.6.0-cuda12.4-cudnn9-devel

%post
apt-get update
apt-get install -y ffmpeg git
pip install openai-whisper
apt-get clean

%environment
export LC_ALL=C

%runscript
exec whisper "$@"

%help
Whisper speech recognition container (NVIDIA GPU).
Usage: apptainer run --nv whisper_nvidia.sif <audio_file> [options]
</syntaxhighlight>

A quick walkthrough of what is happening here:

{| class="wikitable"
|-
! Section !! Purpose
|-
| <code>Bootstrap / From</code> || Uses the official PyTorch Docker image, which already includes Python, PyTorch, CUDA, and cuDNN.
|-
| <code>%post</code> || Installs <code>ffmpeg</code> (required by Whisper for audio decoding), <code>git</code>, and the Whisper package itself.
|-
| <code>%environment</code> || Sets the locale to avoid encoding warnings.
|-
| <code>%runscript</code> || Makes <code>whisper</code> the default command, passing through any arguments.
|-
| <code>%help</code> || Provides usage information (accessible via <code>apptainer run-help</code>).
|}

==== Building the Image ====

Request a compute node and build:

<syntaxhighlight lang="bash">
module reset
module load utilities Apptainer
apptainer build whisper_nvidia.sif whisper_nvidia.def
</syntaxhighlight>

==== Running Whisper ====

Once built, run Whisper on the sample audio file. First, request a GPU node:

<syntaxhighlight lang="bash">
srun --partition=gpu --gres=gpu:1 --pty bash
</syntaxhighlight>

Then load Apptainer and run:

<syntaxhighlight lang="bash">
module reset
module load utilities Apptainer
apptainer run --nv whisper_nvidia.sif /lustre/shared/hpcCourses/Whisper/audio.mp3 --model base --device cuda
</syntaxhighlight>

The <code>--nv</code> flag is what makes the GPU visible to the container. Without it, PyTorch would not detect any CUDA devices and Whisper would fall back to CPU (much slower).

You can verify GPU access from inside the container with:

<syntaxhighlight lang="bash">
apptainer exec --nv whisper_nvidia.sif python -c "import torch; print(torch.cuda.is_available())"
</syntaxhighlight>

This should print <code>True</code>.

== AMD GPUs (<code>gpu_amd</code> partition) ==

To use AMD GPUs, you need to:

# Request a node on the <code>gpu_amd</code> partition.
# Use the <code>--rocm</code> flag when running your container.

The <code>--rocm</code> flag tells Apptainer to:
* Make the <code>/dev/dri/</code> and <code>/dev/kfd</code> device entries available inside the container.
* Locate and bind the ROCm libraries from the host into the container.
* Set <code>LD_LIBRARY_PATH</code> so the container uses the host's ROCm libraries.

=== Example: Transcribing Audio with Whisper (AMD) ===

The same Whisper workflow, but using an AMD GPU with the ROCm stack.

==== The Definition File ====

Create a file called <code>whisper_amd.def</code>:

<syntaxhighlight lang="bash">
Bootstrap: docker
From: rocm/pytorch:rocm6.2.4_ubuntu22.04_py3.10_pytorch_release_2.5.0

%post
apt-get update
apt-get install -y ffmpeg git
pip install openai-whisper
apt-get clean

%environment
export LC_ALL=C

%runscript
exec whisper "$@"

%help
Whisper speech recognition container (AMD ROCm GPU).
Usage: apptainer run --rocm whisper_amd.sif <audio_file> [options]
</syntaxhighlight>

The structure is identical to the NVIDIA version. The only difference is the base image: instead of <code>pytorch/pytorch</code> (which includes CUDA), we use <code>rocm/pytorch</code> (which includes ROCm). PyTorch's API is the same regardless of the backend — <code>torch.cuda.is_available()</code> returns <code>True</code> on ROCm as well, since ROCm maps onto the CUDA API.

==== Building the Image ====

<syntaxhighlight lang="bash">
module reset
module load utilities Apptainer
apptainer build whisper_amd.sif whisper_amd.def
</syntaxhighlight>

==== Running Whisper ====

Request an AMD GPU node:

<syntaxhighlight lang="bash">
srun --partition=gpu_amd --gres=gpu:1 --pty bash
</syntaxhighlight>

Then load Apptainer and run:

<syntaxhighlight lang="bash">
module reset
module load utilities Apptainer
apptainer run --rocm whisper_amd.sif /lustre/shared/hpcCourses/Whisper/audio.mp3 --model base --device cuda
</syntaxhighlight>

Note that even though we are on an AMD GPU, the <code>--device cuda</code> flag is correct. PyTorch's ROCm backend uses the same <code>cuda</code> device name for compatibility.

Verify GPU access:

<syntaxhighlight lang="bash">
apptainer exec --rocm whisper_amd.sif python -c "import torch; print(torch.cuda.is_available())"
</syntaxhighlight>

== Summary ==

{| class="wikitable"
|-
! !! NVIDIA !! AMD
|-
| '''Partition''' || <code>gpu</code> || <code>gpu_amd</code>
|-
| '''Apptainer flag''' || <code>--nv</code> || <code>--rocm</code>
|-
| '''Base image''' || <code>pytorch/pytorch</code> (includes CUDA) || <code>rocm/pytorch</code> (includes ROCm)
|-
| '''PyTorch device''' || <code>--device cuda</code> || <code>--device cuda</code> (same API)
|-
| '''Host devices bound''' || <code>/dev/nvidiaX</code> || <code>/dev/dri/</code>, <code>/dev/kfd</code>
|}

The key takeaway: the only things that change between NVIDIA and AMD are the '''base container image''', the '''Apptainer flag''', and the '''Slurm partition'''. Your application code stays the same.

Tutorials/Apptainer-Introduction

2026-03-25T09:23:54Z

Honfi001: /* apptainer pull */

= Introduction to Apptainer =

== What is Apptainer? ==

Apptainer (formerly known as Singularity) is a container platform designed for High Performance Computing (HPC) environments. If you have heard of Docker, Apptainer solves a similar problem — it lets you package an application together with all of its dependencies (libraries, tools, configuration) into a single portable unit called a '''container'''. The key difference is that Apptainer was built from the ground up to run safely on shared multi-user systems like HPC clusters, where Docker cannot be used because it requires root privileges that would pose a security risk.

Some important differences between Apptainer and Docker:

{| class="wikitable"
|-
! !! Apptainer !! Docker
|-
| '''Privileges''' || Runs as a normal user — no root access needed || Requires root or membership in the <code>docker</code> group, which is effectively root
|-
| '''Image format''' || Single portable <code>.sif</code> file || Layered images stored in a daemon's internal storage
|-
| '''Integration with host''' || Seamless access to host filesystems, GPUs, and network by default || Isolated by default; explicit configuration needed to share resources
|-
| '''Designed for''' || HPC, scientific computing, shared multi-user systems || Cloud, microservices, development environments
|-
| '''Docker compatibility''' || Can pull and run Docker images directly || N/A
|}

=== Why Apptainer for Research? ===

Two features make Apptainer particularly valuable for scientific work:

'''Portability:''' An Apptainer container is a single <code>.sif</code> file. You can build it on your laptop, copy it to the cluster, share it with a collaborator, or archive it alongside a publication. It will run the same way everywhere Apptainer is installed.

'''Reproducibility:''' A container captures the exact software environment used for an analysis — down to the specific library versions. This means an experiment can be repeated months or years later with the same environment, even if the host system has changed. When combined with a definition file (a text recipe that describes how the container was built), every step is documented and reproducible.

== Loading Apptainer ==

On the Anunna HPC cluster, Apptainer is available in the <code>utilities</code> module bucket. Load it with:

<syntaxhighlight lang="bash">
module reset
module load utilities
module load Apptainer
</syntaxhighlight>

You can verify it is loaded by running:

<syntaxhighlight lang="bash">
apptainer --version
</syntaxhighlight>

== Best Practices ==

=== Set Your Cache Directory ===

Apptainer downloads container layers to a local cache before building SIF files. By default this cache lives under your home directory (<code>$HOME/.apptainer/cache</code>), which can quickly exceed your home quota — especially with large images.

Change the cache location to your scratch space by setting the <code>APPTAINER_CACHEDIR</code> variable. You will need to create the directory first:

<syntaxhighlight lang="bash">
mkdir -p $myScratch/Apptainer
export APPTAINER_CACHEDIR=$myScratch/Apptainer
</syntaxhighlight>

Consider adding the <code>export</code> line to your <code>~/.bashrc</code> so it is set automatically in every session.

=== Do Not Run Apptainer on the Login Nodes ===

Building and running containers can be resource-intensive. Always request a compute node (e.g. via <code>srun</code>) before running Apptainer commands. The login nodes are shared and should not be used for heavy workloads.

=== Do Not Store Images in Your Home Directory ===

SIF files can easily be hundreds of megabytes or even several gigabytes in size. Store them on Lustre (e.g. in your scratch or project space) rather than in your home directory to avoid quota issues. Running images can be I/O intensive and this is not suitable for the home directory.

== Basic Commands ==

Apptainer has five core commands you will use regularly:

=== <code>apptainer pull</code> ===

Downloads a container image from a remote registry and saves it as a <code>.sif</code> file.

<syntaxhighlight lang="bash">
apptainer pull ubuntu.sif docker://ubuntu:18.04
</syntaxhighlight>

=== <code>apptainer build</code> ===

The build command is used for converting images from one format to another. It can create a SIF from a definition file, convert a sandbox to a SIF, or convert between formats.

<syntaxhighlight lang="bash">
# Build from a definition file
apptainer build myimage.sif myrecipe.def

# Convert a sandbox directory to a SIF
apptainer build myimage.sif /path/to/sandbox/
</syntaxhighlight>

=== <code>apptainer exec</code> ===

Runs a single specific command inside a container and returns the output.

<syntaxhighlight lang="bash">
apptainer exec ubuntu.sif cat /etc/os-release
</syntaxhighlight>

=== <code>apptainer shell</code> ===

Opens an interactive shell inside the container, allowing you to explore and run commands as if you had logged into a different machine.

<syntaxhighlight lang="bash">
apptainer shell ubuntu.sif
</syntaxhighlight>

=== <code>apptainer run</code> ===

Executes the container's default action (its '''runscript'''). What this does depends on how the container was built.

<syntaxhighlight lang="bash">
apptainer run myimage.sif
</syntaxhighlight>

=== At a Glance ===

{| class="wikitable"
|-
! Command !! Purpose
|-
| <code>apptainer pull</code> || Download an image from a registry
|-
| <code>apptainer build</code> || Build an image from a definition file or sandbox
|-
| <code>apptainer exec</code> || Run a single command inside a container
|-
| <code>apptainer shell</code> || Open an interactive shell inside a container
|-
| <code>apptainer run</code> || Run the container's default action
|}

Tutorials/Apptainer-Introduction

2026-03-25T09:18:12Z

Honfi001: Created page with "= Introduction to Apptainer = == What is Apptainer? == Apptainer (formerly known as Singularity) is a container platform designed for High Performance Computing (HPC) environments. If you have heard of Docker, Apptainer solves a similar problem — it lets you package an application together with all of its dependencies (libraries, tools, configuration) into a single portable unit called a '''container'''. The key difference is that Apptainer was built from the ground..."

= Introduction to Apptainer =

== What is Apptainer? ==

Apptainer (formerly known as Singularity) is a container platform designed for High Performance Computing (HPC) environments. If you have heard of Docker, Apptainer solves a similar problem — it lets you package an application together with all of its dependencies (libraries, tools, configuration) into a single portable unit called a '''container'''. The key difference is that Apptainer was built from the ground up to run safely on shared multi-user systems like HPC clusters, where Docker cannot be used because it requires root privileges that would pose a security risk.

Some important differences between Apptainer and Docker:

{| class="wikitable"
|-
! !! Apptainer !! Docker
|-
| '''Privileges''' || Runs as a normal user — no root access needed || Requires root or membership in the <code>docker</code> group, which is effectively root
|-
| '''Image format''' || Single portable <code>.sif</code> file || Layered images stored in a daemon's internal storage
|-
| '''Integration with host''' || Seamless access to host filesystems, GPUs, and network by default || Isolated by default; explicit configuration needed to share resources
|-
| '''Designed for''' || HPC, scientific computing, shared multi-user systems || Cloud, microservices, development environments
|-
| '''Docker compatibility''' || Can pull and run Docker images directly || N/A
|}

=== Why Apptainer for Research? ===

Two features make Apptainer particularly valuable for scientific work:

'''Portability:''' An Apptainer container is a single <code>.sif</code> file. You can build it on your laptop, copy it to the cluster, share it with a collaborator, or archive it alongside a publication. It will run the same way everywhere Apptainer is installed.

'''Reproducibility:''' A container captures the exact software environment used for an analysis — down to the specific library versions. This means an experiment can be repeated months or years later with the same results, even if the host system has changed. When combined with a definition file (a text recipe that describes how the container was built), every step is documented and reproducible.

== Loading Apptainer ==

On the Anunna HPC cluster, Apptainer is available in the <code>utilities</code> module bucket. Load it with:

<syntaxhighlight lang="bash">
module reset
module load utilities Apptainer
</syntaxhighlight>

You can verify it is loaded by running:

<syntaxhighlight lang="bash">
apptainer --version
</syntaxhighlight>

== Best Practices ==

=== Set Your Cache Directory ===

Apptainer downloads container layers to a local cache before building SIF files. By default this cache lives under your home directory (<code>$HOME/.apptainer/cache</code>), which can quickly exceed your home quota — especially with large images.

Change the cache location to your scratch space by setting the <code>APPTAINER_CACHEDIR</code> variable. You will need to create the directory first:

<syntaxhighlight lang="bash">
mkdir -p $myScratch/Apptainer
export APPTAINER_CACHEDIR=$myScratch/Apptainer
</syntaxhighlight>

Consider adding the <code>export</code> line to your <code>~/.bashrc</code> so it is set automatically in every session.

=== Do Not Run Apptainer on the Login Nodes ===

Building and running containers can be resource-intensive. Always request a compute node (e.g. via <code>srun</code>) before running Apptainer commands. The login nodes are shared and should not be used for heavy workloads.

=== Do Not Store Images in Your Home Directory ===

SIF files can easily be hundreds of megabytes or even several gigabytes in size. Store them on Lustre (e.g. in your scratch or project space) rather than in your home directory to avoid quota issues.

== Basic Commands ==

Apptainer has five core commands you will use regularly:

=== <code>apptainer pull</code> ===

Downloads a container image from a remote registry and saves it as a <code>.sif</code> file.

<syntaxhighlight lang="bash">
apptainer pull ubuntu.sif docker://ubuntu:24.04
</syntaxhighlight>

=== <code>apptainer build</code> ===

The build command is used for converting images from one format to another. It can create a SIF from a definition file, convert a sandbox to a SIF, or convert between formats.

<syntaxhighlight lang="bash">
# Build from a definition file
apptainer build myimage.sif myrecipe.def

# Convert a sandbox directory to a SIF
apptainer build myimage.sif /path/to/sandbox/
</syntaxhighlight>

=== <code>apptainer exec</code> ===

Runs a single specific command inside a container and returns the output.

<syntaxhighlight lang="bash">
apptainer exec ubuntu.sif cat /etc/os-release
</syntaxhighlight>

=== <code>apptainer shell</code> ===

Opens an interactive shell inside the container, allowing you to explore and run commands as if you had logged into a different machine.

<syntaxhighlight lang="bash">
apptainer shell ubuntu.sif
</syntaxhighlight>

=== <code>apptainer run</code> ===

Executes the container's default action (its '''runscript'''). What this does depends on how the container was built.

<syntaxhighlight lang="bash">
apptainer run myimage.sif
</syntaxhighlight>

=== At a Glance ===

{| class="wikitable"
|-
! Command !! Purpose
|-
| <code>apptainer pull</code> || Download an image from a registry
|-
| <code>apptainer build</code> || Build an image from a definition file or sandbox
|-
| <code>apptainer exec</code> || Run a single command inside a container
|-
| <code>apptainer shell</code> || Open an interactive shell inside a container
|-
| <code>apptainer run</code> || Run the container's default action
|}

Main Page

2026-03-25T06:56:50Z

Honfi001: Add tutorials section and edited the heading of the courses section

Anunna is a [http://en.wikipedia.org/wiki/High-performance_computing High Performance Computer] (HPC) infrastructure hosted by [https://www.wur.nl/en/show/supercomputer-anunna-opens-up-more-opportunities-for-data-storage-and-artificial-intelligence-applications.htm Wageningen University & Research Centre]. It is open for use for all WUR research groups as well as other organizations, including companies, that have collaborative projects with WUR.

= About =

* [[History of the Cluster|Historical information on the startup of Anunna]]

== Access Policy ==
[[Access_Policy | Main Article: Access Policy]]

Access needs to be granted actively (by creation of an account on the cluster by FB-IT). Use of resources is limited by the scheduler. Note that the use of Anunna is not free of charge.

= Our Courses and Tutorials =
The Anunna team organizes HPC courses three times a year to strengthen basic & more advanced skills and enable users to make the most effective use of our facility.

* [[Linux Basic]]
* [[HPC Basic]]
* [[HPC Advanced]]
* [[2026 Course dates]]
* [[Tutorials]]

= Using Anunna =
* [[Tariffs | Costs associated with resource usage]]

== Gaining access to Anunna==
Access to the cluster and file transfer are traditionally done via [http://en.wikipedia.org/wiki/Secure_Shell SSH and SFTP].
* [[log_in_to_B4F_cluster | Logging into cluster using ssh]]
* [[file_transfer | File transfer options]]
* [[Services | Alternative access methods, and extra features and services on Anunna]]
* [[Filesystems | Data storage methods on Anunna]]

== Using Anunna for courses (mainly jupyter notebooks) ==
* [[steps_for_courses | Steps involved to run a course on Anunna]]

= Events =

* [[Courses]] that have happened and are happening
* [[Downtime]] that will affect all users
* [[Meetings]] that may affect the policies of Anunna

= Software =
* [[Modules]]
* [[Apptainer]]
* [[Python]]
* [[R]]
* [[Julia]]

== Browser apps ==
This page provides an overview of the GUI-based applications available Anunna, including background information and practical guidance on how to access and use interactive desktops and graphical tools directly from your web browser.

* [[General overview|General Overview]]
* [[Anunna Shell Access]]
* [[Using the File browser|File Browser]]
* [[Jupyter|Featured Apps]]
* [[Jupyter]]
* [[RStudio|R Studio]]
* [[Linux desktop|Linux Desktop]]
* [[Requesting new software|Requesting New Software]]

== Command-line Software ==

==== Cluster Scheduler ====
Anunna uses Slurm as job scheduler.
* [[Using_Slurm | Submit jobs with Slurm]]
* [[node_usage_graph | Be aware of how much work the cluster is under right now with 'node_usage_graph']]
* [[SLURM_Compare | Rosetta Stone of Workload Managers]]

==== [[Globally installed software]] ====

==== [[ABGC_modules |ABGC specific modules]] ====

==== Installation of software by users ====
* [[Domain_specific_software_on_B4Fcluster_installation_by_users | Installing domain specific software: installation by users]]
* [[Setting local variables]]
* [[Installing_R_packages_locally | Installing R packages locally]]
* [[Setting_up_Python_virtualenv | Setting up and using a virtual environment for Python3 ]]
* [[Virtual_environment_Python_3.4_or_higher | Setting up and using a virtual environment for Python3.4 or higher ]]
* [[Installing WRF and WPS]]
* [[Running scripts on a fixed timeschedule (cron)]]

= Useful Notes =

== Being in control of Environment parameters ==

* [[Using_environment_modules | Using environment modules]]
* [[Aliases and local variables]]
* [[Setting local variables]]
* [[Setting_TMPDIR | Set a custom temporary directory location]]
* [[Installing_R_packages_locally | Installing R packages locally]]
* [[Setting_up_Python_virtualenv | Setting up and using a virtual environment for Python3 ]]
* [[Locale_settings]] (how numbers and dates are displayed)

== Controlling costs ==

* [[SACCT | using SACCT to see your costs]]
* [[get_my_bill | using the "get_my_bill" script to estimate costs]]

== Management ==
Product Owner of Anunna is Alexander van Ittersum (Wageningen UR,FB-IT, C&PS). [[User: prins089 | Fons Prinsen (Wageningen UR, FB-IT, C&PS)]] is responsible for [[Maintenance_and_Management | Maintenance and Management]] of the cluster.

* [[Roadmap | Ambitions regarding innovation, support and administration of Anunna ]]

= Miscellaneous =
* [[Bioinformatics_tips_tricks_workflows |Bioinformatics tips, tricks, and workflows]]
* [[Parallel_R_code_on_SLURM | Running parallel R code on SLURM]]
* [[Convert_between_MediaWiki_and_other_formats | Convert between MediaWiki format and other formats]]
* [[Manual GitLab | GitLab: Create projects and add scripts]]
* [[Monitoring_executions | Monitoring job execution]]
* [[Shared_folders | Working with shared folders in the Lustre file system]]
* [[Old_binaries | Running older binaries on the updated OS]]
* [[locale_settings | How to change language settings for yourself]]

= See also =
* [[Maintenance_and_Management | Maintenance and Management]]
* [[About_ABGC | About ABGC]]
* [[Computer_cluster | High Performance Computing @ABGC]]
* [[Lustre_PFS_layout | Lustre Parallel File System layout]]

= External links =
{| width="90%"
|- valign="top"
| width="30%" |
* [https://www.wur.nl/en/Value-Creation-Cooperation/Facilities/Wageningen-Shared-Research-Facilities/Our-facilities/Show/High-Performance-Computing-Cluster-HPC-Anunna.htm SRF offers a HPC facilty]
| width="30%" |
* [http://en.wikipedia.org/wiki/Scientific_Linux Scientific Linux]
* [http://en.wikipedia.org/wiki/Help:Cheatsheet Help with editing Wiki pages]
|}

Tutorials/Apptainer-FakerootAndOverlays

2026-03-25T06:54:45Z

Honfi001:

= Apptainer Overlays: Modifying Container Images =

'''Important:''' Before you begin, make sure the following are in place:

* You are running on a '''compute node''', not a login node. Request an interactive session first (e.g. via <code>srun</code> or your scheduler).
* Your <code>.sif</code> image files should be stored on '''Lustre''' (e.g. in your scratch space), not in your home directory. SIF files can be large and will eat through your home quota fast.
* Set your Apptainer cache to Lustre as well. Add this to your session (or your <code>.bashrc</code>):

<syntaxhighlight lang="bash">
export APPTAINER_CACHEDIR=$myScratch/apptainer_cache
</syntaxhighlight>

== Getting Started ==

Load the required modules:

<syntaxhighlight lang="bash">
module reset
module load utilities Apptainer
</syntaxhighlight>

== Pulling the Base Image ==

Let's pull an Ubuntu 24.04 image from Docker Hub:

<syntaxhighlight lang="bash">
apptainer pull ./ubuntu_24.04.sif docker://ubuntu:24.04
</syntaxhighlight>

This will download and convert the image into a SIF file in your current directory.

== The Problem: SIF Images Are Read-Only ==

Now let's try to update the package list inside the container:

<syntaxhighlight lang="bash">
apptainer exec ubuntu_24.04.sif apt update
</syntaxhighlight>

This will fail. You will see errors about not being able to write to package lists and lock files. This is because SIF files are '''read-only''' by design — you cannot modify them directly.

So how do we install software into a container? This is where '''overlays''' and '''fakeroot''' come in.

== What is fakeroot? ==

On an HPC system you do not have root (administrator) privileges. But many operations inside a container — like installing packages with <code>apt</code> — expect to be run as root.

The <code>--fakeroot</code> flag (or <code>-f</code>) tells Apptainer to make it ''look like'' you are running as root inside the container, even though you are not actually root on the host system. This is enough to trick package managers like <code>apt</code> into working.

== What is an Overlay? ==

An overlay is a writable layer that sits on top of a read-only SIF image. Think of it like putting a sheet of tracing paper over a printed page — you can write on the tracing paper without changing the original page underneath.

Any changes you make (installed packages, new files, config changes) are stored in the overlay, leaving the original SIF image untouched.

== Creating and Using an Overlay ==

Let's create a temporary directory to use as our overlay:

<syntaxhighlight lang="bash">
ov=$(mktemp -d)
</syntaxhighlight>

This creates a temporary directory somewhere under <code>/tmp</code> and stores the path in the variable <code>$ov</code>.

Now let's try that <code>apt update</code> again, this time with <code>--fakeroot</code> and <code>--overlay</code>:

<syntaxhighlight lang="bash">
apptainer exec --fakeroot --overlay $ov ubuntu_24.04.sif apt update
</syntaxhighlight>

This time it should work. Apptainer is running you as fake root, and any writes are going into the overlay directory instead of trying to modify the read-only SIF.

== Installing Software via the Overlay ==

Now let's install <code>neofetch</code> (a tool that displays system information) into the container through the overlay:

<syntaxhighlight lang="bash">
apptainer exec --fakeroot --overlay $ov ubuntu_24.04.sif apt install -y neofetch
</syntaxhighlight>

The <code>-y</code> flag tells <code>apt</code> to answer "yes" to all prompts automatically.

Once this completes, neofetch is installed — but only in the overlay. The original <code>ubuntu_24.04.sif</code> is still untouched.

The takeaway tis that the an overlay enables a read-only image to be "modified" at runtime. This enables the use of applications that dowlooad data, e.g. databases at runtime.

== Cleaning Up ==

Don't forget to remove the temporary overlay directory when you're done:

<syntaxhighlight lang="bash">
rm -rf $ov
</syntaxhighlight>

== Summary ==

{| class="wikitable"
|-
! Step !! Command
|-
| Pull base image || <code>apptainer pull ./ubuntu_24.04.sif docker://ubuntu:24.04</code>
|-
| Create overlay directory || <code>ov=$(mktemp -d)</code>
|-
| Update packages (with overlay + fakeroot) || <code>apptainer exec --fakeroot --overlay $ov ubuntu_24.04.sif apt update</code>
|-
| Install software || <code>apptainer exec --fakeroot --overlay $ov ubuntu_24.04.sif apt install -y neofetch</code>
|-
| Clean up overlay || <code>rm -rf $ov</code>
|}

Tutorials

2026-03-12T13:18:36Z

Honfi001:

== Tutorials ==

=== Modules ===
[[Create Your Own Modules]]

=== Apptainer ===

* [[Tutorials/Apptainer-PullingImages|Pulling Images]]
* [[Tutorials/Apptainer-FakerootAndOverlays|Fakeroot and overlays]]
* [[Tutorials/Apptainer-FakerootAndSandbox|Fakeroot and sandbox]]
* [[Tutorials/Apptainer-DefinitionFiles|Definition Files]]

Tutorials/Apptainer-DefinitionFiles

2026-03-12T12:32:44Z

Honfi001: Created page with "= Apptainer Definition Files: Building Containers from a Recipe = '''Important:''' Before you begin, make sure the following are in place: * You are running on a '''compute node''', not a login node. Request an interactive session first (e.g. via <code>srun</code> or your scheduler). * Your <code>.sif</code> image files should be stored on '''Lustre''' (e.g. in your scratch space), not in your home directory. SIF files can be large and will eat through your home quota..."

= Apptainer Definition Files: Building Containers from a Recipe =

'''Important:''' Before you begin, make sure the following are in place:

* You are running on a '''compute node''', not a login node. Request an interactive session first (e.g. via <code>srun</code> or your scheduler).
* Your <code>.sif</code> image files should be stored on '''Lustre''' (e.g. in your scratch space), not in your home directory. SIF files can be large and will eat through your home quota fast.
* Set your Apptainer cache to Lustre as well. Add this to your session (or your <code>.bashrc</code>):

<syntaxhighlight lang="bash">
export APPTAINER_CACHEDIR=$myScratch/apptainer_cache
</syntaxhighlight>

== Getting Started ==

Load the required modules:

<syntaxhighlight lang="bash">
module reset
module load utilities Apptainer
</syntaxhighlight>

== What is a Definition File? ==

In the previous tutorials we modified containers by hand — either through overlays or by entering a sandbox and running commands interactively. That works, but it has a problem: if someone else (or future you) wants to know exactly what was changed, there is no record of the steps taken.

A '''definition file''' (sometimes called a "def file" or "recipe") solves this. It is a plain text file that describes, step by step, how to build a container from scratch. Think of it like a cooking recipe: it lists the base ingredients and every instruction needed to produce the final result. Anyone with the same definition file can reproduce the exact same container.

== The Definition File ==

Create a file called <code>cowsay.def</code> with the following contents:

<syntaxhighlight lang="bash">
Bootstrap: docker
From: ubuntu:24.04

%post
apt-get update
apt-get install -y cowsay fortune-mod
apt-get clean

%environment
export PATH=/usr/games:${PATH}

%runscript
fortune | cowsay
exec "$@"
</syntaxhighlight>

Let's walk through each section.

=== <code>Bootstrap</code> and <code>From</code> (the Header) ===

<syntaxhighlight lang="bash">
Bootstrap: docker
From: ubuntu:24.04
</syntaxhighlight>

The header tells Apptainer where to get the base image to start from. <code>Bootstrap: docker</code> means we are pulling from a Docker/OCI registry, and <code>From: ubuntu:24.04</code> specifies which image. This is equivalent to the <code>apptainer pull docker://ubuntu:24.04</code> command we used in the earlier tutorials.

=== <code>%post</code> ===

<syntaxhighlight lang="bash">
%post
apt-get update
apt-get install -y cowsay fortune-mod
apt-get clean
</syntaxhighlight>

The <code>%post</code> section contains commands that run '''inside the container at build time''', as root. This is where you install software, download data, compile code, or make any other modifications to the container's filesystem. It is the equivalent of what we did interactively inside the sandbox shell.

=== <code>%environment</code> ===

<syntaxhighlight lang="bash">
%environment
export PATH=/usr/games:${PATH}
</syntaxhighlight>

The <code>%environment</code> section defines environment variables that are set every time the container runs. Here we add <code>/usr/games</code> to the PATH so that <code>cowsay</code> and <code>fortune</code> can be found. This replaces the manual <code>echo</code> to <code>90-environment.sh</code> that we did in the sandbox tutorial.

=== <code>%runscript</code> ===

<syntaxhighlight lang="bash">
%runscript
fortune | cowsay
exec "$@"
</syntaxhighlight>

The <code>%runscript</code> section defines the default action when someone uses <code>apptainer run</code> on the container. This replaces the manual edit we made to the runscript file in the sandbox tutorial. The <code>exec "$@"</code> line at the end allows the container to accept additional arguments if needed.

== Building the Image ==

With the definition file in place, build the SIF image:

<syntaxhighlight lang="bash">
apptainer build cowsay.sif cowsay.def
</syntaxhighlight>

Apptainer will pull the base Ubuntu image, run the <code>%post</code> commands to install the software, set up the environment and runscript, and package everything into <code>cowsay.sif</code>.

== Running It ==

<syntaxhighlight lang="bash">
apptainer run cowsay.sif
</syntaxhighlight>

You should see a random fortune inside a cow speech bubble:

<syntaxhighlight lang="text">
________________________________________
/ You will be awarded some great honor. \
\ /
----------------------------------------
\ ^__^
\ (oo)\_______
(__)\ )\/\
||----w |
|| ||
</syntaxhighlight>

The same result as the sandbox tutorial — but this time, every step is documented in a single file that anyone can inspect and reproduce.

== Summary ==

{| class="wikitable"
|-
! Step !! Command
|-
| Create the definition file || Write <code>cowsay.def</code> (see above)
|-
| Build the image || <code>apptainer build cowsay.sif cowsay.def</code>
|-
| Run it || <code>apptainer run cowsay.sif</code>
|}

=== Definition File Sections at a Glance ===

{| class="wikitable"
|-
! Section !! Purpose
|-
| <code>Bootstrap</code> / <code>From</code> || Where to get the base image (the starting point)
|-
| <code>%post</code> || Commands to run inside the container at build time (install software, configure things)
|-
| <code>%environment</code> || Environment variables set every time the container runs
|-
| <code>%runscript</code> || The default command executed by <code>apptainer run</code>
|}

Tutorials/Apptainer-FakerootAndSandbox

2026-03-12T12:22:43Z

Honfi001: Created page with "= Apptainer Sandbox: Modifying Containers Interactively = '''Important:''' Before you begin, make sure the following are in place: * You are running on a '''compute node''', not a login node. Request an interactive session first (e.g. via <code>srun</code> or your scheduler). * Your <code>.sif</code> image files should be stored on '''Lustre''' (e.g. in your scratch space), not in your home directory. SIF files can be large and will eat through your home quota fast. *..."

= Apptainer Sandbox: Modifying Containers Interactively =

'''Important:''' Before you begin, make sure the following are in place:

* You are running on a '''compute node''', not a login node. Request an interactive session first (e.g. via <code>srun</code> or your scheduler).
* Your <code>.sif</code> image files should be stored on '''Lustre''' (e.g. in your scratch space), not in your home directory. SIF files can be large and will eat through your home quota fast.
* Set your Apptainer cache to Lustre as well. Add this to your session (or your <code>.bashrc</code>):

<syntaxhighlight lang="bash">
export APPTAINER_CACHEDIR=$myScratch/apptainer_cache
</syntaxhighlight>

== Getting Started ==

Load the required modules:

<syntaxhighlight lang="bash">
module reset
module load utilities Apptainer
</syntaxhighlight>

== What is a Sandbox? ==

In the previous tutorial we used overlays to make changes on top of a read-only SIF image. Another approach is to convert the image into a '''sandbox''' — a regular directory on disk that contains the full filesystem of the container. Because it is just a directory, you can write to it directly.

This makes it easy to interactively install software, edit config files, and generally tinker with the container before converting it back into a portable SIF file.

== Pulling as a Sandbox ==

First, create a temporary directory and pull the Ubuntu 24.04 image directly as a sandbox:

<syntaxhighlight lang="bash">
sandbox=$(mktemp -d)
apptainer pull $sandbox/ubuntu --sandbox docker://ubuntu:24.04
</syntaxhighlight>

Instead of producing a single <code>.sif</code> file, this creates a directory at <code>$sandbox/ubuntu</code> that contains the entire container filesystem. You can <code>ls</code> it to see the familiar Linux directory structure:

<syntaxhighlight lang="bash">
ls $sandbox/ubuntu
</syntaxhighlight>

You should see directories like <code>bin</code>, <code>etc</code>, <code>usr</code>, <code>var</code>, and so on — just like a normal Linux root filesystem.

== Entering the Sandbox ==

Now let's open an interactive shell inside the sandbox:

<syntaxhighlight lang="bash">
apptainer shell --containall --writable --fakeroot $sandbox/ubuntu
</syntaxhighlight>

We are using three flags here, each doing something important:

{| class="wikitable"
|-
! Flag !! What it does
|-
| <code>--containall</code> (or <code>-C</code>) || Fully isolates the container from the host system. Your home directory, host environment variables, and host filesystems are '''not''' mounted into the container. This gives you a clean environment.
|-
| <code>--writable</code> (or <code>-w</code>) || Allows you to make changes to the container's filesystem. Without this flag, even a sandbox would be mounted read-only.
|-
| <code>--fakeroot</code> (or <code>-f</code>) || Makes it look like you are running as root inside the container. This is needed because package managers like <code>apt</code> expect root privileges to install software.
|}

Your prompt should change to <code>Apptainer></code>, indicating you are now inside the container.

== Installing Software ==

From inside the container, update the package lists and install <code>nano</code>, <code>cowsay</code> and <code>fortune-mod</code>:

<syntaxhighlight lang="bash">
Apptainer> apt-get update
Apptainer> apt-get install -y nano cowsay fortune-mod
</syntaxhighlight>

Once the installation finishes, clean up the apt cache to keep the image small:

<syntaxhighlight lang="bash">
Apptainer> apt-get clean
</syntaxhighlight>

== Fixing the PATH ==

In Ubuntu, <code>cowsay</code> and <code>fortune</code> are installed into <code>/usr/games/</code>, which is '''not''' in the default PATH for non-interactive shells. If we were to build a SIF from this sandbox right now, running <code>fortune</code> or <code>cowsay</code> would fail with a "command not found" error.

We need to add <code>/usr/games</code> to the container's PATH. Apptainer reads environment settings from files in <code>/.singularity.d/env/</code>. Run this command inside the container:

<syntaxhighlight lang="bash">
Apptainer> echo 'export PATH=/usr/games:${PATH}' >> /.singularity.d/env/90-environment.sh
</syntaxhighlight>

This appends a line to the environment script that ensures <code>/usr/games</code> is on the PATH every time the container runs.

== Editing the Runscript ==

The '''runscript''' is the command that gets executed when you use <code>apptainer run</code> on the container. It lives at <code>/.singularity.d/runscript</code>. Let's edit it so that our container does something fun by default.

Open the runscript with nano:

<syntaxhighlight lang="bash">
Apptainer> nano /.singularity.d/runscript
</syntaxhighlight>

You should see something like:

<syntaxhighlight lang="bash">
#!/bin/sh
OCI_ENTRYPOINT=''
# ...various lines...
exec "$@"
</syntaxhighlight>

Add <code>fortune | cowsay</code> on the line just '''above''' the final <code>exec "$@"</code>, so the end of the file looks like this:

<syntaxhighlight lang="bash">
fortune | cowsay
exec "$@"
</syntaxhighlight>

Save and exit nano (<code>Ctrl+O</code>, <code>Enter</code>, <code>Ctrl+X</code>).

Now exit the container:

<syntaxhighlight lang="bash">
Apptainer> exit
</syntaxhighlight>

== Building the Final SIF Image ==

Convert the sandbox back into a portable SIF file:

<syntaxhighlight lang="bash">
apptainer build fortune.sif $sandbox/ubuntu
</syntaxhighlight>

This compresses the entire sandbox directory into a single <code>fortune.sif</code> file.

== Running It ==

Now for the moment of truth:

<syntaxhighlight lang="bash">
apptainer run fortune.sif
</syntaxhighlight>

You should see a random fortune displayed inside a speech bubble from a friendly cow. Something like:

<syntaxhighlight lang="text">
________________________________________
/ You will be awarded some great honor. \
\ /
----------------------------------------
\ ^__^
\ (oo)\_______
(__)\ )\/\
||----w |
|| ||
</syntaxhighlight>

Every time you run it, you get a different fortune.

== Cleaning Up ==

Remove the temporary sandbox directory:

<syntaxhighlight lang="bash">
rm -rf $sandbox
</syntaxhighlight>

== Summary ==

{| class="wikitable"
|-
! Step !! Command
|-
| Create temp directory || <code>sandbox=$(mktemp -d)</code>
|-
| Pull as sandbox || <code>apptainer pull $sandbox/ubuntu --sandbox docker://ubuntu:24.04</code>
|-
| Enter sandbox || <code>apptainer shell --containall --writable --fakeroot $sandbox/ubuntu</code>
|-
| Install software || <code>apt-get update && apt-get install -y nano cowsay fortune-mod && apt-get clean</code>
|-
| Fix PATH || <code>echo 'export PATH=/usr/games:${PATH}' >> /.singularity.d/env/90-environment.sh</code>
|-
| Edit runscript || <code>nano /.singularity.d/runscript</code>
|-
| Exit container || <code>exit</code>
|-
| Build SIF from sandbox || <code>apptainer build fortune.sif $sandbox/ubuntu</code>
|-
| Run it || <code>apptainer run fortune.sif</code>
|-
| Clean up || <code>rm -rf $sandbox</code>
|}

Tutorials/Apptainer-FakerootAndOverlays

2026-03-12T10:00:23Z

Honfi001: /* What is --fakeroot? */

= Apptainer Overlays: Modifying Container Images =

'''Important:''' Before you begin, make sure the following are in place:

* You are running on a '''compute node''', not a login node. Request an interactive session first (e.g. via <code>srun</code> or your scheduler).
* Your <code>.sif</code> image files should be stored on '''Lustre''' (e.g. in your scratch space), not in your home directory. SIF files can be large and will eat through your home quota fast.
* Set your Apptainer cache to Lustre as well. Add this to your session (or your <code>.bashrc</code>):

<syntaxhighlight lang="bash">
export APPTAINER_CACHEDIR=$myScratch/apptainer_cache
</syntaxhighlight>

== Getting Started ==

Load the required modules:

<syntaxhighlight lang="bash">
module reset
module load utilities Apptainer
</syntaxhighlight>

== Pulling the Base Image ==

Let's pull an Ubuntu 24.04 image from Docker Hub:

<syntaxhighlight lang="bash">
apptainer pull ./ubuntu_24.04.sif docker://ubuntu:24.04
</syntaxhighlight>

This will download and convert the image into a SIF file in your current directory.

== The Problem: SIF Images Are Read-Only ==

Now let's try to update the package list inside the container:

<syntaxhighlight lang="bash">
apptainer exec ubuntu_24.04.sif apt update
</syntaxhighlight>

This will fail. You will see errors about not being able to write to package lists and lock files. This is because SIF files are '''read-only''' by design — you cannot modify them directly.

So how do we install software into a container? This is where '''overlays''' and '''fakeroot''' come in.

== What is fakeroot? ==

On an HPC system you do not have root (administrator) privileges. But many operations inside a container — like installing packages with <code>apt</code> — expect to be run as root.

The <code>--fakeroot</code> flag (or <code>-f</code>) tells Apptainer to make it ''look like'' you are running as root inside the container, even though you are not actually root on the host system. This is enough to trick package managers like <code>apt</code> into working.

== What is an Overlay? ==

An overlay is a writable layer that sits on top of a read-only SIF image. Think of it like putting a sheet of tracing paper over a printed page — you can write on the tracing paper without changing the original page underneath.

Any changes you make (installed packages, new files, config changes) are stored in the overlay, leaving the original SIF image untouched.

== Creating and Using an Overlay ==

Let's create a temporary directory to use as our overlay:

<syntaxhighlight lang="bash">
ov=$(mktemp -d)
</syntaxhighlight>

This creates a temporary directory somewhere under <code>/tmp</code> and stores the path in the variable <code>$ov</code>.

Now let's try that <code>apt update</code> again, this time with <code>--fakeroot</code> and <code>--overlay</code>:

<syntaxhighlight lang="bash">
apptainer exec --fakeroot --overlay $ov ubuntu_24.04.sif apt update
</syntaxhighlight>

This time it should work. Apptainer is running you as fake root, and any writes are going into the overlay directory instead of trying to modify the read-only SIF.

== Installing Software via the Overlay ==

Now let's install <code>neofetch</code> (a tool that displays system information) into the container through the overlay:

<syntaxhighlight lang="bash">
apptainer exec --fakeroot --overlay $ov ubuntu_24.04.sif apt install -y neofetch
</syntaxhighlight>

The <code>-y</code> flag tells <code>apt</code> to answer "yes" to all prompts automatically.

Once this completes, neofetch is installed — but only in the overlay. The original <code>ubuntu_24.04.sif</code> is still untouched.

== Building a New Image from the Original + Overlay ==

Right now your changes only exist in that temporary overlay directory. If you were to delete it or reboot, those changes would be gone. To make your modifications permanent, you can build a new SIF image that bakes in the overlay changes:

<syntaxhighlight lang="bash">
apptainer build --fakeroot ubuntu_neofetch.sif --overlay $ov ubuntu_24.04.sif
</syntaxhighlight>

This takes the original <code>ubuntu_24.04.sif</code>, applies everything in the overlay on top of it, and produces a brand new file: <code>ubuntu_neofetch.sif</code>.

== Testing the New Image ==

Let's verify that neofetch is available in our new image:

<syntaxhighlight lang="bash">
apptainer exec ubuntu_neofetch.sif neofetch
</syntaxhighlight>

You should see the familiar Ubuntu logo and system information output. Neofetch is now permanently part of this new image — no overlay or fakeroot needed to run it.

== Cleaning Up ==

Don't forget to remove the temporary overlay directory when you're done:

<syntaxhighlight lang="bash">
rm -rf $ov
</syntaxhighlight>

== Summary ==

{| class="wikitable"
|-
! Step !! Command
|-
| Pull base image || <code>apptainer pull ./ubuntu_24.04.sif docker://ubuntu:24.04</code>
|-
| Create overlay directory || <code>ov=$(mktemp -d)</code>
|-
| Update packages (with overlay + fakeroot) || <code>apptainer exec --fakeroot --overlay $ov ubuntu_24.04.sif apt update</code>
|-
| Install software || <code>apptainer exec --fakeroot --overlay $ov ubuntu_24.04.sif apt install -y neofetch</code>
|-
| Build new image from original + overlay || <code>apptainer build --fakeroot ubuntu_neofetch.sif --overlay $ov ubuntu_24.04.sif</code>
|-
| Test the new image || <code>apptainer exec ubuntu_neofetch.sif neofetch</code>
|-
| Clean up overlay || <code>rm -rf $ov</code>
|}

Tutorials/Apptainer-FakerootAndOverlays

2026-03-12T09:59:42Z

Honfi001: Created page with "= Apptainer Overlays: Modifying Container Images = '''Important:''' Before you begin, make sure the following are in place: * You are running on a '''compute node''', not a login node. Request an interactive session first (e.g. via <code>srun</code> or your scheduler). * Your <code>.sif</code> image files should be stored on '''Lustre''' (e.g. in your scratch space), not in your home directory. SIF files can be large and will eat through your home quota fast. * Set you..."

= Apptainer Overlays: Modifying Container Images =

'''Important:''' Before you begin, make sure the following are in place:

* You are running on a '''compute node''', not a login node. Request an interactive session first (e.g. via <code>srun</code> or your scheduler).
* Your <code>.sif</code> image files should be stored on '''Lustre''' (e.g. in your scratch space), not in your home directory. SIF files can be large and will eat through your home quota fast.
* Set your Apptainer cache to Lustre as well. Add this to your session (or your <code>.bashrc</code>):

<syntaxhighlight lang="bash">
export APPTAINER_CACHEDIR=$myScratch/apptainer_cache
</syntaxhighlight>

== Getting Started ==

Load the required modules:

<syntaxhighlight lang="bash">
module reset
module load utilities Apptainer
</syntaxhighlight>

== Pulling the Base Image ==

Let's pull an Ubuntu 24.04 image from Docker Hub:

<syntaxhighlight lang="bash">
apptainer pull ./ubuntu_24.04.sif docker://ubuntu:24.04
</syntaxhighlight>

This will download and convert the image into a SIF file in your current directory.

== The Problem: SIF Images Are Read-Only ==

Now let's try to update the package list inside the container:

<syntaxhighlight lang="bash">
apptainer exec ubuntu_24.04.sif apt update
</syntaxhighlight>

This will fail. You will see errors about not being able to write to package lists and lock files. This is because SIF files are '''read-only''' by design — you cannot modify them directly.

So how do we install software into a container? This is where '''overlays''' and '''fakeroot''' come in.

== What is <code>--fakeroot</code>? ==

On an HPC system you do not have root (administrator) privileges. But many operations inside a container — like installing packages with <code>apt</code> — expect to be run as root.

The <code>--fakeroot</code> flag (or <code>-f</code>) tells Apptainer to make it ''look like'' you are running as root inside the container, even though you are not actually root on the host system. This is enough to trick package managers like <code>apt</code> into working.

== What is an Overlay? ==

An overlay is a writable layer that sits on top of a read-only SIF image. Think of it like putting a sheet of tracing paper over a printed page — you can write on the tracing paper without changing the original page underneath.

Any changes you make (installed packages, new files, config changes) are stored in the overlay, leaving the original SIF image untouched.

== Creating and Using an Overlay ==

Let's create a temporary directory to use as our overlay:

<syntaxhighlight lang="bash">
ov=$(mktemp -d)
</syntaxhighlight>

This creates a temporary directory somewhere under <code>/tmp</code> and stores the path in the variable <code>$ov</code>.

Now let's try that <code>apt update</code> again, this time with <code>--fakeroot</code> and <code>--overlay</code>:

<syntaxhighlight lang="bash">
apptainer exec --fakeroot --overlay $ov ubuntu_24.04.sif apt update
</syntaxhighlight>

This time it should work. Apptainer is running you as fake root, and any writes are going into the overlay directory instead of trying to modify the read-only SIF.

== Installing Software via the Overlay ==

Now let's install <code>neofetch</code> (a tool that displays system information) into the container through the overlay:

<syntaxhighlight lang="bash">
apptainer exec --fakeroot --overlay $ov ubuntu_24.04.sif apt install -y neofetch
</syntaxhighlight>

The <code>-y</code> flag tells <code>apt</code> to answer "yes" to all prompts automatically.

Once this completes, neofetch is installed — but only in the overlay. The original <code>ubuntu_24.04.sif</code> is still untouched.

== Building a New Image from the Original + Overlay ==

Right now your changes only exist in that temporary overlay directory. If you were to delete it or reboot, those changes would be gone. To make your modifications permanent, you can build a new SIF image that bakes in the overlay changes:

<syntaxhighlight lang="bash">
apptainer build --fakeroot ubuntu_neofetch.sif --overlay $ov ubuntu_24.04.sif
</syntaxhighlight>

This takes the original <code>ubuntu_24.04.sif</code>, applies everything in the overlay on top of it, and produces a brand new file: <code>ubuntu_neofetch.sif</code>.

== Testing the New Image ==

Let's verify that neofetch is available in our new image:

<syntaxhighlight lang="bash">
apptainer exec ubuntu_neofetch.sif neofetch
</syntaxhighlight>

You should see the familiar Ubuntu logo and system information output. Neofetch is now permanently part of this new image — no overlay or fakeroot needed to run it.

== Cleaning Up ==

Don't forget to remove the temporary overlay directory when you're done:

<syntaxhighlight lang="bash">
rm -rf $ov
</syntaxhighlight>

== Summary ==

{| class="wikitable"
|-
! Step !! Command
|-
| Pull base image || <code>apptainer pull ./ubuntu_24.04.sif docker://ubuntu:24.04</code>
|-
| Create overlay directory || <code>ov=$(mktemp -d)</code>
|-
| Update packages (with overlay + fakeroot) || <code>apptainer exec --fakeroot --overlay $ov ubuntu_24.04.sif apt update</code>
|-
| Install software || <code>apptainer exec --fakeroot --overlay $ov ubuntu_24.04.sif apt install -y neofetch</code>
|-
| Build new image from original + overlay || <code>apptainer build --fakeroot ubuntu_neofetch.sif --overlay $ov ubuntu_24.04.sif</code>
|-
| Test the new image || <code>apptainer exec ubuntu_neofetch.sif neofetch</code>
|-
| Clean up overlay || <code>rm -rf $ov</code>
|}

Tutorials

2026-03-12T09:58:49Z

Honfi001:

== Tutorials ==

=== Modules ===
[[Create Your Own Modules]]

=== Apptainer ===

* [[Tutorials/Apptainer-PullingImages|Pulling Images]]
* Fakeroot and overlays

Tutorials

2026-03-12T09:14:20Z

Honfi001: /* Apptainer */

== Tutorials ==

=== Modules ===
[[Create Your Own Modules]]

=== Apptainer ===

* [[Tutorials/Apptainer-PullingImages|Pulling Images]]

Tutorials

2026-03-12T09:13:07Z

Honfi001: /* Apptainer */

== Tutorials ==

=== Modules ===
[[Create Your Own Modules]]

=== Apptainer ===

* [[Apptainer-PullingImages|Pulling Images]]

Tutorials/Apptainer-PullingImages

2026-03-12T09:11:44Z

Honfi001:

= Pulling Apptainer Images =

== Getting Started ==

First, grab an interactive session in a compute node.

Then make sure your module environment is clean and Apptainer is loaded:

<syntaxhighlight lang="bash">
module reset
module load utilities Apptainer
</syntaxhighlight>Also, please make sure to store image and in your lustre folders.

== Your First Pull ==

Let's start by pulling a simple "hello world" container image:

<syntaxhighlight lang="bash">
apptainer pull ./hello-world.sif shub://vsoch/hello-world
</syntaxhighlight>

That is a lot happening in one line, so let's break it down piece by piece:

{| class="wikitable"
|-
! Part !! What it means
|-
| <code>apptainer pull</code> || The Apptainer command to download a container image.
|-
| <code>./hello-world.sif</code> || The output filename. This is where Apptainer will save the downloaded image. The <code>.sif</code> extension stands for '''Singularity Image Format''' — Apptainer's own container format. The <code>./</code> means "save it in my current directory".
|-
| <code>shub://vsoch/hello-world</code> || The source to pull from. <code>shub://</code> tells Apptainer to look at [https://singularity-hub.org Singularity Hub], a public registry for container images. <code>vsoch/hello-world</code> is the user and image name, much like a path on GitHub.
|}

Once the command finishes, you will have a file called <code>hello-world.sif</code> in your current directory. You can verify this:

<syntaxhighlight lang="bash">
ls -lh hello-world.sif
</syntaxhighlight>

This <code>.sif</code> file is your container — a single, portable file that contains an entire operating system and software environment. You can copy it, move it, or share it just like any other file.

== Running the Container ==

The simplest way to use a container is with <code>apptainer run</code>. This executes whatever default action the container was built to perform:

<syntaxhighlight lang="bash">
apptainer run ./hello-world.sif
</syntaxhighlight>

You should see a friendly output from the container. That is it — you just ran software inside a container.

== Opening a Shell Inside the Container ==

Instead of running the container's default action, you can open an interactive shell inside it. This lets you look around and explore the container's environment as if you had logged into a different machine.

<syntaxhighlight lang="bash">
apptainer shell ./hello-world.sif
</syntaxhighlight>

You will notice your prompt changes (usually to <code>Apptainer></code>), indicating that you are now "inside" the container. Type <code>exit</code> when you want to leave.

=== The Container is Not Fully Isolated (by Default) ===

Here is something important that surprises many beginners: by default, Apptainer does '''not''' fully isolate the container from the host system. Your home directory and parts of the host filesystem are still visible inside the container.

Try this while inside the shell:

<syntaxhighlight lang="bash">
apptainer shell ./hello-world.sif
</syntaxhighlight>

Then, from inside the container:

<syntaxhighlight lang="bash">
Apptainer> mkdir ~/test-from-container
Apptainer> ls ~/test-from-container
Apptainer> exit
</syntaxhighlight>

Now, back on the host:

<syntaxhighlight lang="bash">
ls ~/test-from-container
</syntaxhighlight>

The directory is there — on your '''real''' filesystem. The container was able to create it because your home directory was mounted inside the container by default. This is by design: it makes it easy to work with your own files, but it means the container is not completely separate from the host.

=== Full Isolation with <code>--containall</code> ===

If you want the container to be fully isolated from the host system — no access to your home directory, no shared environment variables, no host filesystems — use the <code>--containall</code> flag (or its short form <code>-C</code>):

<syntaxhighlight lang="bash">
apptainer shell --containall ./hello-world.sif
</syntaxhighlight>

Now try the same thing from inside:

<syntaxhighlight lang="bash">
Apptainer> mkdir ~/test-isolated
Apptainer> exit
</syntaxhighlight>

Back on the host:

<syntaxhighlight lang="bash">
ls ~/test-isolated
</syntaxhighlight>

This time, the directory does '''not''' exist on your host. The container was completely isolated — anything it created lived only inside the container's temporary environment and was discarded when you exited.

Use <code>--containall</code> (or <code>-C</code>) when you want a clean, reproducible environment that does not interfere with (or depend on) the host system.

== Running a Specific Command with <code>exec</code> ==

Sometimes you do not want a full interactive shell — you just want to run a single command inside the container and get the output. That is what <code>apptainer exec</code> is for.

For example, let's check which operating system is inside this container:

<syntaxhighlight lang="bash">
apptainer exec ./hello-world.sif cat /etc/lsb-release
</syntaxhighlight>

You should see output similar to:

<syntaxhighlight lang="text">
DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=14.04
DISTRIB_CODENAME=trusty
DISTRIB_DESCRIPTION="Ubuntu 14.04.6 LTS"
</syntaxhighlight>

The container is running '''Ubuntu 14.04''' — regardless of what operating system your host machine is running. This is the power of containers: you can run software built for a completely different OS environment without any conflicts.

The pattern for <code>exec</code> is:

<code>apptainer exec ''[options]'' ''container.sif'' ''command'' ''[arguments]''</code>

== Summary ==

You now know the three main ways to interact with a pulled Apptainer container:

{| class="wikitable"
|-
! Command !! What it does
|-
| <code>apptainer run container.sif</code> || Runs the container's default action
|-
| <code>apptainer shell container.sif</code> || Opens an interactive shell inside the container
|-
| <code>apptainer exec container.sif ''command''</code> || Runs a single specific command inside the container
|}

And one important flag to remember:

{| class="wikitable"
|-
! Flag !! What it does
|-
| <code>--containall</code> (or <code>-C</code>) || Fully isolates the container from the host (no shared home directory, no host environment)
|}

Tutorials/Apptainer-PullingImages

2026-03-12T09:09:41Z

Honfi001: Add message about storing image in lustre

= Pulling Apptainer Images =

== Getting Started ==

First, make sure your module environment is clean and Apptainer is loaded:

<syntaxhighlight lang="bash">
module reset
module load utilities Apptainer
</syntaxhighlight>Also, please make sure to store image and in your lustre folders.

== Your First Pull ==

Let's start by pulling a simple "hello world" container image:

<syntaxhighlight lang="bash">
apptainer pull ./hello-world.sif shub://vsoch/hello-world
</syntaxhighlight>

That is a lot happening in one line, so let's break it down piece by piece:

{| class="wikitable"
|-
! Part !! What it means
|-
| <code>apptainer pull</code> || The Apptainer command to download a container image.
|-
| <code>./hello-world.sif</code> || The output filename. This is where Apptainer will save the downloaded image. The <code>.sif</code> extension stands for '''Singularity Image Format''' — Apptainer's own container format. The <code>./</code> means "save it in my current directory".
|-
| <code>shub://vsoch/hello-world</code> || The source to pull from. <code>shub://</code> tells Apptainer to look at [https://singularity-hub.org Singularity Hub], a public registry for container images. <code>vsoch/hello-world</code> is the user and image name, much like a path on GitHub.
|}

Once the command finishes, you will have a file called <code>hello-world.sif</code> in your current directory. You can verify this:

<syntaxhighlight lang="bash">
ls -lh hello-world.sif
</syntaxhighlight>

This <code>.sif</code> file is your container — a single, portable file that contains an entire operating system and software environment. You can copy it, move it, or share it just like any other file.

== Running the Container ==

The simplest way to use a container is with <code>apptainer run</code>. This executes whatever default action the container was built to perform:

<syntaxhighlight lang="bash">
apptainer run ./hello-world.sif
</syntaxhighlight>

You should see a friendly output from the container. That is it — you just ran software inside a container.

== Opening a Shell Inside the Container ==

Instead of running the container's default action, you can open an interactive shell inside it. This lets you look around and explore the container's environment as if you had logged into a different machine.

<syntaxhighlight lang="bash">
apptainer shell ./hello-world.sif
</syntaxhighlight>

You will notice your prompt changes (usually to <code>Apptainer></code>), indicating that you are now "inside" the container. Type <code>exit</code> when you want to leave.

=== The Container is Not Fully Isolated (by Default) ===

Here is something important that surprises many beginners: by default, Apptainer does '''not''' fully isolate the container from the host system. Your home directory and parts of the host filesystem are still visible inside the container.

Try this while inside the shell:

<syntaxhighlight lang="bash">
apptainer shell ./hello-world.sif
</syntaxhighlight>

Then, from inside the container:

<syntaxhighlight lang="bash">
Apptainer> mkdir ~/test-from-container
Apptainer> ls ~/test-from-container
Apptainer> exit
</syntaxhighlight>

Now, back on the host:

<syntaxhighlight lang="bash">
ls ~/test-from-container
</syntaxhighlight>

The directory is there — on your '''real''' filesystem. The container was able to create it because your home directory was mounted inside the container by default. This is by design: it makes it easy to work with your own files, but it means the container is not completely separate from the host.

=== Full Isolation with <code>--containall</code> ===

If you want the container to be fully isolated from the host system — no access to your home directory, no shared environment variables, no host filesystems — use the <code>--containall</code> flag (or its short form <code>-C</code>):

<syntaxhighlight lang="bash">
apptainer shell --containall ./hello-world.sif
</syntaxhighlight>

Now try the same thing from inside:

<syntaxhighlight lang="bash">
Apptainer> mkdir ~/test-isolated
Apptainer> exit
</syntaxhighlight>

Back on the host:

<syntaxhighlight lang="bash">
ls ~/test-isolated
</syntaxhighlight>

This time, the directory does '''not''' exist on your host. The container was completely isolated — anything it created lived only inside the container's temporary environment and was discarded when you exited.

Use <code>--containall</code> (or <code>-C</code>) when you want a clean, reproducible environment that does not interfere with (or depend on) the host system.

== Running a Specific Command with <code>exec</code> ==

Sometimes you do not want a full interactive shell — you just want to run a single command inside the container and get the output. That is what <code>apptainer exec</code> is for.

For example, let's check which operating system is inside this container:

<syntaxhighlight lang="bash">
apptainer exec ./hello-world.sif cat /etc/lsb-release
</syntaxhighlight>

You should see output similar to:

<syntaxhighlight lang="text">
DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=14.04
DISTRIB_CODENAME=trusty
DISTRIB_DESCRIPTION="Ubuntu 14.04.6 LTS"
</syntaxhighlight>

The container is running '''Ubuntu 14.04''' — regardless of what operating system your host machine is running. This is the power of containers: you can run software built for a completely different OS environment without any conflicts.

The pattern for <code>exec</code> is:

<code>apptainer exec ''[options]'' ''container.sif'' ''command'' ''[arguments]''</code>

== Summary ==

You now know the three main ways to interact with a pulled Apptainer container:

{| class="wikitable"
|-
! Command !! What it does
|-
| <code>apptainer run container.sif</code> || Runs the container's default action
|-
| <code>apptainer shell container.sif</code> || Opens an interactive shell inside the container
|-
| <code>apptainer exec container.sif ''command''</code> || Runs a single specific command inside the container
|}

And one important flag to remember:

{| class="wikitable"
|-
! Flag !! What it does
|-
| <code>--containall</code> (or <code>-C</code>) || Fully isolates the container from the host (no shared home directory, no host environment)
|}

Main Page/Tutorials/Apptainer

2026-03-11T13:55:51Z

Honfi001: Created page with "This page contains a list of tutorials related to the usage of apptainer in Anunna."

This page contains a list of tutorials related to the usage of apptainer in Anunna.

Main Page/Tutorials

2026-03-11T13:55:02Z

Honfi001: Created page with " =Tutorials= This page contains an index of various tutorials specific to the Anunna supercomputer."

=Tutorials=

This page contains an index of various tutorials specific to the Anunna supercomputer.

Apptainer

2026-03-11T13:46:58Z

Honfi001:

Apptainer is a container platform. It allows you to create and run containers that package up pieces of software in a way that is portable and reproducible. You can build a container using Apptainer on your laptop, and then run it on many of the largest HPC clusters in the world, local university or company clusters, a single server, in the cloud, or on a workstation down the hall. Your container is a single file, and you don’t have to worry about how to install all the software you need on each different operating system.

Apptainer is a fork of singularity and, thus, also supports singularity commands and workflows.

==Apptainer on Anunna==

Since Apptainer is not dependent on specific compilers and toolchains, it is now place inside the '''utilities''' bucket. Inside this bucket, there are two options:

* Apptainer
* Apptainer-compat

The regular '''Apptainer''' module loads the version compiled in Anunna. This is more suitable to containers built with more recent operating systems. For most projects this will be enough.

However, some projects still use some very old Linux versions and through errors related to missing versions of GLIBC when running in Anunna. That is where '''Apptainer-compat''' comes in, this is a package distributed by the Fedora Project EPEL (Extra Packages for Enterprise Linux) repositories. This package is built with a broad range of versions of GLIBC in mind, so will likely work with older images like ubuntu 22.04 or older.

One can load apptainer by running the following commands

<pre>module load utilities
module load Apptainer</pre>

==== Initial Setup ====
Apptainer will cache SIF container images generated from remote sources, and any OCI/docker layers used to create them. The cache is created at <code>$HOME/.apptainer/cache</code> by default. The location of the cache can be changed by setting the <code>APPTAINER_CACHEDIR</code> environment variable.

Since there is a limited amount of space available at <code>$HOME</code>, the Apptainer cache can quickly fill your quota. So it is recommended that you set the variable <code>APPTAINER_CACHEDIR</code> to a location ion lustre by edition your <code>$HOME/.bash_aliases</code> file. An example is provided at [[Aliases and local variables]]

Jupyter

2026-02-25T18:10:23Z

Honfi001: New jupyter page in OOD

JupyterLab is the latest web-based interactive development environment for notebooks, code, and data. Its flexible interface allows users to configure and arrange workflows in data science, scientific computing, computational journalism, and machine learning. A modular design invites extensions to expand and enrich functionality.

Traditionally, jupyter has been offered at Anunna via [https://notebook.anunna.wur.nl notebook.anunna.wur.nl], though OOD makes it possible to deploy Jupyter based off the environment modules from Anunna. Adding greater stability and flexibility. Jupyter is listed in the featured apps speed-dial and upon clicking on it, the user is presented with a form where they can select their preferences and allocate resources for their session
[[File:Jupyter-form-20260225.png|thumb|695x695px|Resource Allocation form for Jupyter Session]]

=== Resource Allocation Form ===

* '''Python version:''' version of python the default kernel will be running
* '''Session Type:''' traditional notebooks interface or the newer lab interface. It is also possible to change the interface from within the active Jupyter session.
* '''Hours:''' Number of hours allocated to the session, max 4 hours
* '''Number of CPUs:''' Number of CPU cores allocated for the session
* '''Amount of Memory:''' RAM allocated for the session
* '''Number of GPUs:''' 0 denotes no GPU is used, a non-zero number will switch the partition from main to the gpu partition
* '''Comment:''' label or project number that will show up in billing.
* '''Slurm Options:''' slurm flags that may override settings above

==== Connecting to an active session ====
After the resources and preferences have been defined, the user can simply click on the launch button. Which will submit a job at Anunna and take them to the My Interactive Sessions page where they can connect to their session.

Once the session is ready a "Connect to Jupyter " button will appear which will allow the user to (re)connect to the corresponding active session.

The card also has a red "Cancel" button where the user may terminate their session.

File:Jupyter-form-20260225.png

2026-02-25T18:01:19Z

Honfi001:

OOD jupyter form

Anunna Shell Access

2026-02-25T14:25:35Z

Honfi001:

Anunna Shell Access is a web based bash shell terminal emulator available at the Anunna apps portal.

This application provides quick access to a bash session in one of the login nodes.

User's are able to select a theme for their terminal session on the top right corner of the screen.

When a session times out, just refresh your browser tab and it should reconnect.

Since this runs in a browser, users should mind that some bash keyboard shortcuts may not work properly, e.g. ctrl + w

Anunna Shell Access

2026-02-25T14:23:56Z

Honfi001: Created page with "Anunna Shell Access is a web based bash shell terminal emulator available at the Anunna apps portal. This application provides quick access to a bash session in one of the login nodes. User's are able to select a theme for their terminal session on the top right corner of the screen. When a session times out, just refresh your browser tab and it should reconnect. Since this runs in a browser, users should mind that some keyboard shortcuts may not work properly, e..."

Anunna Shell Access is a web based bash shell terminal emulator available at the Anunna apps portal.

This application provides quick access to a bash session in one of the login nodes.

User's are able to select a theme for their terminal session on the top right corner of the screen.

When a session times out, just refresh your browser tab and it should reconnect.

Since this runs in a browser, users should mind that some keyboard shortcuts may not work properly, e.g. ctrl + w

Main Page

2026-02-25T14:16:18Z

Honfi001:

Anunna is a [http://en.wikipedia.org/wiki/High-performance_computing High Performance Computer] (HPC) infrastructure hosted by [https://www.wur.nl/en/show/supercomputer-anunna-opens-up-more-opportunities-for-data-storage-and-artificial-intelligence-applications.htm Wageningen University & Research Centre]. It is open for use for all WUR research groups as well as other organizations, including companies, that have collaborative projects with WUR.

= About =

* [[History of the Cluster|Historical information on the startup of Anunna]]

== Access Policy ==
[[Access_Policy | Main Article: Access Policy]]

Access needs to be granted actively (by creation of an account on the cluster by FB-IT). Use of resources is limited by the scheduler. Note that the use of Anunna is not free of charge.

= Our Courses =
The Anunna team organizes HPC courses three times a year to strengthen basic & more advanced skills and enable users to make the most effective use of our facility.

== [[Linux Basic]] ==

== [[HPC Basic]] ==

== [[HPC Advanced]] ==

== [[2026 Course dates]] ==

= Using Anunna =
* [[Tariffs | Costs associated with resource usage]]

== Gaining access to Anunna==
Access to the cluster and file transfer are traditionally done via [http://en.wikipedia.org/wiki/Secure_Shell SSH and SFTP].
* [[log_in_to_B4F_cluster | Logging into cluster using ssh]]
* [[file_transfer | File transfer options]]
* [[Services | Alternative access methods, and extra features and services on Anunna]]
* [[Filesystems | Data storage methods on Anunna]]

== Using Anunna for courses (mainly jupyter notebooks) ==
* [[steps_for_courses | Steps involved to run a course on Anunna]]

= Events =

* [[Courses]] that have happened and are happening
* [[Downtime]] that will affect all users
* [[Meetings]] that may affect the policies of Anunna

= Software =
* [[Modules]]
* [[Apptainer]]
* [[Python]]
* [[R]]
* [[Julia]]

== Browser apps ==
This page provides an overview of the GUI-based applications available Anunna, including background information and practical guidance on how to access and use interactive desktops and graphical tools directly from your web browser.

* [[General overview|General Overview]]
* [[Anunna Shell Access]]
* [[Using the File browser|File Browser]]
* [[Jupyter|Featured Apps]]
* [[Jupyter]]
* [[RStudio|R Studio]]
* [[Linux desktop|Linux Desktop]]
* [[Requesting new software|Requesting New Software]]

== Command-line Software ==

==== Cluster Scheduler ====
Anunna uses Slurm as job scheduler.
* [[Using_Slurm | Submit jobs with Slurm]]
* [[node_usage_graph | Be aware of how much work the cluster is under right now with 'node_usage_graph']]
* [[SLURM_Compare | Rosetta Stone of Workload Managers]]

==== [[Globally installed software]] ====

==== [[ABGC_modules |ABGC specific modules]] ====

==== Installation of software by users ====
* [[Domain_specific_software_on_B4Fcluster_installation_by_users | Installing domain specific software: installation by users]]
* [[Setting local variables]]
* [[Installing_R_packages_locally | Installing R packages locally]]
* [[Setting_up_Python_virtualenv | Setting up and using a virtual environment for Python3 ]]
* [[Virtual_environment_Python_3.4_or_higher | Setting up and using a virtual environment for Python3.4 or higher ]]
* [[Installing WRF and WPS]]
* [[Running scripts on a fixed timeschedule (cron)]]

= Useful Notes =

== Being in control of Environment parameters ==

* [[Using_environment_modules | Using environment modules]]
* [[Aliases and local variables]]
* [[Setting local variables]]
* [[Setting_TMPDIR | Set a custom temporary directory location]]
* [[Installing_R_packages_locally | Installing R packages locally]]
* [[Setting_up_Python_virtualenv | Setting up and using a virtual environment for Python3 ]]
* [[Locale_settings]] (how numbers and dates are displayed)

== Controlling costs ==

* [[SACCT | using SACCT to see your costs]]
* [[get_my_bill | using the "get_my_bill" script to estimate costs]]

== Management ==
Product Owner of Anunna is Alexander van Ittersum (Wageningen UR,FB-IT, C&PS). [[User: prins089 | Fons Prinsen (Wageningen UR, FB-IT, C&PS)]] is responsible for [[Maintenance_and_Management | Maintenance and Management]] of the cluster.

* [[Roadmap | Ambitions regarding innovation, support and administration of Anunna ]]

= Miscellaneous =
* [[Bioinformatics_tips_tricks_workflows |Bioinformatics tips, tricks, and workflows]]
* [[Parallel_R_code_on_SLURM | Running parallel R code on SLURM]]
* [[Convert_between_MediaWiki_and_other_formats | Convert between MediaWiki format and other formats]]
* [[Manual GitLab | GitLab: Create projects and add scripts]]
* [[Monitoring_executions | Monitoring job execution]]
* [[Shared_folders | Working with shared folders in the Lustre file system]]
* [[Old_binaries | Running older binaries on the updated OS]]
* [[locale_settings | How to change language settings for yourself]]

= See also =
* [[Maintenance_and_Management | Maintenance and Management]]
* [[About_ABGC | About ABGC]]
* [[Computer_cluster | High Performance Computing @ABGC]]
* [[Lustre_PFS_layout | Lustre Parallel File System layout]]

= External links =
{| width="90%"
|- valign="top"
| width="30%" |
* [https://www.wur.nl/en/Value-Creation-Cooperation/Facilities/Wageningen-Shared-Research-Facilities/Our-facilities/Show/High-Performance-Computing-Cluster-HPC-Anunna.htm SRF offers a HPC facilty]
| width="30%" |
* [http://en.wikipedia.org/wiki/Scientific_Linux Scientific Linux]
* [http://en.wikipedia.org/wiki/Help:Cheatsheet Help with editing Wiki pages]
|}

Using the File browser

2026-02-25T14:12:08Z

Honfi001: Basic file browser information

Open Ondemand provides a web based file browser to Anunna, which provides a convenient and easy interface for managing fiiles.

By default the file browser points to the user's home directory, but shortcuts to lustre and archive are provided in the left side bar. Alterntively users can use the change directory button and type a location they would like to see displayed

* Upload files
* Download files
* Create files and directories
* Delete files and directories
* Move files and directories
* Edit files

These features, including editing feature can be acessed by using the dot menu next to the file name. The editor is very basic and only suitable for editing one file at a time.

Note that, despite having the option to upload and download files, this file browser is not suitable for files larges than a couple of gigabytes.

Main Page

2026-02-25T13:30:50Z

Honfi001: /* Browser apps */

Anunna is a [http://en.wikipedia.org/wiki/High-performance_computing High Performance Computer] (HPC) infrastructure hosted by [https://www.wur.nl/en/show/supercomputer-anunna-opens-up-more-opportunities-for-data-storage-and-artificial-intelligence-applications.htm Wageningen University & Research Centre]. It is open for use for all WUR research groups as well as other organizations, including companies, that have collaborative projects with WUR.

= About =

* [[History of the Cluster|Historical information on the startup of Anunna]]

== Access Policy ==
[[Access_Policy | Main Article: Access Policy]]

Access needs to be granted actively (by creation of an account on the cluster by FB-IT). Use of resources is limited by the scheduler. Note that the use of Anunna is not free of charge.

= Our Courses =
The Anunna team organizes HPC courses three times a year to strengthen basic & more advanced skills and enable users to make the most effective use of our facility.

== [[Linux Basic]] ==

== [[HPC Basic]] ==

== [[HPC Advanced]] ==

== [[2026 Course dates]] ==

= Using Anunna =
* [[Tariffs | Costs associated with resource usage]]

== Gaining access to Anunna==
Access to the cluster and file transfer are traditionally done via [http://en.wikipedia.org/wiki/Secure_Shell SSH and SFTP].
* [[log_in_to_B4F_cluster | Logging into cluster using ssh]]
* [[file_transfer | File transfer options]]
* [[Services | Alternative access methods, and extra features and services on Anunna]]
* [[Filesystems | Data storage methods on Anunna]]

== Using Anunna for courses (mainly jupyter notebooks) ==
* [[steps_for_courses | Steps involved to run a course on Anunna]]

= Events =

* [[Courses]] that have happened and are happening
* [[Downtime]] that will affect all users
* [[Meetings]] that may affect the policies of Anunna

= Software =
* [[Modules]]
* [[Apptainer]]
* [[Python]]
* [[R]]
* [[Julia]]

== Browser apps ==
This page provides an overview of the GUI-based applications available Anunna, including background information and practical guidance on how to access and use interactive desktops and graphical tools directly from your web browser.

* [[General overview|General Overview]]
* [[Using the Shell|Anunna Shell Access]]
* [[Using the File browser|File Browser]]
* [[Jupyter|Featured Apps]]
* [[Jupyter]]
* [[RStudio|R Studio]]
* [[Linux desktop|Linux Desktop]]
* [[Requesting new software|Requesting New Software]]

== Command-line Software ==

==== Cluster Scheduler ====
Anunna uses Slurm as job scheduler.
* [[Using_Slurm | Submit jobs with Slurm]]
* [[node_usage_graph | Be aware of how much work the cluster is under right now with 'node_usage_graph']]
* [[SLURM_Compare | Rosetta Stone of Workload Managers]]

==== [[Globally installed software]] ====

==== [[ABGC_modules |ABGC specific modules]] ====

==== Installation of software by users ====
* [[Domain_specific_software_on_B4Fcluster_installation_by_users | Installing domain specific software: installation by users]]
* [[Setting local variables]]
* [[Installing_R_packages_locally | Installing R packages locally]]
* [[Setting_up_Python_virtualenv | Setting up and using a virtual environment for Python3 ]]
* [[Virtual_environment_Python_3.4_or_higher | Setting up and using a virtual environment for Python3.4 or higher ]]
* [[Installing WRF and WPS]]
* [[Running scripts on a fixed timeschedule (cron)]]

= Useful Notes =

== Being in control of Environment parameters ==

* [[Using_environment_modules | Using environment modules]]
* [[Aliases and local variables]]
* [[Setting local variables]]
* [[Setting_TMPDIR | Set a custom temporary directory location]]
* [[Installing_R_packages_locally | Installing R packages locally]]
* [[Setting_up_Python_virtualenv | Setting up and using a virtual environment for Python3 ]]
* [[Locale_settings]] (how numbers and dates are displayed)

== Controlling costs ==

* [[SACCT | using SACCT to see your costs]]
* [[get_my_bill | using the "get_my_bill" script to estimate costs]]

== Management ==
Product Owner of Anunna is Alexander van Ittersum (Wageningen UR,FB-IT, C&PS). [[User: prins089 | Fons Prinsen (Wageningen UR, FB-IT, C&PS)]] is responsible for [[Maintenance_and_Management | Maintenance and Management]] of the cluster.

* [[Roadmap | Ambitions regarding innovation, support and administration of Anunna ]]

= Miscellaneous =
* [[Bioinformatics_tips_tricks_workflows |Bioinformatics tips, tricks, and workflows]]
* [[Parallel_R_code_on_SLURM | Running parallel R code on SLURM]]
* [[Convert_between_MediaWiki_and_other_formats | Convert between MediaWiki format and other formats]]
* [[Manual GitLab | GitLab: Create projects and add scripts]]
* [[Monitoring_executions | Monitoring job execution]]
* [[Shared_folders | Working with shared folders in the Lustre file system]]
* [[Old_binaries | Running older binaries on the updated OS]]
* [[locale_settings | How to change language settings for yourself]]

= See also =
* [[Maintenance_and_Management | Maintenance and Management]]
* [[About_ABGC | About ABGC]]
* [[Computer_cluster | High Performance Computing @ABGC]]
* [[Lustre_PFS_layout | Lustre Parallel File System layout]]

= External links =
{| width="90%"
|- valign="top"
| width="30%" |
* [https://www.wur.nl/en/Value-Creation-Cooperation/Facilities/Wageningen-Shared-Research-Facilities/Our-facilities/Show/High-Performance-Computing-Cluster-HPC-Anunna.htm SRF offers a HPC facilty]
| width="30%" |
* [http://en.wikipedia.org/wiki/Scientific_Linux Scientific Linux]
* [http://en.wikipedia.org/wiki/Help:Cheatsheet Help with editing Wiki pages]
|}

RStudio

2026-02-25T12:17:12Z

Honfi001: Rstudio

The '''RStudio integrated development environment (IDE''') is a set of tools built to help you be more productive with R and Python.
[[File:RStudio-form-20260225.png|thumb|595x595px|Resource Allocation Form]]
RStudio is built with the aid of EasyBuild and makes use of the relevant R modules available at Anunna

Rstudio can be found both in the All Applications Menu at the navigation bar, and as a button in the Featured Apps speed dial. By clicking in either option, the user will be taken to a form where they will be able to allocate resources for their RStudio session.

=== Resource Allocation form ===
The resource allocation form allows the use to select the following options

* R version
* Partition: main by default but the GPU partition is available
* Number of Hours: Max 4 hours
* Number of CPUs: CPU cores available
* Memory : Amount of RAM available
* Number of GPUs: Zero by default, this need to be switched to, at least 1
** Note that the GPU partition must be selected
* Comment: Project number that will show up at your bill
* Slurm options: Slurm flag overrides.

=== Connecting to an active session ===
Once the form has been filled, the use can then click on the Launch button. This cause the screen to switch to the interactive sessions page where a new session will be listed.

Once the session is ready a "Connect to RStudio Server" button will appear which will allow the user to (re)connect to the corresponding active session.

The card also has a red "Cancel" button where the user may terminate their session.
[[File:RStudio-connect-20260225.png|center|thumb|509x509px|RStudio active session card at My Interactive Sessions]]

File:RStudio-connect-20260225.png

2026-02-25T12:15:04Z

Honfi001:

RStudio connection card

File:RStudio-form-20260225.png

2026-02-25T11:59:48Z

Honfi001:

Rstudio resource allocation form

General overview

2026-02-25T11:45:12Z

Honfi001: bla

=== GUI Applications on Anunna ===
Anunna provides access to desktop environments and GUI-based applications to support interactive research workflows. The environment is built on Open OnDemand, an open-source web portal that connects users to HPC resources through a web browser. The platform enables secure job submission, interactive desktop sessions, file management, and access to applications without requiring command-line interaction.
[[File:OOD20260225.png|thumb|716x716px|apps.anunna.wur.nl]]
The portal consists of a dashboard with the following features

* Navigation Bar
* Message of the day/Announcements
* Feature Applications

==== Navigation bar ====
Provides access to the

* '''All Applications:''' A list of all GUI applications available at Anunna.
* '''Jobs:''' An interactive list of all jobs running at Anunna.
* '''Courses:''' Active education courses available at the HPC.
* '''My Interactive Sessions:''' An overview of your past and currently active sessions.
* '''Help Menu:''' Collection of links and knowledge articles relevant to Anunna

==== Message of the Day ====
This section is dedicated for annoucements and general communication from the HPC team.

=== Featured Applications ===
Highlights of commonly used applications, including:
* [[Using the File browser|File Browser]]

* [[Using the Shell|Shell Access to Anunna]]
* [[R Studio]]
* Active courses currently using Anunna resources

=== Access ===
The portal is available at:

https://apps.anunna.wur.nl

Additional applications may be available depending on user permissions and project allocations. They can be found in the Menu under "All Applications"
.[[File:Menu Bar Anunna GUI-apps.png|left|thumb]]

File:OOD20260225.png

2026-02-25T11:42:18Z

Honfi001:

Current snapshot of the Anunna Apps interface

Linux Basic

2026-02-25T09:56:46Z

Honfi001: Add description to the links and upload slides.

Are you interested in using the High Performance Computing (HPC) Cluster but lack basic Linux knowledge? Join our free 5-hour course on Linux fundamentals for working on the HPC. You will learn the essential Linux commands and skills needed to efficiently navigate the system and automate repetitive tasks.

The course is organized by the Anunna team and SRF, with contributions from WUR scientists experienced in working with the HPC.

'''Prerequisites:'''

Please bring your laptop so you can actively participate and complete the hands-on exercises during the workshop.
See [[2026 Course dates]] for more information on scheduling and registration details.

==== Self-study material: ====
If you are not able to attend the course, you can make use of the following resources

* [[:File:WUR Linux Basics Course 2026 Feb.pdf|Latest Slides]]: Slides of the latest course session offered at thw WUR
* [https://labex.io/linuxjourney Linux Journey]: Great site for self-paced learning about linux. It offers free virtual machines for training
* [https://www.linux-path.com/en Linux Path]: Fork of Linux journey, has additional curated
* [https://carpentries.org Software Carpentry]: Community of free lessons on many topics. For linux click Learn > lessons > Unix shell.

File:WUR Linux Basics Course 2026 Feb.pdf

2026-02-25T09:50:14Z

Honfi001: Latest Linux Basics slides from the Feb/26 session

== Summary ==
Latest Linux Basics slides from the Feb/26 session

Linux Basic

2026-02-25T09:48:42Z

Honfi001: Add external self-study links

Are you interested in using the High Performance Computing (HPC) Cluster but lack basic Linux knowledge? Join our free 5-hour course on Linux fundamentals for working on the HPC. You will learn the essential Linux commands and skills needed to efficiently navigate the system and automate repetitive tasks.

The course is organized by the Anunna team and SRF, with contributions from WUR scientists experienced in working with the HPC.

'''Prerequisites:'''

Please bring your laptop so you can actively participate and complete the hands-on exercises during the workshop.
See [[2026 Course dates]] for more information on scheduling and registration details.

==== Self-study material: ====
If you are not able to attend the course, you can make use of the following resources

* Latest Slides:
* [https://labex.io/linuxjourney Linux Journey]
* [https://www.linux-path.com/en Linux Path]
* [https://carpentries.org Software Carpentry]

File:WUR Linux Basics Course.pdf

2026-02-25T09:40:24Z

Honfi001:

Slides for the latest linux basics course offered at the WUR

Main Page

2026-02-24T14:54:56Z

Honfi001: /* Browser apps */

Anunna is a [http://en.wikipedia.org/wiki/High-performance_computing High Performance Computer] (HPC) infrastructure hosted by [https://www.wur.nl/en/show/supercomputer-anunna-opens-up-more-opportunities-for-data-storage-and-artificial-intelligence-applications.htm Wageningen University & Research Centre]. It is open for use for all WUR research groups as well as other organizations, including companies, that have collaborative projects with WUR.

= About =

* [[History of the Cluster|Historical information on the startup of Anunna]]

== Access Policy ==
[[Access_Policy | Main Article: Access Policy]]

Access needs to be granted actively (by creation of an account on the cluster by FB-IT). Use of resources is limited by the scheduler. Note that the use of Anunna is not free of charge.

= Our Courses =
The Anunna team organizes HPC courses three times a year to strengthen basic & more advanced skills and enable users to make the most effective use of our facility.

== [[Linux Basic]] ==

== [[HPC Basic]] ==

== [[HPC Advanced]] ==

== [[2026 Course dates]] ==

= Using Anunna =
* [[Tariffs | Costs associated with resource usage]]

== Gaining access to Anunna==
Access to the cluster and file transfer are traditionally done via [http://en.wikipedia.org/wiki/Secure_Shell SSH and SFTP].
* [[log_in_to_B4F_cluster | Logging into cluster using ssh]]
* [[file_transfer | File transfer options]]
* [[Services | Alternative access methods, and extra features and services on Anunna]]
* [[Filesystems | Data storage methods on Anunna]]

== Using Anunna for courses (mainly jupyter notebooks) ==
* [[steps_for_courses | Steps involved to run a course on Anunna]]

= Events =

* [[Courses]] that have happened and are happening
* [[Downtime]] that will affect all users
* [[Meetings]] that may affect the policies of Anunna

= Software =
* [[Modules]]
* [[Apptainer]]
* [[Python]]
* [[R]]
* [[Julia]]

== Browser apps ==
bla bla

* [[General overview]]
* [[Using the Shell]]
* [[Using the File browser]]
* [[Jupyter|Featured apps]]
* [[Jupyter]]
* [[RStudio|R Studio]]
* [[Linux desktop]]
* [[Requesting new software]]

== Command-line Software ==

==== Cluster Scheduler ====
Anunna uses Slurm as job scheduler.
* [[Using_Slurm | Submit jobs with Slurm]]
* [[node_usage_graph | Be aware of how much work the cluster is under right now with 'node_usage_graph']]
* [[SLURM_Compare | Rosetta Stone of Workload Managers]]

==== [[Globally installed software]] ====

==== [[ABGC_modules |ABGC specific modules]] ====

==== Installation of software by users ====
* [[Domain_specific_software_on_B4Fcluster_installation_by_users | Installing domain specific software: installation by users]]
* [[Setting local variables]]
* [[Installing_R_packages_locally | Installing R packages locally]]
* [[Setting_up_Python_virtualenv | Setting up and using a virtual environment for Python3 ]]
* [[Virtual_environment_Python_3.4_or_higher | Setting up and using a virtual environment for Python3.4 or higher ]]
* [[Installing WRF and WPS]]
* [[Running scripts on a fixed timeschedule (cron)]]

= Useful Notes =

== Being in control of Environment parameters ==

* [[Using_environment_modules | Using environment modules]]
* [[Aliases and local variables]]
* [[Setting local variables]]
* [[Setting_TMPDIR | Set a custom temporary directory location]]
* [[Installing_R_packages_locally | Installing R packages locally]]
* [[Setting_up_Python_virtualenv | Setting up and using a virtual environment for Python3 ]]
* [[Locale_settings]] (how numbers and dates are displayed)

== Controlling costs ==

* [[SACCT | using SACCT to see your costs]]
* [[get_my_bill | using the "get_my_bill" script to estimate costs]]

== Management ==
Product Owner of Anunna is Alexander van Ittersum (Wageningen UR,FB-IT, C&PS). [[User: prins089 | Fons Prinsen (Wageningen UR, FB-IT, C&PS)]] is responsible for [[Maintenance_and_Management | Maintenance and Management]] of the cluster.

* [[Roadmap | Ambitions regarding innovation, support and administration of Anunna ]]

= Miscellaneous =
* [[Bioinformatics_tips_tricks_workflows |Bioinformatics tips, tricks, and workflows]]
* [[Parallel_R_code_on_SLURM | Running parallel R code on SLURM]]
* [[Convert_between_MediaWiki_and_other_formats | Convert between MediaWiki format and other formats]]
* [[Manual GitLab | GitLab: Create projects and add scripts]]
* [[Monitoring_executions | Monitoring job execution]]
* [[Shared_folders | Working with shared folders in the Lustre file system]]
* [[Old_binaries | Running older binaries on the updated OS]]
* [[locale_settings | How to change language settings for yourself]]

= See also =
* [[Maintenance_and_Management | Maintenance and Management]]
* [[About_ABGC | About ABGC]]
* [[Computer_cluster | High Performance Computing @ABGC]]
* [[Lustre_PFS_layout | Lustre Parallel File System layout]]

= External links =
{| width="90%"
|- valign="top"
| width="30%" |
* [https://www.wur.nl/en/Value-Creation-Cooperation/Facilities/Wageningen-Shared-Research-Facilities/Our-facilities/Show/High-Performance-Computing-Cluster-HPC-Anunna.htm SRF offers a HPC facilty]
| width="30%" |
* [http://en.wikipedia.org/wiki/Scientific_Linux Scientific Linux]
* [http://en.wikipedia.org/wiki/Help:Cheatsheet Help with editing Wiki pages]
|}

Open OnDemand

2026-02-24T14:48:05Z

Honfi001:

Anunna provides a web portal allowing users to access the HPC via their web browser. This is is made possible via the Open OnDemand Project, which is a web based system that proves a Graphical User Interface (GUI) for applications in the HPC. The portal can be accessed at <nowiki>https://app.anunna.wur.nl</nowiki> .

* Apps
* File Browser
* Jobs
* Courses
* Message of the day
* Featured apps

Steps for courses

2026-01-12T15:50:36Z

Honfi001:

To be able to run a course on Anunna, there are a couple of steps to take as a teacher

* Create accounts for all involved (Teachers/TA's/students) and reservations for the course
** You can start with the teachers and TA's, and add the students later once they are known
** Use [https://support.wur.nl/esc?id=sc_cat_item&table=sc_cat_item&sys_id=f4de15c047df9550d7dd9880236d43a5&searchTerm=HPC this] Service Now form to request the accounts you need.
* If you want to use Jupyter:
** Create and test your own kernel, there are multiple options for this:
*** [[Python]]
*** [[R]] (coming)
** Create a ticket to get your kernel added to the list in https://notebook.anunna.wur.nl
** To ease the use of the service, we give courses a dropdown to set up number of CPUs/memory/runtime. Please create a ticket to ask us to add your course to the dropdown menu.

Besides the above interactions, the HPC admin team will also:
* Create a teams chat between the course organisers and administrators, so we have a hotline in case of issues.
* Be present at the start of your course (if on campus), to smooth out any issues that might arise at the start (missing/not working accounts)

If there are any issues, please have a look at [[Hints for courses]]

Steps for courses

2026-01-12T15:47:47Z

Honfi001: Update procedure

To be able to run a course on Anunna, there are a couple of steps to take as a teacher

* Create accounts for all involved (Teachers/TA's/students) and reservations for the course
** You can start with the teachers and TA's, and add the students later once they are known
** Use [https://support.wur.nl/esc?id=sc_cat_item&table=sc_cat_item&sys_id=f4de15c047df9550d7dd9880236d43a5&searchTerm=HPC this] Service Now form to request the accounts you need.
* If you want to use Jupyter:
** Create and test your own kernel, there are multiple options for this:
*** [[Setting_up_Python_virtualenv#Virtualenv_kernels_in_Jupyter|virtualenv]]
*** [[Conda_for_teaching|conda]]
** Create a ticket to get your kernel added to the list in https://notebook.anunna.wur.nl
** To ease the use of the service, we give courses a dropdown to set up number of CPUs/memory/runtime. Please create a ticket to ask us to add your course to the dropdown menu.

Besides the above interactions, the HPC admin team will also:
* Create a teams chat between the course organisers and administrators, so we have a hotline in case of issues.
* Be present at the start of your course (if on campus), to smooth out any issues that might arise at the start (missing/not working accounts)

If there are any issues, please have a look at [[Hints for courses]]

Tutorials

2025-11-20T17:13:27Z

Honfi001: Tutorials Page

== Tutorials ==

=== Modules ===
[[Create Your Own Modules]]

=== Apptainer ===

Modules

2025-11-20T16:28:41Z

Honfi001: Updates

== Modules in anunna ==

Anunna uses modules via Lmod to provide software to their users. A module configures the environment of the user and/or their jobs to enable the desired application to run.
These modules are organized in "buckets" for each year. We intend to keep three buckets of software, one for the current year, one for the previous year and another for legacy software. The legacy module should contain software that is older than two years and is still used or relevant.

The point is to have a conveyor belt of software and have more up-to-date software with more modern build tools (GCC, MPI, intel), which makes the software more maintainable. The conveyor belt also enables the use of more modern toolchains (foss, intel), which will enable software to run more efficiently.

For each bucket, we intend to keep one version of software. These are the buckets currently available at Anunna: legacy, utilities, groups, 2023, 2024 and GPU

The new modules have been built with the aid of EasyBuild (https://easybuild.io/)

EasyBuild makes use of publicly shared recipe's, called easyconfigs. Have a look at their repository for available software:

https://github.com/easybuilders/easybuild-easyconfigs/tree/develop/easybuild/easyconfigs

===Requesting Modules===

If a module you require is not available, please submit a software request at https://ideas.anunna.wur.nl . There you are able to follow the progress of the software you need and upvote the request of other users. The software or features with more upvotes will be prioritised sooner.

===Module Organization===

Modules are to be organized into buckets by year or additional categories. Current buckets are

* '''legacy''' - old software that is no longer maintained or updated, but it is still used in active research.
* '''2023''' - software built using the 2023 compilers and toolchain. It is meant to contain a single version of each software.
* '''2024''' - software built using the 2024 compilers and toolchain. It is meant to contain a single version of each software.
* '''utilities''' - software that is not dependent on specific compilers or toolchains.
* '''groups''' - This bucket contains subfolders containing module files for groups in and outside the WUR.
* '''GPU''' - CUDA, cuDNN and related packages that are independent of toolchains

In order to access the modules of the '''2023''' bucket one needs to execute the following commands:

<pre>module load 2023</pre>

Afterwards, the list of available modules is expanded and this can be verified by running

<pre>module avail</pre>

===Why Buckets?===

As time goes by, software is developed with newer compilers and tools. So the buckets are snapshots of these new compilers and tools that have been used to develop and build these pieces of software. The compilers will determine which processor operations will be supported by the software, so if a job runs software from two different compilers conflicts, errors or unwanted behaviour may occur.

Therefore, it is best to have jobs with software built from the same compiler. This is the purpose of the buckets, where all the software should be built with the same compiler.

==Usage==

===Listing Modules===

The commands that hereby follow will list the modules available to the user in increansing detail. '''overview''' provides a top level view of the software available without going into detail about the different versions available. It will only list the software and the number of versions. The '''avail''' command will list the different versions of the same software. Finally, '''spider''' will provide a verbose list with all the different versions and the description of each.

<pre>
module overview
</pre>

<pre>
module avail
</pre>

<pre>
module spider
</pre>

===Searching For Modules===

The same commands used for listing modules can be used for searching, the only difference is that that the name of the module is passed as an argument. Like the listing in the section above, the commands provide different levels of verbosity.

<pre>
module overview <nameOfModule>
</pre>

<pre>
module avail <nameOfModule>
</pre>

<pre>
module spider <nameOfModule>
</pre>

===Searching For Keywords===

As a more advanced search feature, one can search for keywords inside of modules. This is useful when searching for which modules contain a specific Python or R extension. There are bundle modules for both languages that contain a list of their extensions. Lmod will also search inside the description of the modules, which can be useful for discoverability.

This feature can be used with the following command template:

<pre>module key <keyword></pre>

To illustrate, say that one needs to find a module with the R packager '''terra''' installed. The first step would be to load one of the buckets, for instance 2023.

<pre>module load 2023</pre>

Then, the next step would be to apply the key template above

<pre>module key terra</pre>

which yields the following results

<pre>
The following modules match your search criteria: "terra"
--------------------------------------------------------------------------------------------------------

R-bundle-CRAN: R-bundle-CRAN/2023.12-foss-2023a
Bundle of R packages from CRAN

--------------------------------------------------------------------------------------------------------
</pre>

Hence, one would need to load the module '''R-bundle-CRAN/2023.12-foss-2023a''' to have access to the '''terra''' package

===Loading Modules===

Modules are loaded through the following command template

<pre>module load <moduleName></pre>

The example below show how to load the python module from the 2023 bucket

<pre>
module load 2023
module load Python/3.11.3
</pre>

It is good practice to specify the version of the module being loaded for consistency and reproducibility.

If the version of the module is not specified, lmod will choose the default available version at the time and that may change.

By specifying the version in your submit scripts, it transforms the script into additional documentation.

When loading modules, the dependencies of that module will also be loaded with it.

===List Loaded Modules===

Loaded modules can be listed with following command

<pre>module list</pre>

Following the example in the previous section, after loading the 2023 and the Python/3.11.3 modules (and its dependencies), one can this list the modules loaded

<pre>
user001@login201:~$ module list

Currently Loaded Modules:
1) slurm/24.05.1 (S) 5) binutils/2.40-GCCcore-12.3.0 9) Tcl/8.6.13-GCCcore-12.3.0 13) OpenSSL/1.1
2) 2023 6) bzip2/1.0.8-GCCcore-12.3.0 10) SQLite/3.42.0-GCCcore-12.3.0 14) Python/3.11.3-GCCcore-12.3.0
3) GCCcore/12.3.0 7) ncurses/6.4-GCCcore-12.3.0 11) XZ/5.4.2-GCCcore-12.3.0
4) zlib/1.2.13-GCCcore-12.3.0 8) libreadline/8.2-GCCcore-12.3.0 12) libffi/3.4.4-GCCcore-12.3.0

Where:
S: Module is Sticky, requires --force to unload or purge
</pre>

we can see that aside from the slurm modules (which is loaded by default), the 2023 module and the Python/3.11.3, 11 other dependencies are loaded with the Python/3.11.3 module

===Removing Modules===

Modules can be removed with the following template command

<pre>module unload <moduleName></pre>

Following the example of the python module above, the module can be removed with the following command

<pre>module unload Python/3.11.3</pre>

This command will only unload the Python/3.11.3 module and not its dependencies.

We can see this if we list the loaded modules again

<pre>
user001@login201:~$ module unload Python/3.11.3
user001@login201:~$ module list

Currently Loaded Modules:
1) slurm/24.05.1 (S) 5) binutils/2.40-GCCcore-12.3.0 9) Tcl/8.6.13-GCCcore-12.3.0 13) OpenSSL/1.1
2) 2023 6) bzip2/1.0.8-GCCcore-12.3.0 10) SQLite/3.42.0-GCCcore-12.3.0 14) Python/3.11.3-GCCcore-12.3.0
3) GCCcore/12.3.0 7) ncurses/6.4-GCCcore-12.3.0 11) XZ/5.4.2-GCCcore-12.3.0
4) zlib/1.2.13-GCCcore-12.3.0 8) libreadline/8.2-GCCcore-12.3.0 12) libffi/3.4.4-GCCcore-12.3.0
</pre>

We can completely clean the environment by using the purge command

<pre>module purge</pre>

From our example,

<pre>user001@login201:~$ module purge
The following modules were not unloaded:
(Use "module --force purge" to unload all):

1) slurm/24.05.1</pre>

The only remaining module is the slurm module with we have set as sticky.

This command is useful to execute in job scripts since it clear the environment of unwanted software that may be loaded by mistake.

Modules

2025-11-20T16:22:30Z

Honfi001:

== Modules in anunna ==

Anunna uses modules via Lmod to provide software to their users. A module configures the environment of the user and/or their jobs to enable the desired application to run.
These modules are organized in "buckets" for each year. We intend to keep three buckets of software, one for the current year, one for the previous year and another for legacy software. The legacy module should contain software that is older than two years and is still used or relevant.

The point is to have a conveyor belt of software and have more up-to-date software with more modern build tools (GCC, MPI, intel), which makes the software more maintainable. The conveyor belt also enables the use of more modern toolchains (foss, intel), which will enable software to run more efficiently.

For each bucket, we intend to keep one version of software.Currently there are five buckets available: legacy, groups, 2023, 2024 and GPU

The new modules have been built with the aid of EasyBuild (https://easybuild.io/)

EasyBuild makes use of publicly shared recipe's, called EasyConfigs. Have a look at their repository for available software:

https://github.com/easybuilders/easybuild-easyconfigs/tree/develop/easybuild/easyconfigs

===Requesting Modules===

In principle, all modules from the above listed repository should be available for installation on Anunna. Please reach out to the admins per support ticket if you want to request the installation of a new module. In the future we plan to build a module deployment pipeline with an easy to use user interface, where modules can be requested and installed with minimal admin interference. More on this later..

===Module Organization===

Modules are to be organized into buckets by year or additional categories. Current buckets are

* '''legacy''' - old software that is no longer maintained or updated, but it is still used in active research.
* '''2023''' - software built using the 2023 compilers and toolchain. It is meant to contain a single version of each software.
* '''2024''' - software built using the 2024 compilers and toolchain. It is meant to contain a single version of each software.
* '''utilities''' - software that is not dependent on specific compilers or toolchains.
* '''groups''' - This bucket contains subfolders containing module files for groups in and outside the WUR.
* '''GPU''' - CUDA, cuDNN and related packages that are independent of toolchains

In order to access the modules of the '''2023''' bucket one needs to execute the following commands:

<pre>module load 2023</pre>

Afterwards, the list of available modules is expanded and this can be verified by running

<pre>module avail</pre>

===Why Buckets?===

As time goes by, software is developed with newer compilers and tools. So the buckets are snapshots of these new compilers and tools that have been used to develop and build these pieces of software. The compilers will determine which processor operations will be supported by the software, so if a job runs software from two different compilers conflicts, errors or unwanted behaviour may occur.

Therefore, it is best to have jobs with software built from the same compiler. This is the purpose of the buckets, where all the software should be built with the same compiler.

==Usage==

===Listing Modules===

The commands that hereby follow will list the modules available to the user in increansing detail. '''overview''' provides a top level view of the software available without going into detail about the different versions available. It will only list the software and the number of versions. The '''avail''' command will list the different versions of the same software. Finally, '''spider''' will provide a verbose list with all the different versions and the description of each.

<pre>
module overview
</pre>

<pre>
module avail
</pre>

<pre>
module spider
</pre>

===Searching For Modules===

The same commands used for listing modules can be used for searching, the only difference is that that the name of the module is passed as an argument. Like the listing in the section above, the commands provide different levels of verbosity.

<pre>
module overview <nameOfModule>
</pre>

<pre>
module avail <nameOfModule>
</pre>

<pre>
module spider <nameOfModule>
</pre>

===Searching For Keywords===

As a more advanced search feature, one can search for keywords inside of modules. This is useful when searching for which modules contain a specific Python or R extension. There are bundle modules for both languages that contain a list of their extensions. Lmod will also search inside the description of the modules, which can be useful for discoverability.

This feature can be used with the following command template:

<pre>module key <keyword></pre>

To illustrate, say that one needs to find a module with the R packager '''terra''' installed. The first step would be to load one of the buckets, for instance 2023.

<pre>module load 2023</pre>

Then, the next step would be to apply the key template above

<pre>module key terra</pre>

which yields the following results

<pre>
The following modules match your search criteria: "terra"
--------------------------------------------------------------------------------------------------------

R-bundle-CRAN: R-bundle-CRAN/2023.12-foss-2023a
Bundle of R packages from CRAN

--------------------------------------------------------------------------------------------------------
</pre>

Hence, one would need to load the module '''R-bundle-CRAN/2023.12-foss-2023a''' to have access to the '''terra''' package

===Loading Modules===

Modules are loaded through the following command template

<pre>module load <moduleName></pre>

The example below show how to load the python module from the 2023 bucket

<pre>
module load 2023
module load Python/3.11.3
</pre>

It is good practice to specify the version of the module being loaded for consistency and reproducibility.

If the version of the module is not specified, lmod will choose the default available version at the time and that may change.

By specifying the version in your submit scripts, it transforms the script into additional documentation.

When loading modules, the dependencies of that module will also be loaded with it.

===List Loaded Modules===

Loaded modules can be listed with following command

<pre>module list</pre>

Following the example in the previous section, after loading the 2023 and the Python/3.11.3 modules (and its dependencies), one can this list the modules loaded

<pre>
user001@login201:~$ module list

Currently Loaded Modules:
1) slurm/24.05.1 (S) 5) binutils/2.40-GCCcore-12.3.0 9) Tcl/8.6.13-GCCcore-12.3.0 13) OpenSSL/1.1
2) 2023 6) bzip2/1.0.8-GCCcore-12.3.0 10) SQLite/3.42.0-GCCcore-12.3.0 14) Python/3.11.3-GCCcore-12.3.0
3) GCCcore/12.3.0 7) ncurses/6.4-GCCcore-12.3.0 11) XZ/5.4.2-GCCcore-12.3.0
4) zlib/1.2.13-GCCcore-12.3.0 8) libreadline/8.2-GCCcore-12.3.0 12) libffi/3.4.4-GCCcore-12.3.0

Where:
S: Module is Sticky, requires --force to unload or purge
</pre>

we can see that aside from the slurm modules (which is loaded by default), the 2023 module and the Python/3.11.3, 11 other dependencies are loaded with the Python/3.11.3 module

===Removing Modules===

Modules can be removed with the following template command

<pre>module unload <moduleName></pre>

Following the example of the python module above, the module can be removed with the following command

<pre>module unload Python/3.11.3</pre>

This command will only unload the Python/3.11.3 module and not its dependencies.

We can see this if we list the loaded modules again

<pre>
user001@login201:~$ module unload Python/3.11.3
user001@login201:~$ module list

Currently Loaded Modules:
1) slurm/24.05.1 (S) 5) binutils/2.40-GCCcore-12.3.0 9) Tcl/8.6.13-GCCcore-12.3.0 13) OpenSSL/1.1
2) 2023 6) bzip2/1.0.8-GCCcore-12.3.0 10) SQLite/3.42.0-GCCcore-12.3.0 14) Python/3.11.3-GCCcore-12.3.0
3) GCCcore/12.3.0 7) ncurses/6.4-GCCcore-12.3.0 11) XZ/5.4.2-GCCcore-12.3.0
4) zlib/1.2.13-GCCcore-12.3.0 8) libreadline/8.2-GCCcore-12.3.0 12) libffi/3.4.4-GCCcore-12.3.0
</pre>

We can completely clean the environment by using the purge command

<pre>module purge</pre>

From our example,

<pre>user001@login201:~$ module purge
The following modules were not unloaded:
(Use "module --force purge" to unload all):

1) slurm/24.05.1</pre>

The only remaining module is the slurm module with we have set as sticky.

This command is useful to execute in job scripts since it clear the environment of unwanted software that may be loaded by mistake.

Apptainer

2025-11-19T12:53:50Z

Honfi001: Update the location of the apptainer modules

Apptainer is a container platform. It allows you to create and run containers that package up pieces of software in a way that is portable and reproducible. You can build a container using Apptainer on your laptop, and then run it on many of the largest HPC clusters in the world, local university or company clusters, a single server, in the cloud, or on a workstation down the hall. Your container is a single file, and you don’t have to worry about how to install all the software you need on each different operating system.

Apptainer is a fork of singularity and, thus, also supports singularity commands and workflows.

==Apptainer on Anunna==

Since Apptainer is not dependent on specific compilers and toolchains, it is now place inside the '''utilities''' bucket. Inside this bucket, there are two options:

* Apptainer
* Apptainer-epel

The regular '''Apptainer''' module loads the version compiled in Anunna. This is more suitable to containers built with more recent operating systems. For most projects this will be enough.

However, some projects still use some very old Linux versions and through errors related to missing versions of GLIBC when running in Anunna. That is where '''Apptainer-epel''' comes in, this is a package distributed by the Fedora Project EPEL (Extra Packages for Enterprise Linux) repositories. This package is built with a broad range of versions of GLIBC in mind, so will likely work with older images like ubuntu 22.04 or older.

One can load apptainer by running the following commands

<pre>module load utilities
module load Apptainer</pre>

==== Initial Setup ====
Apptainer will cache SIF container images generated from remote sources, and any OCI/docker layers used to create them. The cache is created at <code>$HOME/.apptainer/cache</code> by default. The location of the cache can be changed by setting the <code>APPTAINER_CACHEDIR</code> environment variable.

Since there is a limited amount of space available at <code>$HOME</code>, the Apptainer cache can quickly fill your quota. So it is recommended that you set the variable <code>APPTAINER_CACHEDIR</code> to a location ion lustre by edition your <code>$HOME/.bash_aliases</code> file. An example is provided at [[Aliases and local variables]]

Shared folders

2025-10-30T12:56:14Z

Honfi001: /* ACL shared directories on NFS folders */

= Working with shared folders on Anunna =

If you work in a group or team, it is sometimes useful to work within a shared space. Users can thus share inputs to their models and make their outputs also easily available to each other. This article explains how to do so within the Lustre file system and home or archive folder (NFS).

There are two main methods available to you: Access Control List (ACL) access (that you can administer yourself), group access with AD rights or group access within Anunna (which are centrally administered).

Below we will split out the options for each method.

== ACL shared directories ==
=== ACL shared directories on Lustre ===
You may create a folder that can be accessed by yourself and someone else in the following manner:

<pre>cd /lustre/shared
mkdir shared_folder
chmod 700 shared_folder
user=$USER
setfacl -R -m u:${user}:rwx,d:u:${user}:rwx shared_folder</pre>

Then, for each person who you want to have access to this:
<pre>
user=username001
setfacl -R -m u:${user}:rwx,d:u:${user}:rwx shared_folder
</pre>

Note that the command above grants read, write and execute access to '''username001''' , if you just want to grant read access just substitute '''rwx''' by '''r-x'''.

For groups, replace the "u" with "g", like so:
<pre>group=my_group
setfacl -R -m g:${group}:rwx,d:g:${group}:rwx shared_folder</pre>

If you only want to add read rights to the folder, remove the "w" above.
Do not remove the "x" (for execute), as folders need that set for access.

To see the settings, use getfacl:
<pre>
getfacl shared_folder
</pre>

Adding users or groups later can be done using the same method, but it might be hard.
You may have trouble updating ACLs on files that aren't yours, and you cannot change ownership of files to yourself.
Each user with files in the folder will need to update their ACLs appropriately themselves, or you can contact your sysadmins to assist.

=== ACL shared directories on NFS folders===

{{Warning|Due to a missconfiguration, ACL permissions are currently disabled in our nfs shares, which includes the directories at /home and /shared. This will be addressed at the next downtime.}}

If you want to share e.g. you home folder with another user, follow these steps:

==== Set access rights on folder ====

If you want to e.g. allow somebody (as identified by their user id) full read access on your homefolder, run this :
<pre>
setfacl --recursive --modify u:haars001:r-x $HOME
</pre>

== Group shared directories ==

Users access the Anunna cluster with their WUR-wide (Active Directory) or Anunna only account. This means that all the membership information of the AD is also available on Anunna. To check of which groups your user is a member of, use the following command:

<pre>groups <username></pre>

This can result in a rather long list, reflecting permissions in the system. Within these groups you must then identify the one that is closer to match the team or group with which you wish to collaborate.

For instance, if I wish to work together with colleagues at ISRIC, I can search within my groups an appropriate match:

<pre>groups duque004 | grep isric</pre>

In my case the group des-isric-users looked appropriate. Then next step is to confirm if the other users in my team are also members of the group.

If a group isn't available (cooperation with people outside WUR), please ask the administrators for help, they can then set up a group for you.

=== Creating a shared Lustre folder with correct permissions ===

The Lustre file system is accessible in the <code>/lustre</code> folder and then divided into the <code>/backup</code> and <code>/nobackup</code> sections (corresponding to the different usage plans). Inside each of these folders there is a sub-folder named <code>SHARED</code> in which users are to create their own assets.

You start by creating a folder in this space; it is probably better if it matches the name of your group or team, e.g.:

<pre>mkdir /lustre/nobackup/SHARED/myTeamWorkspace</pre>

Or in alternative:

<pre>
cd /lustre/nobackup/SHARED

mkdir myTeamWorkspace
</pre>

=== Setting permissions ===

Three basic steps are involved in stepping permissions correctly:

1. Pass the ownership of the group to the team. In the example below it is applied recursively to all sub-folder and files that may exist:

<pre>chgrp -R my-team-group myTeamWorkspace</pre>

2. Concede read/write permissions to the group. This allows other members of the group to read and write in the shared folder. If you wish other team members to only read from the folder then remove the <code>w</code> character from the <code>+rw</code> bit:

<pre>chmod -R g+rw myTeamWorkspace</pre>

3. Set default ownership within the group. This guarantees that any new files or folders created within the shared folder are owned by default owned by your team group:

<pre>chmod -R g+s myTeamWorkspace</pre>

In case the contents of the shared are sensitive or private, and should be accessed by your team, you can block access from any other users with the following command:

<pre>chmod -R o-rw myTeamWorkspace</pre>

== Further reading ==

[https://www.digitalocean.com/community/tutorials/an-introduction-to-linux-permissions An Introduction to Linux Permissions]

[https://www.linode.com/docs/tools-reference/linux-users-and-groups/ Linux Users and Groups]

[https://www.digitalocean.com/community/tutorials/linux-permissions-basics-and-how-to-use-umask-on-a-vps#types-of-permissions Linux Permissions Basics and How to Use Umask on a VPS]

[http://www.yolinux.com/TUTORIALS/LinuxTutorialManagingGroups.html Linux Tutorial - Managing Group Access on Linux and UNIX]

Python

2025-10-23T15:56:43Z

Honfi001:

Python is a high-level, interpreted programming language that has gained widespread popularity for its readability, versatility, and user-friendly syntax. Created by Guido van Rossum and first released in 1991, Python was designed to emphasize code clarity and reduce the complexity often associated with other languages. Its straightforward, English-like syntax makes it a natural choice for beginners, while its power and flexibility continue to attract experienced developers in numerous industries.

One of Python’s greatest strengths lies in its extensive standard library, which provides built-in modules and functions for tasks ranging from file manipulation to internet protocols. Additionally, a thriving open-source community has developed countless third-party libraries and frameworks, making Python suitable for everything from data analysis and machine learning to web development and automation. Popular libraries like NumPy, Pandas, and TensorFlow enable developers to handle massive datasets, train artificial intelligence models, and build sophisticated applications with relative ease.

Anunna offers environment modules for a single version of python for each bucket. On top of the standard environment modules, bundle modules are available for more specific user cases.

Users can also install their own Python distributions, like [https://mamba.readthedocs.io/en/latest/ Mamba]. While, the use of Anaconda is discouraged.

== Modules ==

Each module year bucket comes with a version of Python installed

* '''2023''': Python/3.11.3
* '''2024''': Python/3.12.3

Additionally, modules of bundles of python extensions are also installed

* Python-bundle-PyPI

== Mamba ==

== Creating Custom Virtual Environments from Modules ==

The HPC team is aware that users may need to build custom python environments for their jobs. These environments can be based off the python environment modules provided by Anunna.

Python virtual environments are self-contained directories that house a specific Python installation and its associated packages, ensuring that one project’s dependencies don’t clash with another. They isolate your software requirements, letting the user manage different versions of libraries or modules in separate, discrete environments. This prevents version conflicts and keeps your system’s base Python environment clean. Tools like ‘venv’ and ‘virtualenv’ simplify creating and activating these spaces, making it straightforward to switch between multiple projects.

* Load the module of the desired Python version
* Create a virtual environment folder
* Activate virtual environment
* Install desired packages with Pip

Firstly, load the module of the desired python version. The example that hereby follows makes use of Python-3.12.3 available at the 2024 bucket.

<pre>
module load 2024
module load Python/3.12.3
</pre>

Once the Python module is loaded, the environment can be created. The environment will be stored in a folder at the location of your choosing. It is not necessary to create the folder beforehand, though in this example it is assumed that the location <code>$MYBKP/PythonEnv</code> already exists. Note that <code>$MYBKP</code> refers to the lustre backup location specified at your <code>~/.bash_aliases</code> file (see our entry on [[Aliases_and_local_variables| Aliases and local variables]])

<pre>
python -m venv $MYBKP/PythonEnv/my_env
</pre>

Once created, the virtual environment needs to be activated in order to be used or modified.

<pre>
source $MYBKP/PythonEnv/my_env/bin/activate
</pre>

After the environment has been activated, you should see the name of the environment as a suffix of your prompt.

<pre>
(my_env) user001@login200:$
</pre>

While the virtual environment is active, you can use pip to install modules directly into your environment

<pre>
pip install -U numpy pandas matplotlib datetime
</pre>

The installed modules are stored at $MYBKP/PythonEnv/my_env/lib/python3.12/site-packages/.

Note

== Creating Jupyter kernels from virtual environments ==

It is often the case that users need to have a custom environment in jupyter. This can be facilitated with virtual environments. Assuming we use the virtual environment from the previous section, we just need to

* load the required modules
* activate the environment
* install the '''ipython''' package
* generate the kernel
* Write a wrapper script
* Make the wrapper script executable
* Edit the kernel file

First, load the required modules.

<pre>
module load 2024
module load Python/3.12.3
</pre>

Then activate the environment

<pre>
source $myBKP/PythonEnv/my_env/bin/activate
</pre>

Install the ipykernel package

<pre>
pip install ipykernel
</pre>

Run the command below to generate a kernel. Enter the desired name for the kernel with the flag <code>--name</code>

<pre>
python -m ipykernel install --user --name=my_env_kernel_name
</pre>

The kernel will be written to your home folder, more precisely <code>~/.local/share/jupyter/kernels/</code>.
This location will be monitored by jupyter, which should display your custom kernel as one of the kernel options.

As it is, the kernel will not work on jupyter because it will not be able to find the necessary modules to run it. A workaround is, then, to write a wrapper script to load the modules inside the kernel.

<pre>
#!/bin/bash -l

module reset
# modules to load
module load 2024
module load Python/3.12.3
# wrapper line
# exec <pathToVirtualEnvPythonExecutable> -m ipykernel_launcher "$@"
exec /lustre/scratch/<AFFILIATION>/<GROUP>/user001/PythonEnv/my_env/bin/bin/python -m ipykernel_launcher "$@"
</pre>

The wrapper script uses <code>#!/bin/bash -l</code> as the interpreter of the script. The <code>-l</code> flag tell bash to start as a login shell, which loads lmod by default. The modules are reset and the desired buckets and modules are loads.

Finally, the wrapper script executes the module '''ipykernel_launcher''' from the virtual environment we just created. In this example, the code above is saved in <code>/home/WUR/user001/wrap.sh</code> . Make sure the wrapper script is executable.

The last thing to do now is to modify the kernel.json file of the jupyter kernel created above. It should be located at <code>~/.local/share/jupyter/kernels/my_env_kernel_name/kernel.json</code>

<pre>
{
"argv": [
"/home/WUR/user001/wrap.sh",
"-f",
"{connection_file}"
],
"display_name": "Python modTest",
"language": "python",
"metadata": {
"debugger": true
}
}
</pre>

This kernel differs from a vanilla kernel file by specifying the location of the wrapper script as the first string passed to '''argv'''. Now that the modules are loaded, the kernel should be able to run on jupyter.

Python

2025-10-22T13:14:48Z

Honfi001:

Python is a high-level, interpreted programming language that has gained widespread popularity for its readability, versatility, and user-friendly syntax. Created by Guido van Rossum and first released in 1991, Python was designed to emphasize code clarity and reduce the complexity often associated with other languages. Its straightforward, English-like syntax makes it a natural choice for beginners, while its power and flexibility continue to attract experienced developers in numerous industries.

One of Python’s greatest strengths lies in its extensive standard library, which provides built-in modules and functions for tasks ranging from file manipulation to internet protocols. Additionally, a thriving open-source community has developed countless third-party libraries and frameworks, making Python suitable for everything from data analysis and machine learning to web development and automation. Popular libraries like NumPy, Pandas, and TensorFlow enable developers to handle massive datasets, train artificial intelligence models, and build sophisticated applications with relative ease.

Anunna offers environment modules for a single version of python for each bucket. On top of the standard environment modules, bundle modules are available for more specific user cases.

Users can also install their own Python distributions, like [https://mamba.readthedocs.io/en/latest/ Mamba]. While, the use of Anaconda is discouraged.

== Modules ==

Each module year bucket comes with a version of Python installed

* '''2023''': Python/3.11.3
* '''2024''': Python/3.12.3

Additionally, modules of bundles of python extensions are also installed

* Python-bundle-PyPI

== Mamba ==

== Creating Custom Virtual Environments from Modules ==

The HPC team is aware that users may need to build custom python environments for their jobs. These environments can be based off the python environment modules provided by Anunna.

Python virtual environments are self-contained directories that house a specific Python installation and its associated packages, ensuring that one project’s dependencies don’t clash with another. They isolate your software requirements, letting the user manage different versions of libraries or modules in separate, discrete environments. This prevents version conflicts and keeps your system’s base Python environment clean. Tools like ‘venv’ and ‘virtualenv’ simplify creating and activating these spaces, making it straightforward to switch between multiple projects.

* Load the module of the desired Python version
* Create a virtual environment folder
* Activate virtual environment
* Install desired packages with Pip

Firstly, load the module of the desired python version. The example that hereby follows makes use of Python-3.12.3 available at the 2024 bucket.

<pre>
module load 2024
module load Python/3.12.3
</pre>

Once the Python module is loaded, the environment can be created. The environment will be stored in a folder at the location of your choosing. It is not necessary to create the folder beforehand, though in this example it is assumed that the location <code>$MYBKP/PythonEnv</code> already exists. Note that <code>$MYBKP</code> refers to the lustre backup location specified at your <code>~/.bash_aliases</code> file (see our entry on [[Aliases_and_local_variables| Aliases and local variables]])

<pre>
python -m venv $MYBKP/PythonEnv/my_env
</pre>

Once created, the virtual environment needs to be activated in order to be used or modified.

<pre>
source $MYBKP/PythonEnv/my_env/bin/activate
</pre>

After the environment has been activated, you should see the name of the environment as a suffix of your prompt.

<pre>
(my_env) user001@login200:$
</pre>

While the virtual environment is active, you can use pip to install modules directly into your environment

<pre>
pip install -U numpy pandas matplotlib datetime
</pre>

The installed modules are stored at $MYBKP/PythonEnv/my_env/lib/python3.12/site-packages/.

Note

== Creating Jupyter kernels from virtual environments ==

It is often the case that users need to have a custom environment in jupyter. This can be facilitated with virtual environments. Assuming we use the virtual environment from the previous section, we just need to

* load the required modules
* activate the environment
* install the '''ipython''' package
* generate the kernel
* Write a wrapper script
* Make the wrapper script executable
* Edit the kernel file

First, load the required modules.

<pre>
module load 2024
module load Python/3.12.3
</pre>

Then activate the environment

<pre>
source $myBKP/PythonEnv/my_env/bin/activate
</pre>

Install the ipykernel package

<pre>
pip install ipykernel
</pre>

Run the command below to generate a kernel. Enter the desired name for the kernel with the flag <code>--name</code>

<pre>
python -m ipykernel install --user --name=my_env_kernel_name
</pre>

The kernel will be written to your home folder, more precisely <code>~/.local/share/jupyter/kernels/</code>.
This location will be monitored by jupyter, which should display your custom kernel as one of the kernel options.

As it is, the kernel will not work on jupyter because it will not be able to find the necessary modules to run it. A workaround is, then, to write a wrapper script to load the modules inside the kernel.

<pre>
#!/bin/bash -l

module reset
# modules to load
module load 2024
module load Python/3.12.3
# wrapper line
# exec <pathToVirtualEnvPythonExecutable> -m ipykernel_launcher "$@"
exec /lustre/scratch/<AFFILIATION>/<GROUP>/user001/PythonEnv/my_env/bin/bin/python -m ipykernel_launcher "$@"
</pre>

The code above initializes lmod by sourcing <code>/etc/bash.bashrc</code>, then it loaded the modules required by the environment. Finally, it executes ipykernel_launcher from the virtual environment created. In this example, the code above is saved in <code>/home/WUR/user001/wrap.sh</code> . Make sure the wrapper script is executable.

The last thing to do now is to modify the kernel.json file of the jupyter kernel created above. It should be located at <code>~/.local/share/jupyter/kernels/my_env_kernel_name/kernel.json</code>

<pre>
{
"argv": [
"/home/WUR/user001/wrap.sh",
"-f",
"{connection_file}"
],
"display_name": "Python modTest",
"language": "python",
"metadata": {
"debugger": true
}
}
</pre>

This kernel differs from a vanilla kernel file by specifying the location of the wrapper script as the first string passed to '''argv'''. Now that the modules are loaded, the kernel should be able to run on jupyter.