FreeBSD 14.0 RELEASE

Software Sisteme de Operare
1

FreeBSD 14.0-RELEASE Announcement
Date: November 20, 2023

The FreeBSD Release Engineering Team is pleased to announce the availability of FreeBSD 14.0-RELEASE. This is the first release from the stable/14 branch.

Some of the highlights:

  • OpenSSH has been updated to version 9.5p1.
  • OpenSSL has been updated to version 3.0.12, a major upgrade from OpenSSL 1.1.1t in FreeBSD 13.2-RELEASE.
  • The bhyve hypervisor now supports TPM and GPU passthrough.
  • FreeBSD supports up to 1024 cores on the amd64 and arm64 platforms.
  • ZFS has been upgraded to OpenZFS release 2.2, providing significant performance improvements.
  • It is now possible to perform background filesystem checks on UFS file systems running with journaled soft updates.
  • Experimental ZFS images are now available for AWS and Azure.
  • The default congestion control mechanism for TCP is now CUBIC.
    And much more …
1 Like
2

Frumos.

Cele mai importante noutati mi se par cele legate de criptare:

  • Two new daemons, rpc.tlsclntd(8) and rpc.tlsservd(8), are now built by default on amd64 and arm64. They provide support for NFS-over-TLS as described in the Internet Draft entitled “Towards Remote Procedure Call Encryption By Default”. These daemons are built when WITH_OPENSSL_KTLS is specified. They use KTLS to encrypt/decrypt all NFS RPC message traffic, and provide optional verification of machine identity via X.509 certificates. 2b9cbc85d727 59f6f5e23c1a
  • KTLS (the kernel TLS implementation) has added receive offload support for TLS 1.3. Receive offload is now supported for TLS 1.1 through 1.3; send offload is supported for TLS 1.0 through 1.3. 05a1d0f5d7ac (Sponsored by Netflix)
1 Like
3

Si ceva probleme pentru cei care fac update : Upgrading to FreeBSD 14 - how to fix a broken BIOS bootcode

4

Ai dreptate Alex, aceea este o problemă majoră pentru utilizatorul individual (EndUser).

Însă nu ar trebui să fie o problemă pentru un profesionist din zona IT, care nu ar trebui să procedeze orbește la upgradarea sistemului de fișiere pe mașini aflate în producție, fără testare prealabilă.

O problemă, pe care eu o găsesc mult mai gravă, este acest bug prezent în ultima versiune a zfs integrată și în FreeBSD. Aici este vorba de coruperea datelor în anumite operațiuni de copiere, corupere care nu este ușor identificabilă și poate trece nedetectată pentru mult timp.

Este foarte probabil ca focusul unei baterii de teste, prealabile unei operațiuni de upgrade, să nu fie coruperea datelor, fie și pentru că testele respective sunt concepute inclusiv pe baza stabilității zfs și a pretențiilor de integritate a datelor oferită de folosirea sumelor de control (checksum).

Pentru a mimimiza și mai mult riscul (destul de scăzut) de a fi afectat de acest bug:
În cazul FreeBSD se recomandă executarea ca root a următoarelor comenzi:
– as root:
sysctl vfs.zfs.dmu_offset_next_sync=0
– and also as root, add to /boot/loader.conf:
vfs.zfs.dmu_offset_next_sync=0

Pentru Linux comenzile ar fi:
echo 0 > /sys/module/zfs/parameters/zfs_dmu_offset_next_sync
and on Kernel command line:
zfs.zfs_dmu_offset_next_sync=0
Pentru persistență la porniri ulterioare (reboot) trebuie editat corespunzător fișierul /etc/modprobe.d/zfs.conf sau similar, în funcție de distribuția Linux folosită.

Mai multe informații despre bugul zfs:

  • se pare că bugul respectiv este mult mai vechi - cel puțin 18 luni !!!
  • rata de incidență este foarte mică, este necesar un cumul de condiții și operațiuni specifice prezente simultan (de exemplu: copiere de tip sparse, scriere simultană, multiple procese paralele) pentru activarea bugului;
  • operațiunea zfs scrub nu evidențiază defectele - datele scrise sunt consistente însă pot fi corupte - pot fi corupte de o operațiune de citire efectuată exact înainte de scriere, în contexte particulare - coruperea datelor nu este vizibilă;
  • implementarea în zfs a tehnologiei de clonare la nivel de bloc de date (block cloning) a crescut rata de incidență a acestui bug și a ajutat la creșterea vizibilității acestuia, însă nu este responsabilă de apariția acestui bug;
  • setarea parametrului zfs_dmu_offset_next_sync la valoarea 0 nu elimină complet cazurile de incidență ale bugului respectiv, însă ajută micșorând cu cel puțin un ordin de mărime rata de incidență deja foarte mică a bugului respectiv.

Pentru mai multe informații puteți urmări și discuția de pe HackerNews.

5

Cum ar zice un pretin bun, “sounds kinky”. Eu unul personal am migrat ~ 1 an de zile pe un setup mult mai simplu in care nu mai folosesc *BSD sau ZFS, am backup extern la ce este important pentru mine iar restul datelor sunt considerate disposable / easy replaceable .

6