Das längste Thema

Ja, das erinnert mich an etwas, dass ich Ende 1999 für meinen Rechner schreiben musste.

Ausschnitt:

...
restart:
                mov     ah,004h         ; get current BIOS date
                int     01Ah            ;
                lea     bx,base+date    ;
                mov     al,0[bx]        ; fixed year
                cmp     dh,1[bx]        ; month < last month ...
                jge     sameyear        ;
                add     al,1            ; ... => new year
                daa                     ;
                mov     0[bx],al        ; store year
sameyear:
                mov     1[bx],dh        ; store month
                mov     ch,020h         ; 20th century
                mov     cl,al           ; current year
                mov     ah,005h         ;
                int     01Ah            ; rewrite BIOS date
...

»Wer mit SUB Register nullt, hat eh' die Kontrolle über seine Rechenmaschine verloren«

(frei nach Charly Babbage)

des erinnert mich an einen Ralf Brown, der sich a gewaltige Arbeit gemacht hat ...

https://en.wikipedia.org/wiki/Ralf_Brown%27s_Interrupt_List

(aber irgendwie zur falschen Zeit, wie ich Zugang zum Internet hatte,

brauchte ich es nicht mehr, und vorher wie ich keinen Zugang hatte, hätte ich es gebraucht)

Zitat von Olivetti

»Wer mit SUB Register nullt, hat eh' die Kontrolle über seine Rechenmaschine verloren«

(frei nach Charly Babbage)

ja ja die Witzbolde; XOR EAX,EAX macht übrigens des selbe

Sind RHEL8 / AlmaLinux8 / RockyLinux8 User hier? Nutzt jemand die PHP Module aus dem AppStream Repo? Ich wollte gerade bei einem System ein Upgrade von PHP 7.2 -> PHP 7.4 machen. Im Grunde nicht weiter schwierig (dnf module enable php:7.4). Hat soweit auch alles funktioniert. Aber als ich mal genauer hingesehen habe, musste ich feststellen, dass die Version doch etwas sehr alt ist:

PHP 7.4.19 (cli) (built: May  4 2021 11:06:37) ( NTS )
Copyright (c) The PHP Group
Zend Engine v3.4.0, Copyright (c) Zend Technologies

Name         : php
Version      : 7.4.19
Release      : 1.module+el8.5.0+696+61e7c9ba
Architecture : x86_64
Size         : 1.5 M
Quelle       : php-7.4.19-1.module+el8.5.0+696+61e7c9ba.src.rpm
Repository   : appstream
[...]

Das hätte ich jetzt so aus einem RedHat Repo nicht erwartet. So ein bisschen habe ich das Gefühl, dass das mit den Modulen zwar gut gemeint war, aber die praktische Umsetzung doch sehr zu wünschen übrig lässt. Wie seht ihr das?

unterliegt man hier dem "Fehler",

dass zwar die Version als "alt" aufscheint,

dennoch die letzten Patches dabei sind?

war bei CentOS usus

(da war bei CentOS 6 jahrelang die Version von OpenSSL 1.0.1e vom Jahr 2013, obwohl die im Jahr 2018 kräftig gepatcht wurde);

Zitat von mainziman

unterliegt man hier dem "Fehler",

dass zwar die Version als "alt" aufscheint,

dennoch die letzten Patches dabei sind?

Ja, hatte ich zunächst auch gedacht. Aber das "built" Datum ist hier doch recht eindeutig. Da wurde nichts zurückportiert

PHP 7.4.19 (cli) (built: May  4 2021 11:06:37) ( NTS )

FYI: Heute schon an die Verbesserungsmöglichkeiten des eigenen Backup-Konzepts gedacht? [golem.de]

Zitat von m_ueberall

FYI: Heute schon an die Verbesserungsmöglichkeiten des eigenen Backup-Konzepts gedacht? [golem.de]

Falls ich etwas überlesen habe beachtet die nachfolgenden Zeilen nicht. Mal ganz davon abgesehen dass die Forscher absolut nichts dafür können und es wirklich schade wäre wenn die Daten futsch sind:

Kein Backup - kein Mitleid

HPE hat ein großes upsi gemacht

Werde ich nie verstehen. 77 TB an Forschungsdaten. Die hätten den Fileserver ja nur 1:1 spiegeln müssen und hätten zumindest schon mal wenigstens ein Backup gehabt. Am besten in einem anderen Gebäude. Dann noch einmal verschlüsselt in die Cloud und gut ist.

Bei uns in der Firma ist das leider auch immer wieder eine Diskussion, weshalb wir mit Acronis nur einmal in die Cloud sichern. Aber ja, nicht mein Problem. Ich warne immer. Wenn das Geld dafür nicht locker gemacht wird, ist das nicht mein Bier.^^

Zitat von Loxley

Jedenfalls für Neuverträge tun sie das.

Wirklich? gilt das für alle Verträge?

Man muss also Serviceverträge nun jedes Jahr neu abschließen?

Zitat von engine

Werde ich nie verstehen. 77 TB an Forschungsdaten. Die hätten den Fileserver ja nur 1:1 spiegeln müssen und hätten zumindest schon mal wenigstens ein Backup gehabt. Am besten in einem anderen Gebäude. Dann noch einmal verschlüsselt in die Cloud und gut ist.

Bei uns in der Firma ist das leider auch immer wieder eine Diskussion, weshalb wir mit Acronis nur einmal in die Cloud sichern. Aber ja, nicht mein Problem. Ich warne immer. Wenn das Geld dafür nicht locker gemacht wird, ist das nicht mein Bier.^^

spiegelung hilft da aber auch nur sehr begrenzt.
zum einen muss es asynchron sein, zum anderen willst du genug zeit haben fehler zu erkennen und zu beheben, zum anderen willst du aber möglichst synchron sein.

sinnvoller ist da ggf. zwei getrennte backups zu betreiben. das eine kommt zur geraden stundenzahl, das andere zu ungeraden stunden. nur wie weit will man das wieder treiben?

und warum fehlen überhaupt daten, obwohl doch nur das backup gelöscht wurde?

davon ab hat HPE in letzter zeit scheinbar einiges an softwareproblemen... iLO Rootkit, das thema hier, SSDs die nach x Betriebsstunden zu Briefbeschwerern werden und ihre Firmware läuft weder via virtual Media noch iSUT wirklich zuverlässig durch. wildes, wiederholtes klicken hilft dann aber meist.
und oneview ist auch nochmal eine eigene baustelle

erledigt

Neujährliches Reinemachen: Gerade gesehen, dass die längste Statistik nicht mehr geht. Seit Oktober.

• Base Image Rebuild vergessen, weswegen der Parser mit abgelaufenen Lets Encrypt CA Cert hängen geblieben ist
• Migration auf .NET 6 LTS + Debian Bullseye
• Jemand hat einen Post löschen lassen, was der Parser noch nicht unterstützt hat

https://github.com/perryflynn/for…02d7ffdf0..HEAD

Finde es faszinierend, dass ich von .NET Core 2.2 auf .NET 6 rauf bin und meine vor Ewigkeiten gebauten Packages noch alle kompatibel sind. I like. Fast so stabil wie PHP.

Zitat von Paul

Ja, hatte ich zunächst auch gedacht. Aber das "built" Datum ist hier doch recht eindeutig. Da wurde nichts zurückportiert

eindeutig mehrdeutig würd ich sagen, ich würde da meine Hand nicht ins Feuer legen

lt. php.net ist 7.4.27 aktuell, ich würd mir dennoch keine zu großen Gedanken machen;

Eine Info, die vielleicht für alle interssant ist, die öfter mal an den Zeiten (TTL, Retry, Refresh) in der DNS rumschrauben:

Zitat von aRaphael

Ich habe am 21.12. bei der 14ct Aktion eine domain von dort hierher transferiert.

Schien auch alles gut zu laufen, aber seit vorgestern wird die domain nicht mehr aufgelöst. Kein Nameserver kennt sie mehr und wenn ich bei denic nachsehe sind plötzlich wieder (oder sogar immer noch?) die NS von "Sto" eingetragen, obwohl die domain hier liegt. Momentan geht also GARNIX.

Die Ursache war laut Support:

Predelegation Check warning [WARNING: 110 Retry value out of range (expected\, found) (\[900..2400\]\, 3600)]

Der Default-Retry für neue netcup domains liegt allerdings sogar bei 7200, ist also noch höher als der angegebene Maximalwert von 2400

Hab mal kurz recherchiert und festgestellt: Der Retry-Wert ist an den Refresh-Wert gekoppelt.

Ich hatte die TTL runtergesetzt, Retry halbiert auf 3600 und Refresh von 28800 runtergesetzt auf 7200 (Fragt mich bitte nicht wieso )

Das war wohl ein Fehler (Den ich auch bei anderen domains gemacht habe und nun beheben werde)

Denic: "Retry" soll zwischen 1/8 und 1/3 von "Refresh" betragen.

Der Support hat selbst den Retry auf 2400 gesetzt und innerhalb von Minuten waren die netcup-Nameserver und die DNS durchpropagiert und die domain wieder erreichbar. (Ob es nun wirklich daran lag, oder das nur eine Begleiterscheinung war, kann ich natürlich nicht sagen)

Lieber Spamversender: Bitte nutzt nicht den Userpart der E-Mail Adresse zur Pseudo-Anrede im Betreff!

Bildschirmfoto_2022-01-03_18-50-21.png

Ich möchte nicht andauernd den Bildschirm putzen müssen, weil ich während dem Teeschlürfen lautstark lachen musste.

Hmmm.. Ich bin verwirrt.

Habe gerade woanders auf einem neuen Server ein Ubuntu 20.04 Image installiert und dann über die dortige Nutzeroberfläche (analog zum SCP hier) eine ipv6 angelegt.

Und die funktioniert sofort, ohne dass ich etwas auf dem Server konfiguriert hätte. Im netplan-Verzeichnis ist nix zu finden. Im gesamten /etc-Ast ist das verwendete ipv6-Subnetz über grep nicht zu finden.

Wie machen die das?

Cloud Init?

Hab ich mich noch nie mit auseinandergesetzt. Danke für das Stichwort.

(Es ist aber ein dedizierter Server)