Kategorie: IT & Web

externe IP-Adresse bei Wechsel mailen

---

Was tut er?

Sendet bei Änderung die neue externe IP-Adresse per E-Mail.

Wie tut er es?

Ein Bash-Skript läuft alle 15 Minuten per Cronjob in einem Alpine-LXC-Container.
Es prüft die externe IP über ifconfig.me, speichert sie in eine .txt Datei und vergleicht sie mit der letzten.
Bei Änderung erfolgt der Versand per sendmail / ssmtp.

ssmtp

per „apk add ssmtp“ installieren
config file anpassen unter „/etc/ssmtp/ssmtp.conf“

root=asdf@asdf.ch
mailhub=mail.provider.com:465
AuthUser=asdf@asdf.ch
AuthPass=asdf
UseTLS=YES
FromLineOverride=YES

• root: E-Mail-Adresse, an die System-Mails (z.B. von root) weitergeleitet werden
• mailhub: SMTP-Server-Adresse mit Port (465 = SMTPS, verschlüsselt)
• AuthUser: Benutzername für die SMTP-Authentifizierung
• AuthPass: Passwort für die SMTP-Authentifizierung
• UseTLS: Aktiviert TLS/SSL-Verschlüsselung
• FromLineOverride: Erlaubt das Überschreiben der Absenderadresse beim Senden

Script

#!/bin/bash

# Pfad zur Datei, in der die letzte IP-Adresse gespeichert wird
IP_FILE="/home/ipchange/last_ip.txt"
# E-Mail-Empfänger
EMAIL_RECIPIENT="asdf@asdf.ch"
# Absender-E-Mail
EMAIL_SENDER="asdf@asdf.ch"

# Aktuelle externe IP-Adresse abfragen
CURRENT_IP=$(curl -s ifconfig.me)

# Prüfen, ob die Datei mit der letzten IP existiert
if [ -f "$IP_FILE" ]; then
    LAST_IP=$(cat "$IP_FILE")
else
    LAST_IP=""
fi

# Vergleich der IP-Adressen
if [ "$CURRENT_IP" != "$LAST_IP" ]; then
    echo "IP-Adresse hat sich geändert:"
    echo "Alte IP: $LAST_IP"
    echo "Neue IP: $CURRENT_IP"

    # E-Mail-Inhalt erstellen (mit Headern)
    (
        echo "To: $EMAIL_RECIPIENT"
        echo "From: $EMAIL_SENDER"
        echo "Subject: Externe IP-Adresse hat sich geändert"
        echo ""
        echo "Die externe IP-Adresse hat sich geändert."
        echo ""
        echo "Alte IP: $LAST_IP"
        echo "Neue IP: $CURRENT_IP"
    ) | sendmail "$EMAIL_RECIPIENT"

    # Neue IP-Adresse speichern
    echo "$CURRENT_IP" > "$IP_FILE"
else
    echo "IP-Adresse unverändert: $CURRENT_IP"
fi

Script ausführbar machen (chmod +x)

Script in cronjob legen

crontab -e

*/5 * * * * /pfad/tollesscript.sh

(für alle 5min)

0 * * * * /pfad/tollesscript.sh

(jede stunde)

Ich nutze InfluxDB 2.7 zusammen mit OpenHAB, beide laufen in separaten Docker-Containern. OpenHAB schreibt fleissig Messwerte, aber manchmal möchte man nachträglich historische Daten hinzufügen, korrigieren oder löschen. In der „neuen tollen GUI“ von 2.7 gibt es jedoch keine direkte Möglichkeit, Messwerte zu löschen oder zu bearbeiten.

Ein Downgrade auf InfluxDB1.* und Chronograf habe ich zwar versucht (dort hat das damals nämlich „einfach so“ funktioniert) aber klappte schlussendlich nicht wegen den Daten die ich nicht migrieren konnte sowie der Chronograf der einfach nicht starten wollte.

Einen halben Tag damit versauert und entnervt aufgegeben mit dem Gedanken, den Scheiss nie mehr anzufassen.

New Day, New Trys…

Aber, am nächsten Tag: nächster Versuch gestartet. Diesmal Daten per CSV eintragen (das hab ich nämlich damals mit 1.8 und Chronograf einfach so gemacht). Jetzt mit einer neueren Version von Influx sollte das ja noch viel einfacher sein! Doch egal was ich tat – immer Fehlermeldungen. Immer mit dem Hinweis, man solle doch den Raw-Import versuchen. „Ja wiedenn?!?“ Kein Button, keine Infos, nichts was dir hilft. Ich dachte, die müssen die CLI meinen, also hab ich mich darauf ausgerichtet.
Kurz gesagt: der Scheiss hat auch nicht funktioniert, immer Probleme mit dem Zeitstempel: Weder Epoch noch ISO noch RFC3339 wollten so wie ich. Am ehesten noch Epoch (Unix nanoseconds), aber auch da stimmten die Werte/Zeitstempel nie. Auch jede Zeile einzeln – keine Chance.

Line Protocol habe ich natürlich ebenfalls getestet, exakt nach Doku mit Headern und Metadaten – Fehlanzeige. Auch abgespeckte Varianten mit minimalen Headern funktionierten nicht. Also weiter mit CSV probiert, in der Annahme, das sei doch „einfacher“. War es nicht.

Nach einigen weiteren Stunden gab ich auf. Mein letzter Versuch war, in der GUI eine LineProtocol-Datei hochzuladen. Schlug natürlich fehl – trotz UTF-8 und LF (alle drei Varianten getestet) als Zeilenende.
Doch dann, die Wendung die alles veränderte: „Enter manually“
Ausprobiert:

<measurement> value=123 <19stelligerZeitstempel>

SIMPLE AS FUCKING THAT

Enter. Akzeptiert. Korrekt drin. Bier aufgemacht.
Rest der Daten genauso eingegeben. (Export aus LibreOffice Calc mit der Zellenformatierung *“value=“#* als CSV mit Leerzeichen-Trenner, in Notepad++ geöffnet, alles kopiert, im GUI eingefügt, Enter → alle Einträge drin.)

Natürlich…

habe ich hier nicht alles dokumentiert – ursprünglich wollte ich über den ganzen Frust noch ausführlicher ranten, inklusive meiner Abstecher in Python-Skripte, die einem den Import erleichtern würden, die API mit der das auch geht, und warum ich das alles dann doch nicht nutzte. Früher™ in InfluxDB 1.* war das in meiner Erinnerung einfacher.

Ich frage mich schon, warum die Entwickler von Influx sich nicht ein Beispiel an eben diesen Scripten nehmen und das direkt in ihr Produkt einbauen… Dann wäre doch allen geholfen?

Aber: Ich habe meinen Weg gefunden – und das wollte ich hier festhalten, vielleicht hilft es ja irgendwem der einfach nicht weiterkommt.

---

TL;DR

Um einige historische Daten in influxDB2.7 zu bekommen würde ich die GUI -> Load Data -> Lineprotocol -> Enter Manually verwenden.

<measurement> value=123 <19stelligerZeitstempel>
<measurement> value=124 <19stelligerZeitstempel>
<measurement> value=125 <19stelligerZeitstempel>
<measurement> value=126 <19stelligerZeitstempel>

---

CLI Befehle

Docker

Datei in Docker-Container schieben:

docker cp <lokale Datei> <containername>:/pfad/im/container/

Datei aus Container auf Host

docker cp <container>:/pfad/zur/datei ./  

Docker Container interaktiv (Shell) ausführen (auch wenn euch die KI sagt, man solle hintendran anstatt /bin/bash -> influx schreiben, funktioniert nur in influx1.* richtig)

docker exec -it <containername> /bin/bash

Login in die InfluxDB GUI

Falls Benutzer/Passwort unbekannt sind: in der docker-compose.yml oder den ENV-Variablen nachschauen.
In der GUI anmelden → oben links auf den Namen klicken → About.

• Org: manchmal funktioniert die ID, bei mir brauchte ich den Klartext-Namen.
• Token: unter Load Data → API Tokens abrufbar. Bei Bedarf neuen Token anlegen und später wieder löschen.

alte InfluxDB v1 shell

influx v1 shell \
--host http://localhost:8086 \
--org <name der organisation> \
--token <api token>

Influx Bucket-Namen

influx bucket list --org <name der organisation> --token <api token>

CSV importieren

influx write \
  --org <name der organisation> \
  --token <api token> \
  --bucket <bucket name> \
  --file xyz.csv \
  --format csv

  --log-level debug

Anhängen falls gewünscht, dann nur Logoutput, hat mir aber nichts gebracht da unzureichende „Fehlerbeschreibung“.

Komplettes measurement löschen

influx delete \
--bucket <bucket name> \
--org <name der organisation> \
--token <api token> \
--start 1970-01-01T00:00:00Z \
--stop 2100-01-01T00:00:00Z \
--predicate '_measurement="<name des measurements>"'

Für was ich die v1 Shell brauchte

dort drin konnte ich schnell überprüfen ob die Werte reingeschrieben wurden. Zuerst mit „use <db>“ die Datenbank/Bucket auswählen, dann mit „SELECT * FROM _measurement“ anzeigen lassen (aktualisiert sich nicht von selbst, mit q raus und Pfeil nach oben, Enter = neue Daten), oder mit drop eben das ganze measurement löschen.

Das Problem

Vor rund drei Monaten habe ich einem Kunden den Lenovo M70t Gen 5 verkauft und das System eingerichtet. Alles lief zunächst problemlos.

Doch seit etwa fünf Tagen gab es massive Startprobleme: Noch bevor das Lenovo-Logo erscheint, vergehen bis zu 40 Sekunden. Danach dauert es gefühlt ewig, bis der PC überhaupt einsatzbereit ist. Der Windows-Start selbst geht zwar schnell (5–10 Sekunden), aber das BIOS/UEFI scheint teilweise komplett zu hängen.

Bootversuche über USB-Stick halfen nicht – das Problem liegt klar vor dem OS. Teilweise wurde keine Hardware erkannt, der Start brach mit „No OS found“ ab. Warum er trotz deaktiviertem Network-Stack im Netzwerk nach einem OS sucht ist ein weiteres Mysterium.

Ein Firmware-Update wurde versucht, schlug aber fehl, da die Datei nach dem Neustart nicht mehr gefunden wurde. Kein Wunder wenn das Teil nicht das macht, was es will. Zurücksetzen der UEFI-Einstellungen brachte keine Verbesserung. Auch andere Anpassungen blieben wirkungslos.

Ich bin enttäuscht – von einem Business-PC hätte ich mehr erwartet.

Problemlösung

Ich habe dann noch eine Funktion im UEFI gefunden: „Zurückstellen auf Werkseinstellung“ – nicht zu verwechseln mit „Defaults laden“, das war ein eigener Unterpunkt. Klang erstmal klug. Beim Auslösen kam eine Warnung: TPM und das „Absolute Persistence® Module“ werden nicht zurückgesetzt. Dachte mir, passt schon – TPM sollte eh erhalten bleiben, und von APM hatte ich bisher nie gehört, und wenns ja eh nicht verändert wird dann isses ja Wurscht.

Also weiter. Der PC startete neu, und sofort merkte ich: Es geht schneller. Aber nicht etwa zum Lenovo-Logo – nein, er piepste zweimal und machte gleich nochmal einen Neustart. Das Ganze liess ich viermal zu und dachte: „dat mus so“.

Aber dann kam die Ernüchterung: Ich hatte den PC erfolgreich kaputt-repariert.

Die Seriennummer und der Machine-Type fehlten „plötzlich“ im BIOS. Und offenbar kann der PC ohne diese Infos nicht mehr starten.

Wie wäre es Lenovo: DIESER FUCKING HINWEIS könnte man doch auch noch in die vorigen Warnung schreiben können?! Herrgottnochmal.

Natürlich kann man die Seriennummer nicht einfach eingeben, nein… PC Schrott? Garantieeinsendung? Ich brach den Kundenbesuch ab, gönnte mir ein Bierli und nahm die Kiste mit zurück in die Werkstatt. Dort stand sie nun. Und ich verbrachte die Nacht damit, über mögliche Lösungswege nachzudenken.

Problemlösung, die zweite

Wie ich herausfand, muss man einen bootbaren Datenträger erstellen, darauf das Flash-Utility (für BIOS-Updates z. B.) bereithalten, und kann dann im richtigen Moment die passenden Befehle eingeben, um Seriennummer und Machine-Type zu aktualisieren. Hier ein Link zur Lenovo-Seite, die das beschreibt:
Link

Da ich sowieso ein Firmwareupdate machen wollte, nutzte ich gleich diese Gelegenheit. Firmware geladen, USB-Stick erstellt, TPM im BIOS deaktiviert (sonst läufts nicht), vom Stick gebootet und das Update gestartet.

Zu meiner Erleichterung fragt das Tool direkt, ob man Seriennummer und Machine-Type anpassen will – hab ich natürlich gemacht. Die Seriennummer fand ich auf der Lieferantenrechnung (9-stellig, fast die gleiche die physisch auf dme Gerät aufgeklebt ist, aber mit „S“ davor). Als Machine-Type trug ich „ThinkCentre M70t Gen 5“ ein.

Update lief durch, PC startete wieder normal. Danach ins BIOS, TPM wieder aktiviert, Bootreihenfolge und Einstellungen angepasst – und:

Juhuu, PC läuft.

Etliche Tests weiter, Stresstest CPU, RAM und GPU sowie HDD I/O und einige male Standby und wieder zurück, das Teil läuft immer noch wie es sollte. Bin gespannt ob sich das Problem nun erledigt hat, oder ob ich in ein paar Monaten wieder wegen so einem Mist ausrücken muss.

TL;DR

Lenovo M70t Gen 5, nach 3 Monaten plötzlich massive UEFI-Probleme. Boot dauerte ewig, teilweise kein OS erkannt. Firmware-Update schlug fehl, UEFI-Reset machte alles schlimmer – Seriennummer und Machine-Type gelöscht, PC startete gar nicht mehr. Lösung: BIOS-Tool auf Stick, Infos manuell nachgetragen, Firmware erfolgreich geflasht. Jetzt läuft er wieder.

Lenovo, get your shit together.

Auszug der Problemlösung wegen SN/MachineType der Lenovo Seite, falls die das mal löschen oder der Link nicht mehr aktuell ist:

The system machine type and model (MTM), serial number, or system brand ID in the BIOS menu can be corrected through a command line program in the system BIOS flash utility. Refer to the instructions below.

From the Lenovo support site, search for the applicable system BIOS Package for the system, and download the USB Drive/DOS flash program (.zip file).

If using the USB Flash Package with the amidedos.exe tool:
        Create the DOS bootable memory key and unzip the contents of the USB BIOS Flash package to the key.
        Power on the system and make sure the device with the flash program is selected as a boot device.
        Use the below commands to flash the machine type and model, serial number, or system brand ID in BIOS:
        To flash machine type and model: amidedos.exe /sp “String”
        To flash serial number: amidedos.exe /ss “String”
        To flash system brand ID: amidedos.exe /sv “String”
    “String” is the target MTM, SN and System Brand ID.
    The following command line shows how to update the machine type and model number to 1234567:
        amidedos.exe /sp “1234567” Note: The MTM is typically ten characters in length.
    To update the System Brand ID for ThinkCentre M900, for example:
        amidedos.exe /sv "ThinkCentre M900"
    Reboot the system after the update is complete.



If using the USB Flash Package with the amideefix64.efi tool:
        Format a USB key FAT32 and unzip the contents of the USB BIOS Flash package to the key.
        Boot to the key and press Esc immediately when the message Press ESC in 5 seconds to skip startup.nsh or any other key to continue appears onscreen.
        Once the Shell> prompt appears, run the commands below to flash the machine type and model, serial number, or system brand ID in BIOS.
        To flash machine type and model: amideefix64.efi /sp “String”
        To flash serial number: amideefix64.efi /ss “String”
        To flash system brand ID: amideefix64.efi /sv “String”

    “String” is the target MTM, SN and System Brand ID.
    The following command line shows how to update the machine type and model number to 1234567:
        amideefix64.efi /sp “1234567” Note: The MTM is typically ten characters in length.

    For System Brand ID for ThinkCentre M900:
        amideefix64.efi /sv "ThinkCentre M900"

    3. Reboot the system after the update is complete.