Beiträge von WebService4U

    Hallo,


    aktuell habe ich - durch LC automatisch angelegt in der main.cf:


    smtpd_client_restrictions =
    permit_mynetworks,
    permit_sasl_authenticated,
    reject_invalid_hostname,
    reject_unknown_reverse_client_hostname,
    reject_rbl_client xxx,


    Nun möchte ich alternativ statt reject_unknown_reverse_client_hostname den Parameter reject_unknown_client_hostname setzen, da dieser Parameter restriktiver ist.


    Nehme ich nun in der custom.lua auf:


    postfix.LOCALCONFIG = {
    ['smtpd_client_restrictions'] = "reject_unknown_client_hostname"
    }


    Dann erhalte ich schließlich nach der aktualisierung der Konfiguration in der main.cf


    smtpd_client_restrictions =
    reject_unknown_client_hostname


    Alle anderen Parameter für smtpd_client_restrictions sind dann raus.


    Mir ist klar, dass ich natürlich alle Parameter in die custom.lua aufnehmen kann, um das gewünschte Resultat zu erreichen, mit der Folge, dass dann die entsprechenden Einstellungen im Admin-Bereich von LC (Mailserverkonfiguration, z.B. Blacklists) wirkungslos werden.


    Daher meine Frage: gibt es eine Möglichkeit reject_unknown_reverse_client_hostname durch reject_unknown_client_hostname mittels custom.lua zu ERSETZEN, ohne die anderen Parameter mit aufzunehmen oder bleibt mir dann nur, das direkt in der /usr/lib/liveconfig/lua/postfix.lua zu ändern und die Änderung nach jedem LC-Update wieder einzupflegen.

    Danke für den Tipp, ich bin von 20 Minuten auch genau darüber gestolpert:
    Reason: DNS lookup failure for: "localhost:8443liveconfig"


    Die Lösung: Die Umleitung muss auf localhost:8443/* erfolgen.


    Komisch dabei ist nur, dass das seit einem halben Jahr mit localhost:8443 ohne /* funktionierte und seit heute Morgen nicht mehr. Irgendwas muss heute Nacht passiert sein....


    Danke für die Hilfe!

    Hallo,


    LiveConfig-Version: 2.4.1 (r4635) (aktuell)
    Neueste Version: 2.4.1-r4635
    letzte Prüfung: 15.09.2017 09:57:59 CEST
    Plattform: x86_64-unknown-linux-gnu
    Konfigurationsdatei: /etc/liveconfig/liveconfig.conf
    Datenbank: 5.5.57-0+deb7u1 (stmt_open=0, stmt_cached=45)


    Der Zugriff auf die Liveconfig-Oberflächer erfolgt bei mir über eine SubDomain, z.B. https://liveconfig.webclient9.de. Für diese Domain ist dann unter Liveconfig>hostin->Domains als Weiterleitung proxy auf https://localhost:8443 eingerichtet.


    Dies funktionierte bis heute einwandfrei. Seit heute - ohne jegliche Änderung auf dem Server - erhalte ich beim Aufruf von https://liveconfig.webclient9.de den 502er:


    Proxy Error


    The proxy server received an invalid response from an upstream server.
    The proxy server could not handle the request GET /liveconfig/admin/overview.


    Reason: DNS lookup failure for: localhost:8443liveconfig


    Apache Server at liveconfig.webclient9.de Port 443


    Während ich mit der Fehlersuche beschäftigt war, haben sich noch weitere Server auf diese Weise verabschiedet, wie mir Kunden mitteilten.


    Ich bin gerade etwas ratlos. Rufe ich Liveconfig direkt ohne Proxy auf, also https://liveconfig.webclient9.de:8443, klappt der Aufruf.

    Wenn der Mailspace im Vertrag auf unbegrenzt steht, dann kann doch der Kunde auch sein Quota auf das Postfach unbegrenzt erhöhen. Damit ist doch dein Fall abgedeckt - jedoch nur mit der Einschränkung, dass der Kunde eben ab und zu die Auslastung seines Postfaches prüfen muss und das Quota ggf. nach oben anpassen muss. Ich kann da ManDal sonst nur zustimmern.

    Ja, da fehlt wohl ein Wort... sollte heißen: Kann ich (leider) NICHT bestätigen, läuft einwandfrei. Leider, weil es für den TO keine wirkliche hilfe ist, ausser eben der impliziten Aussage, dass es wohl nicht am LC-Update liegt.

    Wenn man eine Domain in einem Vertrag deaktiviert, dann läßt sich die Domain noch einmal im Vertrag erstellen und ist dann doppelt - einmal aktiviert und einmal deaktiviert im Vertrag. Die Domain läßt sich aber dann nicht erreichen, es erscheint die Fehlerseite für nicht am Server konfigurierte Domains.


    LC 2.2.3 4343 auf Debian wheezy

    Ich vermute, es handelt sich um Datenbanken, die von Confixx migriert wurden. Dann haben alle Datenbanken denselben Datenbankbenutzer - das war bei Confixx so und deshalb führt die Kennwortänderung bei einer Datenbank natürlich zu dem Problem, da das Kennwort nicht an die Datenbank sondern an den Benutzer gekoppelt ist. Da hilft nur: alle Datenbanken mit LC neu erstellen, dann hat jede Datenbank einen eigenen Datenbankbenutzer und die Daten überspielen.

    Schau mal bei Einstellungen->Wiederverkäufer. Da kannst Du Präfixe für die Datenbanken usw. Deiner Kunden festlegen, auch mit Vertragsnummer, z.B. %c: "Dieses (optionale) Präfix wird bei neuen Datenbanken automatisch dem Datenbank- und dem Benutzernamen vorangestellt. Der Platzhalter %c wird dabei automatisch durch den jeweiligen Vertragsnamen (z.B. web1) ersetzt." Das dürfte Dein Problem lösen.

    Ich hatte da mal was für Confixx zusammengefricket als php-Script, welches dann vom Cron aufgerufen wurde, vielleicht kannst Du das auf die LC-Datenbank anpassen:


    #!/usr/bin/php
    <?php


    //Ein paar Variablen vorbelegen
    $db_server = "localhost"; // Datenbankserver: localhost
    $db_user = "DBUSER"; // Datenbankbenutzername
    $db_pass = "PASSWORT"; // Passwort für Datenbankbenutzername
    $db_name = "confixx"; // Datenbank "confixx"
    $server = "SERVERNAME"; // sprechender Name des Servers
    $absend = "bitte-nicht-antworten@".$server; // E-Mail-Absenderadresse
    $absendername = "Confixx auf ".$server; // E-Mail-Absendername
    $cc = "technik@xyz.de"; // CC-Empfängeradresse


    //Verbindung initialisieren
    @$db = new mysqli("$db_server", "$db_user", "$db_pass", "$db_name");


    /* Es wird die Query erzeugt mit den Daten aus der Tabelle "pop3" in der Datenbank "confixx" */
    if ($resultat = $db->query('SELECT pop3.*, kunden.emailadresse FROM pop3 INNER JOIN kunden ON pop3.kunde = kunden.kunde;')) {

    /* Das Ergbnis wird solange ausgegeben, bis keine Daten mehr vorhanden sind */
    while($daten = $resultat->fetch_object() ){

    /* Vergleich zwischen aktueller Postfach-Auslastung und Soft-Quota */
    if (($daten->diskusage > $daten->maxkb) AND ($daten->anbieter == 'res0')){


    /* Wenn die aktuelle Postfachauslastung größer als Soft-Quota, dann wird eine E-Mail versendet "*/
    $diskusage = round($daten->diskusage/1024,2);
    $account = $daten->account;
    $hardquota = round($daten->maxkbhard/1024,2);
    $softquota = round($daten->maxkb/1024,2);


    $empfaenger = $daten->emailadresse;
    $absendermail = $absend;
    $betreff = "Ihr Postfach ".$account." auf Server ".$server." ist voll!";
    $text = "Guten Tag,\n
    Ihr Postfach ".$account. " hat eine Auslastung von ".$diskusage." MB bei einer Größe von ".$hardquota." MB.
    Sie erhalten diese Email ab einer Auslastung von ".$softquota." MB - dies entspricht Ihrer Softquota-Einstellung des Postfaches ".$account. "
    unter Confixx->E-Mail->Mailquota.


    Bitte erhöhen Sie die Postfachgröße in Confixx->E-Mail->Mailquota oder löschen Sie nicht mehr benötigte E-Mails.


    Beachten Sie bitte beim Löschen von Emails, dass Sie diese ggf. auch aus dem Papierkorb löschen müssen.


    Die Anzeige der Postfachauslastung im Confixx ist keine Echtzeitanzeige. Sie wird täglich 1x in der Nacht
    aktualisiert.


    Dies ist eine automatische Email. Bitte antworten Sie NICHT direkt auf diese Email, da die Antwort NICHT
    gelesen werden kann. Bei Fragen oder Problemen eröffnen Sie bitte ein Support-Ticket im Kundencenter.


    Internette Grüße
    ".$absendername;


    // echo $empfaenger." ".$betreff." ".$text." From: ".$absendername." <".$absendermail.">
    //";


    mail($empfaenger, $betreff, $text, "From: $absendername <$absendermail>");
    mail($cc, $betreff, $text, "From: $absendername <$absendermail>");
    }


    }


    }
    ?>

    Ja, natürlich ist das möglich. Z.B. mit einem Cronjob, der die entsprechenden Angaben täglich aus der LC-Datenbank ausliest und dann bei Überschreitung die Mail versendet. LC kann das m.E. leider noch nicht allein. Aber da gibt es auch wichtigere Baustellen.