Beiträge von ateo

Im Grunde ist die Definition Serverseitig eine sinnvolle Sache. Dennoch ist es praktisch, die PHP-Mails konkreter zu definieren. Via http://php.net/manual/de/function.mail.php ist es angerissen und mit "$headers.="Return-Path:<name@example.com>\r\n";" erhält man auch einen wünschenswerten Eintrag für Rückläufer. Bei PHP im SafeMode erhielt man damals immer die Meldung, dass der 5. Parameter im Mail-Befehl nicht unterstützt werden würde. Bei Confixx wurde hilfsweise eine .forward im HomeDir des Kunden mit der E-Mail-Adresse gefüllt, die im Kundendatensatz eingetragen wurde.

Abgesehen von dieser Möglichkeit im Script kann sie natürlich auch mit E-Mail-Adressen angewendet werden, die auf dem betreffenden Server nicht gepflegt werden. Dann landen solche Mails bestimmt öfter im Spam-Ordner der Ziele.

Whitelist und Blacklist wegen Spam bzw. false positiv/negativ gab es bereits sehr hilfreich bei Confixx. Da muss man nicht erst Plesk bewundern. Unterm Strich ist deren Potential aber eh in einem Topf mit Edelstahl-Quirl gelandet. LC muss sich "eigentlich" nur eine validierende Oberfläche einfallen lassen, mit der man die Regeln zum (nicht) filtern füttern kann. Auch bei uns ist das ganz oben auf der Wunschliste der E-Mail-Nutzer mit Weblogin!

Auf der Maschine ist zwischenzeitlich stretch. Das Repo hatte ich vergessen anzupassen. Nun so wie hier:

# Debian/Ubuntu Repository:
deb http://repo.liveconfig.com/debian/ main main
deb http://repo.liveconfig.com/debian/ stretch php

# Debian/Ubuntu TEST Repository:
deb http://repo.liveconfig.com/debian-test/ main main

Aber dennoch bekomme ich für PHP 7.0 nun "Neue Version 7.0.23-1+xenial1" aus Main angeboten.

Xenial von Ubuntu oder Jessie?
UNSTIMMIGKEITEN beim Paket-Update:

Pakete php-7.0-opt
Beschreibung amd64 Optional PHP 7.0.23 package, installed at /opt/php-7.0
Neue Version 7.0.23-1+xenial1
Quelle Jessie

The following packages have unmet dependencies:
php-7.0-opt : Depends: libicu55 but it is not installable
Depends: libjpeg8 but it is not installable
E: Unable to correct problems, you have held broken packages.

Ich würde mich diesem Spagat nicht mehr hin geben. Die TLS-Verbindung direkt über die Standardports von ProFTP (FTPS) funktionieren seit einiger Zeit recht stabil. Auch mit vielen gleichzeitigen Verbindungen. ABER: Wenn die Firewall nur ein kleines Spektrum für Passiv-Ports öffnet, üblicherweise die gleichen wie in der Config von ProFTP, dann beschränkt man die Verbindungen entsprechend auf diese Anzahl. Damit ProFTP FTPS aktiviert sind einige Einstellungen via liveconfig/servers/manage/details/ftp .

Henne und Ei? Warum wird ZIP angeboten, wenn es die Installation dafür nicht gibt? Da gibt es verschiedene andere nutzbare Funktionen, die nicht eineindeutig zelebriert werden. Eines der Beispiele wäre "Eigene Links" (8.3. IFRAME API) vom Admin zum Reseller verfügbar, vom Reseller zum Endkunden wesentlich wichtiger, aber nicht durchgetrieben. Trotzdem steht zu lesen "Berechtigungen werden automatisch bei der Zuweisung von Verträgen gegeben. Folgende Berechtigungen sind diesem Kunden aktuell zugewiesen: >>> Eigene Links verwalten: NEIN"

Ich habe nginx als Proxy vor Apache aktiviert. Extrem unglücklich finde ich, dass diese Konstellation nur mit dem Wechsel der IP-Adresse nutzbar ist. Noch unglücklicher ist die Meldung

2017/07/19 17:05:21 [error] 12409#0: *3165 no "ssl_certificate" is defined in server listening on SSL port while SSL handshaking, client: IP, server: IP:443

wenn man für die Domain SSL aktiviert. Der virtuelle Host in /etc/nginx/sites-enabled ist korrekt. Dennoch die obige Meldung. Im Netz fand ich den Hinweis, dass /etc/nginx/sites-enabled/default gelöscht werden solle. Hilfsweise habe ich den Eintrag zur IP der Domain ungültig gemacht und nging neu gestartet.

# SSL interfaces and default HTTPS server:
#server {
# listen IP:443 default_server ssl;
# server_name _;
# root /usr/share/liveconfig/html;
# ssi on;
# error_page 403 /not-available-ssl.shtml;
# error_page 404 /not-available-ssl.shtml;
#}

Nur so scheint nginx als Proxy vor Apache auch mit SSL zu funktionieren. Wenn LC das nun auch bei der Anwendung der Einstellungen beachten würde, dann könnte man ohne solche eine "Krücke" umstellen.

Sobald ein Kunde bei seinem Projekt das Logging von PHP aktiviert werden die Meldungen in logs/priv/php_errors.log geschrieben. Vergisst der Kunde das zurückstellen des Loggings, dann füllt es sich über Wochen und Monate. Der Kunde spielt Aktualisierungen seines Systems ein und bekommt den einen oder anderen PHP-Error nicht mit.

- Dieses Logfile bläht sich schleichend oder schnell fortschreitend auf
- Dieses Logfile wird nicht von LC deaktiviert, wie das Apache error.log
- Dieses Logfile wird nicht von LC gepackt/rotiert

>> Der Webspace des Kunden füllt sich übermäßig.
>> Je nach Einstellungen der QUOTA wirkt sich diese Situation auf den Webspace oder Server aus.

Dieser "Schwachstelle" könnte etwas Hilfreiches entgegengesetzt werden.

Dass es so gewollt ist bezweifel ich in keinem Fall. Die Abweichung vom Plan ist meistens eine Ausnahmesituation. Zu genau diesem Fall habe ich eben eine E-Mail mit Foto des Logfiles an support@ geschickt. Die Vermischung der Zeilen aus zwei Verträgen im betreffenden Ziel-Logfile ist zweifelsfrei dokumentiert. Es bleibt die Frage, wie es geschehen konnte.

Wenn man genau weiß, dass ein Suchbegriff (Eigenname) nur zu einer konkreten Webseite gehören kann, dann ist man echt verwundert diesen in einer fremden Webalizer-Statistik zu finden. Der Fund ist rein zufällig. Betreffende Zeilen der fremden Domain aus dem fremden Webspace kann ich in logs/access.log sehen, in dem die Suchbegriffe in der Statistik zu finden sind.

Nach meinen ersten Blicken wird der Traffic aus other_vhosts_access.log ausgelesen und die Zeilen in die Logfiles der Webspaces übertragen via liveconfig/lclogsplit?

Unter welchen Umständen können es unzählige Zeilen in die Logfiles fremder Speicherplätze schaffen?

Tendenziell wollten die Kollegen LC so erweitern, dass Kunden mit individueller IP-Adresse auch am Mailserver mit genau dieser IP erreichbar sind. In diesem Stadium dürfte auch das Zertifikat genau/eindeutig diesem Mail-Host zuordenbar sein.

Für alle Webspace-Kunden, die die Zentrale Server-IP nutzen und auch mit ihren "Post-Subdomains" auf dieser IP auflaufen, würde ich eine Frage in den Raum stellen. Können die PEMs oder TLS-Dateien im Postfix eine Sammlung von Schlüsseln und Zertifikaten bedienen und verkraften? Praktisch habe ich das noch nicht getestet. Auf die Schnelle spricht die Doku http://wiki.dovecot.org/SSL/DovecotConfiguration auch von diesen Varianten. Nur die Mail-Programme http://wiki.dovecot.org/SSL/SNIClientSupport werden nicht alle damit umgehen können.

"Mit eigenen Links können Sie den Funktionsumfang von LiveConfig durch das Hinzufügen von Links zum Navigations-Menü erweitern. Die verknüpften Inhalte werden über ein <IFRAME>-Tag in LiveConfig integriert. Für weitere Informationen zur Umsetzung und zur Authentifizierung nutzen Sie bitte das Referenzhandbuch." >>>

"8.3.1. Einrichtung „eigener Links“
Als Administrator (ab späteren LiveConfig-Versionen auch als Wiederverkäufer) können Sie die „eigenen Links“ direkt über die LiveConfig-Oberfläche unter Verwaltung#LiveConfig
# Eigene Links konfigurieren. Diese Links werden jeweils allen Benutzern auf der selben Verwaltungsebene sowie allen eigenen Kunden (ersten Grades) angezeigt."

Informationen oder Zusatzfunktionen sind am wichtigsten auf der Ebene Reseller gegenüber Endkunden. Wie lange ist diese Ebene schon im Handbuch angekündigt? Die Endkunden sind es, die viele Fragen immer und immer wieder stellen. Effektiv wäre es, diese Ebene für "eigene Links" zügig zu aktivieren.

Passend zur Korrektur von "das Bearbeiten eines FTP-Benutzers erforderte die Eingabe eines neuen Passworts" und "beim Bearbeiten von FTP-Accounts wurde mehrfach ein '/' vor dem Verzeichnisnamen eingefügt" noch eine Frage zum Verständnis: Wenn ich einem FTP-User ein Verzeichnis zuweise, das es noch nicht gibt, wird das mit der neuen Version dann angelegt oder ist genau diese Aktion noch nicht implementiert?