Beiträge von Mathias_Thielen

    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.

    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.

    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.

    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.

    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.

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


    Hier ist das liveconfig --diag von diesem:


    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

    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


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


    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?

    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

    Hallo zusammen,


    ich habe folgenden seltsamen Fehler bei der Registrierung einer Lets Encrypt Domain. Fehler in der Oberfläche:


    Code
    [04.09.2020 04:59:04] ACME2: sub.domain.top DNS check failed: DNS lookup failed (A): Lookup of 'sub.domain.top' failed: timeout


    System: Debian 10
    LiveConfig 2.9.3-release


    Der entsprechende A-Record wird von beiden DNS-Servern der Domain zurückgegeben und stimmt mit der dem Webserver zugewiesenen Adresse überein. Als Resolver im System sind 2 IPs konfiguriert, die beide korrekt antworten.


    Vor kurzem wurde der 2. DNS-Server der Domain(welcher auch gleichzeitig 2. Resolver war) ersetzt durch einen Server mit anderer IP. Die IP-Adresse des alten DNS-Servers wurde komplett aus dem System und aus den Zonendaten durch die neue Resolver-IP ersetzt.


    Wenn ich jetzt beim anlegen des LetsEncrypt Zertifikates tcpdump auf der Konsole mitlaufen lasse, dann sehe ich, dass die DNS-Anfrage der Domain an die IP-Adresse des alten Resolvers geht, welche natürlich in einen timeout läuft.


    Der Server wurde mehrfach neu gestartet.


    Wie kommt Liveconfig an diese alte Resolver-Adresse?