Beiträge von Lucan

    Ja jetzt läuft es wieder. Sind bei Euch auch die Logs mit


    Code
    mod_fcgid: ap_pass_brigade failed in handle_request_ipc function

    voll?


    Fast alle Seiten bei mir bekommen immer wieder nen Gateway Fehler und das taucht dann in den Logs auf.... Der Support möchte aber nicht die Limits erhöhen.... Passiert auch bei Seiten die vorher hier auf einem günstigeren Webspace bei Netcup liefen...


    Ein Fehler der die Verbindung von externen SMTP Servern betroffen hat wurde nun endlich behoben, nachdem ich ewig mit dem Support diskutieren musste, weil mir immer wieder unterstellt wurde es läge an meinen Scripten.... War wohl nen Fehler in der ipv6 Config und wurde jetzt endlich behoben.

    Bei T-Online lief es ohne Probleme, da habe ich die Mail das der Server entfernt wurde nur an den Support weitergeleitet. Bei Microsoft und yahoo habe ich den Support informiert und zeitgleich Microsoft und Yahoo kontaktiert. Bei Microsoft hakt der Support auch nach. Zwischenzeitlich habe ich von Microsoft direkt die Meldung erhalten, dass sie das Blacklisting "abschwächen" der Support von Netcup will aber wohl weiter dran bleiben bis er komplett delisted ist.


    Bei Yahoo muss ich laut Support aber selber tätig werden, obwohl dort wohl auch eine generelle Sperre vorliegt. Naja, auf jeden Fall bin ich da jetzt dran...


    DKIM & DMARC sind beim Reseller Webhosting ja vermutlich nicht möglich oder? Ich wüsste daher nicht was ich, abgesehen von SPF, machen könnte.

    Das einzig größere Problem das aktuell noch auftritt, ist eine E-Mail-Blacklist bei mehreren Providern....


    Bei T-Online konnte ich die Sperre selber entfernen lassen, Yahoo fordert immer mehr Infos ein, aber macht nicht wirklich voran und Microsoft weigert sich aktuell die IP zu entfernen, hat aber angeblich einen kompletten Teil von NetCup gesperrt....


    Das ist natürlich ziemlich ärgerlich so.



    Habt ihr noch Tips wie man die eigenen Mails auf nem Reseller Webspace möglichst compliant gestalten kann? SPF Records wollte ich jetzt noch für alle betroffenen Domains setzen. Viel mehr Möglichkeiten dürfte ich dann aber auch hier nicht mehr haben....

    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.

    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/

    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:


    Zitat

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

    Hallo Herr Preuß,


    vielen Dank für ihre Rückmeldung.


    Zitat

    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.


    Zitat

    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.

    Hallo Herr Preuß,


    danke für die Rückmeldung.

    Zitat

    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.



    Zitat

    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)

    Zitat

    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:

    Zitat

    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.

    Zitat

    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:


    Zitat

    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

    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.

    Die Erfahrungen mit dem Support sind leider auch sehr bescheiden.

    Obwohl nachweislich die Pfad-Änderungen nicht übernommen werden und ein simples php Script den Fehler klar bestätigt


    Code
    session_start();
    
    if (!is_writable(session_save_path())) {
        echo 'Session path "'.session_save_path().'" is not writable for PHP!'; 
    }


    Ist laut Support alles in Ordnung und funktioniert wie es soll. Das ist leider ein ziemliches Armutszeugnis, insbesondere wenn man bedenkt, dass es ja für den "professionellen" Einsatz beworben wird. Hätte ich da schon Kunden drauf und die Fehler werden so geleugnet und nicht behoben, dann ist man doch ziemlich verloren. ALs wenn es nicht schon schlimm genug wäre, dass man die Fehler auf mehrere Arten "beweisen" muss, werden sie dann immer noch nicht in einiger angemessen Zeit behoben und weiterhin behauptet alles würde funktionieren.

    Hast du dazu schon eine Rückmeldung vom Support bekommen? Ich habe gestern noch gesagt bekommen das es an die zuständige Abteilung weitergeleitet wird. Bei so einem gravierenden Problem hätte ich mir aber eine schnelle(re) Lösung gewünscht. Grade wenn dort Kunden seiten drauf liegen und es ja auch aktiv für Agenturen etc. beworben wird, muss hier meiner Meinung nach schneller reagiert werden.


    Insgesamt macht das Produkt so leider einen ziemlich bescheidenen Eindruck, so dass ich aktuell stark überlege die Kundenseiten wirklich umzuziehen.

    Ich habe mal eins bestellt, ich habe aber das gefühl, man fungiert hier als Beta-Tester....


    Der Session-Pfad ist nicht beschreibbar und manuelle Änderungen in den Einstellungen werden nicht übernommen, Eine Weiterleitung eingerichtet, statt der Weiterleitung wird aber die Plesk Default Page angezeigt.... Das sind nur Punkte die mir mehr oder weniger sofort aufgefallen sind, weil es so nicht möglich ist auch nur halbwegs damit zu arbeiten.


    Leider ist Plesk auch nur über Port 8443 erreichbar und nicht direkt über 443, was natürlich unschön ist (viele Firewalls blocken die nicht-standard Ports).


    https://webhosting.systems leitet (leider) auch immer noch auf das NetCup Customer Control Panel weiter, so dass das meiner Meinung nach auch nur von einem Whitelabeling in einer "light" Version gesprochen werde kann. Wenn viel Wert auf Whitelabeling gelegt werden würde, dann ließe sich die Domain individualisieren.

    https://rw0b0d.webhosting.systems:8443