Beiträge von SiebenG

    Ich verwende schon seit Jahren kein Bayes mehr, nur noch Blacklists. Default so konfiguriert, dass Nachrichten, die auf zwei Blacklists auftauchen automatisch gelöscht werden. Nachrichten auf einer Blacklist landen dann meistens im Spam Ordner. Der Benutzer kann die Grenzwerte aber einstellen.

    Funktioniert eigentlich super, nur ein paar Newsletter bekommen manchmal einen hohen Score und landen im Spam, liegt aber meist an den Versendern, da gewisse Standards nicht eingehalten werden.

    Warum kein Bayes mehr? Selbst vor KI wurden in Spam immer wieder zu viele "gute" Worte eingebaut, so dass das bei meinen Tests nicht gut funktioniert hat. Seit KI sehe ich auch teils sehr individuell generierten Spam, kaum mehr über Bayes greifbar. Blacklists funktionieren hingegen top, bis auf wenige Ausnahmen, meistens gibt's da mal eine Welle, die dann aber irgendwann auch eingedämmt wird (AWS Apps, Google Groups,..)

    Zusätzlich verwende ich noch clamav mit fangfrisch um mails bei der Einlieferung abzuweisen (v.a. malware links), da kann man aber sicherlich über den Nutzen streiten. Frisst leider auch sehr viel RAM (auf 4GB lief es nicht mehr sehr rund) und es gibt auch immer mal ein paar falsch-positive

    Wenn du es noch simpler halten willst, könntest du noch den @ IN CAA 0 issuewild "letsencrypt.org" entfernen. Der ist in diesem Fall überflüssig:

    https://letsencrypt.org/docs/caa/#the-…wild-properties

    Richtig. Und wenn man es noch simpler möchte, kann man auch

    @ IN CAA 0 iodef "mailto:jemand@beispiel.de"

    weglassen. Die meisten Authorities versenden sowieso keine Berichte, und mich interessiert es auch herzlich wenig, wenn jemand versucht bei einer Zertifizierungsstelle ein Zertifikat ausstellen zu lassen und das fehlschlägt. Macht eh keiner, kostet ja Kohle.

    NETCUP_IPv6_Präfix::5060/64

    Ergibt so keinen Sinn. Falls die Geräte ID angegeben wird (hier 0000:0000:0000:5060) dann einfach die Netzmaske weglassen (zur Not /128), oder falls das ganze Netzwerk gemeint ist, dann NETCUP_IPv6_Präfix::1/64.

    5060 Sieht auch verdächtig nach einem SIP Port aus, vielleicht ging Dir da was durcheinander?

    Bei meinen Domains die ich bei Netcup habe läuft der DNS bei Desec. Da gibt es diese Probleme nicht

    Ja, aber auch da musste ich den Timeout hochdrehen. Mit dem default-Wert von 80 Sekunden klappt es jedenfalls bei mir auch nicht, ich habe den auch auf 300 sekunden hochschrauben müssen, damit es stabil läuft... Manche caching ns spielen das 60-Sekunden-TTL-Spiel einfach nicht mit...

    Stay secure for another year
    Your Windows 10 Extended Security Updates (ESU) protection has been extended
    We understand that moving to a new PC can take time. As part of our ongoing commitment to helping customers stay secure during the transition, the Windows 10 Extended Security Updates (ESU) program for personal devices is being provided an additional year. Coverage will now be available through October 12, 2027.

    As a current user enrolled in ESU, you will automatically receive an additional year of protection. No action is required on your end, the extension will be automatic.

    Ich verwende kein Live-Patching. Ich bekomme eine Nachricht von unattended upgrades, sobald der Server neu gebootet werden möchte, und das erledige ich dann recht zeitnah.

    Soweit ich das Live-Patching verstanden habe ist der Vorteil nur, dass du nicht "sofort" neu booten musst und die Zeit vom Einspielen des neuen Kernels bis zum Reboot der Patch schon 'live" ist. Allerdings basieren die Live-Patches ja auf den debs, daher meine Aussage, dass das Live-Patching nicht so viel bringt, wenn das Ubuntu Kernel Team Wochen braucht, die Patches zu erstellen(*)

    Da ich dazu gerade keine gute Internetquelle gefunden habe, habe ich nochmal die KI meines Vertrauens befragt und die bestätigt, dass die Live-Patches zeitgleich mit den neuen Kernelpaketen oder kurz danach veröffentlicht werden.

    (*) Ich bin mir auch nicht ganz sicher, ob die Verzögerung immer durch das Kernel-Team entsteht, die offizielle Linie von Ubuntu ist ja nur alle 4 Wochen einen Kernel zu releasen, außer bei gaaaaaanz kritischen CVEs, da darf dann auch nach zwei Wochen ein Fix kommen (https://documentation.ubuntu.com/kernel/explana…elease-updates/). Ich hatte in den letzten Monaten bei den ganzen Bugs öfter mal aufs build-Datum geschaut und mir sah das so aus, dass im Moment ziemlich genau alle 4-6 Wochen ein neuer Kernel kommt. 2 Wochen habe ich noch nie gesehen.

    Entschuldige, falls das falsch rüber gekommen ist. Ich wollte keine Grundsatzdiskussion zwischen Debian/Ubuntu vom Zaun brechen, sondern auf folgendes Bezug nehmen:

    Inzwischen sind zeitkritische Kernel-Sicherheitsupdates für mich jedoch wichtiger geworden

    Wenn Du bei Ubuntu bleiben musst und schnell Kernelpatches einpflegen willst, solltest Du Dir den Stockkernel selbst kompilieren . Mit dem Live-Patching kommen sicherheitskritische Updates erst 3-4 Wochen später.

    Ich weiß, Du willst hier was anderes hören (daher höre ich jetzt auch auf mit meinen Kommentaren), ich wollte nur loswerden, dass die Frage "Live-Patching oder nicht" bei sicherheitskritischen Anforderungen eigentlich irrelevant ist.

    Keine direkte Erfahrung, nur eine generelle Einschätzung: Falls Dir eine zeitnahe Behebung von Kernelbugs wichtig ist, auf jeden Fall von Ubuntu Abstand halten. Deren Strategie, neue Kernel nur alle paar Wochen zu releasen, auch bei kritischen Schwachstellen,, muss man mögen.

    Oder anders ausgedrückt: Wenn Dein Kernel sowieso drei Wochen nicht gepatched und verwundbar ist, dann ist's eigentlich auch egal ob er dann ge-live-patched wird oder Du nach 2 Tagen einen manuellen reboot machst... dann lieber ein Debian stable, Schwachstellen nach 2 Tagen gepatched und ein manueller oder geteiggerter reboot.

    Es gibt Neuigkeiten für die Orakel Free Tier/PAYG Benutzer, seit heute, 1.7. gilt:

    Always Free Ampere A1 Compute limits have changed to 2 OCPUs and 12 GB of memory, review your current usage and update or re-provision instances to stay within the new limits.

    D.h. FreeTier Benutzer sollten schnell downgraden, sonst geht die VM ab Monatsmitte aus. PAYG Benutzer sollten noch schneller downgraden, sonst wird's teuer.

    E-mail Info gab es keine, das Banner ist aber beim Einloggen in der OCI sichtbar.

    Ah ok, joa mal gucken.
    Auch wo es steht. mit den Kosten.

    hab ja die Hoffnung das sie Bestandssysteme so lassen.

    Mal ein Update dazu. Bei meinem Orakel Account werden mir immer noch die alten Limits als kostenlos angezeigt (4 Kerne, 24GB RAM). Scheint also so zu sein, dass Bestandssysteme tatsächlich Bestandsschutz genießen.

    Gibt mittlerweile sogar eine Aussage vom Support dazu: https://www.reddit.com/r/oraclecloud/…une2026_update/

    Also vermutlich nochmal Glück gehabt :)

    Wenn Du im Rescue system entschlüsseln kannst, dann ist das ja erstmal ein gutes Zeichen. Andere Klassiker neben der Keymap sind noch nicht geladene Kernel Module oder der Wechsel von luks1 zu luks2.

    Falls Du beim booten mit dropbear entschlüsselst, schau mal ob im initramfs die notwendigen Module mit drin sind.

    Die Geschichte mit luks1 zu luks2 ist schon ein paar Jahre her, sollte aber eigentlich auch nur bei einem release Upgrade auftreten. Wie Du die luks version auslesen kannst, verrät dir sicher die KI deines Vertrauens ;) Den Spaß hatte ich auch mal bei einem Debian release Upgrade, musst dann leider die Partition komplett neu anlegen mit luks2.

    Edit: Scheinbar doch ein Free Account?

    Das müsste ein PAYG sein, das free trial sind die ersten 30 Tage, in denen man die $300 verballern darf.

    Bei mir steht da

    Plan type Free Tier

    Solange Du das morgen direkt abschaltest sobald Kosten auflaufen, kommen ja nur ein paar Cent zusammen..

    Einen PAYG Account muss man ohnehin anlegen um dann die Free Tier Ressourcen nutzen zu können, ohne Zahlungsmittel-Verifikation gibt dir O*acle denke ich schon länger keine Free Tier Ressourcen mehr.

    Stimmt, mittlerweile ist das so. Gibt aber viele, die noch die alten Accounts haben und keine Kreditkarte hinterlegt haben, bei denen klappt das dann halt nicht.

    Ich bin mir auch nicht sicher, ob ich dort eine KK hinterlegen würde , gerade die Aktion jetzt den Kunden dann ohne Email einfach mal $27 zu belasten, zeigt mir kein großes Vertrauen in eine Firma.

    Ich habe meine Instanz mal vorsorglich auf 2 Cores / 12GB RAM reduziert. Wir werden sehen was wirklich passiert.

    Ich lass meine mal und schau was mit existierenden passiert. Steht ja nirgends, dass die runtergefahren werden, wie es der Support einem Reddituser erzählt hat...

    Ist wirklich schade, die Micros sind schon vor einem Jahr so langsam geworden, dass sie kaum mehr verwendbar sind und jetzt ist auch noch der ARM dran... Erst vor kurzem die Bandbreite auf 50 Mbits reduziert und jetzt das...

    Wenn die so weitermachen verlieren die mich als nicht-zahlenden Kunden 8o