Beiträge von cfraatz

    Leider ist dieses Thema noch immer aktuell. Das Administrator-Dashboard ist gewohnt fix, aber das Kunden-Dashboard ist elend langsam. Ich vermute, es liegt tatsächlich nicht an der SEU, sondern an der hohen Zahl von aktuell 1.495 Mailboxen und zusätzlich zahlreichen Weiterleitungen, die der Kunde auf verschiedenen Domains eingetragen hat.


    Hat dazu jemand eine Idee, wo man ansetzen kann, um das Dashboard zu beschleunigen - wenn meine Vermutung denn Sinn macht.


    Danke und Grüße

    Carsten

    Installierte pd-admin-Version: v4.96

    Installierte Reihe und Version der Serverumgebung: 4-0.402


    Nach Installation der SEU 4-0.402 dauert der Aufruf des Dashboards für "customer" sehr lang, teilweise bis zu 45 Sekunden. Alle Untermenü-Punkte funktionieren dann normal, aber der Aufruf des Dashboards dauert immer wieder lang.


    Per "top" ist zu sehen, dass das Skript customer.cgi relativ hohe CPU-Ressourcen benötigt.


    Kann jemand dieses Problem bestätigen?


    Danke und Grüße

    Carsten

    Installierte pd-admin-Version: v4.95

    Installierte Reihe und Version der Serverumgebung: 4-0.401


    Die Bedienung der pdadmin-Oberfläche ist momentan quasi nicht möglich, man wird ständig vom System ausgeloggt. Dies passiert sowohl mit Chrome als auch mit Firefox, im normalen und im Inkognito-Modus. Das Ausloggen passiert an den unterschiedlichsten Stellen, es ist kein Muster erkennbar. Man landet dann auf der Login-Seite mit der Meldung "Login failed".

    Es kommt immer mal wieder eine Anfrage von Kunden, die wissen wollen, wieviel Speicherplatz sie zur Verfügung haben, und wieviel belegt sind. Die einzelnen Werte gibt es zwar, aber an unterschiedlichen Stellen: Unter Dashboard > Webspace findet sich der verfügbare Platz, unter Statistiken > Speicherplatz der belegte Platz.


    Schön wäre es, wenn der belegte Platz gleich mit im Dashboard angezeigt würde.


    Beste Grüße

    Carsten Fraatz

    Der schient doch auf dem lokalen vServer nach Updates zu suchen denn

    Code
    130.255.76.239

    ist doch eine IP von B&K.

    Yup, diese IP wurde durch einen Eintrag in der /etc/hosts gesetzt - nachdem ich den Eintrag gelöscht habe, funktioniert alles wie gewünscht.


    Wie gesagt sind die Server neulich auf neue Hardware umgezogen; dieser Umzug wurde durch Providerdienste durchgeführt. Evtl. ist der Eintrag dabei entstanden und wurde versehentlich nicht gelöscht.


    Danke auf jeden Fall an Sumeragi für den entscheidenden Tip! :thumbup:

    Einen schönen Abend euch allen!

    Ich habe bei Ausführung von freshclam ebenfalls keine Probleme.


    Was passiert denn Sie eines der Files manuell herunter laden?

    Bash
    curl -vvv https://database.clamav.net/daily-25824.cdiff --output delete.me && rm delete.me

    Da passiert das hier:


    Die betroffenen Server sind vor Kurzem auf neue Hardware umgezogen worden. Kann es sein, dass es da eine Art "Fingerprint" gibt, die jetzt nicht mehr passt und zu den beobachteten Verbindungsproblemen führt? :/

    Das hat nichts mit Deinen SSL Zertis zu tun, hier wird über das Zertifikat von database.clamav.net gemeckert.


    Bei einem Test auf einem meiner Server konnte ich das Problem jetzt nicht nachvollziehen. Bist Du mit der Serverumgebung soweit halbwegs up to date?

    Ach Mist, da habe ich die Angaben vergessen... :rolleyes:


    Installed pd-admin Version: v4.63

    Installed Version of the Server-Environment: 4-0.359


    Also soweit alles aktuell...

    Installed pd-admin Version: v4.63

    Installed Version of the Server-Environment: 4-0.359


    Beim Update-Prozess von freshclam erscheint neuerdings auf mehreren Servern ein SSH/SSL-Fehler:


    Unter /opt/pdadmin/sslcerts/ liegen gültige SSL-Zertifikate, das Backend ist auch ordnungsgemäß verschlüsselt. Scheinbar verwendet freshclam aber andere Zertifikate - wo liegen die? Oder liegt der Fehler ganz woanders?

    [...] Auf dem Screenshot sieht man ja auch, dass /usr/local/pd-admin2/php-7.2.31/bin/php-cli angegeben ist. Jedoch ohne "-c /home/USER/php.ini". Daher wird hier die Standard php.ini geladen, welche allow_url_fopen deaktiviert hat. Da es dort ein Ändern Button gibt, schätze ich kann dies angepasst werden und würde vorschlagen dort mal "/home/USER/bin/php" für die PHP-CLI anzugeben. Natürlich mit aktivierter lokaler php.ini ;) Alternativ könnte man auch versuchen "/usr/local/pd-admin2/php-7.2.31/bin/php-cli -c /home/USER/php.ini" anzugeben.

    Bingo - die Eingabe von "/home/USER/bin/php" löst das Problem, Contao ist zufrieden! Der zweite Weg funktioniert nicht, da Contao eine PHP-Binary erwartet, ohne Parameter.


    Vielen Dank für die Hilfe! :thumbup:

    In der .bashrc findet sich keine PATH Variable:

    Code
    # .bashrc
    
    # User specific aliases and functions
    
    # Source global definitions
    if [ -f /etc/bashrc ]; then
    . /etc/bashrc
    fi


    In der .bash_profile hingegen schon


    Bei keiner der Dateien ändert sich der Timestamp, wenn man Änderungen an den PHP-CLI-Einstellungen vornimmt. Was sich ändert, ist die Datei bin/php - aktuell sieht sie so aus:

    Bash
    #!/bin/bash
    export PHP_BINARY=/usr/local/pd-admin2/bin/php-7.2-cli
    exec /usr/local/pd-admin2/bin/php-7.2-cli -c /home/frieddby/php.ini "$@"


    Die Shell /bin/bash ist für den Kunden frieddby aktiviert.

    Installierte pd-admin-Version: v4.63

    Installierte Version d. Serverumgebung: 4-0.356


    Wenn ich im Kundenmenü unter Allgemein > PHP-CLI-Einstellungen den Haken bei Lokale php.ini verwenden > Aktivieren setze, wird das der anschließenden Meldung zufolge ausgeführt. Wenn ich dann aber wieder den Menüpunkt wieder öffne, ist das Klickfeld nicht aktiviert.


    Nun wird entweder die lokale php.ini nicht aktiviert (wie kann ich das überprüfen?), oder das Klickfeld wird immer deaktiviert angezeigt, egal wie die tatsächliche Einstellung ist.

    Inzwischen habe ich das Phänomen auf allen unseren Servern (alle unter CentOS).


    Wenn ich das oben gelistete /service/qmail-smtpd/run Skript einstelle, liegt der Port 25 flach, d.h. es werden keine ankommenden Mails mehr vom Server angenommen...

    Gleiches Problem hier, erst nur auf einem Server, nun auf einem zweiten. Allerdings kann ich in den Logfiles nichts relevantes finden; der Client stellt erst gar keine Verbindung her. Beide Server laufen auf CentOS release 6.9 (Final) mit der aktuellen SE.

    - Welche Version von pd-admin wird eingesetzt? v4.57


    - Welche Version der Serverumgebung wird eingesetzt? 4-0.301


    - Welche Logfile-Einträge (zB. Webserver- oder Mail-Logfile) gibt es?


    Code
    [Fri Dec 01 15:59:43 2017] [error] [client x.x.x.x] PHP Warning:  PHP Startup: ldap: Unable to initialize module
    [Fri Dec 01 15:59:43 2017] [error] [client x.x.x.x] Module compiled with module API=20090626
    [Fri Dec 01 15:59:43 2017] [error] [client x.x.x.x] PHP    compiled with module API=20131226
    [Fri Dec 01 15:59:43 2017] [error] [client x.x.x.x] These options need to match
    [Fri Dec 01 15:59:43 2017] [error] [client x.x.x.x]  in Unknown on line 0


    Ich habe wie hier beschrieben versucht, PHP5 mit LDAP Unterstützung zu installieren. Leider erhalte ich aber die o.g. Fehlermeldung. Wenn ich die Meldung richtig verstehe, ist das Modul älter als PHP möchte - es ist aber die aktuelle Version 5.3.3-49.el6 für das installierte CentOS 6.9.


    Muss ich jetzt auf CentOS 7 upgraden, um LDAP zum laufen zu bekommen? Oder liegt der Fehler ganz woanders.


    Danke + Grüße
    Carsten