bytelude

Ein Kollege hat mir den Dienst nip.io gezeigt, der extrem praktisch ist, wenn man schnell und unkompliziert eine Domain benötigt, die auf eine spezielle IP zeigt.

Das Prinzip ist relativ einfach, denn bei nip.io ist die Ziel IP direkt ein Teil der Domain:

optionale-subdomain.192.168.1.10.nip.io

Den Teil optionale-subdomain kann man beliebig nutzen/ändern oder auch einfach weg lassen, der Rest erklärt sich glaube ich relativ leicht selbst 🙂

Mein Schwiegervater hat ein Fischer E-Bike und zumindest eine Zeit lang hatten die als Fahrradcomputer ein Tahuna Teasi One 3 extend mit dabei. Das Teil ist ein Windows CE PocketPC mit Touch Screen und da drauf läuft Tahuna, was quasi ein Open Streetmap Client mit Spezialisierung auf Fahrrad fahren ist. Der Hersteller dieses Gerätes ist vor einer Zeit insolvent gegangen und es gab noch ein letztes Update für das System, wo dann wohl auch alle Länderkarten freigeschaltet wurden (die vorher Geld gekostet haben). Und dieses Update funktionierte wohl noch bis Ende 2023 und damit zu spät für mich. Da noch ein zweites Teasi mit einer neueren Software vorhanden war, dachte ich, dass ich das System einfach rüber kopieren kann (das Gerät verhält sich wie ein USB Stick am Rechner). Dummerweise ging das zwar, allerdings wollte das Tahuna dann einen Lizenzschlüssel, der natürlich nicht vorhanden war. Und ganz blöderweise ging in diesem Moment der USB Stick Modus nicht mehr, sodass das Gerät quasi festgefahren war.

Weder möglicher Support Dienstleister noch das was von der Firma übrig war konnten mir weiterhelfen bzw. waren überhaupt erreichbar. Auf den noch online verfügbaren Seiten des Herstellers war die Rede von einem Wiederherstellungsimage, welches man auf eine Micro SD Karte kopieren konnte und damit das Gerät auf Werkseinstellungen bekommen konnte. Ja, aber leider waren die Links bereits tot. Also klapperte ich diverse Blogs und Foren ab, um dann irgendwann beim Forum von mtb-news.de zu landen. Dort fand ich einen Thread und ein User namens Holger hatte genau das gleiche Teasi wie ich und sprach auch von dem Wiederherstellungs-Image. Also kontaktierte ich ihn, er meldete sich, fand noch die alte Micro-SD Karte von seiner Wiederherstellung und konnte dank einer Anleitung von mir eine Kopie der Karte als Image anfertigen. Nachdem er mir die Datei dann zugeschickt hatte, spielte ich sie auf die Karte und es funktionierte direkt auf Anhieb – sie formatierte das Teasi komplett und nach einem Neustart ging es direkt in den USB Stick Modus.

Und GLÜCKLICHERWEISE hatte ich vor meiner Herumkopiererrei eine komplette Sicherheitskopie des Systems gezogen, welche ich anschließend wieder auf das Gerät kopieren konnte – und es funktionierte.

Da ich vielleicht nicht der letzte mit diesem Problem bin, möchte ich die Datei zur Verfügung stellen und hoffe jemandem damit genauso zu helfen wie Holger es mit mir getan hat.

WICHTIG: dieses Image formatiert mehr oder weniger einfach nur den internen Speicher des Teasi One 3 Extend (ich vermute es geht auch mit den anderen Versionen, kann das aber nicht verifizieren!). Das bedeutet, nachdem diese SD Karte in das Gerät eingelegt wird beginnt SOFORT die Formatierung, alle Daten auf dem Teasi sind direkt gelöscht! Wenn das Gerät nicht eingeschaltet ist dann passiert die Formatierung erst nach dem Einschalten mit der eingelegten Karte.

ACHTUNG!!!! ACHTUNG!!!! ACHTUNG!!!!

Die Teasi Update Server sind offline, ihr könnt das original System NICHT wiederherstellen!!!!

HABT IHR ALSO KEINE KOMPLETTE SICHERHEITSKOPIE EURES “BikeNav” ORDNERS VOM TEASI, DANN LEGT KEINESFALLS!!!!! EINE MICRO-SD MIT DIESEM IMAGE IN DAS GERÄT EIN!!!!!!

Dieses Image bringt euch nur etwas, wenn ihr eine original Kopie des BikeNav Ordners habt!

Nach dieser Warnung, hier nun das Image: Teasi One 3 Extend Recovery Image

Wie in so vielen CI/CD Tools kennt auch Jenkins das Prinzip von Secrets. Dabei kann man Benutzername/Passwort, nur Passwort, SSH Keys usw. im System hinterlegen und dann innerhalb von Build Jobs darauf zugreifen. Sollte der Inhalt des Secrets irgendwo im Build Log ausgegeben werden, ist Jenkins sogar so schlau das ganze mit **** zu maskieren. An sich also ein sehr praktisches System. Kommt man nun aber wie ich an den Punkt, dass man Secrets in Jenkins hat, aber sie dummerweise nirgendwo anders gespeichert hat, dann ist das ein Problem.

Aber es gibt eine Lösung, die ich hier gefunden habe: https://stackoverflow.com/questions/34795050/how-do-i-list-all-of-my-jenkins-credentials-in-the-script-console

Man öffnet im Jenkins einfach die Script Konsole ([JENKINS_URL]/manage/script) und fügt dort folgendes Script ein, und lässt es dann ausführen:

import java.nio.charset.StandardCharsets;
def creds = com.cloudbees.plugins.credentials.CredentialsProvider.lookupCredentials(
      com.cloudbees.plugins.credentials.Credentials.class
)
for (c in creds) {
  println(c.id)
  if (c.properties.description) {
    println("   description: " + c.description)
  }
  if (c.properties.username) {
    println("   username: " + c.username)
  }
  if (c.properties.password) {
    println("   password: " + c.password)
  }
  if (c.properties.passphrase) {
    println("   passphrase: " + c.passphrase)
  }
  if (c.properties.secret) {
    println("   secret: " + c.secret)
  }
  if (c.properties.secretBytes) {
    println("    secretBytes: ")
    println("\n" + new String(c.secretBytes.getPlainData(), StandardCharsets.UTF_8))
    println("")
  }
  if (c.properties.privateKeySource) {
    println("   privateKey: " + c.getPrivateKey())
  }
  if (c.properties.apiToken) {
    println("   apiToken: " + c.apiToken)
  }
  if (c.properties.token) {
    println("   token: " + c.token)
  }
  if (c.properties.subscriptionId) {
    println("   subscriptionId: " + c.subscriptionId)
  }
  if (c.properties.clientId) {
    println("   clientId: " + c.clientId)
  }
  if (c.properties.tenant) {
    println("   tenant: " + c.tenant)
  }
  if (c.properties.clientSecret) {
    println("   clientSecret: " + c.clientSecret)
  }
  if (c.properties.plainClientSecret) {
    println("   plainClientSecret: " + c.plainClientSecret)
  }
  println("")
}

Anschließend werden in der Ausgabe alle Secrets mit ihrem hinterlegten Namen und ihren Inhalten ausgegeben.

Influxdb wird bei sehr vielen IoT Systemen verwendet, weil es die perfekte Datenbank für die Erfassung von Metriken ist. Wenn man dann im Sekundentakt Daten rein pumpt, dann füllt sich so eine Datenbank natürlich auch irgendwann. Und dafür gibt es dann den Mechanismus der Compaction, welcher in regelmäßigen (konfigurierbaren) Abständen die bisherigen Daten zusammenfasst, optimiert und ggf. auch reduziert.

In sehr vielen Fällen kommt als Server ein Raspberry Pi zum Einsatz, der in den meisten Fällen auf einem 32 Bit Betriebssystem betrieben wird. Und hier ist Influxdb (mittlerweile wird von denen auch 32Bit gar nicht mehr supported) eine mehr oder weniger tickende Zeitbombe. So auch bei mir. In den letzten Tagen ist die Last auf dem System auf durchschnittlich 20 und darüber gegangen, obwohl der Raspberry sonst nur eine Load von ca. 1-2 hatte.

Im Log konnte ich dann sehen, dass Influxdb alle 15 Sekunden versucht hat, die Daten zu compacten, aber immer wieder scheiterte – weil der RAM nicht ausreichte. “cannot allocate memory” konnte ich dann immer wieder im Log lesen, und der Spaß ging von vorne los.

Das Problem hier ist: Influxdb lädt alle Daten erstmal in den RAM, um sie dann zu compacten. Es benötigt für seine Arbeiten dann ungefähr das 2-3 fache der Datenbankgrö0e an RAM. Sobald man diese Grenze einmal überschreitet, passiert der Fehler wie bei mir und ist nicht wirklich zu lösen.

Ein User hat sich dann hingesetzt und das Problem analysiert und auch einen Fix gebastelt, der aber leider nicht gemerged wurde. Aber man kann den Fix selbst einbauen oder dankenswerterweise direkt das fertige Docker Image mit dem Patch nutzen:

https://github.com/terjesannum/docker-influxdb-arm32/pkgs/container/influxdb-arm32

docker pull ghcr.io/terjesannum/influxdb-arm32:1.8.10-1

Zusätzlich solltest du in deiner Influxdb Config folgendes einstellen:

[data]
…
index-version = “tsi1”
tsm-use-seek = true
…

Der zweite Parameter sollte nur gesetzt werden, wenn deine Influx DB auf einer SSD liegt, da im Prinzip auf in-Memory Sachen verzichtet wird und stattdessen die Platte genutzt wird. Das ist bei Low-Memory Systemen wie derm Raspberry Pi vorteilhafter. Wenn du den Raspberry Pi allerdings nur mit der SD Karte betreibst, dann schalte das keineswegs an!

Wenn du nun Influxdb startest, dann sollte die Compaction der Datenbank ohne Probleme durchlaufen.