Neue Produktsparte: Cloud-Webhosting Reselling

  • Aktueller Stand ist übrigens, nach einigem Hin und her, dass ein Netcup Mitarbeiter dann zugegegeben hat, dass es nicht normal ist, dass der Pfad als nicht beschreibbar erkannt wird und auch, dass ich den Pfad über Plex manuell ändern können müsste (die Option wird mir auch gegeben, aber sie greift nicht). Darauf hin hat sich dann noch einmal ein anderer Mitarbeiter von Netcup gemeldet und mitgeteilt, dass das Verhalten so normal sei. Angeblich werden Sessions geschrieben, dass php den Pfad als nicht beschreibbar erkennt ist offensichtlich auch "normal" und den Pfad manuell zu ändern sei für Reseller nicht vorgesehen.


    Zusammenfassend: Es funktioniert nach wie vor nichts, der Support macht einen inkompetenten Eindruck und widerspricht sich selber.

  • Zusammenfassend: Es funktioniert nach wie vor nichts, der Support macht einen inkompetenten Eindruck und widerspricht sich selber.

    Das ist sehr schade das der Support hier anscheinend 2 komplett unterschiedliche Aussagen getroffen hat. Ich denke für solche Fälle ist die Beschwerdestelle von netcup der richtige Weg (der Link befindet sich am unteren Ende in jeder gesendeten Mail vom Support).

  • Guten Morgen,


    Lucan es tut mir Leid das Sie mit unserem neuen Produkt so unzufrieden sind. Ich habe mir aufgrund Ihrer Schilderungen hier im Forum Ihr Ticket angeschaut. Eine Beschwerde konnte ich nicht finden. Wann haben Sie diese aufgegeben?


    Das Ticket ist in Bearbeitung. Wir konnten einige Ihrer Fragen bereits lösen. Bzgl. des Session-Save-Path waren wir denke ich recht aktiv. Wir sind bemüht Fehler auf unserer Seite auszuschließen. Bislang konnten wir das von Ihnen geschilderte Problem noch nicht nachstellen. Wir haben Ihnen dazu sogar ein beispielhaftes Script zukommen lassen. Unsere Techniker sind dabei. Sollte ein Fehler auf unserer Seite vorliegen, werden wir diesen selbstverständlich zeitnah beheben. Bitte geben Sie uns die dafür erforderliche Zeit.


    Mit freundlichen Grüßen


    Felix Preuß

  • Hallo Herr Preuß,


    danke für die Rückmeldung.

    Quote

    Lucan es tut mir Leid das Sie mit unserem neuen Produkt so unzufrieden sind. Ich habe mir aufgrund Ihrer Schilderungen hier im Forum Ihr Ticket angeschaut. Eine Beschwerde konnte ich nicht finden. Wann haben Sie diese aufgegeben?

    am 03.10.2019 um 10:22 - per mail an beschwerdestelle@netcup.de. Ich habe diese direkt per Mail dorthin gesendet, da bei mir kein Link bei den Mails des Supports angehangen wird / wurde. Liegt ggf. daran, dass ich mein "Ticket" als Antwort auf die Bestellbestätigung "eröffnet" habe anstatt dies über das CCP zu tun.



    Quote

    Das Ticket ist in Bearbeitung. Wir konnten einige Ihrer Fragen bereits lösen. Bzgl. des Session-Save-Path waren wir denke ich recht aktiv. Wir sind bemüht Fehler auf unserer Seite auszuschließen. Bislang konnten wir das von Ihnen geschilderte Problem noch nicht nachstellen. Wir haben Ihnen dazu sogar ein beispielhaftes Script zukommen lassen. Unsere Techniker sind dabei. Sollte ein Fehler auf unserer Seite vorliegen, werden wir diesen selbstverständlich zeitnah beheben. Bitte geben Sie uns die dafür erforderliche Zeit.

    Gelöst wurde eigentlich noch nichts, es wurden lediglich Fragen beantwortet (u.a. wie DNS Einstellungen zu setzen sind - es wird leider nirgends erwähnt ob z.B. der Mail-Server gesondert läuft oder ob alles die gleiche IP-Adresse hat)


    Am 03.10 um 19:38 habe ich zum Ändern des Session Pfades (nachdem es erneut angesprochen habe folgende Aussage erhalten)

    Quote

    Wir werden dies nochmals genau prüfen. Es sollte möglich sein, den session_path aus Plesk zu ändern. Ich kann sehen, dass dies in Ihrem Fall nicht erfolreich ist. Wir werden überprüfen, warum dies so ist


    Einen Tag später (4.10 17:20) (ohne weitere Rückmeldung meinerseits) gab es dazu diese Aussage:

    Quote

    Eine Änderung des Pfad per Plesk

    funktioniert generell nicht auf Resellerebene da dieser in die globale php.ini geschrieben wird.



    Zu dem Problem mit den Sessions wurde am 03.10 in der gleichen Mail um 19:38 auch erstmals "zugegeben", dass das Verhalten mit dem Pfad nicht korrekt ist.

    Quote

    Der derzeitige Session-Pfad ist beschreibbar, ich sehe darin auch Session-Daten von Ihnen. Das von mir erweiterte Skript zeigt auch auf, dass eine Session erstellt und bearbeitet werden kann, ansonsten wäre ein sich pro HTTP-Request erhöhender Zähler auch technisch nicht möglich. Dennoch kann ich auch sehen, dass PHP den Pfad als nicht beschreibbar ansieht, was zwar für das Erstellen von Sessions keine Schwierigkeiten auslöst, aber dennoch inkorrekt ist. Auch das werden wir nochmals prüfen


    EInen Tag später, ebenfalls in der gleichen Mail von 17:20 am 04.10:


    Das aber etwas schief läuft wurde bereits bestätigt.


    Aktuell liegt dort ein Script, welches wie folgt aussieht:


    Quote

    Der obere Part zum Checken ob das Verzeichniss beschreibbar ist kommt dabei von mir, der untere von ihren Kollegen.

    Es kann unter https://2x9.eu/session_check.php eingesehen werden.

    Dabei ist ganz klar, dass etwas mit dem Pfad nicht stimmt, da er von php mit einer simplen Abfrage als nicht beschreibbar erkannt wird.

    In der Tat wird aber wohl etwas in die Sessions geschrieben. Fakt ist aber, dass ein Login bei sämtlichen Scripten die ich getestet habe nicht möglich war. Erst durch das weitere Debuggen bin ich auf den Fehler aufmerksam geworden. Getestet wurden u.a. Nextcloud und Pydio. Um den Fehler auf Scriptseite auszuschließen habe ich dann den Zweizeiler php zur Validierung hochgeladen und auch dem Support zukommen lassen.



    Als session.save_path ist "/tmp/" in Plesk gesetzt. Was ankommt, kann man hier sehen: https://2x9.eu/test.php

  • kann ich so nur bestätigen, gleiches Problem mit dem Session-Pfad und somit nicht benutzbar. Auch wird FPM nicht unterstützt, was ich persönlich nicht optimal finde.

    Da ich meinen Beitrag nicht mehr bearbeiten kann, das noch als Anmerkung; Ich bin ja nicht der einzige Kunde mit dem Problem.

  • Lucan vielen Dank für Ihre Rückmeldung!


    Was mir gerade noch eingefallen ist: Haben Sie einen passenden Wert für "open_basedir" gesetzt?


    beschwerdestelle@netcup.de kann nicht direkt kontaktiert werden. Wir brauchen dazu immer ein originales Ticket. Bitte eröffnen Sie ein solches über Ihren Account im CCP oder via Mail an mail@netcup.de .


    Der Vorgang ist weiterhin in Bearbeitung.



    Mit freundlichen Grüßen


    Felix Preuß

  • Hallo Herr Preuß,


    vielen Dank für ihre Rückmeldung.


    Quote

    beschwerdestelle@netcup.de kann nicht direkt kontaktiert werden. Wir brauchen dazu immer ein originales Ticket. Bitte eröffnen Sie ein solches über Ihren Account im CCP oder via Mail an mail@netcup.de .

    Gut zu wissen, ggf. sollte aber hier ein Autoresponder o.ä. eingeführt werden - ich habe so nämlich gar keine Rückmeldung erhalten.


    Quote

    Was mir gerade noch eingefallen ist: Haben Sie einen passenden Wert für "open_basedir" gesetzt

    Auf den Gedanken hätte ich vorher natürlich auch mal kommen können....

    Das war offensichtlich der Übeltäter. Ich hatte den Wert auf dem Standard belassen und nicht weiter angepasst, in der Annahme, dass dann soweit alles korrekt konfiguriert wäre... Hier sollte also der Pfad im Standard am besten auch mit aufgenommen werden. Dann ergeht es wohl nicht nur mir so.


    Vielen Dank dafür - so hätte ich mir das allerdings vom Support direkt gewünscht. Bzw. im Idealfall sind die Standard-Einstellungen so gesetzt, dass es erst gar nicht so solchen "Fehlern" kommt.

  • Kurzer Nachtrag:

    Jetzt funktionieren auch alle Skripte ohne Probleme.


    Herr Preuß, ist denn noch etwas bzgl. dem Port und dem Whitelabeling angedacht?

    Das man über die "Haupt-Domain" direkt aufs CCP von Netcup ist nicht ganz im Sinne des Whitelabelings.

  • Guten Tag,



    ich freue mich, dass ich Ihnen die richtige Hilfestellung geben konnte. Wir werden für die Zukunft einige Parameter mehr für "open_basedir" als Standard setzen, so dass es hier nicht so schnell zu Fehlkonfigurationen kommen kann.


    Zu den anderen Punkten:


    Die Beschwerdestelle bewerben wir einzig in den Tickets selbst. Bitte verwenden Sie nur bekannte E-Mail-Adressen für Kontaktaufnahmen.


    Wir werden in der Zukunft in den Beschwerden darauf verweisen, dass diese nur über das vorgesehene Formular eröffnet werden können.


    Den Port und die Hauptdomain von webhosting.systems werden wir vorerst nicht ändern. Ein 100%iges Whitelabling werden wir leider nie erreichen können. Dafür müssten Sie die Server dann selbst betreiben.



    Mit freundlichen Grüßen


    Felix preuß

  • Ich habe in der Zwischenzeit eine Website von einem anderen Netcup Webspace auf den Reseller-Tarif umziehen wollen - das Script benötigt aber den Zend Guard Loader.


    Vor meiner Bestellung hatte ich extra geschaut was das Wiki zu Zend Guard sagt:

    https://www.netcup-wiki.de/wiki/PHP_Zend_Guard_Loader


    Da die Reseller Tarife ja neu sind, dachte ich, ich bin damit auf der sicheren Seite mit der Aussage:


    Quote

    netcup stellt den Zend Guard Loader kostenlos in allen Business und Reseller Tarifen bereit

    Ist zwar etwas widersprüchlich mit Confixx im Anschluss, aber ich dachte eben nur dort muss dann die Config angepasst werden.



    Habe es gestern versucht und festgestellt: ZendGuard läuft nicht. Also den Support angeschrieben mit Verweis auf den Wiki Eintrag. Darauf hin eine Rückmeldung erhalten, dass sich der Eintrag nur auf Confix bezieht und bei Plesk nichts gemacht werden muss und es direkt funktioniert. Daraufhin gab es dann von mir einen Link zur Seite die jetzt nicht mehr läuft; Daraufhin gab es die Rückmeldung, dass es an die zuständige Abteilung geht.


    Dort kam jetzt die Aussage, dass der ZendGuard Loader nicht zur Verfügung gestellt wird.



    Es ist ehrlich etwas ernüchternd, dass man hier offensichtlich das Wiki falsch pflegt, unterschiedliche Aussagen vom Support erhält und am Ende dann wohl der "dumme" ist, weil die Seiten nicht laufen.....

  • Zendguard kann bei einer kompatiblen Version von PHP einfach direkt über das Documentroot des jeweiligen vHosts geladen werden. Der Hersteller von Zend gibt dazu Anleitungen.


    Wir können natürlich nicht Zendguard in nicht kompatiblen PHP-Versionen anbieten. Das kann denke ich niemand.



    Mit freundlichen Grüßen


    Felix Preuß

  • Eben hat es mit den Sessions schon wieder nicht funktioniert, offensichtlich wurde jetzt der Session Pfad von "/var/lib/php5/sessions" auf "/var/lib/php/sessions" angepasst. Kommt natürlich super, wenn man die openbase_dir selber nachpflegen muss und keine Info bekommt...



    Umzug einer anderen Seite (von einem anderen Netcup Webspace) führt auch nur zu Fehlern...


    [Wed Oct 09 15:17:40.742071 2019] [fcgid:warn] [pid 14513:tid 139695824500480] (104)Connection reset by peer: [client XXX:46546] mod_fcgid: error reading data from FastCGI server, referer: https://XXX.de/

    [Wed Oct 09 15:17:40.742167 2019] [core:error] [pid 14513:tid 139695824500480] [client XXX:46546] End of script output before headers: index.php, referer: https://XXX.de/

  • [Wed Oct 09 15:17:40.742167 2019] [core:error] [pid 14513:tid 139695824500480] [client XXX:46546] End of script output before headers: index.php, referer: https://XXX.de/

    Entweder hast Du einen falschen PHP-Interpreter oder falsche Berechtigungen für die index.php gesetzt. In dem Fall wird das PHP nicht ausgeführt und das CGI wartet vergeblich auf Antwort.

  • Gibts da auch irgendwelche Informationen dazu, was genau (CMS? Oder welche sonstige Anwendung ) da wie umgezogen wurde, unter welcher PHP-Version das ggf vorher gelaufen ist und unter welcher jetzt im Reseller Webhosting nicht? In welcher Logdatei stehen diese Fehler überhaupt? Ansonsten ist es nett, wenn ich das hier mitbekomme, aber was soll ich damit jetzt anfangen? Alles was mir das sagt ist: Irgendwas spuckt irgendwo irgendwelche Fehler aus. Immerhin kann deine Problematik wohl auch nicht auf alle Reseller Webhostings verallgemeinert werden, ein anderer User hat hier schon berichtet, dass seine PHP-Anwendung im Reseller Webhosting besser lief als in seinem normalen Webhosting. Damit wird er wohl nicht gemeint haben, dass er jetzt einen Fehler weniger bekommt als vorher ;). Scheint für mich also am ehesten eine Fehlkonfiguration deines Servers zu sein.


    Wenn ich mehr Zeit hätte, würde ich mir ja mal so ein Reseller-Webhosting holen zum Testen, das habe ich schon länger vor. Aber das mache ich erst, wenn ich auch gleich zum Testen komme und damit die Zufriedenheitsgarantie am Ende auch noch nutzen kann. Prinzipiell ist das Konzept des Reseller Webhostings nicht uninteressant für mich, wobei die Ressourcen im Vergleich zu einem separate Webspace pro Kunde von der Spezifikation her erst mal deutlich weniger zu sein scheinen. Naja, 100 Kunden würde ich auf ein Reseller 8000 sicher auch nicht draufquetschen wollen. Eher maximal vier oder fünf.

  • Wenn ich mehr Zeit hätte, würde ich mir ja mal so ein Reseller-Webhosting holen zum Testen, das habe ich schon länger vor. Aber das mache ich erst, wenn ich auch gleich zum Testen komme und damit die Zufriedenheitsgarantie am Ende auch noch nutzen kann.

    Mir würde ja schon ein Demo-Zugang (Backend-only) genügen, damit ich Auskunft geben kann, wenn mich jemand fragt.

  • Hallo zusammen,


    zwischenzeitlich hatte ich erneut mit dem Support Kontakt, u.a. mit Verweis auf den Kommentar von Herrn Preuß, daraufhin teilte mir der Support mit, dass ihm auch keine andere Möglichkeit bekannt sei als den Loader dann über die php.ini zu laden. Zeitgleich war man so freundlich und hat das für die entsprechende (Sub-)Domain erledigt - so wünsche ich mir das.


    Leider wurde der Eintrag offensichtlich heute Nacht erneut entfernt, so dass es wieder nicht funktioniert hat. Da ich in dem gleichen Abonnement Probleme mit der Hauptdomain habe (Beitrag #56) und dort auch in Plesk die Ganze zeit die php Informationen nicht abrufen konnte (Fehler: Informationen über die PHP-Konfiguration können nicht abgerufen werden.) habe ich mir gedacht, dass es wohl am sinnvollsten ist, das Abonnement einmal zu löschen und erneut anzulegen.


    Das hat aber zu einem ziemlich kryptischen Fehler nach dem Anlegen geführt (siehe Anhang).

    Fehler: Unable to load object of type PhDomain with id=62: Domaindaten können nicht aktualisiert werden: Domaindaten können nicht aktualisiert werden: Domain Service Web not exists: domain=XXX.de, id=61


    Also erneut versucht zu löschen und wieder hinzuzufügen: Löschen klappt, das neu anlegen wird aber jetzt komplett verweigert, da er meint, dass die User etc. bereits existieren.



    Irgendwo ist also leider immer noch ziemlich der Wurm drin bei dem Produkt, wobei ich es grundsätzlich sehr gerne produktiv nutzen würde.