Also ich kenne Plesk nicht nie genutzt und ich habe mich bewusst für LC entschieden.
Entschuldigung, das ging auch weltmeister.
Beiträge von WebService4U
-
-
Ich finde das auch sinnvoll, allerdings finde ich deses ständige "In Plesk gibt es diese Funktionen schon lange" hier ein wenig daneben. Mir wäre neu, dass Plesk die Normierungsstelle für Webserververwaltungssoftware ist und dies hier ist ein LC-Forum. Man ist fast geneigt zu fragen: warum nimmst Du dann nicht Plesk?
-
Hmmm, da gibt es Für und Wider. Natürlich hält man sich damit als Provider Ärger vom Hals, weil, der Kunde hat es ja selbst aktiviert oder deaktiviert. Zielführend ist das aber eigentlich auch nicht wirklich.
In der Regel gibt es ja einen NDR für den Absender in diesem Fall. Und ganz neben bei: Kunden, die deswegen ausflippen, würde ich freundlich aber bestimt Lebewohl sagen. Aber das nur am Rande.
-
Danke für die Rückmeldung. Die Daten sind raus, Ticketnummer LC#2017121434000017.
-
Deaktiviert man PHP für einen Vertrag, so werden PHP-Scripte dennoch ausgeführt, und zwar mit der PHP-Standardversion des Betriebssystems, egal welche PHP-Version der Kunde unter Hosting->Domains an der Domain gesetzt hat.
Es sollte ausserdem auch nicht möglich sein, im Kundendialog eine PHP-Version einzustellen, wenn PHP für einen Vertrag vertragsseitig durch den Verkäufer deaktivert wurde.
LiveConfig 2.5.2-r4777
-
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_hostnamewas 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_hostnameAlle 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.
