Beiträge von Twindaddy

    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.

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

    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.

    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.

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

    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.

    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 habe genau das gleiche Problem (Let's Encrypt) und deshalb auch eine Supportanfrage lauten. Ich bekomme die LE-Zertifikate einfach nicht zum Browser. Dass LE in den zusätzlichen Services deaktiviert dargestellt wird, hatte ich bis jetzt noch gar nicht gesehen. Das Problem ist weiterhin nicht gelöst, nachdem ich auf Rückmeldung vom Support die Zuordnungen und Zertifikate einmal komplett gelöscht und neu habe ausstellen lassen. Es kommt immer nur das Plesk-Zertifikat.


    In Subdomains habe ich auch Probleme, css-Dateien zu laden. Hier ist es nginx, das mir auf vorhandene Dateien trotzdem ein 404 liefert, obwohl ich parametriert habe, dass alle Anfragen an Apache weitergeleitet werden. Auf dieses Ticket habe ich noch keine Antwort.


    Hilft Dir alles nicht, aber Du bist nicht allein ;)

    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