Hat hier jemand zufällig eine Ahnung, was folgende Fehlermeldung bei der Domainbestellung bedeutet, die über die unterschiedlichen Bestellwege reproduzierbar auftritt (Warenkorb, CCP, API):
ZitatBestellung Ihrer Domain abcdefgh.info ist fehlgeschlagen.
Die Bestellung ist fehlgeschlagen. Bitte beauftragen Sie die Bestellung der Domain erneut.
Geraten:
So: Heute nochmal die gleiche Fehlermeldung - diesmal aber ohne, dass mir offene Rechnungen angezeigt werden!
Was den Workaround über Website+Warenkorb angeht: Was macht man, wenn man die Domain nicht für den Hauptbenutzer, sondern für ein abweichendes Handle bestellen will - wenn ich die Darstellung im Wiki richtig sehe, ist dafür kein Feld vorgesehen, d.h. der Workaround ist nicht Reseller-tauglich!
Zu dem Vergleich mit den Lockangeboten:
Darunter würde ich eher das verstehen, was die Konkurenz teilweise anbietet:
Domains für nur 0,08€ pro Monat!
(natürlich nur im ersten Jahr, laut Kleingedrucktem danach 0,99€ pro Monat für .de, 1,99€ pro Monat für .com)
Bei Kreditkarten kann man ja auch einen Betrag sperren. Ich glaube Kreditkartenzahlung ist sowieso dafür die Lösung.
Sammelrechnungen wären auch toll. Eine pro Monat.
Löst Kreditkartenzahlung das Sperr-Tage-Problem? Die FAQ enthält bisher keinen Hinweis dazu.
Genauergesagt erwähnt die FAQ auch keinen Vorteil der Kreditkartenzahlung oder einen Grund, warum man sie nutzen sollte. Von daher netcup: das wäre eine gute Idee, wenn dies in der FAQ erwähnt werden würde, damit jeder Kunde es abwägen könnte, ob die Vorteile das für ihn Wert sind (Vorteile von SEPA: kein Mindestbetrag; läuft nicht irgendwann ab wie eine Kreditkarte). Ebenso wäre es hilfreich, wenn in der FAQ und den Fehlertexten bei Bestellungen während offener Rechnungen erwähnt werden würde, ob man offene Rechnungen (so noch nicht in SEPA Queue) statt per PayPal auch per Kreditkarte bezahlen kann, um sofort wieder bestellen zu können.
31.10. 12:41 Ticket erstellt (SLA+ nur für Server; wobei SLA+ für Webhosting hier vermutlich auch nichts beschleunigt hätte - oder?)
Zitat von Antworten vom SupportAlles anzeigen31.10. 17:31
Aktuell ist die Rechnung in der SEPA Queue. Diese wird morgen bzw. Donnerstag von Ihrem Bankkonto eingezogen.
01.11. 18:06
Aktuell befinden sich noch 16 Domains in der Berechnungswarteschlange.
Diese werden Morgen Abend mit unserem nächsten Rechnungslauf berechnet und Bestellungen sind dann wieder möglich.
Alternativ können Sie weitere Domains direkt über die Website buchen. Hier kann dann eine Vorauszahlung ausgestellt werden.
Bitte loggen Sie sich hier aber im Bestellprozess in Ihrem Account an.
Fazit 1: Eigentlich wäre es wünschenswert, wenn schon die erste Supportantwort am gleichen Tag zu einer temporären Freischaltung (oder einem Hinweis auf den Workaround) führen würde.
Fazit 2: Gut zu wissen, dass es doch noch einen anderen Weg noch gibt, um Domains an Sperrtagen zu bestellen. Wobei dies nur eine Notlösung ist - insbesonders, wenn man an Reseller denkt, die ihren Kunden via API eine automatisierte Bestellung ermöglichen und davon ausgehen, dass dies an 365 Tagen im Jahr möglich ist. (Hab selber schon etwas mit dem API rumgetestet - bisher aber nur für eigene Automatisierungsskripte.)
Fazit 3: Unter der Annahme, dass ab heute Abend wieder eine reguläre Bestellung möglich ist, ist meine obige Rechnung falsch: Wir hätten dann in diesem Fall 6 statt 4 Sperrtage für eine Rechnung (ok, bei einem Wochenende und einem Feiertag dazwischen - falls das relevant ist). Womit wir bei 72 Sperrtagen bei 12 Rechnungen im Jahr wären (19,7% aller Tage!).
Guten Tag,
ich habe folgendes Problem:
Heute wollte ich mal wieder ein paar Domains bestellen - aber das CPP sagt "Momentan haben Sie eine offene Rechnung über 27,57 Euro." und verweigert die Bestellung.
Die Rechnung ist vom 28.10.2023 - heute ist der 31.10.2023.
Genaue Fehlermeldung:
ZitatVielen Dank für Ihr Interesse an unseren Domain-Produkten. Leider können wir ihre Bestellung zum aktuellen Zeitpunkt nicht durchführen. Dies kann an noch offenen Rechnungen, bzw. an Domains oder Posten, welche erst über eine kommende Rechnung abgewickelt werden, liegen. Auch ist dies der Fall, wenn bei ihrem Account ein Domaintransfer oder eine Domainbestellung in Bearbeitung ist. Sollten Sie noch offene Rechnungen haben, so empfehlen wir Ihnen die Zahlung per PayPal, danach können Sie sofort weitere Domains bestellen. Für Rückfragen steht Ihnen unser Kundenservice gerne zur Verfügung.
Dies ist mir jetzt schon zum zweiten oder dritten Mal so passiert. Allerdings hilft diesmal nicht mal eine PayPal-Zahlung weiter - diese wird mit dem Hinweis abgelehnt "Diese Rechnung befindet sich bereits im Bankeinzug und kann daher nicht via PayPal bezahlt werden.".
Die Hotline ist heute nicht zu erreichen - ich bin mal gespannt, wie schnell sich heute (an einem Aktionstag) jemand um mein Support-Ticket (NCSUP-251474) kümmert.
Ganz grundsätzlich stellt sich da bei mir als Domain-Reseller die Frage: Wie praxistauglich ist Netcup eigentlich bei größeren Domain-Mengen?
Aktuell habe ich 61 Domains und 6 weitere Artikel über Netcup gebucht, und habe im letzten Jahr 19 Rechnungen an 18 Tagen bekommen (davon 6 über 0,00 €).
Wenn nun jede Rechnung > 0 € für 4 Sperrtage sorgen würde, an denen keine direkte Bestellung möglich ist, dann wäre ich schon in Summe bei 48 Sperrtagen im Jahr - also gut 13% aller Tage!
(Wobei es in Vorjahren auch schon bis zu 19 Rechnungen > 0€ waren - das wären dann rechnerisch 76 Sperrtage - also ca. 20% aller Tage! )
Gibt es hier ein Skalierungsproblem, dass sich mit mehr Domains verschärft?
Oder bleibt es (wenn man nicht gerade neue Server oder Tarife bestellt) im Normalfall bei 12 echten Rechnungen im Jahr? (wobei selbst 13% Sperrtage eigentlich etwas viel sind)
Wie ist die Aussage "Sie können kostenlos und ohne Neuinstallation in größere Tarife wechseln." in der Tarifbeschreibung der Reseller-Webhosting-Tarife zu verstehen -
heißt das, dass man sich darauf verlassen kann, dass z.B. die E-Mail-Konfiguration, die man seinen Kunden gegeben hat, unverändert bleiben?
Oder muss man damit rechnen, dass man im Fall eines Tarifupgrades allen Endkunden erklären darf, dass sie jetzt ihre E-Mail-Clients neu konfigurieren müssen?
Kann man eigentlich sonst irgendworan erkennen, ob Systeme auf dem gleichen Host liegen?
Kurze Frage: wenn für zwei G9-Root-Server im SCP die gleiche IP (185.232.68.1) bei "Gateway / Routing auf" steht - bedeutet das, dass sie sich auf dem gleichen Hostsystem befinden, oder nur, dass sie sich im gleichen Netzwerksegment befinden? (Mit wäre möglichst große Unabhängigkeit wichtig, da der eine Server als Replikations/Backuplösung für den anderen gedacht ist - und da wäre ein anderes Hostsystem wirklich sinnvoll...)
Hab gerade die gleiche Frage und frage mich, ob da nicht der netcup AGB Absatz 6.1 greift:
ZitatSoweit nicht anders vereinbart, werden Verträge auf unbestimmte Zeit geschlossen. Solche Verträge sind von beiden Parteien mit einer Frist von einem Monat zum Monatsende kündbar, frühestens jedoch zum Ablauf einer vertraglich vereinbarten Mindestlaufzeit
Die Verlängerung um 12 Monate wird explizit nur im AGB Absatz 6.2 erwähnt für Verträge mit 24-Monatiger Laufzeit - was bei mir nicht der Fall ist.
(Habe schon über ein Jahr einen RS 4000 SSD G8 a1 12M, die Mindestlaufzeit ist also bei mir abgelaufen)
Laut CCP:
Nächste Abrechnung: 27.08.2020
Text im Kündigungs-Tab: "Kündigung zum 26.02.2021 eintragen (Rückerstattung nicht genutzter Monate): [Button: Produkt regulär kündigen]"
Eigentlich hätte ich das jetzt so interpretiert, dass ich entweder über das CPP per "Produkt regulär kündigen" den Server zum Ende des 12-Monats-Intervalls kündigen kann, oder über den Support gemäß AGB 6.1 zum Ende des nächsten Monats (unter Rückerstattung der nicht genutzten Monate).
Stimmt es wirklich, dass AGB Absatz 6.1 für 12monatige Root-Server nicht greift?
Boah, die Domains sind sicher handgestrickt "Made in Germany".
Korrekt - gegen Aufpreis werden die zugehörigen Webhostingtarife in Deutschland* betrieben.
* teilweise gemanaget aus der Ukraine
Das Problem hatte ich auch. Dein Hoster hat aktuell Probleme mit .eu und du löst dies über ein Supportticket und fragst um die Erstellung eines neuen Authcodes. Andere Domains gehen wie üblich direkt im RP.
Die Bestellung im Warenkorb und Eingabe erst später ist die richtige Lösung dafür.
Danke - das mit dem Warenkorb hab ich so gemacht, und das Problem mit den Authcodes vertagt. Vielleicht war unser alter Provider gestern von Umzugsanfragen für .eu-Domains überhäuft worden? (Wer ist schon von der Perspektive begeistert, ab in einem Monat 21,48€/Jahr pro .eu-Domain zu bezahlen...? Plus 59,88€/Jahr pro Domain Validated SSL-Zertifikat - da es dort kein Lets Encrypt gibt? (Listenpreise - evtl zutreffende Rabatte nicht berücktsichtigt))
Das verrät mein alter Anbieter leider nicht. Gekündigt habe ich vor 50 Minuten - aber es wurden schon davor irgendwelche Auth-Codes für die Domains angezeigt - ich weiß aber nicht, ob es die gleichen waren. Zum Erneuern der Codes sehe ich leider keine Funktion im Admin-Panel.
Aber zum Verständnis: Für .eu-Domains muß direkt bei netcup ein AuthCode angegeben werden?
Frage des Tages: wie transferiert man als Reseller eigentlich eine .eu-Domain zu netcup?
Wenn ich im CCP bei der Registrierung den Authcode angebe, bekomme ich die Meldung "Invalid authorization information: Authorisation code is expired. Bitte wenden Sie sich an unseren Support."
Wenn ich keinen angebe, kommt die Aufforderung, einen einzugeben.
Der angegebene Authcode ist so direkt aus dem Admin-Bereich eines anderen Hosters rüberkopiert (direkt, nachdem die Domain dort gekündigt wurde).
Läuft der Domaintransfer bei .eu-Domains nicht eigentlich so, dass man den Authcode erst in ein Online-Formular eingeben muß, dessen Link man per Mail bekommt?
Was tun?
Ich hatte heute ebenfalls das Problem, dass seit dem Abspeichern der PHP-Einstellungen (Umstellen von PHP 7.2 auf 7.4) für eine Domain besagtes open_basedir-Problem auftrat. Die Einstellungen auf die vorherigen Werte zurücksetzen brachte keine Linderung - wohl aber das Umstellen auf /var/lib/php5/sessions (bisher nie verwendet!) . Von daher scheint es tatsächlich, als wäre da gerade ein kleiner Bug...
Ich würde es mal so deuten:
Mit den Black Friday und Adventangeboten testet netcup, wieviel SSD-Space die aktuelle Intel-basierte Hardware unter realen Anwendungsfällen verkraftet. (Irgendwo stand, dass Gen7 zu viel SSD-Space hatte, was sich negativ auf die Performance ausgewirkt hat, und das es deshalb bei Gen8 weniger SSD-Space gab)
Auf Basis dieser Tests gestaltet dann netcup im neuen Jahr die nächste Generation.
Evtl. sind sie auch am überlegen, ob als Alternative zu den SSD-RS eher RS mit HDD+Optane Sinn machen, oder RS-Tarife à la Mamba/Pearl/Rentier (=sehr viel SSD, ordentlich RAM, wenig CPU)
Auf mehr SSD bei den regulären SSD-RS können wir wohl schon hoffen - mit 14-Kernern würde eher nicht rechnen (Hab ich das richtig in Erinnerung - wegen Spectre/Meltdown vergibt netcup nur noch ganze CPU-Kerne - und davor wurden durchaus mehrere Threads pro Kern genutzt?)
Ich hab wahrscheinlich in den nächsten Monaten den Anwendungsfall, 50-80 Domains zu netcup umzuziehen.
Da liegt natürlich die Idee nahe, dafür ein Hilfsscript zu bauen, das dies schnell erledigt.
Ein Studium der API-Doku lässt mich dabei vermuten, dass an zwei Stellen manuelle Nacharbeit nötig wäre (die den Sinn des Hilfsscripts infragestellen):
Sind derartige Funktionen in Planung?
Nebenbei: Diese beiden Funktionen sind meiner Meinung nach nötig, damit die API-Funktionen nicht nur von Groß-Resellern sinnvoll verwendet werden können (die eigene Web-, Mail- und DNS-Server betreiben), sondern auch von den kleineren, die es vorziehen, die Technik (Webhostingpakete) fertig bei netcup einzukaufen. Dies sollte doch auch im Interesse von netcup sein!
Noch eine Anregung: Kannst du Netzwerkstörungen als Ursache ausschließen? Falls nein, könntest du in deinem Browser HTTP/2 abschalten und schauen, ob es dadurch besser wird!
HTTP/2 beschleunigt bei fehlerfreier Verbindung die Übertragung - sobald Übertragungsfehler auftreten, wird die Übertragung deutlich langsamer als bei HTTP/1, weil bei HTTP/1 in der Regel mehrere unabhängige Verbindungen parallel aufgebaut werden, und bei HTTP/2 alles über eine Verbindung geht - und wenn es da eine Störung gibt, ist erstmal alles blockiert - Stichwort: TCP Head Of Line Blocking
mit Basisordner meine ich den neu angelegten www-Ordner.
Gegen httpdocs spricht, dass neu jede neu registrierte Domain (oder neu angelegte Subdomain) erstmal dorthin zeigt, und - solange sie nicht geändert wird - dann sämtliche Inhalte des httpdocs-Ordners dann darüber greifbar sind.
... oder noch besser:
--> diese Lösung schützt davor, versehentlich oder temporär Domains oder Subdomains zu haben, die den Basisordner komplett freigeben
