Eure Erfahrungen mit der Konfiguration von Webhosting Paketen?

  • Hallo zusammen,

    ich habe gestern ein Webhosting 4000 SE gebucht und wollte, bevor ich meine Domains von Hosteurope umziehe, erst einmal ein paar Erfahrungen mit der Konfiguration anhand einer Domain machen, die ich als Spielwiese verwende. Auf dem Papier ist das Preis-/Feature-Verhältnis großartig, aber in den letzten 24 Stunden bin ich auch für Basisanforderungen auf so viele Probleme gestoßen, dass ich aktuell frage, ob sich der Aufwand lohnt. Meine Motivation war vor allem, auch mit einem günstigen Webhosting-Tarif node.js nutzen zu können. Das ist mir bis jetzt passiert:

    • Meine Domain wurde dem Produkt nicht korrekt zugeordnet. So war eine Einrichtung nicht möglich (mittlerweile behoben).
    • Ich muss - wenn ich Dateien über das Webinterface oder FTP hochlade - hinterher den Zugriff für alle ermöglichen, weil ich keinen Weg gefunden habe, diese Verzeichnisse / Dateien der Gruppe zuzuordnen, der die Service-Benutzer angehören. chown gibt aus auch per ssh nicht.
    • Ich habe mehrere Let's Encrypt-Zertifikate generieren lassen und sie sind auch - zumindest in den Dashboards angezeigt - korrekt zugeordnet. Die Seiten werden aber weiterhin mit einem Heimwerkerzertifikat von Plesk ausgeliefert. Support-Anfrage ist eröffnet.
    • Ich habe eine Subdomain erstellt, um ein aktuelles Roundcube zu installieren. Was immer ich dort einstelle, nginx findet in dem Verzeichnis der Subdomain bestimmte Dateitypen nicht (z.B. .css, .js). Es ist mir auch nicht gelungen (trotz Deaktivierung der Optionen in der Oberfläche), nginx dazu zu überreden, die Dateien nicht selbst auszuliefern. Das Verzeichnis mit roundcube 1:1 in die Hauptdomain kopiert funktioniert tadellos. Wenn ich Dateien anfrage, die wirklich nicht da sind, antwortet Apache mit einem 404, wenn ich aber eine vorhandene .css-Datei anfrage, antwortet nginx mit einem 404, egal, was ich in den Hosting-Einstellungen abwähle.

    Nachdem ich selbst mit einer einfachen Spielwiese nicht in der Lage bin, mit der Webhosting-Oberfläche, Basis-Dienste einzurichten, und ich eigentlich keinen (v)Server brauche, bin ich verunsichert, ob ich den Umzug mit bestehenden Domains versuchen soll. Funktionieren die oben genannten Aktionen bei Euch, ohne das Ihr den Support jedesmal bemühen müsst? Habe ich einfach nur eine Montagsinstallation erwischt und nächste Woche ist alles gut?


    Viele Grüße,

    Markus

  • Twindaddy

    Hat den Titel des Themas von „Eure Erfahrungen mit der Konfiguration von Webhosting Pakten, oder: wird es irgendwann besser?“ zu „Eure Erfahrungen mit der Konfiguration von Webhosting Paketen?“ geändert.
  • Ok, nach ein wenig stöbern und auch heute noch neu aufgetauchten Posts, kann ich mir dir Frage selbst beantworten.

    Noch läuft meine Entscheidungsphase, aber jede neue Domain tagelang mit dem Support zusammen einzurichten, gefällt auf Dauer weder mir noch dem Support ...

  • Ich kann deinen Frust verstehen, es scheint in den letzten Tagen vermehrt zu Problemen zu kommen. :(


    Ich kann soviel zu meinem Hosting (das letzte ist 2021 bestellt) sagen: all deine Punkte treffen bei mir nicht zu, Einrichtung klappte anstandslos. :)


    Hilft dir nur leider auch nicht wirklich weiter, wenn die neuen Hostings vermehrt Probleme bereiten....


    Drücke dir die Daumen. :)

  • Aktuell sind alle Punkte aus dem Eingangspost (außer der Gruppenzuordnung von Dateien, aber ist halt wohl einfach so) gelöst. Alle Supportanfragen wurden innerhalb eines Tages (< 24h) gelöst (:thumbup:), was sich aber bei mehreren nacheinander auftretenden Problemen immer noch lang anfühlt. Ich hoffe daher, dass der Umzug produktiver Domains ohne diese Probleme funktioniert.

  • Was meinst du mit der Gruppenzuordnung? Welcher Gruppe sind sie denn derzeit zugeordnet und welcher sollten sie deiner Meinung nach zugeordnet sein?

    Dass das einen Tag gedauert hat, ist bestimmt auch dem Umstand zu verdanken, dass die Menge an ähnlichen/gleichen Fehlermeldungen in den letzten Tage einfach eine nachhaltige Lösung braucht, denn wenn das weiterhin bei jedem neuen Webhosting passieren würde, könnte der Support/die Technik die Einzelprobleme gar nicht so schnell beheben wie neue wieder dazukommen. Ich hoffe, die Lage beruhigt sich damit an der Fehlerfront, denn sowas wie in den letzten Tagen ist sicher das Letzte, was netcup sehen will und wäre auf Dauer im Hinblick die Aussenwirkung auf potenzielle Neukunden wohl ein ziemlicher Supergau. Webhosting ist ein ziemlich umkämpfter Markt, da sollte man sich sowas nicht allzu oft erlauben.

  • Was meinst du mit der Gruppenzuordnung? Welcher Gruppe sind sie denn derzeit zugeordnet und welcher sollten sie deiner Meinung nach zugeordnet sein?

    Aus dem Gedächtnis ist der Webserver-User in der Gruppe psaserv, alles was ich hochlade erhält aber psacln. Damit der Service das sieht (oder im schlimmsten Fall gar schreiben können soll), muss ich das für die Welt öffnen. Da auf diesem chroot nur ich herumturne, ist das jedoch nichts, was mich besorgt, aber schön isses halt nicht.

  • Aus dem Gedächtnis ist der Webserver-User in der Gruppe psaserv, alles was ich hochlade erhält aber psacln. Damit der Service das sieht (oder im schlimmsten Fall gar schreiben können soll), muss ich das für die Welt öffnen.

    Der Webserver läuft eventuell mit psa*, aber die jeweiligen Scripts (z.B. PHP) sollten unter dem gleichen User wie auch die ganze SSH-Chroot-Umgebung laufen. Würde mich wundern, wenn das bei node.js & Co. anders ist. Somit reichen dort Schreibrechte für den Besitzer, die Gruppe oder gar die ganze Welt brauchen keine Schreibrechte.


    Was Du versuchen könntest: Lade die Inhalte einmal über SFTP (nicht FTPS!) hoch. Treten dann die gleichen Probleme auf? Wem gehören die Ordner und Dateien dann wirklich? (SSH: ls -la o.ä.)


    Dass man chown/chgrp nicht nutzen kann ist jedenfalls logisch. Unabhängig davon, dass das nur root darf, könnte man damit zu viel Schaden anrichten.


    Was immer ich dort einstelle, nginx findet in dem Verzeichnis der Subdomain bestimmte Dateitypen nicht (z.B. .css, .js).

    In welchem Ordner genau? Es gibt nämlich einige Forenthreads, dass man z.B. den /icons/ Ordner auf der obersten Ebene nicht nutzen kann, weil es sich dabei um ein globales Alias für die Autoindex-Icons des Apache-Webservers handelt.


    Es könnte aber auch sein, dass es sich in Wirklichkeit gar nicht um statische Dateien handelt und diese durch eine RewriteRule von einem PHP-Script ausgeliefert werden. In diesem Fall sollte es helfen, wenn man auf Nginx ganz verzichtet und nur den Apache werkeln lässt. (Siehe z.B. mein Screenshot hier.)

    "Wer nur noch Enten sieht, hat die Kontrolle über seine Server verloren." (Netzentenfund)

    Gefällt mir 1
  • Wie gesagt, Dateien und Verzeichnisse, gehören natürlich dem Benutzer, der so heißt, wie das Hosting-Paket. Die Gruppe ist psacln. Die Verzeichnisse, die initial durch die Skripte beim Anlegen einer Domain erstellt werden, gehören dem gleichen Benutzer, aber die Gruppe ist psaserv. Darauf hat der Webservice Zugriff, ohne das ich Rechte für public einräume. Für die von mir hochgeladenen Dateien und Verzeichnisse, muss den Zugriff aber auch für public freigeben. Das gefällt mir nicht, ist aber in meiner Konstellation kein Problem.


    Das Problem mit den .css- und .js-Dateien hat der Support gelöst, ohne das ich etwas geändert habe, oder sich irgendetwas für mich Sichtbares verändert hätte. Die betroffenen Dateien waren definitiv statisch (z.B. Stylesheets, die zu Roundcube-Skins gehörten). Da war sicher in der generierten Konfiguration etwas kaputt. Jetzt ist alles in Ordnung, und ich hoffe, der Fix war nachhaltig, so dass mich bei den nächsten Domains nicht das gleiche Schicksal ereilt.

  • Was Du versuchen könntest: Lade die Inhalte einmal über SFTP (nicht FTPS!) hoch. Treten dann die gleichen Probleme auf? Wem gehören die Ordner und Dateien dann wirklich? (SSH: ls -la o.ä.)

    PS: bei der Nutzung von SFTP und Weboberfläche besteht diesbezüglich kein Unterschied. Die Gruppe ist immer pascln, was auch wenig verwunderlich ist, wenn der gleiche Benutzer genutzt wird und chgrp eben nicht am Start ist.

  • Also ich kann aus Erfahrung sagen, wenn ich das Dokumentenstammverzeichnis selbst anlege, bevor ich es als Dokumentenstamm für die Domain eintrage, dann gehört das Verzeichnis auch danach noch meinem User und die Gruppe bleibt psacln. Funktioniert trotzdem, weil PHP unter meinem User läuft und somit überall in den von mir angelegten Verzeichnissen schreiben darf und der Webserver selbst eigentlich nichts schreibt - außer seinen Logs vielleicht, aber die gehen ja eh in ein ganz anderes Verzeichnis, wo er auch schreiben darf. Will sagen, ich muss in einer vergleichbaren Konstellation zu deiner nichts extra freigeben.

  • Für die von mir hochgeladenen Dateien und Verzeichnisse, muss den Zugriff aber auch für public freigeben.

    Das sollte aber sowieso standardmäßig der Fall sein, also kein manueller Eingriff notwendig sein?


    (Ordnerrechte: 0755; Dateirechte: 0644)


    Prinzipiell braucht der Webserver aber sowieso nur Zugriff auf Dateien, die er selbst einlesen muss. D.h. für statische Dateien oder z.B. um die Existenz von PHP-Dateien zu verifizieren, bevor sie über FPM ausgeführt werden. Irgendwelche Includes-Ordner o.ä. müssen somit nicht für jeden lesbar sein. Die könnte man sogar als 0700 chmod'en bzw. die Dateien als 0600.


    (Ich beziehe mich mangels Erfahrung jetzt rein auf PHP. Bei node.js könnte es Unterschiede geben.)

    "Wer nur noch Enten sieht, hat die Kontrolle über seine Server verloren." (Netzentenfund)

  • Um zur ursprünglichen Frage auch noch etwas Konstruktives beizutragen…

    Nachdem ich selbst mit einer einfachen Spielwiese nicht in der Lage bin, mit der Webhosting-Oberfläche, Basis-Dienste einzurichten, und ich eigentlich keinen (v)Server brauche, bin ich verunsichert, ob ich den Umzug mit bestehenden Domains versuchen soll. Funktionieren die oben genannten Aktionen bei Euch, ohne das Ihr den Support jedesmal bemühen müsst? Habe ich einfach nur eine Montagsinstallation erwischt und nächste Woche ist alles gut?

    Ich habe das Webhosting nur knapp zwei Jahre produktiv verwendet, meine Erfahrung damit: Wenn es mal läuft, dann läuft es auch. Klar, Pech kann man immer haben und irgendwelche Fehler könnten jederzeit auftreten. Aber es ist wohl im Interesse von netcup, dass Probleme nicht zum Standard werden.


    Weil Du das Thema (v)Server ansprichst: Das ist schon eher der Knackpunkt. Wenn man das notwendige Wissen für einen selbst administrierten (v)Server hat, fühlt man sich bei einem Webhosting, egal bei welchem Anbieter, schnell eingeschränkt. Im Endeffekt ist Shared Webhosting immer ein Kompromiss, den man eingehen muss. Wenn man dazu nicht bereit ist, sollte man halt doch lieber einen (v)Server verwenden. Dort kann man alles einrichten, wie man es möchte, mit dem großen Nachteil, dass es mehr (Zeit-) Aufwand ist.

    "Wer nur noch Enten sieht, hat die Kontrolle über seine Server verloren." (Netzentenfund)

    Einmal editiert, zuletzt von KB19 ()

  • Ich habe das jetzt noch einmal getestet, und ja, die Dateien werden im Standard mit 644 angelegt. Als ich zu Beginn mit der Weboberfläche gearbeitet habe, war es aber definitiv 640, obwohl ich nicht mit umask herumgespielt habe. Da musste ich dann rekursiv alles ändern. In meinem Anwendungsfall kann ich mit 644 gut leben, also ist jetzt alles gut. Manchmal zweifelt man ja auch an sich selbst, ob man das wirklich gesehen hat, aber die ersten html-Dateien, die ich hochgeladen hatte, wurden definitiv nicht ausgeliefert. Ich kann mich allerdings nicht bewusst erinnern, ob ich ein 403 oder 404 als Antwort bekommen habe.


    php und apache / nginx scheinen von unterschiedlichen Benutzern ausgeführt zu werden, denn .php-Dateien mit hostingxxxxx/psacln, und 640 werden problemlos gefunden/verwendet, statische html-files jedoch nicht, da braucht's 644. Aber wenn der Default jetzt stimmt ist ja alles in Ordnung.


    Danke für die Anregungen.

  • Weil Du das Thema (v)Server ansprichst: Das ist schon eher der Knackpunkt. Wenn man das notwendige Wissen für einen selbst administrierten (v)Server hat, fühlt man sich bei einem Webhosting, egal bei welchem Anbieter, schnell eingeschränkt. Im Endeffekt ist Shared Webhosting immer ein Kompromiss, den man eingehen muss. Wenn man dazu nicht bereit ist, sollte man halt doch lieber einen (v)Server verwenden. Dort kann man alles einrichten, wie man es möchte, mit dem großen Nachteil, dass es mehr (Zeit-) Aufwand ist.

    Ich hatte jahrelang einen vServer bei hosteurope und bin dann doch wieder ein einen Hosting-Tarif gewechselt. Natürlich ist es super, wenn man alles selbst in der Hand hat und potenziell auch alles machen kann. Aber ich mache einfach zu wenig damit, als dass sich das lohnen würde und man muss sich halt kümmern. Muss man beim Hosting sicher auch, aber beim eigenen Server muss man sich eben so richtig kümmern, Schließlich hat man dann ja auch eine Verantwortung, dass die eigene Maschine nicht plötzlich randaliert, plündert und brandschatzt ...

  • Weil Du das Thema (v)Server ansprichst: Das ist schon eher der Knackpunkt. Wenn man das notwendige Wissen für einen selbst administrierten (v)Server hat, fühlt man sich bei einem Webhosting, egal bei welchem Anbieter, schnell eingeschränkt. Im Endeffekt ist Shared Webhosting immer ein Kompromiss, den man eingehen muss. Wenn man dazu nicht bereit ist, sollte man halt doch lieber einen (v)Server verwenden. Dort kann man alles einrichten, wie man es möchte, mit dem großen Nachteil, dass es mehr (Zeit-) Aufwand ist.

    Ich stimme dir zu, wenn du wirklich gar keine Kompromisse eingehen kannst. Ansonsten sind Shared Hostings durchaus sehr unterschiedlich, so dass man zwar überall Kompromisse machen muss, aber eben nicht überall die selben. Man kann sich also das Webhosting danach aussuchen, wo man mit den zu machenden Kompromissen am besten leben kann. Das mag auch von Projekt zu Projekt unterschiedlich ausfallen. Beispiel open_basedir, ich habe auch ein Shared Webhosting, bei dem open_basedir nicht aktiv ist. Da freut sich die Nextcloud und eigentlich auch alle anderen PHP-basierten Applikationen. Und die einzigen meiner Webhostings mit Plesk sind die bei netcup. Als ich die Panels hier zum ersten Mal gesehen habe, habe ich erst mal ganz schön geschluckt. Dafür kann ich bei einem Webhosting z.B. zwar die PHP-Version wählen, aber die gilt dann für alle Projekte in dem Webhosting. Manche setzen auf MariaDB, andere auf MySQL 8. Und so weiter.

  • […] und man muss sich halt kümmern. Muss man beim Hosting sicher auch, aber beim eigenen Server muss man sich eben so richtig kümmern […]

    Treffend am Punkt gebracht. :)


    Beim Webhosting muss man sich wenigstens "nur" um die installierten Anwendungen kümmern, und das kann bekanntlich schon enorm zeitraubend sein. ^^


    Ich stimme dir zu, wenn du wirklich gar keine Kompromisse eingehen kannst. Ansonsten sind Shared Hostings durchaus sehr unterschiedlich, so dass man zwar überall Kompromisse machen muss, aber eben nicht überall die selben.

    Mein persönliches Problem ist halt, dass ich es sehr genieße, meine eigenen Nginx/PHP/sonstwas Konfigurationen verwenden zu können und bei Bedarf root zu sein. Wenn ich dann zusätzlich nicht lange in einem Webinterface rumklicken muss, ist es natürlich noch besser.


    Ich brauche meine Webserver aber sowieso für einige Dinge, die ich niemals auf einem Shared Server laufen lassen könnte. Der wirkliche Grund gegen Webhosting ist bei mir also eigentlich nicht zwangsläufig der Komfort: Wenn ich das sowieso schon selbst betreiben muss, kommt es auf einen vHost (oder vServer) mehr oder weniger auch nicht mehr an. :saint:


    Aber wir schweifen langsam ins Offtopic ab…

    "Wer nur noch Enten sieht, hat die Kontrolle über seine Server verloren." (Netzentenfund)

    Einmal editiert, zuletzt von KB19 ()

  • So, ich habe heute zwei produktive Domains umgezogen (möglicherweise etwas optimistisch vor dem Wochenende ;)), aber diesmal lief alles glatt. Nur der Umzug von Mail-Postfächern ist - sagen wir mal - suboptimal. Dass man die Adressen erst anlegen und umziehen kann, wenn die Domain dem Paket zugeordnet ist, sorgt doch für unnötige Hektik (ich hatte die TTL auf 10 Minuten gesetzt). Mit mehr Adressen wäre das für mich kein vernünftig nutzbarer Weg.


    Irgendwo hier im Forum hatte ich gelesen, dass man die Postfächer doch vorher einrichten kann, wenn man die Domain erst als externe Domain zuordnen würde und dann auch die Postfächer erzeugen könnte. Nach meinen ersten Erlebnissen mit den Konfigurationsskripten, habe ich mich das aber nicht getraut 8o.


    Lange Rede, kurzer Sinn: Die Konfiguration funktioniert jetzt einwandfrei, hat aber ein paar architektonische Schwächen. Bei dem Preis und für das, was ich tue, kann man das aber in Kauf nehmen.

  • Neu erstellte Beiträge unterliegen der Moderation und werden erst sichtbar, wenn sie durch einen Moderator geprüft und freigeschaltet wurden.

    Die letzte Antwort auf dieses Thema liegt mehr als 365 Tage zurück. Das Thema ist womöglich bereits veraltet. Bitte erstellen Sie ggf. ein neues Thema.

    • :)
    • :(
    • ;)
    • :P
    • ^^
    • :D
    • ;(
    • X(
    • :*
    • :|
    • 8o
    • =O
    • <X
    • ||
    • :/
    • :S
    • X/
    • 8)
    • ?(
    • :huh:
    • :rolleyes:
    • :love:
    • :pinch:
    • 8|
    • :cursing:
    • :wacko:
    • :thumbdown:
    • :thumbup:
    • :sleeping:
    • :whistling:
    • :evil:
    • :saint:
    • <3
    • :!:
    • :?:
    Maximale Anzahl an Dateianhängen: 10
    Maximale Dateigröße: 1 MB
    Erlaubte Dateiendungen: bmp, gif, jpeg, jpg, pdf, png, txt, zip