Beiträge von Ringelnatz

    Wir sind schließlich hier Kunden weil wir netup vom Preis-/Leistungs-Verhältnis spitze finden, und nicht weil wir nicht wüssten was die Konkurrenz zu bieten hat!

    Du hast vor ein paar Jahren ja bereits den offiziellen Grund für diese Regel genannt bekommen. Hier mal zwei Zitate von Felix:

    Allerdings ist es in vielerlei Hinsicht nicht ratsam, dass im Forum eines Betreibers Namen von Mitbewerbern des Betreibers genannt und über diese diskutiert werden. Schließlich kann dem Betreiber so immer vorgeworfen werden, dass er die Beiträge zu seinen Gunsten manipuliert. Abmahnungen sind hier dann so gut wie sicher.

    Wir als Betreiber des Forums sind für jeden Beitrag mit verantwortlich, von dem wir Kenntnis haben. Aus dem Grund schließen wir die Nennung von Mitbewerbern hier aus.

    Ob das rechtlich wirklich so problematisch ist kann ich natürlich nicht beurteilen (und unser Forenjurist nimmt ja gerade eine Auszeit ;)). Aber die Haltung passt zumindest zu netcup, wenn man bedenkt wie lange die Kündigung hier nur per Post/Fax möglich war, und dass Domain-Reseller nicht eigenständig Kundendomains löschen können, obwohl die Haftung in so einem Fall per zusätzlichem Vertrag eindeutig geklärt ist, und sicher gibt es noch weitere Beispiele. Man geht halt auf Nummer sicher.

    ArtCore7 += ist ja durchaus verbreitet (Java, JavaScript, ...), in Verbindung mit einem return (das dann auch noch mehrfach pro Methode) ist mir das allerdings noch nicht untergekommen ;)

    Erinnert ein bisschen an yield, aber das funktioniert nochmal ein bisschen anders.

    Bei der Denic kam es immer wieder zu einem Fehler, weil ns1 und ns2 auf einer IP lagen, ergo wurde eine 2. iPv4 ueber netcup geordert und eingerichtet.

    Diese Anforderung soll sicherstellen, dass beim Ausfall eines Nameservers die darauf gehosteten Zonen trotzdem aufgelöst werden können (Stichwort Redundanz). Dem Nameserver einfach eine weitere IP zu verschaffen ist daher naheliegenderweise nicht zielführend.


    Die ns-Records können in Schlundtech nicht neu gesetzt werden. Aktuell werden immer wieder die Standard Schmundtech-Nameserver gesetzt.

    Bei Problemen mit dem Verwaltungsinterface eines anderen Hosters kann hier niemand helfen, das ist ein Fall für deren Support.

    Ich würde mit Git-Tags arbeiten, also ein Tag (den kannst du ja jederzeit für einen beliebigen Branch/Commit anlegen) in GitHub entspricht einem Deployment der Webseite. Das lässt sich mit Actions automatisieren: https://docs.github.com/en/fre…hpull_requestbranchestags


    Dann per scp den jeweiligen Code-Stand auf den Server schieben, z.B. hiermit (kurz gegoogelt, gibt auch noch andere actions dafür): https://github.com/marketplace/actions/scp-deploy-action

    Beide Scripts testen die rohe CPU Leistung. Das ist fürs Webhosting sicherlich ein wichtiger Parameter. ABER:

    Es fehlt die Datenbankleistung und die Time-To-First-Byte. Was sicherlich auch noch wichtige Parameter sind!

    Um ehrlich zu sein ist die CPU-Leistung für eine klassische Webseite wohl mit der unwichtigste Parameter. Zumindest für dynamische/modulare Seiten (z.B. WordPress-basiert oder irgendeine Software die auf viele Libraries dependet, im Dateisystem einen Cache anlegt etc.) ist IO-Performance sehr wichtig, und falls eine Datenbank im Spiel ist natürlich auch deren Performance sowie die Latenz bei den Abfragen.

    mainziman Logisch, das ändert aber nichts an der vorübergehenden "Downtime" der Domain. Bis der Registrar die neuen Nameserver übernimmt und diese global bekannt sind kann es halt ein paar Stunden dauern. Wenn die alten NS sich dann schon nicht mehr zuständig fühlen klappt solange die Auflösung nicht mehr.

    Wie ist das eigentlich, wenn man aktuell eine Domain weg transferiert? Behalten die netcup NS die bisherigen DNS-Records noch für eine gewisse Zeit oder geben die sofort NXDOMAIN zurück, sobald der Transfer durch ist?

    Beim Umstellen auf eigene NS werden die von netcup ja zumindest sofort deaktiviert (was auch ziemlich ungünstig ist), insofern schätze ich, dass es bei einem ausgehenden Transfer nicht anders sein wird. Aber ist nur ne Vermutung.


    Aufgrund der aktuellen Berichte hier im Forum und meinen eigenen Erfahrungen bin ich jetzt soweit, dass ich in nächster Zeit meine bei netcup liegenden Domains wegtransferieren werde (bin noch nicht ganz sicher wohin). Selbst wenn man wie ich hauptsächlich eigene NS nutzt gibt es noch genug Möglichkeiten hier in Fehler zu laufen welche die Domain unerreichbar machen und nur durch den Support zu lösen sind. Schade, ich habe ja sogar die neue API in der Betaphase getestet und Feedback gegeben, dennoch hat sie es allenfalls in den Status "gerade so brauchbar" geschafft. Und auch andere Systeme scheinen ja alles andere als ausgefeilt zu sein. Das ist mir dann doch zu heikel.

    Mir fällt jetzt erst auf, dass ich für diverse Server Rechnungen für einen Zeitraum ab dem 1.1.21 erhalten, tageweise abgerechnet (auch bei RS). Braucht netcup grade dringend Geld oder war das schon immer so, dass die Rechnung über einen Monat im Voraus kommt? :/


    Ich gestehe, dass ich mir die Rechnungen meistens nicht genauer ansehe (sind ja auch so viele ...). War es ein Fehler einfach auf die Richtigkeit zu vertrauen ("wird ja automatisch erzeugt, was soll schon schief gehen")?

    Viel schlechter kann es ja eigentlich nicht werden.

    Glaub mir das geht. Es gibt auf GitHub schon einige Skripte von Leuten die damit ab einem gewissen Packetloss das Teil automatisch neustarten lassen, ich hatte das Problem teilweise auch, da bin ich keine 24h ohne Restart der Box ausgekommen weil nichts mehr ging.

    Tja, zu früh gefreut: Der 500er ist wieder da im CCP und als Krönung sind alle DNS-Records mit "www" plötzlich ungültig und lösen nicht mehr auf.


    Und wie das passieren kann, weiß wohl auch nur netcup…

    Oh man, das klingt echt beunruhigend. Nutze zwar kaum die Nameserver von netcup, aber mit dem Umstellen auf eigene NS hatte ich auch schon ein paar Mal Probleme. Ich hatte irgendwie gehofft das alles würde mit der Zeit etwas ausgereifter werden.