Beiträge von tab

Dem Support melden, mehr wirst du nicht machen können.

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.

Zitat von Olivetti

ja, WH2000SE (04.09.2019).

die sind eben handcrafted by netcup.

das wurde ja irgendwann generell mal geändert. insofern würde ich sagen: es hängt vom alter ab.

Vom Alter des Hosts oder vom Alter desjenigen, der das System installiert hat?

Zitat von Olivetti

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 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 , 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?

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.

Also in einem eher unbenutzten Webhosting von mir, deshalb denke ich mal, das ist der reine Standardinhalt, sieht ~/bin so aus:

bash-5.0$ ls bin/
basename  cut               gzip       php        sha512sum   vi
bash      date              head       php.os     sleep       vim
bin       diff              id         printf     sort        wc
bunzip2   dirname           less       pwd        ssh         wget
bzcat     du                ln         readlink   ssh-keygen  which
bzdiff    env               ls         rm         tac         whoami
bzgrep    false             md5sum     rmdir      tail        xargs
bzip2     file              mkdir      scp        tar         zcat
bzmore    find              mktemp     sed        tee         zdiff
cat       git               more       sftp       touch       zgrep
chmod     git-receive-pack  mv         sh         tr          zip
clear     git-upload-pack   mysql      sha1sum    true        zless
convert   grep              mysqldump  sha224sum  uname       zmore
cp        groups            nano       sha256sum  uniq
curl      gunzip            patch      sha384sum  unzip

Edit: /bin ist letztlich auch nur ein symbolischer Link auf /usr/bin

Ich weiss es nicht absolut sicher, aber es wird auch funktionieren, wenn die Datenbank gar nicht zugewiesen ist. Außer vielleicht, wenn man das Wordpress-Toolkit benutzt, da mag es eine Rolle spielen, muss aber nicht so sein. Da ich kein Wordpress nutze ist das Wordpress Toolkit nicht unbedingt meine Expertise . Wenn Plesk das offenbar nach einiger Zeit selbst regelt und es dann auch funktioniert, ist ja alles gut. Ich habe eine meiner Datenbanken in einem Webhosting einem anderen User, sogar auf einem anderen Webhostingserver, zur Verfügung gestellt. Er kann sie problemlos nutzen, obwohl ich die Datenbank natürlich nicht seiner Domain zuordnen kann. Ich muss dann allerdings den Datenbankzugriff für seine IP oder für beliebige externe IPs freigeben.

Wie sieht denn deine Ordnerstruktur aus? Hat jede Subdomain einen eigenen Ordner, der nicht im Ordner der Hauptdomain oder einer anderen Subdomain liegt? Ist bei allen Subdomains der Dokumentenstamm auf das entsprechende Unterverzeichnis gesetzt? Davon gehe ich mal aus, sonst würden auch andere Dateien als PHP nicht gefunden. Es liegt auch keine .htaccess in einem übergeordneten Verzeichnis? Dass es mit nginx funktioniert und mit Apache nicht, deutet eigentlich schon ein wenig auf ein Problem mit einer .htaccess hin. NGinX interessiert sich eben im Gegensatz zu Apache nicht für diese Dateien, ignoriert sie also einfach. Wenn da also irgendwas unpassendes drinsteht in der .htaccess, dann stört das nur den Apache. Ganz besonders, wenn vielleicht in einem Rewrite nur PHP-Dateien umgeschrieben werden.

Das einzige was ich mir denken könnte, vielleicht interpretiert das der Parser als 1000er Punkte. Vielleicht hilft es, die irgendwie auszuschalten beim Integer Zahlenformat. Keine Ahnung ... aber davon jede Menge.

Edit: Gerade mal getestet in meinem Libreoffice, ich kann es erst einmal nicht nachvollziehen, die IPs werden als Text importiert.

Zitat von aRaphael

Ist das denn für Serverhoarder ein Kriterium?

Eigentlich nicht, es handelt sich dabei um ein reines Sammlerobjekt .

Zitat von AutoYaST

Mich würde ja das Hostsystem interessieren, ernährt sich vermutlich vollständig von Backports.

Besser als von Backdoors.

Also der Aufruf mit einem einfach kopierten zsh-Binary endet bei mir im Webhosting so:

bash-4.4$ zsh --version
zsh: error while loading shared libraries: libcap.so.2: cannot open shared object file: No such file or directory

Wie sollen wir das klären? Wir kennen ja noch nicht mal die Domain und selbst wenn ...

Ist es eine Inklusivdomain oder eine Zusatzdomain? Was hast du im DNS eingetragen? Richtige Syntax, also bei Host '@' für die Domain selbst , '*' für Wildcard Subdomains', 'sub' für sub.deinedomain.tld? Also jedenfalls nicht 'sub.deinedomain.tld' oder 'deinedomain.tld als Host eintragen, sonst gilt der Record für für deinedomain.tld.deinedomain.tld bzw sub.deinedomain.tld.deinedomain.tld. Dann kannst du lange warten bis das für (sub.)deinedomain.tld greift . Wenn die korrekten DNS-Einträge nach mehreren Wochen immer noch nicht greifen, dann kann dir nur der Support helfen. Und nach so langer Zeit wird sich der Support da schwerlich mit der o.g. Aussage rausreden können. Ansonsten musst du das Ticket halt eskalieren.