Beiträge von Sumeragi

    Die Traffic Warnung wird per Cronjob über /opt/pdadmin/bin/traffic_warning.pl verschickt. Gibt es einen Fehler wenn man diese Datei manuell ausführt?


    Ich weiß nur gerade nicht wo die Traffic Statistiken generiert wird... Müsste man mal im crontab schauen was da einmal pro Nacht ausgeführt wird. Irgendwas davon ist es dann :-P

    Der Traffic wird mit /opt/pdadmin/bin/ftp_log.pl ausgewertet. Bin nicht so firm mit Perl, aber hier

    wird das Log ausgewertet. Mit der split() Funktion wird der String auseinander genommen und \s+ steht für whitespace. Sieht mir ähnlich wie bei dem Tool awk aus. Sehe da kein Problem mit der IP Adresse.


    Prinzipiell sollte man /opt/pdadmin/bin/ftp_log.pl ja auch manuell ausführen und somit testen können. Also ob es Fehler gibt oder nicht. Oder man passt denn Cronjob an und lässt die Ausgabeumleitung weg.

    Zitat von monderka

    Diese Rechte sollte wohl jeder mal prüfen um vor Überraschungen sicher zu sein.

    Mein PDA ist gut 3 Jahre alt und hat diese Probleme nicht. Demnach werden wohl nur Neuinstallationen ab Version X bzw Zeitpunkt Y betroffen sein. Was ist Ihre älteste betroffene Installation? Dann hätte man zumindest einmal einen groben Zeitraum.

    Danke Dir. Möglicherweise haben sich jetzt unsere Postings überschnitten. Konnte inzwischen einiges eingrenzen.


    Zusammengefasst die Erkenntnis:

    Die Weiterleitungsdatei wird angelegt wie geplant. Sobald ich die erste Zeile (...forward_filter) entferne, funktioniert die Weiterleitung.
    Mit dieser Zeile funktioniert sie wie beschrieben nicht.

    Ja sieht so aus :)


    Also sollte man sich /opt/pdadmin/bin/forward_filter einmal genauer anschauen. Stimmen auch hier die Berechtigungen?

    Shell-Script
    1. $ ls -al /opt/pdadmin/bin/forward_filter
    2. -rwsr-xr-x. 1 popuser popuser 9547 29. Jun 2016 /opt/pdadmin/bin/forward_filter

    Also Mails kommen lokal an, werden aber nicht weiter geleitet.


    Die Weiterleitungen finden sich unter /home/<endkunde>/qmail-*


    Daher würde ich hier einmal schauen: Gibt es die Datei(en)? Stimmen die Berechtigungen? Wie ist der Inhalt? Bei mir sieht der Inhalt einer neu angelegten Weiterleitung wie folgt aus:


    |/opt/pdadmin/bin/forward_filter

    |/opt/pdadmin/bin/srs_forward.pl mail@beispiel.de


    Was passiert wenn man die erste Zeile entfernt? Was passiert wenn man nur


    &mail@beispiel.de


    einträgt? (in dem Fall sollte einfach an die Mailadresse weitergeleitet werden)

    Ob damit ein Zusammenhang besteht weiß ich leider auch nicht. Auch diesen Fehler finde ich bei meinen Logs nichts. Besagte Datei befindet sich jedenfalls unter


    /usr/local/pd-admin2/lib/perl5/site_perl/5.10.1/x86_64-linux/Net/DNS/RR/AAAA.pm


    Wie sieht denn die @INC Variable aus?

    Shell-Script
    1. perl -e "print \"@INC\""

    Dort sollte '/usr/local/pd-admin2/lib/perl5/site_perl/5.10.1/x86_64-linux' vorkommen. Dann sollte die Datei auch gefunden werden.

    beim Angebot ist die Option "SAPI-Änderung erlaubt" deaktiviert, warum hat der Kunde trotzdem die Möglichkeit "PHP ausführen über" zu ändern?

    Die Möglichkeit wird angezeigt, aber der Nutzer kann diese nicht ändern. Bei Deaktivierung bleibt es bei 'default'.


    Wie kann verhindert werden, dass der Kunde Werte an der php.ini ändern kann?

    Vielleicht mit 'chattr -i /home/<endkunde>/php.ini die Datei vor Änderungen schützen? Ja, der Nutzer könnte dies wieder entfernen... aber nur wenn dieser SSH Zugriff hätte.


    Wie kann das Kundenmenü "FTP-Konten" deaktiviert werden? Wir verwenden ausschließlich SFTP.

    In /opt/pdadmin/etc/customer_menu.conf den Eintrag

    entfernen.

    Warum wird beim Kunden im Homeverzeichnis neuerdings eine php.ini angelegt, obwohl die Variable phprc in der pdadmin.conf nicht auf 'home' gesetzt ist?

    Das weiß ich leider nicht. Womöglich gibt die Variable nur an, wo die php.ini zu finden ist. Wann wird denn die php.ini angelegt?

    Die Leistung hängt nicht von den Limits ab, sondern von der Ausstattung des Servers (CPU, Kerne, RAM, ...).


    Hat man Beispielsweise zwei identische Shops/Domains - sagen wir im Schnitt mit 10 gleichzeitigen Nutzern - sollte das CPU Limit bei einzelnen Accounts auf min. 10. Bei einem gemeinsamen Account wären es dann min. 20.

    Die Limits sollen vor übermäßigem Ressourcengebrauch schützen. Wenn z.b. ein Skript endlos läuft oder wenn die Seite Ziel von Bots wird. So wird verhindert, dass andere Seiten, Accounts, Dienste oder gar der ganze Server in die Knie geht. Höhere Limits ≠ mehr Performance.


    Wenn zwei gleiche Shopsysteme unterschiedliche Performance liefern, muss man sich beide genauer anschauen. Konfiguration identisch/unterschiedlich? speziell Caching. Anzahl an Nutzern? Anzahl an Produkten?


    Mehrere Accounts macht in so fern Sinn, dass man Seiten voneinander trennen kann. Ist ein Account z.b. kompromittiert worden, betrifft die nur diesen Account. Das ist speziell dann kritisch wenn die Zugangsdaten des Hauptnutzers (DB oder FTP) ausgespäht wurden. Mehrere Accounts zu nutzen hat also mehr ein Sicherheitsaspekt.

    Ich habe es gerade Mal nachgeschaut. Bei mir ist das CPU Limit auch 480. Der Wert scheint mir aus der httpd_vhost.pl zu kommen. Zumindest konnte ich dies nirgends finden... Hatte es mir bisher aber auch nie näher angeschaut und lediglich Änderungen für :80 im Template vorgenommen.


    Wenn das RLIMIT_NPROC Limit erreicht wurde, sollte geprüft werden wodurch. Denn die bedeutet ja, dass entsprechend viele Skripte bzw Prozesse ausgeführt würden.

    Leider ist nicht klar was genau hier der Fehler ist. Was steht denn im Log von Let's Encrypt dazu?


    Ich rate einfach Mal drauf los: Es gibt Unstimmigkeiten mit dem Document Root. Das Document Root in der httpd.conf lautet


    /usr/local/pd-admin2/htdocs


    vermutlich ist unter


    /etc/letsencrypt/renewal/admin.web4.x.y


    ein anderer Pfad als Webroot angegeben. Dieser muss identisch zum Pfad in der httpd.conf sein.

    Das Template des Apache 2.4 findet man unter /usr/local/pd-admin2/httpd-2.4/conf/httpd24.conf-template

    Dort finden sich die Werte für den vhost des Backends. Angegeben sind nur die Werte für :80. Für :443 werden diese übernommen.


    Auch alles andere zum Apache 2.4 findet sich ebenfalls unter /usr/local/pd-admin2/httpd-2.4/

    Laut

    Code
    1. Certificate did not match expected hostname: acme-v02.api.letsencrypt.org.

    passt das Zertifikat des Servers nicht zum Hostnamen. Worauf löst der Hostname auf? Was gibt

    Shell-Script
    1. echo "" | openssl s_client -servername acme-v02.api.letsencrypt.org -connect acme-v02.api.letsencrypt.org:443 | openssl x509 -noout --dates

    aus?