Rechneraufbau (Hilfe/Übernahme)

Das liest sich für mich aber anders.
Dann lies bitte noch mal meine Anforderungen. Und das ich will, kannst Du zu ich arbeite für meine Kunden auf Windows. Also die Kunden sind gerade die Leute die mich für meine Leistungen bezahlen und deren Systeme sind Windows Systeme. Und ich wäre Dir immer noch verbunden mir zu erläutern was an den Forderungen zu diskutieren ist. Braucht Du den Rechner oder ich?
 
Ich hab das auch so einige Zeit laufen lassen wie der OP das wünscht, allerdings unter Linux / KVM. Ich halte das für einen völlig legitimes Ziel. Ich nutze aber kein FreeBSD :)
 
Vielleicht kommen wir mir diesem Vorschlag konstruktiv weiter:
FDominicus eröffnet einen Wiki Artikel der ungefähr so heißen könnte: Aufbau FreeBSD Entwicklungs- und Virtualisierungs-Workstation
Darin füllt er alle Abschnitte nach bestem Wissen und Gewissen, verlinkt zu relevanten anderen Artikeln, legt den Grundstein für andere mit den gleichen Fragen und die erfahrenen Mitglieder des Forum werten das Wiki mit ihren Tipps auf.
So haben alle etwas davon und aktuelles Wissen zu diesem Thema wird schön geteilt wie es sich für eine Community gehört.

Alternativ bleibt der Vorschlag im Raum dass eine "Ausschreibung" gemacht wird und jemand gegen Cash die Leistung erbringt diese Workstation aufzubauen.

Gegenvorschläge?
 
Da sich bisher niemand bei mir meldete, werde ich es wohl selbst machen müssen. Vielleicht kann man mir zumindest sagen was die ausgereifteste Virtualisierungslösung ist und nett wäre es auch mir zu schreiben wie es mit dem Ausführen von Linux Programmen aussieht.

Danke
 
Wenn du jmd suchst wäre das einfachste im Bereich "Jobsuche und Angebote" eine Anfrage zu platzieren. Idealerweise mit Umfangbeschreibung und einer groben finanziellen Vorstellung.

Zur Virtualisierung kann ich dir nicht viel sagen, denn ich verwende bisher meist VBox und Jails (was beides deinen Anforderungen nicht entspricht). Aber zum Ausführen von Linuxprogrammen musst du den Linuxulator installieren/aktivieren. Hierzu kannst du ins Handbuch schauen https://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/linuxemu.html

Allgemein wird dir das Handbuch gute Dienste leisten bei ersten Fragen.
 
Es gibt unter FreeBSD zwei uneingeschränkt nutzbare Virtualisierungslösungen:
  • VirtualBox, genauer gesagt eine Portierung von dessen Community-Variante. Sie entspricht im Funktionsumpfang der OSE-Edition unter Linux und Windows, kann allerdings nicht um die proprietären Feature-Packs erweitert werden. VirtualBox kann praktisch alle halbwegs aktuellen und verbreiteten Systeme ausführen und emuliert eine ganze Reihe Hardware. Dazu kommen Dinge wie 3D-Beschleunigung im Gast, einfache Netzwerkkonfiguration, SCSI-Passthrough und so weiter. VirtualBox kann als Desktop-Virtualisierunglösung genutzt werden, aber mit dem beiliegenden VBoxHeadless können auch im Hintergrund laufende virtuelle Maschinen ausgeführt werden. Zur Server-Virtualisierung gibt es eine ganze Reihe offizieller und inoffizieller Lösungen, von phpVirtualBox bis zur Integration in libvirt. Das Hauptproblem von VirtualBox ist, dass es sich um ein ziemliches Monster aus diversen Kernelmodulen und einzelnen Prozessen handelt. VirtualBox ist damit recht weit von der gerne zitierten Unix-Philosophie entfernt. Auch sind VirtualBox-VMs relativ ressourcenintensiv, der CPU-Overhead ist vergleichsweise groß und und die Integration in die virtuelle Speicherverwaltung von Host und Gast schwach.
  • Bhyve ist ein minimaler Hypervisor, der speziell für FreeBSD entwickelt wurde. Bhyve hat relativ hohe Hardware-Anforderungen, die CPU muss bei Intel VT-x und Unrestrictes Guest unterstützen, bei AMD SVM und RVI. Dafür ist der Ressourcenverbrauch durch eine gute Integration in das Host-System und per VirtIO in die Gäste allerdings herausragend gut. Bhyve emuliert per Design nur eine sehr begrenzte Menge Hardware, u.a. AHCI-Controller und VirtIO-Devices, aber keine Grafikkarte. Er integriert gut in das restliche FreeBSD-System, beispielsweise durch Netgraph-Anbindung, Netmap-Support und TRIM auf ZFS-Volumes. Bhyve kann in 10-STABLE die meisten unixoiden Systeme ausführen, in 11-CURRENT per UEFI auch Windows. Mit ein wenig Glück schafft Windows-Support es noch in FreeBSD 10.3. Der Hauptnachteil von Bhyve ist, dass es schwer zu bedienen ist. Man hat (in der Variante ohne UEFI) ein Loader-Programm (bhyveload und grub-bhyve), das 'bhyve' Kommando, muss VMs bei Bedarf selbst mit bhyvectl zerstören und so weiter. Zusammen mit der fehlenden Grafikemulation (man muss serielle Konsolen nutzen, eine VNC-Brücke taucht langsam am Horizont auf) ist Bhyve damit für Laien kaum bedienbar. Es gibt zwar Management-Scripte und man kann libvirt nutzen, aber das abstrahiert es nur geringfügig.
Für den Anfang ist VirtualBox also die beste Wahl. Bhyve wird interessant, wenn man sich mit Server-Virtualisierung, leichtgewichtigen VMs und Dingen wie VMs als Security Model zu befassen beginnt. Es sind beide mächtige Lösungen, allerdings mit unterschiedlichen Anwendungsbereichen.
 
Ich habe meine Schuldigkeit getan. ;) Die Liste der Änderungen und der SVN-Patch mit vollem Mergeinfo liegen seit einer Woche bei Peter Grehan. Aber er soll sich deshalb nun nicht kaputt machen. Wenn er keine Zeit hat und es nicht schafft, schafft er es halt nicht. Den Patch manuell ins System zu werfen ist nun auch nicht unzumutbarer Aufwand... Beim Testen auf AMD-Systemen habe ich auch noch einen schweren (Hardware-)Bug auf K10-Kernen gefunden. Der Patch schafft es aber definitiv nicht mehr in 10.3.
 

Anhänge

  • bhyve_merge.diff
    80,2 KB · Aufrufe: 216
  • microcode_update_amd.diff
    392 Bytes · Aufrufe: 226
Okay, dann hoffen wir mal, dass Peter noch dazu kommt. Sonst muss man halt bis Juni zum 11er Release warten oder manuell fummeln.
 
Idee derzeit: SSD + 2 Platten im Raid 1 Verbund

Nun die Frage welche Partitionen/Teile auf die SSD und welche auf die Platte
Ist es sinnvoll/üblich zu partitionieren?
Also /
/usr
/usr/local evtl
/home
/var evtl.

Oder packt ihr alles auf nur eine Paritition?

Es erscheint mir sinnvoll von SSD und vom Raid1 booten zu können. Wenn halt eines mal kaputt geht kann ich 1) die Platte 2) die SSD wechseln.

Meine Datenmengen sind selbst nach 20 Jahren überschaubar, derzeit reichen mir rund 90 GB für alle meine Produktivdaten (und selbst da gibt es schon Redundanzen durch ein paar Backups)

Backup dachte ich einfach auf eine externe Platte zu ziehen. Wie gesagt wichtig für mich eigentlich nur meine Produktivdaten.
Bei mir tut es dazu ein simples tar. Wenn's aber eine einfache Möglichkeit gibt vom Backup alles wieder zu installieren, bin ich darüber auch nicht traurig.

Insgesamt habe ich einiges auch auf meinem derzeitigen Rechner installiert aber auch da reichen mir derzeit 25 GB für den ganzen Dateibaum, dabei dürfte es schon ein paar "Leichen" geben. So diverse Fenstersysteme, Datenbanken die ich im Grunde nicht mehr benutze und so'n Kram.

Also überschaubare Datenmengen. Hochverfügbarkeit ist bei mir keine Anforderung. Sollte halt möglichst laufen und wenn was kaputt geht relative einfach wieder zu reparieren sein, umziehen auf neue Rechner wird immer mal wieder vorkommen, aber wohl kaum so oft wie in der Vergangenheit. Mein derzeitiges System läuft mit kleineren Update seit rd. 6 Jahren.
Der Rechner steht im Büro und wird kaum durch die Gegend ziehen, daher bräuchte ich wohl keine Verschlüsselung des Systems. Aber für manche Daten wäre es schon gut. Macht Ihr das über Verschlüsselung auf Verzeichnisebene oder wie handhabt Ihr das mit Euren Produktivdaten?
 
Die Frage der Partitionierung ist so alt wie die Menschheit und wie immer bei solchen Fragen gibt es zwei Lager. Im Jahr 2016 mit seinen großen Speichermedien, zuverlässigen Dateisystemen und ZFS würde ich eine Partition für das System und eine für die Daten unter /home vornehmen. Auf UFS also in etwa:

/ -> 25GB
/usr/home -> Rest

Dann kann man das System platt machen, ohne seine Daten zu gefährden. Und man kann ohne großen Aufwand zwei getrennte Backups für das System und für die Daten schreiben. Bei ZFS würde ich es ähnlich machen, allerdings noch Boot-Environments nutzen. Also in etwa so:

tank/ROOT/default -> Standard-Bootenv
tank/home -> Wird nach /usr/home gemountet

Je nach Bedarf kann man sich dann noch gemeinsame Ports, Sourcen und so weiter gönnen:

tank/ports -> /usr/ports
tank/src -> /usr/src

Bei ZFS ist es auch eine gute Idee auf allen Datasets lz4-Kompression einzuschalten. Der Geschwindigkeitsverlust ist vernachlässigbar, der Speicherplatzgewinn aber doch recht nennenswert. Es schwankt natürlich nach Art der Daten, 50% sind aber durchaus zu erreichen. Eine Ausnahme sind SSDs mit Sandforce-Controllern, denn sie mögen keine vorkomprimierten Daten und quittieren sie mit Perfomanceeinbrüchen bis hin zu verkürzter Lebensdauer.

Zu Boot-Environments schaue auch mal hier: http://blather.michaelwlucas.com/archives/2363 In FreeBSD 10.3 wird man das Boot-Environment übrigens direkt im Loader auswählen können.
 
Ich verfolge da ein anderes Konzept. Ich habe eine 2GB root Partition (6boot) und eine root Partition (6root) mit dem Rest der Platte.

Auf der 2 GB Partition liegt das /boot Verzeichnis. Die 2. ist geli Verschlüsselt und mein eigentliches root. Das System lädt den Kernel von der kleine Partition. Im Listing Partition 3 und 5:
Code:
> gpart show
=>       34  500118125  ada0  GPT  (238G)
         34          6        - free -  (3.0K)
         40       1920     1  efi  (960K)
       1960         88     2  freebsd-boot  (44K)
       2048    4194304     3  freebsd-ufs  [bootme]  (2.0G)
    4196352   67108864     4  freebsd-swap  (32G)
   71305216  428812288     5  freebsd-ufs  (204G)
  500117504        655        - free -  (328K)
Partitionen 1 u. 2 sind Gefrickel damit das System per EFI und per MBR booten kann (ich benutze tatsächlich beides, wenn ich will das Suspend funktioniert muss ich per MBR booten, wenn ich will, dass VT mit nativer Auflösung geht per EFI.

Mein Swap ist natürlich Overkill.

Das wichtigste aus der /boot/loader.conf:
Code:
vfs.root.mountfrom="ufs:ufs/6root"
geom_eli_load="YES"                     # FS crypto
aesni_load="YES"                        # Hardware AES
nullfs_load="YES"                       # Allow nullfs mounting /boot

Wie man sieht sind alle meine Partitionen ordentlich galabelt, sowohl per GPT als auch direkt die UFS Partitionen. Das erleichtert die Dinge, wenn man die Platte in ein anderes System setzt und davon booten will. Daher hat auch jede Platte eine eindeutige Nummer, die ich allen Labels voran stelle.

Die Magie passiert in der /etc/fstab:
Code:
# Device           Mountpoint   FStype Options    Dump Pass
/dev/ufs/6root     /            ufs    rw,noatime 1    1
/dev/gpt/6boot     /mnt/boot    ufs    rw,noatime 1    1
/mnt/boot/boot     /boot        nullfs rw         0    0
/dev/gpt/6swap.eli none         swap   sw         0    0

Ich mounte also 6boot in ein anderes Verzeichnis um dann per Nullfs das /boot Verzeichnis einzubinden. So spare ich mir das Manuelle rumkopieren des Kernels bei Updates.
 
Zurück
Oben