Raspberry Pi und Bacula…

Lange Zeit hatte ich hier für meine kleine Serverumgebung ein BareOS laufen, vor einiger Zeit dann aber auf Bacula gewechselt.

So lange der Director auf einem der Raspberry Pi lief war auch alles gut, vor ein paar Monaten folge dann aber noch ein Umzug auf Proxmox in ein LXC Container.

Für bestehende Backupjobs kein Problem, sowohl x86 als auch arm-hf Quellen sind super weiter gelaufen (Incremental forever).

Ein neuer Client unter arm-hf lief allerdings nicht, immer beim starten der Sicherung (Initial Full) ist der bacula-fd mit einem SigFault weg gecrasht. Da dieses System nicht soo wichtig war hab ich es dann dabei belassen, vor ein paar Tagen hatte ich aber noch andere Probleme und dabei sind die wichtigen Raspberri Pi Systeme auch ausgelaufen und wollten ein neues Full Backup machen.

Hier sind dann genau die selben Probleme hoch, welche stellenweise auch im Netz diskutiert wurden. Eine Lösung für die Kombination arm-hf bacula-fd und x86 bacula-dir als gemeinsame Problemursache gibt es wohl nicht. Zu seltener Use-Case, um da viel Zeit rein zu investieren…

Da fiel mir heute morgen ein, das der bareos-fd ja auch ein bacula Compability Mode hat und é voila, eingerichtet und das Backup läuft 1A 🙂

Also Tipp wenn ihr das Problem habt:
Nutzt den bareos-fd (bareos-client) zusammen mit dem Bacula Director.

Anbei noch die Fehlermeldung vom Bacula FD:

Apr 16 07:02:55 raspi-vzmon bacula-fd[4551]: Bacula interrupted by signal 11: Segmentation violation
Apr 16 07:02:55 raspi-vzmon bacula-fd[4551]: Kaboom! bacula-fd, raspi-vzmon.mgmt.2-cpu.local-fd got signal 11 - Segmentation violation at 16-Apr-2021 07:02:55. Attempting traceback.
Apr 16 07:02:55 raspi-vzmon bacula-fd[4551]: Kaboom! exepath=/usr/sbin/
Apr 16 07:02:55 raspi-vzmon bacula-fd: Bacula interrupted by signal 11: Segmentation violation
Apr 16 07:02:55 raspi-vzmon bacula-fd[4551]: Calling: /usr/sbin/btraceback /usr/sbin/bacula-fd 4551 /var/lib/bacula
Apr 16 07:03:00 raspi-vzmon bacula-fd[4551]: bsmtp: bsmtp.c:488-0 Failed to connect to mailhost localhost
Apr 16 07:03:00 raspi-vzmon bacula-fd[4551]: The btraceback call returned 1
Apr 16 07:03:00 raspi-vzmon bacula-fd[4551]: LockDump: /var/lib/bacula/bacula.4551.traceback
Apr 16 07:03:00 raspi-vzmon bacula-fd[4551]: raspi-vzmon.mgmt.2-cpu.local-fd: lockmgr.c:1221-0 lockmgr disabled
Apr 16 07:03:00 raspi-vzmon bacula-fd[4551]: raspi-vzmon.mgmt.2-cpu.local-fd: smartall.c:400-2863311530 Orphaned buffer: raspi-vzmon.mgmt.2-cpu.local-fd 536 bytes at bd4690 from bsockcore.c:157
Apr 16 07:03:00 raspi-vzmon bacula-fd[4551]: raspi-vzmon.mgmt.2-cpu.local-fd: smartall.c:400-2863311530 Orphaned buffer: raspi-vzmon.mgmt.2-cpu.local-fd 280 bytes at bd0f58 from jcr.c:384
Apr 16 07:03:00 raspi-vzmon bacula-fd[4551]: raspi-vzmon.mgmt.2-cpu.local-fd: smartall.c:400-2863311530 Orphaned buffer: raspi-vzmon.mgmt.2-cpu.local-fd 280 bytes at bd1950 from jcr.c:388
Apr 16 07:03:00 raspi-vzmon bacula-fd[4551]: raspi-vzmon.mgmt.2-cpu.local-fd: smartall.c:400-2863311530 Orphaned buffer: raspi-vzmon.mgmt.2-cpu.local-fd 312 bytes at bd3400 from bsock.c:852
Apr 16 07:03:00 raspi-vzmon bacula-fd[4551]: raspi-vzmon.mgmt.2-cpu.local-fd: smartall.c:400-2863311530 Orphaned buffer: raspi-vzmon.mgmt.2-cpu.local-fd 4120 bytes at bd4ac0 from bsockcore.c:156
Apr 16 07:03:00 raspi-vzmon systemd[1]: bacula-fd.service: Main process exited, code=killed, status=11/SEGV
Apr 16 07:03:00 raspi-vzmon systemd[1]: bacula-fd.service: Failed with result 'signal'.
Apr 16 07:04:00 raspi-vzmon systemd[1]: bacula-fd.service: Service RestartSec=1min expired, scheduling restart.
Apr 16 07:04:00 raspi-vzmon systemd[1]: bacula-fd.service: Scheduled restart job, restart counter is at 3.
Apr 16 07:04:00 raspi-vzmon systemd[1]: Stopped Bacula File Daemon service.

Encrypted ZFS Dataset – Unlock @boot

Ich habe bei mir gerade unter Ubuntu 19.10 auf die native ZFS Verschlüsselung umgestellt und dabei nur mein Data-Pool mittels Passphrase verschlüsselt, nicht jedoch den System Pool.

Beim System Pool sollte wohl direkt beim Booten eine Passphrase-Abfrage zu kommen, bei meinem Data allerdings nicht. Nach dem Boot sind die Datasets zwar da, aber nicht lesbar weil noch nicht entsperrt.

Nach einigem Basteln hat sich diese systemd service file bei mir als funktional erwiesen:

cat /etc/systemd/system/zfs-load-key.service

[Unit]
Description=Import key for ZFS pool
Documentation=man:zfs(8)
DefaultDependencies=no
After=systemd-udev-settle.service
After=zfs-import.target
After=systemd-remount-fs.service
Before=zfs-mount.service

[Service]
Type=oneshot
RemainAfterExit=yes
ExecStart=/bin/bash -c 'systemd-ask-password "Encrypted ZFS password" --no-tty | zfs load-key -a'

[Install]
WantedBy=zfs.target

Setzt allerdings aktuel voraus, das alle Datasets den selben Passphrase haben und checkt auch nicht ob valide und ggfs Retry notwendig ist 😉

Quelle:
https://wiki.archlinux.org/index.php/ZFS#Unlock_at_boot_time

Firmware Update D2x00 /MSAx0

Ich habe aktuell von einem auf zwei HP D2700 Disk Shelfs erweitert um mehr mit Ceph zu spielen.

Das neue hatte eine aktuellere Firmware als das alte, also hab ich mal geschaut, was da ganz aktuell ist und wie ich die dann drauf bekommen (Kein HP Server, kein Smartarray Controller vorhanden).

Wichtig hierbei: Einen HBA benutzen, kein Raid Controller!

Hier der Weg, der sowohl bei MSA60/MSA70 als auch D2600/D2700 sowie den HP SAS Expandern funktioniert (Letztlich ist im Shelf ja auch ein Expander):

Benötigte Tools:
– sg3-utils
– lsscsi

Aktuellen Stand und Pfad auslesen:
lsscsi -g
--> [33:0:25:0] enclosu HP D2700 SAS AJ941A 0149 - /dev/sg30

Die scexe/rpm von HP mit dem Firmware Update entpacken, die cpio (cpio -idv < ../datei.cpio) Datei dann ebenfalls.

Aufspielen der Firmware:
sg_write_buffer --mode=dmc_offs_defer --bpw=4096 --in=CAMSPR0150_6G_app_4MB_ai.pmc /dev/sg30
sg_write_buffer --mode=activate_mc /dev/sg30

Nach einem Reboot wurden mir dann die aktuellen Firmware-Stände angezeigt.

Ich übernehme keine Garantie, das es bei jedem so klappt, Benutzung der Anleitung auf eigene Gefahr!

Bosch PSR – Qualmt und Stinkt

Ich hatte vor einiger Zeit das Problem, das meine Bosch PSR 14,4 LI II „ausgestiegen“ ist. Sobald sie läuft qualmt und stinkt es schlimm und sie bringt keine Power mehr.

Hab schon gedacht – na super, Motor hin – und nach einem Ersatz geschaut, da bin ich über ein paar Beiträge zu dem Thema gestolpert.

Ende vom Lied:

Demontieren und mit Bremsenreiniger (KFZ Zubehör) den Motorblock ordentlich durchschwämmen. Habe den Vorgang einige male wiederholt bis nix mehr dreckiges raus gekommen ist, dabei auch ab und an mal etwas drehen, verschiedene Öffnungen verwenden und den Winkel variieren.

Danach in Ruhe trocknen und dann ein paar Minuten laufen lassen. Es stinkt dann anfangs noch, also besser draußen… Nach kurzer Zeit hat sich dann der Geruch und Qualm bei mir gelegt.

Meine läuft jetzt wieder wie am ersten Tag 🙂

Exchange 201x – ACE doesn’t exist

Ich hatte gerade ein sehr unschönes Szenario:

Exchange 2016, steht in Ressource-Domain und die Mailboxen werden auf LinkedMailbox zur Userdomain umgestellt. Die Skripte hierfür mit set-user (nicht offiziell unterstützt) sind etwas buggy und die Umgebung historisch gewachsen, weswegen einige Mailboxen wohl nicht mehr ganz saubere Berechtigungen haben.

Versuchte man dann auf einer Mailbox die FullAccess Berechtigung, die in get-mailboxpermission mit RESDOMAIN\User angezeigt wird, zu entfernen kam es zu einem „ACE doesn’t exist“ und der User wurde fälschlich in die Userdomain aufgelöst:

[PS] C:\Windows\system32>Remove-MailboxPermission -Identity "sharedmailbox" -User RESDOMAIN\user -AccessRights FullAccess

WARNING: Can't remove the access control entry on the object "CN=sharedmailbox,OU=ou,DC=dc,DC=local" for account "USERDOMAIN\user" because the ACE doesn't exist on the object.

Auch wenn ich die SID der RESDOMAIN genommen hab, kam es nicht zu einem erfolgreichen entfernen. Hier wurde der User zwar in die richtige Domäne aufgelöst, der Fehler blieb allerdings der selbe.

In dem MS Foren gibt es Tipps von -deny:$true bis zur Installation der Exchange 2003 Management Tools, aber in meinem Fall hat geholfen:

Get-MailboxPermission -Identity "sharedmailbox" -user user | Remove-MailboxPermission

Vielleicht klappt es bei noch jemanden, der das Problem auch hat.