Probier mal den Check mit https://whatsmychaincert.com/ das hilft meist gut.
Posts by sudo
-
-
Beim "webmail"-DNS-Eintrag kannst du das Proxying (die Wolke) eigentlich an lassen. Wo du es ausschalten musst, ist beim "mail"-DNS-Eintrag, denn damit verbindet sich der Webmailer via IMAP / SMTP und Cloudflare proxied (jedenfalls in den meisten Tarifen) kein IMAP / SMTP (weswegen es zu dem genannten Fehler kommt). Beim Webmailer selbst hingegen ist es kein Problem, da die Verbindung mit diesem ja via HTTP / HTTPS stattfindet.
-
There are two speed test servers you can also ping:
There is https://lg.netcup.net/ as well (but it is Nuremberg, Germany only).
-
Hab mal ein bisschen im JS-Code geschaut, hier kommt das her:
https://wordpress.github.io/wordpress-playground/architecture/host-your-own-playground
-
Die DNS-Einträge der Domain werden noch auf das alte Hosting verweisen, wenn du die Domain also aufrufst, landest du auf dem alten (gesperrten) PPA-Hostingtarif. Das ist die Meldung, die erscheint, wenn ein Tarif in PPA deaktiviert ist.
Beachte hier den dritten Punkt:
Danach kann es einige Stunden dauern, bis du beim Abruf der Domain auf dem neuen Hostingserver landest.
-
Ich sehe den Fehler, weiß aber nicht, wie dieser bei deiner Anwendung zu lösen ist. Dennoch hilft es vielleicht, erst einmal festzustellen, was hier nicht stimmt.
Deine Anwendung versucht auf /assets/… zuzugreifen. Der Pfad müsste jedoch so beginnen:
Code/var/www/vhosts/hostingxxxxxx.a1234.netcup.netwobei „hostingxxxxxx.a1234.netcup.net“ durch die Standarddomain deines Hostings zu ersetzen wäre.
Bei vielen Webanwendungen kann man diesen Pfad z.B. in einer Konfigurationsdatei definieren.
Wenn du dich per FTP oder SSH einloggst, dann befindet sich dein Root, also „/”, unter diesem Pfad. Wird jedoch eine PHP-Anwendung vom Webserver ausgeführt, entspricht der Root, also „/”, dem Root vom ganzen Webhostingserver, so dass immer obiger Pfad mit übergeben werden muss.
-
Lösche das Verzeichnis mit den falschen Berechtigungen und lasse dieses dadurch anlegen, dass du im CCP den Dokumentenstamm einer Domain auf den gewünschten Pfad zeigen lässt (ohne dass dieser bereits existiert). Wird das Verzeichnis über diesen Weg neu angelegt, erhält es die korrekten Rechte.
-
Versuch mal, vor dem php-Befehl noch COMPOSER_MEMORY_LIMIT=512M zu schreiben, also:
CodeCOMPOSER_MEMORY_LIMIT=512M php -d memory_limit=512M composer.phar install --no-dev --optimize-autoloader -
Bei diesen genannten DDNS Client benötige ich einen WebServer mit PHP. (https://github.com/stecklars/dynamic-dns-netcup-api)
Das Skript benötigt keinen Webserver, sondern lediglich PHP-CLI, die Kommandozeilenversion von PHP, die sich einzeln installieren lässt (und auch nur in dem Moment Ressourcen verbraucht, in dem das Skript gerade läuft).
-
Genau, falls es daran nicht liegt, schau mal in /var/log/plesk/panel.log – dort sollte der Fehler auch geloggt werden, inkl. der PHP-Datei, welcher diesen auslöst. Es wird vermutlich irgendeine Extension sein.
-
Hi, poste am besten mal die genaue Fehlermeldung von Plesk. Das Plesk Panel nutzt ein eigenes PHP (sw-engine), das kannst du nicht einfach ändern. Aber vielleicht kommen wir mit der genauen Fehlermeldung dem Problem ja auf die Schliche.
-
Du kannst das einfach mit angeben:
Codephp -d memory_limit=1G dein_skript.php -
Ehrlich gesagt glaube ich, bei der Mehrzahl der Anbieter würde man das nur daran bemerken, dass die Antwort schlicht länger als sonst dauert. Insofern ist diese Offenheit doch grundsätzlich zu bevorzugen.
-
Display More
Spinnen bei euch gerade auch die DNS Server von Netcup?
Also sowohl die "internen" als auch die authoritativen Server?
EDIT: Mit "spinnen" meine ich (teilweise) lange Antwortzeiten.
EDIT #2: Ok betrifft wohl nur die jeweils ersten internen also 46.38.225.230 sowie 2a03:4000:0:1::e1e6
Kann hier keine Probleme feststellen.
-
Da versucht wer CVE-2021-40438 auszunutzen. Wenn du eine gepatchte Apache2-Version nutzt, hast du nichts zu befürchten. Für Debian kannst du hier z.B. sehen, welche Version den Patch hat:
https://security-tracker.debian.org/tracker/CVE-2021-40438
Wenn du nur nginx nutzt: Evtl. gab es da mal eine ähnliche Lücke, das weiß ich nicht. Oder der Angreifer geht davon aus, dass dahinter ein verwundbarer Apache2-Server ist und der nginx nur als Reverse Proxy fungiert (oder prüft den Webserver gar nicht).
-
Es dauert ca. 10 Minuten bis der Record von netcup übernommen wird und du dürftest erst danach auf "Neu laden" klicken. Daher mein Tipp: Lass die Option mit der Wildcard-Domain ("Wildcard-Domain schützen (inklusive www und Webmail")) beim Erstellen des Zertifikats weg, dann brauchst du nichts an den DNS-Einstellungen machen. www. und die Domain selbst kannst du problemlos sichern ohne die DNS-Einträge anzupassen. Dann wird das Zertifikat zukünftig übrigens auch automatisch verlängert.
Wenn du doch mal eine Subdomain sichern willst, kannst du das bei der genauso machen, von daher braucht man die Wildcard-Option nur in sehr wenigen, speziellen Anwendungsfällen unbedingt.
-
Versuche mal, bei der Domain in den "PHP-Einstellungen" bei "open_basedir" den anderen Wert zu nutzen, danach ca. 5 Min. abwarten. Ggf. einmal explizit beide Werte testen. Daran könnte es liegen.
-
Es funktioniert nur am PC / großem Tablet. Auf Handys werden die Eier nicht angezeigt, weil es zu einfach wäre. Liegt es vielleicht daran bei dir Illunis?
-
Also ich sehe die Ostereier schon.
-
Interessanter Artikel zu UCEPROTECT:
https://blog.sucuri.net/2021/0…ect-when-rbls-go-bad.html
QuoteAfter a thorough investigation, we discovered that the RBL provider uceprotect[.]net has listed a wide range of IPs (including our own) as notable reputed spammers, despite the fact that many servers are not even set up or capable of sending email content
