Ist das denn im Shared Hosting hier möglich, das auf den DocRoot zu begrenzen?
Ja, es gibt zwei Varianten. Im Wesentlichen unterscheiden sie sich darin, dass einmal WEBSPACEROOT freigegeben ist und bei der anderen DOCROOT. Leider gibt es nichts dazwischen - was ich gut brauchen könnte z.B. für Symfony-Anwendungen.
Kommt m.E. auf die PHP-Einstellungen an, insbesondere open_basedir. Wenn hier die Variante mit {WEBSPACEROOT} am Anfang gewählt ist, dann ganz sicher ja.
Edit: Wenn die Installationen parallel in Unterordnern liegen, die auch in der URL auftauchen, dann natürlich mit Sicherheit auch.
Edit2: Das bezieht sich nur auf "auf PHP-Basis". Wenn dir da z.B. ein Binary untergejubelt wird oder sonst was ausführbares, die sind von den PHP-Einstellungen nicht betroffen und können grundsätzlich auf alle deine Dateien und Verzeichnisse zugreifen.
Nein, musste ich nicht teilen.
Ich werde dennoch die Root-Zugangsdaten ändern.
Root-Zugangsdaten? Dann ist das also kein Webhosting-Paket, sondern ein Rootserver/VPS?
Stelle mir gerade eine inkontinente Datei vor 
Zumindest würde ich mal deinen PC gründlich scannen lassen. Wenn da entsprechende Schadsoftware sich installiert hat, dann greift die deine gesetzten Passwörter ab und dann ist es klar, dass die Wordpress-Installationen sehr schnell wieder gehackt sind. Einen Schutz gegen Login mit Username und Passwort gibts da nicht? Zwei-Faktor Authentifizierung?
Würde ich mal den Support fragen was da los ist. Ich habe jetzt zwar kein brandneues Paket von September 2019, aber in meinem Webhosting 1000 von Ostern diesen Jahres und dem Webhosting 2000 SE Plus vom Juni diesen Jahres ist er jeweils dabei. Allerdings nur in der Plesk Onyx Übersicht sichtbar, nicht auf der Übersichtsseite des Hostingpakets. Ist im Paket schon eine Domain drin? Ohne Domain gibt es keinen direkten Link zur Plesk Onyx Übersicht bzw Websites/Domains. Da klicke ich erst einen anderen Link, z.B Dateimanager, dann habe ich links den Link zu Websites&Domains und da sehe ich dann auch den Presence Builder.
Womit wir wieder beim Thema wären. Der "VPS 500 G8" um 4,29€ ist eigentlich ein "VPS 500 G8 1 EUR Rabatt" und somit ein anderes Produkt, auf das man über das CCP nicht upgraden kann. Auch wenn der Unterschied der beiden Produkte auch hier nur im Namenszusatz "1 EUR Rabatt" und eben dem um 1€ niedrigeren Preis besteht.
Ich wusste gar nicht, das Huawei eine "öffentliche" Cloud (a la AWS/...) hat...
<sarcasm>Muss man da überhaupt noch Backups anlegen?</sarcasm>
Nein, kann man notfalls von der NSA anfordern 
Horde, bzw IMP, kann es wohl auch. https://www.horde.org/apps/imp/
Was mich aber generell noch immer wundert ist, dass ich ja einen Wildcard A Record habe und der vom MX Record "ausgehebelt" wird. Ich sehe darin den Sinn nicht.
Ob es Sinn macht oder nicht, sei mal dahingestellt. Es ist jedenfalls so, dass Wildcard records grundsätzlich nur für nicht existente (Sub-)Domains gelten. Eine Wildcard ist hier etwas anderes als aus anderen Bereichen gewohnt. Existiert eine angefragte Subdomain, dann gibt der DNS-Server auf Anfrage die passenden Einträge hierzu zurück. Existiert sie nicht, dann (und nur dann) schaut der DNS-Server, ob es passende Wildcards gibt und erzeugt ggf einen entsprechenden Resource Record. Eine Subdomain existiert, wenn es für sie oder mindestens eine ihrer Subdomains einen DNS-Eintrag gibt.
Das heißt dann halt in der Praxis, dass der Wildcard A oder AAAA oder was auch immer Record gilt, solange keinerlei Eintrag für die Subdomain existiert. Hinzufügen eines MX Records für eine Subdomain macht die Subdomain existent, womit dann die Wildcard-Records nicht mehr für sie gelten.
Da musst du mal die relevanten RFCs für das DNS konsultieren. Sind zwar alles andere als klar, aber ich fürchte das Verhalten ist so gewollt. Jedenfalls gibt es ein Beispiel, bei dem ein Wildcard MX record gesetzt ist und ein A record für eine bestimmte Subdomain. Da wird darauf hingewiesen, dass der MX record für diese Subdomain damit nicht mehr funktioniert. Wahrscheinlich gilt das dann auch anders herum für einen Wildcard A record und einen MX für eine Subdomain.
Weiterhin ist spezifiziert, dass ein Wildcard A record explizit NICHT für Subdomains einer Wildcard Subdomain gilt, also in deinem Beispiel gilt der Wildcard A record für example.com von vornherein explizit NICHT für http://www.xy.example.com.
Ich fürchte das wird nicht gehen. Das ist ein Webhosting, kein Root Server. Die zwei open_basedir Settings die Du ja schon gefunden hast sind die einzig verfügbaren. Wenn beide nicht funktionieren, kannst Du nur noch schauen, ob man bei den Erweiterungen etwas einstellen kann, was sie weniger besitzergreifend macht.
Ja, ist schon extrem. Und war ja nicht mal Ostern, Weihnachten, Neujahr oder Black Friday
Hier bei Netcup geht das im Webhosting eh schon automatisch mit der Verlängerung. Bei all meinen anderen Hostern mittlerweile auch. Bei einem Managed Server würde ich eigentlich auch davon ausgehen. Und wer einen Rootserver mietet, der sollte mit der Automatisierung kein unlösbares Problem haben, sonst bringt ihm ein SSL-Zertifikat auch nichts. Außer einer gefühlten Sicherheit, die dann im Endeffekt wahrscheinlich nicht vorhanden ist, weil der ganze Server nicht sicher ist.
Warum kann das nicht sein? Es zählt ja theoretisch schon jeder potenzielle Interessent der für 3 Sekunden einen VPS testet als Kunde. Was meinst du wieviel dieser Karteileichen Systeme wie Payback oder ebay haben. Braucht ja jeder Kunde eine eigene ID, ob und wie lange die genutzt wird ist irrelevant.
Wir haben hier in China mal nen lustiges System gehabt. Da wurden die Nummern random vergeben. Es wurde lediglich einmal gecheckt, ob die Nummer existiert und dann random eine neue vergeben. Resultierte dann in insgesamt 8 doppelten Kundennummern 😂😂 Der Kollege der es damals gefixt hat, fand das zumindest sehr amüsant 🤣
Möglich wärs wohl schon, wenn das z.B. gerade ein Aktionszeitraum war. Ansonsten wäre es aber schon ungewöhnlich. Ich bin seit Juni 2018 Kunde und habe eine Kundennummer 76xxx. Man fragt such dann aber schon, warum das in den ersten 16 Jahren dann so langsam ging .
Welchen Reseller Tarif hast Du denn? Und wieviele "Kunden" bzw Websites hast du darin am laufen? Höre ich jedenfalls sehr gern, dass es flott läuft. Wobei die EiWoMiSau vielleicht nicht unbedingt der geeignete Vergleich ist, die hat keine garantierten Ressourcen. Kommt wohl auch total drauf an, was in dem Hosting laufen soll. Statische Webseiten, die so gut wie keine Ressourcen brauchen außer vielleicht Bandbreite im Netzwerk? Statische Dateien liefern nginx und Apache bequem in großer Zahl aus und langweilen sich noch dabei. Aber ein CMS hat halt andere Anforderungen., da braucht jeder Request der nicht komplett aus dem Cache kommt deutlich mehr CPU-Zeit und RAM.
Dass das Wordpress-Toolkit ein anderes, besseres ist als beim Webhostingtarif ist schon mal eine gute Info und gibt zumindest Hoffnung, dass auch andere Dinge trotz des selben Namens anders/besser sind.
Über CPU-Ressourcen erfährt man leider gar nichts, weder beim normalen Webhosting noch beim Reseller-Webhosting. Das ist man letztlich auf eigene Tests angewiesen und das ist beim Reseller-Hosting relativ schwierig, weil man in der Regel nicht mal eben 10 stark frequentierte Websites im Schrank liegen hat, die man mal eben zum Test in das Hosting stellen kann. Ok, es gibt Tools, die Last erzeugen in Form von Requests, da muss man dann halt mal die Grenzen ausloten was noch geht und wann es schwierig wird. Real ist das dann immer noch nicht, eigentlich müsste man das dann parallel mit der gesamten Cloud machen um vernünftige Werte zu bekommen.
Beim RAM hat man wenigstens einen Anhaltspunkt, den Garantiewert. Der "echte" Wert dürfte im Mittel höher liegen, auch die Tarife ohne garantiertes RAM laufen ja irgendwie, also muss da schon eine Reserve da sein, die bei Bedarf vergeben werden kann, nach welchem Algorithmus auch immer. Geht man mangels belastbarer Daten von den Garantiewerten aus, dann hat ein Webhosting 8000 immerhin die Hälfte der (garantierten) RAM-Ressourcen des größten Reseller-Webhostings und eigentlich insgesamt mehr Ressourcen, beim RAM gleich viel, als der Reseller 4000.
Wenn das die ganze Wahrheit ist, dann zahlt man den Rest des Preises für die Möglichkeit, als Reseller aufzutreten. Das könnte ich auch jederzeit bequem so akzeptieren, aber es wäre dann jedenfalls relativ sinnlos, nur für sich selbst so ein Resellerhosting zu benutzen. Gleiche Ressourcen zum doppelten Preis. Als Reseller kann es schon Sinn machen.
irgendwie die Apokalypse:
https://www.chip.de/news/Gut-f…ders-macht_173186929.html
welches Problem existiert hier eigentlich?
ich hätt eher Sorgen, daß meine Geldbörse zu sehr kupferhaltig würde;
Keine Ahnung welches Problem da gesehen wird. Das machen die (zumindest) beim Aldi schon solange ich mich erinnern kann. Wenn man da mal mitstoppen würde, dann würde man wohl feststellen, dass Barzahlung tendenziell immer noch am schnellsten funktioniert.
Wenn ich eine Domain hier registriere, sei es Inklusiv- oder Zusatzdomain, dann kann ich in der Regel auch quasi sofort damit arbeiten. Jedenfalls bis ich dann das CMS aufgesetzt habe, Datenbank erzeugt, PHP-Einstellungen und Hosting-Einstellungen gemacht usw, ist die Domain bereits für mich erreichbar. Was wohl nicht heissen wird, dass das auch für alle anderen auf der Welt gilt. Jedenfalls habe ich da noch nie drauf warten müssen. Anderswo allerdings auch nicht. Keine Ahnung warum es bei einer neuen Domain so viel schneller geht. Bis die neue Domain dann bei Google auftaucht, das kann dann entsprechend dauern, da gehen Tage ins Land trotz Webmaster Tools. Meinen obigen Beitrag (#31) habe ich übrigens geschrieben ohne den unmittelbar davorstehenden (#30) mitbekommen zu haben, er bezieht sich also explizit NICHT darauf.
Sowas geht ja auch heutzutage eigentlich gar nimmer. Wenn der US-Präsi seinen neuesten Hirnfurz twittert oder irgendein "Influencer" sein Frühstück per Youtube veröffentlicht, dann weiss es 5 Minuten später die ganze Welt. Aber wenn die wichtigste Domain von allen - nämlich meine - umzieht, dann dauert das bis zu 48 Stunden. Rauchzeichen sind schneller. Technik aus dem 20. Jahrhundert halt.
