I wish…

Nichts geht über große Zahlen, die hier zum Beispiel:

3028 marius 20 0 82,805g 197924 106164 S 3,0 1,2 1:24.88 /usr/libexec/webkit2gtk-4.0/WebKitWebProcess 2 20
2505 marius 20 0 98,788g 129688 60080 S 2,6 0,8 1:08.40 liferea

Reine Fiktion, weil mein Rechner nur 16 GB RAM hat. Was soll der Unsinn und vorallem, für was würde Liferea 100 GB Ram brauchen können ?

Vorallem, das wächst nicht über die Zeit an, es wird gleich beim Start fällig :

19657 marius 20 0 98,601g 127636 58256 S 1,0 0,8 0:03.26 /usr/bin/liferea –gapplication-service

Mit „pmem 19657“ sieht man dann auch den Batzen an RAM, der für nichts bestimmtes allociert zu sein scheint. Naja, ich hab den Maintainer mal angemailt, da es ja kein „Problem“ mit dem VMem gibt, es kann meiner Meinung nach keine Absicht gewesen sein, soviel RAM benutzen zu wollen, für einen RSS Feedreader!

Supermicro IPMI mit Remote-Exploit < FW 3.8

WARNUNG: Wer einen SuperMicro Server betreibt und noch die IPMI Firmware < 3.80 betreibt und extern erreichbare IPs benutzt, wird bald unerwünschten Besuch erhalten!

CVE-2019-6260

In der 3.65 Version der Firmware ist eine Schwachstelle enthalten, über die Hacker Zugriff auf das System bekommen können. Ein sofortiges Update ist angeraten, aber vorher prüfen, ob Ihr nicht schon infiziert seid, weil sonst Beweise vernichtet werden.

Workaround: die IP auf eine lokale IP umstellen

$ ipmitool lan set 1 ipaddr 192.168.1.2
$ ipmitool lan set 1 ipsrc static

Static, damit sich das nicht per DHCP Update wieder umstellt! DHCP als DEFAULT für eine IPMI !!! unglaublich!

Wie kommt man darauf? Wenn man einen Anruf bekommt, daß das Cluster XZY plötzlich so langsam reagiert und ein XenServer Mensch da mal nachsehen soll. Warum war es langsam, weil da jemand BitCoin gemint hat, mit allen 52 Kernen 😀

Für den Fall, daß Euch das auch passiert, hier eine Checkliste:

CHECKLISTE

  1. last -ai
    Wenn im last-Output „tty“ als Konsole auftaucht, ohne IP, dann ist es die IPMI.
  2. /etc/passwdDie müßt Ihr auf einen weiteren Rootuser hin checken, also 0:0 als UID:GID. Wenn da, dann auch in der /etc/shadow löschen
  3. crontab -lPrüfen ob der Miner per Cron neugestartet wird.
  4. CronjobsPrüfen ob die Cronjobs unter /etc/cron* manipuliert oder welche hinzugefügt wurden.
  5. Verbindungen checkenmit „netstat -lnap| grep LISTEN“ prüfen ob da Dienste laufen, die da nicht hingehören.
    mit „netstat -lnap| grep VERBUNDEN“ prüfen, ob da grade aktiv was ausgeleitet wird.
  6. System überprüfen, z.b. „yum reinstall *“ um unveränderte Software zu bekommen, aber Vorsicht, daß kann auf einem Produktionssystem auch in die Hose gehen. Vielleicht weniger invasiv mal nach kürzlich geänderten Dateien suchen:find / -ctime -30
    find / -mtime -30

Im Beispiel sind es 30 Tage. Wenn man dann „verdächtige“ Files hat, kann man z.b. rpm -qf filename benutzen und sieht, ob die über das System kamen oder von Hand sind.

Kleines Update: „rpm -qa | awk ‚{print „rpm -V „$1;}‘ | bash“ sehr nützlich beim prüfen von korrekten Files.

WICHTIG: ERST MIT TAR ARCHIVIEREN, DANN LÖSCHEN! Gilt auch für Logfiles.

Link: https://nvd.nist.gov/vuln/detail/CVE-2019-6260

Friendica Update 2019.03 nicht ganz wie in der Anleitung

Da denkt man, man müßte nur der Anleitung folgen und am Ende, ist es doch wieder Arbeit 🙂 Friendica 03.2019 ist eigentlich ganz einfach anzuwenden,
wenn man nicht der Anleitung folgt 😉

Friendica 2019.03 „Dalmatian Bellflower“ Released

Am Ende war es ja nur wieder, alles nochmal machen und einen Bugreport, und 2 Patchfiles einreichen. Ich hatte mich entschieden nicht git zu nehmen, sondern das Komplette Tar-Archiv auszurollen. Dazu gibt es u.a. diese Anleitung:

Using the Archive Files

If you had downloaded the source files in an archive file (zip or tar.gz) please download the current version of the archive (friendica-full-2019.03.tar.gz and friendica-addons-2019.02.tar.gz) and unpack it on your local computer.

Da man eh beide Files braucht, hätte man die auch gleich zusammen ausliefern können. Nur son Gedanke.

As many files got deleted or moved around, please upload the unpacked files to a new directory on your server (say friendica_new) and copy over your existing configuration and .htaccess files. Afterwards rename your current Friendica directory (e.g. friendica) to friendica_old and friendica_new to friendica.

und hier fängt der Ärger an, wenn man jetzt „cp config/* to_new_path/config/“ macht. Ihr dürft NUR die local.config.php und die addon*.config.php kopieren. Die anderen dürfen nicht übergenagelt werden, sonst ist aus Friendica ein Unfriendica geworden 🙂

Please be aware of the changes in the configuration format. You should follow the instructions linked from your admin panel as soon as possible to move your configuration to the new location.

Welche Instructions? Da waren keine 😉 Und dann halt noch das DB Update hinterher, aber da das lief, lassen wir das mal unbeachtet.

Danach dürft Ihr gleich noch zwei Bugs beheben, wenn Ihr wollt 🙂

include/conversations.php: Zeile 821 muß so aussehen: if (is_array($comments) && count($comments) != 0) {
src/Model/Photo.php: Zeile 177 bitte einfügen: if (!isset($photo[„backend-class“]) return null;