Ansonsten ist es auch nicht sonderlich schwierig ein Wordpress ohne Plugin umzuziehen, solange du Zugriff auf die Dateien und die Datenbank hast. Bevor du dir einen abbrichst mit temporären DNS-Einträgen.
Beiträge von tab
-
-
Debian 13.3 scheint released worden zu sein. Perfekt um an einem verschneiten Winternachmittag 🌨️ zu prokastinieren und statt wichtige Dinge zu erledigen, meine Serverchen zu aktualisieren

Da habe ich leider schon andere unwichtige Dinge vor.

-
Well, you're not alone at least. Same here. I rarely ever look in there, so I checked a minute ago after reading your post. Obviously, something is broken. Did you open a support ticket already? I'll have to do this later this evening, because I'm off in 5 minutes.
-
Gibt's nicht, und mir geht's nicht um den Steal, sondern dass es halt langsam war (der Steal ist nur gut geeignet zum Messen). Und wie gesagt, im Großen und Ganzen bin ich ja zufrieden mit dem Preis/Leistungs-Verhältnis.
EDIT: Präziser, dass es halt gefühlt immer langsam ist, nicht nur manchmal.
Da ich die genaue Situation bezüglich ARM Servern bei netcup als Kunde nicht kenne, kann ich die Ursachen der gefühlten (und tatsächlichen) Langsamkeit nur anhand von Indizien vermuten. Und diese Vermutung geht in Richtung Auslastung der Nodes. Dass es schon längere Zeit keine neuen VPS ARM mehr zu geben scheint (derzeit ausverkauft) ist ein Indiz dafür. Die Nodes sind voll und man will keine weiteren ARM-Server mehr reinquetschen, selbst wenn es nur VPS sind. Das man nicht will ist lobenswert, ändert aber nichts daran, dass die Nodes eben voll sind und naturgemäß bei VPS auch überbucht. Wie stark man überbucht entscheidet letztlich der Anbieter, hier netcup. Kann man als Kunde auch nicht viel dagegen machen, sofern nicht in der Produktbeschreibung oder in den AGB etwas konkret versprochen wird, was dem aus Sicht des Anbieters noch akzeptablen Steal widerspricht. Mal abgesehen von der Abstimmung mit den Füßen.
Die vCores der VPS ARM waren allerdings seit Anbeginn in GB6 etwas weniger performant als die damaligen VPS x86, haben aber dafür mehr vCores. Die VPS ARM sind auf dem Leistungsstand zur Zeit der Einführung geblieben, der Steal hat etwas zugenommen. Die VPS x86 sind allerdings mittlerweile um einiges performanter geworden, obwohl man auch hier nach einiger Zeit sieht, wie die Performance runtergeht. Aber eben auf deutlich höherem Niveau. Wahrscheinlich auch hier durch stärkere Auslastung der Nodes, die anfangs meist noch nicht voll belegt sind. Und auch durch Nodes mit älteren Prozessoren.
Die zeitweise auftretenden Paketverluste ärgern mich auch, weil das früher (tm) nicht so war. Ob so etwas auch von Überlastung kommen kann oder zwingend auf defekte Kabel, Switches oder sonstige Komponenten hindeutet, weiss ich nicht. Da kenne ich mich zuwenig mit aus. Für normal halte ich es aber jedenfalls nicht. Bei meinen Servern bei Strota und I0N0S sehe ich jedenfalls keine Paketverluste. Bei mir gibt es (bei netcup) oft stunden- oder tagelang gar keine Verluste, dann aber plötzlich doch wieder welche. Vor einiger Zeit dachte ich schon, die Paketverluste (drops) seien behoben, sehe aber in Munin schon länger wieder, dass sie noch da sind. Abhängig vom Server (oder vom Netzwerksegment?) mehr oder weniger häufig oder gar nicht. Das betrifft auch mein Cloud VLAN.
-
Die mail-Subdomain verweist im netcup Webhosting per Default auf den MX. Webmail ist dort wohl nicht vorgesehen, nur zentral auf webmail01.webhosting.systems.
Das ist auch eine andere IP als dein MX /SMTP-Server im Webhosting-Paket. Du kannst Webmail auch über webmail.meine-domain.de aufrufen, aber die Verbindung ist dann nicht sicher, nur http. Da du auf dem Webmail-Server dafür kein Zertikat installieren kannst, geht es eben nicht gesichert über https. Du kannst natürlich in deinem Hosting-Paket eine eigene Webmail-Software installieren, dafür kannst du dann auch ein Zertifikat erstellen lassen.
-
Ich hab hier einen VPS ARM 3000, und eigentlich[tm] bin ich mit dem auch ganz zufrieden, ich mach da normalerweise wenig CPU-intensives Zeug drauf. Aber jedes Mal wenn ich dann doch CPU-Leistung brauche, habe ich zwischen 30 und 40% Steal. Jetzt ist mir schon klar, dass ich halt nicht für dedizierte Kerne bezahle, und wenn das nur manchmal wäre, wäre es mir auch egal, aber es passiert halt echt ständig.
Meint ihr den Support interessiert sowas?
EDIT: Ich hab daheim einen RK3588 (ungekühlt), und der outperformed den VPS 😂
30-40% Steal wird den Support wohl eher nicht interessieren bei einem VPS. Im allerbesten Fall verschieben sie dich aus Kulanz auf einen anderen Node. Ob es dort dann besser ist? Vielleicht. Dafür hockt dann halt ein anderer Kunde auf deinem Node. Bei einem RS hättest du da andere Argumente.
Ich hatte bisher noch nie einen Server, den mein Heimrechner nicht deutlich outperformed hätte. Wenn das meine Ansprüche an einen Server wären, würde ich mir einen dedizierten Server mieten. Den dann mit einem besseren AMD Ryzen als ihn mein Heimrechner hat und mit einer dedizierten Grafikkarte. Da meine Anwendungszwecke (Webhosting, ein bisschen Mail) solche Leistungen nicht brauchen, kann ich mit vergleichsweise wenig Performance gut leben. Trotzdem vergleiche ich natürlich, was ich für mein Geld bekomme. Bekomme ich anderswo die von mir benötigte Leistung für deutlich weniger Geld, dann denke ich über einen Umzug nach.
Auch mein vServer von I0N0S ist sicher nett - für einen vServer. Und übertrifft bei GB 6 die ARM VPS hier um mindestens einen Faktor 2,5. Egal ob Single Core oder Multi-Core (auch mit weniger Cores). Aber an meinen Desktop-PC kommt er nicht ran. Dafür hat er aber eine dedizierte IPv4 und ein IPv6 Subnetz und ist so angebunden, dass manchmal auch 8-9 GBit/s erreicht werden, je nach Gegenstellle und den Aktivitäten der Nachbarn auf dem Node. Würde ich das zuhause haben wollen, dann müsste ich wahrscheinlich dreistellige Monatsbeträge allein für die Anbindung zahlen. Dazu Strom, etwaige Reparaturen usw. Und so betrachtet ist er für seinen Preis ein echtes Schnäppchen.
-
Das kann ich Dir jetzt auch nicht sagen, merkwürdig. Versuche doch mal, die IP-Adresse als ip4:188.68.63.166 direkt bei deinem SPF-Record mit aufzunehmen, vielleicht schaut Google nicht tief genug in die SPF-Records rein.
Das scheint mir jedenfalls ein guter Ansatz zur Analyse des Problems zu sein. Die IP - wenn es denn immer die selbe ist - vor die includes setzen und schauen ob sie dann als berechtigt azeptiert wird. Ich bin mir jetzt nicht sicher, welche Einschränkungen SPF im Einzelnen hat. Also wie tief ein auswertendes Programm zwingend zu suchen hat und wieviele DNS-Abfragen zur Auswertung des SPF-Records zwingend zu machen sind.
Mit MS hatte ich ein Problem damit, dass MS den Timeout für die DNS-Abfragen sehr niedrig setzt. Gleichzeitig wird die Abfrage wohl auch noch aus den USA gemacht, was die Sache nicht gerade beschleunigt. Bei einem hohen Prozentsatz der Mails stand dann im Report auch ein fail drin. Allerdings stand im MS-Report dann unten bei den AUTH_RESULTS nicht ebenso "fail", sondern "temperr". Wie Google das handhabt weiss ich nicht mehr, da kam das auch sehr selten oder gar nicht vor. Eventuell bleiben die dann auch einfach beim "fail".
Damals (tm) wurde die Mail über die grüne Mailbox aus Berlin verschickt - mit dem entsprechenden include im SPF Text-Record. Das hat dann wohl bei der Abfrage gelegentlich zu lange gedauert. Seit die Mail wieder direkt vom Mailserver des Webhosting-Pakets verschickt wird kommt das nicht mehr vor. Das war nur ein include, du hast zwei.
-
Anleitungen werden nun aber mal (meistens) von Leuten geschrieben, die sich auskennen.

Was nicht immer ein Vorteil ist ...

-
Ja, aber warum ist dann der Text ein anderer?
Und wer sagt an der Stelle, dass es NICHT für alle Domains gilt?
Ich, sonst würde bei mir nichts mehr funktionieren. Auch wenn man es vielleicht missverstehen könnte, es ist jedenfalls nicht so. Würde auch keinerlei Sinn machen, für alle Domains die selben Nameserver benutzen zu müssen. Da wäre man ja fast gezwungen, mindestens 5-6 Kundenaccounts zu haben, um allen Domains die jeweils passenden Nameserver eintragen zu können.
-
-
Ich mache da bei MS auch nichts mehr. Wie käme ich dazu? Wer keine Mail will, der hat schon. Irgendwann, wenn ich in der richtigen Laune dazu bin, sperre ich mal alle MS-Netze und lasse alle Mails von deren Servern abweisen, mit einer passend abgewandelten Kopie iher eigenen Begründung. Habe zwar einige Bekannte mit MS Freemail, aber da kann ich notfalls andere Adressen benutzen. Die dürfen sich dann aber auch gern an MS wenden wegen der von mir konfigurierten Sperrung. Und nach der 5. Mail antworte ich dann sogar selbst.

-
Das ist schon korrekt so bei Standort Nürnberg. Bei anderen Standorten kannst du Alternativdomains bestellen. Eine .com Domain ist beim Standort Manassas dabei.
-
Typischerweise ist Port 465 SSL und Port 587 (START)TLS. Insofern könnte es sein, dass es an der Kombination von Port 465 und TLS liegt.
-
Naja, Piko wäre grenzwertig, da würde die Installation ohne 1-2 GB Swap nicht durchlaufen. Ich habs auf einem VC1-1 drauf, aber nur um mal auszutesten ob es überhaupt möglich ist. Nicht um es ernsthaft zu nutzen. Immerhin, eine Contao-Demo läuft recht flüssig drauf, den Virenscanner für Mails würde ich mich aber nicht trauen zu aktivieren. Ich habe vorsichtshalber erst gar kein Postfach erstellt auf dem Kleinen.
Die memory usage in Munin sieht dann so aus:
-
Alles anzeigen
Ich habe jetzt alles 3x neuinstalliert und peinlichst genau darauf geachtet alles richtig zu machen.
Für die Domain die mir KeyHelp während der Installation nennt (Hostname [sub.meinedomain.de]), habe ich einen DNS A-Eintrag auf meine IP bei netcup eingerichtet.
Ich komme mittlerweile über diese Domain auf die Weboberfläche von KeyHelp.
Ich richte einen Nutzer ein, melde mich als dieser an, richte eine Domain ein [meinedomain.de], schalte DNS bei KeyHelp aus.
Die Domain wird auch mit SSL eingerichtet und hat einen grünen Haken.
Besuche ich diese domain erhalte ich aber weiterhin SSL_ERROR_BAD_CERT_DOMAIN.
Hat das irgendwas damit zu tun, dass ich dieser Domain bei netcup im WCP bereits ein SSL-Zertifikat eingrichtet habe?
Normalerweise hat die domain doch wegen der geänderten DNS-Einträge gar nichts mit dem WCP zu tun?
Ist der grüne Haken auch noch da, wenn du die Seite neu lädst. Schau dir als Admin unter Allgemein/Systemstatus -> Control Panel/Protokolle das update.log (Aufgaben abarbeiten) an. Da siehst du die Logs der minütlich abgearbeiteten Aufgaben, u.a. auch die Versuche ein Zertifikat für eine Domain zu bekommen und auch ob sie erfolgreich waren oder nicht.
Ggf findet sich dann da eventuell auch ein Hinweis, was das Problem gewesen sein könnte.
Es ist schwer zu helfen nur anhand allgemeiner Beschreibung dessen, was du getan hast.
Zumindest für mich, der Keyhelp noch nie in einer lokalen Umgebung installiert hat und auch noch nie mit einer VM mit Virtualisierung von Virtualbox.
Allerdings habe ich in der Forensuche bei community.keyhelp.de Beiträge gefunden, die zeigen, dass das wohl auch in so einer Konstellation funktionieren sollte. Habe mir die Beiträge allerdings nicht im Detail durchgelesen, sondern nur nach "virtualbox" gesucht.
-
Alles anzeigen
Nochmal aufgelistet:
- bei Netcup DNS A * und @ Records für meine Domain auf meine IP zu Hause geändert
- FritzBox hat ganz normal ein PortForwarding 80/443
- frischer Debian Server mit KeyHelp (ich rufe das Webinterface über 192.168.... auf)
- als Admin einloggen, Benutzer erstellen
- zum Benutzer wechseln, Domain erstellen mit SSL-Zertifikat (ja, URL korrekt eingetragen)
-- DNS für die Domain in KeyHelp deaktiviert, soll über netcup laufen
-- warten bis zur vollen Minute, bis KeyHelp die Änderungen übernimmt
Ich rufe meine Domain auf > SSL_ERROR_BAD_CERT_DOMAIN
Hast du das Zertifikat gleich bei der Erstellung der Domain mit erstellen lassen? Das geht in der Regel schief, da versucht LE eventuell schon sich zu verbinden bevor die Domain auch tatsächlich erreichbar ist auf dem Server. Im Zweifel als Workaround erst die Domain ohne Zertifikat erstellen, nächste volle Minute abwarten und die Domain dann bearbeiten und das LE-Zertifikat erstellen lassen, nächste volle Minute abwarten. Ich mache das aus eben diesem Grund schon seit Jahren gewohnheitsmäßig so.
-
Ey Bud, du bist Bayer, kein Ösi!

Vielleicht hat er das heuer geändert

-
Alles anzeigen
Die sind mir viel zu teuer. Ich möchte bei netcup bleiben. Nicht nur wegen dem Preis, sondern weil ich schon immer hier war.
Es gibt jetzt nur ein paar Hürden zu überwältigen und Fragen zu klären.
Besonders:
- wenn ich mir einen echten VPS miete, KeyHelp installiere und meine DNS-A * und @ Records auf die IP des VPS lenke-- kann ich dann ohne Probleme Domains dort eintragen? Firefox akzeptiert das self signed SSL von KeyHelp nicht.
Ich habe alles korrekt eingerichtet (Benutzer + Domain) und Firefox meldet "SSL_ERROR_BAD_CERT_DOMAIN".
Meine Domain ist aber korrekt eingetragen.
Was ist mit IPv6 (AAAA)? Ich habe mehrere netcup VPS unter Keyhelp am Laufen, keiner davon hat so ein Problem. Das kann also schon funktionieren mit dem Zertifikat. Let's Encrypt verbindet sich bevorzugt über IPv6. Wenn also ein AAAA Record für den Hostnamen eingetragen ist, LE sich aber über diese IPv6 nicht auf den VPS verbinden kann,z.B. weil die IPv6 auf dem Server gar nicht konfiguriert ist, dann scheitert die Ausstellung des LE-Zertifikats. Normalerweise, wenn alle im DNS eingetragenen IPs (v4 und ggf v6) auf dem Server konfiguriert sind und der Server darüber erreichbar ist, dann erstellt Keyhelp ein LE-Zertifikat für den Server.
We ist denn eigentlich der genaue Status? Kommst du in die Keyhelp-Oberfläche gar nicht erst rein? Notfalls sollte das auch vorübergehendüber die IP des Servers möglich sein.
-
Ich könnte mir ebenfalls vorstellen, dass das die Kalkulation erschweren würde. Webspace und Mailspace gehören zu zwei unterschiedlichen Plesk-Abonnements. Ich weiss nicht, wie so eine Kombination von Webhosting-Server, Mail-Server und MySQL-Server physisch realisiert ist. Also ob das alles VMs sind oder doch "echtes Blech".
Gleiches gilt für den Speicher. Es könnte also durchaus auch sein, dass der Speicher für die Webspaces und die Mailspaces eines Webhostings strikt getrennt ist, so dass eben x GB Webspace und y GB Mailspace für die Webhosting-Pakete insgesamt zur Verfügung steht. Wenn da dann ein Großteil der Kunden seinen Speicher anders verteilt, vermutlich eher Richtung Webspace, dann könnte das schnell zu Problemen führen, weil die doppelte Menge an Webspace insgesamt gar nicht zur Verfügung steht.
Und wenn man für die Worst Cases jeweils die doppelte Menge an Mailspace und Webspace pro Webhosting-Paket einplanen würde - oder zumindest eine ausreichende Reserve, dann würde das sicher den Preis ordentlich nach oben treiben. So wie es derzeit ist, ist alles einfacher kalkulierbar. Auch wenn der Speicher wohl überbucht sein wird, wie so ungefähr alles im Shared Webhosting.
Wäre das alles auf dem gleichen Speicherverbund, dann könnte man ja einfach von vornherein die Gesamtmenge (Webspace + Mailspace) limitieren, womit ein Schieberegler gar nicht mehr gebraucht würde. Das ist bei anderen Hostern teils auch durchaus so.
-
Tja, die Website versteckt sich hinter Cloudflare. Eventuell wollen die es sich nur nicht mit ihrem Hoster verderben
