Next: Bacula Console Up: Bacula User's Guide Previous: Anpassen der Konfigurations-Dateien Contents Index
Die Console-Konfigurations-Datei ist die einfachste Konfigurations-Datei von allen. Normalerweise müßen Sie in dieser Datei nicht außer dem Passwort ändern. Diese Datei enthält alle Informationen die nötig sind, damit sich das Console-Programm zu dem Director-Dienst verbinden kann und darf.
Für eine allgemeine Übersicht der Syntax der Konfigurations-Dateien, sowie der verschiedenen Einträge, einschließlich der Datentypen, sehen Sie sich bitte das Kapitel Konfiguration an.
Die folgenden Console-Konfigurations-Parameter müssen definiert werden:
Der Director-Eintrag enthält die notwendigen Parameter, um über das Console-Programm Zugriff auf den Director-Dienst zu haben. Sie können mehrere Director-Dienste in dieser Datei angeben, in dem Fall werden Sie beim starten der Console gefragt, zu welchem Director-Dienst Sie sich verbinden wollen.
--with-base-port angegeben haben, wird dieser Wert schon entsprechend gesetzt sein.
Der Port muß mit dem in der Director-Konfiguration angegebenen DIRport identisch sein.
Standardmäßig wird der Port 9101 verwendet, so dass dieser Parameter normalerweise nicht gesetzt ist.
Ein Beispiel eines Director-Eintrags in der Console-Konfigurations-Datei:
Director {
Name = HeadMan
address = rufus.cats.com
password = xyz1erploit
}
Der ConsoleFont-Konfigurations-Eintrag ist nur in der GNOME-Version des Console-Programms verfügbar. Er erlaubt Ihnen, die im Hauptfenster verwendete Schriftart auszuwählen.
Font = "LucidaTypewriter 9"
Vielen Dank an Phil Stracchino der diese Funktion in Bacula implementiert hat.
Hier noch ein zweites Beispiel:
ConsoleFont {
Name = Default
Font = "Monospace 10"
}
Seit der Bacula-Version 1.33 gibt es drei verschiedene Console-Typen, die der Administrator oder Benutzer zur Verwaltung des Director-Dienstes verwenden kann. Diese drei verschiedenen Typen umfassen drei unterschiedliche Sicherheitslevel.
Dieser zweite Consolen-Typ hat absolut keine Rechte, außer denen, die in der Director-Konfiguration explizit zugewiesen werden. Die Director-Konfiguration legt also fest, was dieser Consolen-Typ darf.
Damit können Sie also in der Director-Konfiguration diverse Consolen-Einträge anlegen, die jeweils unterschiedliche Passwörter und Namen haben und diese dann verschiedenen Benutzern zuweisen, die dann z.B. nur auf bestimmte Kommandos und Clients Zugriff haben. Standardmäßig darf diese Console überhaupt nichts -- keine Kommandos ausführen, absolut nichts. Sie müssen die Berechtigung für bestimmte Kommandos und Ressourcen in der Zugriffskontrollliste innerhalb der Director-Konfiguration erteilen. Dadurch hat der Administrator gezielte Kontrolle darüber, was er der Console bzw. dem Benutzer erlaubt.
Der Consolen-Konfigurations-Eintrag ist optional, wenn er angegeben wird, haben Sie allerdings die Möglichkeit, Zugriffskontrolllisten anzulegen, um die entsprechende Console in ihren Rechten einzuschränken. Damit können Sie z.B. dem Benutzer nur Zugriff auf die Backup-Jobs seines Clients erlauben.
Sie können beliebig viele Console-Einträge in Ihrer Consolen-Konfiguration anlegen. Im allgemeinen wird dann immer der erste Eintrag verwendet. Wenn Sie allerdings mehrere Director-Dienste, mit entsprechenden Einträgen in Ihrer Consolen-Konfiguration, haben, müssen Sie beim starten der Console einen der Director-Dienste auswählen. Lesen Sie bitte auch die Beschreibung des "Director"-Parameters in der Console-Konfiguration, der weiter unten beschrieben wird.
Ein Beispiel, wenn Sie folgendes in Ihrer Consolen-Konfigurations-Datei, bconsole.conf oder bwx-console.conf, definieren:
Director {
Name = MyDirector
DIRport = 9101
Address = myserver
Password = "XXXXXXXXXXX" # das dient hier nicht der Unkenntlichmachung.
}
Console {
Name = restricted-user
Password = "UntrustedUser"
}
wobei das Passwort im Director-Konfigurations-Eintrag bewußt falsch gesetzt ist und der Consolen-Eintrag einen Name besitzt, hier restricted-user. Danach erstellen Sie in der Konfiguration des Director-Dienstes, auf die der Benutzer keinen Zugriff hat, folgende Consolen:
Console {
Name = restricted-user
Password = "UntrustedUser"
JobACL = "Restricted Client Save"
ClientACL = restricted-client
StorageACL = main-storage
ScheduleACL = *all*
PoolACL = *all*
FileSetACL = "Restricted Client's FileSet"
CatalogACL = DefaultCatalog
CommandACL = run
}
dann wird der Benutzer beim Anmelden an den Director-Dienst als restricted-user angemeldet. Der Benutzer wird nur Zugriff auf Jobs mit dem Namen Restricted Client Save, auf den Client restricted-client, auf den Storage main-storage, auf jeden Zeitplan (Schedule) und auf jeden Pool, ein FileSet namens Restricted Client's FileSet, den Katalog DefaultCatalog, sowie einzig und allein das Kommando run haben. Mit anderen Worten, dieser Benutzer ist sehr eingeschränkt in dem, was er mit der Console sehen und tun kann.
Das folgende Beispiel zeigt eine bconsole.conf-Datei, in der mehrere Director-Dienste, sowie verschiedene Consolen-Einträge, abhängig vom Director, zu sehen sind:
Director {
Name = MyDirector
DIRport = 9101
Address = myserver
Password = "XXXXXXXXXXX" # das dient hier nicht der Unkenntlichmachung.
}
Director {
Name = SecondDirector
DIRport = 9101
Address = secondserver
Password = "XXXXXXXXXXX" # das dient hier nicht der Unkenntlichmachung.
}
Console {
Name = restricted-user
Password = "UntrustedUser"
Director = MyDirector
}
Console {
Name = restricted-user
Password = "A different UntrustedUser"
Director = SecondDirector
}
Der zweite Director-Dienst, benannt als "secondserver", könnte diese Konfiguration besitzen:
Console {
Name = restricted-user
Password = "A different UntrustedUser"
JobACL = "Restricted Client Save"
ClientACL = restricted-client
StorageACL = second-storage
ScheduleACL = *all*
PoolACL = *all*
FileSetACL = "Restricted Client's FileSet"might
CatalogACL = RestrictedCatalog
CommandACL = run, restore
WhereACL = "/"
}
Im Unterschied zum ersten Director-Dienst, darf der Benutzer hier, neben einem anderem Storage, auch das Consolen-Kommando restore ausführen (wobei er als Where allerdings nur "/" angeben darf).
Für mehr Details zum arbeiten mit der Console und ihrer Kommandos, lesen Sie bitte das Kapitel Bacula Console in diesem Handbuch.
Dies könnte ein Beispiel für eine Console-Konfigurations-Datei sein:
#
# Bacula Console Configuration File
#
Director {
Name = HeadMan
address = "my_machine.my_domain.com"
Password = Console_password
}
The Monitor configuration file is a stripped down version of the Director configuration file, mixed with a Console configuration file. It simply contains the information necessary to contact Directors, Clients, and Storage daemons you want to monitor.
For a general discussion of configuration file and resources including the data types recognized by Bacula, please see the Configuration chapter of this manual.
The following Monitor Resource definition must be defined:
The Monitor resource defines the attributes of the Monitor running on the network. The parameters you define here must be configured as a Director resource in Clients and Storages configuration files, and as a Console resource in Directors configuration files.
The Director resource defines the attributes of the Directors that are monitored by this Monitor.
As you are not permitted to define a Password in this resource, to avoid obtaining full Director privileges, you must create a Console resource in the Director's configuration file, using the Console Name and Password defined in the Monitor resource. To avoid security problems, you should configure this Console resource to allow access to no other daemons, and permit the use of only two commands: status and .status (see below for an example).
You may have multiple Director resource specifications in a single Monitor configuration file.
--with-base-port option of the ./configure command. This port must be
identical to the DIRport specified in the Director resource of
the
Director's configuration file. The
default is 9101 so this record is not normally specified.
The Client resource defines the attributes of the Clients that are monitored by this Monitor.
You must create a Director resource in the Client's configuration file, using the Director Name defined in the Monitor resource. To avoid security problems, you should set the Monitor directive to Yes in this Director resource.
You may have multiple Director resource specifications in a single Monitor configuration file.
The Storage resource defines the attributes of the Storages that are monitored by this Monitor.
You must create a Director resource in the Storage's configuration file, using the Director Name defined in the Monitor resource. To avoid security problems, you should set the Monitor directive to Yes in this Director resource.
You may have multiple Director resource specifications in a single Monitor configuration file.
There is no security problem in relaxing the permissions on tray-monitor.conf as long as FD, SD and DIR are configured properly, so the passwords contained in this file only gives access to the status of the daemons. It could be a security problem if you consider the status information as potentially dangereous (I don't think it is the case).
Concerning Director's configuration:
In tray-monitor.conf, the password in the Monitor resource must point to
a restricted console in bacula-dir.conf (see the documentation). So, if
you use this password with bconsole, you'll only have access to the
status of the director (commands status and .status).
It could be a security problem if there is a bug in the ACL code of the
director.
Concerning File and Storage Daemons' configuration:
In tray-monitor.conf, the Name in the Monitor resource must point to a
Director resource in bacula-fd/sd.conf, with the Monitor directive set
to Yes (once again, see the documentation).
It could be a security problem if there is a bug in the code which check
if a command is valid for a Monitor (this is very unlikely as the code
is pretty simple).
An example Tray Monitor configuration file might be the following:
#
# Bacula Tray Monitor Configuration File
#
Monitor {
Name = rufus-mon # password for Directors
Password = "GN0uRo7PTUmlMbqrJ2Gr1p0fk0HQJTxwnFyE4WSST3MWZseR"
RefreshInterval = 10 seconds
}
Client {
Name = rufus-fd
Address = rufus
FDPort = 9102 # password for FileDaemon
Password = "FYpq4yyI1y562EMS35bA0J0QC0M2L3t5cZObxT3XQxgxppTn"
}
Storage {
Name = rufus-sd
Address = rufus
SDPort = 9103 # password for StorageDaemon
Password = "9usxgc307dMbe7jbD16v0PXlhD64UVasIDD0DH2WAujcDsc6"
}
Director {
Name = rufus-dir
DIRport = 9101
address = rufus
}
Click here to see the full example.
#
# Restricted Director, used by tray-monitor to get the
# status of the file daemon
#
Director {
Name = rufus-mon
Password = "FYpq4yyI1y562EMS35bA0J0QC0M2L3t5cZObxT3XQxgxppTn"
Monitor = yes
}
Click here to see the full example.
#
# Restricted Director, used by tray-monitor to get the
# status of the storage daemon
#
Director {
Name = rufus-mon
Password = "9usxgc307dMbe7jbD16v0PXlhD64UVasIDD0DH2WAujcDsc6"
Monitor = yes
}
Click here to see the full example.
#
# Restricted console used by tray-monitor to get the status of the director
#
Console {
Name = Monitor
Password = "GN0uRo7PTUmlMbqrJ2Gr1p0fk0HQJTxwnFyE4WSST3MWZseR"
CommandACL = status, .status
}