mit gefaketer Faxnummer aus dem Bundeskanzleramt.
Denkst du echt, von denen könnte sich noch jemand eine Telefonnummer merken?
mit gefaketer Faxnummer aus dem Bundeskanzleramt.
Denkst du echt, von denen könnte sich noch jemand eine Telefonnummer merken?
die Abweisung der Mail dem verhinderten Empfänger zur Kenntnis zu bringen
Wer sollte dies denn tun, bzw wie?
ist da was dran
Nein.
aber es sind Ämter
Da frage ich mich schon lange, wie die dort überhaupt so breit rein gekommen sind (und bleiben).
Gibt es in der IT von Ämtern nurnoch solche Vollhonks als Admins?
Oder sind die mittlerweile ALLE korrupt?
Ja ich weiß der nur für De ist.
Nein, technisch kannst du damit auch .com etc testen.
Aber es geht bei deinem Problem um die NS Delegation und nicht um Fehler in der Zone.
Du musst da also den eventuellen Cache des Denich Tools ausschließen.
ZitatDie TV und Com haben eh noch eine "Uhr" im CCP und kann keine Einstellungen verändern.
Ja, das sollte maximal 1 Stunde andauern.
ZitatLustig ist, dass wo ich jetzt mal bei einer den Hacken für DNSEC gesetzt habe plötzlich die richtigen Nameserver vorhanden sind. Spukie.
Naja, nicht wirklich.
Bei NC sind offensichtlich KK und das immer sofort folgende Update verschiedne Tasks.
Das Problem ist, dass dann das Update noch vielfach schief geht.
Zum Dnssec wird ebenfalls ein Update Task gestartet. Als Einzeltask geht der dann anscheinend durch.
Versuch das also einfach auch mal bei den sonstigen hängenden Vorgängen.
Hatte ich nicht zu entscheiden^^
Mich wundert es nur, unter https://www.denic.de/service/tools/nast/ sind immer noch die alten Nameserver bei der Domain drin... die müssten doch fliegen. Ist schon über 48 Stunden her.
Naja, so lang man es dir dann auch nicht in die Schuhe schiebt...
Mit dem Denic nast solltest du weder tv noch com domains "prüfen".
Das solltest du immer mit dem whois Tool der entsprechenden Registry abfragen.
bei der Arbeit habe ich ein paar Domains zu Netcup umgezogen
Schlechte Idee.
NC kriegt das mit den Domains seit dem Anfang nicht zuverlässig hin.
Selbst mit .de Domains gibt es überdurchschnittlich oft Probleme. Auch nachträglich noch (bei mir werschwand z.B. schon manches mal einfach meine NS Delegation).
Ich benutze NC deshalb nur für "unwichtige" Privatdomains zum Parken.
Na gerade das kann doch auch sehr lecker sein. Notfalls halt am nächsten Tag als Suppeneinlage.
Genau. Noch Knochenmark und Gewürze rein und fertig sind die Markklößchen.
bitte erweitere im Kasten "Suche" links oben den Zeitraum der angezeigten Rechnungen.
Habe ich versucht.
Dann sagt er "Datumsformat falsch".
Seltsam. jetzt geht es wieder.
Vor 10 Minuten kam der Fehler sowohl bei Handeingabe, als auch bei Auswahl über das Dropdown.
Danke. Ist also erledigt.
Schnitzel is billiger
Ein Hundeschnitzel?
Dafür kriegt man doch nichtmal Schwein, geschweige denn Kalb.
Hallo,
seit wann kann man seine Rechnungen nurnoch lediglich 12 Monate lang abrufen?
Das war doch schon länger!
So kann ich ja nicht einmal die Vorjahresrechnungen auf Vollständigkeit prüfen.
Wie teuer sind bei euch denn bitte die Döner? Noch mehr als 5€?!
So 6,50 rum. Und manche lassen sich dann auch noch das billige Huhn andrehen.
Für Zeug das zuverlässig arbeiten muss (Nextcloud in Firma z.B.) ist ECC verdammt wichtig, da keiner will dass mit der Zeit die daten aufgrund eines Falschen Bits kaputt geschrieben werden.
Das Risiko halte ich angesichts der anderen Gefahren für vernachlässigbar.
Immer wieder sehenswert:
wenn wir anfangen über z. b. verschlüsselte oder komprimierte Daten zu sprechen
Wichtige Daten sollten (vom Dateisystem oder Tools) nach dem Speichern "kontrollgelesen" bze überprüft werden.
ECC ist nach meiner Meinung nur z.B. als schneller Cache in Hardware Raid Controllern notwendig.
Dönerfleisch!
Ah, also Vegatarisch?
Ach naja, 15€ sind auch nur 3 Döner im Jahr
Bäääh.
Was ist da denn dann für ein Fleisch drin? Hund?
Die Frage ist natürlich auch immer ob man so wichtige Daten im RAM hat
Potenziell hat man das bei Linux immer, denn der unbenutzte RAM wird als Cache für die Disk i/o benutzt. Ein defektes Ram Bit ergibt also im Zweifel eine fehlerhafte Datei.
Ich hab das nun auch mal getestet (nach ca 600 tagen up):
RS 2000 SSDx4 G8 ADV19
********kvm alt mit hinweis
test: (g=0): rw=randrw, bs=(R) 4096B-4096B, (W) 4096B-4096B, (T) 4096B-4096B, ioengine=libaio, iodepth=64
fio-3.12
Starting 1 process
test: Laying out IO file (1 file / 4096MiB)
Jobs: 1 (f=1): [m(1)][100.0%][r=109MiB/s,w=35.7MiB/s][r=27.9k,w=9140 IOPS][eta 00m:00s]
test: (groupid=0, jobs=1): err= 0: pid=2774: Sun Feb 27 23:00:49 2022
read: IOPS=26.8k, BW=105MiB/s (110MB/s)(3070MiB/29319msec)
bw ( KiB/s): min=58168, max=130088, per=99.87%, avg=107082.53, stdev=11574.85, samples=58
iops : min=14542, max=32522, avg=26770.59, stdev=2893.71, samples=58
write: IOPS=8958, BW=34.0MiB/s (36.7MB/s)(1026MiB/29319msec); 0 zone resets
bw ( KiB/s): min=19424, max=43200, per=99.86%, avg=35785.36, stdev=3882.11, samples=58
iops : min= 4856, max=10800, avg=8946.31, stdev=970.53, samples=58
cpu : usr=9.98%, sys=22.71%, ctx=104855, majf=0, minf=8
IO depths : 1=0.1%, 2=0.1%, 4=0.1%, 8=0.1%, 16=0.1%, 32=0.1%, >=64=100.0%
submit : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
complete : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.1%, >=64=0.0%
issued rwts: total=785920,262656,0,0 short=0,0,0,0 dropped=0,0,0,0
latency : target=0, window=0, percentile=100.00%, depth=64
Run status group 0 (all jobs):
READ: bw=105MiB/s (110MB/s), 105MiB/s-105MiB/s (110MB/s-110MB/s), io=3070MiB (3219MB), run=29319-29319msec
WRITE: bw=34.0MiB/s (36.7MB/s), 34.0MiB/s-34.0MiB/s (36.7MB/s-36.7MB/s), io=1026MiB (1076MB), run=29319-29319msec
Disk stats (read/write):
sda: ios=781891/261318, merge=0/15, ticks=1384146/400852, in_queue=1806108, util=100.00%
***********kvm alt nach reboot
test: (g=0): rw=randrw, bs=(R) 4096B-4096B, (W) 4096B-4096B, (T) 4096B-4096B, ioengine=libaio, iodepth=64
fio-3.12
Starting 1 process
Jobs: 1 (f=1): [m(1)][100.0%][r=109MiB/s,w=35.0MiB/s][r=27.8k,w=9214 IOPS][eta 00m:00s]
test: (groupid=0, jobs=1): err= 0: pid=869: Sun Feb 27 23:09:15 2022
read: IOPS=25.6k, BW=100MiB/s (105MB/s)(3070MiB/30696msec)
bw ( KiB/s): min=68200, max=119912, per=99.83%, avg=102236.59, stdev=12859.19, samples=61
iops : min=17050, max=29978, avg=25559.13, stdev=3214.79, samples=61
write: IOPS=8556, BW=33.4MiB/s (35.0MB/s)(1026MiB/30696msec); 0 zone resets
bw ( KiB/s): min=23984, max=40408, per=99.82%, avg=34166.05, stdev=4153.98, samples=61
iops : min= 5996, max=10102, avg=8541.49, stdev=1038.48, samples=61
cpu : usr=10.62%, sys=25.44%, ctx=82074, majf=0, minf=7
IO depths : 1=0.1%, 2=0.1%, 4=0.1%, 8=0.1%, 16=0.1%, 32=0.1%, >=64=100.0%
submit : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
complete : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.1%, >=64=0.0%
issued rwts: total=785920,262656,0,0 short=0,0,0,0 dropped=0,0,0,0
latency : target=0, window=0, percentile=100.00%, depth=64
Run status group 0 (all jobs):
READ: bw=100MiB/s (105MB/s), 100MiB/s-100MiB/s (105MB/s-105MB/s), io=3070MiB (3219MB), run=30696-30696msec
WRITE: bw=33.4MiB/s (35.0MB/s), 33.4MiB/s-33.4MiB/s (35.0MB/s-35.0MB/s), io=1026MiB (1076MB), run=30696-30696msec
Disk stats (read/write):
sda: ios=790339/262276, merge=0/680, ticks=1468695/401751, in_queue=1882556, util=100.00%
*******kvm neu nach poweroff
test: (g=0): rw=randrw, bs=(R) 4096B-4096B, (W) 4096B-4096B, (T) 4096B-4096B, ioengine=libaio, iodepth=64
fio-3.12
Starting 1 process
Jobs: 1 (f=1): [m(1)][100.0%][r=112MiB/s,w=36.8MiB/s][r=28.6k,w=9409 IOPS][eta 00m:00s]
test: (groupid=0, jobs=1): err= 0: pid=905: Sun Feb 27 23:22:57 2022
read: IOPS=27.4k, BW=107MiB/s (112MB/s)(3070MiB/28657msec)
bw ( KiB/s): min=102224, max=118176, per=99.91%, avg=109602.42, stdev=3412.67, samples=57
iops : min=25556, max=29544, avg=27400.58, stdev=853.17, samples=57
write: IOPS=9165, BW=35.8MiB/s (37.5MB/s)(1026MiB/28657msec); 0 zone resets
bw ( KiB/s): min=34264, max=38992, per=99.91%, avg=36627.44, stdev=1079.53, samples=57
iops : min= 8566, max= 9748, avg=9156.82, stdev=269.90, samples=57
cpu : usr=11.22%, sys=30.13%, ctx=83100, majf=0, minf=7
IO depths : 1=0.1%, 2=0.1%, 4=0.1%, 8=0.1%, 16=0.1%, 32=0.1%, >=64=100.0%
submit : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
complete : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.1%, >=64=0.0%
issued rwts: total=785920,262656,0,0 short=0,0,0,0 dropped=0,0,0,0
latency : target=0, window=0, percentile=100.00%, depth=64
Run status group 0 (all jobs):
READ: bw=107MiB/s (112MB/s), 107MiB/s-107MiB/s (112MB/s-112MB/s), io=3070MiB (3219MB), run=28657-28657msec
WRITE: bw=35.8MiB/s (37.5MB/s), 35.8MiB/s-35.8MiB/s (37.5MB/s-37.5MB/s), io=1026MiB (1076MB), run=28657-28657msec
Disk stats (read/write):
sda: ios=790517/262629, merge=0/70, ticks=1342064/381975, in_queue=1734596, util=100.00%
toller unterschied...