Category: Homelab
[Docker] IT-Tools
Really cool tool collection. Check it out here.
https://github.com/CorentinTh/it-tools
version: '3.3'
services:
it-tools:
image: 'corentinth/it-tools:latest'
container_name: it-tools
restart: unless-stopped
ports:
- 8080:80
environment:
- UID=1000
- GID=1000
[Proxmox] Upgrade 7.4 to 8.0 – Failed to run lxc.hook.pre-start for container
After updating my Proxmox Server to PVE8.0, suddenly two lxc containers did not start anymore.
root@pve:~# pct start 192
run_buffer: 322 Script exited with status 2
lxc_init: 844 Failed to run lxc.hook.pre-start for container "192"
__lxc_start: 2027 Failed to initialize container "192"
startup for container '192' failed
I tried to view the error.log but couldn’t find any helpful information.
lxc-start -lDEBUG -o error.log -F -n 192
When googling, I stumbled across this reddit post. Although the issue was a bit different, I tried the recommended steps. The first command, directly led me to the right direction…
root@pve:~# pct mount 192
mounting container failed
directory '/mnt/nfs/data/folder' does not exist
For whatever reason, after restarting proxmox it did not mount the nfs shares properly on the host. And of course, after this hint, I noticed that both containers were trying to mount some of these folders, which were actually nfs shares from my NAS. A simple mount -a
on the host fixed it immediately. Besides of this little problem, everything went well with the proxmox upgrade!
[Home Assistant] Stromzähler auslesen: LOGAREX LK13BE803049
Wurde der Stromzähler in den letzten Jahren getauscht, solltet ihr eine moderne Messeinrichtung haben, welche eine Infrarot (IR) Schnittstelle für das Auslesen von Daten anbietet. Dazu gibt es bereits eine große Anzahl an Anleitungen, z. B. hier und hier. Daher nur kurz zusammengefasst, welche Schritte notwendig waren für meinen LOGAREX LK13BE803049 (Baujahr 2018).
Stromzähler vorbereiten
Um Zugriff auf alle Daten, die der Stromzähler so sammelt zu bekommen, benötigt man eine PIN. Diese PIN kann man über das Online-Portal des Messstellenbetreibers herausfinden, alternativ geht das auch via Hotline oder Mail. Hat man seine PIN, am besten in der Anleitung nachschlagen, wie die PIN eingeben (Seite 6) und wie der “vollständiger Datensatz” (Seite 8) aktiviert wird. Ansonsten bekommt man nur einen Bruchteil der vorhanden Daten zurück.
IR Lese-Schreibkopf
Kann man selber basteln für wenige Euro oder alternativ fertig kaufen. Ich habe diesen (WIFI lese-schreib-Kopf EHZ Volkszähler Hichi Smartmeter) gekauft, da hier ein ESP32 dabei ist und dieser sogar bereits mit Tasmota geflasht wurde. Um Abstürze im Betrieb zu verhindern, darauf achten, dass das Netzteil der Micro-USB Stromversorgung genug Leistung hat. Ist die Stromversorgung sichergestellt, mittels Smartphone mit dem vom ESP32 geöffneten Access Point verbinden und die WLAN Daten des Heimnetzes im Tasmota Webinterface eingeben (sollte sich automatisch öffnen nach der AP Verbindung). Nun kann das ganze Teil mithilfe des Magneten am Stromzähler über der IR Schnittstelle (Optische Datenschnittstelle D0) angebracht werden. Im Idealfall hat man dafür noch eine freie Steckdose in der Nähe des Stromzählers.
Script anlegen in Tasmota
Erneut das Tasmota Webinterface aufrufen, am besten diesmal vom Desktop PC, und über den Button Consoles zu Edit Script navigieren. Dort müssen nun einige Zeilen eingetragen werden, die sich je nach Stromzähler unterscheiden können. Eine Übersicht der möglichen Werte des LOGAREX Zählers findet ihr in der Anleitung auf Seite 10. Bei mir sah das Ergebnis dann so aus:
>D
>B
=>sensor53 r
>M 1
+1,3,o,0,9600,LOGAREX
1,1-0:1.8.0*255(@1,BEZUG,KWh,total_in,4
1,1-0:2.8.0*255(@1,EINSPEISUNG,KWh,total_out,4
1,1-0:16.7.0*255(@1,Verbrauch aktuell,W,current,16
1,1-0:1.8.0*96(@1,letzter Tag,KWh,total_day,1
1,1-0:1.8.0*97(@1,letzte Woche,KWh,total_week,1
1,1-0:1.8.0*98(@1,letzter Monat,KWh,total_month,1
1,1-0:1.8.0*99(@1,letztes Jahr,KWh,total_year,1
#
Home Assistant
Via MQTT und Tasmota Integration können die Werte direkt an Home Asisstant übertragen werden und z.B. im Energy Dashboard verwendet werden. Dafür einfach die Schritte unter 4b von dieser Anleitung umsetzten. Falls MQTT auf eurem Home Assistant noch nicht eingerichtet ist, müsst ihr das noch tun. Dafür gibt es auch einen Haufen Anleitungen oder Videos. Am besten einfach eine recht aktuelle Anleitung heraussuchen. Bei der Einrichtung legt ihr auch einen separaten User für MQTT an, welchen ihr dann angeben müsst in Tasmota. So sah es bei mir dann aus.
In der Tasmota Integration in Home Assistant wurde das Device mit entsprechen Entitäten direkt gefunden.
Da die Werte jedoch ohne Einheit übertragen werden, muss diese noch händisch in der configuration.yaml
gepflegt werden. Wenn ich mich recht erinnere, ist danach ein Neustart von Home Assistent erforderlich.
# Tasmota Stromzähler
homeassistant:
customize:
sensor.tasmota_logarex_total_in:
device_class: energy
unit_of_measurement: "kWh"
state_class: total_increasing
sensor.tasmota_logarex_total_out:
device_class: energy
unit_of_measurement: "kWh"
state_class: total_increasing
sensor.tasmota_logarex_current:
device_class: power
unit_of_measurement: "W"
sensor.tasmota_logarex_total_day:
device_class: energy
unit_of_measurement: "kWh"
state_class: total_increasing
sensor.tasmota_logarex_total_week:
device_class: energy
unit_of_measurement: "kWh"
state_class: total_increasing
sensor.tasmota_logarex_total_month:
device_class: energy
unit_of_measurement: "kWh"
state_class: total_increasing
sensor.tasmota_logarex_total_year:
device_class: energy
unit_of_measurement: "kWh"
state_class: total_increasing
So sieht die Anzeige der Sensoren direkt etwas brauchbarer aus. 🙂
Die schöne Energieverteilungsanzeige vom Energy Dashboard kann auch in jedem anderen Dashboard verwendet werden via:
type: energy-distribution
link_dashboard: true
Einen Überblick der weiteren Energy Cards findet man hier.
Im Energy Dashboard kann auch ein Preis für die kWh hinterlegt werden. So sieht man direkt seinen Verbrauch für ausgewählte Zeiträume. Hier mal ein extremes Beispiel, an dem wir den ganzen Tag Äpfel eingekocht und Kuchen gebacken haben. So ein Verbrauch ist bei uns natürlich nicht die Regel. 🙂
Für mein Smartphone Dashboard habe ich dann noch die neue Statictics Card genutzt, um einen noch einfacheren Einblick in meine laufenden Kosten zu bekommen. Die Anordnung erfolgt durch eine Grid Card.
square: false
columns: 2
type: grid
cards:
- type: statistic
entity: sensor.tasmota_logarex_total_in_cost
period:
calendar:
period: day
stat_type: change
name: Kosten heute
- type: statistic
entity: sensor.tasmota_logarex_total_in_cost
period:
calendar:
period: day
offset: -1
stat_type: change
name: Kosten gestern
[Nextcloud] Docker update 21.0.7 to 21.0.8
And again… a Nextcloud upgrade failed. After a docker-compose pull
and docker-compose up -d
the maintenance mode won’t turn off. So I tried to turn it off manually, but I still couldn’t finish the update via WebGUI. I also couldn’t find any errors via the log.
docker exec --user www-data nextcloud-app php /var/www/html/occ maintenance:mode --off
So I triggered the upgrade again from the terminal and finally got an exception.
$ docker exec --user www-data nextcloud-app_1 php /var/www/html/occ upgrade
Nextcloud or one of the apps require upgrade - only a limited number of commands are available
You may use your browser or the occ upgrade command to do the upgrade
Setting log level to debug
Turned on maintenance mode
Updating database schema
Updated database
Updating <user_ldap> ...
An unhandled exception has been thrown:
Error: Call to undefined method OC\DB\QueryBuilder\QueryBuilder::executeQuery() in /var/www/html/apps/user_ldap/lib/Migration/GroupMappingMigration.php:56
Stack trace:
#0 /var/www/html/apps/user_ldap/lib/Migration/Version1130Date20220110154717.php(54): OCA\User_LDAP\Migration\GroupMappingMigration->copyGroupMappingData('ldap_group_mapp...', 'ldap_group_mapp...')
#1 /var/www/html/lib/private/DB/MigrationService.php(528): OCA\User_LDAP\Migration\Version1130Date20220110154717->preSchemaChange(Object(OC\Migration\SimpleOutput), Object(Closure), Array)
#2 /var/www/html/lib/private/DB/MigrationService.php(426): OC\DB\MigrationService->executeStep('1130Date2022011...', false)
#3 /var/www/html/lib/private/legacy/OC_App.php(1012): OC\DB\MigrationService->migrate()
#4 /var/www/html/lib/private/Updater.php(347): OC_App::updateApp('user_ldap')
#5 /var/www/html/lib/private/Updater.php(262): OC\Updater->doAppUpgrade()
#6 /var/www/html/lib/private/Updater.php(134): OC\Updater->doUpgrade('21.0.8.3', '21.0.7.0')
#7 /var/www/html/core/Command/Upgrade.php(249): OC\Updater->upgrade()
#8 /var/www/html/3rdparty/symfony/console/Command/Command.php(255): OC\Core\Command\Upgrade->execute(Object(Symfony\Component\Console\Input\ArgvInput), Object(Symfony\Component\Console\Output\ConsoleOutput))
#9 /var/www/html/3rdparty/symfony/console/Application.php(1009): Symfony\Component\Console\Command\Command->run(Object(Symfony\Component\Console\Input\ArgvInput), Object(Symfony\Component\Console\Output\ConsoleOutput))
#10 /var/www/html/3rdparty/symfony/console/Application.php(273): Symfony\Component\Console\Application->doRunCommand(Object(OC\Core\Command\Upgrade), Object(Symfony\Component\Console\Input\ArgvInput), Object(Symfony\Component\Console\Output\ConsoleOutput))
#11 /var/www/html/3rdparty/symfony/console/Application.php(149): Symfony\Component\Console\Application->doRun(Object(Symfony\Component\Console\Input\ArgvInput), Object(Symfony\Component\Console\Output\ConsoleOutput))
#12 /var/www/html/lib/private/Console/Application.php(215): Symfony\Component\Console\Application->run(Object(Symfony\Component\Console\Input\ArgvInput), Object(Symfony\Component\Console\Output\ConsoleOutput))
#13 /var/www/html/console.php(100): OC\Console\Application->run()
#14 /var/www/html/occ(11): require_once('/var/www/html/c...')
Quick search on google and it seems that the image for 21.0.8 is broken and already withdrawn. Here and here. Great if users can still pull it from the docker repo…
I disabled the user_ldap
addon via command line. This site helped me finding the right commands. After another occ upgrade
and a few minutes, the instance finally came back online.
docker exec --user www-data nextcloud-app php /var/www/html/occ app:list
docker exec --user www-data nextcloud-app php /var/www/html/occ app:disable user_ldap
docker exec --user www-data nextcloud-app php /var/www/html/occ maintenance:mode --off
docker exec --user www-data nextcloud-app php /var/www/html/occ upgrade
In the end I also stumbled across the official nextcloud blog, where they announce 20.0.9 and that they had problems with 20.0.8…. But if the new docker image is not yet provided, and you can’t downgrade from your broken 20.0.8 back to 20.0.7, this doesn’t help you at all.
[Docker] OCI runtime create failed on Ubuntu 18.04.
Yesterday after rebooting my Server running Ubuntu 18.04. I couldn’t run most of my Docker Container. Strangely, some worked and some did not. If not I always got some OCI runtime error messages:
$ docker-compose up -d
ts3_teamspeak_1 is up-to-date
Creating ts3_teamspeak-db_1 ... error
ERROR: for ts3_teamspeak-db_1 Cannot start service teamspeak-db: OCI runtime create failed: container_linux.go:380: starting container process caused: process_linux.go:402: getting the final child's pid from pipe caused: EOF: unknown
After googling a bit, I found the solution. I did an apt upgrade before rebooting and my Docker version was updated to v5.20. And it seems that Ubuntu 18.04. and Docker v5.20 are not working well together. Therefore I had to downgrade docker to v5.18. Find more here.
apt install docker-ce=5:18.09.1~3-0~ubuntu-bionic
apt install containerd.io=1.2.2-1
[Nextcloud] Docker upgrade 20.0.10 to 21.0.3
As always the nextcloud update failed for me…
After a quick search I found this post. Seems like using mariadb:latest
is not a good idea anymore. After switching to mariadb:10.5
and manually turning the maintenance mode off I could proceed the update process.
$ docker exec --user www-data nextcloud-app php /var/www/html/occ maintenance:mode --off
Nextcloud or one of the apps require upgrade - only a limited number of commands are available
You may use your browser or the occ upgrade command to do the upgrade
Maintenance mode disabled
[Wallabag] Docker upgrade 2.3.8. to 2.4.2
Just did an upgrade for Wallabag from Version 2.3.8 to 2.4.2. So I opened my docker-compose.yml and changed the image version and ran docker-compose up -d
version: '3'
services:
wallabag:
image: wallabag/wallabag:2.4.2
container_name: wallabag-app
restart: unless-stopped
environment:
- MYSQL_ROOT_PASSWORD=${MARIADB_ROOT_PASSWORD}
- SYMFONY__ENV__DATABASE_DRIVER=pdo_mysql
- SYMFONY__ENV__DATABASE_HOST=wallabag-db
- SYMFONY__ENV__DATABASE_PORT=3306
- SYMFONY__ENV__DATABASE_NAME=wallabag
- SYMFONY__ENV__DATABASE_USER=${MARIADB_USER}
- SYMFONY__ENV__DATABASE_PASSWORD=${MARIADB_PASSWORD}
- SYMFONY__ENV__DATABASE_CHARSET=utf8mb4
- SYMFONY__ENV__MAILER_HOST=${WALLABAG_MAILER_HOST}
- SYMFONY__ENV__MAILER_USER=~
- SYMFONY__ENV__MAILER_PASSWORD=~
- SYMFONY__ENV__FROM_EMAIL=${WALLABAG_FROM_EMAIL}
- SYMFONY__ENV__DOMAIN_NAME=${WALLABAG_DOMAIN_NAME}
depends_on:
- wallabag-db
volumes:
- /opt/containers/wallabag/images:/var/www/wallabag/web/assets/images
networks:
- proxy
wallabag-db:
image: mariadb
restart: unless-stopped
container_name: wallabag-db
environment:
- MYSQL_ROOT_PASSWORD=${MARIADB_ROOT_PASSWORD}
volumes:
- /opt/containers/wallabag/data:/var/lib/mysql
networks:
- proxy
networks:
proxy:
external: true
But somehow after the upgrade my container won’t come back online. Although the log was saying “Provisioner finished”, it could not connect to the database. When opening the webpage for wallabag the docker logs said: “…unable to parse the MySQL grant string: GRANT USAGE ON entrypoint.sh TO wallabag
@%
IDENTIFIED BY PASSWORD…”
After searching on google I finally found this note on the Wallabag Github page….
“If there is a version upgrade that needs a database migration. The most easy way to do is running the migrate
command:”
docker exec -t wallabag-app /var/www/wallabag/bin/console doctrine:migrations:migrate --env=prod --no-interaction
After running the db migration everything came back online. So this post is just a reminder for myself that sometimes Wallabag needs a db migration after upgrading. 🙂
[Proxmox] Unprivileged Container: Using local directory bind mount points
https://pve.proxmox.com/wiki/Unprivileged_LXC_containers
https://www.reddit.com/r/Proxmox/comments/jz5ugx/lxc_user_mapping_help/
I had to map my lxc user nocin (uid=1000(nocin) gid=1000(nocin)) to user nocin (uid=1000(nocin) gid=1000(nocin)) on the host. So they have the same uid and gid on the host and inside the container and I had to map 1000 to 1000.
$ nano /etc/pve/lxc/114.conf
# had to append these lines
lxc.idmap: u 0 100000 1000
lxc.idmap: g 0 100000 1000
lxc.idmap: u 1000 1000 1
lxc.idmap: g 1000 1000 1
lxc.idmap: u 1001 101001 64535
lxc.idmap: g 1001 101001 64535
Also append the following line to /etc/subuid
and /etc/subgid
.
root:1000:1
Now all mount points are fully accessible and not owned by “Nobody/NoGroup” anymore.
If you are not able to access your home directory inside your container after the user mapping, you can change the permissions for it directly from the host. Find your lxc directory on your host and update the permissions to your current uid and gid.
$ cd /rpool/data/subvol-114-disk-0/home/
$ chown 1000:1000 -R nocin/
$ ls -l
drwxr-x---+ 5 nocin nocin 9 Mai 16 11:22 nocin