dynaDAT | UNIXoni | REDATEK | ITVeteran - wiki

adaptec_logicaldrive

Anonymous (anonymous@undisclosed.example.com) — 2026-05-03T06:47:11+00:00

Austausch von Festplatten und Erstellen eines neuen Logical Drives mit arcconf

Dieser Beitrag beschreibt, wie man ein defektes Logical Drive ersetzt, indem alle vier Festplatten (HDDs) ausgetauscht werden. Achte darauf, dass alle Festplatten vom gleichen Typ sind, da unterschiedliche Laufwerksgeometrien zu Ausfällen führen können.

Das Tool „arcconf“ kann von der offiziellen Seite von ADAPTEC heruntergeladen werden: ADAPTEC RAID 6805E Downloadseite

Schritt-für-Schritt-Anleitung

1. Logical Drive löschen Um das bestehende Logical Drive zu löschen, nutze den folgenden Befehl:

  
  linux_x64/arcconf delete 1 logicaldrive 2

2. Überprüfen des HDD-Status Prüfe nach dem Löschen des Logical Drives, ob alle Festplatten im Status „Ready“ zur Verfügung stehen:

 
  linux_x64/arcconf getconfig 1

3. Neues Logical Drive erstellen Erstelle ein neues Logical Drive mit den folgenden Parametern:

  
  linux_x64/arcconf create 1 logicaldrive max 10 0 4 0 5 0 6 0 7

4. Status des neuen Drives überprüfen Stelle sicher, dass das neu erstellte Logical Drive den Status „optimal“ hat:

  
  linux_x64/arcconf getconfig 1 ld

Wichtige Hinweise

Achte darauf, dass alle Festplatten vom gleichen Typ sind.
Unterschiedliche Laufwerksgeometrien können zu Ausfällen führen.
Verwende immer die aktuellste Version von arcconf.

Durch diese Schritte wird ein neues Logical Drive mit den ausgetauschten Festplatten erstellt und korrekt konfiguriert.

Stichworte

Adaptec, arcconf, RAID, Logical Drive, HDD, 6805E

ausfall_raid_hdd

Anonymous (anonymous@undisclosed.example.com) — 2026-05-03T06:47:02+00:00

arcconf – Arbeiten mit RAID-Volumes unter Linux

Ein Logical Drive (LD) meldet eine ausgefallene Festplatte (HDD). Die folgenden Schritte helfen bei der Diagnose und Reparatur mittels `arcconf`.

1. Rescan aller Devices

Führt eine erneute Erkennung aller Geräte durch.

linux_x64/arcconf rescan 1

2. Rebuild anstoßen (wenn automatisch möglich)

Ein funktionierender Versuch:

linux_x64/arcconf task start 1 device 0 initialize
linux_x64/arcconf rescan 1

→ Danach begann automatisch ein Rebuild.

3. Device feststellen

Listet physikalische und logische Geräte auf.

linux_x64/arcconf getconfig 1 pd

Hinweis: * PD = Physical Device * LD = Logical Device

4. Device löschen (clear)

Setzt ein Device zurück (z. B. nach Austausch oder Fehlerstatus). Achtung: Vorher Device-Nummer herausfinden über `getconfig`.

linux_x64/arcconf task start 1 device 0 1 clear

→ Syntax: `device <Channel> <Device>`

5. Device prüfen oder reparieren

linux_x64/arcconf task start 1 device 0 0 verify
linux_x64/arcconf task start 1 device 0 0 verify_fix

6. Danach: Devices erneut scannen

linux_x64/arcconf rescan 1

7. Logical Drive prüfen

linux_x64/arcconf task start 1 logicaldrive 0 verify_fix

8. HDD austauschen und identifizieren

Lässt die LED des betreffenden Geräts blinken, zur physischen Identifikation.

linux_x64/arcconf identify 1 device 0 0

Hinweise

Immer vorher aktuelle Konfiguration sichern.
Im Zweifel zuerst `getconfig` nutzen.
Prüfen, ob „hot spare“ eingerichtet ist.
Rebuild-Status regelmäßig beobachten mit:

  linux_x64/arcconf getstatus 1

Stichworte

RAID, arcconf, Adaptec, Logical Drive, HDD, Rebuild, Linux

dokuwiki

Anonymous (anonymous@undisclosed.example.com) — 2026-09-07T12:24:03+00:00

DokuWiki

DokuWiki is a simple to use and highly versatile Open Source wiki software that doesn't require a database. It is loved by users for its clean and readable syntax. The ease of maintenance, backup and integration makes it an administrator's favorite. Built in access controls and authentication connectors make DokuWiki especially useful in the enterprise context and the large number of plugins contributed by its vibrant community allow for a broad range of use cases beyond a traditional wiki.

Read the DokuWiki Manual to unleash the full power of DokuWiki.

Download

DokuWiki is available at https://download.dokuwiki.org/

All documentation and additional information besides the syntax description is maintained in the DokuWiki at www.dokuwiki.org.

About DokuWiki

Installing DokuWiki

Using DokuWiki

Customizing DokuWiki

DokuWiki Feedback and Community

Copyright

2004-2020 © Andreas Gohr andi@splitbrain.org²⁾ and the DokuWiki Community

The DokuWiki engine is licensed under GNU General Public License Version 2. If you use DokuWiki in your company, consider donating a few bucks .

Not sure what this means? See the FAQ on the Licenses.

Stichworte

DokuWiki, Wiki, Wiki-Syntax, Dokumentation, Open Source, Installation, Konfiguration, Plugins, ACL, Authentifizierung, Backups

²⁾

Please do not contact me for help and support – use the mailinglist or forum instead

informix_rowid

Anonymous (anonymous@undisclosed.example.com) — 2026-05-03T06:46:59+00:00

Nutzung der rowid in SQL Statements

Die Verwendung der `rowid` in SQL-Statements sollte mit Vorsicht erfolgen und nach Möglichkeit vermieden werden. Dies gilt insbesondere im Kontext von Datenbankmigrationen oder bei der Verwendung von Datenbank-Wrapping-Technologien wie z.B. dem Informix-Wrapper für PostgreSQL.

Laut IBM-Dokumentation wird empfohlen, sich nicht auf `rowid` zu verlassen, da sie systemabhängig ist und sich unter bestimmten Umständen ändern kann. (vgl. https://www.ibm.com/docs/de/informix-servers/12.10.0?topic=statements-rowid-values-in-select)

In Informix ist `rowid` ein Integer-Wert. In PostgreSQL gibt es kein direktes Äquivalent, aber es existiert die systeminterne Spalte `ctid`, die eine ähnliche Funktion übernimmt. (vgl. https://www.enterprisedb.com/postgres-tutorials/what-equivalent-rowid-postgresql?lang=en und https://www.postgresql.org/docs/current/ddl-system-columns.html)

Unterschiede zwischen Informix rowid und PostgreSQL ctid

Der Informix-Wrapper leitet die `rowid` grundsätzlich an die PostgreSQL-`ctid` weiter. Dabei gibt es jedoch wichtige technische Unterschiede:

`rowid` in Informix ist ein einfacher Integer.
`ctid` in PostgreSQL ist ein Tupel bestehend aus (page_number, tuple_index).
Der Informix-Wrapper setzt `rowid` auf den ersten Wert von `ctid`, also ergibt sich die übergebene Form: `ctid = (rowid, 0)`.

Technische Eigenschaften der ctid in PostgreSQL

`ctid` ändert sich bei jeder UPDATE-Operation.
Wird durch VACUUM FULL neu zugewiesen.
Kann nach VACUUM ANALYZE wiederverwendet werden.
Ist systemintern und nicht als dauerhaft eindeutiger Schlüssel geeignet.

Beste Praktiken

Statt `rowid` oder `ctid` zu verwenden, sollten möglichst logische Identifikatoren eingesetzt werden. Empfohlene Alternativen:

Primärschlüssel nutzen (z.B. durch `SERIAL` oder `BIGSERIAL` erzeugt).
Aufbau geeigneter Indexstrukturen zur Performanceoptimierung.
Logische Referenzen statt physischer Adressen (z.B. Foreign Keys auf Primärschlüssel).
Anpassung der Anwendung, um auf `rowid`/`ctid` zu verzichten.

Mögliche Lösungen bei Migration oder Wrapper-Nutzung

Wenn eine bestehende Anwendung auf `rowid` angewiesen ist, gibt es folgende Workarounds:

Anlage einer eigenen physischen Spalte `rowid` vom Typ `BIGSERIAL` in der PostgreSQL-Zielstruktur.
Aufbau eines dedizierten Index zur effizienten Suche.
Anpassung der SQL-Statements in der Anwendung, um die neue Struktur zu unterstützen.

Hinweis: Die Verwendung von `ctid` als langfristiger Zeilenidentifikator sollte vermieden werden, da er sich durch normale Datenbankoperationen wie `UPDATE`, `VACUUM`, etc. verändern kann und somit nicht stabil ist.

Fazit

Die `rowid` bzw. `ctid` sind für temporäre oder systeminterne Zwecke nützlich, sollten jedoch nicht als zuverlässige Referenz in langlebigen Anwendungen oder Datenmodellen verwendet werden. Stattdessen ist auf Primärschlüssel-basierte Logik umzusteigen.

Stichworte

Informix, PostgreSQL, rowid, ctid, FDW, Migration, Primärschlüssel

iphone_video

Anonymous (anonymous@undisclosed.example.com) — 2026-05-03T06:47:12+00:00

iPhone Video (.mov) in MP4 umwandeln

Der, für mich, einfachste Weg:

  ffmpeg -i 'iPhone.mov' -vcodec h264 -acodec mp2 video.mp4

Stichworte

ffmpeg, iPhone, MOV, MP4, Video, Konvertierung

letsencrypt_webpath_docker_renew

Anonymous (anonymous@undisclosed.example.com) — 2026-05-03T06:46:47+00:00

Apache Konfiguration für Let's Encrypt Zertifikats-Erneuerung mit Podman

Um Let's Encrypt Zertifikate in einem Container zu erneuern, ist eine spezifische Konfiguration des Apache Virtual Hosts erforderlich, da die Zertifikatserneuerung über einen Container erfolgt. Die folgende Konfiguration stellt sicher, dass Anfragen an die /.well-known/acme-challenge-Ressourcen erfolgreich verarbeitet werden, selbst wenn der eigentliche DocumentRoot für die Webseite anders gesetzt ist.

Apache VHost Konfiguration

In der Apache-Konfigurationsdatei des Virtual Hosts wird der DocumentRoot auf das Verzeichnis der Webseite gesetzt. Da Let's Encrypt jedoch auf /.well-known/acme-challenge zugreift, um die Zertifikate zu validieren, ist eine Alias-Direktive erforderlich, um Anfragen korrekt umzuleiten. Der relevante Ausschnitt der Konfiguration:

.... <VirtualHost *:80> 
DocumentRoot /var/www/html/redatek 
Alias /.well-known/acme-challenge/ /var/www/html/.well-known/acme-challenge/ 
... </VirtualHost>

Erklärung:

DocumentRoot legt das Verzeichnis fest, das die Hauptinhalte der Webseite enthält. In diesem Beispiel: `/var/www/html/redatek`.
Alias definiert eine Umleitung für das Verzeichnis /.well-known/acme-challenge/ auf `/var/www/html/.well-known/acme-challenge/`. Dadurch können Let's Encrypt Validierungsanfragen unabhängig vom DocumentRoot beantwortet werden.

Beachten im Containerbetrieb

Apache Config für http (80) anpassen:

<If "%{THE_REQUEST} !~ m# /.well-known/?#i">
       RedirectPermanent / https://url.tld/
</If>

Zumindest Apache > 2.4

Zertifikat generieren

den Webroot Ordner angeben –> certbot certonly –webroot /var/www/ -d domain.tld

Let's Encrypt Zertifikats-Erneuerung im Container

Da die Zertifikatserneuerung über Podman in einem Container stattfindet, wird das Verzeichnis für die Webseiten-Validierung gemountet. Dies erfolgt mittels Volumemapping, um sicherzustellen, dass Let's Encrypt auf die notwendigen Verzeichnisse zugreifen kann.

Der Befehl für die Zertifikats-Erneuerung im Container sieht wie folgt aus:

podman run --rm -it
-v "/container/letsencrypt/log:/var/log/letsencrypt"
-v "/var/www/html:/var/www/"
-v "/container/letsencrypt/cert:/etc/letsencrypt"
docker.io/certbot/certbot renew

Erklärung:

–rm löscht den Container nach der Ausführung, um Speicherplatz freizugeben.
-it ermöglicht eine interaktive Ausführung im Terminal.
-v „/container/letsencrypt/log:/var/log/letsencrypt“ legt das Log-Verzeichnis fest, um Protokolle der Zertifikats-Erneuerung zu speichern.
-v „/var/www/html:/var/www/„ mappt das lokale Webverzeichnis `/var/www/html` in das Verzeichnis `/var/www/` innerhalb des Containers.
-v “/container/letsencrypt/cert:/etc/letsencrypt“ weist das Verzeichnis für die Zertifikate zu.

Neustart nicht vergessen

nach dem

podman run --rm -it -v "/container/letsencrypt/log:/var/log/letsencrypt" -v "/var/www/html:/var/www/" -v "/container/letsencrypt/cert:/etc/letsencrypt" docker.io/certbot/certbot renew -v

unbedingt die betreffenden Dienste neu starten damit der neue Key aktiv geladen wird.

systemctl restart httpd
podman container restart mailserver

Problematik ohne Alias-Direktive

Ohne das Alias-Mapping schlägt der Erneuerungsprozess fehl, da Let's Encrypt auf /.well-known/acme-challenge zugreifen muss. Der angegebene DocumentRoot für die Webseite (/var/www/html/redatek) enthält jedoch dieses Verzeichnis nicht direkt. Daher ist das Alias in der Apache-Konfiguration notwendig, um die Validierung erfolgreich abzuschließen.

Zusammenfassung

Diese Konfiguration ermöglicht es, Let's Encrypt Zertifikate über einen Podman-Container zu erneuern, indem die Apache-Konfiguration angepasst wird, um die notwendigen Ressourcen bereitzustellen.

DocumentRoot verweist auf den Hauptinhalt der Webseite.
Alias stellt sicher, dass die Zertifikatsanfragen von Let's Encrypt korrekt beantwortet werden.
Podman Container-Setup mit Volumemapping ermöglicht den Zugriff auf die Verzeichnisse für Logs und Zertifikate sowie auf das Webverzeichnis für die Validierung.

Stichworte

Let's Encrypt, ACME, Apache, Alias, VirtualHost, certbot, Podman, Docker, Zertifikat, /.well-known

logger

Anonymous (anonymous@undisclosed.example.com) — 2026-09-09T16:49:49+00:00

Protokollierung von Benutzeraktionen mit Username in Syslog

Bevorzugte Lösung

Diese Lösung wird von mir bevorzugt. Sie verwendet `auditd` zur Erfassung der Befehle, ein eigenes Formatter-Skript zum Zusammenführen und Aufbereiten der Audit-Datensätze sowie `rsyslogd` zum Schreiben der fertigen Meldung nach `/var/log/syslog`.

Standardlösung: rohe Audit-Meldungen

Die übliche Standardlösung leitet die Audit-Meldungen lediglich weiter und schreibt sie beispielsweise nach `/var/log/user-audit.log`. Dort stehen die einzelnen Audit-Datensätze (`SYSCALL`, `EXECVE` und `EOE`) jedoch getrennt und im technischen Rohformat. Ein einzelnes Ereignis verteilt sich dadurch auf mehrere schwer lesbare Logzeilen; Username und Befehlsargumente sind nicht übersichtlich in einer Meldung zusammengefasst.

Die Datei kann beispielsweise mit `ausearch` ausgewertet werden:

sudo ausearch -k user_commands

Diese Standardlösung ist für die nachträgliche technische Analyse geeignet, erzeugt aber keine kompakte Meldung der Form „Zeit, eingeloggter Benutzer, ausführender Benutzer, Befehl“. Deshalb wird in diesem Beitrag die oben beschriebene Formatter-Lösung bevorzugt.

Ziel

Diese Konfiguration protokolliert ausgeführte Befehle mit folgenden Informationen:

Zeitpunkt der Ausführung
ursprünglich eingeloggter Benutzer (Audit-ID, AUID)
tatsächlich ausführender Benutzer (UID)
ausgeführter Befehl einschließlich Argumenten

Der Datenfluss ist:

auditd -> Audit-Formatter -> rsyslogd -> /var/log/syslog

Hinweis: Eine reine rsyslogd-Regel kann die getrennten Audit-Datensätze (SYSCALL und EXECVE) nicht zuverlässig zu einem vollständigen Ereignis zusammenführen. Diese Aufgabe übernimmt der Formatter. rsyslogd schreibt anschließend die fertige Meldung in die Syslog-Datei.

Voraussetzungen

Debian/Ubuntu:

sudo apt update
sudo apt install auditd audispd-plugins rsyslog

Das Formatter-Skript aus dem Projekt ist:

audit-format-syslog.py

1. Audit-Regeln einrichten

Datei `/etc/audit/rules.d/user-commands.rules` anlegen oder bearbeiten:

-a always,exit -F arch=b64 -S execve,execveat -F auid>=1000 -F auid!=unset -k user_commands
-a always,exit -F arch=b32 -S execve,execveat -F auid>=1000 -F auid!=unset -k user_commands

Die Regeln überwachen die Ausführung von Programmen durch angemeldete Benutzer. Der Schlüssel `user_commands` erleichtert die spätere Suche mit `ausearch`.

Regeln laden:

sudo augenrules --load
sudo auditctl -l

2. Audit-Formatter installieren

Das Skript installieren:

sudo install -m 0755 \
  /path/to/audit-format-syslog.py \
  /usr/local/sbin/audit-format-syslog.py

Der Formatter liest die Audit-Meldungen über die Standardeingabe. Er sammelt die zusammengehörigen `SYSCALL`, `EXECVE` und `EOE`-Datensätze, löst die UID-Nummern in Benutzernamen auf und schreibt anschließend eine formatierte Syslog-Meldung.

Der vollständige Quelltext des Formatters:

#!/usr/bin/env python3
 
import binascii
import pwd
import re
import shlex
import sys
import syslog
import time
from functools import lru_cache
 
 
EVENT_RE = re.compile(r"msg=audit\(([^:]+):(\d+)\)")
FIELD_RE = re.compile(r'([A-Za-z_][A-Za-z0-9_]*)=("[^"]*"|[^ ]+)')
 
 
def fields(line):
  return {key: value.strip('"') for key, value in FIELD_RE.findall(line)}
 
 
@lru_cache(maxsize=1024)
def username(value):
  if value in (None, "unset", "4294967295"):
    return "-"
  try:
    return pwd.getpwuid(int(value)).pw_name
  except (KeyError, ValueError):
    return value
 
 
def argument(value):
  if value is None:
    return ""
  if value.startswith('"') and value.endswith('"'):
    value = value[1:-1]
  if re.fullmatch(r"[0-9A-Fa-f]+", value) and len(value) % 2 == 0:
    try:
      return binascii.unhexlify(value).decode("utf-8", "replace")
    except (binascii.Error, UnicodeError):
      pass
  return value
 
 
def emit(event):
  syscall = event.get("syscall")
  execve = event.get("execve")
  if not syscall or not execve or syscall.get("key") != "user_commands":
    return
 
  try:
    timestamp = time.strftime("%Y-%m-%d %H:%M:%S", time.localtime(float(event["epoch"])))
  except (KeyError, ValueError, OverflowError):
    timestamp = "-"
 
  args = [argument(execve.get(f"a{index}")) for index in range(int(execve.get("argc", 0)))]
  command = " ".join(shlex.quote(value) for value in args)
  command = command.replace("\r", "\\r").replace("\n", "\\n")
  login_user = username(syscall.get("auid") or syscall.get("AUID"))
  executing_user = username(syscall.get("uid") or syscall.get("UID"))
  syslog.syslog(syslog.LOG_INFO, f"user-audit: {timestamp}, {login_user}, {executing_user}, {command}")
 
 
current = {}
EVENT_TIMEOUT = 30
syslog.openlog("audit-format", syslog.LOG_PID, syslog.LOG_LOCAL6)
 
for line in sys.stdin:
  match = EVENT_RE.search(line)
  if not match:
    continue
  epoch, serial = match.groups()
  event = current.setdefault(serial, {"epoch": epoch})
  if line.startswith("type=SYSCALL"):
    event["syscall"] = fields(line)
  elif line.startswith("type=EXECVE"):
    event["execve"] = fields(line)
  elif line.startswith("type=EOE"):
    emit(event)
    current.pop(serial, None)
 
  now = time.time()
  expired = [
    key for key, pending in current.items()
    if now - float(pending["epoch"]) > EVENT_TIMEOUT
  ]
  for key in expired:
    current.pop(key, None)

Die erzeugte Meldung hat dieses Format:

user-audit: 2026-09-09 14:30:01, alice, root, 'apt' 'update'

Die Reihenfolge ist:

Zeit, eingeloggter Benutzer, ausführender Benutzer, Befehl

3. Audit-Plugin konfigurieren

Datei `/etc/audit/plugins.d/audit-format.conf` anlegen:

active = yes
direction = out
path = /usr/local/sbin/audit-format-syslog.py
type = always
format = string

Auch bei neueren Debian- und Ubuntu-Versionen ist `audispd` in `auditd` integriert; die Plugin-Konfiguration bleibt dabei versionsabhängig. Die Werte müssen zur installierten `auditd`-Version passen. Das Skript muss ausführbar sein (`chmod 0755`). Wenn AppArmor oder SELinux aktiv ist, müssen zusätzlich der Zugriff auf den Skriptpfad und der passende Sicherheitskontext geprüft werden.

Das Skript verwendet die Syslog-Facility `local6` und den Programmnamen `audit-format`.

4. rsyslogd konfigurieren

Datei `/etc/rsyslog.d/30-audit-format.conf` anlegen:

module(load="imuxsock")
 
template(
    name="AuditSyslogFormat"
    type="string"
    string="%timegenerated% %HOSTNAME% %syslogtag%%msg:::drop-last-lf%\n"
)
 
if ($programname == "audit-format" and
    $syslogfacility-text == "local6") then {
    action(
        type="omfile"
        file="/var/log/syslog"
        template="AuditSyslogFormat"
        createMode="0640"
    )
    stop
}

Dadurch werden nur die vom Formatter erzeugten Audit-Meldungen nach `/var/log/syslog` geschrieben.

`imuxsock` ist erforderlich, weil die Python-Syslog-Bibliothek die Meldung an `/dev/log` sendet. Auf Systemen, die zusätzlich oder hauptsächlich `imjournal` verwenden, sollte geprüft werden, dass `imuxsock` geladen ist und keine doppelte Verarbeitung über `journald` entsteht.

Beispiel:

Sep  9 14:30:01 server audit-format[1234]: user-audit: 2026-09-09 14:30:01, alice, root, 'apt' 'update'

Der erste Zeitstempel wird von rsyslogd ergänzt. Der zweite Zeitstempel stammt aus dem Audit-Ereignis.

5. Dienste neu starten

Zuerst die rsyslogd-Konfiguration prüfen:

sudo rsyslogd -N1

Bei erfolgreicher Prüfung Dienste neu starten:

sudo systemctl restart rsyslog
sudo service auditd restart

Auf manchen Distributionen wird ein direkter Neustart von `auditd` über `systemctl` aus Sicherheitsgründen abgelehnt. Verwende dann `service auditd restart` oder lade nach einer Regeländerung zunächst mit `sudo augenrules –load` die Audit-Regeln neu.

Status prüfen:

sudo systemctl status rsyslog
sudo systemctl status auditd

6. Funktion testen

Einen Befehl ausführen und Syslog beobachten:

id
ls -la /tmp
sudo tail -f /var/log/syslog

Bei einem Aufruf über `sudo` kann die Ausgabe beispielsweise so aussehen:

Sep  9 14:35:12 server audit-format[1234]: user-audit: 2026-09-09 14:35:12, alice, root, 'id'

Dabei bedeutet:

`alice`: ursprünglich eingeloggter Benutzer (`auid`)
`root`: Benutzer, unter dem der Prozess tatsächlich ausgeführt wurde (`uid`)
`'id'`: ausgeführter Befehl

7. Fehlerdiagnose

Audit-Regeln prüfen:

sudo auditctl -l
sudo ausearch -k user_commands

Dienste und Fehlermeldungen prüfen:

sudo journalctl -u auditd -n 50
sudo journalctl -u rsyslog -n 50

Prüfen, ob das Log geschrieben wird:

sudo grep audit-format /var/log/syslog

Sicherheit und Betrieb

Die Audit-Regeln können viele Meldungen erzeugen. Die Datei `/var/log/syslog` sollte deshalb regelmäßig rotiert und vor unbefugtem Zugriff geschützt werden.

Bei produktivem Betrieb sollte geprüft werden, ob die vorhandene Logrotate-Konfiguration für `/var/log/syslog` aktiv ist. Zusätzlich sollten die Berechtigungen der Logdatei und des Verzeichnisses kontrolliert werden.

Die Audit-Daten sind sicherheitsrelevant. Benutzer mit Root-Rechten können lokale Logdateien grundsätzlich verändern. Für manipulationsgeschützte Protokollierung ist eine Weiterleitung an einen zentralen Logserver erforderlich.

Stichworte

Linux, auditd, Audit, Benutzeraktionen, execve, sudo, rsyslog, syslog, audispd, Systemprotokoll, Sicherheitsprotokoll, Logdatei

sudoer

Anonymous (anonymous@undisclosed.example.com) — 2026-09-07T12:24:03+00:00

SUDOERS: Sichere Konfiguration und Best Practices (Admin-Level)

Die `/etc/sudoers`-Datei (oder Dateien im `/etc/sudoers.d/`-Verzeichnis) ist das zentrale Konfigurationselement, um Benutzern und Gruppen die Ausführung von Befehlen mit Root-Rechten oder als anderer Benutzer zu ermöglichen, ohne das Root-Passwort direkt preiszugeben.

1. Grundprinzip und Sicherheitsaspekte

`sudoers` definiert, welche Benutzer/Gruppen (`User_Alias`, `Cmnd_Alias`), auf welchen Hosts (`Host_Alias`) welche Befehle (`Cmnd_Alias`) mit welchen Rechten (`Runas_Alias`) ausführen dürfen. Das Kernziel ist das *Prinzip der geringsten Privilegien*, um die Angriffsfläche bei kompromittierten Benutzerkonten zu minimieren.

ABSOLUTE WARNUNG VOR: `User ALL=(ALL) NOPASSWD: ALL`

Die Konfiguration `User ALL=(ALL) NOPASSWD: ALL` (oder vergleichbare für Gruppen) ist ein erhebliches Sicherheitsrisiko und sollte auf produktiven Systemen niemals verwendet werden. Dies bedeutet: * Jeder Benutzer (oder die betreffende Gruppe) kann *jeden* Befehl als *jeden* anderen Benutzer (inkl. Root) ohne Passwort ausführen. * Dies macht eine Rechteausweitung extrem einfach, wenn das Benutzerkonto kompromittiert wird. * Es gibt keine Kontrolle mehr darüber, welche Aktionen tatsächlich als Root ausgeführt werden.

Diese Einstellung untergräbt das gesamte Konzept von `sudo` und der Rechteverwaltung unter Linux und ist nur für Testsysteme ohne Sicherheitsrelevanz oder in sehr speziellen, hochgradig kontrollierten Umgebungen (z.B. spezielle CI/CD-Agents) denkbar, wo das Risiko durch andere Maßnahmen abgefangen wird.

2. Sichere, granulare `sudoers`-Konfiguration

Statt pauschaler Freigaben sollte `sudoers` präzise Rechte für spezifische Befehle vergeben. Hier ein Beispiel, das `adminuser` erlaubt, den Apache-Dienst neu zu starten und den Status abzufragen, sowie `logreader` erlaubt, `journalctl` ohne Paging zu nutzen:

Konfiguration in `/etc/sudoers` oder `/etc/sudoers.d/01_custom_admin` (bevorzugt):

# Definition von Aliasen für Benutzer, Hosts, Befehle
User_Alias      WEBADMINS = adminuser
User_Alias      LOGREADERS = logreader

Cmnd_Alias      WEB_SERVICE = /bin/systemctl restart apache2, /bin/systemctl status apache2
Cmnd_Alias      VIEW_LOGS = /bin/journalctl

# Zuweisung der Rechte
WEBADMINS ALL=(ALL) NOPASSWD: WEB_SERVICE
LOGREADERS ALL=(ALL) NOPASSWD: VIEW_LOGS

Erläuterung: * `User_Alias`: Definiert Gruppen von Benutzern. * `Cmnd_Alias`: Definiert Gruppen von Befehlen. Jeder Befehl muss mit seinem absoluten Pfad angegeben werden! * `WEBADMINS ALL=(ALL) NOPASSWD: WEB_SERVICE`: Der Benutzer `adminuser` darf auf allen Hosts jeden Befehl aus der `WEB_SERVICE`-Liste als jeder beliebige User (Standard: root) ohne Passworteingabe ausführen. * `LOGREADERS ALL=(ALL) NOPASSWD: VIEW_LOGS`: Der Benutzer `logreader` darf `journalctl` ohne Passwort ausführen.

3. Verhinderung von Befehlsketten und Rechteerschleichung

Eine der größten Fallen bei `sudoers` sind Befehlsketten. Wenn ein Befehl erlaubt ist, der weitere Befehle ausführen kann, kann dies zur Rechteausweitung führen. Beispiele hierfür sind: * Editoren wie `vi` oder `nano` (`sudo vi /etc/shadow`) * Paging-Programme wie `less` oder `more` (`sudo less /var/log/audit/audit.log`, dann über `!bash` eine Shell öffnen) * Programme, die Shell-Befehle ausführen können (z.B. `find -exec`, `awk -F /etc/passwd '{print $1}'`, `ssh`)

3.1 Argumente mit Regex exakt begrenzen

Bei aktuellen sudo-Versionen (ab 1.9.10) können die komplette Befehlszeile und ihre Argumente mit einer Regex eingeschränkt werden. Die Regex sollte mit `^` beginnen und mit `$` enden. Dadurch sind keine zusätzlichen Argumente erlaubt.

Beispiel: `deployuser` darf nur genau dieses Skript mit genau einem nicht-leeren, leerzeichenfreien Dateinamen ausführen:

Cmnd_Alias DEPLOY = ^/usr/local/sbin/deploy[[:space:]]+[^[:space:];&|<>$()]+$
deployuser ALL=(root) NOPASSWD: DEPLOY

Damit wird beispielsweise folgender Aufruf erlaubt:

sudo /usr/local/sbin/deploy release.tar

Nicht erlaubt sind zusätzliche Argumente oder eine vermeintliche Befehlsverkettung wie:

sudo /usr/local/sbin/deploy release.tar\;id

`digit` bedeutet nicht „Leerzeichen und Ziffern verhindern“, sondern matcht ein einzelnes Zeichen, das entweder Leerraum oder eine Ziffer ist. Für „ein oder mehrere Zeichen, aber niemals Leerraum“ wird `[^[:space:]]+` verwendet. Im obigen Beispiel werden zusätzlich `;`, `&`, `|`, `<`, `>`, `$` und runde Klammern ausgeschlossen.

Wichtig: `sudo` startet den freigegebenen Befehl nicht automatisch über eine Shell. Zeichen wie `;`, `&&` oder `|` werden daher bei einem normalen Programm nicht als Verkettung interpretiert. Eine Befehlskette wird gefährlich, sobald ein freigegebenes Programm selbst eine Shell oder einen Interpreter startet, zum Beispiel:

/bin/sh -c ...
/bin/bash -c ...
/usr/bin/python ...
/usr/bin/perl ...

Solche Programme dürfen nicht freigegeben werden, wenn eine isolierte Einzelaktion beabsichtigt ist. Am sichersten ist ein fest installiertes Root-Skript ohne frei wählbare Argumente oder mit einer eigenen, strikten Argumentprüfung. Das Skript muss absolut referenziert werden und darf keine vom Benutzer kontrollierten Shell-Kommandos ausführen.

Best Practices zur Verhinderung:

1. Absolute Pfade und Argumente: Geben Sie Befehle immer mit ihrem absoluten Pfad an. Wenn möglich, beschränken Sie auch die erlaubten Argumente oder verwenden Sie reguläre Ausdrücke (Regex) in `sudoers` (mit Vorsicht). 2. Keine Shell-Escapes: Erlauben Sie keine Programme, die interne Shell-Escapes oder die Ausführung externer Programme zulassen (z.B. `vi`, `nano`, `more`, `less`, `man`, `find`, `awk`, `perl`, `python` ohne `sudo -i`). 3. Umfeldbeschränkung (`env_reset`, `SETENV`):

`Defaults env_reset` (Standard) bereinigt die Umgebungsvariablen. Dies ist wichtig, um Manipulationen wie `LD_PRELOAD` zu verhindern.
Vermeiden Sie `SETENV` für sensible Befehle, da dies eine manipulierte Umgebung zulassen könnte.
Setzen Sie `PATH` in der `sudoers`-Datei explizit für Root-Aktionen, um PATH-Hijacking zu verhindern.

4. Minimale `NOPASSWD`-Verwendung: Verwenden Sie `NOPASSWD` nur, wenn es absolut notwendig ist, und nur für sehr spezifische, „dumme“ Befehle, die keine weiteren Subprozesse starten oder Dateien manipulieren können (z.B. `/bin/systemctl status <service>`). 5. Listen Sie alle abhängigen Befehle auf: Wenn ein Skript als `sudo` ausgeführt wird, das intern weitere Root-Aktionen ausführt, müssen diese weiteren Aktionen ebenfalls explizit in `sudoers` erlaubt werden. 6. `visudo` verwenden: Bearbeiten Sie die `sudoers`-Datei immer mit `visudo`, da dies Syntaxfehler prüft und somit Systemausfälle verhindert.

4. Überprüfung der `sudoers`-Konfiguration

Verwenden Sie den Befehl `sudo -l -U <username>` um zu prüfen, welche `sudo`-Rechte ein bestimmter Benutzer tatsächlich hat. Dies ist unerlässlich nach jeder Änderung.

5. Fazit und Best Practices für Administratoren

Das Prinzip der geringsten Privilegien ist nicht verhandelbar. Jeder unnötige Zugriff ist ein Sicherheitsrisiko.
Pauschale `NOPASSWD: ALL`-Konfigurationen sind extrem gefährlich und sollten vermieden werden.
Genaue Befehlspfade und beschränkte Argumente minimieren das Missbrauchspotenzial.
Achten Sie auf Befehlsketten und vermeiden Sie die Freigabe von interaktiven Programmen oder Skriptinterpretern per `sudo`.
Nutzen Sie `visudo` und testen Sie Konfigurationen immer mit `sudo -l -U <username>`.

`sudo` ist ein mächtiges Werkzeug, das bei korrekter Konfiguration die Systemsicherheit erhöht. Bei unsachgemäßer Handhabung kann es jedoch eine der größten Schwachstellen darstellen.

Stichworte

sudo, sudoers, visudo, Linux, Root-Rechte, Rechteverwaltung, Least Privilege, NOPASSWD, User_Alias, Cmnd_Alias, Host_Alias, Runas_Alias, Regex, Rechteausweitung, Systemsicherheit

xfs_error_kernel

Anonymous (anonymous@undisclosed.example.com) — 2026-05-03T06:46:56+00:00

XFS Fehler nach Kernel-Update

Fehlerbeschreibung

Nach einem Update auf folgenden Kernel:

Linux 4.18.0-553.58.1.el8_10.x86_64

trat beim Booten bzw. Mounten des XFS-Dateisystems folgender Fehler auf:

`kernel: XFS (dm-0): Corruption detected. Unmount and run xfs_repair`
`kernel: XFS (dm-0): Internal error i != 1 at line 481 of file fs/xfs/libxfs/xfs_alloc.c. Caller xfs_alloc_fixup_trees+0x198/0x3b0 [xfs]`

Änderungen an Kernel-Konfiguration

In der Datei `config-4.18.0-553.58.1.el8_10.x86_64` wurden folgende Optionen aktiviert:

CONFIG_XFS_FS=y
CONFIG_XFS_QUOTA=y
CONFIG_XFS_POSIX_ACL=y
CONFIG_XFS_RT=y
CONFIG_XFS_ONLINE_SCRUB=y

Analyse & Hintergrundwissen

Fehlerursache: Der Fehler `i != 1` in `xfs_alloc.c` deutet auf eine Inkonsistenz in den freien Speicherbaumstrukturen des Dateisystems hin. Dies kann durch eine beschädigte Metastruktur oder durch eine fehlerhafte Kernel-Implementierung ausgelöst werden.
xfs_repair: Das Tool `xfs_repair` sollte verwendet werden, um die Dateisystemstruktur zu prüfen und zu reparieren. Wichtig: Das Dateisystem muss vorher ausgehängt werden.
CONFIG_XFS_RT: Aktiviert Unterstützung für „Real-Time Subvolumes“, eine selten genutzte Funktion. Falls nicht benötigt, kann sie deaktiviert werden, um Komplexität zu reduzieren.
CONFIG_XFS_ONLINE_SCRUB: Ermöglicht die Online-Prüfung von Dateisystemstrukturen. Diese Funktion ist experimentell und kann bei bestimmten Kernel-Versionen instabil sein.
Kernel-Kompatibilität: Änderungen an XFS-bezogenen Optionen können zu Inkompatibilitäten mit bestehenden Dateisystemen führen, insbesondere wenn das Dateisystem mit einem älteren Kernel erstellt wurde.

Empfehlung

System im Rescue-Modus starten.
betroffene Partition aushängen (`umount /dev/dm-0`)
`xfs_repair /dev/dm-0` ausführen.
Bei wiederholtem Auftreten: Kernel-Konfiguration prüfen, insbesondere experimentelle Optionen wie `CONFIG_XFS_RT` und `CONFIG_XFS_ONLINE_SCRUB`.
Backup wichtiger Daten vor weiteren Tests!

In meinem konkreten Fall war das root Filesystem betroffen und ich bin das Risiko, ohne xfs_repair auf ausgegangenem Device, mit geänderter Konfiguration neu zu starten, eingegangen.

Quellen & Tools

`man xfs_repair`
https://xfs.org
Kernel-Quellcode: `fs/xfs/libxfs/xfs_alloc.c`

Stichworte

XFS, Kernel, RHEL, EL8, xfs_repair, Filesystem, Korruption, CONFIG_XFS_RT, Rescue

dynaDAT | UNIXoni | REDATEK | ITVeteran - wiki

adaptec_logicaldrive

Austausch von Festplatten und Erstellen eines neuen Logical Drives mit arcconf

Schritt-für-Schritt-Anleitung

Wichtige Hinweise

Stichworte

ausfall_raid_hdd

arcconf – Arbeiten mit RAID-Volumes unter Linux

1. Rescan aller Devices

2. Rebuild anstoßen (wenn automatisch möglich)

3. Device feststellen

4. Device löschen (clear)

5. Device prüfen oder reparieren

6. Danach: Devices erneut scannen

7. Logical Drive prüfen

8. HDD austauschen und identifizieren

Hinweise

Stichworte

dokuwiki

DokuWiki

Download

Read More

Copyright

Stichworte

informix_rowid

Nutzung der rowid in SQL Statements

Unterschiede zwischen Informix rowid und PostgreSQL ctid

Technische Eigenschaften der ctid in PostgreSQL

Beste Praktiken

Mögliche Lösungen bei Migration oder Wrapper-Nutzung

Fazit

Stichworte

iphone_video

iPhone Video (.mov) in MP4 umwandeln

Stichworte

letsencrypt_webpath_docker_renew

Apache Konfiguration für Let's Encrypt Zertifikats-Erneuerung mit Podman

Apache VHost Konfiguration

Beachten im Containerbetrieb

Zertifikat generieren

Let's Encrypt Zertifikats-Erneuerung im Container

Neustart nicht vergessen

Problematik ohne Alias-Direktive

Zusammenfassung

Stichworte

logger

Protokollierung von Benutzeraktionen mit Username in Syslog

Bevorzugte Lösung

Standardlösung: rohe Audit-Meldungen

Ziel

Voraussetzungen

1. Audit-Regeln einrichten

2. Audit-Formatter installieren

3. Audit-Plugin konfigurieren

4. rsyslogd konfigurieren

5. Dienste neu starten

6. Funktion testen

7. Fehlerdiagnose

Sicherheit und Betrieb

Stichworte

sudoer

SUDOERS: Sichere Konfiguration und Best Practices (Admin-Level)

1. Grundprinzip und Sicherheitsaspekte

2. Sichere, granulare `sudoers`-Konfiguration

3. Verhinderung von Befehlsketten und Rechteerschleichung

3.1 Argumente mit Regex exakt begrenzen

4. Überprüfung der `sudoers`-Konfiguration

5. Fazit und Best Practices für Administratoren

Stichworte

xfs_error_kernel

XFS Fehler nach Kernel-Update

Fehlerbeschreibung

Änderungen an Kernel-Konfiguration

Analyse & Hintergrundwissen

Empfehlung

Quellen & Tools

Stichworte