Beiträge von tab

Das Problem mit dem vlan habe ich auch bei den beiden Servern von heute. Ich mache auch mal ein Ticket auf.

Zitat von aRaphael

Ich mag ja Nextcloud nicht besonders. (Nutze Seafile), aber wenn ich mal muss, dann tatsächlich dort, in Form von deren "Storageshare" und nicht selbstgehosted.

Ich mag Nextcloud schon, jedenfalls zum Teil. Einige Sachen sind schon gut, aber vieles oft noch nicht wirklich ausgereift, selbst in der "stabilen" Version. Ein fester Release-Zyklus mit kurzen Zykluszeiten hat Vorteile, aber eben auch Nachteile. Ist nicht nur bei Nextcloud so, zumal wenn ernsthafte Tester eher rar sind. Das nächste "Minor-Release" mit neuen Features kommt oft (meist) bevor die Bugs aus dem vorhergehenden gefixt sind. Ein wirklich stabiles Release, so dass die Issues abgearbeitet sind, hat man so praktisch nie. Eine LTS-Version gibt es meines Wissens auch nicht.

Zitat von aRaphael

Danach kannst du (wie ich das z.B. immer mache) den Link /etc/resolv.conf löschen und als echte Datei anlegen und dort den NS (127.0.0.1) eintragen. (Dann unbound neu starten) Ich gebe zu, für diesen letzten Schritt gibt es elegantere Wege, aber bei mir hat das bisher immer gut funktioniert.

Danach kann man zur Sicherheit - so wie netcup, dhcp, cloud-init oder was auch immer es neuerdings auch macht in den netcup images, die Datei noch "immutable" machen (mit Root-Rechten oder sudo)

chattr +i /etc/resolv.conf

So, jetzt habe ich gestern Abend meine Nextcloud von Strota zu netcup auf den VPS 1000 G11 umgezogen. War auch prinzipiell kein großes Ding. Aber nach einem Blick in die alte nextcloud.log ging es los. Grundsätzlich bei Updates weint mir die Cloud wohl das Log voll. Zudem hatte ich in der Übersicht die beinahe schon zur Familie gehörende Meldung wegen OPCache und internem String buffer und bitte noch ein paar GB Memory mehr einstellen. Redis läuft da eh schon, sonst wären es noch mehr Meldungen. Die habe ich jetzt alle weg, fragt nicht wie ... Ich sage nur, ich habe die Werte geändert und dabei keinen erhöht .

Hatte da gestern einen Thread im Hilfeforum gefunden, wo die Experten darüber beratschlagten, warum denn diese dämlichen und eigentlich nach ihrer Ansicht völlig unverständlichen Meldungen kommen, wo doch eine nicht zu große Cloud mit 512 MB mehr als gut bedient ist und den String Buffer, ok, den könne man eventuell von 32 auf 48 MB erhöhen, das sollte dicke reichen. Und für JIT maximal vielleicht 8 MB. Also dachte ich mir, wenn die Experten das sagen ...

Ich hatte vorher inmeinerVerzweiflung 1 GB für OPCache, 256MB für String Buffer und für JIT hatte ich auch ein Vielfaches von 8 MB zugelassen. Ich glaube 128MB . Das kam eben zustande, weil bei jedem Test immer ein (noch) höherer Wert empfohlen wurde und ich das gemacht habe, bis ich Angst um mein OS hatte. Irgendwann hatte ich nach erfolglosen 5GB OPCache den Wert einfach auf 1 GB runtergesetzt und mir gedacht: Ihr könnt mich mal, verarschen kann ich mich selbst. Also habe ich gestern die Werte einzeln mal nacheinander runtergesetzt in die Expertenrichtung . Erst war die OPCache Meldung weg, dann die String Buffer auch. Alle Tests bestanden.

Aber Nextcloud versteht es meisterhaft, bei den Usern bipolare Störungen zu verursachen.

Voller Freude schaue ich in meine App-Liste, gehe wieder in die Übersicht und $%&%"$%!! Ein Error und ein mehrere Warnungen im Log. Wohlgemerkt, nur auf Apps geklickt, gelesen dass alle Apps aktuell sind und wieder zurück. Den Fehler (beim Cron) konnte ich noch wegbekommen, indem ich eine alte, deaktivierte App deinstalliert habe. Aber die Warnungen bleiben erhalten, jedes Mal, wenn ich auf Apps klicke bekomme ich diese Warnung:

Invalid defaultDaemonConfig data provided to provideInitialState by settings

Aus den Details ...

  "app": "no app in context",
  "method": "GET",
  "url": "/settings/apps",
  ...
  "data": [],

Bekommt das noch jemand außer mir mit Nextcloud 30.0.4.1 oder kennt jemand mögliche Ursachen?

Naja, spätestens Ende des Jahres wandert diese letzte Cloud wohl eh auch zum roten H. Sollen die sich doch um solches Zeug kümmern. Naja, tun sie auch nicht immer, habe da oft genug Meldungen stehen. Aber da sage ich mir dann: "Ist halt so, ich kann da nichts dran ändern". Zumindest bei einigen Meldungen sicher nicht, weil die entsprechenden, angezeigten occ-Kommandos über das rote Panel schlicht nicht zur Verfügung stehen.

Einen Nameserver mit IPv6-Adresse solltest du eigentlich gar nicht brauchen, ansonsten wohl ::1.

Zitat von EconomicParadox

Das verstehe ich nicht, wieso sollte das nicht möglich sein? Ein anfragender MTA sollte entweder die DNS-Einträge des alten oder des neuen Registrars sehen, aber niemals einen Zwischenstand mit "Domain existiert, hat aber keine MX-Einträge".

Das kommt vermutlich auf die Konfiguration des Mailservers an, aber für den Fall "es gibt keine MX-Einträge" ist es schon relativ wahrscheinlich, dass die E-Mail als unzustellbar an den Absender zurückgeht. Und wenn dort nicht gerade jemand über die Fehlermeldungen schaut, etwa bei automatisierten Versendern, fällt das vermutlich nicht einmal auf.

Bei einer Domain war mailbox.org als MX eingetragen, bei einer anderen AnonAddy, sprich die MX-Einträge haben sich beim Umzug nicht geändert.

Unter "unterbrechungsfrei" verstehe ich hier, dass die MX-Einträge zu jeder Zeit, also unterbrechungsfrei, auch rekursiv abgefragt werden können. Nach meinen Beobachtungen ist das bei einer Änderung der Nameserver nicht der Fall. Bisher hatte ich dabei immer eine - relativ kurze - Zeitspanne, in der gar kein NS-Eintrag aufgelöst werden konnte und somit gar nichts von der Domain. Somit konnte ein Resolver in der Zeit auch die NS und MX höchstens aus seinem Cache auflösen. Wenn allerdings die TTL abgelaufen ist und er eine rekursive Abfrage machen muss, dann kann er halt in der Zeit nichts auflösen. Ansonsten stehen die Chancen jedenfalls wesentlich besser als wenn sich die MX bei der Aktion ändern würden.

Wie der sendende Mailserver auf das DNS-Desaster reagiert kommt halt darauf an, ob das als permanenter oder temporärer Fehler betrachtet wird.

Bei automatisierten Versendern der Marke günstig (per PHP mail-Funktion) fällt das wohl wirklich nicht einmal auf. Die Senden genau einmal nach dem Motto "den Rest macht der liebe Gott" - oder halt auch nicht . Beim Versand über einen professionellen Massenmailer wird das aber schon ganz anders aussehen.

Die Geschichte mit mailb0x.org hat eventuell noch eine andere Ausfallmöglichkeit. Es fehlt ja nicht nur der MX, sondern auch der TXT-Eintrag, an dem die MXe von mailb0x.org erkennen, ob sie für die Mail überhaupt zuständig sein sollen oder nicht. Wie lange das ohne den TXT-Eintrag weiterfunktioniert weiss ich nicht. Der TXT-Record könnte eventuell zumindest periodisch überprüft werden, vermutlich aber nicht bei jeder ankommenden Mail. Somit stehen hier die Chancen wohl eher gut. Jedenfalls hast du damit schon eine günstige Konstellation.

Zitat von tab

Spannend. Verstehe ich nicht. Ich habe sogar mehrmals die Seite komplett neu geladen. Habe allerdings nach 1 Uhr wohl nicht mehr geschaut, abgelaufen ist abgelaufen - dachte ich zumindest. War aber wohl nicht so. Vielleicht ist es ein Zeitzonenproblem (UTC vs MEZ). Im RSS-Feed habe ich aber von heute auch nur die de-Domain von heute Morgen (7:08). War aber einige Male in den letzten Tagen, dass die englische Version des RSS-Feeds bei mir in Thunderbird zu wirren Zeiten ankam. Vielleicht war es ja das hier, das war die internationale Variante, die Zeiten passen da jedenfalls auch nicht zusammen. Vielleicht sollte ich mal die internationale Seite ausproieren nach Mitternacht. Naja, war nicht so tragisch, ich wollte das Angebot nur nochmal anschauen wegen der Laufzeit.

Code

Received: by localhost; Tue, 17 Dec 2024 12:38:47 +0100
Date: Tue, 17 Dec 2024 06:08:50 GMT

Habe jetzt gerade mal um 0:47 getestet, heute geht das Türchen auf. Entweder haben die Heinzelmännchen das mittlerweile schon korrigiert oder es variiiert je nach Tag oder Angebot.

Ein vollig unterbechungsfreier Umzug ist auf diese Weise sowieso nicht möglich. Allerdings sollte man dabei eigentlich keine Mails verlieren. Zumindest keine, die von einem Mailserver gesendet werden, der den Namen verdient. Da sollten wegen ein paar Stunden Unterbrechung eigentlich keine Mails verloren gehen. Trotzdem sollte das nicht so sein. Wenn man die Werte beim Umzug eintragen kann, dann sollten sie auch zumindest nach dem Umzug in den dann authoritativen Nameservern von netcup im Zonenfile stehen.

Haben sich die MX-Einträge beim Umzug geändert oder sind die selben wie zuvor bei netcup eingetragen worden (inklusive der IP, auf die sie aufgelöst werden)? Ansonsten wird es ja immer so sein, dass in einer Übergangszeit ein Teil der sendenden Server die alten und ein Teil die neuen MXe benutzen wird. Je kürzer die TTL des Eintrags vor dem Umzug, desto kürzer sollte die Übergangszeit sein. Mit der Betonung auf "sollte", nicht alle DNS-Server halten sich daran. Das weltweite DNS wird auch sowieso nicht in Echtzeit upgedatet.

Zitat von Olivetti

»Der Gerät« ist heute angekommen.

[Ach, RAD750 hat ja schon gespoilspoilert]

Liebe Moderatoren und @El_Scheffe,

vielen, vielen Dank für das tolle Paket.

Ja, sehr schön, auch von mir vielen Dank!

Zitat von Virinum

Also ich konnte den VPS 2000 gerade in den Warenkorb legen.

Um 1 Uhr kam aber auch nochmal eine Meldung vom RSS-Fead (auf Englisch). Vielleicht ist zwischen 0 und 1 Uhr eine Lücke.

Spannend. Verstehe ich nicht. Ich habe sogar mehrmals die Seite komplett neu geladen. Habe allerdings nach 1 Uhr wohl nicht mehr geschaut, abgelaufen ist abgelaufen - dachte ich zumindest. War aber wohl nicht so. Vielleicht ist es ein Zeitzonenproblem (UTC vs MEZ). Im RSS-Feed habe ich aber von heute auch nur die de-Domain von heute Morgen (7:08). War aber einige Male in den letzten Tagen, dass die englische Version des RSS-Feeds bei mir in Thunderbird zu wirren Zeiten ankam. Vielleicht war es ja das hier, das war die internationale Variante, die Zeiten passen da jedenfalls auch nicht zusammen. Vielleicht sollte ich mal die internationale Seite ausproieren nach Mitternacht. Naja, war nicht so tragisch, ich wollte das Angebot nur nochmal anschauen wegen der Laufzeit.

Received: by localhost; Tue, 17 Dec 2024 12:38:47 +0100
Date: Tue, 17 Dec 2024 06:08:50 GMT

Zitat von [netcup] Sarah G.

Wie immer ist der Deal bis morgen, 08:00 in der Früh gültig.

Hmm, letztens bei der eu-Domain war das wohl nicht so, das Türchen habe ich nach Mitternacht aufgerufen und das ging dann nicht mehr auf ("Dieses Türchen ist abgelaufen, der Deal ist daher nicht mehr verfügbar). Gleiches gilt heute seit Mitternacht(?) für den VPS 2000 G11 SE. Das nächste Türchen von heute (18.12.) lässt sich erwartungsgemäß noch nicht öffnen. Zwischen 0 Uhr und 8 Uhr gibt es also wohl grundsätzlich keine bestellbaren Deals dieses Jahr. Nicht weiter tragisch, nur zur Info.

Du hast Recht! (selbstverständlich)

Zitat von NaN

Rechnungen kommen jetzt per Brief, oder Paket, je nach Umfang.

Ach, so funktioniert also die Sammelrechnung! Die Einzelrechnungen werden gesammelt und dann gemeinsam per DHLverschickt

Dann schaun wir doch mal (Zustellung voraussichtlich morgen). ..

Tu das! Und stürze dich demnächst nicht wieder kopfüber in ein Abenteuer, wenn du keines suchst! Denn sowas ist IMNSHO grob fahrlässig, Mist, Bullshit - oder suche dir deinen Lieblingsausdruck einfach selbst aus! Prüfe immer vorab, was möglich ist und wie es ggf zu machen ist. Und beschwere dich nicht hinterher, wenn das Kind im Brunnen liegt, dass etwas nicht so funktioniert hat wie von dir stillschweigend vorausgesetzt oder für selbstverständlich erachtet.

Weil die meisten bei yabs gerade im 4K Test hängen? Die Wahrscheinlichkeit für 4K ist jedenfalls größer als für die größeren Blockgrößen. Der 4K Test dauert am längsten von den fio Tests. Naja, ist jetzt sehr weit hergeholt ... hoffentlich . Aber wennes noch mehr solche User gibt wie mich, dann ist der Host jedenfalls durch Tests mehr beansprucht als durch alles Andere.

Also wenn das Domains sind, die für irgendetwas auch nur halbwegs wichtig sind, dann halte ich deine Vorgehensweise für - sagen wir es mal so - mutig. Da würde man doch normalerweise im Vorfeld klären, was wie funktioniert und was eventuell nicht. Wenn es zu kompliziert ist für eine Abklärung durch den Support, dann registriere ich mir eine Domain, mit der ich so einen Umzug 1 zu 1 teste. Wenn ich dann notgedrungen die ganzen auftretenden Schwierigkeiten mitbekomme, dann blase ich entweder den Umzug zu netcup erst einmal ab oder plane ihn zumindest anders, je nach den Ergebnissen des Vorab-Tests. Eventuell mit einem Zwischenschritt über externe Nameserver die kein Glue brauchen und nachfolgender Umstellung auf die eigenen Nameserver mit Glue.

Wenn andere Dienstleister das alles so können wie du es brauchst, warum nicht einfach dorthin umziehen? Denn selbstverständlich ist das durchaus nicht. Ich könnte hier einige deutsche Anbieter aufzählen, bei denen das nicht mal im Ansatz funktionieren würde. Weil sie von vornherein keine eigenen Nameserver mit DNSSEC unterstützen. Eigene Namserver ja, DNSSEC auch ja, aber nicht mit den eigenen Nameservern (Gruß z.B. an den orangenen Anbieter aus Berlin). Manche unterstützen sogar gar kein DNSSEC.

Ich stimme dir aber durchaus gern zu, dass manches im DNS bei netcup nicht zuverlässig funktioniert und großes Verbesserungspotential auch und gerade bei Domainumzügen besteht. Manches was über die starren, automatisierten Abläufe im CCP nicht funktioniert, mag über den Support letztlich schon möglich sein, wenn auch wohl eher kostenpflichtig. Aber dafür ist die Zeit während eines Aktionsmonats schlecht gewählt, bei der wohl ohnehin schon knappen Personaldecke (aber man sucht wenigstens). Sieht man ja auch an den (echten) Support-Reaktionszeiten. Die waren vor den Aktionen schon eher hoch und sind jetzt nochmal drastisch gestiegen. Das gilt nicht für den Notfallsupport, aber der dürfte hier eher nicht zuständig sein.

Derzeit nervt mich das SCP immer wieder mit Nachrichten wie, das ich den Server einmal ausschalten muss, damit die letzten Änderungen wirksam werden. Oder, dass der qemu-guest-agent nicht installiert sei und ich das doch bitte machen soll. Daraufhin habe ich gerade eben versucht, den qemu-guest-agent zu installieren auf dem entsprechenden Server und bekomme die fröhliche Antwort

qemu-guest-agent ist schon die neueste Version (1:7.2+dfsg-7+deb12u7).

und

~# systemctl status qemu-guest-agent.service
● qemu-guest-agent.service - QEMU Guest Agent
     Loaded: loaded (/lib/systemd/system/qemu-guest-agent.service; static)
     Active: active (running) since Mon 2024-12-16 15:24:17 CET; 7min ago

Was ist denn da los? Schmiert der vielleicht irgendwann mal ab? Immerhin nach dem Aus- und Einschalten läuft er wieder und die Message im SCP wird nicht mehr angezeigt. Werde ich mal im Auge behalten. Hmm, sehe gerade, wenn der Server läuft erscheint die Meldung nicht, erst nach dem Runterfahren. Wenn damit gemeint sein soll, dass der qemu-guest-agent gerade nicht aktiv ist, dann ist das erstens nicht was da steht und zweitens eine schöne Binsenweisheit. Wenn der Server nicht läuft, dann halt auch der qemu-guest-agent nicht.

Die Preise der Aktionsprodukte sind alle permanent.

Ja, ist auch korrekt so. (Zumindest) AT, DE und US. Ob Amsterdam auch ein Stück vom Kuchen abbekommen hat weiss ich nicht. Mehrere Subnetze davon sind in DE, also Nürnberg. Ich habe zwei Server in dem Netz in zwei unterschiedlichen Subnetzen. Zumindest der eine hat eine IP aus meinem Nürnberger Cloud VLAN zugewiesen bekommen und kann darüber auch erreicht werden. Der andere kommt auch gleich dran