Kommentare, die die Welt nicht braucht – LXXI

https://giphy.com/gifs/a3zqvrH40Cdhu

Pi-hole: Reset stats

Man kann die Fritzbox konfigurieren, dass sie ihre DNS-Auflösung über den Pi-hole macht. Man kann die Fritzbox aber auch so konfigurieren, dass sie den Pi-hole mittels DHCP als DNS-Server im LAN bekannt macht – Danke, Johann. Dann (und nur dann) werden Clients korrekt aufgelöst, statt dass die Fritzbox der einzige Client ist.

Das wäre so einer der Fälle, in dem man evt. die Statistik des Pi-hole zurücksetzen möchte:

cd /etc/pihole
sudo service pihole-FTL stop
sudo mv pihole-FTL.db pihole-FTL.db.old
sudo service pihole-FTL start

cd /etc/pihole

sudo service pihole-FTL stop

sudo mv pihole-FTL.db pihole-FTL.db.old

sudo service pihole-FTL start

Update: Oooder man geht in der Admin Console auf Settings › System › Flush logs 🙃

5 Alben für die Insel

Long time no hear! Heute auch nur ganz schnell meine Lieblinge von Twitter:

Shirley Bassey – Diamonds are Forever

Spy Game OST

Sei ein Faber im Wind

The Who – Live in Hyde Park

CAN Discography

Raspberry Pi Stromversorgung

Ich habe einen 3B hier, der vermehrt “Under-voltage detected” (Code 0x00050005) meldet – dabei aber (als einziges Gerät!) über einen wertigen USB-Hub direkt am Stromnetz hängt. Der Hub hat auch schon früher Raspberrys versorgt, darunter den eigentlich hungrigeren 3B+. Was also ist los?

Es kann natürlich ein Fehlalarm, bzw. ein defekter Pi sein. Vermutlich eher unwahrscheinlich 🙂 Es kann auch der Hub sein; tatsächlich sind minderwertige Netzteile oft ein Grund für (alle möglichen!) Probleme mit dem Pi. Ich hoffte allerdings auf das Kabel; ein Punkt, den man häufig vergisst. Nicht umsonst gibt es explizite “Quick Charging”-Kabel.

Also: Gegenprobe. Weitere Kabel, sowie das “originale” Netzteil (Danke, Nathan!) statt des Hub ausprobiert. Stellt sich raus:

es scheint doch am Hub zu liegen
das originale Netzteil liefert 5.1V statt den im USB-Standard spezifizierten 5V

In anderen Worten: Die Foundation bescheißt. So funktioniert natürlich kein standard USB Supply 🙄 Aber wie auch immer. Was das Ganze blogbar macht, ist ein kleines Skript, das ich hier gefunden und während der Tests genutzt habe:

#!/bin/bash

// sudo apt-get install stress:
$(stress --cpu 4 -t 310 -q) &

COUNTER=0
while [  $COUNTER -lt 300 ]; do
  /opt/vc/bin/vcgencmd measure_temp >> CpuTemp.txt
  let COUNTER=COUNTER+1
  sleep 1
done

#!/bin/bash

// sudo apt-get install stress:

$(stress --cpu 4 -t 310 -q) &

COUNTER=0

while [ $COUNTER -lt 300 ]; do

/opt/vc/bin/vcgencmd measure_temp >> CpuTemp.txt

let COUNTER=COUNTER+1

sleep 1

done

Es stresst den Pi so sehr, dass er mit einigen der Kabel nach ein paar Schleifendurchläufen hart abgestürzt ist! Mit dem originalen Netzteil hatte ich keine Probleme (wobei da das Kabel fester Bestandteil ist). Also: Das obige Skript ist ein guter Lasttest für einen Pi.

Spring Boot 2: /health Endpoint überschreiben

Im Grunde geht’s sogar um zwei Themen, die beide relativ unklar sind, wenn man sich die Einträge auf Stack Overflow ansieht:

wie pretty-printe ich den (JSON-)Output eines Spring-Endpoints
wie überschreibe ich Default-Endpoints (denn das kann eine Lösung für 1. sein)

Bspw. hier, hier, hier, hier. Es gibt dort einige Lösungsvorschläge, mehr oder weniger aufwändig, viele für Spring Boot 1.x – hier eine weitere (für Spring Boot 2), imho sehr elegante (mit viel Input von Nils!):

@Component
@WebEndpoint(id = "prettyhealth")
public class PrettyHealthEndpoint {

  private final HealthEndpoint healthEndpoint;
  private final ObjectMapper objectMapper;

  @Autowired
  public PrettyHealthEndpoint(HealthEndpoint healthEndpoint, ObjectMapper objectMapper) {
    this.healthEndpoint = healthEndpoint;
    this.objectMapper = objectMapper;
  }

  @ReadOperation(produces = "application/json")
  public String getHealthJson() throws JsonProcessingException {
    Health health = healthEndpoint.health();
    ObjectWriter writer = objectMapper.writerWithDefaultPrettyPrinter();
    return writer.writeValueAsString(health);
  }

  @ReadOperation
  public String prettyHealth() throws JsonProcessingException {
    return "<html><body><pre>" + getHealthJson() + "</pre></body></html>";
  }
}

@Component

@WebEndpoint(id = "prettyhealth")

public class PrettyHealthEndpoint {

private final HealthEndpoint healthEndpoint;

private final ObjectMapper objectMapper;

@Autowired

public PrettyHealthEndpoint(HealthEndpoint healthEndpoint, ObjectMapper objectMapper) {

this.healthEndpoint = healthEndpoint;

this.objectMapper = objectMapper;

}

@ReadOperation(produces = "application/json")

public String getHealthJson() throws JsonProcessingException {

Health health = healthEndpoint.health();

ObjectWriter writer = objectMapper.writerWithDefaultPrettyPrinter();

return writer.writeValueAsString(health);

}

@ReadOperation

public String prettyHealth() throws JsonProcessingException {

return "<html><body><pre>" + getHealthJson() + "</pre></body></html>";

}

Dann wird /health auf /internal/health (oder irgendwas) umgeleitet, und danach /prettyhealth auf /health:

# application.properties:
management.endpoints.web.exposure.include=prettyhealth
management.endpoints.web.path-mapping.health=internal/health
management.endpoints.web.path-mapping.prettyhealth=/health

# application.properties:

management.endpoints.web.exposure.include=prettyhealth

management.endpoints.web.path-mapping.health=internal/health

management.endpoints.web.path-mapping.prettyhealth=/health

et voilà.

Talking Heads

Watch this video on YouTube

Hatte ich doch gerade Schwierigkeiten, das Video wiederzufinden: Mal getwittert, nicht gebloggt, hiermit nachgeholt.

WiX: Upgrade Pitfalls

Art des Upgrades

tl;dr: MajorUpgrade ab der initialen Version!

Folgendes Szenario: Ich baue mit WiX einen MSI-Installer für meine Software. Die Software hat die Version 1.0. Nun möchte ich meine Software auf v1.1 upgraden. Was tun?

WiX bietet mehrere Möglichkeiten, namentlich “Major Upgrades”, “Minor Upgrades”, sowie “Small Updates”, die sich ungefähr so definieren:

Small Updates: Quasi ein Patch vorhandener Files, erfordert nicht (zwingend?) eine Änderung der Versionsnummer
Minor Upgrade: Aktualisiert bestehende Files ohne die vorhandene Software zu deinstallieren. Kann aber Features oder Komponenten hinzufügen. Erfordert neue (=höhere) Versionsnummer
Major Upgrade: “Deinstalliert das Produkt und installiert es neu”, erfordert neue (=höhere) Versionsummer und eine neue Product.Id (Achtung: Product.UpgradeCode “bleibt immer unverändert”)

Liest sich, als würde man meistens ein Minor Upgrade wollen. Internet sagt allerdings das Gegenteil, die Literatur^* sieht Major Upgrades als “easier to implement than any other option” an, und last but not least empfiehlt WiX selbst:

When creating an .msi-based installer, you are strongly encouraged to include logic that supports Windows Installer major upgrades.

Was dabei nie so richtig, richtig klar wird (teilweise wird implizit das Gegenteil angedeutet): Beinhaltet nicht bereits Version 1.0 MajorUpgrade (sondern bspw. erst das erste Upgrade), dann funktioniert quasi nichts:

v1.1 wird nicht als Update erkannt, sondern parallel installiert!
Conditions funktionieren deshalb ebenfalls nicht wie erwartet, es gilt der Pfad wie bei Erstinstallation
Downgrades werden nicht verhindert, weil ja beides parallel installiert wird
…
In anderen Worten: Eine Installation, deren Installer nicht MajorUpgrade enthielt, wird von Upgrade/Downgrade-Logik komplett ignoriert!

Warum das dann nicht mandatorisch ist, wird wohl Microsofts Geheimnis bleiben.

^*Nick Ramirez, “WiX 3.6: A Developer’s Guide to Windows Installer XML”, Seite 342

“Scheduling”

Per default deinstalliert ein MajorUpgrade die alte Version und installiert dann die neue. Das kann problematisch sein, denn ein Upgrade (engl. für “Verbesserung”, “Aufrüstung”!) sollte ja bspw. Konfigurationsdaten usw. behalten. Da hilft das Scheduling-Attribut:

<MajorUpgrade Schedule="afterInstallExecute" DowngradeErrorMessage="A newer version of [ProductName] is already installed."/>

1	<MajorUpgrade Schedule="afterInstallExecute" DowngradeErrorMessage="A newer version of [ProductName] is already installed."/>

sorgt dafür, dass bestehende Dateien (und in diesem Fall auch Services) erhalten bleiben. Es wird quasi definiert, wann das bestehende Produkt entfernt werden soll, und afterInstallExecute sagt “nach der Installation des Upgrades” – natürlich wird dann nur noch entfernt, was in v1.1 nicht mehr benötigt wird.

Achtung: Das setzt offenbar die Erkennung außer Kraft, die eine Neuinstallation derselben Version verhindert 🙄

Conditions

Bestimmte Schritte des Installers sollen nur bei Erstinstallation ausgeführt werden (etwa die Konfiguration durch den User, die Installation eines Services, …). Dafür gibt es Conditions, bzw. verschiedene States, auf die man prüfen kann – und das ist ziemlich unübersichtlich. Ich beschränke mich an dieser Stelle auf einen Stackoverflow-Post, der gute, sprechende Aliase definiert:

<SetProperty After="FindRelatedProducts" Id="FirstInstall" Value="true">
  NOT Installed AND NOT WIX_UPGRADE_DETECTED AND NOT WIX_DOWNGRADE_DETECTED
</SetProperty>
<SetProperty After="SetFirstInstall" Id="Upgrading" Value="true">
  WIX_UPGRADE_DETECTED AND NOT (REMOVE="ALL")
</SetProperty>
<SetProperty After="RemoveExistingProducts" Id="RemovingForUpgrade" Sequence="execute" Value="true">
  (REMOVE="ALL") AND UPGRADINGPRODUCTCODE
</SetProperty>
<SetProperty After="SetUpgrading" Id="Uninstalling" Value="true">
  Installed AND (REMOVE="ALL") AND NOT (WIX_UPGRADE_DETECTED OR UPGRADINGPRODUCTCODE)
</SetProperty>
<SetProperty After="SetUninstalling" Id="Maintenance" Value="true">
  Installed AND NOT Upgrading AND NOT Uninstalling AND NOT UPGRADINGPRODUCTCODE
</SetProperty>

NOT Installed AND NOT WIX_UPGRADE_DETECTED AND NOT WIX_DOWNGRADE_DETECTED

</SetProperty>

WIX_UPGRADE_DETECTED AND NOT (REMOVE="ALL")

</SetProperty>

(REMOVE="ALL") AND UPGRADINGPRODUCTCODE

</SetProperty>

Installed AND (REMOVE="ALL") AND NOT (WIX_UPGRADE_DETECTED OR UPGRADINGPRODUCTCODE)

</SetProperty>

Installed AND NOT Upgrading AND NOT Uninstalling AND NOT UPGRADINGPRODUCTCODE

</SetProperty>

Update

Ein Kind von Component sollte immer KeyPath="yes" gesetzt bekommen. Selbst, wenn es nur ein Kind gibt, aber insbesondere bei mehreren. Daran wird entscheiden, welches die maßgebliche Datei ist, die vorhanden (und aktuell) sein muss, um “muss (re-)installiert werden” zu entscheiden.