dynaDAT | UNIXoni | REDATEK | ITVeteran

leap_16_informix_konfig

Thomas Schilling (admin@undisclosed.example.com) — 2026-04-18T18:55:53+00:00

Informix unter openSUSE Leap 16.0: fehlende /etc/services und /etc/hosts.equiv

Nach einem Update auf openSUSE Leap 16.0 startet ein Informix-Server, der in der sqlhosts mit einem Servicenamen konfiguriert ist, nicht mehr auf dem erwarteten Port. Zusätzlich werden Client-Verbindungen mit Fehler -956 „Client host or user is not trusted by the server“ abgewiesen, weil /etc/hosts.equiv fehlt.

Ursache

Mit Leap 16.0 hat openSUSE den Weg der Trennung von Distribution-Defaults (/usr/etc) und lokalen Overrides (/etc) konsequent umgesetzt:

  /etc/services ist nur noch eine **leere Dummy-Datei** und soll
  künftig ganz entfallen. Der eigentliche Inhalt liegt jetzt unter
  /usr/etc/services. Das Paket netkit-rsh / rsh-server ist abgelöst durch
  **OpenSSH**. Dadurch werden die klassischen Trust-Dateien /etc/hosts.equiv und /etc/hosts.lpd **nicht mehr automatisch angelegt**.

Quellen:

Auswirkung auf Informix

sqlhosts mit Servicename

Enthält $INFORMIXDIR/etc/sqlhosts einen Servicenamen statt einer Portnummer, z. B.:

ol_azur   onsoctcp   azur.local   sqlexec

… dann löst Informix über getservbyname() gegen /etc/services auf. Unter Leap 16.0 ist diese Datei leer, der Start schlägt mit Meldungen wie

listener-thread: err = -25595: oserr = 0: errstr = ...: Service not found

fehl bzw. der Server bindet nicht auf dem erwarteten Port.

Trusted-Host-Authentifizierung

Informix prüft eingehende Verbindungen standardmäßig gegen eine Trusted-Hosts-Datei:

entweder /etc/hosts.equiv
oder die in onconfig über REMOTE_SERVER_CFG konfigurierte Datei
sowie ~/.rhosts des Zielusers

Fehlt /etc/hosts.equiv komplett, meldet der Client:

-908  Attempt to connect to database server (...) failed.
-956  Client host or user (...) is not trusted by the server.

Siehe: IBM Docs – Trusted-host information

Lösungen

A: Portnummer direkt in sqlhosts

Am robustesten: den Servicenamen durch die numerische Portnummer ersetzen. Damit entfällt die Abhängigkeit von /etc/services vollständig.

ol_azur   onsoctcp   azur.local   9088

Variante B: /etc/services wiederherstellen

Eintrag für Informix manuell ergänzen (auf Server und Client):

sqlexec       9088/tcp
sqlexec-ssl   9089/tcp

Wahlweise als Override in /etc/services (wird gegenüber /usr/etc/services vorgezogen) oder als Drop-in.

IANA-konforme Ports: 9088/tcp (sqlexec), 9089/tcp (sqlexec-ssl).
Siehe: IANA standard service names in sqlhosts.std

hosts.equiv wiederherstellen

Datei /etc/hosts.equiv mit den vertrauenswürdigen Hosts neu anlegen:

# hostname        user
client1.local     informix
client1           informix
10.0.0.15         informix

Zwingende Voraussetzungen (laut IBM Docs):

Besitzer: informix:informix
Rechte: 0644, 0640, 0444 oder 0440
Sowohl Kurzname als auch FQDN eintragen, um DNS-Probleme zu vermeiden.

touch /etc/hosts.equiv
chown informix:informix /etc/hosts.equiv
chmod 0644 /etc/hosts.equiv

Variante empfohlen: REMOTE_SERVER_CFG nutzen

Seit Informix 11.70 kann die Trusted-Hosts-Datei über die onconfig umgelenkt werden – damit ist kein Root-Zugriff auf /etc/hosts.equiv nötig und das Problem ist zukunftssicher gelöst:

In $INFORMIXDIR/etc/onconfig:

REMOTE_SERVER_CFG  trusted_hosts.cfg

Dann Datei $INFORMIXDIR/etc/trusted_hosts.cfg mit den erlaubten Hosts füllen. Änderungen lassen sich im laufenden Betrieb übernehmen:

onmode -wf REMOTE_SERVER_CFG=trusted_hosts.cfg

Quelle: XTIVIA – Informix Trusted Client Connections

Prüfbefehle

# Existiert /etc/services und hat es Inhalt?
ls -l /etc/services /usr/etc/services
getent services sqlexec
 
# Kann Informix den Servicenamen auflösen?
su - informix -c "getent services sqlexec"
 
# Trusted-Host-Datei prüfen
ls -l /etc/hosts.equiv $INFORMIXDIR/etc/hosts.equiv 2>/dev/null
onstat -g cfg | grep REMOTE_SERVER_CFG

Zusammenfassung

Leap 16.0 liefert /etc/services nur noch als Dummy aus – echter

Inhalt liegt in /usr/etc/services.

/etc/hosts.equiv fehlt, da rsh durch OpenSSH ersetzt wurde.
Informix bricht deshalb mit Servicename-basierter sqlhosts und

bei Trusted-Connections (Fehler -956) nach dem Update.

Schnellste Lösung: Portnummer direkt in sqlhosts verwenden, /etc/hosts.equiv wiederherstellen oder auf REMOTE_SERVER_CFG umstellen.

Weiterführende Quellen

Stichworte

Informix, openSUSE Leap 16, sqlhosts, /etc/services, hosts.equiv, REMOTE_SERVER_CFG, Fehler -956, Trusted Host

xfs_error_kernel

Thomas Schilling (admin@undisclosed.example.com) — 2025-08-04T15:23:38+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

statistik_und_audit

Thomas Schilling (admin@undisclosed.example.com) — 2025-07-18T13:33:04+00:00

PostgreSQL DDL-Audit Setup

Dieses Setup dokumentiert alle strukturverändernden Aktionen (DDL) in PostgreSQL, wie z. B. CREATE TABLE, ALTER FUNCTION, DROP INDEX usw. Die Änderungen werden automatisch in einer zentralen Audit-Tabelle gespeichert und sind über ein Dashboard oder View auswertbar.

Verwandter Artikel: Tabellen, Trigger-Funktionen, Event Trigger und Wartung (DISABLE/ENABLE) sind in PostgreSQL DDL Audit Logging beschrieben (Referenzimplementierung).

Ziel

* Nachvollziehbare Dokumentation aller DDL-Änderungen * Speicherung in einer zentralen Tabelle im Schema public * Unterstützung für CREATE, ALTER, DROP und verwandte Befehle * Trennung von Schema und Objektname für bessere Auswertbarkeit * Minimale Belastung für produktive Systeme

Komponenten

* Audit-Tabelle: Speicherung der DDL-Ereignisse * Event Trigger: Reaktion auf DDL-Befehle * Trigger-Prozeduren: Extrahieren der Metadaten aus Systemfunktionen * Optional: pg_stat_statements: Ergänzende Erfassung von DDL-Texten

Schritt 1: Audit-Tabelle erstellen

CREATE TABLE public.ddl_audit_log (
id SERIAL PRIMARY KEY,
command_tag TEXT,             -- z. B. CREATE TABLE, DROP FUNCTION
object_type TEXT,             -- z. B. TABLE, FUNCTION, INDEX
schema_name TEXT,             -- z. B. public
object_name TEXT,             -- z. B. users
executed_by TEXT DEFAULT CURRENT_USER,
executed_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP
);

Schritt 2: Prozedur für CREATE/ALTER

CREATE OR REPLACE FUNCTION public.log_ddl_command()
RETURNS event_trigger
LANGUAGE plpgsql
AS $$
DECLARE
ddl_record RECORD;
BEGIN
FOR ddl_record IN SELECT * FROM pg_event_trigger_ddl_commands()
LOOP
INSERT INTO public.ddl_audit_log (
command_tag,
object_type,
schema_name,
object_name,
executed_by
)
VALUES (
ddl_record.command_tag,
ddl_record.object_type,
split_part(ddl_record.object_identity, '.', 1),
split_part(ddl_record.object_identity, '.', 2),
CURRENT_USER
);
END LOOP;
END;
$$;

Schritt 3: Event Trigger für CREATE/ALTER

CREATE EVENT TRIGGER ddl_audit_trigger
ON ddl_command_end
EXECUTE FUNCTION public.log_ddl_command();

Schritt 4: Prozedur für DROP-Aktionen

CREATE OR REPLACE FUNCTION public.log_ddl_drop()
RETURNS event_trigger
LANGUAGE plpgsql
AS $$
DECLARE
obj RECORD;
BEGIN
FOR obj IN SELECT * FROM pg_event_trigger_dropped_objects()
LOOP
INSERT INTO public.ddl_audit_log (
command_tag,
object_type,
schema_name,
object_name,
executed_by
)
VALUES (
'DROP',
obj.object_type,
split_part(obj.object_identity, '.', 1),
split_part(obj.object_identity, '.', 2),
CURRENT_USER
);
END LOOP;
END;
$$;

Schritt 5: Event Trigger für DROP-Aktionen

CREATE EVENT TRIGGER ddl_drop_audit_trigger
ON sql_drop
EXECUTE FUNCTION public.log_ddl_drop();

Wartung: Trigger aktivieren/deaktivieren

Befehle und Erläuterung: PostgreSQL DDL Audit Logging — Abschnitt Wartung: Trigger aktivieren/deaktivieren.

Beispiel: DDL-Aktion und Auswertung

\-- Beispielaktion
CREATE TABLE public.audit_test (
id SERIAL PRIMARY KEY,
name TEXT
);
 
DROP TABLE public.audit_test;
 
\-- Auswertung
SELECT * FROM public.ddl_audit_log ORDER BY executed_at DESC;

Optional: View für Dashboard

CREATE VIEW public.ddl_audit_summary AS
SELECT
executed_at::DATE AS datum,
schema_name,
object_name,
command_tag,
object_type,
executed_by
FROM public.ddl_audit_log
ORDER BY executed_at DESC;

Erweiterung: pg_stat_statements

Die PostgreSQL-Erweiterung pg_stat_statements kann ergänzend verwendet werden, um vollständige DDL-Befehle (inkl. Spaltennamen) zu erfassen, die über Event Trigger nicht verfügbar sind.

SELECT query, calls, userid, dbid, queryid, total_time
FROM pg_stat_statements
WHERE query LIKE 'ALTER TABLE%'
AND query \~\* 'ADD COLUMN|DROP COLUMN|RENAME COLUMN'
ORDER BY total_time DESC;

oder eben selektiv mit lesbarem User und Datenbanknamen:

SELECT a.rolname,b.datname,c.query
FROM public.pg_stat_statements c, pg_roles a, pg_database b
WHERE a.oid = c.userid AND b.oid = c.dbid
AND c.query LIKE 'ALTER%';

Hinweis:

* Die Erweiterung speichert normierte SQL-Befehle * Die Statistik wird nicht sofort aktualisiert * Für produktive Systeme mit hoher Last kann die Kombination mit Event Triggern zu Performance-Einbußen führen

Hinweise

* Die Spalte ddl wurde entfernt, da der Typ pg_ddl_command nicht direkt gespeichert werden kann. * Spaltenänderungen (z. B. ADD COLUMN) enthalten keine Spaltennamen über Event Trigger. * Die Lösung ist leichtgewichtig und für produktive Systeme geeignet. * DDL-Audit vorübergehend aus: PostgreSQL DDL Audit Logging, Abschnitt Wartung: Trigger aktivieren/deaktivieren (ALTER EVENT TRIGGER … DISABLE / ENABLE). * Event Trigger und Tabellen-Trigger sind verschiedene Mechanismen — siehe folgender Unterabschnitt.

Event Trigger versus Tabellen-Trigger

Aspekt	Event Trigger (dieses DDL-Audit)	Tabellen-Trigger
Zweck	Reaktion auf DDL (`CREATE TABLE`, `DROP`, …) auf Datenbankebene	Reaktion auf Datenänderungen in einer Tabelle: `INSERT` / `UPDATE` / `DELETE`, oft `FOR EACH ROW`
Anlage	`CREATE EVENT TRIGGER …`	`CREATE TRIGGER … ON eine_tabelle …`
Abschalten (Beispiel)	`ALTER EVENT TRIGGER … DISABLE` / `… ENABLE`	z. B. `ALTER TABLE … DISABLE TRIGGER …`

Zum vorübergehenden Abschalten dieses DDL-Audits werden nur Event Trigger mit ALTER EVENT TRIGGER … gesteuert. ALTER TABLE … DISABLE TRIGGER … betrifft Tabellen-Trigger auf einer konkreten Tabelle und hat mit diesem DDL-Protokoll nichts zu tun.

Erweiterungen möglich

* Filterung nach Objektarten oder Benutzer * Integration mit Git zur Versionskontrolle * Visualisierung der Änderungen über Dashboards * Benachrichtigung bei kritischen Änderungen (z. B. DROP TABLE)

Bemerkung

Für mich ist das Standard Vorgehen meist unbrauchbar, da pg_stat_statements wie auch pgaudit nicht das Objekt selbst aufzeichnet. Ich schreibe meine eigene Triggerfunction — dokumentiert in PostgreSQL DDL Audit Logging.

Stichworte

PostgreSQL, DDL, Audit, Event Trigger, pg_stat_statements, Dashboard

informix_fdw - angelegt

Thomas Schilling (admin@undisclosed.example.com) — 2025-06-20T13:19:10+00:00

IMPORT FOREIGN SCHEMA von Informix nach PostgreSQL

Vorbereitung

Zur besseren Nachverfolgung aktivieren wir das erweiterte Debugging:

SET client_min_messages TO DEBUG2;

Vollständiger IMPORT aller Tabellen eines Informix-Datenbank-Schemas

IMPORT FOREIGN SCHEMA daten
    FROM SERVER tcp_azur_Test
    INTO test
    OPTIONS (DATABASE 'test');

LIMITIERTER IMPORT (z. B. nur eine Tabelle)

IMPORT FOREIGN SCHEMA informix
    LIMIT TO (abfrage)
    FROM SERVER tcp_azur_Test
    INTO test
    OPTIONS (DATABASE 'test');

Hinweis:

`IMPORT FOREIGN SCHEMA` bezieht sich nicht auf das PostgreSQL-Schema, sondern auf den Owner der Tabellen im Informix-System.
Die Angabe wie z. B. `daten` ist ein Benutzer (Owner) in Informix, nicht der Name eines Schemas.
Beispielhafte vom Server generierte Abfrage:

    DEBUG:  PREPARE query "SELECT tabid, trim(owner), tabname FROM systables 
    WHERE tabid >= 100 AND owner = 'daten' 
    AND tabname IN ('abfrage') ORDER BY tabname DESC"

Wichtiger Hinweis zur Richtung des Imports

Ein `IMPORT FOREIGN SCHEMA` ist nur unidirektional möglich:

Von Informix nach PostgreSQL. Nicht umgekehrt! Ein Export oder Zugriff von Informix auf PostgreSQL über dieselbe Methode ist nicht möglich. Das Schema muss also zwingend auf Informix vorhanden sein!

Kopieren der Tabellen lokal in PostgreSQL (struktur+daten)

Die folgende PL/pgSQL-Prozedur kopiert Tabellen aus dem per Foreign Schema importierten Schema (`quelle`) in ein lokales Zielschema (`ziel`).

Dabei wird:

das Zielschema ggf. neu angelegt,
jede Tabelle zuerst strukturell dupliziert (`LIKE … INCLUDING ALL`),
anschließend werden die Daten kopiert.
Bei einem Fehler wird trotzdem die leere Tabelle erstellt (zur späteren Analyse oder Wiederholung).

CREATE OR REPLACE PROCEDURE db.kopie(
    IN quelle TEXT,
    IN ziel TEXT)
LANGUAGE 'plpgsql'
AS $$
DECLARE
    tabelle TEXT;
BEGIN
    -- Schema prüfen und ggf. erstellen
    PERFORM 1 FROM information_schema.schemata WHERE schema_name = ziel;
    IF NOT FOUND THEN
        EXECUTE format('CREATE SCHEMA %I', ziel);
    END IF;
 
    -- Tabellenstruktur kopieren
    FOR tabelle IN
        SELECT TABLE_NAME
        FROM information_schema.tables
        WHERE table_schema = quelle
    LOOP
        EXECUTE format('DROP TABLE IF EXISTS %I.%I', ziel, tabelle);
        RAISE NOTICE 'Struktur % verarbeitet', tabelle;
        EXECUTE format(
            'CREATE TABLE %I.%I (LIKE %I.%I INCLUDING ALL)',
            ziel, tabelle, quelle, tabelle
        );
    END LOOP;
 
    -- Daten kopieren mit Fehlerbehandlung
    FOR tabelle IN
        SELECT TABLE_NAME
        FROM information_schema.tables
        WHERE table_schema = quelle
    LOOP
        BEGIN
            EXECUTE format('INSERT INTO %I.%I SELECT * FROM %I.%I',
                           ziel, tabelle, quelle, tabelle);
            RAISE NOTICE 'Tabelle % verarbeitet', tabelle;
        EXCEPTION WHEN OTHERS THEN
            RAISE NOTICE '------------ FEHLER bei % --------------', tabelle;
            COMMIT;
        END;
    END LOOP;
END;
$$;
 
ALTER PROCEDURE db.kopie(text, text)
    OWNER TO postgres;

Zusammenfassung

`IMPORT FOREIGN SCHEMA` erlaubt das Einbinden externer Informix-Tabellen als Foreign Tables in PostgreSQL.
Ein vollständiger Import kann auf Wunsch auf einzelne Tabellen beschränkt werden.
Für dauerhafte Nutzung oder Fehlerunabhängigkeit empfiehlt sich die Kopie der Tabellen lokal via PL/pgSQL.
Der Prozess ist einseitig – nur von Informix zu PostgreSQL möglich.

Stichworte

PostgreSQL, Informix, IMPORT FOREIGN SCHEMA, FDW, Foreign Data Wrapper

informix_rowid - angelegt

Thomas Schilling (admin@undisclosed.example.com) — 2025-06-17T12:23:25+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

dokuwiki

Thomas Schilling (admin@undisclosed.example.com) — 2025-06-08T14:17:04+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.

¹⁾

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

ham_spam_sa-learn

Thomas Schilling (admin@undisclosed.example.com) — 2025-06-08T12:28:57+00:00

Hinzugefügte Cronjob-Einträge

Ich habe folgende Cronjob-Einträge hinzugefügt, um den Spam-Filter (SpamAssassin) zu trainieren:

Spam lernen:

    sa-learn --spam /var/mail/*/*/.Junk --dbpath /var/mail-state/lib-amavis/.spamassassin

Ham (keine Spam) lernen:

    sa-learn --ham /var/mail/*/*/.Ham --dbpath /var/mail-state/lib-amavis/.spamassassin

Synchronisieren:

    sa-learn --sync

Einbindung des Cron-Job-Volumes

Das Cron-Job-Volume wird über die `docker-compose.yml` eingebunden:

/container/mail/docker-data/dms/cron/sa-learn:/etc/cron.d/sa-learn

Nachtrag 2025 Wechsel von amavisd zu rspamd

Änderung der CRON Jobs

rspamd lernt über andere Hilfsprogramme. So sollte der cronjob Eintrag aussehen

9 3 * * * root rspamc learn_spam /var/mail/*/*/.Junk/cur
9 3 * * * root rspamc learn_ham /var/mail/*/*/.Ham/cur

Hinweis nach Update Juni 2025

Das Procedere ist nach wie vor nötig Fehlermeldung syslog Docker-Mailserver

Stichworte

SpamAssassin, rspamd, sa-learn, Cron, Docker-Mailserver, Mail

letsencrypt_webpath_docker_renew

Thomas Schilling (admin@undisclosed.example.com) — 2025-06-01T15:47:23+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

neuer_user_domain

Thomas Schilling (admin@undisclosed.example.com) — 2025-05-23T11:23:32+00:00

Mail Prozedur

Neue Konten

podman exec -ti mailserver setup add neu@domain.tld

Kontrolle

podman exec -ti mailserver setup email list

Neue Domain DKIM DMARC

podman exec -ti mailserver setup config dkim

Einträge im DNS

DKIM

  mail._domainkey IN TXT v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w......

DMARC

  _dmarc.example.com. IN TXT v=DMARC1; p=quarantine; sp=quarantine; fo=0; adkim=r; aspf=r; pct=100; rf=afrf; ri=86400; rua=mailto:dmarc.report@example.com; ruf=mailto:dmarc.report@example.com

SPF

  TXT v=spf1 ip4:91.26.196.29 ~all

Prüfung

MXToolbox SuperTool

Info

DKIM, DMARC, SPF – Docker Mailserver Dokumentation

Stichworte

Mailserver, DKIM, DMARC, SPF, DNS, docker-mailserver, Podman

enterpriselogorahmen2.png - angelegt

Thomas Schilling (admin@undisclosed.example.com) — 2024-08-31T07:35:35+00:00

favicon.ico - angelegt

Thomas Schilling (admin@undisclosed.example.com) — 2024-08-31T06:50:21+00:00

logo.png - angelegt

Thomas Schilling (admin@undisclosed.example.com) — 2024-08-31T06:50:21+00:00

vt52.jpg - angelegt

Thomas Schilling (admin@undisclosed.example.com) — 2024-08-31T05:59:40+00:00

gfud.png - angelegt

Thomas Schilling (admin@undisclosed.example.com) — 2024-08-31T05:59:40+00:00

banner.png - angelegt

Thomas Schilling (admin@undisclosed.example.com) — 2024-08-31T05:59:40+00:00

itveteran.png - angelegt

Thomas Schilling (admin@undisclosed.example.com) — 2024-08-31T05:59:40+00:00

bdrthomas-336x400-1.jpg - angelegt

Thomas Schilling (admin@undisclosed.example.com) — 2024-08-21T13:34:38+00:00

ksnip_20240821-144545.png - angelegt

Thomas Schilling (admin@undisclosed.example.com) — 2024-08-21T12:58:45+00:00

ksnip_20240821-144826.png - angelegt

Thomas Schilling (admin@undisclosed.example.com) — 2024-08-21T12:58:12+00:00

dynaDAT | UNIXoni | REDATEK | ITVeteran

leap_16_informix_konfig

Informix unter openSUSE Leap 16.0: fehlende /etc/services und /etc/hosts.equiv

Ursache

Auswirkung auf Informix

sqlhosts mit Servicename

Trusted-Host-Authentifizierung

Lösungen

A: Portnummer direkt in sqlhosts

Variante B: /etc/services wiederherstellen

hosts.equiv wiederherstellen

Variante empfohlen: REMOTE_SERVER_CFG nutzen

Prüfbefehle

Zusammenfassung

Weiterführende Quellen

Stichworte

xfs_error_kernel

XFS Fehler nach Kernel-Update

Fehlerbeschreibung

Änderungen an Kernel-Konfiguration

Analyse & Hintergrundwissen

Empfehlung

Quellen & Tools

Stichworte

statistik_und_audit

PostgreSQL DDL-Audit Setup

Ziel

Komponenten

Schritt 1: Audit-Tabelle erstellen

Schritt 2: Prozedur für CREATE/ALTER

Schritt 3: Event Trigger für CREATE/ALTER

Schritt 4: Prozedur für DROP-Aktionen

Schritt 5: Event Trigger für DROP-Aktionen

Wartung: Trigger aktivieren/deaktivieren

Beispiel: DDL-Aktion und Auswertung

Optional: View für Dashboard

Erweiterung: pg_stat_statements

Hinweise

Event Trigger versus Tabellen-Trigger

Erweiterungen möglich

Bemerkung

Stichworte

informix_fdw - angelegt

IMPORT FOREIGN SCHEMA von Informix nach PostgreSQL

Vorbereitung

Vollständiger IMPORT aller Tabellen eines Informix-Datenbank-Schemas

LIMITIERTER IMPORT (z. B. nur eine Tabelle)

Wichtiger Hinweis zur Richtung des Imports

Kopieren der Tabellen lokal in PostgreSQL (struktur+daten)

Zusammenfassung

Stichworte

informix_rowid - angelegt

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

dokuwiki

DokuWiki

Download

Read More

Copyright

ham_spam_sa-learn

Hinzugefügte Cronjob-Einträge

Einbindung des Cron-Job-Volumes

Nachtrag 2025 Wechsel von amavisd zu rspamd

Änderung der CRON Jobs

Hinweis nach Update Juni 2025

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

LIMITIERTER IMPORT (z. B. nur eine Tabelle)