-=Kernel-Error=-

Datenhaufen zu IT und Elektronik.

Autor: kernel-error (Seite 14 von 48)

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

8. August 2017 / / 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 / / 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.

DNSSEC, EDNS und PMTU-Size Fehler beim BIND beheben

5. Juli 2017 / / Keine Kommentare

Mir ist in der letzten Zeit an ein paar Systemen ein kleines „Problem“ im Zusammenhang mit DNSSEC, IPv6 und UDP Paketgrößen aufgefallen. Wobei aufgefallen hier nicht ganz korrekt ist, ich bin durch http://dnsviz.net darauf gestoßen worden. Die Jungs kommen mir nämlich mit der folgenden Warnung entgegen:

domain.tld/A: No response was received until the UDP payload size was decreased, indicating that the server might be attempting to send a payload that exceeds the path maximum transmission unit (PMTU) size. (2001:210:5000:bbbb::aaaa:1, UDP_0_EDNS0_32768_4096)

Diese Meldung besagt das es vom jeweiligen DNS Server erst eine Antwort gegeben hat, nachdem die UDP Größe verringert wurde. Dieses fällt einem im normalen Tests mit dig / drill oder ähnlichem nicht wirklich auf. Denn hier wird absolut automatisch die Paketgröße weiter verringert bis es klappt. Es „dauert“ nur etwas länger….

Der DNS-Server, in diesem Fall ein bind9.11, versucht auf die Frage mit einem IPv6 UDP Paket zu Antworten und schickt dieses mit 4096 Byte raus. Aus irgendeinem Grund (Firewall, Einstellungen im OS, Filter auf dem Netzwerk….) wird dieses Paket auf seinem Weg aber verworfen und erreicht sein Ziel nicht. Da wir hier über UDP sprechen merkt das der Server nicht und glaubt er habe seinen Job gut gemacht. Woher soll bind auch wissen das sein Paket nicht angekommen ist oder irgendwas auf dem Weg sein Pakete mit dieser Größe nicht mag?

Um als Admins herauszufinden wie groß die Pakete von seinem System denn werden können kann man folgenden einfachen Test nutzen:

$ dig +short rs.dns-oarc.net txt
rst.x490.rs.dns-oarc.net.
rst.x499.x490.rs.dns-oarc.net.
rst.x457.x499.x490.rs.dns-oarc.net.
"2001:310:6000:f::1fc7:1 sent EDNS buffer size 512"
"Tested at 2017-07-05 08:23:52 UTC"
"2001:310:6000:f::1fc7:1 DNS reply size limit is at least 499"

Wie zu erkennen ist endet es auf diesem System bei 512 Byte. Wenn wir uns jetzt nicht weiter um den Grund kümmern wollen oder können, müssten wir also unserem bind sagen das er bitte immer nur mit maximal 512 Byte arbeitet, wenn er UDP nutzt. Dieses geht wie folgt im Options Block:

options {
	[....]
	edns-udp-size 512;
	max-udp-size 512;
	[....]
};

edns-upd-size ist hier für das Empfangen und max-udp-size für das Senden von Paketen. Ab dem Moment probiert es bind nur noch mit 512 Byte und die Clients werde auf ihre erste Frage hin direkt eine Antwort bekommen, ohne die Frage so oft wiederholen zu müssen, bis sie schrittweise zurück auf 512 Byte sind.

So long…

FreeBSD: WLAN und der Ländercode korrekt einstellen

31. Mai 2017 / / 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?

Piwigo 2.8.2/2.9 Upgrade: Häufige Fehler und Lösungen

31. Mai 2017 / / Keine Kommentare

Da klicke ich doch gestern das Upgrade meiner Piwigo Bildergalerie von 2.8 auf 2.9 und es scheint sauber gelaufen zu sein. Leider findet sich ab dem Moment auf der Seite die folgende Fehlermeldung:

Warning:  [mysql error 1054] Unknown column 'last_visit' in 'field list'

UPDATE piwigo_user_infos
  SET last_visit = NOW(),
      lastmodified = lastmodified
  WHERE user_id = 1
 in /pfad/bilder.kernel-error.de/include/dblayer/functions_mysqli.inc.php on line 845

Was ist da wohl passiert? Im nginx Logfile findet sich dabei folgendes:

UPDATE piwigo_user_infos
  SET last_visit = NOW(),
      lastmodified = lastmodified
  WHERE user_id = 2
 in /pfad/bilder.kernel-error.de/include/dblayer/functions_mysqli.inc.php on line 845" while reading upstream, client: 2001:aaaa:aaaa:aaaa:eef4:bbff:fe47:c54c, server: bilder.kernel-error.de, request: "GET / HTTP/2.0", upstream: "fastcgi://unix:/var/run/php-fpm.sock:", host: "bilder.kernel-error.de"
2017/05/30 15:53:29 [error] 97077#100936: *1 FastCGI sent in stderr: "PHP message: PHP Warning:  [mysql error 1054] Unknown column 'last_visit' in 'field list'

Also schaue ich mir mal die Logmeldungen zum Zeitpunkt des Upgrades von Version 2.8.x auf Version 2.9.0 an und finde diesen Eintrag:

ALTER TABLE `piwigo_user_infos`
  ADD COLUMN `last_visit` datetime default NULL,
  ADD COLUMN `last_visit_from_history` enum('true','false') NOT NULL default 'false'
; in /pfad/bilder.kernel-error.de/include/dblayer/functions_mysqli.inc.php on line 845" while reading response header from upstream, client: 2001:aaaa:aaaa:aaaa:eef4:bbff:fe47:c54c, server: bilder.kernel-error.de, request: "GET /upgrade.php?now= HTTP/2.0", upstream: "fastcgi://unix:/var/run/php-fpm.sock:", host: "bilder.kernel-error.de"
2017/05/30 15:53:28 [error] 97076#100895: *48 FastCGI sent in stderr: "PHP message: PHP Warning:  [mysql error 1054] Unknown column 'last_visit' in 'field list'

Tja… Da ist beim Upgrade aus irgendeinem Grund also wirklich das Upgrade an der Datenbanke abgesoffen 🙁 Ich habe mir dann aus dem Upgradescript die passenden Einträge für die Datenbank herausgesucht und sie noch einmal von Hand auf die DB log gelassen:

ALTER TABLE `piwigo_comments` CHANGE `date` `date` datetime NOT NULL default '1970-01-01 00:00:00';
ALTER TABLE `piwigo_history` CHANGE `date` `date` date NOT NULL default '1970-01-01';
ALTER TABLE `piwigo_images` CHANGE `date_available` `date_available` datetime NOT NULL default '1970-01-01 00:00:00';
ALTER TABLE `piwigo_old_permalinks` CHANGE  `date_deleted` `date_deleted` datetime NOT NULL default '1970-01-01 00:00:00';
ALTER TABLE `piwigo_rate` CHANGE `date` `date` date NOT NULL default '1970-01-01';
ALTER TABLE `piwigo_sessions` CHANGE `expiration` `expiration` datetime NOT NULL default '1970-01-01 00:00:00';
ALTER TABLE `piwigo_upgrade` CHANGE `applied` `applied` datetime NOT NULL default '1970-01-01 00:00:00';
ALTER TABLE `piwigo_user_infos` CHANGE `registration_date` `registration_date` datetime NOT NULL default '1970-01-01 00:00:00';
ALTER TABLE `piwigo_user_infos`
  ADD COLUMN `last_visit` datetime default NULL,
  ADD COLUMN `last_visit_from_history` enum('true','false') NOT NULL default 'false'
;

Scheint zu passen 🙂

matrix und Riot als Ersatz für Jabber?

24. Mai 2017 / / Keine Kommentare

Ich teste im Moment matrix als Basis für die Kommunikation. Client ist dabei Riot auf Android und iOS und als Server probiere ich im moment Synapse aus. Alles unter der Domain: https://matrix.kernel-error.com

Beim Identiy Server bin ich einfach mal bei https://matrix.org geblieben! Alles ist noch sehr beta. Dafür tut es aber schon ganz ordentlich. Schreiben und Dateien verschicken funktioniert problemlos. Videocalls gehen so mäßig. Das Bild hängt halt immer mal wieder. Einfache Voicecalls klappten dafür richtig gut, sowohl zu zweit als auch in der Konferenz.

Etwas hakelig war das Einfügen von E-Mail Adresse und Rufnummer über den Andoid Client… Das war etwas verwirred. Hier ist der Workflow und die UI auf dem iOS besser. Insg. tut es aber….

Zuletzt habe ich nun den nginx als proxy for den matrix-synapse Server gesetzt. Dem vertraue ich an der Stelle einfach etwas mehr. Oh es läuft in einer FreeBSD 11 jail und dort auch recht Problemlos.

Sobald es mehr zu berichten gibt schreibe ich mehr! Wer es ebenfalls nutzt und mich anschreiben möchte: @kernel:matrix.kernel-error.com

So long…

Brute-Force Angriffe auf Joomla

10. April 2017 / / Keine Kommentare

Sobald man einen standard Dienst im Netz stehen hat wird dieser auch von verschiedenen Bots abgegrabbelt. Diese testen nach ungepatchten Versionen mit nutzbaren Sicherheitslöchern oder gehen Rainbow Tables durch. Gegen Sicherheitslöcher hilft ein Patchmanagement gegen Rainbow Tables helfen gute Kennwörter und ein Schutz gegen Brute-Force…. Einfach ist hier zum Beispiel der fail2ban Ansatz. Einfach mit zählen wie viele Fehlerhafte Logins in einem gewissen Zeitraum von einer IP-Adresse kommen und dann direkt die IP-Adresse für einen gewissen Zeitraum sperren.

Jetzt sind die Entwickler der Bots nicht dumm… Zuerst haben diese Bots genau so angefangen. Erstmal alle möglichen Kennwörter durchprobieren. Als ersten Schutz natürlich fail2ban, dann haben die Bots angefangen nicht mehr als genau drei Anfragen von einer IP Adresse zu stellen, etwas warten und dann wieder drei Anfragen. Man musste also im fail2ban „nachstellen“. Nun sind wir schon beim Punkt das diese Anfragen nicht mehr gebündelt als Dreierblock kommen sondern immer nur eine Anfrage von einer Adresse und 2 – 3 Stunden später erst wieder von dieser Adresse. Der einzelne Bot würde also Jahrzehnte brauchen um einige Versuche durch zugehen! Wenn er sich mit vielen anderen Abspricht, werden in kurzer Zeit noch immer sehr viele Kombinationen durchprobiert. Also wieder nachrüsten… Zwei Faktor, „Lebenderkennung“, Zertifikatslogin usw… Damit hat man sicher erst mal etwas Ruhe. OK, hier gibt es ebenfalls Möglichkeiten nur gibt es sicher genug schlechter gesicherte Ziele die zuerst angegangen werden können!

« Ältere Beiträge Neuere Beiträge »

© 2025 -=Kernel-Error=-

Theme von Anders Norén — Hoch ↑