…jemand Lust ein solch lustiger Kollege zu werden?
Oder besser vorher bei mir fragen 🙂
Wirklich! Fragt vorher…
Kategorie: Kernel-Error-Blog (Seite 15 von 49)
Persönlicher Tech-Blog von Sebastian van de Meer — Beiträge zu IT-Security, Netzwerken, FreeBSD, Linux, Elektronik und Maker-Projekten.
In einer der Küchen meines Brötchengebers steht seit ein paar Tagen ein Tiefer Teller gefüllt mit Zucker in der Nähe der Kaffeemaschine. Warum auch immer dieses so ist; keine Ahnung. Heute hat jemand ein Bild hinter diesen Teller gestellt und joar das bringt mich zum Lachen.
Nur damit nicht gemotzt wird: Dorgen sind böse!
Ich habe vor kurzem in einem DataCenter gestanden und mir einen „neuen“ Kaltgang angeschaut bei dem mir wirklich alles aus dem Gesicht gefallen ist. Der Betreiber dieses DataCenters ist groß, international tätig, nennt eine größere zweistellige Zahl an DataCentern sein eigen und ist doch recht namhaft… Dieser Versuche von einem Kaltgang ist dabei von eben diesem Betreiber gebaut worden. Nicht für einen vermieteten Cage sondern ganz trocken für vermietete Rackreihen…. Rackreihen bei denen sie penibel darauf achten dass dort ganz sicher auch die einzelnen HE Blenden eingesetzt werden, damit ein korrekter Luftstrom garantiert ist. Das meinen die wirklich ernst! *kopfschüttel*
Oh und nein… ich werde jetzt nicht sagen wer der Betreiber ist.
Wenn ich meine Graphen so verfolge sehe ich eine Verdopplung des IPv6 Traffics seit dem Anfang diesen Jahres beim HTTPS Traffic. SMTP ist es nur knapp 50% mehr. Ich würde nun jetzt einfach mal behaupten dass inzwischen viel mehr Enduser mit einer IPv6 Adresse unterwegs sind und Mailserverbetreiber so schnell nicht „nachziehen“.
Mich überrascht dieser starke Anstieg in 2017 etwas daher habe ich nun mal alles gegen meinen IPv4 Traffic gehalten.
Insg. habe ich von meinen Systemen ausgehend 12,5% mehr IPv6 Traffic als IPv4 Traffic. Eingehend habe ich tatsächlich 6% mehr IPv6 Traffic als IPv4 Traffic 🙂 OK OK jetzt bin ich dabei sicher nicht repräsentativ… Nur ist in 2017 das Verhältnis zumindest bei mir von IPv4 zu IPv6 gekippt. Jetzt sind alle Systeme bei mir durchgängig IPv6 fähig und alles bewegt sich sicher sehr in seiner eigenen Blase, nicht zu viel herein steigern…
Gab es da nicht vor Kurzem eine Heise Meldung?
Schaue ich mir die großen an sieht man das es mehr wird und vor allem auch bei uns in Deutschland:
https://www.google.de/ipv6/statistics.html
https://stats.labs.apnic.net/ipv6
Mit einigen Bekannten habe ich ebenfalls gesprochen, hier zeigt sich ein sehr ähnliches Bild. Wir bleiben nur immer in der gleichen „Blase“. Mein Brötchengeber wäre noch ein ganz guter und sicher schon ein repräsentativ Statistikgeber, nur leider ist es hier produktiv noch extrem dunkel wenn es um IPv6 geht. 🙁 Hier gibt es gerade andere Baustellen.
Wie ist es denn bei euch? Jemand ein paar Zahlen oder Links für mich?
Update
Na schau an, eine erste Anregung habe ich schon mal. Mobile Endgeräte... Wenn man nicht gerade bei der Telekom ist sind viele noch mit ihren Smartphones auf IPv4 festgebunden. Statistiken von google/facebook/twitter usw. wird dieses sicher stark verfälschen. Wobei *grübel* verfälschen? Ist „das Internet“ (ich denke gerade an The IT Crowd) nicht inzwischen eher Smartphone? Benutzer mit einem Smartphone werden meine Webseite kaum anschauen, denn sie sieht mit so einem Gerät noch viel schlimmer aus als sie es bereits mit einem normalen Browser tut.
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ß
In meiner Werkstatt habe ich ein paar Elektrogeräte für welche ich gerne einen Sanftanlauf hätte. Einmal um den „Druck“ den hohen Anlaufstrom etwas von den ~Sicherungen~ zu nehmen und dann natürlich um die Geräte an sich etwas zu schonen, denn ein schlagartig anlaufender Elektromotor haut schon ganz schön rein 🙂
Natürlich gibt es viele schöne Dinge, die man einfach kaufen und zwischen stecken/einbauen kann aber ich wollte selbst einmal überlegen wie ich es realisieren kann und vor allem mit dem Zeug aus meiner „Restekiste“. So bin ich auf folgende Schaltung für meine Absauganlage gekommen. Die Anlage bekommt nur Strom, wenn ein anders Elektrogerät eingeschaltet wird und schaltet mit einem gewissen Nachlauf selbst ab (diese Schaltung führe ich vielleicht auch mal irgendwann auf). Es funktioniert also nicht diese einfach immer unter Strom zwischen zu stecken! Oh und natürlich sind Arbeiten am Strom sehr gefährlich und dürfen nur von Menschen ausgeführt werden, welche dieses dürfen 🙂 Diese Beschreibung also nicht nachmachen!
C1 und R1 arbeiten in der Schaltung als eine Art Kondensatornetzteil. D1 – D4 übernehmen die Aufgabe des Gleichrichters. R2 sorgt dafür, dass beim Abschalten die Schaltung möglichst schnell spannungsfrei ist (die Kondensatoren also entladen werden). C2 glättet die Spannung aus dem Gleichrichter, D5 nagelt die Spannung in der Schaltung auf ca. 18V fest. Über R3 wird C3 langsam geladen. R4 sorgt wieder für schnelles Entladen von C3. D6 schützt Q1 vor der Spule in K1, R5 ist die eigentliche „Handbremse“ für den nachgeschalteten Elektromotor. Er lässt, bis zum anziehen des Relais weniger durch und der Motor kann nicht mit voller Power loslegen.
Kommt also Spannung auf die Schaltung wird diese so lang über R5 zum Motor geleitet, bis C3 geladen ist. Denn wenn C3 voll ist, schaltet Q1 durch und somit zieht K1 an und überbrückt so R5.
R5 muss daher auf den nach gelagerten Elektromotor abgestimmt sein, sonst platzt R5 ggf. einfach. Die Größe von C3 bestimmt hierbei die Länge der Verzögerung von K1. 220μF war dabei für mich etwas zu klein. 440μF ist die perfekte Zeit
Die Platine selbst sieht nun so aus.
Oh, die Absauganlage besteht aus einem Nassauger von Kärcher hinter einem selbstgebauten Zyklonabscheider.
Fragen? Dann fragen 🙂
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.
Am 19 und 20.08 ist es wieder so weit. Die FrOSCon öffnet ihre Türen. https://www.froscon.de/
Ich bin in diesem Jahr auch wieder dort wer noch? 😀
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.
Einigen sehr aufmerksamen Bloglesern ist es ja inzwischen aufgefallen. Ja ich habe meine Schlüssel getauscht 🙂