Beiträge von tab

    Also ich würde es schon auch besser finden, wenn Netcup klar kommunziert wo die Grentzen für den Mailversand sind.

    In der AGB wird nur Massenhafter Versand ausgeschlossen und restliche Informationen findet man vielleicht im Forum.

    Eine klare Ansage in der Produktbeschhreibung, notfallas auch mit Sternchen und als Fußnote wäre schon transparenter.


    Gruß Eckhard

    Und was schreibst du da dann hin? Nicht mehr als 5 Newsletter-Mails an Yahoo pro Stunde, nicht mehr als 2 an MS, 3 an gmail, gerne aber 48 unterschiedliche Mails pro Stunde? Und wenn du 5 an Yahoo erlaubst, weil die vielleicht momentan 5 zulassen, dann musst du deine Produktbeschreibung jedes Mal ändern, wenn irgendein großer Mailanbieter seine Limits/Filter ändert, weil sonst wieder irgendjemand kommt und sagt "Da steht aber ich darf 5 Newsletter-Mails versenden pro Stunde an Yahoo. Das habe ich gemacht und jetzt kann ich keine Mails mehr an Yahoo senden!"


    Ich bin auch dafür, Limits klar zu kommunizieren, aber manchmal ist es halt schwierig, wenn die Ursachen für die Limits nicht in den eigenen Systemen liegen, sondern anderswo. Wenn der Mailserver nicht mehr als 50 Mails pro Stunde und Kunde verkraftet, kann man das klar kommunizieren, das ist was Anderes. Aber zuverlässiger Mailversand ist in den letzten Jahren leider schwierig geworden. Herzlichen Dank auch dafür an alle Spammer! Wenn das so weitergeht, wird es wohl bald keine Postfächer mehr geben im Shared Webhosting, weil man ja eh kaum noch was drüber verschicken kann ;(. Oder die Preise müssen steigen, damit entweder die großen Mailanbieter bezahlt werden können oder ein paar Mitarbeiter sich um die ganzen Freischaltungen kümmern können. Das ist dann ziemlich transparent. :D;)

    Er hat einen "Info-Letter" an <50 Yahoo Empfänger verschickt innerhalb einiger Stunden. So steht es in seinem Beitrag. Ob das jetzt Info-Letter oder Newsletter heisst ist doch Latte. Es sind <50 identische oder sehr ähnliche Mails an verschiedene Empfänger bei Yahoo eingegangen. Selbst wenn hierbei meinetwegen die Anrede unterschiedlich war, die Spamfilter bei den großen Mailanbietern springen darauf an, auch schon deutlich vor 50 Mails! Er schreibt ja sogar selbst, dass Spam-Meldungen anderer Provider kamen, als er noch selbst einen Server betrieb. Und sein Beitrag liest sich jedenfalls nicht so, dass er sich jetzt anders verhält, so dass es nicht mehr passiert. Liest sich für mich eher so, dass er in ein Webhosting umgezogen ist, damit künftig netcup seinen Müll aufräumt und er "die Umstände" nicht beheben muss. Dass netcup seinen Müll wegräumen muss, sehe ich durchaus auch so, denn die anderen davon betroffenen Kunden dürfen darunter nicht leiden. Was netcup dann - spätestens im Wiederholungsfall - mit einem Kunden macht, der wiederholt die AGB missachtet und damit erhebliche Kosten verursacht, ist deren Sache. Ich weiss, was ich machen würde.


    Klar gibt es WEG's und auch Vereine, die mehr als 50 Mitglieder haben, die wegen Jahreshauptversammlung oder anderen Events angeschrieben werden müssen. Aber das ändert nichts an der Tatsache, dass das zu Problemen führt. Nicht nur für den Absender, sondern auch für andere Kunden. Wobei bei Vereinen oder WEG's im Normalfall nicht 50 Empfänger bei Yahoo sind. Allerdings braucht es auch nicht so viele um die entsprechende Reaktion auszulösen. Und andere große Mailanbieter reagieren teils ebenso empfindlich und noch rigoroser.


    Viele Massenversender sind sogar kostenlos für eine solche, für ihre Verhältnisse minimale Anzahl von Mails. Manche davon sogar noch werbefrei. Man muss sie eben nur nutzen.


    50 Newsletter an Yahoo? An einem Tag? Herzlichen Glückwunsch, auch an alle Kunden auf "deinem" Webhosting-Mailserver!


    Zu den Dingen, die man vor dem Kauf eines Webhostings bei netcup auch kennen sollte, zählen auch die AGB. Hier steht unter "5. Pflichten des Kunden" unter anderem auch, dass "massenhafter Versand von Emails" untersagt ist. Was netcup - zumindest vor einigen Jahren noch - als "massenhaft" ansah, kann man hier im Forum noch irgendwo nachlesen. Ich erinnere mich noch dunkel daran, dass in dem betreffenden Beitrag die Zahl "zwei" vorkam. Das finde ich zwar leicht übertrieben, aber nachvollziehbar angesichts dessen, dass manche große Mailanbieter eben schon auf zwei Newsletter-Mails mit den rigorosen Maßnahmen reagieren, unter denen jetzt du, die anderen Kunden auf dem selben Mailserver (selbe IP), und - wenn es blöd (oder eigentlich normal) läuft - auch gleich alle Kunden auf dem selben Subnetz, leiden.


    Newsletter gehören m.E. über einen professionellen Massenmail-Versender verschickt. Die haben entsprechende (kostenpflichtige!) Verträge mit diversen, einschlägigen Mailanbieter, durch die sie sich die Zustellung von über sie versandten Mails erkaufen. Zudem ermöglichen sie in der Regel die genaue Nachverfolgung, welche Mails angekommen sind und welche nicht. Aber auch diese Massenmail-Versender haben AGBs, die gelesen und beachtet werden sollten.

    Die geblockten Grafiken kommen wohl vom Kopieren aus Plesk. und sind keine Fehler beim entsprechenden Request. Es ist einfach ein kleines png, das als Symbol für den Browser-Agent im Protokoll angezeigt wird. Die "Broken pipe"-Fehler dürften davon herrühren, dass der Client die Verbindung unterbrochen hat bevor der Server die Antwort auf den Request verschickt hat. Da hat man also eher wenig Chancen auf Behebung, außer man schafft es, die Requests schneller zu beantworten oder den Client dazu zu bewegen, die Verbindung länger aufrecht zu erhalten. Die entsprechenden Anfragen kommen auch von anderen, teilweise unterschiedlichen IPs als der erste Eintrag, der als einziger was mit der Software zu tun zu haben scheint. Wenn die IP wirklich geblockt ist/war durch fail2ban bzw die Firewall, dann würden Requests den Apache oder nginx ja gar nicht mehr erreichen, könnten also auch keine Fehler mehr auslösen. Das bringt uns m.E. leider keinen Schritt weiter.


    Deswegen meine ich ja, er muss sich die Logs anschauen vom Zeitraum bevor die IP geblockt wurde. Dann könnte man eventuell sehen, ob da wirklich relativ viele Requests von dieser IP eingingen, was dann zum Blocken hätte führen können. Wenn das wirklich die Ursache sein sollte, dann kann da bestenfalls netcup noch an irgendeinem Schräubchen drehen, um zu verhindern, dass die IP immer wieder gesperrt wird. Da habe ich aber eher wenig Hoffnung, dass da eine Extrawurst gebraten wird. Man wird sich ja (hoffentlich) was bei dieser Einstellung gedacht haben ;) .

    Du solltest dir nicht nur die Fehler von der vermutlich gesperrten IP ansehen, sondern auch die erfolgreichen ZUgriffe, also alle Zugriffe anzeigen lassen und darin nach der IP suchen. Eigentlich sollten die ja auch eine Aussage machen können, in welchen Zeitabständen die zugreifen oder bei welcher Aktion deinerseits oder deiner Website.

    Ich fürchte, das wird wieder mal ein Fall für den Support. Hast du die automatische Weiterleitung auf https aktiviert, bevor das Zertifikat erstellt wurde (oder jedenfalls bevor der Versuch gestartet wurde)? Oder wie bist du genau vorgegangen?


    Hast du mal versucht, ob es ganz unter Umgehung des nginx funktioniert? Also in den "Einstellungen für Apache & nginx" den Haken bei "Intelligente Bearbeitung statischer Dateien" rausgenommen (und auch bei "Statische Dateien direkt durch nginx bedienen")? Dann wäre der nginx weitgehend aussen vor. Wenn es da funktionieren würde, dann hat der nginx hier wohl wirklich ein Problem. Die letzte Einstellmöglichkeit "Statische Dateien direkt durch nginx bedienen" empfiehlt sich sowieso in den meisten Fällen nicht, weil Rewrites z.B. nicht ausgeführt werden.


    Aber wenn Let's Encrypt nicht funktioniert, wird es wohl eh besser zu sein, den Support zu kontakten, vorzugsweise über das CCP (Kontakt), mit möglichst genauer Beschreibung was du gemacht hast und was nicht funktioniert.

    Nicht gut, das ist hier ein reines Kundenforum. Kunden helfen Kunden. Der Support und die Technik schauen zwar auch ab und zu mal rein, aber da sollte man sich nicht drauf verlassen. Alles was Kunden nicht lösen können, weil es eben einen Eingriff vom Support/der Technik braucht, sollte man dem Support melden, telefonisch oder über das CCP. Klar, wenn man sich darüber nicht sicher ist, ob es vielleicht auch ohne Support geht, kann man schon mal hier fragen, ob es vielleicht irgendwelche Tricks oder Workarounds gibt. Aber wenn da nach Stunden noch kein Lösungsvorschlag kommt, dann zum Support damit. In deinem Fall käme höchstens noch eine lokal bei dir installierte Security Suite oder ähnliches in Frage, die irgendwas grundsätzlich blockt, also in allen Browsern. Ansonsten kannst du ja nicht mehr machen als im SCP die entsprechenden Aktionen anklicken.

    Einfachste Möglichkeit: Im Prinzip müssen alle Domains dem Webhosting zugewiesen werden.

    Für die Domains die weiterleiten sollen, den Hosting Typ auf Weiterleitung stellen https://www.netcup-wiki.de/wik…el_Webhosting#Hosting-Typ

    Soweit ich weiss, gibt es da zumindest Schwierigkeiten mit LE-Zertifikaten. Also für eine weitergeleitete Domain kannst du kein LE-Zertifikat erzeugen, das müsstest du dann vor der Weiterleitung tun und bei jeder Verlängerung des Zertifikats müsste man wohl vorher nochmals die Weiterleitung rausnehmen. Alternativ kannst du allen Domains den selben Dokumentenstamm zuweisen und dann mit einer .htaccess die Weiterleitungen realisieren. Oder du nimmst halt in Kauf, dass die weitergeleiteten Domains nur mit http:// funktionieren.

    Die Software ist WBB-Lite 102pl3.


    tab: Ja auch der Seitenquellentext ist leer. Und wegen der Datenbank/Zugangsdaten - wo muss ich das vornehmen?


    Sorry für die ganzen Fragen eines ahnungslosen, aber als ich das Forum für über 14 Jahren installiert hatte, war das deutlich leichter.

    Hmm, ich habe gerade mal geschaut und einen WBB-Lite 1.0.2 pl3 Download gefunden aus dem Jahr 2008. Wenn das Ding wirklich so alt ist und nie ein Update bekommen hat, dann wird es jetzt wohl schwierig. Unter welcher PHP-Version lief das denn in deinem alten Webhosting? Bei mir als älteste Version im WCP die Version 5.6 angeboten. Die kam lange nach 2008, nämlich 2014. Und selbst wenn das funktionieren sollte, dann sehe ich spätestens bei MySQL 8 - was in den aktuellen Webhostings verwendet wird, ziemlich schwarz. Das mag aber vielleicht in deiner Business-Version anders aussehen, keine Ahnung. Ich wusste gar nicht, dass es sowas gibt.

    Die neue Datenbank nebst Zugangsdaten hast du eingetragen?

    Ansonsten, was heisst "ohne sichtbare Daten"? Wenn du den Seitenquelltext anschaust, ist der dann komplett leer? Das deutet dann üblicherweise darauf hin, dass dein PHP irgendwo mit einem Fehler aussteigt, der findet sich dann normalerweise in den Logs.


    Oder du schaltest einfach mal vorübergehend die Fehlerausgabe von PHP im Frontend ein. Das geht in den PHP-Einstellungen, display_error auf On stellen und speichern.

    Ist denn deine Domain in deinem neuen Webhostingpaket mit drin? Ich kenne das Forum nicht. Was genau meinst du mit: "ich kann die Seiten nicht aufrufen"? Kommt beim Versuch eine Fehlermeldung oder "nur" ein 404 Fehler. Findet er also die Forensoftware und die wirft irgendeinen Fehler oder sucht der Webserver im falschen Verzeichnis.


    Dinge, die du abklären könntest wären z.B.

    1. Ist der Dokumentenstamm (document root) der (Sub-)Domain deines Forums so eingestellt, dass die aufzurufende Datei (index.php?) sich darin befindet? Falls nicht, entweder die Dateien in den eingestellten Dokumentenstamm kopieren oder den Dokumentenstamm auf das Verzeichnis umstellen, wo die Dateien liegen.
    2. Passt die eingestellte PHP-Version für diese Subdomain zu deiner Version der Forensoftware? Falls nicht, im WCP in den PHP-Einstellungen umstellen.
    3. Irgendwo in deiner Forensoftware musst du sicher auch noch einige Einstellungen auf das neue Hosting anpassen. Zumindest mal die Datenbankzugangsdaten.

    An wen richtet sich denn deine Frage? Denn es ist niemand direkt angesprochen, also würde ich das normalerweise auf mich beziehen, weil ich der letzte war, der was geschrieben hat. Ich finde in meinem Beitrag aber nichts, was diese Schlussfolgerung zulassen würde. Daher bin ich jetzt unsicher, wer gemeint ist…


    Nur um sicher zu gehen, antworte ich jetzt einfach mal: Eine automatisierte Antwort ist keine Reaktion und beschleunigt auch nichts. Keine Ahnung, wem das helfen sollte.

    Hatte ich durchaus auf deine Antwort bezogen. Und ja, eine automatisierte Reaktion ist auch eine Reaktion. Sie sagt dir immerhin, dass dein Ticket oder Anruf im System ist und (hoffentlich) nicht im Nirwana versandet. Viel mehr an Erstreaktion habe ich auch bei anderen Webhostern in einem etwas höheren Preissegment meist nicht erhalten. Falls es eine schnell zu behebende Kleinigkeit ist, dann sollte sie schnell behoben und der Kunde nach Behebung darüber benachrichtigt werden. Falls es aber länger dauert, weil es eben nicht so trivial ist, dann habe ich im Verlauf der Bearbeitung eines Tickets mit Rückfragen und Antworten darauf, durchaus auch zwischendurch mal eine Woche nichts gehört, bis zur nächsten Rückfrage oder der endgültigen Lösung des Problems.

    Aber Irgendwelche regelmäßigen Mails wie "Ihre Anfrage ist in Bearbeitung" wären ja auch wieder nur automatisierte Reaktionen, die niemandem wirklich was bringen, solange es in der Sache keinen Fortschritt (für den Kunden) gibt.

    Das heißt, wenn dir netcup eine automatische Bestätigungsmail schicken würde innerhalb von ein paar Stunden nach Erstellung des Tickets oder dem Anruf beim Support, dann wärst du schon zufrieden?

    Sieht man im access.log des Webservers irgendwelche Zugriffe von der Buchhaltungssoftware? Falls ja, könnte man eventuell sehen, ob da zeitweise sehr viele Zugriffe in kurzer Zeit kommen, bzw vor der Blockierung gekommen sind.

    Ich koennte da komplett falsch liegen, aber bei solchen Zeiten habe ich immer als erstes die DNS-Aufloesung im Verdacht. Als zweites einen Fallback von IPv6 auf IPv4.

    Hatte ich auch im Verdacht, aber dann habe ich mir die entsprechenden Zeiten angeschaut, unter anderem namelookup_time, connect_time pretransfer_time. Alle sehr kurz. IPv6 hatte ich auch im Verdacht und liess mir die IP-Adresse ausgeben. War tatsächlich eine IPv6. Dann habe ich IPv4 Auflösung fest eingestellt, danach hatte ich eine IPv4 in der Ausgabe und die Zeit hat sich nicht geändert. Mir fällt nichts Besseres mehr ein, als dass netcup da irgendwas anhand der IP und/oder dem User Agent verzögert. Vielleicht sollte ich um ganz sicherzugehen, dass es nicht an IPv6 liegt, mal eine externe Seite per IPv6 runterladen. Ich habe da leider nichts eigenes außer S. und meine netcup-Server. Habe jetzt die Beschränkung auf IPv4 wieder rausgenommen und suche mir mal ein paar Opfer zum Testen :D .


    Edit: wikipedia.org hat mich zugelassen per IPv6, TTFB 0,31 Sekunden. Auch google.com per IPv6, TTFB 0,08 Sekunden. Geht also auch schneller per IPv6 außerhalb des Netcup Netzwerks.

    Echt? =O

    Man kann ein Ticket nicht mehr eskalieren?

    DAS wäre eine echte Verschlechterung. :thumbdown::thumbdown:

    Nach meiner Erfahrung hatte nämlich der First-Level-Support nicht immer die ausreichende Kompetenz, um meine Anfrage zu bearbeiten (oder überhaupt zu verstehen ;) ), die Beschwerdestelle hat mich dann aber bisher immer zufrieden gestellt.

    Oha. Den Support werde ich demnächst vielleicht auch mal wieder in Anspruch nehmen müssen. Ich bin auf ein Phänomen gestossen, das ich mir nicht erklären kann. Dass es die Beschwerdestelle nicht mehr gibt finde ich einigermassen alarmierend und auch die (Nicht-)Reaktionszeiten, von denen hier berichtet wird. Ich hoffe, das ist dem Personalmangel geschuldet oder jetzt einfach anders geregelt, dass es vielleicht nach mehreren Antworten automatisch eskaliert wird oder nach welchen Regeln auch immer.


    Aber nun zu meinem aktuellen Problem. Vielleicht weiss ja auch hier jemand was darüber. Seit kurzem bin ich nun auch Kunde beim Webhoster S, dem zigfachen Service-Weltmeister mit der dicken Weltkugel in der Fernsehwerbung. Ich habe da ein Aktionsangebot wahrgenommen, weil ein Kunde von S mit einem Auftrag gedroht hat, ich mit S noch überhaupt keine Erfahrungswerte hatte und ich deshalb einfach vorab Erfahrungen aus erster Hand mit S Shared Webhostings sammeln wollte, um ein böses Erwachen am Projektende auszuschliessen. Auch im Hinblick auf mögliche zukünftige Anfragen von S-Kunden.


    Meine schlimmste Befürchtung, dass mein CMS dort vielleicht nicht installierbar oder lauffähig sein würde, war schnell ausgeräumt. Ich hatte aber schon öfter Erfahrungen anderer mitbekommen, nach denen die Webhostings von S nicht unbedingt ein Ausbund an Schnelligkeit seien und insbesondere die Datenbanken sehr langsam. Das nahm ich dann zum Anlass, um das einmal selbst zu überprüfen.


    Ich habe zu diesem Zweck die selbe Website jetzt auf 4 verschiedenen Webhostings installiert, inklusive dem bei S und einem von netcup. Zusätzlich als Referenz noch auf einem größeren netcup Rootserver. Auf Caching habe ich hier komplett verzichtet, weil mich nicht die Zugriffszeiten auf den Cache interessieren, die nicht viel mit der tatsächliechen Performance des Webhostings zu tun haben, sondern die Zeiten für die Erzeugung des HTML. Vorab habe ich mir auf die Schnelle einfach mal die Ergebnisse von Google Pagespeed angeschaut, die Ergebnisse waren zwar teilweise etwas überraschend für mich, aber nachvollziehbar. Das Paket von S war jedenfalls der Verlierer. Alle anderen, inklusive netcup RS und Webhosting 4000, schienen relativ nahe beisammen zu liegen.


    Nun wollte ich diesen ersten Eindruck mit ein paar eigenen Zahlen untermauern. Ich habe ein PHP-Skrikt erstellt, das die 5 URLs per curl runterlädt und die URL, TTFB und die Zeit bis das HTML runtergeladen ist, in eine Datei protokolliert. Diese Skript habe ich dann von einem anderen RS aus per Cronjob alle 10 Minuten aufgerufen. Und hier ist das netcup Webhosting plötzlich sehr langsam, langsamer als es eigentlich sein kann. Teilweise 6-7 Sekunden bis zum ersten Byte, selten mal unter 2 Sekunden. Einzelne Ausreisser allerdings bis unter 0,5 Sekunden. S dümpelt so bei 2-3 Sekunden rum, die anderen beiden Webhostingpakete streuen zwischen 0,18 und 0,6 Sekunden. Der RS streut so um die 0,1 Sekunden, hat aber auch einen Vorteil bei der Verbindung zum aufrufenden RS.


    Alle Werte, bis auf die des netcup Webhosting 4000, sind für mich schlüssig und nachvollziehbar. Aber wie entstehen die langsamen Zeiten des Webhosting 4000? Ich würde ja sagen, vielleicht ist es einfach so langsam. Aber wo bekommt dann Google Pagespeed die 0,4 Sekunden für "First Contentful Paint" und "Time to Interactive" her? Hier streuen zwar die Zeiten auch etwas, aber >2 Sekunden kommen schlicht nicht vor. Kennen die eine Abkürzung? Oder rufen die eventuell mehrfach auf, was die Ladezeit kürzer machen könnte, weil dadurch der PHP Code des CMS im OPCache liegt? ?(;) (Die letzte Idee kam mir jetzt beim Schreiben, das baue ich versuchshalber bei mir auch mal ein.) Oder kann es sein, dass netcup Zugriffe von Servern per curl (= Bots) irgendwie runterbremst und gewisse Server (Google ...) davon ausnimmt? Die anderen Webhoster im Test tun das offenbar nicht, möglicherweise eventuell noch S, aber die anderen beiden jedenfalls nicht. Mein RS offensichtlich auch nicht :D.