Posts by tab

    Ok, dann halt nur noch telefonieren auf dem Smartphone, E-Mail ist damit dann halt für mich auf dem Smartphone einstweilen gestorben.

    Trägst du den Hostnamen oder die IP-Adresse ein? Da gibt es einen Unterschied.


    tab das taucht nicht auf, weil eine Domain angegeben wurde. Probiere mal die IP des Servers anzugeben, dann kommt die ellenlange Liste raus.

    Eine meiner Domains, die auf dem Server ihre Mailaccounts hat. Ok, da kommt dann auch, dass ich da gelistet sei, die Erklärung klingt nach UCEPROTECT :D . Wusste gar nicht, dass die auch in Polen agieren. Also das juckt mich jetzt weniger, als wenn in Peking ein Sack Reis umfällt. Aber ja, ich habe schon Spam-Mails aus Polen auf diesen Server bekommen, vielleicht zählt das ja auch schon :/ .

    Meinst du bl-h3.rbl.polspam.pl?

    Auf der Liste sind auch meine drei netcup-Server. Aber auch meine zwei von Cont*** und von ION** sind dort gelistet.


    Genau, siehe #42500.

    Mein Server mit der IP vom roten H ist ebenfalls geblacklistet.

    Aber nicht den von Skriptsprache-Freunde. Weder bei polspam.pl noch bei UCEPROTECT.

    Wahrscheinlich sind da alle gelistet, die nicht aus Polen kommen und schon mal eine Mail an eine polnische Adresse geschickt haben.

    Nennt sich "Polspam BL-H3" und ist geblacklisted bei mir (zwei Server hier bei Netcup aus dem 37.120... und 202.61... Bereich)

    Die gibt es aber bei deinem Link gar nicht ?( . Bei mir sind alle grün, eine Polspam BL-H3 wird da nicht angezeigt, nur

    Polspam RHSBL und Pospam RHSBL-H.

    Kann man doch eigentlich nichts falsch machen beim Klicken auf einen Link?!? Oder muss ich von da erst noch irgendwohin navigieren um an die Polspam BL-H3 zu kommen?

    polspam.pl ist doch dort gar nicht dabei?!? Nur rhsbl.rbl.polspam.pl und rhsbl-h.rbl.polspam.pl. Bei beiden ist mein Mailserver nicht gelistet, eigentlich bei keiner der dortigen Blacklists. Also halt nur auf den unsichtbaren Blacklists einer Firma aus Redmond.

    Wahrscheinlich zuviele Performance-Tests ^^:D;( . Nee, im Ernst, da ist wohl etwas schiefgelaufen.

    Was du probieren könntest, ohne Garantie auf Erfolg weil ungetestet.


    1. Im CCP unter Domains die Zuordnung der Domain zum Webhosting aufheben. Das wird dir allerdings vermutlich die bereits eingerichte Domain und Subdomains zerschiessen/löschen, inklusive eventuell eingerichteter E-Mail Postfächer. Plesk ist da relativ radikal.
    2. Die Nameserver der Domain auf Cloudflare setzen und dort A, AAAA und sonstige Records wie gewünscht/benötigt für Domain und Subdomains auf Webhosting- bzw Server-IP verweisen lassen.
    3. Die Domain als externe Domain ins Webhosting einbinden.
    4. Im Webhosting die gewünschten Subdomains anlegen

    Der kritische Schritt, bei dem ich nicht sicher bin ob er funktionieren wird, wäre Schritt 3. Ich bezweifle es eigentlich, denn Zusatzdomains sind nun mal keine externen Domains, sondern bei netcup registriert. Ich sehe aber keine andere Möglichkeit, ohne dass netcup das seltsame Verhalten (nginx funktioniert, Apache nicht) behebt. Dazu könntest du mal beim Support nachfragen bzw das dort als Verbesserungsvorschlag anbringen. Also dass Apache auch mit Subdomains funktioniert, die nach der Umstellung einer dem Webhosting zugewiesenen Zusatzdomain auf einen externen Nameserver angelegt werden. Das wäre grundsätzlich schon wünschenswert. Eventuell kann man das auch im Forum hier an der passenden Stelle als Vorschlag unterbringen. Ob das aus Sicht von netcup technisch ohne riesigen Aufwand realisierbar ist und welche Priorität das dann bei der Umsetzung hat sei mal dahingestellt. Ich fürchte, selbst wenn das technisch möglich ist und letztlich realisiert werden sollte, wird es wohl eine Weile dauern.


    Wenn auch das o.g. Vorgehen scheitert, bliebe als letzte Konsequenz nur noch die Möglichkeit, die Domain umzuziehen und dann vorzugehen wie oben, wobei der Domainumzug zwischen Schritt 1 und 2 eingeschoben werden sollte. Das sollte jedenfalls funktionieren, mit externen Domains gab es eigentlich nie Probleme bei meinen netcup Webhostings. Falls die Einbindung als externe Domain trotzdem scheitern sollte, geistern wahrscheinlich noch irgendwelche Überreste der umgezogenen Domain in den netcup-Systemen rum, das wäre dann Aufgabe des Supports, diese zu beseitigen, so dass die Domain als externe Domain ganz normal eingebunden werden kann. Bei einem vServer sollte es eh völlig irrelevant sein, wo die Domain registriert ist und welche Nameserver sie benutzt.

    Also "von außen" löst die Domain auf ein netcup Webhosting auf. IPv4 und IPv6. Bei Aufruf im Browser kommt eine Verbindung über https problemlos zustande. Zertifikat von Let's Encrypt, sieht völlig ok aus.

    Für mich sieht das Szenario danach aus, dass - aus welchem Grund auch immer - neu angelegte Subdomains nur richtig funktionieren, wenn zum Zeitpunkt ihrer Erzeugung die netcup Nameserver im DNS der Domain eingetragen sind. Ansonsten macht zumindest der Apache Probleme bearbeitet keine Requests, während nginx trotzdem zu funktionieren scheint. Das mag so gewollt sein, ist aber doch irgendwie inkonsistent, weil nginx trotzdem funktioniert und nur der Apache nicht.


    Wenn also der Proxymodus bei nginx aktiv ist, wird nginx je nach den beiden anderen Einstellungen manche oder alle statischen Dateien (wie auch die index.html) selbst ausliefern, während z.B. Requests für PHP-Dateien an den Apache weitergeleitet werden, der sich aber nicht dafür zuständig fühlt und die Requests somit auch nicht bedient bzw mit einem 404 quittiert.


    Wäre mal interessant, ob die index.html immer noch ausgeliefert wird, wenn die "Intelligente Bearbeitung statischer Dateien" deaktiviert wird. Dann wäre Apache auch für die statischen Dateien zuständig, würde sie aber nicht ausliefern, wenn ich mit meiner Vermutung richtig liege. Es dürfte dann also bei allen Requests für die Subdomain ein 404 kommen oder jedenfalls ein Fehler.

    Na, mit geblocktem Javascript wirst du nicht viel Vergnügen haben im Web. Ich bin zwar auch nicht davon begeistert, aber es ist heutzutage praktisch allgegenwärtig, insbesondere noch nach Einführung der DSGVO, aber auch schon viele Jahre vorher. Ob das Backend von WP ohne Javascript läuft weiss ich nicht, im Frontend wird man auch bei WP ohne Javascript auskommen können, aber es erfordert dann halt mehr Wissen um die Möglichkeiten von HTML5 und CSS3, wenn man sich nicht auf relativ einfache, traditionelle (manche sagen auch "old school") Websites beschränken will. Da der Hauptfocus bei WP aber m.E. darauf liegt, auch jedem Ahnungslosen zu ermöglichen, eine "eindrucksvolle" Website zu erstellen, wird das eben ohne Javascript - gelinde gesagt - schwierig.

    bei mir ist's umgekehrt. ^^

    Code
    l -d /bin /usr/bin
    drwxr-xr-x   2 root root 4096 Mai 13 15:08 /bin/
    lrwxrwxrwx 259 root root    4 Apr 19  2021 /usr/bin -> /bin/

    Auch bei dir in einem netcup-Webhosting? Hmm. Jeder Server ein Unikat ;):rolleyes: Muss ich nachher doch mal einige weitere Webhostings anschauen, ob die auch unterschiedlich sind in der Beziehung. Letztlich sollen die Dateien wohl einfach unter beiden Pfaden erreichbar sein, wozu auch immer.

    Also wenn definitiv im document root vorhandene html-Dateien gefunden werden und php-Dateien nicht, dann sollte sich eigentlich der Support damit befassen. Was allerdings sehr komisch ist, dass der selbe Apache bei anderen Subdomains offenbar funktioniert. Bist du sicher, dass wirklich alle html-Dateien gefunden werden und nicht nur eine index.html, die vielleicht auf einem völlig anderen Server liegen könnte? Ping auf die zuerst angelegten Subdomains zeigt die selbe IP-Adresse wie bei den neu angelegten? Du hattest ja anfängliche Probleme mit Cloudflare bei den mittlerweile funktionierenden Subdomains erwähnt.

    Also ich würde da nach deiner Beschreibung, dass hier beim ersten Upload was schiefgegangen ist, eher den Umzug nochmal komplett neu machen. Aber ich denke ich halte mich da mit meinem gefährlichen Wordpress-Halbwissen (eher 'Un' als 'Halb') besser raus, es gibt hier genügend Leute, die sich mit Wordpress wesentlich besser auskennen als ich.

    Also wenn zwei andere, von der Konfiguration her wirklich 100% identische Installationen laufen, dann sind sie sehr wahrscheinlich nur 99% identisch ;) . Und Plesk dann da mit seinem Wordpress Toolkit dazwischengrätschen zu lassen war wahrscheinlich keine gute Idee, auch wenn sie vom Support kam. Dass die sowas empfehlen, auch wenn schon Plugins installiert sind, die eventuell was an der Konfiguration ändern, das verstehe ich nicht. Das kann aber auch an mir bzw daran liegen, dass ich Wordpress nicht wirklich kenne.


    Wenn Cache-Plugins installiert sind, könnten die eigentlich nicht mehr vorhandenen Dateien da noch drin sein. Oder auch die von deiner eigenen, umgezogenen Installation. So dass das - wahrscheinlich nicht gecachete - Backend was anderes anzeigt als das Frontend. Oder die Seite, die dir beim direkten Aufruf der Domain angezeigt wird, ist in deinem Browser-Cache. Ich weiss auch nicht, ob Plesk da irgendwelche unsichtbaren Backup-Kopien von seinen verwalteten Wordpress-Installationen anlegt. Aber falls ja, würde ich hoffen, dass die nicht einfach, ohne vorher zu fragen, wieder eingespielt werden. Da würde ich mir dann doch eine Meldung erhoffen, dass die Installation sich (ohne Zutun von Plesk) geändert hat, mit der Frage, ob man das wieder auf den gesicherten Originalzustand zurücksetzen möchte.

    Also ich weiss nur, dass ich 1-Click Installationen immer meide, sofern irgend möglich. Da habe ich auch bei einem anderen namhaften Webhoster aus Montabaur, der sich mittlerweile im Hosting-Bereich elektrisch aufgeladen hat :D , teils sehr üble Erfahrungen gemacht. Ich verlasse mich ungern auf Blackbox Software, auf die ich nur einen begrenzten Einfluss habe. Zumal wenn die manuelle Installation unproblematisch ist.

    Was meinst du mit "nach außen"? Das Zielverzeichnis /usr/bin ( ~/usr/bin) liegt innerhalb der chroot.


    Edit: Bzw. würde das dann tatsächlich so angezeigt werden?

    Code
    bash-5.0$ ls -l /bin
    lrwxrwxrwx 257 root root 7 Apr 19  2021 /bin -> usr/bin

    ALso bei mir ist das "Verzeichnis" /bin kein Verzeichnis, sondern eben ein symbolischer Link auf /usr/bin. Also nicht die einzelnen Dateien symlinken oder kopieren. Für eigene Binaries habe ich in einigen Webhostings /user/bin eingerichtet und in den Pfad aufgenommen.