Posts by tab

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.

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.

Quote from 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?

Quote from 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.

Quote from aRaphael

Ist das denn für Serverhoarder ein Kriterium?

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

Quote from 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