• Diese Seite verwendet Cookies. Indem du diese Website weiterhin nutzt, erklärst du dich mit der Verwendung von Cookies einverstanden. Erfahre mehr

FreeBSD 12.0 erschienen

medV2

Well-Known Member
#29
Coole Sache. Ich hab auf meinem Hauptrechner schon seit ein paar Tagen die Version 12 drauf und wie zu erwarten gab es keine Probleme.

Es gibt viele gute Neuerungen. Die persönlich mit am interessanteste finde ich aber die hier:

Ich verfolge jetzt Capsicum (man capsicum) schon eine ganze Weile und finde es ein gutes Framework für mehr Security und freue mich daher, dass es inzwischen innerhalb von FreeBSD breitere Anwendung findet.


Kürzere Releasezyklen haben aber den Vorteil, dass man bei einem neuen Release dann nicht so viele Änderungen hat und dementsprechend beim Upgrade auch weniger, was dabei kaputt gehen kann. Falls wirklich mal was kaputt geht, ist es i.d.R. auch schnell gefixt.
Abgesehen davon das ja mit neuen Releases auch neue Funktionen z.B. in Hinblick von Security kommen. Viele Einbrüche kommen ja da her, dass irgendwo ein altes System steht was aber keiner mehr anfassen weil sonst zusammenbrechen würde es aber auch gleichzeitig löchrig wie ein Schweizer Käse ist.
Das ist so wie mit dem Mann der aus dem Hochhaus springt und bei jedem Stockwerk sagt: Na bis hier hin ging es gut.

Und wenn wir mal ehrlich sind: Firmen lieben vor allem deshalb lange Releasezyklen, weil die oftmals einfach ihre internen Prozesse schlecht organisiert haben. Da "nerven" Upgrades natürlich.

Wir haben immer noch mit einem unausrottbaren Phänomen zu tun. IT ist zwar heute für fast jede Firma überlebenswichtig, aber sie wird trotzdem häufig nach wie vor stiefmütterlich behandelt. Und da liegt das Problem.

Für eure kaputte IT kann FreeBSD am allerwenigsten.

Ich muss halt in der Realität arbeiten und da haben 90% der Firmen in deren IT ich tieferen Einblick hatte "schlechtes Prozessmanagement". Da hilft es mir nichts mich hinzustellen und zu erklären das man alles viel besser machen könnte. Und in Wirklichkeit ist es halt so, bei kürzeren Releasezyklen nimmt man das Produkt im besten fall garnicht, oder es bleibt ungepatched stehen weil keiner die Zeit dafür hat. Jaja, mehr Personal, bessere Leute und überhaupt aber es geht halt meist nicht, wie du schon geschrieben hast, die IT wird oft stiefmütterlich behandelt und solange nichts schief geht...

Aber auch im eigenen Haus bin ich schlicht froh, wenn ich über ~30 Maschinen nicht jährlich Releaseupates machen muss. Selbst WENN alles gutgeht, und ja mit kürzeren Zyklen ist die Chance besser, muss ich danach alles Testen, was so oder so Zeit kostet. Zudem bietet es sich bei langen Zyklen an, das ganze System im Zuge eines Hardwaretausches zu machen.




Ad Encryption: Ich hätte auch sehr stark gehofft, brauch das auf einem System, hatte auch lange PEFS im Einsatz, mir war das aber bei vielen Schreiboperationen zu langsam, daher musste ich jetzt den umweg zvol -> geli- > ufs gehen..
Vielleicht find ich mal demnächste die Zeit, die patches zu Testen. Welche Secrity-Einwände stehen da im Raum @Yamagi ?.
 

mr44er

Well-Known Member
#31
Nachtrag:
Code:
root@asus1:/usr/home/mr44er # cbsd bhyve-ppt mode=attach ppt=2/0/0 jname=opnsense
I/O MMU / VT-d not enabled. Check you hardware or BIOS setting
Die Meldung kommt reichlich 'spät' im Einrichtvorgang...erstmal rumspielen, dann weitersehen. :rolleyes: Ich weiß, dass man im Vorfeld abfragen kann, ich wusste es aber nicht genau, weil nichts passierte und das BIOS nix hergab, aber Willi wollts wissen. Wird auf passender HW nachgeholt.

kannst du Überprüfen ob es funktioniert hat.
cpucontrol -v -u /dev/cpuctl0

Die Ausgabe hat funktioniert, gab aber kein Update. Die CPU ist auch eher Nische, AMD, lahm und alt! :)
 

jmt

Well-Known Member
#32
Gibt es einen neueren Treiber für Realtek Netzwerkkarten? Oder muss man immer noch den Treiber von Realtek nehmen? Der alte Treiber war mindestens unter Last instabil...
 

mr44er

Well-Known Member
#33
Genau das ist aber ein (Security-)Problem wenn Du virtuelle Maschinen hast. Die könnten über den Umweg PCI-Gerät Speicheradressen lesen/manipulieren, die ihnen gar nicht gehören.
Nachtrag2:
Ich hab jetzt rein zum Spielen opnsense als vm in bhyve reingehockt. Wegen nicht vorhandenem IOMMU trotz hw.vmm.amdvi.enable=1 konnte ich die NIC nicht als pptdev durchreichen.
Wenn ich dich richtig verstanden habe, habe ich damit den von dir beschriebenen Fall: Wenn ich von einer physikalischen NIC eine einfache hostbridge in eine bhyve-vm hineinlege (und damit eben auf dem Host sichtbar bleibt)?
 

Yamagi

Possessed With Psi Powers
Mitarbeiter
Themenstarter #34
Ad Encryption: Ich hätte auch sehr stark gehofft, brauch das auf einem System, hatte auch lange PEFS im Einsatz, mir war das aber bei vielen Schreiboperationen zu langsam, daher musste ich jetzt den umweg zvol -> geli- > ufs gehen..
Vielleicht find ich mal demnächste die Zeit, die patches zu Testen. Welche Secrity-Einwände stehen da im Raum @Yamagi ?.
Also, Oracles Verschlüsselung war totaler Schmonz, da sie einen Großteil der Metadaten nicht verschlüsselte. Aber die ist ja niemals offiziell im Source veröffentlicht worden und daher sowieso nicht verfügbar. Die Patches portieren die im Rahmen von ZFS on Linux entwickelte Verschlüsselung, die ein Dataset vollständig verschlüsselt. Also Daten und Metadaten. Allerdings bleiben die global im Pool gespeicherten Transaktionsgruppen unverschlüsselt, wodurch ein kleiner Teil der Metadaten an der Verschlüsselung vorbei lecken kann. Schlimmer und deutlich umstrittener ist, dass die Verschlüsselung alle Blöcke mit dem gleichen Initialization Vetcor verschlüsselt. Dadurch wird die Verschlüsselung theoretisch für eine ganze Reihe Angriffe, praktisch mindestens für Watermarking Attacken anfällig. Daran scheiden sich die Geister. Die Crypto-Puristen sagen, dass die ganze Geschichte damit Schlangenöl ist und man sie besser gleich vergessen sollte. Die Pragmatiker einschließlich der Entwickler der Patches argumentieren, dass die Verschlüsselung immer noch besser und sicherer als gestackte Verschlüsselung durch encfs, pefs und co. ist. Außerdem könnte man sehr wohl einen eigenen Intitialization Vector pro Block nutzen und würde nur einige selten genutzte ZFS Features verlieren. Dedup ginge nicht mehr, mehrere Kopien eines Block vorzuhalten würde im Aufwand linear steigen.

Auf Linux waren die Sicherheitsbedenken weitgehend egal, ZFS on Linux hat eh keine Chance jemals in den Mainline-Kernel zu kommen und ist daher nicht an dessen Vorgaben gebunden. Unter FreeBSD sieht es aber anders aus. Dessen Security Team war in der Vergangenheit immer konservativ und hat sich oft gegen Features entschieden, wenn es begründete Sicherheitsbedenken gab. Sozusagen der Präzedenzfall in den letzten Jahren waren die Unterstützung von GHOST. GHOST wurde von mehreren einflussreichen Firmen, die FreeBSD einsetzen, gefordert. Und es gab eine lautstarke Gruppe Nutzer, die es haben wollte. Dennoch hat das Security Team klar entschieden, dass GHOST kein Teil von FreeBSD werden wird.
Die ZFS Verschlüsselung ist irgendwo in der Mitte. Sie ist sicherlich für einen Großteil der Nutzer sicher genug, aber eben unsicherer als geli. Man kann nun argumentieren, dass sie in jedem Fall besser als pefs und co. ist und damit einen Sicherheitsgewinn bringt. Aber eben auch, dass man einem unbedarften Nutzer ein potentiell unsicheres Feature an die Hand gibt. Wo die Reise hingeht ist schwer zu sagen.
 

Yamagi

Possessed With Psi Powers
Mitarbeiter
Themenstarter #35
kannst du Überprüfen ob es funktioniert hat.
Das Microcode-Update steht nun auch in der dmesg. Auf meiner Skylake-Box:

Code:
---<<BOOT>>---
Copyright (c) 1992-2018 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
        The Regents of the University of California. All rights reserved.
FreeBSD is a registered trademark of The FreeBSD Foundation.
FreeBSD 12.0-RELEASE 952c9691f1b(releng/12.0) GENERIC amd64
FreeBSD clang version 6.0.1 (tags/RELEASE_601/final 335540) (based on LLVM 6.0.1)
VT(efifb): resolution 1024x768
CPU: Intel(R) Core(TM) i7-6700K CPU @ 4.00GHz (4008.17-MHz K8-class CPU)
  Origin="GenuineIntel"  Id=0x506e3  Family=0x6  Model=0x5e  Stepping=3
  Features=0xbfebfbff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE>
  Features2=0x7ffafbbf<SSE3,PCLMULQDQ,DTES64,MON,DS_CPL,VMX,EST,TM2,SSSE3,SDBG,FMA,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,TSCDLT,AESNI,XSAVE,OSXSAVE,AVX,F16C,RDRAND>
  AMD Features=0x2c100800<SYSCALL,NX,Page1GB,RDTSCP,LM>
  AMD Features2=0x121<LAHF,ABM,Prefetch>
  Structured Extended Features=0x29c6fbf<FSGSBASE,TSCADJ,SGX,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM,NFPUSG,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PROCTRACE>
  Structured Extended Features3=0x9c000000<IBPB,STIBP,L1DFL,SSBD>
  XSAVE Features=0xf<XSAVEOPT,XSAVEC,XINUSE,XSAVES>
  VT-x: PAT,HLT,MTF,PAUSE,EPT,UG,VPID
  TSC: P-state invariant, performance statistics
real memory  = 34359738368 (32768 MB)
avail memory = 33281839104 (31740 MB)
CPU microcode: updated from 0x74 to 0xc6 <--------------------------- Hier
Event timer "LAPIC" quality 600
ACPI APIC Table: <ALASKA A M I>
FreeBSD/SMP: Multiprocessor System Detected: 8 CPUs
FreeBSD/SMP: 1 package(s) x 4 core(s) x 2 hardware threads
random: unblocking device.
 

holgerw

Well-Known Member
#37
Das Microcode-Update steht nun auch in der dmesg. Auf meiner Skylake-Box:

Code:
---<<BOOT>>---
Copyright (c) 1992-2018 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
        The Regents of the University of California. All rights reserved.
FreeBSD is a registered trademark of The FreeBSD Foundation.
FreeBSD 12.0-RELEASE 952c9691f1b(releng/12.0) GENERIC amd64
FreeBSD clang version 6.0.1 (tags/RELEASE_601/final 335540) (based on LLVM 6.0.1)
VT(efifb): resolution 1024x768
CPU: Intel(R) Core(TM) i7-6700K CPU @ 4.00GHz (4008.17-MHz K8-class CPU)
  Origin="GenuineIntel"  Id=0x506e3  Family=0x6  Model=0x5e  Stepping=3
  Features=0xbfebfbff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE>
  Features2=0x7ffafbbf<SSE3,PCLMULQDQ,DTES64,MON,DS_CPL,VMX,EST,TM2,SSSE3,SDBG,FMA,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,TSCDLT,AESNI,XSAVE,OSXSAVE,AVX,F16C,RDRAND>
  AMD Features=0x2c100800<SYSCALL,NX,Page1GB,RDTSCP,LM>
  AMD Features2=0x121<LAHF,ABM,Prefetch>
  Structured Extended Features=0x29c6fbf<FSGSBASE,TSCADJ,SGX,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM,NFPUSG,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PROCTRACE>
  Structured Extended Features3=0x9c000000<IBPB,STIBP,L1DFL,SSBD>
  XSAVE Features=0xf<XSAVEOPT,XSAVEC,XINUSE,XSAVES>
  VT-x: PAT,HLT,MTF,PAUSE,EPT,UG,VPID
  TSC: P-state invariant, performance statistics
real memory  = 34359738368 (32768 MB)
avail memory = 33281839104 (31740 MB)
CPU microcode: updated from 0x74 to 0xc6 <--------------------------- Hier
Event timer "LAPIC" quality 600
ACPI APIC Table: <ALASKA A M I>
FreeBSD/SMP: Multiprocessor System Detected: 8 CPUs
FreeBSD/SMP: 1 package(s) x 4 core(s) x 2 hardware threads
random: unblocking device.
Hallo Yamagi,

heißt das, es braucht nur noch das Paket devcpu-data, ohne enable Eintrag in der rc.conf?
Oder ist sogar das Paket nun überflüssig?
 

solarix

Konsolenpenner
#39
Coole Sache. Ich hab auf meinem Hauptrechner schon seit ein paar Tagen die Version 12 drauf und wie zu erwarten gab es keine Probleme.


Und wenn wir mal ehrlich sind: Firmen lieben vor allem deshalb lange Releasezyklen, weil die oftmals einfach ihre internen Prozesse schlecht organisiert haben. Da "nerven" Upgrades natürlich.

Wir haben immer noch mit einem unausrottbaren Phänomen zu tun. IT ist zwar heute für fast jede Firma überlebenswichtig, aber sie wird trotzdem häufig nach wie vor stiefmütterlich behandelt. Und da liegt das Problem.

Für eure kaputte IT kann FreeBSD am allerwenigsten.
JEIN..... Mag alles sein.... das Prozesse scheisse sind... seh ich oft genug, brauchen wir gar nicht zu diskutieren.
Trotzdem ist es für den Produktivbetrieb, wichtig das man eine stabile Plattform hat, die auch berechenbar ist. Was ja oft eine Kritik an Linux ist, weil die öfters mal gern API's und ABI's brechen.

Ohne Long Term Support (wie auch immer der dann aussieht) brauchst Du bei keiner Firma eine Plattform ausrollen, die möglichst langlebig ist.
Die Kunden werden Dich lynchen.

Im übrigen geht es nicht nur darum das irgendwelche Wald und WIesen Applikationen wie ein paar schimmelige Web oder Mailserver mit ein paar Wordpress Blogs oder sonstigem Spielzeug laufen, sondern auch noch um ganz andere Themen.

FreeBSD selbst ist eine wunderbare Plattform, aber Du wirst es bei keinem Kunden irgendwo platzieren können, wenn Du nicht möglichst
lange Support dafür anbieten kannst.

Nicht alle Kunden haben eine so potente und kompetente IT wie z.B. Netflix oder wegen mir noch Yahoo, die im großen Stil FreeBSD einsetzen.
Geh mal zu einem Autobauer.
Dort bist Du schon happy wenn das Betriebsteam es schafft sich an der Shell mittels Putty anzumelden und
/var/log
/var/adm
/opt
findet.
Aber ich kann Dir versichern, bei den Autobauern findest Du mindestens genau so viel Unix/LInux wie bei den Banken.

In den letzten Jahren hätte ich einige Szenarien gehabt wo FreeBSD die Lösung gewesen wäre.... man konnte es aber nicht nehmen
wegen den kurzen Supportzeiten....

Für mich ist FreeBSD abgesehen von Solaris, vielleicht das sauberste und professionellste System, dem leider der kommerzielle Support völlig fehlt und damit bist Du leider auf dieses IKEA System namens Linux angewiesen. Nur mal so nebenbei. :)
 

foxit

Moderator
Mitarbeiter
#41
Kurz zusammengefasst gibt es recht konkrete Pläne vom langsam sterbenden Illumos auf ZFS on Linux als Upstream zu wechseln.
Ohje ohne jetzt wieder der Buhmann zu sein: Wie lange wird es dauern, bis die Linux Leute wieder auf die Kompatibilität scheissen werden und wieder nur ihr Ding durchziehen? Ich dachte mit OpenZFS sei das erledigt?
 

Yamagi

Possessed With Psi Powers
Mitarbeiter
Themenstarter #42
Naja, die Sache ist halt, wie Matthew Macy schon schreibt, dass mit Delphix die mit Abstand größte zu ZFS beitragende Firma zu ZoL gewechselt ist. Und Illumos ging es auch schon mal besser... Kurz gesagt, man kann entweder wieder sein eigenes Ding machen oder sich mit ZoL verbünden.
 

-Nuke-

Well-Known Member
#43
Ohje ohne jetzt wieder der Buhmann zu sein: Wie lange wird es dauern, bis die Linux Leute wieder auf die Kompatibilität scheissen werden und wieder nur ihr Ding durchziehen?
Da ein Dateisystem ziemlich eng mit dem Kernel verbunden ist, wenn man auch etwas Performance haben will, ist es zwangsläufig so, dass man auch Teile hat die nur mit dem jeweiligen Kernel funktionieren. ZoL hat z.B. auch noch kein TRIM Support was bei FreeBSD schon seit Jahren enthalten ist. Ist also nicht so als wenn die Codebasis von FreeBSDs ZFS hier immer hochgradig portabel war.

Ich dachte mit OpenZFS sei das erledigt?
OpenZFS ist eine Format/Feature-Beschreibung.
 

foxit

Moderator
Mitarbeiter
#44
Kurz gesagt, man kann entweder wieder sein eigenes Ding machen oder sich mit ZoL verbünden.
Also Pest oder Cholera.
Ist also nicht so als wenn die Codebasis von FreeBSDs ZFS hier immer hochgradig portabel war.
Das ist klar. Ich warte aber nur auf das erste "Feature", dass beim Linux Code umgesetzt wird, es dann essentiel wird und nicht auf andere OS migriert werden kann. Dann heisst es wieder für FreeBSD friss oder stirb. Da ist es dann auch wieder egal ob es Open Source ist oder nicht.
 

Andy_m4

Well-Known Member
#45
Ich warte aber nur auf das erste "Feature", dass bei Linux Code umgesetzt wird, es dann essentiel wird und nicht auf andere OS migriert werden kann.
Oh-ha. Du lässt ja wenig gutes Haar an Linux bzw. dem Linux-Umfeld. :-)
Dabei müsste man doch denken, "die bei Linux" machen alles richtig. Der Erfolg ist ja immerhin deutlich erkennbar.
 

-Nuke-

Well-Known Member
#46
Das ist klar. Ich warte aber nur auf das erste "Feature", dass beim Linux Code umgesetzt wird, es dann essentiel wird und nicht auf andere OS migriert werden kann. Dann heisst es wieder für FreeBSD friss oder stirb. Da ist es dann auch wieder egal ob es Open Source ist oder nicht.
Also hätte FreeBSD TRIM oder die Jail<->ZFS interops nicht implementieren dürfen, weil das aktuell unter Linux nicht funktioniert? ;)
 

foxit

Moderator
Mitarbeiter
#47
@Nuke
Darum gehts doch gar nicht. Kannst du dich noch daran erinnern, wie "plötzlich" alle Linux Treiber KMS vorraussetzten und FreeBSD dadurch keine aktuellen Grafiktreiber mehr hatte? Heute noch leidet man unter dieser Situation. Das sollte man aber alles in einem anderen Thread besprechen!
 

medV2

Well-Known Member
#48
Mir macht eher sorgen, das ZoL doch noch nicht so stabil wie ZFS auf FBSD ist. Auch gibt es immer wieder Releases mit teils gravierenden Bugs.
 

ralli

BSD Fanboy
#50
Leider läuft bei mir FreeBSD 12 nicht, weil es sich bei mir nicht installieren läßt. Beim booten der DVD für die Grundinstallation kommt er nur bis zu dem Punkt, wo der eigentliche Bootvorgang booten ... kommt, da hängt er und gibt die Fehlermeldung aus:

Code:
can't find /boot/entropy
hab dann mal disk1 CD gebrannt, der selbe Fehler.

Hier im englischen Forum haben einige User das selbe Problem:

FreeBSD Forum

Gelöst wurde es offensichtlich noch nicht.

Er findet also den Eintiegspunkt nicht. Was könnte das sein? Die 1TB HD habe ich platt gemacht, keine msdos Partition und nichts. Wer hat eine Idee?

Ich arbeite jetzt und hier mit einem erfolgreich installiertem FreeBSD 11.2 auf dem XFCE Desktop. Läuft auf dem alten Pentium Rechner mit 2 GB RAM unter UFS Filesystem und einer Nvidia Geforce 9500 GT super.