Beiträge von weltmeister

Das Problem hat sich mit dem gestrigen Update erledigt. Danke nochmals dafür!

Das mit der Sprache ist mir auch aufgefallen, das sollte noch angepasst werden.

Schade aber, dass diese Sache von gestern nicht mehr ins aktuellen Update integriert werden konnte: https://www.liveconfig.com/de/…/3270-ProFTP-sehr-langsam

Tausend Dank, das war die Lösung und der entscheidende Tipp. Der Zugriff klappt wieder in ca. einer Sekunde.

Da wir allerdings ProFTP durch LiveConfig verwalten lassen: kann dies bitte mit in die Standardkonfiguration aufgenommen werden, @Herr Keppler?

Auch hier wird empfohlen, dies auf off zu stellen: http://www.proftpd.org/docs/howto/BCP.html

Hat das Problem noch jemand?
Vor ein paar Tagen oder Wochen konnte man eine FTP-Verbindung noch innerhalb von einer Sekunde herstellen. Jetzt dauert es bis zu 10 Sekunden oder der Vorgang bricht ab. Wo könnte die Ursache sein? Ein Neustart des Dienstes bringt leider nichts, auch nicht das neukonfigurieren der Einstellungen im LiveConfig.
Das Problem tritt derzeit auf allen Servern auf, egal ob unter Debian 9 oder Debian 10.

Wir sind da auch seit über 14 Jahren registriert - eine Prüfung o.ä. hat es bisher jedoch noch nie gegeben.

Wer will schon exe- oder com-Dateien als Anhang in einer Mail? Zu 99,99% sind das Spam und Virenmails, die man somit blocken könnte.

Nicht separat, sondern global.

https://www.kais-universum.de/…enge-mit-postfix-filtern/

Könnte man dies mit / durch LiveConfig auch problemlos umsetzen?

Weiß jemand, ob man diese Liste nun wieder einbinden und nutzen kann?

Wir mussten die Liste überall rausnehmen, hier ging gar nichts mehr. Über 100 Anrufe und knapp 60 Mails am heutigen Sonntag sind das Resultat dieser schlamperei!

Zitat von taenzerme

OT: Wie löscht man denn versehentlich diesen Ordner?

Per FTP problemlos machbar, es gibt leider eben auch Leute / Anfänger, die denken, das sei "Datenmüll", der weg kann Sobald man das Verzeichnis gelöscht hat, ist die Webseite nicht mehr erreichbar. Und schon kommen Mails wie "der Server ist abgestürzt..." und die Fehlersuche beginnt. Es gab sogar auch schon Webdesigner, welche die Verzeichnisse entfernt haben, weil sie eben löschbar waren.

Heute hat sich wieder ein Kunde gemeldet, der den OpCache Ordner "versehentlich" gelöscht hat. Mit den korrekten Schreibrechten könnte man dies von vornherein umgehen. Das Resultat war eine nicht mehr erreichbare Webseite.

Kann dies noch beim kommenden Update berücksichtigt werden?

Eine neue Backup-Funktion ist (schon seit langer Zeit) in Arbeit. Hoffen wir auf ein baldiges Update.

Dann hast du sicher nicht viele oder nur eine Handvoll Kunden. Wie schon geschrieben, wer es nicht braucht, muss es nicht nutzen.

Es geht nicht darum was wir wollen, sondern was ein Großteil der Kunden wünscht. Wer es nicht braucht, muss es nicht nutzen.

Da die Anfragen nach einem Spamordner nicht nachlassen, frage ich erneut nach dieser Möglichkeit an.

Über sinn und unsinn kann man sich streiten, aber die Kunden wollen es so.

Ständig kommen Mails und Anfragen wie:

"Wo ist der Spamordner", "Warum ist der Spamordner leer", "Bei anderen Providern gibt es Spamordner nur bei Ihnen nicht"... ich kann es schon nicht mehr lesen.

Dem Kunden sollte es überlassen bleiben, das Mails, die als Spam markiert werden in einen Ordner verschoben werden oder eben wie bisher nur markiert werden. Hierzu stelle ich mir eine Checkbox unter den Maileinstellungen vor.

Siehe auch: https://www.liveconfig.com/de/…erschieben-statt-abweisen

Vielen Dank!

Das hört sich doch gut an, vielen Dank! Ich hoffe auf ein baldiges Update.

In der Tat wird immer wieder auf verschiedenen Servern wo dieses Problem auftritt auf volle Kundenwebspaces verwiesen.

"journalctl -u logrotate.service"

gibt immer und immer wieder aus:

Zitat

Jan 18 00:00:00 s5.de systemd[1]: Starting Rotate log files...
Jan 18 00:00:02 s5.de logrotate[26935]: error: Compressing program wrote following message to stderr when compressing log /var/www/web11/logs/priv/php_errors.log.1:
Jan 18 00:00:02 s5.de logrotate[26935]: gzip: stdout: Disk quota exceeded
Jan 18 00:00:02 s5.de logrotate[26935]: error: failed to compress log /var/www/web11/logs/priv/php_errors.log.1
Jan 18 00:00:02 s5.de logrotate[26935]: error: Compressing program wrote following message to stderr when compressing log /var/www/web120/logs/priv/php_errors.log.1:
Jan 18 00:00:02 s5.de logrotate[26935]: gzip: stdout: Disk quota exceeded
Jan 18 00:00:02 s5.de logrotate[26935]: error: failed to compress log /var/www/web120/logs/priv/php_errors.log.1
Jan 18 00:00:04 s5.de logrotate[26935]: error: Compressing program wrote following message to stderr when compressing log /var/www/web5/logs/priv/php_errors.log.1:
Jan 18 00:00:04 s5.de logrotate[26935]: gzip: stdout: Disk quota exceeded
Jan 18 00:00:04 s5.de logrotate[26935]: error: failed to compress log /var/www/web5/logs/priv/php_errors.log.1
Jan 18 00:00:06 s5.de systemd[1]: logrotate.service: Main process exited, code=exited, status=1/FAILURE
Jan 18 00:00:06 s5.de systemd[1]: logrotate.service: Failed with result 'exit-code'.

Alles anzeigen

Wenn der Kunde jedoch z.B. keinen größeren Tarif wünscht, können wir nich einfach so umstellen. Es muss eine andere Lösung geben, falls dies die Ursache ist, wovon ich bisher ausgehe.

Es sind nur die standardmäßigen Cronjobs von LiveConfig aktiv, sonst nichts. Der Backup-Dienst ist nicht aktiviert.