Beiträge von Mathias_Thielen

  • [Fix] Liveconfig/SRS: Temporary lookup failure

    Ich habe gerade in Liveconfig 2.18.3 das Paket lc-postsrsd installiert und anschließend in der GUI unter

    Serververwaltung -> E-Mail -> Viren/Spam -> SRS aktiviert.


    Anschließend bekomme ich die Fehlermeldung im Client: "...Temporary lookup failure...". Niemand kann mehr E-Mail versenden.


    Logs


    Das sind die Log-Einträge in /var/log/mail.log:


    Code
    Aug 22 12:32:11 webhost01 postfix/smtpd[1659811]: warning: connect to srs: No such file or directory
Aug 22 12:32:11 webhost01 postfix/smtpd[1659811]: warning: table socketmap:unix:srs:reverse lookup error: No such file or directory
Aug 22 12:32:11 webhost01 postfix/smtpd[1659811]: warning: socketmap:unix:srs:reverse lookup error for "user@domain.tld"
Aug 22 12:32:11 webhost01 postfix/smtpd[1659811]: NOQUEUE: reject: RCPT from server.domain.tld[1.2.3.4]: 451 4.3.0 <user@domain.tld>: Temporary lookup failure; from=<otheruser@otherdomain.tld> to=<user@domain.tld> proto=ESMTP helo=<server.domain.tld>


    Ursache


    Herr Keppler wusste die Lösung sofort. Es war ein AppArmor-Profil, was von einer vormaligen postsrsd Version 1 noch im System war.

    Lösung (für Debian/Ubuntu)

    1. Prüfen ob Reste von postsrsd 1.x noch installiert sind

    Code
    dpkg -l |grep postsrs


    Hier sollte nur lc-postsrsd Version 2.x zu sehen sein. Wenn postsrsd Version 1.x vorhanden ist, dann ist das sehr wahrscheinlich der hier beschriebene Fehler.


    2. Prüfen ob der postsrsd korrekt gestartet ist

    Code
    systemctl status postsrsd
...
journalctl -u postsrsd --no-pager --lines=1000

...
Aug 22 12:10:50 webhost01 systemd[1]: Started Sender Rewriting Scheme daemon for Postfix.
Aug 22 12:10:50 webhost01 postsrsd[1629433]: postsrsd: error: cannot read '/etc/postsrsd/postsrsd.conf': Permission denied
Aug 22 12:10:50 webhost01 systemd[1]: postsrsd.service: Main process exited, code=exited, status=1/FAILURE
Aug 22 12:10:50 webhost01 systemd[1]: postsrsd.service: Failed with result 'exit-code



    Hier sieht man dass postsrsd nicht starten konnte, weil er keine Berechtigungen auf die Konfigurationsdatei hat, obwohl die Berechtigung im Dateisystem vollkommen korrekt ist.

    Code
    ls -ltra /etc/postsrsd

insgesamt 28
-rw-r--r--   1 root root    25 26. Feb 19:15 postsrsd.secret
-rw-r--r--   1 root root  7095 22. Aug 12:11 postsrsd.conf
drwxr-xr-x   2 root root  4096 22. Aug 12:44 .
drwxr-xr-x 169 root root 12288 22. Aug 13:07 ..


    3. Entfernen der Reste des postsrsd Paketes

    Code
    apt purge postsrsd



    4. Alle AppArmor-Profile entladen und neu laden


    Code
    aa teardown
systemctl restart apparmor

    5. postsrsd neu starten und prüfen


    Jetzt noch den postsrsd neu starten und prüfen ob er läuft:


  • Feature Request: POP3/IMAP Sammeldienst

    Das Roundcube-Fetchmail-Plugin scheint zu funktionieren, wie es soll.


    Der Abruf ist bei einem Testkonto bei mir erfolgreich. Bisher keine Auffälligkeiten. Ich habe dazu eine separate Datenbank angelegt. Aber eigentlich ist das problemlos auch auf der Haupt-Roundcube-DB. Es ist nur eine Tabelle, die für fetchmail angelegt wird. Der Name der Tabelle ist "fetchmail".


    Was noch fehlt ist eine Fehlerbehandlung. D. h. wenn der Abruf aus irgend einem Grund nicht erfolgreich ist, sollte das der Benutzer sehen können. Das wäre dann entweder selbst zu programmieren oder zu beauftragen.

  • Feature Request: POP3/IMAP Sammeldienst

    Zitat von Systemhaus-EHST

    einfach alle E-Mails in ein IMAP oder POP Postfach leiten.


    Es gibt beide Anwendungsfälle. Manche möchten das getrennt. Die bekommen das üblicherweise selbst eingerichtet. Die anderen möchtens möglichst einfach haben. Für die konfiguriert das dann idR der IT-Dienstleister und die haben überall Zugriff auf alle Mails.


    Zitat

    Oder ein Postfach mit mehreren ALIAS Adressen sofern es die selbe Domain ist.


    Ist es üblicherweise nicht.


    Zitat

    Gehört IMHO eher Richtung Webmailer, beispielsweise bei RoundCube


    Das ist nicht gut. Das setzt vermutlich zwingend die dauerhafte Nutzung von RoundCube voraus. Das passiert so aber nicht. Die Leute nutzen Ihr Smartphone und die native MailApp.


    Aber vielleicht könnte man das Plugin nutzen um einen eigenen Poller zu bauen und zu füttern, der die Mails dann als Dienst im Hintergrund periodisch abruft.

  • Feature Request: POP3/IMAP Sammeldienst

    Der Anwendungsfall:


    • Kund:in hat mehrere persönliche E-Mailadressen
    • Kund:in möchte alle E-Mailadressen unter einer Oberfläche haben.
    • E-Mailweiterleitung macht aufgrund von SPF u. a. viele Probleme


    Deswegen ein E-Mailsammeldienst für mehrere externe Konten, die an ein lokales Konto weitergeleitet werden.


    Um es den Benutzer:innen einfacher zu machen, kann man hier ja auch auf E-Mail-Autokonfiguration zurückgreifen und die korrekten Werte vorschlagen.


    T-Online hat hier z. B. die Möglichkeit einen Sammeldienst zu konfigurieren. Natürlich nicht flexibel für beliebige Anbieter, sondern nur auswählbar für die großen. Es wäre schön, eine Alternative in LiveConfig dafür zu haben.

  • Verbesserungsvorschlag: LetsEncrypt Zertifikate jetzt erneut registrieren!

    Hallo,


    was mich regelmässig nervt, ist, wenn ich ein LetsEncrypt-Zertifikat registrieren will, ist, dass ich irgend etwas vergesse - z. B. entsprechende DNS-Records vor der Registrierung anzulegen und dann steht das LetsEncrypt-Zertifikat erst einmal im Fehlermodus und ich muss lange warten, bis die Registrierung erneut versucht wird.


    Workaround, das doch machen zu können, ist das Zertifikat zu löschen und neu anzulegen. Das ist aber vergleichsweise viel Aufwand.


    Ich möchte aber nicht warten, sondern ich möchte es bei Bedarf gleich haben. D. h. ich hätte gerne im Zertifikatsfenster gerne einen Button: "Registrierungsversuch jetzt wiederholen" oder so ähnlich.


    Mir ist schon klar, dass man da recht schnell in die LE-RateLimits reinlaufen kann. Aber das weiss ich ja. Man könnte die Option ja in einem weiteren Unterfenster platzieren, so dass das nicht so prominent ist und durch alle Menschen, denen das nicht klar ist, wieder Supportaufwand auslöst.


    Alternative wäre für mich ein CLI-Befehl [B]le re-register, der genau das macht.[/B]


    Ansonsten habe ich mich mir die DB nur obeflächlich angeschaut und nicht gesehen, wie ich das vielleicht jetzt schon selbst auslösen kann.


    Hilfreich wäre auch: Den Trigger zu kennen, um selbst irgendwie den Re-Register auslösen zu können. Da muss ich aber wahrscheinlich in der SQLite-DB Änderungen vornehmen, was vermutlich aufgrund der Single-User-Architektur grundsätzlich problematisch ist, dieses öffentlich bekannt zu geben.

  • LC + Ugrade von Ubuntu: 16.04(Xenial) -> 20.04(Focal): FTP-Login schlägt fehl

    Zitat von kk

    Wir planen nun, LC.crypt.crypt() auf die POSIX-Variante umzustellen, müssen aber prüfen dass das bei alten Systemen keine Probleme macht. Parallel prüfen wir, ob sich die alten Hashes übergangsweise weiter nutzen lassen - alternativ werden dokumentieren wir man auslesen kann, welche Accounts betroffen sind.


    Gibt es dazu schon ein Update? Aktuell kann ich ja keine Updates sauber einspielen ohne dass die Problematik wieder auftritt, weil die vsftpd.lua natürlich durch neue Pakete überschrieben wird. Ist mir ansonsten natürlich klar, dass sie aktuell mit LC3 stark beschäftigt sind.

  • LC + Ugrade von Ubuntu: 16.04(Xenial) -> 20.04(Focal): FTP-Login schlägt fehl

    Ein Debian 11 Server ist auch betroffen. (Wurde seit Debian 8 immer mit dist-upgrade aktualisiert).


    Hier ist das liveconfig --diag von diesem:


  • LC + Ugrade von Ubuntu: 16.04(Xenial) -> 20.04(Focal): FTP-Login schlägt fehl

    Ich habe mal das debugging vom pam_userdb Plugin eingeschaltet. Dann bekomme ich im auth.log:


    Code
    Jan 11 14:10:34 primary vsftpd: pam_userdb(vsftpd-lc:auth): Verify user `validuser' with a password
Jan 11 14:10:34 primary vsftpd: pam_userdb(vsftpd-lc:auth): password in database is [0x123450033ba0]`abcdegIDyopY', len is 13
Jan 11 14:10:34 primary vsftpd: pam_userdb(vsftpd-lc:auth): lengths of computed and stored hashes differ
Jan 11 14:10:34 primary vsftpd: pam_userdb(vsftpd-lc:auth): user `validuser' denied access (incorrect password)
Jan 11 14:10:34 primary vsftpd: pam_unix(vsftpd-lc:auth): check pass; user unknown
Jan 11 14:10:34 primary vsftpd: pam_unix(vsftpd-lc:auth): authentication failure; logname= uid=0 euid=0 tty=ftp ruser=validuser rhost=1.2.3.4

  • LC + Ugrade von Ubuntu: 16.04(Xenial) -> 20.04(Focal): FTP-Login schlägt fehl

    Hallo,


    ich habe ein Upgrade von Ubuntu 16.04 auf 18.04 auf 20.04 durchgeführt. Als FTP-Server ist vsftpd installiert.


    Nach dem Upgrade funktioniert der FTP login nicht mehr(Support-Ticket ist bereits auch erstellt). Mehrfache Neuanlage von Benutzern hat nichts gebracht. Der primäre FTP-Account von Liveconfig funktioniert. Alle zusätzlichen FTP-Accounts erhalten beim Login die Fehlermeldung ...


    ...am Client:


    Code
    Ablehnung des Logins mit "530 Login incorrect."


    ...am Server in der vsftpd.log:


    Code
    [username] FAIL LOGIN: Client "13....174"


    Hier nochmal die Ausgabe von liveconfig --diag


  • Massenänderung PHP-Version

    Noch ein kleiner Einzeiler, der eine Liste der Hostingverträge, konfigurierten Subdomains und konfigurierter PHP-Version ausgibt:


  • [ERR] selected PHP default version 'nil' not found! Using 'nil'...

    Hallo,


    ich habe ein Liveconfig-System ohne PHP. Wenn ich jetzt seit neuestem eine Änderung durchführe bekam ich diese Fehlermeldung im liveconfig.log:


    Code
    [2021/03/03 14:45:20.837576] [23700|23702] [LUA] LC.mutex: forcing unlock of mutex 'web.configure'
[2021/03/03 14:45:20.838664] [23700|23702] LC.web.configureVHost(KMKG)) failed: /usr/lib/liveconfig/lua/apache.lua:1846: bad argument #3 to 'gsub' (string/function/table expected)
stack traceback:
        [C]: in function 'gsub'
        /usr/lib/liveconfig/lua/apache.lua:1846: in function 'writeVHostDocRoot'
        /usr/lib/liveconfig/lua/apache.lua:2466: in function 'buildConfig'
        /usr/lib/liveconfig/lua/apache.lua:2799: in function 'configureVHost'
        /usr/lib/liveconfig/lua/web.lua:1329: in function </usr/lib/liveconfig/lua/web.lua:1102>


    liveconfig --diag liefert mir u. a. das:


    Code
    [ERR] selected PHP default version 'nil' not found! Using 'nil'...


    Nach kurzem googeln habe ich als Lösung hier gefunden, dass php-cgi installiert werden muss, was das Problem gelöst hat.


    Muss ich wirklich PHP installieren, obwohl ich es nicht nutze, oder kann man den Fehler in LC vielleicht abfangen?

  • LiveConfig: Basic Version attraktiver für Privatpersonen gestalten!

    Hallo,


    ich finde LiveConfig wirklich gut. Ich würde es wirklich gerne auch jedem empfehlen, der ankommt und mir sagt, dass er mit Plesk liebäugelt.


    Plesk ist halt wirklich deutlich günstiger. Wenn ich sehe, dass bei Ionos das Plesk für den VServer schon für 1 EUR zu haben ist.


    Grundsätzlich finde ich die 2,80 EUR für die Basic Edition schon ok. Dass da allerdings kein Let's Encrypt dabei ist, ist dann schon das Ausschlußkriterium.


    Ich kann den Wunsch danach, für seine Arbeit auch bezahlt zu werden durchaus nachvollziehen. :D


    Für eine generelle Preisreduktion bin ich da jetzt also eher nicht. Ich wünsche mir, dass LC auch für Privatpersonen eine brauchbare und günstige Option bietet. Vielleicht mit Nutzungs-Einschränkungen, die wirklich für den Privat-nutzer mit ~10/~20 Domains nicht ins Gewicht fallen.


    Ich würde sagen, dass das im Moment ohnehin ein Kundensegment ist, was für LC einfach wegfällt, weil zu teuer.


    Natürlich muss man sich dann vor Supportanfragen schützen. Für so einen Minimalpreis kann man wohl realistisch keinen Support bieten außer das Forum.


    Viele Grüße,
    Mathias