Wir verbieten inzwischen per robots.txt einige Bots und überlegen, mittelfristig direkt in LiveConfig per Button entsprechende Filter zu aktivieren.
Eine sehr gute Idee!!
Wir verbieten inzwischen per robots.txt einige Bots und überlegen, mittelfristig direkt in LiveConfig per Button entsprechende Filter zu aktivieren.
Eine sehr gute Idee!!
aziegler Danke für die Belehrung und die nicht hilfreiche Antwort. Vielleicht mal gründlich nachdenken, ob ich einen ANDEREN Grund hatte, das genau hier zu posten. Du kommst bestimmt drauf..
kk Danke für die Rückmeldung. Wenn diese Info im richtigen Thread schon vor Tagen gekommen wäre, dann hätte ich nicht "hijacken" müssen. Gut zu wissen, dass es doch nicht untergegangen ist.
ap24 Gutes Workaround für diesen speziellen Fall. Funktioniert. Danke dafür!!
Sorry für das Hijacking, aber wie sieht es denn nun mit dem Fehler bei phpMyAdmin und dem Anwendungsinstaller aus? Wenigstens eine Rückmeldung von Euch wäre da mal nett.
Frage an die Kollegen mit Debian > 7: Gib es da auch den phpMyAdmin-Fehler?
Der Fehler ist bereits hier
https://www.liveconfig.com/de/…ds/2658-APP-Problem/page2
beschrieben, es gibt noch keine Rückmeldung dazu.
Den phpmyadmin-Fehler kann ich auf Debian 7.11 mit aktuellem LC Stable bestätigen.
Kann bestätigen, dass es wieder läuft. Danke Herr Keppler.
Status: Fehler: while connecting to database: Access denied for user 'geändert'@'localhost' (using password: YES)
Hier dasselbe.
In der o.g. Liste sehe ich übrigens mindestens vier Module, die in Shared-Hosting-Umgebungen definitiv nichts verloren haben.
Ich lerne gern dazu - das wären?
aziegler: ... Wir sind sicher nicht "Per DU" - das wüsste ich.
...
Nun halten SIE mal bitte wirklich die Luft an. "DU" ist in Foren ja wohl total üblich. Man versucht IHNEN hier zu helfen, da empfinde ich IHRE Belehrungen wirklich leicht deplaziert. Mann, mann, mann ...
Gerne! Schönes Wochenende.
Richte einen Webhostingvertrag mit einer (Sub)Domain ein, unter der LiveConfig erreichbar sein soll. Installiere dafür ein LE-Zertifikat. Die (Sub)Domain dann in den Domaineinstellungen unter Weiterleitung als Proxy aus https://localhost:8443/* bedienen.
reject_rbl_client xxx,
reject_rbl_client xxy,
reject_rbl_client xxz,
xxx, xxy und xxz kann man in der LC-Oberfläche bei der Mailserverkonfiguration eintragen, Registerkarte Viren/Spam, dort DNS-Blacklists.
Danke Ralf, aber wenn ich nur den fehlenden Parameter in der custom.lua aufnehme, also:
postfix.LOCALCONFIG = {
['smtpd_client_restrictions'] = "reject_unknown_client_hostname"
}
Dann wird in der main.cf der gesamte Bereich
smtpd_client_restrictions =
permit_mynetworks,
permit_sasl_authenticated,
reject_invalid_hostname,
reject_unknown_reverse_client_hostname,
reject_rbl_client xxx,
erstetzt durch:
smtpd_client_restrictions =
reject_unknown_client_hostname
was ja nicht Sinn der Sache ist. Natürlich kann ich auch die
permit_mynetworks,
permit_sasl_authenticated,
reject_invalid_hostname,
reject_unknown_reverse_client_hostname,
reject_rbl_client xxx,
mit in die custom.lua aufnehmen, aber das ist nicht optimal, da dann bestimmte Einstellungen, die ich in Liveconfig direkt an der Postfixkonfiguration vorgenommen habe, nicht greifen.
Gibt es keine andere Lösung?
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.
Ja, Anton, genau so war es. Heute morgen flogen die neuen Zertifikate auf allen Servern ein, wie ich jetzt im log sehen konnte.
Danke für Eure Hilfe.
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.
Autsch. An Antons Stelle wäre ich jetzt sauer.
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.