Kategorie: Software

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

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.

Sicherung von LXD Containern

Leider ist in den 2.xx Versionen von LXD noch keine direkte Backup-Funktion eingebaut.

Der Workaround geht über:

  • Snapshot der VM erstellen
  • Snapshot in Image wandeln
  • Image exportieren

Für diese Schritte hab ich mir mal ein Skript zusammen gebaut, das ich nicht vorenthalten will:

#!/bin/bash
datum=$(date +%Y-%m-%d)
backupdir=/mnt/data/backup/lxd
#vmliste=$(lxc list | awk '$4 == "STARTED" {print $2}')
vmliste=$(lxc list --format csv -c n)

echo "Starte Backup auf $(hostname -f)"
echo " "
date
echo " "
echo "Sicherungsliste:"
echo $vmliste
echo " "
for vm in $vmliste
do
 echo "Sichere VM: " $vm
 lxc snapshot $vm backup && echo "Snapshot erfolgreich"
 lxc publish $vm'/backup' --alias $vm'-backup' --compression none && echo "Publish erfolgreich"
 [ -d $backupdir/$datum ] || mkdir $backupdir/$datum
 lxc image export $vm-backup $backupdir/$datum/$vm.tar && echo "Export erfolgreich"
 lxc image delete $vm-backup && echo "Image Cleanup erfolgreich"
 lxc delete $vm/backup && echo "Snapshot Cleanup erfolgreich"
 [ -e /var/lib/lxd/containers/$vm/backup.yaml ] && cp /var/lib/lxd/containers/$vm/backup.yaml $backupdir/$datum/$vm.yaml && echo "Config kopiert"
 echo " "
done

date
echo " "
echo "Sicherungen abgeschlossen."

Die Formatierung und Ausgaben zielen herbei auf meine cron-Mail-Formatierung ab 😉

Am Anfang ist noch ein „Switch“, ggfs nur die laufenden VMs zu sichern.

Ich habe die gzip-Komprimierung aus Performancegründen abgeschaltet, andernfalls dauert der Publish sehr lange. Das Image ist dann zwar größer, aber auch bedeutend schneller fertig (bei meinem etwas schwachen Server…).