Zockertown: Nerten News

Ab- und zu mal einen Blick auf die lang dauernden SQL Queries gucken, macht Sinn

In /etc/mysql/mariadb.conf.d/50-server.cnf

Müssen entsprechende Einträge existieren:

# Enable the slow query log to see queries with especially long duration
slow_query_log
slow_query_log_file     = /var/log/mysql/mariadb-slow.log

Bei mir fehlte slow_query_log. Die Angabe des Logfiles allein reicht nicht.

slow_query_log also einfach hinzugefügt, die Datenbank gestartet und schon kanns losgehen.

Momentan ist es allerdings leer 

Mit Überwachungstools ist die Linuxfamilie reichlich gesegnet. 

Seit mehreren Jahren setze ich collectd ein. Dieser Daemon schreibt fortwährend Perfomancedaten im rrd Format auf die Platte und ist netzfähig.

Das umwerfende an collectd ist seine einfache Konfiguration.

Das meiner Meinung nach am einfachsten zu verwendende grafische Interface ist CGP (Collectd Grafik Panel)

Auf Buster musste ich ein wenig fummeln, bis es wieder lief.

Es war zu lange her, dass ich damit was zu tun hatte, weil es einfach lief

Lange Rede kurzer Sinn:

Damit die Grafiken dargestellt werden können, muss Open_basedir angepasst werden:

Mit dem Plugin Processes habe ich ein wenig rumgespielt, dabei ist mir eine fehlende Grafik im CGP aufgefallen.

Im Apache error.log fand ic:

ERROR: No DS called 'value' in '/var/lib/collectd/rrd/domain.de/processes-pg_autovacuum/io_ops.rrd'

Ich habe es so gelöst.
in CGP/inc/types.db
Added
io_ops read:DERIVE:0:U, write:DERIVE:0:U

in
CGP/plugin/processes.json
Added

        "ps_io_ops": {
                "title": "IO Operations ({{PI}}) on {{HOST}}",
                "vertical": "Ops per second",
                "type": "io",
                "legend": {
                        "read": {
                                "name": "Read",
                                "color": "0000ff"
                        },
                        "write": {
                                "name": "Write",
                                "color": "00b000"
                        }
                },

Warum blogge darüber nach ca. 6 Jahren Einsatz erst jetzt? Damit ich beim nächsten Mal wenigstens schon mal einen Eintrag habe

Im Ernst, gerade heute hatte ich mich gewundert, warum der Server so einen stark erhöhten Load hat, wo er doch meist nur vor sich rum dümpelt. Ich gebe zu, ich hatte erst wieder einen ungebetenen Gast in Verdacht und fahndete nach einen nicht vorhandenen Geist. Doch dann fiel mir ein, dass Softraid alle 4 Wochen Sonntags immer einen Check durchführte....

Bingo! # dmesg -T |grep md:
[Mon Jan 20 03:42:11 2020] md: data-check of RAID array md0
[Mon Jan 20 03:42:11 2020] md: delaying data-check of md1 until md0 has finished (they share one or more physical units)
[Mon Jan 20 03:42:15 2020] md: md0: data-check done.
[Mon Jan 20 03:42:16 2020] md: data-check of RAID array md1

Schön, das war also geklärt

(Wenn der Check fertig ist, momentan ist er bei:

cat /proc/mdstat |grep check
      [===================>.]  check = 99.6% (2919523968/2929609152) finish=7.4min speed=22487K/sec

Achso, also gleich fertig, dann warte ich noch die paar Minuten und schreibe gleich weiter

# dmesg -T |grep md:
[Mon Jan 20 03:42:11 2020] md: data-check of RAID array md0
[Mon Jan 20 03:42:11 2020] md: delaying data-check of md1 until md0 has finished (they share one or more physical units)
[Mon Jan 20 03:42:15 2020] md: md0: data-check done.
[Mon Jan 20 03:42:16 2020] md: data-check of RAID array md1
[Mon Jan 20 19:25:31 2020] md: md1: data-check done.

Der Check hat also knapp 16 Stunden gedauert und mich dadurch mit vielen (ca. 50 email vom Monitoring System) genervt.

Zu den Benachrichtitungen schreibe nochmal einen Extra Artikel, momentan ist das nämlich nicht mit Collectd realisiert. Dabei sollte ich gleich diesen vorhersehbaren Load Anstieg berücksichtigen und die Schwellwerte  in der Zeit anpassen.

Zum Abschluß heute noch einen Screenshot der Load Grafik, die sich sehr gut mit dem dmesg Eintrag deckt.

Ich habe die Kombi png / Canvas eingestellt, dadurch kann ich in der Detailansicht sehr fein zoomen. 

Ps: Bei Buster ist der Cronjob anders eingestellt, nämlich immer am 20. des Monats

42 3 20 * * root if [ -x /usr/share/mdadm/checkarray ]; then /usr/share/mdadm/checkarray --cron --all --idle --quiet; fi

Beim Durchsehen der Statistiken ist mir besonders beim Disk Traffic aufgefallen, dass ich mir die Bösewicht Sucherei wirklich hätte schenken können, dieses Bild ist eher unüblich für malware.

In MariaDB 10.2 und später ist das DYNAMIC-Zellenformat das Standardzellenformat. Wenn die Tabellen ursprünglich auf z.B. Compact stehen, kommt es zu Fehlermeldungen im mysql error.log.

[Warning] InnoDB: Cannot add field `basic_auth_password` in table `xxowncloud`.`oc_news_feeds` because after adding it, the row size is 8269 which is greater than maximum allowed size (8126) for a record on index leaf page.

Mit dem folgenden SQL Statement : (irgendwo im Netz gefunden)

SELECT NAME, ROW_FORMAT

FROM information_schema.INNODB_SYS_TABLES

WHERE ROW_FORMAT IN('Redundant', 'Compact')

AND NAME NOT IN('SYS_DATAFILES', 'SYS_FOREIGN', 'SYS_FOREIGN_COLS', 'SYS_TABLESPACES', 'SYS_VIRTUAL', 'SYS_ZIP_DICT', 'SYS_ZIP_DICT_COLS');

Gibt man eine Liste der Tabellen, die nicht auf DYNAMIC stehen, aus.

Ein Beispielauszug.

| xxowncloud/oc_properties                                        | Compact    |
| xxowncloud/oc_schedulingobjects                                 | Compact    |
| xxowncloud/oc_share                                             | Compact    |
| xxowncloud/oc_share_external                                    | Compact    |

Da es bei mir mehr als 1000 Zeilen waren, habe ich mit etwas einzeiler Script Magie (Dirty, hat aber geklappt) ein SQL Script generiert, um die Tabellen zu ändern.

Das Ergebnis des oberen SQL Kommandos in eine Datei als repair-inno.sql gespeichert.

Dann mit dem Einzeiler:

​cat repair-inno.sql |awk '{ printf "ALTER TABLE `%s`  ROW_FORMAT=DYNAMIC;\n",$2 }'|sed s'/\//\`.`/g'>innodb2dynamic.sql

die Datei in das hier gewandelt:

ALTER TABLE `xxowncloud`.`oc_properties`  ROW_FORMAT=DYNAMIC;
ALTER TABLE `xxowncloud`.`oc_schedulingobjects`  ROW_FORMAT=DYNAMIC;
ALTER TABLE `xxowncloud`.`oc_share`  ROW_FORMAT=DYNAMIC;
ALTER TABLE `xxowncloud`.`oc_share_external`  ROW_FORMAT=DYNAMIC;

und mit mysql -u root -p ausgeführt.

Hat etwas gedauert, aber nun sind alle Tabellen geändert, wie ein erneuter Select Befehl zeigt.

Nun ist Ruhe im Error Log

SMART Self-test log structure revision number 1
Num  Test_Description    Status                  Remaining  LifeTime(hours)  LBA_of_first_error
# 1  Extended offline    Completed: read failure       90%     58160         1050014
# 2  Extended offline    Completed without error       00%     55855         -

​wie gewünscht haben wir die defekte Festplatte mit der S/N: xxxxx für Sie ausgetauscht.
Leider haben wir momentan keine 3 TB Enterprise HDDs mehr im Lager,
daher haben Sie von uns eine 4 TB Enterprise HDD bekommen.

Als ich nach wenigen Minuten nach dem Einbau der Platte die Partitionierung durchführte und gerade dem Raid wieder die neuen Partionen hinzufügen wollte, stand der Server.

Es half nur ein manueller Hardware Reset, der bei Hetzner nach wenigen Minuten durchgeführt wurde.

Ursache war

wie gewünscht haben wir Ihren Server überprüft, es schien wohl ein Problem mit der neuen HDD 
im Zusammenspiel mit der alten BIOS-Version auf dem Server zu bestehen.

Wir haben die BIOS-Version auf die aktuellste von uns geprüfte und freigegebene Version 
aktualisiert und den Server ins installierte System starten lassen.

Tja so ist das eben. Naja, Downtime unter 30 Minuten, das Raid synct natürlich noch...

Heute wurde der Server von Stretch auf Buster angehoben.

Caveats:

Bei Dovecot hat sich eine Sache in der dovecot.conf Syntax geändert.

Gut beschrieben ist es hier: https://b4d.sablun.org/blog/2019-02-25-dovecot_2.3_upgrade_on_debian/

Weil ich ispconfig benutze, wurde das auch gleich upgegradet auf 3.1.15p2.

Dabei festgestellt, dass ich noch die diversen php7.3 pakete nachinstallieren musste.

Ich habe auch confluence laufen, also Java und tomcat gedöns. Deshalb ist postgres installiert, welches ein 

postgres reindexdb --all

benötigt. (Man wird aber darauf hingewiesen)

Mal sehen, was es noch für Probleme gibt ...

Nur mal so für mich zum merken.

Immer wenn ich mal auf einem neuen (jungfräulichen) Linuxrechner zu tun habe, fehlt mir meine Lieblingseinstellung für den vi

cat ~/.vimrc
:map <F2> :w\|!python3 %<CR>
:color industry
if has("autocmd")
  au BufReadPost * if line("'\"") > 1 && line("'\"") <= line("$") | exe "normal! g'\"" | endif
endif

Der :map auf F2 sorgt für das unmittelbare Ausführen des Python Codes.

Aber das ist nur ein Gimmick.

:color ist selbsterklärend.

Wichtiger für mich ist der autocmd Teil. Das sorgt dafür, dass sich vi(m) merkt, in welcher Zeile ich in jeweiliger Datei war.

Ps: habt ihr evtl. noch andere Dinge, die das Leben erleichtern?

Ein Medion Akoya E1210 fiel mir nach vielen Jahren wieder in die Hände.

Es war Debian 8 Jessi installiert.

Irgendwann war das Gerät zu klein, vor allem die Auflösung und der etwas lahme Prozessor waren wohl das Manko, was zum einmotten führte.

Bevor ich das Teil wieder in die Versenkung schicke, dachte ich mir, guckst du doch mal was das schlaue Internet dazu sagt.

Das Ergebnis:

Das Gerät ist weitgehend baugleich zum MSI Wind U100

Unterschied zum MSI U100: im Medion ist kein eingelötetes RAM, sondern nur ein Steckplatz, der ab Werk mit 1GB bestückt ist.

Der Hammer ist allerdings, dass es die Möglichkeit gibt das E1210 mit dem MSI BIOS zu flashen, um dann auch die Übertaktungsmöglichkeiten zur Verfügung zu haben.. Immerhin sind bis zu 124% CPU Takt drin!

Also ans Werk:

Freedos von http://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/distributions/ geholt,

BIOS von https://www.msi.com/Laptop/support/U100#down-bios.

Damit einen bootfähigen USB Stick konstruiert und das E1210 damit geflasht.

Eine fast 100% richtige Anleitung wie man das macht ist hier:

https://feeding.cloud.geek.nz/posts/creating-freedos-bootable-usb-stick-to/

(Richtig: cp /usr/lib/syslinux/mbr/mbr.bin . Falsch: cp /usr/lib/syslinux/mbr.bin .)

Das Gerät muß dazu am Netz sein, wenn es auf Akku läuft, verweigert das Flash Utility die Arbeit mit der irreführenden Fehlermeldung, es hätte die vorhergehende BIOS Version nicht auslesen können, obwohl der Schalter, um die Überprüfung zu übergehen gesetzt ist.

Nach stromlos machen, 30 Sekunden warten muß beim nun folgenden ersten Boot die ESC Taste gedrückt werden, denn wie oben bereits erwähnt hat das MSI Board 1GB eingelötetes RAM, das natürlich initialisiert, bzw. gecheckt wird. Da das beim Medion nicht vorhanden ist, führt der Versuch zum schwarzen, eingefrorenen Bildschirm.

Mein Medion Akoya E1210 läuft nun mit Debian 10 Buster, Mate Desktop und 24% Übertaktung recht flott.

Was mache ich nun damit?

Ich denke im Elektronik Bastelzimmer ist es gut aufgehoben, um mal schnell einen Datenblatt nachzuschlagen oder ähnliches.

Ok, Chromium ist etwas träge, der Epiphany ist ein klein wenig flotter, eine reine Fraude ist das aber auch nicht, vielleicht sollte ich die 12,50€ für einen 2GB Riegel ausgeben, schadet bestimmt nicht. Denn nur der laufende Webbrowser mit ein paar einfachen Seiten und evince mit einem PDF Dokument reichen bereits aus um das RAM auszulasten und ersten 200MB Swap zu nutzen.

Die 80GB Hitachi Platte könnte man noch gegen eine SSD tauschen. Sollte ich mal mein Tuxedo XC1506 aufrüsten, fällt eine gebrauchte SSD 256 ab.

Ich hatte mich ja in meinem ersten Artikel über den neuen Laptop über die fehlenden Einstellungen für die Akku Ladestrategie mukiert. Jetzt (Aprif 2016) habe ich einen FAQ Eintrag gefunden, der genau dieses Problem angeht.

Beim Tuxedo XC1506 übernimmt das die BIOS Funktion "Flexicharge" FAQ Artikel im Supportforum von Tuxedo

Damit bin ich die gefährlichen Mikro Ladezyklen und das "immer Volle Pulle" auf 100% laden los.

Update 04.10.2019: Mein Laptop ist ca. 3,75 Jahre alt. Der Akku hat noch 94% seiner Design Kapazität. Ich habe die Schwellen auf 70% und 90% eingestellt. Der Laptop ist zu 95% am Netz.

Diese Frage hat mich heute Morgen beschäftigt, als mich Gnome mit einer Notiz "wichtige Aktualisierungen sind verfügbar" (leider keinen Screenshot gemacht) darauf aufmerksam machte und mir die Wahl zwischen "nicht jetzt" und "Ja, aktualisieren" ließ.

Na klar, wollte ich das mal ausprobieren, also auf "Ja" geklickt.

Dann kam der Hinweis, das dazu der Rechner rebootet werden muss.

WTF? Das hat mich dermaßen geschockt, dass ich erneut den Screenhot vergaß.

Also habe ich gesagt, "OK".

Was dann kam hat mich doch sehr überrascht. Es wurde sofort der Shutdown eingeleitet auf halben Wege  wurden dann die Pakete installiert und danach fuhr der Rechner  weiter mit dem Reboot fort.

Jetzt gab es auf dem Desktop diese Nachricht.

Hiervon habe ich einen Screenshot gemacht.

Es war ja schon lange in der internen Diskussion bei Debian, über das Für und Wider von automatischen Installationen.

Aus Sicht eines einfachen, evtl. von Windows migrierten Anwenders vielleicht gar nicht die schlechteste Idee.

Abschalten oder einfach ignorieren, bis man es dann selber macht kann man es ja trotzdem.

Doch ich bin besonders verblüfft über die Art und Weise. Ist der Reboot nun obligatorisch? Hoffentlich nicht, das wäre dann wirklich eine Verschlechterung. Bisher war das meiner Meinung nach eins der wichtigsten Argumente Linux anstelle Windows für die tägliche Arbeit zu benutzen. Wenn ich sehe wie häufig Windows Systeme wegen einer Software Aktualisierung reboot werden müssen....

Ps: ich suche nochmal die Pakete raus, die aktualisiert wurden,  es war vermutlich etwas dabei, das einen Reboot erfordert.

Nachtrag: Ja, diese Pakete waren betroffen. U.a. der Kernel.

Start-Date: 2019-08-14  08:38:35
Commandline: packagekit role='update-packages'
Upgrade: libpangoft2-1.0-0:amd64 (1.42.4-6, 1.42.4-7~deb10u1), libpangoft2-1.0-0:i386 (1.42.4-6, 1.42.4-7~deb10u1), linux-libc-dev:amd64 (4.19.37-5+deb10u1, 4.19.37-5+deb10u2), 
chrome-remote-desktop:amd64 (76.0.3809.21, 76.0.3809.117), libgs9:amd64 (9.27~dfsg-2, 9.27~dfsg-2+deb10u1), linux-image-4.19.0-5-amd64:amd64 (4.19.37-5+deb10u1, 4.19.37-5+deb10u2), 
chromium:amd64 (73.0.3683.75-1, 76.0.3809.100-1~deb10u1), gir1.2-pango-1.0:amd64 (1.42.4-6, 1.42.4-7~deb10u1), linux-compiler-gcc-8-x86:amd64 (4.19.37-5+deb10u1, 4.19.37-5+deb10u2), 
chromium-sandbox:amd64 (73.0.3683.75-1, 76.0.3809.100-1~deb10u1), chromium-common:amd64 (73.0.3683.75-1, 76.0.3809.100-1~deb10u1), pango1.0-tools:amd64 (1.42.4-6, 1.42.4-7~deb10u1), 
libpangoxft-1.0-0:amd64 (1.42.4-6, 1.42.4-7~deb10u1), libpango1.0-dev:amd64 (1.42.4-6, 1.42.4-7~deb10u1), libpangocairo-1.0-0:amd64 (1.42.4-6, 1.42.4-7~deb10u1), 
libpangocairo-1.0-0:i386 (1.42.4-6, 1.42.4-7~deb10u1), ghostscript:amd64 (9.27~dfsg-2, 9.27~dfsg-2+deb10u1), linux-headers-4.19.0-5-amd64:amd64 (4.19.37-5+deb10u1, 
4.19.37-5+deb10u2), libgs9-common:amd64 (9.27~dfsg-2, 9.27~dfsg-2+deb10u1), linux-kbuild-4.19:amd64 (4.19.37-5+deb10u1, 4.19.37-5+deb10u2), 
linux-headers-4.19.0-5-common:amd64 (4.19.37-5+deb10u1, 4.19.37-5+deb10u2), libpango-1.0-0:amd64 (1.42.4-6, 1.42.4-7~deb10u1), libpango-1.0-0:i386 (1.42.4-6, 1.42.4-7~deb10u1)
End-Date: 2019-08-14  08:39:21

Die alte Variante gefiel mir besser, es wurde einfach eine Marker Datei " /var/run/reboot-required" angelegt.

Bei einem Server ist es vermutlich immer noch so, aber auch so mancher Entwickler wird sich ärgern, wenn er durch ein leichtfertiges "Ja" seine gesamte Palette an gestarteten Programmen schwinden sieht und er alles wieder einzeln öffnen muss.

Nun Gut, das passiert nur ihm sicher nicht nochmal... 

Zum nachlesen 

https://anarc.at/blog/2016-12-22-debian-considering-automated-upgrades/

https://www.pro-linux.de/news/1/24312/debian-diskutiert-%C3%83%C2%BCber-automatische-aktualisierung-als-standard.html

Nachtrag 18.8.2019:

So, wieder wird mir von gnome eine notwendige Betriebssystem Aktualisierung angezeigt.

Auch hier blau hervorgehoben, im Hintergrund noch gerade erkennbar wird von Neustart geredet.

Diesmal ist kein Kernel Update und auch die Libs sehen für mich nicht so auss, als wäre ein Neustart notwendig.

Also kurzerhand in der Console apt update und full-upgrade gemacht.

Es wird kein /var/run/reboot-required  angelegt, also ist kein Reboot aus Sicht des Packagemanagers notwendig, dennoch wurde der Anwender von der Notwendigkeit, (siehe links) infomiert.

Erschwehrend kommt ja noch hinzu, dass man, wenn man ok gesagt hat ja den Neustart nicht mehr aufhälten kann. Das macht Windows besser (Oh Gott, dass ich das mal sage ..), denn dort wird installiert und man bekommt die Option den Neustart später zu machen.

Fazit für mich, ich inoriere die GUI Benachrichtigung und mache es weiterhin in der Console, wenn es mir passt.

Was gab es lange nicht auf Zockertown? richtig eine politische, engagierte Meinungsäußerung.

Nun, dem kann abgeholfen werden.

Plastiktüten verbieten! Tolle Idee?

Meint man alle Tüten aus Plastik, also auch die hauchdünnen beim Schlachter, auf dem Markt am Gemüsestand, die Plastiktüten, in denen Zierfische nach Hause getragen werden, oder nur Einkaufstüten?

Will man danach für jeden Verpackungsgegenstand ein neues Gesetz schaffen?

Warum gerade jetzt?

Ich behaupte, es ist einfach mal wieder ein Schnellschuß, der wieder nicht durchdacht ist und Wahlkampfgetöse ist.

Wie komme ich darauf? Meine Argumente sind:

Eine Einkaufstüte findet doch irgendwann ihr Ende als Sammelbeutel für den Gelben Sack...

Deutschland hat eine sehr große Recycling Quote, bedingt durch den Grünen Punkt. Ein Alleingang für Deutschland ist außerdem meiner Meinung nach witzlos. Unsere Plastiktüten landen nicht im Meer, sondern wenn es gut läuft in Müllverbrennungsanlagen zusammen mit den anderen Plastikverpackungen. Wenn es schlecht läuft in Afrika, wo sie dann vom Winde verweht über Umwege doch im Meer landen. Früher hatte Cina unseren Plastikmüll gekauft, was jetzt wohl vorbei ist.

Warum also nicht lieber den Export von Gelben Säcken, also die gesammelten "Grüner Punkt Verpackungen" ins Ausland verbieten?

Unsere deutschen Umweltgesetze sorgen wenigstens dafür, dass unsere Müllverbrennungsanlagen relativ sauber sind im Vergleich zur Verklappung auf andere Kontinente.

Warum nicht die Mineralölsteuer auch auf sämtliche Kunststofferzeugnisse ausweiten? Derzeit werden die Plastiktüten aus unversteuertem Mineralöl hergestellt. Warum?

Ich sehe nicht ein, da einen Unterschied zu machen. Mineralöl als Treibstoff wird versteuert, aber die Erzeugung von Kunststoff nicht.

Das Ergebnis wäre eine Verteuerung der Plastiktüten, was den Verbrauch einschränken würde.

Derzeit sind Papiertüten im Supermarkt teurer als Plastiktüten, warum?

Warum fördert man nicht alternative Herstellungsmethoden für Verpackungen aus nachhaltigen Materialien?

Es gibt ja bereits Alternativen. Wobei es da auch etliche Fallen gibt. Siehe https://www.umweltbundesamt.de/themen/tueten-aus-bioplastik-sind-keine-alternative

Ein weitere Ansatz wäre das fördern von wiederverwendbaren Tragetaschen. Die hat bereits jeder Supermarkt im Angebot mit Eigenwerbung bedruckt. Vielleicht wäre eine verstärkte Werbung für die wiederverwendbaren Tragetaschen, gefördert durch das Umweltbundesamt die beste Idee?

Zum weiterlesen:

http://www.michael-bockhorst.de/2015/12/plastiktuten-hysterie/

https://www.wissenschaft.de/umwelt-natur/wie-viel-oel-steckt-in-plastiktueten/

https://www.zeit.de/2018/04/abfall-muell-deutschland-china-exporte

Ich bin heute von Stretch auf Buster gewechselt, auf meinem Dektop fehlten jetzt die Icons. Default sind die nicht mehr eingeschaltet bei Gnome 3.30.

Ich habe die gnome-tweaks (in Gnome Sprech=Optimierungen) installiert, damit kann man das steuern.

Das Werkzeug Optimierungen starten und im Abschnitt Erweiterungen die Desktop Icons einschalten. 

Wenn das nicht geht weil das Feld inaktiv ist, dann fehlt sicherlich das Paket gnome-shell-extension-desktop-icons.

Nachinstallieren mit apt install gnome-shell-extension-desktop-icons  und dann läßt es sich einschalten. Schwupps sind die Icons wieder da

Taucht "Optimierungen" gar nicht nicht auf wenn man danach sucht, dann einfach gnome-tweaks installieren mit apt install gnome-tweaks. (oder mit einem anderen Debian Tool)

Ps: Kommentare beachten!

Ich liebe die Suchfunktionalität in Gnome 3, habe ich das schon erwähnt?

Einfach die Meta Taste drücken und anfangen zu tippen ... Einfacher geht es nicht.

Oder mit der Maus ins linke obere Eck fahren, das geht auch.

Es geht ja momentan durch die News, google hat bald Stadia am Start. Das ist eine Plattform, die die Computerspiele als Streaming Dienst anbieten wird.

Vorteil für den User, die Hardware muss nur den Chrome Browser starten und betreiben können. Die normalen integrierten Grafikkerne in den CPUs werden reichen, wenn sie jetzt schon FullHD Videos darstellen können.

Das bedeutet also, jeder halbwegs aktuelle  Laptop ohne dedizierte Grafikkarte ist dafür geeignet.

Was mich dazu bewogen hat, schonmal das Starterpaket zu ordern. Es besteht im wesentlichen aus Controllpad und Chromecast Ultra.

"Warum das? Ist das nicht zu teuer?" Lieber Spiele kaufen und lokal Spiele installieren!

Naja, mein Gedanke ist: Der momentane Laptop ist der XC1506 von Tuxedo, rennt wie der Teufel, aber der kommt auch mal an sein Lebensende und dann?

Wieder einen Haufen Geld für einen Spiele tauglichen Laptop ausgeben, oder nicht doch lieber einen Laptop in Top Qualität ohne dedizierte Grafik und mit ordentlich Akkulaufzeit, der ganz nebenbei auch leichter und preiswerter ist?

Für mich mit meinen 2-3 Spielen, die ich gelegentlich in Wellen mal spiele doch die klügere Alternative.

Ok, Spielen geht dann natürlich nur Online und es fragt sich, ob es überhaupt meine Spielekategorien, also Singleplayer;Strategie; auf Stadia geben wird...

Hhm. was meint ihr?

Ich stelle immer wieder fest, das ich nach einer Neuinstallation nicht auf Anhieb an alle Helferlein und Tools denke, die mir in meinem Dasein als Debian Nutzer ans Herz gewachsen sind.

Deshalb hier die lose Zusammenstellung meiner Favoriten mit kurzer Erläuterung dazu.

Die Reihenfolge hat keine Bedeutung, sind mir halt so eingefallen.

Paketname	Paket Beschreibung	Bemerkung
ncdu	ncurses disk usage viewer	Unentbehrlich, um die Platzverschwender zu orten und auch gleich ggfs. zu löschen
dlocate	fast alternative to dpkg -L and dpkg -S	Wenn man mal wieder nicht weiß zu welchem Paket eine Datei gehört. Das Paket muß natürlich auch installiert sein.
mlocate	quickly find files on the filesystem based on their name	locate -i mitgliedschaft findet alle Dateien mit mit diesen Namen
apt-file	search for files within Debian packages (command-line interface)	Gegenüber dlocate findet es auch Dateien in nicht installierten Pakteten. Erstellt dazu eine Datenbank
localepurge	Reclaim disk space removing unneeded localizations	Einmal konfiguriert, tut es zuverlässig seinen Dienst, allerdings verlangsamt es ein apt-get install bzw. upgrade....
htop	interactive processes viewer	Das bessere top
iotop	interactive IO Viewer	Welcher Prozess macht am meisten IO?
debian-goodies	Kleine Programmsammlung für Debian-Systeme	u.a. dpigs
tlp	Save battery power on laptops	Wenn man einen Laptop hat, nützlich um die Ladeschwelle für den Akku einzustellen
hdapsd	HDAPS daemon for various laptops with motion sensors	Fallschutz für Laptops
smartmontools	control and monitor storage systems using S.M.A.R.T.	Gesundheit der Platten überwachen
inxi	full featured system information script	z.B. mit inxi -v6 eine Äbersicht gewinnen
aha	ANSI color to HTML converter	z.B. inxi -v6|aha >t500.html
shellcheck	Prüft ein Shell Script auf typische Fehler	z.B. shellcheck mein-script.sh
wird ergänzt

Wegen eines leicht erhöhten Load hat mich nagios informiert. Was macht man da als Admin? Klar, mal gucken, was das denn schon wieder sein könnte....

Ich habe in einem Joomla Web auf meinem Server einen fiesen Burschen eingefangen, der andere Server  angreift.

   21936     1  0 17:13 ?        00:00:01 /usr/bin/perl ./jcache domain.de
   21938     1  0 17:13 ?        00:00:00 /usr/bin/perl ./jcache domain.de
   21940     1  0 17:13 ?        00:00:01 /usr/bin/perl ./jcache domain.de
   21942     1  0 17:13 ?        00:00:01 /usr/bin/perl ./jcache domain.de
   21944     1  0 17:13 ?        00:00:01 /usr/bin/perl ./jcache domain.de
   21946     1  0 17:13 ?        00:00:00 /usr/bin/perl ./jcache domain.de
   21948     1  0 17:13 ?        00:00:00 /usr/bin/perl ./jcache domain.de
   21950     1  3 17:13 ?        00:00:05 /usr/bin/perl ./jcache domain.de
   21952     1  0 17:13 ?        00:00:00 /usr/bin/perl ./jcache domain.de
... insgesamt 18 Prozesse ...

 Das habe ich durch mitlesen der Prozesse durch strace -p Beobachtung herausgefunden.

Abschalten ist kein Problem, es kommt aus dem Joomla.

Wenn ich das Web kurz aktiviere werden die Perl Prozesse innerhalb kurzer (unterschiedlichen Zeiträumen im 1-2 stelligen Minutenbereich) wieder gestartet.

Das Problem ist, dass ich keine manipulierte Datei oder extra Datei im betreffenden Web finden kann. Klar, ich werde ein Backup einspielen, nur ist es schon eigenartig, dass ich keine Spuren finde. Eine Möglichkeit wäre ja, das an der Datei der Datumsstempel manipuliert worden ist. maldet findet auch nichts.

Es wäre gut zu wissen, was ich mir da eingefangen habe. Nach den straces jedenfalls etwas fortgeschrittenes, es liest meine /etc/hosts /etc/resolv.conf und /etc/ssl/certs/ca-certificates.crt aus und greift verschiedene Server auf Port 80 und 443 an um nach Lücken in Wordpress Installationen zu finden.

Allerdings macht mich ein Fund in meinen Traces mißtrauisch .

/var/www/clients/clientN/webMMM/tmp/phpSM2Np7  (deleted);

Möglicherweise wird, nachdem das Script gestart wurde, die Datei auch gleich wieder gelöscht?!

Um den auf die Spur zu kommen, habe ich nun ein kleines Script gebastelt, um das eingespielte Backup zu überwachen, denn das heutige erneute aktivieren des Webs führte nicht zum erneuten aufflammen des jcache Wahnsinns ...

cat ueberwache.sh 
while true; do
    inotifywait -m -e modify,create,delete,move --timefmt '%Y-%m-%d_%H:%M:%S' --format '%T %w %:e %f'  -r /var/www/clients/clientN/webMMM/web >>/root/ueberwachung-webMMM-neu.log

done

Also wirklich dirty Scripting, das könnte man natürlich besser gestalten.

Gestartet habe ich das script mit nohup ./ueberwache.sh&

Danach wurde das zurücksetzte Web dem "Kunden" (Kumpel) übergeben und ich konnte die Funktion schön überprüfen, weil jetzt erstmal alle Addons/Plugins upgedatet bzw deinstalliert wurden.

Ausschnitt:

2019-01-09_20:17:54 /var/www/clients/clientN/webMMM/web/administrator/components/com_jem/views/ DELETE:ISDIR 
2019-01-09_20:17:54 /var/www/clients/clientN/webMMM/web/administrator/components/com_jem/views/imagehandler/ DELETE:ISDIR tmpl
2019-01-09_20:17:54 /var/www/clients/clientN/webMMM/web/administrator/components/com_jem/views/ DELETE:ISDIR imagehandler

Nun ist der erste Tag vorbei und kein erneuter Angriff.

das inotifywait tut aber nicht weh, ich lasse es jetzt einfach mal laufen, wenn dann wieder das, oder was anderes unterwegs ist hilft die Dokumentation und das Log hoffentlich.

Es ist kein Geheimnis, das Bloggen ist nicht mehr in.

Wenn ich mir in meinen Zugriffstatistiken immer den jeweiligen Dezember ansehe....

So langsam sollte ich mir wieder einen einfachen Webspace mieten und den Rootserver kündigen

Ich nutze mein Blog ja selber nicht mehr so häufig wie früher, das mag am eigenen geringeren Interesse liegen und vielleicht auch daran, dass man weniger im Zusammenhang mit Linux an aufschreibenswerten Dingen erlebt...

Läuft halt.