Beiträge von tab

Eventuell hilft es auch schon, den DNS-Cache auf deinem lokalen PC zu löschen oder andere Nameserver einzutragen.

Die "vorläufige" Domain ist eine dauerhafte. Die bekommt auch jeder, nicht nur wer nicht gleich bei der Bestellung eine Domain angegeben hat. Und sie zählt natürlich bei den 3 Inklusivdomains nicht mit. Du kannst also wirklich drei eigene de-Domains nutzen. Man kann sie auch z.B. benutzen, um schon vor der Bestellung einer Domain seine Website zu testen. Voreingestellt ist für diese Systemdomain, dass sie auf das Verzeichnis /httpdocs verweist. Wenn du also dahin dein HTML, CSS und Javascript hochlädst, dann bist du bereits soweit, dass deine Website angezeigt werden kann. Du kannst natürlich für HTML, CSS und Javascript auch eine dir genehme Ordnerstruktur anlegen, allerdings sollte die Startseite, bei dir wohl index.html, direkt in /httpdocs liegen.
Deine Dateien kannst du mit dem Dateimanager oder per FTP hochladen.

Was verstehst du da unter Firewall? Den DDOS-Schutz? Den hat netcup ja auch.

Zitat von aRaphael

Heute das erste mal "which which" verwendet.

Das muss doch heissen "witch witch" oder auf deutsch "Hex hex".

Also es fallen mir da zwei Dinge auf. Die mögen bei Mailcow so sein müssen, weiss ich nicht.

1.) Je nach DNS-Server darf bei Host nicht die Domain nochmal mit drinstehen, die wird automatisch angehängt. Wenn das Netcup-DNS-Server sind, dann ist das jedenfalls so. Mag aber sein, dass Mailcow eigene DNS-Server mitbringt, wo die Domain selbst nochmal mit anzugeben ist.

Ansonsten z.B. bei netcup-DNS-Server halt nur

Host: dkim._domainkey

2.) Wie marpri bereits geschrieben hat, dass "mail." vor "meinedomain.de" muss weg und stelle die TTL mal runter, solange es noch nicht funktioniert.

Die ganzen Geschichten habe ich in den letzten Tagen auch durchgekaut für zwei Domains, bei mir funktioniert es mittlerweile mit DKIM, SPF, DMARC, DNSSEC, MTA-STS. DANE habe ich mir dann geschenkt.3x 5/5 bei MECSA reicht mir fürs Erste.

Vielleicht mal im access.log nachschauen, was die App denn so alles an Requests geschickt hat.

Da hilft nur, in den PHP-Einstellungen der betreffenden Domain für open_basedir die Einstellung auszuwählen, die mit {WEBSPACEROOT} beginnt.

Wer UCEPROTECT Level 3 benutzt, der will offensichtlich keine Mails empfangen. Ich denke mal relativ wenige werden sich das antun. Trotzdem wäre es schön, wenn netcup mal danach schauen würde, was die Kunden mit ihren Mailaccounts so treiben. Ansonsten bleibt das ein Dauerzustand, solange niemand die Organisation hinter UCEPROTECT aus dem Netz klagt, was vermutlich gar nicht so einfach sein wird. Ginge die Spammerei aus dem Netz von netcup zurück, wäre die Listung wohl bald vorbei. Aber ohne einen "strongly worded letter" an die entsprechenden Kunden und im Wiederholungsfall der Sperrung ihrer Accounts wird das nicht zu machen sein. Ich will gar nicht wissen, wieviele vServer hier gebucht sind, deren einziger Verwendungszweck (oder zumindest der Hauptzweck) der Versand von Spam-Mails ist. Wobei unter Spam im Grunde auch schon eine automatische Abwesenheitsnotiz fällt oder zumindest fallen kann. Oder ein Kontaktformular, wo sich der Absender unter Angabe seine E-Mail-Adresse eine Kopie seiner Anfrage schicken lassen kann, eine klassische Spamschleuder.

Auf der anderen Seite ist so eine BL natürlich ein einträgliches Geschäftsmodell und man kann sich sogar noch auf die Fahne schreiben, das man für das Gute kämpft. Auch wenn die Betreiber von UCEPROTECT in Wirklichkeit natürlich nur unser Bestes wollen, also unser Geld.

Zitat von youbenick

Würde der gleiche Effekt beim Webhosting 2000 Produkt auftreten? Hier sind 4GB Ram garantiert, würde das helfen oder wäre hier gleiches zu beobachten?

Es tritt auch beim Webhosting 8000 auf. Ich habe jetzt keine Vergleichstests dafür gefahren, aber auch beim Webhosting 8000 sind so lange Wartezeiten möglich.

Zitat von condor

Wenn Einnahmen über Prestashop laufen, kann ich dringend einen (managed) vServer empfehlen. Ein Root-Server ist wahrscheinlich zu viel. Selbst mit Online-Shop, Nextcloud und diversen Diensten dümpelt mein Epic-2Core-Server mit 2-3% Auslastung vor sich her Ich war vorher bei einem anderen Anbieter, dort hat ein leeres Woocommerce auch bis zu 10 Sekunden gebraucht.

Auch Ladezeiten von über 1 Sekunden (HTML) sind nachteilig, da Google diese kaum besuchen und indexieren wird.

Nextcloud lädt bei mir im ms-Bereich, die reine HTML-Seite von Woocommerce lädt in ca. 300-500ms (Gesamtübersicht ,100 Produkte), einzelne Produktseiten beim zweiten Aufruf dauern ca. 100ms, beim ersten Mal ca. 500ms. Presta selbst verwende ich nicht.

Externe Datenbanken machen Seiten jedoch extrem langsam. Ein Dashboard für die Verwaltung von externen Forschungsdaten (Azure, MS-SQL) lädt auch 2,5 Sekunden, was ich schon als nervig empfinde Da lässt sich nicht viel machen, außer SQL-Code optimieren (Potential gibt es, aber ich glaube nicht, dass mein Arbeitgeber mich dafür bezahlen würde. Hauptsache es läuft ).

Cronjobs bringen nicht viel, meine persönliche Erfahrung. Insbesondere da der Arbeitsspeicher pro Kunde aus technischen Gründen limitiert wird, können meist nicht alle Produktseiten im RAM gespeichert bleiben, erst recht keine komplettes Backend. (zumindest meine Erfahrung beim vorherigen Anbieter, habe mit Sharedhosting bei Netcup keine Erfahrung).

Die Seiten müssen ja nicht im RAM gespeichert werden, Festplatte tuts dafür eigentlich auch. Einen Cache wird ja Wordpress hoffentlich zustande bringen. Und falls nicht, wird halt das Shopsystem notgedrungen einen mitbringen (müssen!).

Na dann versuche ich mich nachher nochmal zu registrieren, ich schätze ext-sodium sollte eine sinnvolle Erweiterung sein. Ich vermute mal stark, es ist das aktivierte Greylisting bei meiner Adresse. Vielleicht kommt das Forum damit nicht klar. Mail ist eh Glücksache. Habe mir mal eine icu-Domain im Angebot geholt, jetzt stelle ich fest, dass Spamassassin mir allein wegen der TLD schon 3.5 Punkte draufhaut in der Defaulteinstellung . Da darf sonst nichts verkehrt sein oder der Empfänger die Schwelle mal von 5 auf 3 runtersetzen. Kein Wunder war die TLD im Angebot.

Zitat von youbenick

Wie lange dauert es bis der Cache wieder leer ist? Dh bei einer Website die regelmäßig frequentiert wird fällt das dann gar nicht auf?

Nein, das fällt bei einer stark frequentierten Website überhaupt nicht auf. Je nachdem was sonst noch so auf den OPcache zugreift dauert es jedenfalls zumindest Stunden ohne Zugriff, bevor der Seitenaufbau dadurch auffallend verzögert wird. Nach einem Tag oder mehr sind es dann aber je nach Webhosting Verzögerungen bis gerade in den hier genannten Zeitbereich von 30 Sekunden. Auch das kann natürlich varrieren, je nachdem wie lange deine konkrete Anwendung eben benötigt, wenn sie praktisch von Null auf geladen werden muss, also wenn keine nennenswerten Reste mehr davon im Cache sind. Je fetter die Anwandung, desto länger kann es dauern.

Zitat von Virinum

Das umstellen auf FPM hat das ganze leider nicht behoben, sondern nur die Grenze der mindestens vorhandenen Downloadgeschwindigkeit etwas nach unten gesetzt.

Folgendes Verhalten kann ich beim Download von https://vm0.de/5GB.php beobachten:

• 5 GB Datei über 50 Mbit/s: nach ca. 14 Minuten erfolgreich
• 5 GB Datei über 25 Mbit/s: nach ca. 5,5 Minuten abgebrochen

Im Log finde ich folgende Fehlermeldungen:

Code: error_log

[Wed Apr 24 09:54:45.924903 2019] [proxy_fcgi:error] [pid 32264] [client XXX.XXX.XXX.XXX] AH01068: Got bogus version 166
[Wed Apr 24 09:54:45.924972 2019] [proxy_fcgi:error] [pid 32264] (22)Invalid argument: [client XXX.XXX.XXX.XXX] AH01075: Error dispatching request to : (passing brigade to output filters)

Ich hab auch schon versucht den Support zu kontaktieren, der stellt sich aber quer:

Wobei ich das starke Gefühl habe, dass meine Mail nur sehr halbherzig gelesen wurde. Es geht ja nicht konkret um eine Software, sondern um eine Grundfunktion von PHP. Aber ich bleibe da dran.

Ehrlich gesagt habe ich keine Ahnung, was ich mir jetzt von euch erhoffe. Ich denke nämlich, dass nur der Support kann da wirklich was reißen. Aber vielleicht hat ja jemand eine Erleuchtung.

Falls es noch jemand interessiert, habe gerade nochmal DuckDuckGo bemüht und das hier gefunden:

https://bz.apache.org/bugzilla/show_bug.cgi?id=59838

Die Fehlermeldung dort sieht sehr ähnlich aus. Da ging es um einen Apache Bug, allerdings sieht es zumindest so aus, als ob das damals gefixed wurde. Keine Ahnung ob der Fix mittlerweile bei unseren Webhostingservern angekommen ist oder eventuell erst mit dem Plesk-Update kommt. Immerhin ist 2016 schon ne Weile her.

In der ersten Spalte: Host, da muss der Name der Subdomain rein, da wo sonst meist @ oder * steht. Einfach unten in die erste der nicht ausgefüllten Zeile.

Deine Einträge für die Subdomain machst du im DNS der Hauptdomain. Einfach in der ersten Spalte den Namen der Subdomain eintragen, also "mysubdomain" für die Subdomain "mysubdomain.example.com"

So, mittlerweile habe ich einiges ausprobiert und bin im Großen und Ganzen sehr zufrieden mit Keyhelp. Ein paar Dinge stören (mich) noch ein wenig

1. Kein nginx oder zumindest nginx Proxy. Kann man natürlich selbst installieren und konfigurieren, aber dann kann ich auch gleich alles selbst installieren und konfigurieren. Ok, verzichte ich auf den nginx Proxy, angesichts des Geschwindigkeitsunterschieds des VPS zum Webhosting nicht allzu gravierend.
2. Bei PHP fehlt mir die Sodium Extension, das ist schade, die werde ich wohl mittelfristig benötigen. Auch das kann man selbst installieren, sogar mit guter Anleitung. Aber dann muss ich die automatischen Updates für PHP ausschalten und vermutlich bei jedem PHP-Update wieder selbst neu zu kompilieren anfangen.
3. Bei der E-Mail finde ich keine Einstellung für Greylisting, das ist aber schon jammern auf hohem Niveau.

Wegen Punkt 2 wollte ich mich im Forum registrieren und nachfragen ob man das vielleicht mit aufnehmen kann, allerdings ist die mir zugeschickte Mail nie angekommen. Die muss in mein schwarzes Loch gefallen sein. Muss ich wohl nochmal eine andere Adresse verwenden bei der Registrierung.

Ansonsten gefällt mir das für meine Zwecke aber sogar besser als Plesk.

Zitat von DerRené

Hmmm... könnte man dafür dann nicht einfach auch einen eigenen Cronjob direkt vom Webserver aus laufen lassen? Beispielsweise ein curl-Script?

Führt dann natürlich kein Javascript etc aus, aber reicht das schon? Anderenfalls ein Python-Script mit Scrapy, BeautifulSoup o.ä.

Aber dennoch unschön, dass ein solcher Workaround überhaupt nötig ist.

Javascript und sonstige Assets sind kein Problem. Der "Problemcache" ist eben der OPcache. Man kann förmlich zusehen, wie die Ladezeit immer länger wird, wenn einige Zeit kein Request stattfindet, der dafür sorgt, dass das verwendete PHP inklusive Framework wie Symfony etc geladen und interpretiert wird. Je länger kein Zugriff, desto mehr benötigte PHP-Skripte fliegen aus dem OPcache. Dann nehmen wir noch die trotz SSD nicht so besonders berühmte IO-Geschwindigkeit dazu, den Bremsfallschirm open_basedir, der dafür sorgt, dass der realpath cache disabled ist und schon wird das Laden des CMS/Shopsoftware/Nextcloud, bestehend aus ziemlich vielen Skripten, eine sehr laaaaangsame Angelegenheit.

Zitat von Manisch

Sehr, sehr seltsam...

Jetzt über Nacht scheint es auf einmal zu gehen

Da waren die Heinzelmännchen am Werk. Typischerweise hat solche Probleme auch nicht nur ein einzelner User auf einem Webhostingserver.

Zitat von eripek

Marktbeobachtung: In Wien gibt es zumindest noch einen Anbieter, der 25 GB, 512 MB, 1 Core und 100 Mbit/s (gegen Aufpreise etliches konfigurierbar) um € 1,45 netto (bei 24 M MVD) im Sortiment hat.

Um den Preis bekomme ich ja schon ein richtiges Webhosting

Also mein VPS mit 6 vCores wurde ausgeliefert mit der Einstellung 1 Sockel, 6 Cores pro Sockel. Und so habe ich ihn auch gelassen und er nutzt so auch alle Cores. Wenn nicht lizenzrechtliche Unterschiede eine Rolle spielen oder das OS das unbedingt anders braucht, sehe ich eigentlich keinen Grund das zu ändern, ist eh alles virtualisiert.