Posts by helpy

    Bei mir ist das auch noch immer so:

    Code
    1. bash-4.3$ /usr/local/php72/bin/php --version
    2. PHP 5.6.40-0+deb8u1 (cli) (built: Feb 17 2019 01:19:33)
    3. Copyright (c) 1997-2016 The PHP Group
    4. Zend Engine v2.6.0, Copyright (c) 1998-2016 Zend Technologies
    5. with Zend OPcache v7.0.6-dev, Copyright (c) 1999-2016, by Zend Technologies
    6. bash-4.3$

    Ich habe das jetzt ebenfalls über CCP gemeldet.

    Gegt das in einem Webhosting-Paket 4000?


    RainLoop bietet folgende Plugins für Password-Änderungen:

    • Change password (cPanel)Plugin that adds functionality to change the email account password (cPanel).
    • Change password (DirectAdmin)Plugin that adds functionality to change the email account password (DirectAdmin).
    • Change password (ISPConfig)Plugin that adds functionality to change the email account password (ISPConfig).
    • Change password (POPPASSD)Plugin that adds functionality to change the email account password (POPPASSD).
    • Change password (hMailServer)Plugin that adds functionality to change the email account password (hMailServer).
    • Change password (LDAP)Plugin that adds functionality to change the email account password (LDAP).

    Funktioniert eines davon? Welche Parameter sind dann notwendig?

    Wer die ServerLogs im /logs Verzeichnis nicht möchte, kann diese auch mit einem CronJob alle 15 Minuten löschen lassen.

    Das funktioniert auch bei Webhosting-Paket 4000 (selbst ausprobiert).


    Trotz Löschen des Datein im /logs Verzeichnis sind die Protokoll weiterhin über das CCP einsehbar (entsprechend der dort eingestellten Rotation).

    Daher werden logs wohl auch noch an anderer Stelle gespeichert als im /logs Verzeichnis.

    Ich hätte da einen Feature-Request: IP-Anonymisierung bei Webhosting

    Im Controlpanel bei der Verwaltung der Protokolldateien kann man Einstellungen für die Protokoll-Rotation machen.


    Es wäre super, wenn man an dieser Stelle auch die IP-Anonymisierung aktivieren könnte.

    Bei Verwendung des Tools anonip könnnte man auch noch ein paar Parameter für die Konfiguration der Anonymisierung mit aufnehmen.

    Am besten gleich mit Strg+F5 im Browser den Cache "hard" leeren. Damit spart man das Rumgeklickte durch den Einstellungen vom Browser, um den Cache zu leeren.

    Hinweis:

    Strg+F5 löscht nicht den gesamten Cache, sondern lädt das aktuelle Browser-Fenster neu, ohne den Cache zu verwenden. Wobei dies nicht für den Inhalte von iframe-Elementen gilt.


    Wer also den gesamten Cache löschen will, nimmt entweder den Weg über die Einstellungen oder verwendet den Shortcut Strg+Shift+Entf.

    Ich habe Webhosting 4000 Paket und teste Sieve-Regeln gerade auch mit meiner persönlichen RainLoop-Installation.

    Regeln erstellen und auf dem Server speichern hat schon mal funktioniert.

    Und nach meinem aktuellen Test funktionieren diese Regeln auch und werden korrekt ausgeführt.


    SUPER! Vielen Dank.

    Der normale cron schickt tatsächliche keine Emails raus

    Das kann ich nicht nachvollziehen!

    Ich rufe per Server Cronjob die cron.php auf und da werden in der Tat E-Mails verschickt und ich werde über Uploads/Downloads, neue und gelöschte Dateien/Ordner informiert.


    Auch in der Nextcloud 12.x Dokumentation ist cron.php noch erwähnt:

    siehe: https://docs.nextcloud.com/ser…?to=admin-background-jobs

    Das ist nicht veraltet, sondern immer noch ein möglicher Weg, um E-Mails zu verschicken!

    Auch im Backend (...domain.tld/index.php/settings/admin#backgroundjobs) ist der Hinweis auf cron.php zu finden.


    occ hat aber genauso seine Berechtigung, um mehr Kontrolle über den Zeitpunkt des Versendens der E-Mails zu haben.


    Es ist also beides möglich und erlaubt ... und keines ist veraltet.

    Sie verhalten sich nur unterschiedlich!

    Ich habe ebenfalls Nextcloud in einen Netcup Webhostingpaket (Webhosting 4000) laufen.

    Nextcloud hat die Version 12.0.4.


    Den Cronjob habe ich wie folgt erstellt:

    ==> Aufgaben-Typ: PHP-Skript ausführen

    ==> Skript-Pfad: httpdocs/meine-domain.tld/nextcloud/cron.php

    ==> keine Argumente

    ==> PHP-Version: 7.1.13


    Das hat bisher gut funktioniert bei mir!


    Probier doch anstatt Aufgaben-Typ "Befehl ausführen" doch mal "PHP-Skript ausführen" aus:

    Gib als Skript-Pfad "httpdocs/XXXXX/occ" und als Argumente "activity:send-mails hourly" ein.

    PHP-Version wählen, mit der Du Nextcloud betreibst.

    So wie ich das verstanden habe, werde die Verzeichnisse nicht gelöscht, oder?

    Beim WCP (Webhosting 4000) ist das der Fall!

    Zugeordnete Verzeichnisse und Datenbanken werden nicht gelöscht.

    Zumindest konnte ich das gerade bei einer Sub-Domain feststellen.

    Und das ist IMHO auch gut so!

    Ich habe gestern probeweise Nextcloud 12.0.3 auf einem Webhostingpaket 4000 installiert.

    Dort habe ich dieselbe Fehlermeldung bzgl. /dev/urandom bekommen.


    Nach Rückfrage beim Suppert habe ich die Information erhalten, dass hier nichts geändert wird.

    Damit müssen wir also leben oder auf ein vServer Paket umsteigen.


    Ich habe mich dann nochmal auf dei Suche gemacht und bin auf folgende Information gestoßen:


    ==> https://github.com/nextcloud/server/issues/5530


    Ich habe mir dann noch den PHP-Code von Nextcloud angesehen.

    Ab PHP 7.0 wird die Funktion random_bytes(length) verwendet. Ein Zugriff vom PHP-Skript auf /dev/urandom ist damit nicht notwendig. Die Fehlermeldung wird ab PHP 7.x also unnötigerweise ausgegeben.