Beiträge von hchristo

  • Feature-Wunsch: ALIAS-Record-Typ für DNS-Einträge (LiveConfig 2 & 3)

    Hallo zusammen,

    im DNS-Editor (siehe Screenshot – Auswahl der Record-Typen beim Anlegen eines neuen Eintrags) gibt es aktuell A, AAAA, CAA, CNAME, MX, NS, SSHFP, SRV, TLSA, TXT und PTR – aber keinen ALIAS-Typ.

    Warum das fehlt und nützlich wäre: CNAME darf laut RFC nicht auf der Zonen-Root (@) gesetzt werden, wenn dort gleichzeitig andere Records (MX, TXT/SPF, NS etc.) existieren – was bei praktisch jeder "echten" Domain der Fall ist.


    Genau dafür haben sich ALIAS-Records etabliert (von PowerDNS, Cloudflare, AWS Route53, DNSimple u.a. schon länger unterstützt): Der Nameserver löst das Ziel serverseitig bei jeder Anfrage auf und liefert direkt A/AAAA-Records aus – funktioniert dadurch auch auf der Root-Domain, ohne die CNAME-Einschränkung zu verletzen.

    Mittlerweile praktisch der Standard-Ersatz für "CNAME auf der Root-Domain", daher der Filenamen-Scherz "ALIAS ist das neue CNAME".


    Konkreter Anwendungsfall: Root-Domain (example.tld) soll auf einen extern gehosteten Dienst zeigen (z.B. eine CDN-Adresse, einen Load Balancer, GitHub Pages, o.ä.), der selbst hinter einem sich ändernden Hostnamen/IP-Set liegt – aktuell nur über feste A/AAAA-Records lösbar, die man manuell nachpflegen muss, sobald sich die Ziel-IP ändert.


    Wunsch: Einen ALIAS-Typ im DNS-Editor (Liveconfig 2 UND 3) ergänzen, der intern periodisch aufgelöst und als A/AAAA-Records in die Zone geschrieben wird (klassische "ALIAS via serverseitiger Auflösung"-Umsetzung, wie es andere Anbieter machen).

    Wäre das grundsätzlich denkbar? Falls es dafür schon einen Workaround oder ein bestehendes Ticket/Feature-Request gibt, gerne Bescheid geben – habe nichts dazu gefunden.

  • Bugreport: Fehlende Spalte USERS.U_REJECTED_COUNT nach Upgrade 2.19.x → 3.2.4

    Zitat von kk

    Nachtrag: vermutlich handelt es sich hier um einen mit KI erstellten Fehlerbericht. Der Neustart vom lcpolicyd dürfte das Problem vermutlich behoben haben (da legt lcpolicyd nämlich die neue Spalte automatisch an), das Hinzufügen von U_REJECTED_COUNT in die USERS-Tabelle von LiveConfig hat absolut keine Auswirkung (und sollte bitte wieder rückgängig gemacht werden).

    Hallo Herr Keppler,

    danke für den Nachtrag – die zusätzliche Spalte in der MySQL-USERS-Tabelle war tatsächlich unwirksam/falsch begründet, wie Sie schon vermutet hatten. Sie wurde bereits vor einiger Zeit wieder per ALTER TABLE ... DROP COLUMN entfernt, ist also nicht mehr vorhanden. Danke für die Klarstellung zur eigentlichen Ursache (lcpolicyd-eigene SQLite-Migration)!

    Viele Grüße

  • Frage: Proxy-Domain (Apache) erzeugt immer trailing Slash im Ziel – kollidiert das mit /liveconfig/hosting/dnsupdate?

    Hallo kk,

    mir ist nach dem Umstieg auf 3.2.4 etwas aufgefallen, das ich gerne einmal zur Einordnung teilen möchte – bin mir nicht sicher, ob das so gewollt ist oder ein Nebeneffekt, den ich einfach noch nicht richtig verstehe.


    Setup: Ich habe eine Domain ([tt]ddns.example.tld[/tt]) im Panel als "Proxy" auf [tt]http://127.0.0.1:82/liveconfig/hosting/dnsupdate[/tt] angelegt, um sie als eigene DynDNS-Update-URL für Kundenrouter (FritzBox, Ubiquiti UDM oder aber Synology) zu nutzen.


    Beobachtung: Egal was ich als Ziel eintrage (mit oder ohne trailing Slash), im generierten Apache-vHost landet immer ein Slash am Ende:

    Code
    ProxyPass        "/" "http://127.0.0.1:82/liveconfig/hosting/dnsupdate/" upgrade=websocket nocanon
ProxyPassReverse "/" "http://127.0.0.1:82/liveconfig/hosting/dnsupdate/"


    Das scheint an dieser Stelle in apache.lua zu liegen (Zeilennummer kann je Version leicht abweichen):

    Code
    if string.sub(dst, -2) == '/*' then dst = string.sub(dst, 1, string.len(dst)-1) end
if string.sub(dst, -1) ~= '/' then dst = dst .. '/' end


    Warum das für mich relevant wurde: Die eigene [tt]/liveconfig/hosting/dnsupdate[/tt]-Route scheint auf eingehende Requests mit trailing Slash ([tt].../dnsupdate/?hostname=...[/tt]) mit 404 zu reagieren, während sie ohne Slash ([tt].../dnsupdate?hostname=...[/tt]) ganz normal mit 401 (fehlende Zugangsdaten) reagiert – also grundsätzlich erreichbar ist.


    Dadurch laufen alle DynDNS-Update-Requests über den Proxy ins Leere, sobald die Domain als Proxy-Typ im Panel verwaltet wird.


    Ich habe das lokal mit curl direkt gegen den internen Port reproduziert (mit und ohne Slash, jeweils identischer Query-String), das Verhalten war reproduzierbar unterschiedlich.


    Frage: Ist das gewolltes Verhalten (und ich sollte die dnsupdate-Route anders/über einen anderen Weg ansprechen), oder ist das eine Lücke zwischen dem generierten Proxy-Ziel und der eigenen Routen-Matching-Logik?


    Falls es tatsächlich ein Zusammenspiel ist, das so nicht beabsichtigt war, würde mich freuen, wenn das mal jemand mit tieferem Einblick in den Code gegenspiegeln könnte – nicht, dass ich da was übersehe.


    Danke schon mal & viele Grüße

  • Bugreport: Fehlende Spalte USERS.U_REJECTED_COUNT nach Upgrade 2.19.x → 3.2.4

    Danke für die Aufklärung! Bestätigt: Nach dem systemctl restart lcpolicyd hat die Datei /var/lib/liveconfig/lcpolicyd.db jetzt korrekt die Spalte:

    Code
    CREATE TABLE USERS ( U_ID INTEGER PRIMARY KEY AUTOINCREMENT NOT NULL, U_USER VARCHAR(255) NOT NULL,  U_LIMIT_1_INTERVAL INTEGER NOT NULL, U_LIMIT_1_LIMIT INTEGER NOT NULL,  U_LIMIT_2_INTERVAL INTEGER NOT NULL, U_LIMIT_2_LIMIT INTEGER NOT NULL,  U_LASTTS INTEGER, U_SEND_STATUS TINYINT DEFAULT 0 NOT NULL,  U_REJECTED_COUNT INTEGER DEFAULT 0 NOT NULL);

    (Meine ursprüngliche Annahme, dass es sich um eine fehlende Spalte in der MySQL-Haupt-DB handelt, war falsch — ich hatte dort eine Spalte ergänzt, die keinen Effekt hatte, und habe sie wieder entfernt.)

    Zeitlicher Ablauf laut Journal:

    • 14:23:17 — lcpolicyd startet zum ersten Mal nach dem Upgrade (kein Fehler im Journal zu diesem Zeitpunkt sichtbar)
    • 14:36:41 — erster [ERR] no such column: U_REJECTED_COUNT (offenbar der erste tatsächliche Login-Versuch nach dem Upgrade, ca. 13 Minuten nach dem Start)
    • Fehler tritt danach bei jedem Login-Versuch wiederholt auf (mehrfach bis 16:24 Uhr protokolliert)
    • 16:27:49 — manueller systemctl restart lcpolicyd → danach keine Fehler mehr, Spalte korrekt vorhanden

    Das deutet darauf hin, dass die Migration beim allerersten Start (ausgelöst durchs Paket-Postinst) nicht korrekt durchlief, ein manueller Neustart später aber problemlos funktionierte.

    Angeforderter Ausschnitt aus /var/log/apt/term.log (kompletter Log-Block für den Upgrade-Vorgang):

    Code
    Log started: 2026-08-19  14:23:06
Entfernen von liveconfig (2.19.1-release) ...
Vormals nicht ausgewähltes Paket liveconfig3 wird gewählt.
Vorbereitung zum Entpacken von .../liveconfig3_3.2.4-1.17979_amd64.deb ...
Entpacken von liveconfig3 (3.2.4-1.17979) ...
liveconfig3 (3.2.4-1.17979) wird eingerichtet ...
Created symlink '/etc/systemd/system/multi-user.target.wants/lcbackup.service' → '/usr/lib/systemd/system/lcbackup.service'.
Trigger für man-db (2.13.1-1) werden verarbeitet ...
Trigger für libc-bin (2.41-12+deb13u3) werden verarbeitet ...
Log ended: 2026-08-19  14:23:19

    Auffällig: Im Log wird nur der lcbackup.service-Symlink explizit erwähnt, kein Hinweis auf einen lcpolicyd-Neustart durch das Postinst-Skript selbst (der laut journalctl aber trotzdem um 14:23:17 erfolgte — vermutlich durch einen separaten systemctl restart-Aufruf im Postinst, der in diesem Log-Ausschnitt nicht mitgeschrieben wird).

    Danke nochmal, insgesamt also kein LiveConfig-weiter Bug, sondern ein einmaliger Migrations-Hänger beim ersten Start nach dem Upgrade, der sich per Neustart beheben ließ.

  • Bugreport: Fehlende Spalte USERS.U_REJECTED_COUNT nach Upgrade 2.19.x → 3.2.4

    Umgebung

    • LiveConfig-Version: 3.2.4 (Build 17979), Paket liveconfig3
    • Vorherige Version: 2.19.1-release (Upgrade von 2.x auf 3.x, kein Neuinstall)
    • OS: Debian
    • Datenbank: MariaDB (Connector/C 3.4.9)
    • Mailsystem: Postfix mit lcpolicyd als Autorisierungs-Policy-Dienst (authorized_submit_users via socketmap:unix:/var/run/lcpolicyd-lookup.sock:user)


    Symptom

    Nach dem Upgrade auf 3.2.4 schlägt jeder Login im LiveConfig-Panel (Web-UI, POST /liveconfig/app/login) mit folgendem Fehler fehl:

    Code
    Login failed
An internal server error has occured. Please check the log file for more details.


    Root Cause

    Beim erfolgreichen Login versucht LiveConfig, eine Sicherheits-Benachrichtigungsmail zu versenden (z. B. "Anmeldung mit neuem Gerät"). Dieser Versand ruft /usr/sbin/sendmail auf, welches über den lcpolicyd-Socket die Absenderberechtigung prüft. Diese Prüfung schlägt fehl:

    Code
    sendmail: warning: socketmap:unix:/var/run/lcpolicyd-lookup.sock:user socketmap server permanent error: Lookup error. please try again later!
sendmail: fatal: authorized_submit_users: socketmap:unix:/var/run/lcpolicyd-lookup.sock:user: table lookup problem

    Der resultierende Exit-Code 75 von sendmail führt zu einer unbehandelten Exception im LiveConfig-Server-Prozess, die den gesamten Login-Request abbricht:

    Code
    [EMERG] Uncaught exception: /usr/sbin/sendmail returned with exit code 75
[EMERG] METHOD: POST; URL: /liveconfig/app/login
[EMERG] Got exception: std::runtime_error

    Im lcpolicyd-Log (/var/log/liveconfig/lcpolicyd.log) findet sich die eigentliche Ursache:

    Code
    [ERR] no such column: U_REJECTED_COUNT

    Die Spalte U_REJECTED_COUNT in der Tabelle liveconfig.USERS fehlt nach dem Upgrade komplett — offenbar wurde der entsprechende Datenbank-Migrations-Patch beim Upgrade von 2.19.x auf 3.2.4 nicht (vollständig) ausgeführt, obwohl der Log beim Start mehrere Patches auflistete (Applying database patch 3.00.00 bis 3.03.01).


    Workaround (selbst angewendet, funktioniert)

    Code
    ALTER TABLE liveconfig.USERS ADD COLUMN U_REJECTED_COUNT INT NOT NULL DEFAULT 0;

    Anschließend systemctl restart lcpolicyd (der Dienst hatte die fehlschlagende Query offenbar zwischengespeichert/vorbereitet und musste neu starten, um die neue Spalte zu erkennen).

    Nach diesem Fix funktionieren Login und Sicherheits-Benachrichtigungsmails wieder einwandfrei.


    Vorschlag

    Bitte den Datenbank-Migrationspfad für Upgrades von 2.19.x auf 3.x prüfen — der Patch, der U_REJECTED_COUNT (vermutlich Teil einer neuen Brute-Force-/Rate-Limiting-Funktion für Logins) anlegt, scheint bei bestehenden Installationen mit Upgrade-Historie nicht zuverlässig zu greifen.

  • Absturzbericht: liveconfig.service beendet sich beim Shutdown mit SIGABRT (uncaught signal 6)

    Kleiner Crashbericht für Liveconfig v2:



    Absturzbericht: liveconfig.service beendet sich beim Shutdown mit SIGABRT (Signal 6)

    ======================================================================================


    Umgebung: Debian GNU/Linux 13 (trixie), LiveConfig 2.19.1-release.

    Auslöser: regulärer System-Reboot (systemctl reboot), kein Crash im Normalbetrieb.


    Zusammenfassung

    ---------------

    Beim Reboot am 2026-08-14 ca. 22:16-22:17 Uhr hat sich liveconfig.service nicht

    sauber beendet, sondern nach ca. 60s mit Backtrace und SIGABRT terminiert. Der

    Versuch, den Crash-Report an update.liveconfig.com zu senden, schlug fehl, weil

    das Netzwerk beim Shutdown bereits abgebaut war.


    Ablauf (aus /var/log/liveconfig/liveconfig.log, PID 11366=Haupt-, 11367=Serverkind)

    ------------------------------------------------------------------------------------

    1. 22:15:11 - Serverkind (11367) verliert MySQL-Verbindung, weil MariaDB im

    selben Reboot ebenfalls gestoppt wird. Reconnect-Loop mit Backoff startet:

    1s -> 2s -> 4s -> 8s -> 16s -> 32s.

    2. 22:16:14 - systemd sendet SIGTERM an den Hauptprozess, um den Dienst zu

    stoppen. Das Serverkind steckt gerade im 32s-Sleep des Reconnect-Loops und

    reagiert nicht.

    3. 22:17:14 (60s später) - systemd eskaliert, sendet SIGTERM erneut, diesmal

    direkt von PID 1. Das Serverkind terminiert daraufhin mit nicht abgefangenem

    Signal 6 (Aborted).

    4. Der Hauptprozess loggt einen Backtrace und versucht erfolglos, den Crash

    automatisch zu melden (HTTPClient: connection error, state=7), da das

    Netzwerk zu dem Zeitpunkt schon gestoppt war. 22:17:18 - "LiveConfig

    terminated."


    Ursache

    -------

    Der MySQL-Reconnect-Loop im Serverkind reagiert offenbar nicht auf SIGTERM,

    während er in seinem Backoff-Sleep blockiert. Erst nach Ablauf von

    TimeoutStopSec (65s) und einem zweiten SIGTERM direkt von PID 1 terminiert der

    Prozess - dann aber per uncaught SIGABRT statt sauber.


    Ausgelöst wurde es dadurch, dass MariaDB im selben Shutdown praktisch

    gleichzeitig mit LiveConfig gestoppt wurde: liveconfig.service hat keine

    explizite Abhängigkeit zu mariadb.service, daher lief der Reconnect-Loop noch,

    als das Stop-Signal kam.


    Häufigkeit: einmaliges Auftreten. Weder das vorherige Log (bis 2026-08-01) noch

    die Journal-Historie (zurück bis 2026-07-05) zeigen einen zweiten Fall - alle

    anderen Stops liefen sauber in unter 1s durch.


    Relevanter Ausschnitt aus liveconfig.service (vor dem Fix)

    -------------------------------------------------------------

    Code
    [Unit]
After=network-online.target
[Service]
Type=forking
ExecStop=/usr/sbin/liveconfig -k stop
TimeoutStopSec=65
KillMode=process


    -> Keine Abhängigkeit zu mariadb.service vorhanden.


    Log-Auszug (Rohdaten, Zeitstempel/PID-Präfix "[2026/08/14 HH:MM:SS.ffffff] [PID|TID]" gekürzt)

    --------------------------------------------------------------------------------------------------

    Getestete, funktionierende Lösung

    ------------------------------------

    systemd-Override für liveconfig.service, ergänzt "After=mariadb.service":


    nano /etc/systemd/system/liveconfig.service.d/override.conf

    Code
    [Unit]
After=mariadb.service


    systemd stoppt Dienste in umgekehrter Start-Reihenfolge, LiveConfig wird damit

    beim Shutdown zuverlässig VOR MariaDB gestoppt - der Reconnect-Loop läuft dann

    gar nicht erst in die Race Condition. Verifiziert per:

    systemctl show liveconfig.service -p After

    -> ...mariadb.service... (enthalten)


    Vorschlag an den Support: "After=mariadb.service" (bzw. die jeweils passende

    DB-Unit, z.B. mysql.service) direkt ins offizielle liveconfig.service-Template

    aufnehmen, damit alle Installationen mit lokaler DB automatisch profitieren -

    zusätzlich wäre wünschenswert, wenn der Reconnect-Loop selbst auf SIGTERM auch

    während eines laufenden Backoff-Sleeps reagieren würde.


    Für andere Admins: passendes Fix-Script als separater Anhang

    (fix-liveconfig-shutdown-order.sh, hier als .txt hochgeladen - vor Ausführung

    zu .sh umbenennen). Erkennt den DB-Service automatisch, legt den Override an,

    kein Neustart von LiveConfig nötig.


    Code
    mv fix-liveconfig-shutdown-order.sh.txt fix-liveconfig-shutdown-order.sh
chmod +x fix-liveconfig-shutdown-order.sh
sudo ./fix-liveconfig-shutdown-order.sh

    Das Script erkennt automatisch euren laufenden Datenbank-Service (mariadb.service/mysql.service/mysqld.service), legt einen systemd-Override für liveconfig.service an und lädt systemd neu. Kein Neustart von LiveConfig nötig, keine Downtime, gefahrlos mehrfach ausführbar.

  • LC 3 Produktiv fähig?

    Es werden ja gem. Changelog ja viele Fehler ausgemerzt.
    Meine Frage ist: Ist liveconfig 3 mittlerweile nutzbar so wie Liveconfig 2 oder sollte man noch die Finger von lassen.


    Freue mich auf die Umfrageergebnisse

  • Roundcube 1.7 / App-Installation

    Hab bereits Roundcube 1.7 im einsatz.

    → H a f t u n g s a u s s c h l u s s ←

    Diese Anleitung wurde nach bestem Wissen erstellt und nur auf meinem Eigenen Server getestet und Umgesetzt.

    Es gibt jedoch keine Garantie auf Funktion, Sicherheit oder Vollständigkeit.

    Die Umsetzung erfolgt auf eigene Gefahr und Verantwortung.

    Der Autor übernimmt keine Haftung für Schäden, Datenverluste, Sicherheitsrisiken oder sonstige negative Folgen.

    Die Anleitung richtet sich ausschließlich an erfahrene Administratoren.



    Wenn du Upgraden möchtest hier meine Config files (im Anhang meines Posts):
    Webmail Domain einstellungen:


    Meine Mailserver Settings:



    Vielleicht hilft das jemanden.


    Ladet euch die neuste Version von Roundcube runter, und ersetzt den Ordner "config" und die "composer.json" im Rootverzeichnis von Roundcube durch meine im ZIP Gepackten Dateien.

    Ich selber habe Roundcube WebMail nicht als APP in der Installation, ich hab das damals in meinem Webspace verlagert für meine Kunden.
    Daher beruht diese "Anleitung" auf eine eigenständige Installation.


    Bitte beachtet dass die Verzeichnisrechte danach erneut gesetzt werden müssen, je nach Inhaber, in meinem fall ist das Gruppe/Nutzer: hchristo:hchristo
    Ebenfalls müssen für die Datei config.inc.php in dem Ordner config die Datenbankparameter angepasst werden.



    Um das in betrieb zu nehmen muss der Composer runtergeladen werden:

    1. mit cd /pfad/zu/roundcubemail navigieren wir ins Roundcube Root Verzeichnis.
    2. jetzt muss der Composer runtergeladen werden, das geht mit curl -s https://getcomposer.org/installer | php
      Setze die Rechte auf die Datei "composer.phar" entsprechend dem welches auch die Rechte zum Roundcube Root Verzeichnis hat.
    3. Anschließend führen wir im Roundcube Root Verzeichnis sudo -u <Verzeichnisinhaber> /opt/php-8.4/bin/php --define apc.enable_cli=1 composer.phar install
      Hinweis: Dadurch werden die Plugins in meiner hinterlegten Roundcube Config aktiv: acl, emoticons, newmail_notifier, password, userinfo, redundant_attachments, zipdownload, markasjunk, managesieve, account_details, libkolab, libcalendaring, calendar, tls_icon, show_folder_size
    4. ggf. kann man noch nen Update hinterher hauen sudo -u <Verzeichnisinhaber> /opt/php-8.4/bin/php --define apc.enable_cli=1 composer.phar update
    5. Bei fragen, meldet euch gerne dazu bei mir...

  • GitHub

    Mag sein dass das Team von Liveconfig klein ist. Aber dann sollte auch mal offen gesprochen werden!
    Themen zu Ignorieren seitens Liveconfig ist nicht die Lösung des Problems.

    Es kann ja gesagt werden: "Die und die Funktion wird nicht umgesetzt!"

    Dann kann man sich wenigstens darauf einstellen dass da nichts kommt. Ich bin auch bereit 20 oder 30€ Mon für Liveconfig zu bezahlen, wenn die gewünschten Funktionen von den es in dem Liveconfig Forum massenhaft gibt, auch umgesetzt werden.


    Dieses Thema beispielweise: Github, in 2018 angefragt, in 2019 noch mal kurz darauf eingegangen, dann nichts mehr...

    Viele Funktionen die andere Systeme schon Ewigkeiten haben, fallen hier aus der reihe.

  • GitHub

    +1

    Der Wandel geht immer mehr zu Laravel Entwicklungen mit Deploy zu GitHub/GitLab.
    Eine GIT und Laravel Integration wird immer wichtiger!

  • [Lösung] ProFTPD TLS funktioniert nach Debian 12 → 13 Upgrade nicht (AUTH not understood)

    Mir ist nach dem Upgrade von Debian 12 auf Debian 13 aufgefallen, dass keine TLS-Verbindung mehr möglich war. Ursache war ein fehlendes TLS-Modul.

    Falls jemand das gleiche Problem hat, hier die Lösung.


    Fehlermeldung (z. B. in WinSCP)

    Code
    proftpd AUTH not understood

    Ursache

    Das TLS-Modul mod_tls war nach dem Upgrade nicht mehr installiert bzw. geladen.

    Lösung

    Zuerst das fehlende Modul nachinstallieren:

    Code
    apt install proftpd-mod-crypto

    Danach in der Datei:

    Code
    /etc/proftpd/modules.conf

    die Raute (#) vor folgender Zeile entfernen:

    Code
    LoadModule mod_tls.c

    Anschließend die Konfiguration neu laden (z. B. über LiveConfig) – danach funktionieren TLS-Verbindungen wieder.


    Optional: TLS standardmäßig erzwingen

    Wer TLS verpflichtend nutzen möchte, kann zusätzlich in folgender Datei:

    Code
    /etc/proftpd/tls.conf

    die Raute (#) vor dieser Zeile entfernen:

    Code
    TLSRequired on

    Danach ebenfalls die Konfiguration neu schreiben oder den Dienst neu starten:

    Code
    systemctl restart proftpd

    (alternativ: service proftpd restart)

  • Erfahrung: Upgrade auf Debian 13 – Autoremove macht Party

    Hallo zusammen,

    ich wollte mal meine jüngste Erfahrung beim Upgrade von LC2 auf Debian 13 teilen – vielleicht hilft es ja dem ein oder anderen, der sich auch gerade auf den Sprung wagt.

    Also: Upgrade wie immer durchgeführt, brav die Anleitung von Liveconfig befolgt – alles schien sauber zu laufen.

    Dann kam der große Schock: apt autoremove hat beschlossen, mir einfach mal ein paar essentielle Pakete zu deinstallieren. Ja, richtig gelesen. Essenzielle Pakete wie:

    • apache2

    • nginx

    • opendkim

    • bind9

    • proftpd

    • clamav

    Keine Ahnung, warum. Vielleicht ein „Feature“ von Debian 13, vielleicht ein kleiner Spaß der Paketverwaltung. Hätte ich Prüfen müssen was er deinstalliert: Klar, aber ich hab mich auf die anleitung verlassen!


    Fakt ist: Mein Server fühlte sich plötzlich ziemlich nackig an.

    Danach musste ich einiges manuell nachinstallieren und hoffen, dass alles wieder stabil läuft.

    Besonders spannend bleibt: Ich hoffe inständig, dass Liveconfig seine child Prozesse nicht im Laufe des Tages die Biege macht – die Nerven liegen noch blank.

    Fazit bisher: Upgrade technisch machbar, aber autoremove kann dir mitten in der Nacht eine echte Überraschung liefern. Also Augen auf und Backup bereithalten, Leute!

    Hat jemand ähnliche Erfahrungen gemacht oder Tipps, wie man das beim nächsten Upgrade sauberer umgeht?

    Traue ich mich das Upgrade auf LC3? Im Leben erst mal nicht, ich werde wohl noch bis ende des Jahres warten und den Support für LC2 so lange wir möglich mitzunehmen.

    Ohne witz, Ich tendiere mittlerweile echt zu der Etwas teureren Hosting variante dessen name nicht genannt werden darf... Liveconfig fühlt sich Unstabil und sensibel an... oder täuscht das?

    Mehr wollte ich nicht, nur nen erfahrungsbericht meiner seits.