Technikraum

Systemd timers are a powerful alternative to cron jobs for scheduling tasks. They offer greater flexibility and better integration into the systemd ecosystem. In this article, I’ll show you how to set up and use systemd timers.

What is a systemd timer?

A systemd timer is a systemd unit that schedules another service to run at specific times. Timers replace cron jobs and offer advantages such as:

• Better logging with journalctl.
• The ability to define dependencies and startup conditions.
• More precise control over execution times.

Basic Structure

A systemd timer consists of two files:

1. Service file: Defines what should be executed.
2. Timer file: Defines when the service should be executed.

Both files are stored in the /etc/systemd/system/ directory.

Step 1: Create the Service File

The service file describes the action to be executed. For example, let’s run a script located at /usr/local/bin/backup.sh.

Create a file named backup.service:

nano /etc/systemd/system/backup.service

Content of the file:

[Unit]
Description=Backup Script
After=network.target

[Service]
Type=oneshot
ExecStart=/usr/local/bin/backup.sh

Explanation:

• [Unit]: Describes the unit. Description provides a short description, and After=network.target ensures the network is available before the service starts.
• [Service]: Defines the service. Type=oneshot means the service performs a one-time action. ExecStart specifies the command or script to be executed.

Step 2: Create the Timer File

The timer file defines when the service should be executed. Create a file named backup.timer:

nano /etc/systemd/system/backup.timer

Content of the file:

[Unit]
Description=Run Backup Script Daily

[Timer]
OnCalendar=daily
Persistent=true

[Install]
WantedBy=timers.target

Explanation:

• [Unit]: Similar to the service file, this provides a short description.
• [Timer]: Defines the scheduling.
  • OnCalendar=daily: Runs the service daily at midnight. Other time specifications can also be used (see below).
  • Persistent=true: Ensures the timer runs after a restart, even if it was missed during downtime.
• [Install]: WantedBy=timers.target ensures the timer is activated at system startup.

Time Specifications for systemd Timers

The time for a systemd timer is defined in the timer file using the OnCalendar option. Systemd supports a flexible and powerful time format for both simple and complex schedules. Here are some examples and explanations:

Basic Format

The general format for OnCalendar is:

OnCalendar=YYYY-MM-DD HH:MM:SS

• YYYY: Year (e.g., 2025)
• MM: Month (01 to 12)
• DD: Day (01 to 31)
• HH: Hour (00 to 23)
• MM: Minute (00 to 59)
• SS: Second (00 to 59)

You can use wildcards (*) to make certain parts flexible.

Common Time Specifications

1. Hourly (every full hour):

   OnCalendar=hourly
   

   Equivalent to: *-*-* *:00:00

2. Daily at midnight:

   OnCalendar=daily
   

   Equivalent to: *-*-* 00:00:00

3. Weekly (Sunday at midnight):

   OnCalendar=weekly
   

   Equivalent to: Sun *-*-* 00:00:00

4. Monthly (1st day of the month at midnight):

   OnCalendar=monthly
   

   Equivalent to: *-*-01 00:00:00

5. Yearly (January 1st at midnight):

   OnCalendar=yearly
   

   Equivalent to: *-01-01 00:00:00

Custom Time Specifications

1. Every day at 15:30:

   OnCalendar=*-*-* 15:30:00
   

2. Every Monday at 08:00:

   OnCalendar=Mon *-*-* 08:00:00
   

3. Every first day of the month at 12:00:

   OnCalendar=*-*-01 12:00:00
   

4. Every last day of the month at 23:59:

   OnCalendar=*-*-28..31 23:59:00
   

   (Systemd automatically detects the last day of the month, e.g., 28, 30, or 31.)

5. Every second day at 06:00:

   OnCalendar=*-*-1,3,5,7,9,11,13,15,17,19,21,23,25,27,29,31 06:00:00
   

Repetitions and Intervals

1. Every 5 minutes:

   OnCalendar=*:0/5
   

   (Runs at minute 0, 5, 10, 15, etc., every hour.)

2. Every 2 hours:

   OnCalendar=*-*-* 0/2:00:00
   

   (Runs at 00:00, 02:00, 04:00, etc.)

3. Every 15 minutes:

   OnCalendar=*:0/15
   

   (Runs at 00, 15, 30, and 45 minutes past the hour.)

4. Every 10 days:

   OnCalendar=*-*-01,11,21 00:00:00
   

Step 3: Reload Systemd

After creating the files, reload the systemd configuration:

systemctl daemon-reload

Step 4: Enable and Start the Timer

Enable the timer so it starts automatically at system boot:

systemctl enable --now backup.timer

The --now flag starts the timer immediately. If you want to start it manually, omit --now and use:

systemctl start backup.timer

Step 5: Verify the Timer

To ensure the timer is set up correctly, check its status:

systemctl status backup.timer

Optional Commands and Tips

1. List all timers:

   systemctl list-timers --all
   

   This displays all active and inactive timers, including their next and last execution times.

2. Check service status:

   systemctl status backup.service
   

3. View service logs:

   journalctl -u backup.service
   

4. Stop or disable a timer:

   • Stop the timer:

     systemctl stop backup.timer
     

   • Disable the timer:

     systemctl disable backup.timer
     

Initially, I planned to use Woodpecker to check my Ansible files. When the initial strategy didn't work optimally, I developed a local script that automatically checks all changed files before each commit. What initially looked like a pragmatic adaptation evolved into an indispensable tool in my development process.

What Does the Script Do?

The script .helper/validate_ansible.sh is a comprehensive validation tool for Ansible projects. It performs various checks to ensure that my infrastructure-as-code remains clean, consistent, and error-free.

Features

1. YAML File Syntax Validation

   • Uses ansible-playbook --syntax-check
   • Checks playbooks, role tasks, and other YAML files
   • Detects structural errors before commit

2. Ansible-Lint

   • Additional quality check for Ansible files
   • Provides hints for potential improvements
   • Helps maintain best practices

3. Inventory Validation

   • Checks inventory files with ansible-inventory
   • Identifies configuration inconsistencies
   • Ensures host groups and variables are correctly defined

4. Jinja2 Template Check

   • Validates syntax of .j2 template files
   • Ensures templates are correctly structured
   • Prevents runtime rendering errors

Flexibility of Use

The script can be executed in various modes:

• Standard: Checks only git-changed files
• --all: Checks all files in the project
• Selective Check: Only playbooks, inventories, or templates as needed

Integration as Git Hook

To enforce checking directly during commit, I implemented a .git/hooks/pre-commit hook:

#!/bin/bash
SCRIPT_PATH=".helper/validate_ansible.sh"

if [[ ! -x "$SCRIPT_PATH" ]]; then
  echo "Error: Script not executable"
  exit 1
fi

if ! "$SCRIPT_PATH"; then
  echo "Error: Commit aborted"
  exit 1
fi

exit 0

This hook ensures that no potentially problematic code can be committed.

Advantages

• Automatic Quality Assurance
• Early Error Detection
• Consistent Code Quality
• Seamless Integration into Development Process
• Reduction of Manual Checks
• Increased Infrastructure Stability

Technical Details

• Language: Bash Script
• Dependencies:
  • ansible-playbook
  • ansible-inventory
  • ansible-lint
  • yamllint
  • Python3 with Jinja2

Conclusion

What began as a pragmatic solution developed into a robust tool. The script not only saves time but also increases the quality and reliability of my Ansible infrastructure. It's a prime example of how small, custom-developed tools can elegantly tackle significant challenges.

Ursprünglich plante ich, Woodpecker für die Überprüfung meiner Ansible-Dateien einzusetzen. Als die initiale Strategie nicht optimal funktionierte, entwickelte ich ein lokales Skript, das vor jedem Commit alle geänderten Dateien automatisch prüft. Was zunächst wie eine pragmatische Anpassung aussah, entwickelte sich zu einem unverzichtbaren Werkzeug in meinem Entwicklungsprozess.

Was macht das Skript?

Das Skript .helper/validate_ansible.sh ist ein Validierungstool für Ansible-Projekte. Es führt verschiedene Checks durch, die sicherstellen, dass meine Infrastruktur-als-Code sauber, konsistent und fehlerfrei bleibt.

Funktionen

1. Syntax-Prüfung für YAML-Dateien

   • Verwendet ansible-playbook --syntax-check
   • Prüft Playbooks, Rolle-Tasks und andere YAML-Dateien
   • Erkennt Strukturfehler bereits vor dem Commit

2. Ansible-Lint

   • Zusätzliche Qualitätsprüfung der Ansible-Dateien
   • Gibt Hinweise bei Verbesserungsmöglichkeiten
   • Hilft, Best Practices einzuhalten

3. Inventar-Validierung

   • Überprüft Inventar-Dateien mit ansible-inventory
   • Erkennt Konfigurationsunstimmigkeiten
   • Stellt sicher, dass Hostgruppen und Variablen korrekt definiert sind

4. Jinja2 Template-Check

   • Validiert Syntax von .j2 Template-Dateien
   • Stellt sicher, dass Templates korrekt aufgebaut sind
   • Verhindert Rendering-Fehler zur Laufzeit

Flexibilität der Nutzung

Das Skript kann in verschiedenen Modi ausgeführt werden:

• Standard: Prüft nur git-veränderte Dateien
• --all: Prüft alle Dateien im Projekt
• Selektive Prüfung: Nur Playbooks, Inventare oder Templates nach Bedarf

Integration als Git-Hook

Um die Prüfung direkt beim Commit zu erzwingen, habe ich einen .git/hooks/pre-commit Hook implementiert:

#!/bin/bash
SCRIPT_PATH=".helper/validate_ansible.sh"

if [[ ! -x "$SCRIPT_PATH" ]]; then
  echo "Fehler: Skript nicht ausführbar"
  exit 1
fi

if ! "$SCRIPT_PATH"; then
  echo "Fehler: Commit abgebrochen"
  exit 1
fi

exit 0

Dieser Hook stellt sicher, dass kein potenziell problematischer Code committed werden kann.

Vorteile

• Automatische Qualitätssicherung
• Frühe Fehlererkennung
• Konsistente Code-Qualität
• Nahtlose Integration in Entwicklungsprozess
• Reduzierung manueller Überprüfungen
• Erhöhung der Infrastruktur-Stabilität

Technische Details

• Sprache: Bash-Skript
• Abhängigkeiten:
  • ansible-playbook
  • ansible-inventory
  • ansible-lint
  • yamllint
  • Python3 mit Jinja2

Fazit

Was als pragmatische Lösung begann, entwickelte sich zu einem robusten Werkzeug. Das Skript spart nicht nur Zeit, sondern erhöht auch die Qualität und Zuverlässigkeit meiner Ansible-Infrastruktur. Es ist ein Paradebeispiel dafür, wie kleine, selbstentwickelte Tools große Herausforderungen elegant bewältigen können.

In this article, I'll guide you through setting up a Mumble server using Docker, with automatic Let's Encrypt certificates for secure connections. We'll use Docker Compose, Certbot, and environment variables to make the configuration flexible and straightforward.

---

What Does This Configuration Do?

1. Certbot:

   • Certbot is a tool that generates and renews certificates from Let's Encrypt. It runs in standalone mode to generate an SSL/TLS certificate for your Mumble server.
   • The certificate is stored in a local directory and used by the Mumble server to enable encrypted connections.

2. Mumble Server:

   • The Mumble server runs in a Docker container and is configured to use the certificate generated by Certbot for secure connections.
   • It waits for Certbot to generate the certificate before starting.

3. Environment Variables:

   • The configuration uses environment variables for the email address and domain. This makes it easy to change the settings without directly modifying the Docker Compose file.

---

Prerequisites

1. Docker and Docker Compose:

   • Ensure Docker and Docker Compose are installed on your server. You can verify this with the following commands:

     docker --version
     docker-compose --version
     

2. Domain:

   • You need a domain that points to your server's IP address. In this example, we use the domain domain.server.de.

3. Ports:

   • Ensure ports 80 (HTTP) and 64738 (Mumble) are open on your server.

---

Step-by-Step Guide

1. Create a Project Directory

Create a new directory for your project and navigate into it:

mkdir mumble-docker
cd mumble-docker

2. Create the Docker Compose File

Create a file named docker-compose.yml and add the following configuration:

services:
  certbot:
    image: certbot/certbot:latest
    container_name: certbot
    ports:
      - 80:80
    volumes:
      - ./data/letsencrypt:/etc/letsencrypt
    entrypoint: >
      sh -c "certbot certonly --standalone --non-interactive --agree-tos --email
      ${CERTBOT_EMAIL} -d ${CERTBOT_DOMAIN}"
    restart: no

  mumble-server:
    image: mumblevoip/mumble-server:latest
    container_name: mumble-server
    ports:
      - 64738:64738
    volumes:
      - ./data:/data
      - ./letsencrypt:/letsencrypt
    environment:
      - MUMBLE_CONFIG_SSL_CERT=/letsencrypt/live/${CERTBOT_DOMAIN}/fullchain.pem
      - MUMBLE_CONFIG_SSL_KEY=/letsencrypt/live/${CERTBOT_DOMAIN}/privkey.pem
    restart: always
    depends_on:
      - certbot

networks: {}
x-dockge:
  urls:
    - mumble://${CERTBOT_DOMAIN}?version=1.2.0
    - http://162.55.131.56:64738/

3. Define Environment Variables

Create a file named .env in the same directory and add the following variables:

CERTBOT_EMAIL=mailadresse@server.de
CERTBOT_DOMAIN=domain.server.de

This file will be automatically loaded by Docker Compose and replace the variables in the docker-compose.yml.

4. Prepare the Directory Structure

Create the necessary directories for certificates and data:

mkdir -p data/letsencrypt

5. Start the Services

Start the services using Docker Compose:

docker-compose up

• The Certbot container will start and generate a certificate for the specified domain.
• The Mumble server container will wait until the certificate is available and then start with the configuration for encrypted connections.

6. Verify Everything Works

• Open your Mumble client and connect to mumble://domain.server.de.
• Your Mumble server should now be running with a valid SSL certificate.

---

Automatic Certificate Renewal

Let's Encrypt certificates are only valid for 90 days. To renew the certificates, you can restart the container to renew the certificates:

docker-compose run certbot

In diesem Artikel zeige ich dir, wie du einen Mumble-Server mit Docker betreibst und dabei automatisch ein Let's Encrypt-Zertifikat für eine sichere Verbindung einrichtest. Wir verwenden dafür Docker Compose, Certbot und Umgebungsvariablen, um die Konfiguration flexibel und einfach zu gestalten.

Was macht diese Konfiguration?

1. Certbot:

   • Certbot ist ein Tool, das Zertifikate von Let's Encrypt erstellt und erneuert. Es wird im Standalone-Modus ausgeführt, um ein SSL/TLS-Zertifikat für deinen Mumble-Server zu generieren.
   • Das Zertifikat wird in einem lokalen Verzeichnis gespeichert und vom Mumble-Server verwendet, um verschlüsselte Verbindungen zu ermöglichen.

2. Mumble-Server:

   • Der Mumble-Server wird in einem Docker-Container ausgeführt und konfiguriert, um das von Certbot generierte Zertifikat für sichere Verbindungen zu nutzen.
   • Er wartet darauf, dass Certbot das Zertifikat erstellt, bevor er startet.

3. Umgebungsvariablen:

   • Die Konfiguration verwendet Umgebungsvariablen für die E-Mail-Adresse und die Domain. Dadurch kannst du die Einstellungen leicht ändern, ohne die Docker-Compose-Datei direkt bearbeiten zu müssen.

Voraussetzungen

1. Docker und Docker Compose:

   • Stelle sicher, dass Docker und Docker Compose auf deinem Server installiert sind. Du kannst dies mit den folgenden Befehlen überprüfen:

     docker --version
     docker-compose --version
     

2. Domain:

   • Du benötigst eine Domain, die auf die IP-Adresse deines Servers zeigt. In diesem Beispiel verwenden wir die Domain domain.server.de.

3. Ports:

   • Stelle sicher, dass die Ports 80 (HTTP) und 64738 (Mumble) auf deinem Server geöffnet sind.

Schritt-für-Schritt-Anleitung

1. Projektverzeichnis erstellen

Erstelle ein neues Verzeichnis für dein Projekt und wechsle in dieses Verzeichnis:

mkdir mumble-docker
cd mumble-docker

2. Docker-Compose-Datei erstellen

Erstelle eine Datei namens docker-compose.yml und füge die folgende Konfiguration ein:

services:
  certbot:
    image: certbot/certbot:latest
    container_name: certbot
    ports:
      - 80:80
    volumes:
      - ./data/letsencrypt:/etc/letsencrypt
    entrypoint: >
      sh -c "certbot certonly --standalone --non-interactive --agree-tos --email
      ${CERTBOT_EMAIL} -d ${CERTBOT_DOMAIN}"
    restart: no

  mumble-server:
    image: mumblevoip/mumble-server:latest
    container_name: mumble-server
    ports:
      - 64738:64738
    volumes:
      - ./data:/data
      - ./letsencrypt:/letsencrypt
    environment:
      - MUMBLE_CONFIG_SSL_CERT=/letsencrypt/live/${CERTBOT_DOMAIN}/fullchain.pem
      - MUMBLE_CONFIG_SSL_KEY=/letsencrypt/live/${CERTBOT_DOMAIN}/privkey.pem
    restart: always
    depends_on:
      - certbot

3. Umgebungsvariablen definieren

Erstelle eine Datei namens .env im gleichen Verzeichnis und füge die folgenden Variablen hinzu:

CERTBOT_EMAIL=mailadresse@server.de
CERTBOT_DOMAIN=domain.server.de

Diese Datei wird von Docker Compose automatisch geladen und ersetzt die Variablen in der docker-compose.yml.

4. Verzeichnisstruktur vorbereiten

Erstelle die benötigten Verzeichnisse für die Zertifikate und Daten:

mkdir -p data
mkdir -p letsencrypt

5. Dienste starten

Starte die Dienste mit Docker Compose:

docker-compose up

• Der Certbot-Container wird gestartet und erstellt ein Zertifikat für die angegebene Domain.
• Der Mumble-Server-Container wartet, bis das Zertifikat verfügbar ist, und startet dann mit der Konfiguration für verschlüsselte Verbindungen.

6. Überprüfen, ob alles funktioniert

• Öffne deinen Mumble-Client und verbinde dich mit mumble://domain.server.de.
• Dein Mumble-Server sollte jetzt mit einem gültigen SSL-Zertifikat laufen.

---

Automatische Zertifikatserneuerung

Let's Encrypt-Zertifikate sind nur 90 Tage gültig. Um die Zertifikate zu erneuern, kannst du den Container manuell starten, um die Zertifikate zu erneuern:

docker-compose run certbot

Logical Volume Management (LVM) is a flexible method for managing storage on Linux systems. It allows you to dynamically adjust storage space without recreating partitions or deleting data. This guide explains how to create, extend, and permanently mount an LVM.

Create LVM

Create a Physical Volume (PV)

A Physical Volume (PV) is the foundation of LVM. It represents a physical disk or partition to be used by LVM. To create a PV, run:

pvcreate /dev/sdb

Explanation:

• /dev/sdb is the disk you want to use for LVM. Replace it with the actual device name of your disk.
• This step marks the disk as LVM-compatible and prepares it for use in a Volume Group.##

Create a Volume Group (VG)

A Volume Group (VG) is a collection of Physical Volumes. It provides the storage space from which Logical Volumes are created. To create a VG and add the previously created PV, use:

vgcreate vg_data /dev/sdb

Explanation:

• vg_data is the name of the Volume Group. You can choose any name that makes sense for your setup.
• /dev/sdb is the Physical Volume to be added to the Volume Group.##

Create a Logical Volume (LV)

A Logical Volume (LV) is the actual usable storage space allocated from a Volume Group. To create an LV that uses all available space in the Volume Group, run:

lvcreate -l 100%FREE -n lv_data vg_data

Explanation:

• -l 100%FREE allocates all available space in the Volume Group to the Logical Volume.
• -n lv_data assigns the name lv_data to the Logical Volume.
• vg_data is the Volume Group from which the space is allocated.##

Create a Filesystem

To use the Logical Volume, you need to create a filesystem on it. In this example, we use the ext4 filesystem:

mkfs.ext4 /dev/vg_data/lv_data

Explanation:

• /dev/vg_data/lv_data is the path to the Logical Volume.
• The ext4 filesystem is a common choice for Linux systems, but you can use other filesystems like XFS or btrfs depending on your requirements.##

Extend LVM

If you need more storage space, you can extend an existing LVM. Follow these steps:

Resize the Physical Volume (PV)

If the underlying disk has been expanded (e.g., by adding more storage in a virtual machine), you need to update the Physical Volume:

pvresize /dev/sdb

Explanation:

• This command adjusts the size of the Physical Volume to match the new size of the disk.
• /dev/sdb is the disk you are resizing.##

Extend the Logical Volume (LV)

To use the additional storage space, extend the Logical Volume:

lvextend -l +100%FREE /dev/vg_data/lv_data

Explanation:

• -l +100%FREE extends the Logical Volume by using all available free space in the Volume Group.
• /dev/vg_data/lv_data is the Logical Volume you are extending.##

Resize the Filesystem

After extending the Logical Volume, you need to resize the filesystem to utilize the new space:

resize2fs /dev/mapper/vg_data-lv_data

Explanation:

• resize2fs adjusts the size of the ext4 filesystem to match the new size of the Logical Volume.
• /dev/mapper/vg_data-lv_data is the path to the Logical Volume.##

Add Entry to /etc/fstab

To ensure the Logical Volume is automatically mounted at system startup, you need to add it to the /etc/fstab file.

Display the UUID

Find the UUID of the Logical Volume:

lsblk -f

Explanation:

• The UUID is a unique identifier for the Logical Volume. It is required to add the volume to /etc/fstab.##

Add Entry to /etc/fstab

Add the UUID to the /etc/fstab file so the volume is mounted automatically at boot:

echo "UUID=foo /mnt/data ext4 defaults 0 0" >> /etc/fstab

Explanation:

• Replace foo with the actual UUID of the Logical Volume.
• /mnt/data is the mount point where the Logical Volume will be accessible. Adjust this to your desired directory.
• ext4 is the filesystem type. Use the appropriate type if you used a different filesystem.##

Reload Systemd

Reload the Systemd configuration to apply the changes:

systemctl daemon-reload

Explanation:

• This ensures that Systemd recognizes the updated /etc/fstab configuration.##

Mount the Volume

Finally, mount the volume to verify that everything is working correctly:

mount -a

Explanation:

• This command mounts all filesystems listed in /etc/fstab. If there are no errors, the Logical Volume should now be mounted and accessible.

Logical Volume Management (LVM) ist eine flexible Methode, um Speicherplatz auf Linux-Systemen zu verwalten. Es ermöglicht die dynamische Anpassung von Speicherplatz, ohne dass Partitionen neu erstellt oder Daten gelöscht werden müssen. Diese Anleitung zeigt, wie man ein neues LVM erstellt, erweitert und dauerhaft einbindet.

LVM erstellen

Physical Volume (PV) erstellen

Ein Physical Volume (PV) ist die Grundlage für LVM. Es repräsentiert eine physische Festplatte oder Partition, die für LVM verwendet werden soll. Um ein PV zu erstellen, führe den folgenden Befehl aus:

pvcreate /dev/sdb

Erklärung:

• /dev/sdb ist die Festplatte, die du für LVM verwenden möchtest. Ersetze sie durch den tatsächlichen Gerätenamen deiner Festplatte.
• Dieser Schritt markiert die Festplatte als LVM-kompatibel.

Volume Group (VG) erstellen

Eine Volume Group (VG) ist eine Sammlung von Physical Volumes. Sie stellt den Speicherplatz bereit, aus dem Logical Volumes erstellt werden können. Um eine VG zu erstellen und das vorher erstellte PV hinzuzufügen, nutze:

vgcreate vg_data /dev/sdb

Erklärung:

• vg_data ist der Name der Volume Group. Du kannst einen beliebigen Namen wählen.
• /dev/sdb ist das Physical Volume, das du hinzufügen möchtest.

Logical Volume (LV) erstellen

Ein Logical Volume (LV) ist der tatsächlich nutzbare Speicherplatz, der aus einer Volume Group bereitgestellt wird. Um ein LV zu erstellen, das den gesamten freien Speicherplatz der Volume Group nutzt, führe aus:

lvcreate -l 100%FREE -n lv_data vg_data

Erklärung:

• -l 100%FREE weist dem Logical Volume den gesamten verfügbaren Speicherplatz der Volume Group zu.
• -n lv_data gibt dem Logical Volume den Namen lv_data.
• vg_data ist die Volume Group, aus der der Speicherplatz entnommen wird.

Dateisystem erstellen

Um das Logical Volume nutzen zu können, muss ein Dateisystem darauf erstellt werden. In diesem Beispiel wird das ext4-Dateisystem verwendet:

mkfs.ext4 /dev/vg_data/lv_data

Erklärung:

• /dev/vg_data/lv_data ist der Pfad zum Logical Volume.
• Das Dateisystem ext4 ist eine gängige Wahl für Linux-Systeme, aber du kannst auch andere Dateisysteme wie XFS oder btrfs verwenden.

LVM erweitern

Falls du mehr Speicherplatz benötigst, kannst du ein bestehendes LVM erweitern. Hier sind die Schritte:

Physical Volume (PV) vergrößern

Falls die zugrunde liegende Festplatte erweitert wurde (z. B. durch Hinzufügen von mehr Speicherplatz in einer virtuellen Maschine), musst du das Physical Volume aktualisieren:

pvresize /dev/sdb

Erklärung:

• Dieser Befehl passt die Größe des Physical Volumes an die neue Größe der Festplatte an.

Logical Volume (LV) vergrößern

Um den zusätzlichen Speicherplatz zu nutzen, erweitere das Logical Volume:

lvextend -l +100%FREE /dev/vg_data/lv_data

Erklärung:

• -l +100%FREE erweitert das Logical Volume um den gesamten verfügbaren Speicherplatz in der Volume Group.
• /dev/vg_data/lv_data ist das Logical Volume, das erweitert wird.

Dateisystem vergrößern

Nach der Erweiterung des Logical Volumes muss das Dateisystem angepasst werden, um den neuen Speicherplatz zu nutzen:

resize2fs /dev/mapper/vg_data-lv_data

Erklärung:

• resize2fs passt die Größe des ext4-Dateisystems an.
• /dev/mapper/vg_data-lv_data ist der Pfad zum Logical Volume.

Eintrag in /etc/fstab hinzufügen

Damit das Logical Volume beim Systemstart automatisch eingehängt wird, musst du es in die Datei /etc/fstab eintragen.

UUID anzeigen

Finde die UUID des Logical Volumes heraus:

lsblk -f

Erklärung:

• Die UUID ist eine eindeutige Kennung für das Logical Volume. Sie wird benötigt, um das Volume in /etc/fstab einzutragen.

Eintrag in /etc/fstab hinzufügen

Füge die UUID in die Datei /etc/fstab ein, damit das Volume automatisch eingehängt wird:

echo "UUID=foo /mnt/data ext4 defaults 0 0" >> /etc/fstab

Erklärung:

• Ersetze foo durch die tatsächliche UUID des Logical Volumes.
• /mnt/data ist der Einhängepunkt. Passe diesen an deine Anforderungen an.
• ext4 ist das Dateisystem, das du verwendet hast.

Systemd neu laden

Lade die Systemd-Konfiguration neu, um die Änderungen zu übernehmen:

systemctl daemon-reload

Mount einhängen

Hänge das Volume ein, um sicherzustellen, dass es korrekt funktioniert:

mount -a

Install LiveKit JWT Service

1. Navigate to the /opt directory:

cd /opt

2. Clone the repository:

git clone https://github.com/element-hq/lk-jwt-service.git
cd lk-jwt-service

3. Build the executable:

go build -o lk-jwt-service .
/usr/local/go/bin/go build -o lk-jwt-service .

4. Install the LiveKit CLI tool:

curl -sSL https://get.livekit.io/ | bash

Install and Configure JWT Service

1. Create the file /etc/systemd/system/lk-jwt-service.service with the following content:

[Unit]
Description=LiveKit JWT Service
After=network.target
Requires=livekit-server.service

[Service]
Restart=always
WorkingDirectory=/opt/lk-jwt-service
Environment="LIVEKIT_URL=wss://rtc.domain.com/"
Environment="LIVEKIT_KEY=xxx"
Environment="LIVEKIT_SECRET=xxx"
Environment="LIVEKIT_JWT_PORT=8080"
ExecStart=/opt/lk-jwt-service/lk-jwt-service

[Install]
WantedBy=multi-user.target

2. Ensure the executable is in the correct directory:

cp lk-jwt-service /opt/lk-jwt-service/

Install and Configure LiveKit Server

1. Create the file /etc/systemd/system/livekit-server.service with the following content:

[Unit]
Description=LiveKit Server Container
After=network.target

[Service]
LimitNOFILE=500000
Restart=always
WorkingDirectory=/opt/livekit
ExecStart=livekit-server --config /etc/livekit/livekit.yaml

[Install]
WantedBy=multi-user.target

2. Create the directory /opt/livekit and copy the LiveKit server binary into it:

mkdir -p /opt/livekit
cp livekit-server /opt/livekit/

3. Create the configuration file /etc/livekit/livekit.yaml with the following content:

port: 7880
bind_addresses:
  - ""
rtc:
  tcp_port: 7881
  port_range_start: 50000
  port_range_end: 50200
  use_external_ip: true
  ips:
    includes:
      - 162.55.131.56/26
      - 192.168.100.39/32
  enable_loopback_candidate: false
turn:
  enabled: false
  domain: rtc-turn.domain.com
  tls_port: 5349
  udp_port: 3478
  external_tls: true
keys:
  xxx: xxx

Enable and Start Systemd Services

1. Reload the Systemd daemon configuration:

systemctl daemon-reload

2. Enable and start the services:

systemctl enable --now lk-jwt-service.service livekit-server.service

Configure NGINX as a Reverse Proxy

1. Open your NGINX configuration file and add the following sections:

location ^~ /livekit/jwt/ {
  proxy_set_header Host $host;
  proxy_set_header X-Real-IP $remote_addr;
  proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
  proxy_set_header X-Forwarded-Proto $scheme;

  # JWT Service running at port 8080
  proxy_pass http://localhost:8080/;
}

location ^~ /livekit/sfu/ {
  proxy_set_header Host $host;
  proxy_set_header X-Real-IP $remote_addr;
  proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
  proxy_set_header X-Forwarded-Proto $scheme;

  proxy_send_timeout 120;
  proxy_read_timeout 120;
  proxy_buffering off;

  proxy_set_header Accept-Encoding gzip;
  proxy_set_header Upgrade $http_upgrade;
  proxy_set_header Connection "upgrade";

  # LiveKit SFU websocket connection running at port 7880
  proxy_pass http://localhost:7880/;
}

2. Test the NGINX configuration:

nginx -t

3. Reload the NGINX configuration:

systemctl reload nginx

Verification

• Ensure the services are running:

systemctl status lk-jwt-service.service livekit-server.service

• Test the endpoints:
  • JWT Service: http://<your-domain>/livekit/jwt/
  • LiveKit SFU: http://<your-domain>/livekit/sfu/

LiveKit JWT-Service installieren

1. Wechseln Sie in das Verzeichnis /opt:

cd /opt

2. Klonen Sie das Repository:

git clone https://github.com/element-hq/lk-jwt-service.git
cd lk-jwt-service

3. Erstellen Sie die ausführbare Datei:

go build -o lk-jwt-service .
/usr/local/go/bin/go build -o lk-jwt-service .

4. Installieren Sie das LiveKit-CLI-Tool:

curl -sSL https://get.livekit.io/ | bash

JWT-Service installieren und konfigurieren

1. Erstellen Sie die Datei /etc/systemd/system/lk-jwt-service.service mit folgendem Inhalt:

[Unit]
Description=LiveKit JWT Service
After=network.target
Requires=livekit-server.service

[Service]
Restart=always
WorkingDirectory=/opt/lk-jwt-service
Environment="LIVEKIT_URL=wss://rtc.domain.com/"
Environment="LIVEKIT_KEY=xxx"
Environment="LIVEKIT_SECRET=xxx"
Environment="LIVEKIT_JWT_PORT=8080"
ExecStart=/opt/lk-jwt-service/lk-jwt-service

[Install]
WantedBy=multi-user.target

2. Stellen Sie sicher, dass die ausführbare Datei im richtigen Verzeichnis liegt:

cp lk-jwt-service /opt/lk-jwt-service/

LiveKit-Server installieren und konfigurieren

1. Erstellen Sie die Datei /etc/systemd/system/livekit-server.service mit folgendem Inhalt:

[Unit]
Description=LiveKit Server Container
After=network.target

[Service]
LimitNOFILE=500000
Restart=always
WorkingDirectory=/opt/livekit
ExecStart=livekit-server --config /etc/livekit/livekit.yaml

[Install]
WantedBy=multi-user.target

2. Erstellen Sie das Verzeichnis /opt/livekit und kopieren Sie die LiveKit-Server-Binärdatei dorthin:

mkdir -p /opt/livekit
cp livekit-server /opt/livekit/

3. Erstellen Sie die Konfigurationsdatei /etc/livekit/livekit.yaml mit folgendem Inhalt:

port: 7880
bind_addresses:
  - ""
rtc:
  tcp_port: 7881
  port_range_start: 50000
  port_range_end: 50200
  use_external_ip: true
  ips:
    includes:
      - 162.55.131.56/26
      - 192.168.100.39/32
  enable_loopback_candidate: false
turn:
  enabled: false
  domain: rtc-turn.domain.com
  tls_port: 5349
  udp_port: 3478
  external_tls: true
keys:
  xxx: xxx

Systemd-Dienste aktivieren und starten

1. Laden Sie die Systemd-Daemon-Konfiguration neu:

systemctl daemon-reload

2. Aktivieren und starten Sie die Dienste:

systemctl enable --now lk-jwt-service.service livekit-server.service

NGINX als Reverse Proxy konfigurieren

1. Öffnen Sie Ihre NGINX-Konfigurationsdatei und fügen Sie die folgenden Abschnitte hinzu:

location ^~ /livekit/jwt/ {
  proxy_set_header Host $host;
  proxy_set_header X-Real-IP $remote_addr;
  proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
  proxy_set_header X-Forwarded-Proto $scheme;

  # JWT-Service läuft auf Port 8080
  proxy_pass http://localhost:8080/;
}

location ^~ /livekit/sfu/ {
  proxy_set_header Host $host;
  proxy_set_header X-Real-IP $remote_addr;
  proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
  proxy_set_header X-Forwarded-Proto $scheme;

  proxy_send_timeout 120;
  proxy_read_timeout 120;
  proxy_buffering off;

  proxy_set_header Accept-Encoding gzip;
  proxy_set_header Upgrade $http_upgrade;
  proxy_set_header Connection "upgrade";

  # LiveKit SFU WebSocket-Verbindung läuft auf Port 7880
  proxy_pass http://localhost:7880/;
}

2. Testen Sie die NGINX-Konfiguration:

nginx -t

3. Laden Sie die NGINX-Konfiguration neu:

systemctl reload nginx

Überprüfung

• Stellen Sie sicher, dass die Dienste laufen:

systemctl status lk-jwt-service.service livekit-server.service

• Testen Sie die Endpunkte:
  • JWT-Service: http://<your-domain>/livekit/jwt/
  • LiveKit SFU: http://<your-domain>/livekit/sfu/