Schlagwort: Linux

Alt-Tab für Citrix in Wayland

nachdem ich zum wiederholten Mal darüber gestolpert bin das bei der Nutzung von Citrix unter Wayland die „Alt-Tab“-Taste vom Host-System „gefressen“ wird und damit der schnelle Programmwechsel in der Citrix-Umgebung nicht wirklich funktioniert, schreibe ich hier jetzt die Lösung des Problems als kleinen Reminder für mich selbst auf, damit ich nicht immer wieder neu danach suchen muss.

Für Gnome

Einfach folgenden Zweizeiler auf Kommandozeile abgesetzt und schon klappt’s auch mit „Alt-Tab“:

gsettings set org.gnome.mutter.wayland xwayland-grab-access-rules "['Wfica']"
gsettings set org.gnome.mutter.wayland xwayland-allow-grabs true

Gefunden auf: https://wiki.archlinux.org/title/citrix

Für KDE

In KDE kann das entsprechende Verhalten mithilfe der Systemeinstellungen vorgegeben werden. Dazu muss unter „Fensterverwaltung -> Fensterregeln“ eine neue Regel angelegt und dort eine Eigenschaft hinzugefügt werden:

Beschreibung:  Citrix  (kann frei gewählt werden)
Fensterklasse (Programm):  "Exakte Übereinstimmung"  wfica

und als Eigenschaft:
Globale Kurzbefehle ignorieren:   Erzwingen Ja

ISC-DHCP und IPv6 bei Debian-Stretch

Vorgeplänkel …

Nachdem das Upgrade von Jessie nach Stretch für die meisten Dienste auf meinem kleinen Cubietruck vollkommen problemlos durchlief, verursachte das Upgrade des ISC-DHCPD ein paar graue Haare mehr auf meinem Kopf.

Hintergrund der Probleme waren IPv4 und IPv6.
Ich nutze den Cubietruck u.a. auch dazu um im heimischen Netz IP(v4!)-Adressen zu verteilen. Das funktioniert seit Jahren wunderbar und vollkommen problemlos. Gleichzeitig wird der DNS-Server -dieser läuft selbstredend auch auf der kleinen Kiste- durch den dhcpd mit aktuellen Daten versorgt.

Soweit, so gut.

ISC-DHCP und IPv6 bei Debian-Stretch weiterlesen

Bareos / Bacula und Notebooks

Vorwort

Backups sind wichtig. Das weiß mittlerweile jedes Kind. Daher setze ich hier zur Sicherung meiner Server schon seit längerem Bacula und seit kürzerem auf einem zweiten System Bareos, einen Bacula-Fork, ein. Man muss zwar anfänglich etwas Hirnschmalz in die Konfiguration investieren, aber dann laufen beide Systeme ohne weiteres Eingreifen und machen genau das was sie sollen. Und das verdammt zuverlässig. Für alle Maschinen die sich regelmäßig vom Backup-Server erreichen lassen ist diese Lösung somit optimal.

Aber was macht man mit Geräten, welche sich nicht kontinuierlich im „heimischen Netz“ befinden, sondern gerne auch mal auf Reisen und damit auch in anderen Netzen unterwegs sind, sprich Notebooks?

Vor diesem Problem stand ich nun. Google förderte zwar den einen oder anderen Lösungsvorschlag zu Tage, aber keiner davon gefiel mir wirklich gut. Daher war wieder „Hirnschmalz investieren“ angesagt, und nun möchte ich euch an meiner Lösung teilhaben lassen. Vielleicht gefällt mein Ansatz ja dem einen oder anderen und erspart dann etwas Zeit und Mühe. Ich würde mich auf jeden Fall freuen.

Vorwissen

Ich setze für den weiteren Text zumindest Grundwissen beim Einrichten und Betrieb von Bacula /  Bareos voraus, schreibe also kein Einsteigertutorial. Die gibt es zur Genüge und auch die Doku beider Systeme ist sehr ergiebig. Ich gehe davon aus, das Bareos bereits läuft und auf dem Notebook ein File-Daemon installiert und passend zum Server konfiguriert ist.
Außerdem sollten Grundkenntnisse bei der Arbeit mit Linux und diversen Diensten (z.B. ssh, cron, …) vorhanden sein.

Auch wenn ich im weiteren Verlauf von Bareos schreibe, gilt alles auch für Bacula.

Lastenheft

Folgende Punkte sind mir wichtig:

  • Die Sicherung fügt sich, möglichst umfassend in das bestehende Sicherungskonzept ein
  • Die Sicherung erfolgt mit Bareos
  • Die Sicherung startet automatisch, sobald das Gerät das „heimische Netz“ betritt
  • Die Sicherung wird nur einmal täglich gestartet, auch wenn das Gerät mehrfach das Netz betritt.
  • Die Sicherung erfolgt mindestens einmal täglich, ganz besonders wenn sich das Gerät länger im heimischen Netz befindet.

Die Umsetzung

Grundsätzlich wird das Sicherungsintervall ja durch den Bareos-Direktor gesteuert. In dessen Konfiguration wird hinterlegt was wann, wo und wie gesichert wird.

Dieses Vorgehen ist für Server und auch fest installierte Desktop-Rechner spitze, stößt bei Notebooks jedoch auf Probleme, wenn diese zum Zeitpunkt der geplanten Sicherung gerade mal wieder unterwegs sind. Bareos wartet hier bei Abwesenheit des Gerätes bis zum Timeout und protokolliert dann einen Fehler. Das sieht irgendwie unschön aus und spätestens nach der 5 E-Mail vom Bareos-Direktor nervt das auch, und alles nur, weil der Kollege gerade mal wieder einige Tage auf Dienstreise ist.

Die Idee

Da es, wie gerade beschrieben, problematisch ist das Backup für Notebooks vom Direktor steuern zu lassen, besteht meine Idee jetzt darin, dem Direktor diese Aufgabe zu entziehen und dem Notebook selbst zu übertragen.

Dieses kann beim Auftreten bestimmter Ereignisse prüfen ob der Bareos-Server erreichbar ist und im Erfolgsfall den Bareos-Direktor anweisen das Backup zu starten.

Als Ereignisse zum Triggern der Überprüfung und des Backupstarts fallen mir jetzt spontan der Aufbau der Netzwerkverbindung oder auch das Timing per Cronjob ein. So soll das nachfolgend auch umgesetzt werden.

Arbeiten am Bareos-Server

Fangen wir mit dem Server an. Wir entziehen dem Bareos-Direktor im ersten Schritt die Steuerung des Backup für das Notebook. Dazu tilgen wir den starren Zeitplan aus der Konfiguration indem wir im entsprechenden Schedule einfach alle „Run-Direktiven“ entfernen bzw. auskommentieren. Sollte ein Schedule verwendet werden, welches auch für andere Backup-Jobs benötigt wird, erstellt man einfach ein neues ohne Run-Direktiven und passt die Konfiguration entsprechend an. Nach einem Neustart des Bareos-Direktors, bzw. reload in der bconsole gibt es dann auch keine Meldung mehr über fehlgeschlagene Backupversuche bei abwesendem Notebook. Leider wird jetzt aber auch kein automatisches Backup mehr erzeugt. Also erstmal nur die halbe Miete.

Da Bareos selbst keine direkte Möglichkeit bietet Jobs per Skript zu starten und/oder zu stoppen, müssen wir für das weiter Vorgehen die Möglichkeit nutzen, das Programm „bconsole“ per Pipe zu steuern. Dazu habe ich mir ein kleines Bash-Skript „bareos-remote.sh“ (Listing 1) geschrieben. Dieses Skript liegt hier im Verzeichnis /etc/bareos/ und nimmt auf der Kommandozeile 2 Parameter entgegen. Einmal die gewünschte Aktion (start oder stop) und dann den Namen des entsprechenden Jobs.

Listing 1: „bareos-remote.sh“
(Das zum Download angebotene Shell-Skript ist ausführlicher kommentiert als das nachfolgende Skript, unterscheidet sich ansonsten aber nicht.)

#!/bin/bash

################################################################
# this script pipes commands to bconsole to start
# or cancel a bareos/bacula job
#
# Copyright (C) 2014 Michael Oehme <m.m.oehme@gmail.com>
#
# This program is free software: you can redistribute it
# and/or modify it under the terms of the GNU General
# Public License as published by the Free Software Foundation,
# either version 3 of the License, or (at your option) any 
# later version.
#
#
# This program is distributed in the hope that it will
# be useful,
# but WITHOUT ANY WARRANTY; without even the implied
# warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
# See the
# GNU General Public License for more details.
################################################################

MYSELF=$0
ACTION=$1
JOBTORUN=$2

## Funktion für die Ausgabe der Synopsis (--help)
function usage {
 echo "Usage: $MYSELF start|stop Job"
 echo ""
 echo "start|stop Should the given Job be started or stoped?"
 echo "Job Which bareos Job should be processed?"
}

## Funktion zum Start eine Bareos/Bacula-Jobs
function start_job {
  echo "Job wird gestartet."
  /usr/sbin/bconsole <<EOF
  run job=$JOBTORUN yes
  quit
  EOF
}

## Funktion zum Abbruch eine Bareos/Bacula-Jobs
function stop_job {
  echo "Job wird abgebrochen!"
  /usr/sbin/bconsole <<EOF
  cancel job=$JOBTORUN
  EOF
}

## Funktion zum überprüfen ob der angegebene Job ein gültiger Bareos/Bacula-Job ist
function check_jobs {
  AVAILJOBS=`echo -e "@output /dev/null\nmess\n@output\n.jobs"|/usr/sbin/bconsole `
  AVAILJOBS=`echo $AVAILJOBS|sed 's/.*\.jobs //'`
  for Job in $(echo $AVAILJOBS); do
    [ "$Job" = "$JOBTORUN" ] && return
  done
  echo "Kein gültiger Job angegeben."
  exit 1
}

## JETZT GEHTS LOHOS, ...
case $ACTION in
start)
  check_jobs
  start_job
  exit 0
  ;;

stop)
  check_jobs
  stop_job
  exit 0
  ;;

*)
  usage

esac

exit 1

Einem ersten Testlauf des Skripts steht jetzt nicht mehr im Weg. Somit sollte ein beherzter Aufruf von „/etc/bareos/bareos-remote.sh start Job-BU-MMOs-Notebook“ die Sicherung des Notebooks anschubsen. Hier muss natürlich der Name des Jobs an die lokalen Gegebenheiten angepasst werden. Wenn alles klar gegangen ist, läuft jetzt die Sicherung wie gewünscht an, vorausgesetzt natürlich das Notebook ist nicht doch irgendwo auf Reisen.

Arbeiten am Bareos-Client (Notebook)

Wenn im vorangegangenen Abschnitt alles klar gegangen ist, wird es jetzt Zeit, auf das Notebook zu wechseln und dort die weiteren Arbeiten vorzunehmen.

Geplant ist es zukünftig das Skript “bareos-remote.sh”, dieses liegt ja auf dem Server, per SSH zu starten. Damit dies auch vollautomatisch ohne lästige Passworteingabe funktioniert, muss SSH so eigerichtet werden, das sich root vom Notebook auf dem Bareos-Server als Benutzer bareos mittels Key anmelden kann.

Sobald SSH entsprechend vorbereitet ist gilt es zu testen, ob der Skriptaufruf richtig funktioniert. Also beherzt in die Tasten gegriffen und als root auf dem Notebook folgendes abgesetzt: ssh -c bareos@bareosserver “/etc/bareos/bareos-remote.sh start Job-BU-MMOs-Notebook”.

Wenn wieder alles klar gegangen ist, dann sollte Bareos auch jetzt das Backup starten und zwar ohne, dass nach dem Absetzen des Kommandos eine Eingabe vom Benutzer erwartet wird.

Soweit so gut. Jetzt gilt es den Skriptaufruf zu triggern. Außerdem soll vor dem eigentlichen Aufruf geprüft werden, ob der Bareos-Server überhaupt erreichbar und der letzte Backupstart nicht bereits am Tag des Aufrufs erfolgt ist.

Um das ganze zu Vereinfachen habe ich auch dafür ein kleines Bash-Skript geschrieben. Dieses Skript prüft erstens ob der Bareos-Server erreichbar ist und zweitens ob am Tag des Aufrufs noch kein Backup gelaufen ist. Wenn beide Bedingungen erfüllt sind, wird das Skript “bareos-remote.sh” auf dem Bareos-Server gestartet und damit das Backup.

Listing 2: call-bareos.sh
(Das zum Download angebotene Shell-Skript ist ausführlich kommentiert, anders als das nachfolgende Listing.)

#!/bin/bash
##################################################################
# this script calls another script per ssh to start a bacula-job.
#
# Copyright (C) 2014 Michael Oehme <m.m.oehme@gmail.com>
#
# This program is free software: you can redistribute it
# and/or modify it under the terms of the GNU General Public 
# License as published by the Free Software Foundation, 
# either version 3 of the License, or (at your option) any
# later version.
#
# This program is distributed in the hope that it will be
# useful, but WITHOUT ANY WARRANTY; without even the implied
# warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR
# PURPOSE. See the GNU General Public License for more details.
#
##################################################################

BAREOSSERVER="StaBi-ZB508-01L"
BAREOSREMOTESCRIPT="/etc/bareos/bareos-remote.sh"
BAREOSJOB="Job-BU-MMOs-Notebook"
LASTRUNFILE="/var/lib/bacula/lastrun"


## IST der Server erreichbar? -> Wenn nicht, dann ENDE
if ! /bin/ping -c 1 $BAREOSSERVER > /dev/null
then
/usr/bin/logger info "BAREOS: Der Server ist nicht erreichbar."
exit 0
fi

## Liegt das letze Backup länger als einen Tag zurück? Wenn nicht, dann ENDE
if [ $(find $LASTRUNFILE -mtime -1|wc -l) -gt 0 ];
then
/usr/bin/logger info "BAREOS: Backup heute bereits gelaufen."
exit 0
fi

##################################################################
# Da wir bis hierher gekommen sind, sollte das Backup nun auch gestartet werden.
if ssh $BAREOSSERVER -C "$BAREOSREMOTESCRIPT start $BAREOSJOB"
then
/usr/bin/logger info "BAREOS: Backup wurde in die Warteschlange aufgenommen."
touch -t `date +%m%d0000` $LASTRUNFILE
exit 0
fi

## Wenn wir hier landen, dann ist irgendwas schief gegangen.
/usr/bin/logger info "BAREOS: Backup konnte nicht in die Warteschlange aufgenommen werden."
exit 1

Dieses Skript wird ohne Parameter aufgerufen. Dies ist wichtig, da bei einem der geplanten, automatischen Aufrufe keine Parameterübergabe möglich ist.   Um aber trotzdem einigermaßen flexibel zu bleiben, wurden am Anfang des Skripts einige Variablen definiert. Diese sollten vor dem Einsatz an die lokalen Gegebenheiten angepasst werden. ich habe versucht einigermaßen sprechenden Namen zu verwenden.

Wenn ihr wollt, könnt ihr jetzt auch dieses Skript einmal zur Probe laufen lassen. Ist alles richtig eingestellt, sollte zum dritten Mal ein Backup starten.

Nun gilt es tatsächlich die Trigger zu schalten.

Netzwerk

Wir haben oben geschrieben, das dass Backup automatisch starten soll, sobald das Notebook das heimische Netz betritt. Dazu bietet sich der Start von bareos.sh über das Verzeichnis “/etc/network/if-up.d” an.

Ich habe dazu im genannten Verzeichniss einen Link zum eigentlichen Skript hinterlegt. Sobald dann ein Netzwerkinterface aktiviert wird, werden die Skripte in diesem Verzeichnis der Reihe nach aufgerufen und abgearbeitet.

Hinweis: Auf meinem Ubuntu Notebook werden die Skripte per run-parts gestartet. Dies führt dazu, das alles was einen “.” im Dateinamen hat nicht gestartet wird. Daher heißt der Link bei mir einfach nur bareos, ohne “.sh”. Nach meinem Kenntissstand betrifft dieses Problem nahezu alle Distributionen.

Cron

Eine weitere Bedingung war, dass das Backup auch dann mindestens einmal am Tag starten soll wenn es doch mal länger im heimischen Netz verweilt. Der Aufruf über “if-up.d” hilft uns hier nicht weiter, da dieser nur beim Aufbau der Netzwerkverbindung aktiv wird.

Allerdings schreit diese weitere Bedingung förmlich nach einem cron-Job.

Also noch schnell einen Link nach “/etc/cron.daily/” angelegt und schon haben wir alle gewünschten Punkte abgefrühstückt.

Beim Aufruf per Cron wäre auch noch die Alternative über die Crontab denkbar – hier könnt man dann sogar noch Parameter an das Skript weitergeben – aber ein einfacher Link ist sicherlich schneller eingerichtet. Am Ende ist es aber egal.

Zusammenfassung

Nachfolgend noch einmal stichpunktartig eine Zusammenfassung der notwendigen Schritte:

auf dem Server

  • Skript “bareos-remote.sh” (Listing 1) erstellen
  • in der Bareosr-Konfiguration im Schedule alle Run-Direktiven deaktivieren

auf dem Client

  • SSH-Key-Authentifizierung einrichten (Notebook-root muss als Nutzer bareos auf den Server zugreifen)
  • Skript “call-bareos.sh” erstellen und anpassen
  • Skript “call-bareos.sh” nach “/etc/network/if-up.d/bareos” verlinken
  • Skript “call-bareos.sh” nach “/etc/cron.daily/if-up.d/bareos” verlinken