Kein bock mehr auf parted? Mit growpart kann man das auch automatischer erledigen:

growpart /dev/nvme0n1 1
resize2fs /dev/nvme0n1p1

Man muss nicht immer die live cd raussuchen und chroot in ein system machen um ein password zu ändern. Wenn es sich bei der Maschine um eine Virtual Machine handelt, kann man dieses auch auf dem Hypervisor schneller machen.

virt-customize -v -a <your-qcow2-image> --root-password password:<your-password-here>

/usr/bin/perl: error while loading shared libraries: libcrypt.so.1: cannot open shared object file: No such file or directory
dpkg: error processing package libc6:amd64 (--configure):
 installed libc6:amd64 package post-installation script subprocess returned error exit status 127
Errors were encountered while processing:
 libc6:amd64
perl: error while loading shared libraries: libcrypt.so.1: cannot open shared object file: No such file or directory
E: Sub-process /usr/bin/dpkg returned an error code (1)

Das passiert leider, weil in Debian 12 wurde aus einem Paket, zwei und libcrypt wird nicht automatisch installiert. Reparieren kann man das folgendermaßen:

curl http://ftp.us.debian.org/debian/pool/main/libx/libxcrypt/libcrypt1_4.4.33-2_amd64.deb -O
dpkg-deb -x libcrypt1_4.4.33-2_amd64.deb .
cp -av lib/x86_64-linux-gnu/* /lib/x86_64-linux-gnu/
apt -y --fix-broken install
apt upgrade -y

Aber erst libcrypt installieren, wenn man den Fehler erhalten hat nach einem apt upgrade , ansonsten kann man neu installieren.

Falls man etwas ältere CPU verwendet kann es sein das diese nicht BLST unterstuetzen. Bei einer golang Anwendung kann dieses zu folgender Fehlermeldung führen:

Caught SIGILL in blst_cgo_init, consult <blst>/bindings/go/README.md.

Damit die Anwendung jedoch auch auf älteren CPU funktioniert muss man diese mit folgenden build parameter bauen:

CGO_CFLAGS="-O -D__BLST_PORTABLE__"
CGO_CFLAGS_ALLOW="-O -D__BLST_PORTABLE__"

Der Nachteil? Die Anwendung wird vermutlich langsamer laufen.

Ich bin schon lange nicht mehr in Probleme gelaufen bei OS updates, aber es musste natuerlich bei Ubuntu von 20.04 nach 22.04 ein kleines Problem geben.

Auf 20.04 hatte ich pipewire benutzt und waehrend des updates kam folgendes Problem auf:

libpipwire-0.3.0 : Depends libspa-0.2-modules...

Es konnte nicht mehr updaten und das Problem war das die Installation nicht abgeschlossen werden konnte und der Boot einfach ohne X passiert ist. Was fehlte, war das upstream ppa.

sudo add-apt-repository ppa:pipewire-debian/pipewire-upstream

Anschliessend konnte man mit dem Update wie gewohnt weitermachen.

Es gibt leider nicht viele Information wenn man einen Corda node auf einen neuen Server migrieren muss. Was man unbedingt braucht ist ein Backup der Datenbank, der Keys – am besten vom ganzen Corda Verzeichnis das alle kritischen Daten enthält (wie auch die Cordaaps).

Was man jedoch nicht braucht ist die nodekeystore.jks. Die wird basierend auf dem Hostnamen (vermutlich) erstellt und muss auf dem neuen System neu erstellt werden. Das passiert automatisch beim starten von Corda. Falls man die Datei nicht löscht wird der Node nicht erkannt und wird von der Map immer wieder gelöscht.

network.PersistentNetworkMapCache. - Removing node with info: NodeInfo(addresses=[xxx.xxx.xxx.x:10002], 

Seit Grafana 7.x benutzt Grafana ein grafana-image-renderer oder man benutzt einen docker container dafuer. Ich habe mich für das Plugin entschieden, aber vielleicht wäre der Container einfacher gewesen. Auf Debian 10 braucht das Plugin doch ein paar Abhängigkeiten die nirgendswo zu finden sind.

Installation des Plugins:

grafana-cli plugins install grafana-image-renderer

Installation Abhaengigkeiten:

apt install cups fonts-liberation gconf-service libasound2 libatk1.0-0 libatk-bridge2.0-0 libc6 libcairo2 libcups2 libdbus-1-3 libexpat1 libfontconfig1 libgcc1 libgconf-2-4 libgdk-pixbuf2.0-0 libglib2.0-0 libgtk-3-0 libnspr4 libpango-1.0-0 libpangocairo-1.0-0 libstdc++6 libx11-6 libx11-xcb1 libxcb1 libxcomposite1 libxcursor1 libxdamage1 libxext6 libxfixes3 libxi6 libxrandr2 libxrender1 libxss1 libxtst6 ca-certificates fonts-liberation libappindicator1 libnss3 lsb-release xdg-utils wget

Wenn man Grafana mit TLS konfiguriert hat muss man entweder den host korrekt setzen, ansonsten bekommt man eine Fehlermeldung weil Grafana versucht nach localhost:3000 zu verbinden.

Error:

grafana-server[25147]: 2020/12/18 07:18:47 http: TLS handshake error from [::1]:55768: remote error: tls: unknown certificate
grafana-server[25147]: t=2020-12-18T07:18:47+0000 lvl=eror msg="Browser request failed" logger=plugins.backend pluginId=grafana-image-renderer method=GET failure=net::ERR_CERT_COMMON_NAME_INVALID url="https://localhost:3000/d-solo/iuCnU9JGz/test?orgId=1&panelId=2&render=1"
grafana-server[25147]: t=2020-12-18T07:18:47+0000 lvl=eror msg="Render request failed" logger=plugins.backend pluginId=grafana-image-renderer url="https://localhost:3000/d-solo/iuCnU9JGz/test?orgId=1&panelId=2&render=1" error="Error: net::ERR_CERT_COMMON_NAME_INVALID at https://localhost:3000/d-solo/iuCnU9JGz/test?orgId=1&panelId=2&render=1"grafana-server[25147]: t=2020-12-18T07:18:47+0000 lvl=eror msg="Failed to render and upload alert panel image." logger=alerting.notifier ruleId=2574 error="Rendering failed: Error: net::ERR_CERT_COMMON_NAME_INVALID at https://localhost:3000/d-solo/iuCnU9JGz/test?orgId=1&panelId=2&render=1"

Konfiguration in /etc/grafana/grafana.ini

[plugin.grafana-image-renderer]
rendering_ignore_https_errors = true

Confluence benutzt normalerweise H2DB, eine file based Datenbank. Sollte man nicht in Produktion benutzen, aber so ist das manchmal im Leben. Wenn dann auch noch der Server oder ein filesystem problem auftaucht kann es zu einer korrupten Datenbank kommen. Confluence selber bietet keine tools an um die Datenbank zu reparieren, aber ein findiger Benutzer hat ein gutes tool geschrieben um dieses durchzuführen.

Der Fehler von Confluence:

Cannot connect to h2db
java.lang.RuntimeException: Cannot connect to h2db

Undo MVStore log:

sudo apt install maven
git clone https://github.com/bert2002/h2-recover.git
cd h2-recover
mvn clean package
java -jar target/h2-recover-1.0-SNAPSHOT.jar /path/to/h2.mv.db

Der Standardpfad bei Confluence der Datenbank is in /var/atlassian/application-data/confluence/database/. Vorher nicht vergessen ein Backup zu erstellen.

#!/bin/bash
# script: run gtk application as another user 
# author: bert2002
# notes:

OTHERUSER=peter

if [ -z "$1" ];then
	echo "$0 <application>"
	exit
fi

COOKIE=$(xauth list | grep $(uname -n) | awk '{print $3}')
sudo su - $OTHERUSER -s /bin/bash -c "unset XAUTHORITY ; touch ~/.Xauthority ; DISPLAY=:0; export DISPLAY ; xauth add :0 . $COOKIE ; $1"