Kategorie: Linux & BSD (Seite 4 von 7)

OpenPOWER-Testsystem mit POWER8-CPU von Thomas-Krenn im Detail

28. Juni 2018 / Sebastian van de Meer / Keine Kommentare

Die netten Leute von Thomas Krenn haben uns ihr OpenPower Testsystem zur Verfügung gestellt \o/ Wir wollten dieses System schon etwas länger in die Finger bekommen. Jetzt hat es endlich geklappt!

Der Server verballert mit seinen zwei 1200 Watt Netzteilen in der Spitze etwas um 370Watt (im normalen Betrieb etwas um die 230Watt) und soll laut TK 1.325 BTU/h produzieren.

Verbaut sind 128GB RAM und natürlich eine Power8 CPU:

root@ubuntu:/home/tk# lscpu
Architecture:          ppc64le
Byte Order:            Little Endian
CPU(s):                64
On-line CPU(s) list:   0-63
Thread(s) per core:    8
Core(s) per socket:    8
Socket(s):             1
NUMA node(s):          1
Model:                 2.0 (pvr 004d 0200)
Model name:            POWER8 (raw), altivec supported
CPU max MHz:           3857.0000
CPU min MHz:           2061.0000
Hypervisor vendor:     horizontal
Virtualization type:   full
L1d cache:             64K
L1i cache:             32K
L2 cache:              512K
L3 cache:              8192K
NUMA node0 CPU(s):     0-63

OS ist ein Ubuntu:

root@ubuntu:/home/tk# lsb_release -a          
No LSB modules are available.
Distributor ID:	Ubuntu
Description:	Ubuntu 16.04.4 LTS
Release:	16.04
Codename:	xenial

Die im Testsystem mitgelieferten Festplatten (3,5″ Nearline SAS mit 7,2k) waren für unseren Datenbanktest etwas zu langsam, daher haben wir ein paar ältere 15k 2,5″ Platten aus unserem Lager verbaut und diese in ein Raid 10 geworfen. Damit ist das lokale Storage-Backend nun laut pg_test_fsync vergleichbar mit unseren anderen Testsystemen. Wir wollen ja sehen welche CPU "schneller" ist und nicht welche Festplatte am meisten "bremst".

So „einfach“ ist es nicht zu sagen welche CPU nun wirklich schneller ist als eine andere. Ich habe als erstes versucht ein paar alltägliche Dinge miteinander zu vergleichen:

CPU	SHA256-hashing 500 MB	bzip2-compressing 500 MB	AES-encrypting 500 MB
2 x Intel(R) Xeon(R) CPU E5-2665 0 @ 2.40GHz	3.859 seconds	5.445 seconds	1.337 seconds
1 x Power8 2.0 (pvr 004d 0200)	3.803 seconds	7.868 seconds	0.866 seconds
1 x Intel(R) Core(TM) i7-6700 CPU @ 3.40GHz	2.370 seconds	4.207 seconds	0.831 seconds
2 x Intel(R) Xeon(R) CPU E5-2650 v4 @ 2.20GHz	2.652 seconds	5.413 seconds	1.585 seconds
2 x Intel(R) Xeon(R) CPU E5-2650 v3 @ 2.30GHz	2.484 seconds	5.217 seconds	1.500 seconds

Als nächstes habe ich unixbench.sh laufen lassen:

wget --no-check-certificate https://github.com/teddysun/across/raw/master/unixbench.sh
chmod +x unixbench.sh
./unixbench.sh

Hier sollte nun das OpenPower System einmal gegen einen Dell System mit zwei verbauten Intel(R) Xeon(R) CPU E5-2665 0 @ 2.40GHz antreten. Natürlich sind hier nur die Infos zu CPU/RAM spannend!

2 x Intel(R) Xeon(R) CPU E5-2665 0 @ 2.40GHz				Power8
Dhrystone 2 using register variables	34551077.1 lps	(10.0 s, 7 samples)		27167563.6 lps	(10.0 s, 7 samples)
Double-Precision Whetstone	4082.2 MWIPS	(9.9 s, 7 samples)		4092.2 MWIPS	(9.7 s, 7 samples)
Execl Throughput	2124.0 lps	(30.0 s, 2 samples)		2776.0 lps	(29.9 s, 2 samples)
File Copy 1024 bufsize 2000 maxblocks	1087796.7 KBps	(30.0 s, 2 samples)		299978.8 KBps	(30.0 s, 2 samples)
File Copy 256 bufsize 500 maxblocks	299275.0 KBps	(30.0 s, 2 samples)		75847.4 KBps	(30.0 s, 2 samples)
File Copy 4096 bufsize 8000 maxblocks	3350511.2 KBps	(30.0 s, 2 samples)		1079708.7 KBps	(30.0 s, 2 samples)
Pipe Throughput	2067851.3 lps	(10.0 s, 7 samples)		465883.7 lps	(10.0 s, 7 samples)
Pipe-based Context Switching	215476.9 lps	(10.0 s, 7 samples)		132003.3 lps	(10.0 s, 7 samples)
Process Creation	4278.0 lps	(30.0 s, 2 samples)		7390.5 lps	(30.0 s, 2 samples)
Shell Scripts (1 concurrent)	5542.8 lpm	(60.0 s, 2 samples)		7085.1 lpm	(60.0 s, 2 samples)
Shell Scripts (8 concurrent)	6090.1 lpm	(60.0 s, 2 samples)		4356.5 lpm	(60.0 s, 2 samples)
System Call Overhead	4186839.6 lps	(10.0 s, 7 samples)		344156.5 lps	(10.0 s, 7 samples)

System Benchmarks Index Values	BASELINE	RESULT	INDEX	RESULT	INDEX
Dhrystone 2 using register variables	116700.0	34551077.1	2960.7	27167563.6	2328.0
Double-Precision Whetstone	55.0	4082.2	742.2	4092.2	744.0
Execl Throughput	43.0	2124.0	494.0	2776.0	645.6
File Copy 1024 bufsize 2000 maxblocks	3960.0	1087796.7	2747.0	299978.8	757.5
File Copy 256 bufsize 500 maxblocks	1655.0	299275.0	1808.3	75847.4	458.3
File Copy 4096 bufsize 8000 maxblocks	5800.0	3350511.2	5776.7	1079708.7	1861.6
Pipe Throughput	12440.0	2067851.3	1662.3	465883.7	374.5
Pipe-based Context Switching	4000.0	215476.9	538.7	132003.3	330.0
Process Creation	126.0	4278.0	339.5	7390.5	586.5
Shell Scripts (1 concurrent)	42.4	5542.8	1307.3	7085.1	1671.0
Shell Scripts (8 concurrent)	6.0	6090.1	10150.2	4356.5	7260.8
System Call Overhead	15000.0	4186839.6	2791.2	344156.5	229.4

System Benchmarks Index Score			1629.6		851.8

Die hohe Anzahl Threads und die fette Speicheranbindung der CPU sind ein paar Besonderheiten, welche dieses System theoretisch sehr gut brauchbar als Datenbankserver machen sollten. Wir arbeiten viel mit PostgresSQL, daher war einer unserer Tests ein Restore unserer Testdatenbank.

CPU	Restore Zeit
2 x Intel(R) Xeon(R) CPU E5-2650 v3 @ 2.30GHz	129min 34s
1 x Power8 2.0 (pvr 004d 0200)	120min 43s

Bisher zeigt sich folgendes Bild: Die Power8 CPU ist ohne Zweifel sehr leistungsstark. Die „bessere“ Speicheranbindung und die vielen Threads bemerkt man. Das OpenPower System von Thomas Krenn gibt es nur mit einem CPU Socket, also ist es immer eine singel CPU. Im direkten Vergleich mit einer Intel single CPU macht das Power8 System bei Datenbanken sicher den Stich. Da es preislich viel eher an einem dual Intel CPU System angesiedelt ist, muss es sich damit vergleichen lassen, selbst wenn es nicht ganz fair ist. Hier hat im direkten Vergleich ein solches Intel System die Nase vorne.

IBM hat im Jahr 2013 ihre Power8 CPU vorgestellt. Jetzt haben wir 2018…. Daher sind die Vergleichssysteme ebenfalls etwas älter. Unterm Strick: Echt tolle CPU, leider im Preis/Leistungsvergleich (für einen Datenbankserver) gegenüber eines Intel-Systems, der Verlierer! Was sicher im HPC oder bei Anbindungen von Nvidia Rechenbeschleunigern anders aussieht. Dual CPU Systeme wären spannend, besser noch direkt Power9 Systeme (mit AES und GZIP im Chip). Da IBM von diesen CPUs im Vergleich mit Intel nur sehr geringe Stückzahlen verkauft ist der Preis hoch. Vielleicht passiert hier ja noch mal irgendwann etwas?!?!

Wir haben hier noch ein paar Tests mehr gemacht und wir werden in den nächsten Tagen noch ein paar Experimente mit dem System vornehmen. Wenn sich also am ersten Eindruck noch etwas ändert schreibe ich es.

Hier habe ich noch ein paar Bilder..

Fragen? Na dann wie immer einfach fragen 🙂

Typ-2-Hypervisor BHYVE von FreeBSD: Virtualisierung leicht gemacht

20. Juni 2018 / Sebastian van de Meer / Keine Kommentare

Aus euch bekannten Gründen nutze ich selbst auf meinen Desktops und Notebooks FreeBSD als OS. Zugegeben…. An bestimmten Stellen ist es ganz ohne Microsoft Systeme nicht ohne Einschränkungen möglich bestimmte Dinge zu erledigen. Echtes Word oder Excel lässt sich nur bis zu einem bestimmten Punkt „ersetzten“ vor allem wenn alle anderen damit arbeiten. Zwischen Outlook / Evolution oder OWA gibt es auch größere Unterschiede. Das Citrix XenCenter existiert so wie viele andere Software nur als Windows Version bei welcher es keinen Spaß macht diese durch Wine zu schieben….. Wie löst man dieses Problem? Richtig, mit einer VM in VirtualBox! Darf man ein Windows 10 Pro virtualisieren? Ja und nein… Man muss schon auf die passende Lizenz achten! Ähnlich ist es mit VirtualBox, hier ist der kostenlose Einsatz im Unternehmen an bestimmte Einschränkungen gekoppelt.

Alles kein Grund es nicht so zu machen. Die Windows und VirtualBox Lizenzen sind nicht unglaublich teuer und selbst mit den VirtualBox Einschränkungen könnte man sicher in vielen Fällen leben. FreeBSD kommt aber seit Version 10.0 mit einem eigenen Typ-2 Hypervisor mit dem Namen bhyve (gott ich vertippe mich immer bei dem Wort). Jetzt habe ich damit natürlich sehr neugierig experimentiert. Aber schnell gemerkt das es als VirtualBox Ersatz noch etwas Zeit benötigt. Für den täglichen FreeBSD Servereinsatz hatte ich keine Verwendung, hier lebe ich mit den jails 🙂 Inzwischen sind wir bei FreeBSD 11.1 und die Version 11.2 steht vor der Tür. Meine Windows VM hatte ebenfalls irgendein Problem mit welchem ich mich nicht beschäftigen wollte (ja ich vernachlässige sie sehr), also stand eh mal eine neue an. Mit den Basis Tools von bhyve lässt sich eine VM einrichten und nutzen. Ich würde es sogar empfehlen um die Idee dahinter zu verstehen. Für den normalen täglichen Umgang sollte man aber lieber ein Verwaltungstool nutzen. Für meinen neuen Test habe ich dieses mal auf vm-bhyve gesetzt. Weil… Na weil es in den Ports und ebenfalls direkt als binary über pkg zu bekommen ist. Ok ok, ich habe ebenfalls das Wiki in meine Überlegung einbezogen…

Im Wiki findet sich der Quickstart und ähm, ja das ist wirklich alles genau so nutzbar:

1. pkg install vm-bhyve [grub2-bhyve uefi-edk2-bhyve]
2. zfs create pool/vm
3. echo 'vm_enable="YES"' >> /etc/rc.conf
4. echo 'vm_dir="zfs:pool/vm"' >> /etc/rc.conf
5. vm init
6. cp /usr/local/share/examples/vm-bhyve/* /mountpoint/for/pool/vm/.templates/
7. vm switch create public
8. vm switch add public em0
9. vm iso ftp://ftp.freebsd.org/pub/FreeBSD/releases/ISO-IMAGES/10.3/FreeBSD-10.3-RELEASE-amd64-bootonly.iso
10. vm create myguest
11. vm [-f] install myguest FreeBSD-10.3-RELEASE-amd64-bootonly.iso
12. vm console myguest

Für meine Windows VM habe ich nur ein paar Dinge leicht anfassen müssen.

Die ISO hatte ich bereits auf meinem System liegen und schnell mit folgendem Aufruf „importiert“:

vm iso /home/kernel/Download/windoof-iso.iso

Das virtualisierte Windows benötigt am Ende noch Treiber für die Netzwerkkarte. Dabei passt der virtio-net Driver den ich erst heruntergeladen und dann direkt importiert habe:

fetch https://fedorapeople.org/groups/virt/virtio-win/direct-downloads/archive-virtio/virtio-win-0.1.149-1/virtio-win-0.1.149.iso
vm iso /home/kernel/Download/virtio-win-0.1.149.iso

Dann die eigentliche VM aus dem mitgelieferten Template erstellen:

vm create -t windows -s 200G windoof

Durch das Template kommt die VM mit 2 CPUs und 2GB RAM. Die Systemplatte hat durch meine Option -s 200G eine Größe von 200GB. Da ich die Installation aber irgendwie durchführen muss und ich gerne doch 4 CPUs mit 8GB RAM hätte änderte ich die Konfiguration der VM direkt wie folgt ab:

vm configure windoof

uefi="yes"
cpu=4
memory=8G
graphics="yes"
graphics_port="5999"
graphics_listen="127.0.0.1"
graphics_res="1280x1024"
graphics_wait="auto"
xhci_mouse="yes"
network0_type="virtio-net"
network0_switch="public"
disk0_type="ahci-hd"
disk0_name="disk0.img"
uuid="c36583eb-739e-11e8-8176-ecf4bb47c54c"
network0_mac="58:9c:fc:01:41:8a"

So und nun nur noch VM starten und ISO „einlegen“:

vm install windoof windoof-iso.iso

Nun einfach mit einem VNC Viewer der Wahl mit 127.0.0.1:5999 verbinden und Windows installieren. Nachher wieder über vm install die ISO mit den Netzwerktreibern „einlegen“ und Windows einfach dort die Netzwerkkartentreiber suchen lassen, klappt prima. Ich habe dann einfach für meinen Benutzer rdp aktiviert und verbinde mich für alles Zukünftige einfach über rdp mit der VM. Fertig is 🙂

An / aus / snapshot usw. läuft alles über vm. So zum Beispiel auch die Übersicht über alle laufenden VMs:

vm list
NAME            DATASTORE       LOADER      CPU    MEMORY    VNC                  AUTOSTART    STATE
windoof    default         uefi        4      8G        -                    No           Running (10638)

Im Grunde absolut selbsterklärend, oder? Bei mir rennt nun seit einigen Tagen die VM so und ich brauche kein VirtualBox mehr \o/ Fragen? Dann Fragen 🙂

SSD Secure Erase mit FreeBSD: So löschst du deine SSD sicher

20. März 2018 / Sebastian van de Meer / Ein Kommentar

Um alle Daten einer SSD möglichst sicher zu löschen gibt es im ATA die Funktion: „ATA Secure Erase“. Möchte man nun seine SSD schnell und einfach von allen Daten befreien (dd mit Nullen ist ja eher eine schlechte und nicht funktionsfähige Möglichkeit bei SSDs), nutzt man einfach diese Funktion.

Bei einem FreeBSD sieht dieses unter optimalen Bedingungen wie folgt aus:

root@sun-wks:/usr/home/kernel # camcontrol security ada4 -s Erase -e Erase
pass7: <OCZ-AGILITY3 2.15> ATA8-ACS SATA 3.x device
pass7: 600.000MB/s transfers (SATA 3.x, UDMA6, PIO 8192bytes)

You are about to ERASE ALL DATA from the following device:
pass7,ada4: <OCZ-AGILITY3 2.15> ATA8-ACS SATA 3.x device

Are you SURE you want to ERASE ALL DATA? (yes/no) yes
Issuing SECURITY_SET_PASSWORD password='Erase', user='master', mode='high'
Issuing SECURITY_ERASE_PREPARE
Issuing SECURITY_ERASE_UNIT password='Erase', user='master'

Erase Complete

Optimale Bedingungen?

Das eine oder andere BIOS „schützt“ die Festplatten vor dieser Funktion und sorgt dafür das sie nicht genutzt werden kann. Hier hilft es die Platte erst nach dem Boot anzuschließen. Um die Funktion nutzen zu können muss der SSD ebenfalls erst ein Kennwort gegeben werden. Ohne gesetztes Kennwort kann die Funktion ebenfalls nicht genutzt werden. Ich habe dieses in einem Abwasch erledigt indem ich erst das Kennwort und dann direkt die Funktion mit dem gesetzten Kennwort aufrufe (-s Erase -e Erase) Erase ist also in meinem Beispiel das gesetzte Kennwort.

Da wir gerade dabei sind… Viele SSDs habe eine Art „Selbstheilungsmodus“… Ist diese aktiviert prüft sich die SSD selbst und repariert sich, soweit möglich. Dieser Modus wird aktiviert wenn die SSD am Strom aber nicht am Datenbus angeschlossen ist. Bedeutet. SATA/SAS Kabel abziehen. Strom anschließen/einschalten und warten. In der Regel sollten SSDs nach knapp 4 Stunden mit ihrer „Selbstheilung“ fertig sein. Dieses lässt sich natürlich im Anschluss noch einmal wiederholen. Funktioniert die SSD nach zwei Durchläufen noch nicht wie gewünscht, wird sie wohl wirklich kaputt sein.

Fragen? Dann Fragen 😀

RFC 7858 – DNS over Transport Layer Security

30. Oktober 2017 / Sebastian van de Meer / Keine Kommentare

Ich habe in den letzten Tagen etwas mit dem RFC 7858 (https://tools.ietf.org/html/rfc7858) herumgespielt. Meine Zonen und auch Dienste sind per DNSsec, HSTS, Pinning usw. usw. abgesichert. Warum also noch DNS per TLS? Nun ja… Sinn macht es sicher keinen, bei mir ist nichts spannendes zu finden und kaum ein Besucher wird mit Problemen rechnen müssen wenn er hier ist. Für mich sollte Kryptographie nicht die Ausnahme sondern der Normalzustand sein. RFC 7858 ist da nur ein weiteres Detail. In einer DNS Abfrage finden sich selten geheime Daten. Klar wäre es schlecht wenn diese verändert würden um diese zu verhindern reicht eine Signatur. Das mitlesen der DNS Abfragen würde einer dritten Person so aber offenlegen wo man surft und welche Dienste man nutzt. Sind diese Abfragen per TLS verschlüsselt bleibt dieses geheim. Daher macht es wohl am meisten Sinn es für seinen lokalen DNS Resolver zu nutzen oder es auf großen DNS Servern zu aktivieren. DNS Servern welche sich um viele Zonen kümmern….

Um irgendwo zu starten und selbst einen Eindruck davon zu bekommen habe ich es auf meinen DNS Servern für meine Zonen aktiviert. Bis auf ns2.kernel-error.org haben die Server gültige Zertifikate. Bei ns2.kernel-error.org muss ich mal schauen wie es sich entwickelt.

Als Test:

$ getdns_query -s www.kernel-error.de a @176.9.109.53 -l L

Viel Spaß

Read- und Write-Latency mit ioping messen: So geht’s

8. August 2017 / Sebastian van de Meer / Keine Kommentare

Um die Performance von irgendwelchen Datenträgern / Netzlaufwerken usw. zu messen gibt es sehr viele verschiedene Tools. bonnie++ ist hier ein gutes Beispiel. Möchte man nur „mal schnell“ die read-/write latency messen und ein paar grobe Infos zu den IOPs haben kann ich hier ioping empfehlen.

Ein Beispiel zum messen der read latency:

➜  ~ ioping -s 256k -T 120 -D -c 20 ./
256 KiB <<< ./ (zfs tanksmeer/usr/home): request=1 time=16.0 us (warmup)
256 KiB <<< ./ (zfs tanksmeer/usr/home): request=2 time=35.7 us
256 KiB <<< ./ (zfs tanksmeer/usr/home): request=3 time=45.8 us
256 KiB <<< ./ (zfs tanksmeer/usr/home): request=4 time=46.3 us
256 KiB <<< ./ (zfs tanksmeer/usr/home): request=5 time=43.4 us
256 KiB <<< ./ (zfs tanksmeer/usr/home): request=6 time=46.8 us
256 KiB <<< ./ (zfs tanksmeer/usr/home): request=7 time=41.2 us
256 KiB <<< ./ (zfs tanksmeer/usr/home): request=8 time=41.7 us
256 KiB <<< ./ (zfs tanksmeer/usr/home): request=9 time=47.7 us (slow)
256 KiB <<< ./ (zfs tanksmeer/usr/home): request=10 time=42.4 us
256 KiB <<< ./ (zfs tanksmeer/usr/home): request=11 time=41.8 us
256 KiB <<< ./ (zfs tanksmeer/usr/home): request=12 time=41.1 us
256 KiB <<< ./ (zfs tanksmeer/usr/home): request=13 time=48.8 us (slow)
256 KiB <<< ./ (zfs tanksmeer/usr/home): request=14 time=47.1 us
256 KiB <<< ./ (zfs tanksmeer/usr/home): request=15 time=42.8 us
256 KiB <<< ./ (zfs tanksmeer/usr/home): request=16 time=47.9 us
256 KiB <<< ./ (zfs tanksmeer/usr/home): request=17 time=50.5 us (slow)
256 KiB <<< ./ (zfs tanksmeer/usr/home): request=18 time=52.8 us (slow)
256 KiB <<< ./ (zfs tanksmeer/usr/home): request=19 time=44.6 us
256 KiB <<< ./ (zfs tanksmeer/usr/home): request=20 time=45.3 us

--- ./ (zfs tanksmeer/usr/home) ioping statistics ---
19 requests completed in 853.7 us, 4.75 MiB read, 22.3 k iops, 5.43 GiB/s
generated 20 requests in 19.0 s, 5 MiB, 1 iops, 269.2 KiB/s
min/avg/max/mdev = 35.7 us / 44.9 us / 52.8 us / 3.85 us

ioping liest hier jeweils 256k (-s 256k), ignoriert alles was länger brauch als die angegebene Zeit (-T 120), macht es als direct IO ohne cache (-D), dieses insg. 20 mal in Folge (-c 20) und einfach im aktuellen Pfad (./).

Die Zusammenfassung ist ähnlich wie bei ping 🙂

Ein Beispiel zum messen der write latency:

➜  ~ ioping -s 256k -T 120 -D -W -c 20 ./
256 KiB >>> ./ (zfs tanksmeer/usr/home): request=1 time=27.0 us (warmup)
256 KiB >>> ./ (zfs tanksmeer/usr/home): request=2 time=54.4 us
256 KiB >>> ./ (zfs tanksmeer/usr/home): request=3 time=60.6 us
256 KiB >>> ./ (zfs tanksmeer/usr/home): request=4 time=65.5 us
256 KiB >>> ./ (zfs tanksmeer/usr/home): request=5 time=57.8 us
256 KiB >>> ./ (zfs tanksmeer/usr/home): request=6 time=74.0 us
256 KiB >>> ./ (zfs tanksmeer/usr/home): request=7 time=65.5 us
256 KiB >>> ./ (zfs tanksmeer/usr/home): request=8 time=65.3 us
256 KiB >>> ./ (zfs tanksmeer/usr/home): request=9 time=70.9 us
256 KiB >>> ./ (zfs tanksmeer/usr/home): request=10 time=70.7 us
256 KiB >>> ./ (zfs tanksmeer/usr/home): request=11 time=2.65 ms (slow)
256 KiB >>> ./ (zfs tanksmeer/usr/home): request=12 time=71.8 us (fast)
256 KiB >>> ./ (zfs tanksmeer/usr/home): request=13 time=64.5 us (fast)
256 KiB >>> ./ (zfs tanksmeer/usr/home): request=14 time=77.0 us (fast)
256 KiB >>> ./ (zfs tanksmeer/usr/home): request=15 time=63.3 us (fast)
256 KiB >>> ./ (zfs tanksmeer/usr/home): request=16 time=67.4 us (fast)
256 KiB >>> ./ (zfs tanksmeer/usr/home): request=17 time=51.6 us (fast)
256 KiB >>> ./ (zfs tanksmeer/usr/home): request=18 time=82.9 us (fast)
256 KiB >>> ./ (zfs tanksmeer/usr/home): request=19 time=81.5 us (fast)
256 KiB >>> ./ (zfs tanksmeer/usr/home): request=20 time=56.2 us (fast)

--- ./ (zfs tanksmeer/usr/home) ioping statistics ---
19 requests completed in 3.86 ms, 4.75 MiB written, 4.93 k iops, 1.20 GiB/s
generated 20 requests in 19.0 s, 5 MiB, 1 iops, 269.5 KiB/s
min/avg/max/mdev = 51.6 us / 202.9 us / 2.65 ms / 577.9 us

Richtig… Hier ist nur ein -W dazu gekommen!

So lässt sich schnell und einfach ein Eindruck über die aktuelle Performance von einem „Filesystem“ erlangen. Einfach um zu sehen ob es sich unter Last anders verhält oder ähnliches.

Viel Spaß und bei Fragen, einfach fragen.

FreeBSD CPU Microcode Updates

2. August 2017 / Sebastian van de Meer / Keine Kommentare

Das es auch mal in einer CPU Fehler geben kann ist nicht jedem bewusst. Da es aktuell sehr durch die Presse geht, inzwischen vielleicht schon einigen Menschen mehr als vorher. Das diese Fehler in CPUs sogar recht oft vorkommen, daran denken die wenigsten. Ich kann mich noch an einen Intel Prozessor erinnern bei dem man einfach mit dem Windows Taschenrechner testen konnte ob ein bestimmte Bug vorliegt. Diese CPU durfte man sogar zurückgeben weil es sich nicht durch ein simples Update fixen lässt.

Update? Ja man kann den sogenannten Microcode der CPU updaten. Ja der Microcode ist fest in der CPU „eingebrannt“ ein solches Update muss also jedes mal gemacht werden, wenn die CPU erneut eingeschaltet wird. Daher lösen es die meisten Mainbordhersteller über ein Bios Update. Wenn ihr also mal die Changelogs eurer Bios Updates durchgeht werdet ihr immer mal wieder etwas von CPU und oder Microcode lesen. Das ist dann genau so etwas. Setzt man ein älteres Mainboard ein gibt es auch kein Update 😀 Setzt man Linux ein installiert man sich die Microcode Updates und bei jedem Start bekommt die CPU so ihr Update. Bei FreeBSD geht dieses natürlich ebenfalls. Da diese Frage bei mir schon ein paar mal angekommen ist, dieser Beitrag.

Das Paket nennt sich devcpu-data und findet sich in der Ports und ebenfalls auch als Binary:

$ pkg install devcpu-data

Damit es aktiviert ist und beim Booten geladen wird, ja ihr erratet es… Folgendes muss in die /etc/rc.conf :

microcode_update_enable="YES"

Dann lässt sich alles einmal anstarten und direkt sehen ob es erfolgreich ist:

$ /usr/local/etc/rc.d/microcode_update start
Updating cpucodes...
/usr/local/share/cpucontrol/m12206a7_00000029.fw: updating cpu /dev/cpuctl0 from rev 0x28 to rev 0x29... done.
/usr/local/share/cpucontrol/m12206a7_00000029.fw: updating cpu /dev/cpuctl2 from rev 0x28 to rev 0x29... done.
/usr/local/share/cpucontrol/m12206a7_00000029.fw: updating cpu /dev/cpuctl4 from rev 0x28 to rev 0x29... done.
/usr/local/share/cpucontrol/m12206a7_00000029.fw: updating cpu /dev/cpuctl6 from rev 0x28 to rev 0x29... done.
Done.

Wie man sieht, er konnte ich ein Update vom Microcode durchführen und es gab auch eines. Es kommt immer mal wieder vor das Fehler gefunden werden daher dieses immer aktuell halten.

FreeBSD: WLAN und der Ländercode korrekt einstellen

31. Mai 2017 / Sebastian van de Meer / Ein Kommentar

Nutzt man auf seinem FreeBSD das WLAN so funktioniert es in der Regel ohne Probleme. Wenn man aber an ein WLAN gerät das Kanal 12 oder 13 benutzt, so funktioniert das irgendwie nicht. Warum? Ganz einfach… im Standard kommt ein FreeBSD mit dem Ländercode US für USA hoch. Dort ist leider essig mit Kanal 12 und 13. Daher muss man seinem FreeBSD erstmal sagen das es sich in Deutschland befindet. Dieses geht wie folgt:

$ ifconfig  wlan0 list channel
$ ifconfig  wlan0 down
$ ifconfig  wlan0 ecm
$ ifconfig  wlan0 regdomain ETSI
$ ifconfig  wlan0 country DE
$ ifconfig  wlan0 up
$ ifconfig  wlan0 list channel

Zeile 1 zeigt einem dabei die aktuellen Kanaleinstellungen, Zeile 2 schaltet das die Karte für die Umstellungen ab, Zeile 3 bis 5 bringen uns nach Europa und Deutschland, Zeile 6 schaltet das wlan wieder ein und Zeile 7 gibt uns nun die aktuellen Kanäle einmal aus.

Möchte man dieses nun nicht immer einstellen sondern fest bei jedem Start mit eingebaut haben hilft folgende Zeile in der /etc/rc.conf:

create_args_wlan0="ecm regdomain ETSI country DE"

Möchte man mehr erfahren kann man sich die Datei: /etc/regdomain.xml anschauen oder besser noch:

$ ifconfig wlan0 list regdomain

Dieses geht natürlich ebenfalls mit dem country:

$ ifconfig wlan0 list countries

Tjo… Viel Spaß wa?

Was ist los mit Firefox? Häufige Probleme und Lösungen

18. März 2017 / Sebastian van de Meer / Keine Kommentare

Als Browser nutze ich ja schon sehr lange den Firefox… Natürlich ebenfalls auf meinen mobilen Geräten. In der letzten Zeit macht das Teil leider immer mehr Ärger. Er bleibt einfach sinnfrei hängen, performt einfach nicht und ist auch nicht so flexibel beim darstellen und vor allem bei vielen Multimediainhalten. Ich würde ja gerne Opera oder am besten noch dessen Fork Vivaldi einsetzten, der tut nur auf BSD nicht 🙁 *hmpf* Also muss ich jetzt wirklich zum chrome wechseln? Scheint fast so…

Umzug auf FreeBSD / NGINX

18. März 2017 / Sebastian van de Meer / Keine Kommentare

Wie angekündigt habe ich nun meinen Apachen in den Ruhestand geschickt… Damit ist nun also ebenfalls mein Webserver auf FreeBSD und ebenfalls auf NGINX.

FreeBSD slim lightDM MATE und Shutdown/Reboot durch den Benutzer

17. März 2017 / Sebastian van de Meer / Keine Kommentare

Auf fast jedem Unix ähnlichen System haben Benutzer nicht das Recht das komplette System herunterfahren oder neustarten zu können. Macht ja nur Sinn… Nutzt man dieses System aber als Desktop könnte es in gewissen Fällen ebenfalls nicht dumm sein, wenn Benutzer nicht in der Lage sind das System zu rebooten und einen shutdown abzusetzten. In den Meisten Fällen ist man dann wohl doch alleine auf seinem System und es ist eher eine Einschränkung wenn man sich erst als privilegierter Benutzer anmelden muss um seinen Comupter/Laptop abschalten zu können.

Dafür wurden nun verschiedenste Dienste entwickelt um dieses so einfach wie möglich zu erledigen. Das wohl bekannteste und verbreitetste ist consolekit / policykit / polkit. Dieses System ermöglicht es bestimmte Rechte basierend auf Benutzer oder Gruppen zu verteilen. Die gängigen Logonmanager sowie Displaymanager haben in der Regel bereits die Möglichkeit eingebaut um sich damit auszutauschen. Der normale Linux Benutzer wird damit wohl kaum noch in Berührung kommen.

Am einfachsten schaut man sich als Benutzer einmal in einem xterminal an welche Möglichkeiten einem geboten werden:

$ pkaction

Schon gibt es eine Liste der aktuell konfigurierbaren „Berechtigungen“. Ob shutdown und reboot dabei ist sagt einem:

$ pkaction | grep -E 'stop|restart'
org.freedesktop.consolekit.system.restart
org.freedesktop.consolekit.system.restart-multiple-users
org.freedesktop.consolekit.system.stop
org.freedesktop.consolekit.system.stop-multiple-users

Ob der eigene Benutzer es bereits darf sagt einem:

$ pkaction --action-id org.freedesktop.consolekit.system.restart --verbose
org.freedesktop.consolekit.system.restart:
  description:       Restart the system
  message:           System policy prevents restarting the system
  vendor:            
  vendor_url:        
  icon:              
  implicit any:      no
  implicit inactive: no
  implicit active:   yes

Implicit active ist hier der spannende Eintrag… Dieser ergibt sich für mich aus der von mir angelegten Regel 05-shutreboot.rules unter /usr/local/etc/polkit-1/rules.d diese schaut wie folgt aus:

polkit.addRule(function (action, subject) {
  if (action.id == "org.freedesktop.consolekit.system.restart" ||
  action.id == "org.freedesktop.consolekit.system.stop"
  && subject.isInGroup("wheel")) {
  return polkit.Result.YES;
  }
});

Die Regel besagt das org.freedesktop.consolekit.system.stop sowie restart das Ergebnis YES zurückgeben soll, wenn der Benutzer in der Gruppe wheel ist. ist diese Regel eingetragen, und man ist sich sicher das alles klappen müsste, es dennoch nicht funktioniert sind ein beliebter Fehler die Rechte vom Ordner. Hier könnte folgendes helfen:

$ chown polkitd:wheel /usr/local/etc/polkit-1

In diesem Sinne…