Fryboyter

BIOS eines Thinkpads aktualisieren

Ich habe hier ein Thinkpad vor mir liegen bei dem aufgrund einer Sicherheitslücke ein Update des BIOS / UEFI nötig ist. Lenovo bietet zwar eine entsprechende Iso-Datei zum Download an aber diese lässt sich unter Linux nicht einfach so auf einen USB-Stick kopieren. Die Lösung ist allerdings recht einfach.

Als erstes besorgt man sich bei Lenovo die Iso-Datei der Boot-CD für sein Thinkpad. Nehmen wir beispielsweise die, die man hier herunterladen kann.

Als nächstes installiert man sich das Script geteltorito.pl. Bei Arch findet man es im AUR. Alternativ findet man es hier.

Mit diesem extrahiert man mit folgendem Befehl das El-Torito-Boot-Image aus der Iso-Datei.

geteltorito.pl -o bios.img g2uj33us.iso

Die Bezeichnung der Iso-Datei muss man ggf. anpassen.

Abschließend schreibt man mit folgendem Befehl die Img-Datei auf den USB-Stick.

dd bs=64K if=/pfad/zu/bios.img of=/dev/sdX status=progress oflag=sync

Den Teil mit if= und of= muss man an die eigenen Gegebenheiten anpassen. Alternativ kann man auch Tools wie Etcher nutzen.

Nun sollte man von dem USB-Stick booten und das BIOS / UEFI aktualisieren können.

OSBN | Linux

IP-Nummer in der Isso-Datenbank nach 7 Tagen anonymisieren

Martin von blog.mdosch.de hat vor einiger Zeit einen Artikel veröffentlicht in dem er gezeigt hat, wie man die in der Datenbank von Isso gespeicherten IP-Nummern der Kommentare anonymisiert indem man diese einmal wöchentlich mit 127.0.0.1 überschreibt.

Den Befehl (Update comments set remote_addr = “127.0.0.1”;) habe ich damals für meine Isso-Instanz übernommen. Am Wochenende hatte ich mir mal wieder meine diversen Konfigurationen und Dokumentationen angesehen und bin auch auf besagten Befehl gestoßen. Hierbei habe ich mir überlegt, was ist wenn jemand die IP-Nummer jedes einzelnen Eintrags für beispielsweise 7 Tage aufbewahren will oder muss? Denn das klappt mit dem Befehl nicht wirklich.

Denn nehmen wir mal an, der Cronjob der den Befehl ausführt wird immer am Sonntag um 15 Uhr gestartet. Schreibe nun jemand um 14 Uhr einen Kommentar wird dessen IP-Nummer in der Datenbank trotzdem um 15 Uhr mit 127.0.0.1 überschrieben.

Ich habe mir daher einmal die Datenbank von Isso genauer angesehen. In der Tabelle comments gibt es die Spalte created. In dieser ist pro Kommentar ein Wert wie 1369140347.0 vorhanden. Hierbei handelt es sich um die sogenannte Unixzeit die angibt wie viele Sekunden seit dem 01. Januar 1970, 00:00 UTC vergangen sind. Die Verwendung dieser Zeitrechnung ist in Datenbanken weit verbreitet, aber für den Menschen quasi nicht lesbar und nicht im Kopf umrechenbar.

Ich habe mir daher erst einmal eine Ausgabe erstellt die mir den Timestamp, den Timestamp in einer für Menschen lesbaren Forum sowie den jeweiligen Kommentar anzeigt.

SELECT created, strftime('%d-%m-%Y %H:%M:%f', datetime(created, 'unixepoch')) as createdhr, text 
FROM comments;

Somit sehe ich bei weiteren Tests wie alt die Kommentare tatsächlich sind.

Als nächstes habe ich den Befehl so erweitert, dass nur die Kommentare angezeigt werden, die 7 Tage alt sind.

SELECT created, strftime('%d-%m-%Y %H:%M:%f', datetime(created, 'unixepoch')) as createdhr, text 
FROM comments
WHERE created > strftime("%s", "now", "-7 days");

Hiermit wird der aktuelle Zeitpunkt abzüglich 7 Tage berechnet und verglichen ob der Wert in created größer als dieser Wert ist.

Hierbei werden allerdings auch die Kommentare angezeigt bei denen die IP-Adresse in der Spalte remote_addr bereits auf 127.0.0.1 geändert wurde. Da es unnötig ist jedes mal den Wert mit dem gleichen Wert zu überschreiben, habe ich den Befehl nun noch einmal um eine Bedingung erweitert bei der nur die Einträge angezeigt werden bei denen bei remote_address etwas anderes als 127.0.0.1 eingetragen ist.

SELECT created, strftime('%d-%m-%Y %H:%M:%f', datetime(created, 'unixepoch')) as createdhr, text 
FROM comments
WHERE created > strftime("%s", "now", "-7 days")
AND NOT remote_addr = '127.0.0.1';

Nachdem ich mir nach ein paar Tests ziemlich sicher bin, dass es funktioniert habe ich den Befehl so geändert, dass er mir die betreffenden Einträge nicht anzeigt sondern bei diesen die IP-Nummern mit 127.0.0.1 überschreibt.

Update comments set remote_addr = "127.0.0.1"
WHERE created > strftime("%s", "now", "-7 days")
AND NOT remote_addr = '127.0.0.1';

Nun kann man den Befehl mittels eines Cronjobs täglich ausführen. Hierbei sollte man allerdings berücksichtigen, dass die Berechnung des Alters nicht absolut genau ist, so das manche Kommentare unter Umständen erst nach 7,x der 8 Tagen berücksichtigt werden. Hier dürfte es helfen den Cronjob so zu konfigurieren, dass er mehrmals pro Tag ausgeführt wird. Wer in seiner Datenbank noch Einträge mit einer richtigen IP-Nummer hat die älter als 7 Tage sind, sollte den Befehl einmalig manuell ausführen und anstelle von “-7 days” einen entsprechend höheren Wert eintragen so dass alle Kommentare berücksichtigt werden.

Wer sich genauer informieren will, was zum Beispiel strftime oder datetime genau macht, kann dies zum Beispiel unter https://www.sqlite.org/lang_datefunc.html tun.

OSBN | General

Maskieren von Text in Snippets bei VSCode

Urlaubszeit ist bei mir Bastelzeit. Daher bin ich gerade dabei mal wieder VSCode zu testen, obwohl ich mir vorab schon sicher bin, dass ich bei Sublime Text bleiben werde. Naja egal, darum geht es gerade nicht.

Damit ich relativ bequem Artikel veröffentlichen kann, habe ich mir unter Sublime Text diverse Snippets angelegt. Bei einem geht es darum, dass ich Text markiere und per Shortcut der HTML-Code hinzugefügt wird mit dem ich Text als Code hervorhebe. Somit wird zum Beispiel aus “10 PRINT “hallo welt” folgendes.

<pre class="line-numbers language-bash" style="white-space:pre-wrap;">
<code class="language-bash">10 PRINT "hallo welt"</code>
</pre>

Unter VSCode habe ich mir folgendes Snippet angelegt.

"wrap_highlight": {
		"prefix": "wrap_highlight",
		"body": [
			"<pre class="line-numbers language-bash" style="white-space:pre-wrap;">",
			"<code class="language-bash">$TM_SELECTED_TEXT</code>",
			"</pre>"
		],
		"description": "Highlight Code"
	},

Sieht eigentlich ganz gut aus, macht aber nicht was es soll. Denn als Ausgabe erhält man folgendes.

<pre class=
 style=
<code class=
>10 PRINT "hallo welt"</code>
</pre>

Die Lösung ist in dem Fall allerdings recht einfach. Die Ursache ist die fehlende Maskierung (auch escapen genannt) der Anführungszeichen innerhalb des Bereichs “body”.

"wrap_highlight": {
		"prefix": "wrap_highlight",
		"body": [
			"<pre class=\"line-numbers language-bash\" style=\"white-space:pre-wrap;\">",
			"<code class=\"language-bash\">$TM_SELECTED_TEXT</code>",
			"</pre>"
		],
		"description": "Highlight Code"
	},

Ändert man das Snippet wie oben angegeben macht es auch das was es soll.

OSBN | General

LAN Share - Spontan Dateien im LAN versenden

Vor ein paar Tagen habe ich mir auf mein Notebook etwas heruntergeladen, dass ich schlussendlich auf einem anderen Rechner benötigt habe. Um nicht wieder den Turnschuhadmin spielen zu müssen, habe ich mich gefragt welche Möglichkeiten es gibt Dateien möglichst ohne größeren Aufwand von Rechner X auf Rechner Y zu kopieren.

Der Bequemlichkeit halber bin ich bei LAN Share gelandet. Das Tool hat nur die Aufgabe Dateien bzw. ganze Verzeichnisse von einem Rechner zum anderen im LAN zu transferieren. Ideal wenn man nur alle paar Monate mal etwas spontan kopieren will.

LAN Share

Die grafische Oberfläche ist im Grunde idiotensicher. Man klickt links oben auf “Send” und wählt dann aus ob man Dateien oder Verzeichnisse versenden will. Dann wählt man die gewünschte Datei oder Verzeichnis aus und anschließend den Rechner der die Datei empfangen soll. Dort sollte logischerweise LAN Share auch gestartet sein. Abschließend klickt man auf “Send” und das war es schon.

OSBN | General

Borg-Repository auf rsync.net komplett prüfen

Für meine “Offside-Backups” benutze ich Borg und rsync.net. Heute wollte ich meine bei rsync.net gespeicherten Datensicherungen einmal komplett überprüfen.

borg check -v --verify-data XXXXX@ch-s010.rsync.net:MeinRepository

Leider bricht der Befehl schlussendlich immer mit der Fehlermeldung “Borg server is too old for scan. Required version 1.1.0b3” ab. Scheinbar verwendet rsync.net von Haus aus eine ältere Version von Borg. Auf der Internetseite kann man aber nachlesen, dass Version 0.29 und 1.x unterstützt werden. Also sollte es doch möglich sein, die aktuelle Version 1.x zu nutzen. Wie so oft hilft RTFM weiter. Es gibt die Variable BORG_REMOTE_PATH. Mit dieser kann man angeben welche Version von Borg auf dem Server verwendet werden soll. Im Fall von rsync.net muss man den bereits genannten Befehl wie folgt ändern, damit man Version 1.x von Borg verwendet.

borg check -v --verify-data --remote-path=/usr/local/bin/borg1/borg1  XXXXX@ch-s010.rsync.net:MeinRepository

Anstelle den Parameter –remote-path= zu verwenden, kann man das ganze auch allgemeiner mit “export BORG_REMOTE_PATH=/usr/local/bin/borg1/borg1” angeben. Für Scripte dürfte das die bessere Lösung darstellen.

Vor der Nutzung von –verify-data muss ich abschließend aber noch warnen. Hierbei wird sozusagen alles auf Herz und Nieren geprüft. Und das dauert. In dem Repository das ich für den Test verwendet habe, sind nur knapp 3 GB Daten vorhanden. Bis alles getestet worden ist, sind einige Stunden vergangen. Für allgemeine Prüfungen sollte man daher andere Einstellungen wählen.

OSBN | Linux