Console Resource

There are three different kinds of consoles, which the administrator or user can use to interact with the Director. These three kinds of consoles comprise three different security levels.

  • The first console type is an anonymous or default console, which has full privileges. There is no console resource necessary for this type since the password is specified in the Director resource. Typically you would use this anonymous console only for administrators. The second type of console is a “named” or “restricted” console defined within a Console resource in both the Director’s configuration file and in the Console’s configuration file. Both the names and the passwords in these two entries must match much as is the case for Client programs.

  • This second type of console begins with absolutely no privileges except those explicitly specified in the Director’s Console resource. Note, the definition of what these restricted consoles can do is determined by the Director’s conf file. Thus you may define within the Director’s conf file multiple Consoles with different names and passwords, sort of like multiple users, each with different privileges. As a default, these consoles can do absolutely nothing – no commands what so ever. You give them privileges or rather access to commands and resources by specifying access control lists in the Director’s Console resource. This gives the administrator fine grained control over what particular consoles (or users) can do.

  • The third type of console is similar to the above mentioned restricted console in that it requires a Console resource definition in both the Director and the Console. In addition, if the console name, provided on the Name = directive, is the same as a Client name, the user of that console is permitted to use the SetIP command to change the Address directive in the Director’s client resource to the IP address of the Console. This permits portables or other machines using DHCP (non-fixed IP addresses) to “notify” the Director of their current IP address.

The Console resource is optional and need not be specified. However, if it is specified, you can use ACLs (Access Control Lists) in the Director’s configuration file to restrict the particular console (or user) to see only information pertaining to his jobs or client machine.

You may specify as many Console resources in the console’s conf file. If you do so, generally the first Console resource will be used. However, if you have multiple Director resources (i.e. you want to connect to different directors), you can bind one of your Console resources to a particular Director resource, and thus when you choose a particular Director, the appropriate Console configuration resource will be used. See the “Director” directive in the Console resource described below for more information.

Note

The Console resource is optional, but can be useful for restricted consoles as noted above.

The explanation on how to read the directive format:

  • Name: Contains the linked name of the directive.

  • Description: Explains what the directive does.

  • Value: Indicates what type of value to provide (e.g., <type-specification>).

  • Data Type: Specifies the type of data expected.

  • Values: Lists specific acceptable values.

  • Required: If present, indicates that the directive must be set by the user, there is no default value.

  • Default: If present, indicates that the directive has a predefined value that does not need to be set by the user, cannot be removed.

  • Comment: Additional important notes.

  • Example: Shows a usage example.

Console Start of the Console resource.

Name

Description: Used to allow a restricted console to change its IP address using the SetIP command.

Value(s): <name>

Data Type: string

Required: Yes

Comment: The SetIP command must also be defined in the Director’s conf CommandACL list.

Description

Description: The text field contains a description of the Director that will be displayed in the graphical user interface.

Value(s): <text>

Data Type: string

Password

Description: If this password is supplied, then the password specified in the Director resource of your Console conf will be ignored.

Value(s): <password>

Data Type: password

Required: Yes

Director

Description: If this directive is specified, this Console resource will be used by bconsole when that particular director is selected when first starting bconsole. I.e. it binds a particular console resource with its name and password to a particular director.

Value(s): <director-resource-name>

Data Type: string

Heartbeat Interval

Description: If specified will cause the Console to set a keepalive interval (heartbeat) in seconds on each of the sockets to communicate with the Director.

Value(s): <time>

Data Type: time

Default: 0 seconds

Comment: It is implemented only on systems that provide the setsockopt TCP_KEEPIDLE function. The default value is zero, which means no change is made to the socket.

History File

Description: Used to store the console command history.

Value(s): <filename>

Data Type: string

Comm Compression

Description: Enables communication line compression.

Value(s): <yes|no>

Data Type: boolean

Default: yes

Comment: In many cases, the volume of data transmitted across the communications line can be reduced by a factor of three when this directive is enabled. In the case that the compression is not effective, Bacula turns it off on a record by record basis. If you are backing up data that is already compressed the comm line compression will not be effective, and you are likely to end up with an average compression ratio that is very small. In this case, Bacula reports None in the Job report.

Fips Require

Description: Require FIPS! cryptographic module to start the daemon.

Value(s): <>

Data Type: boolean

Tls Psk Enable

Description: Enable or Disable automatic TLS PSK support.

Value(s): <yes|no>

Data Type: boolean

Default: yes

Comment: TLS PSK is enabled by default between all Bacula components. The Pre-Shared Key used between the programs is the Bacula password. If both TLS Enable and TLS PSK Enable are enabled, the system will use TLS certificates.

Tls Authenticate

Description: When TLS Authenticate is enabled, after doing the CRAM-MD5 authentication, Bacula will also do TLS authentication, then TLS encryption will be turned off, and the rest of the communication between the two Bacula components will be done without encryption. If TLS-PSK is used instead of the regular TLS, the encryption is turned off after the TLS-PSK authentication step.

Value(s): <yes|no>

Data Type: boolean

Tls Verify Peer

Description: Verify peer certificate. Instructs server to request and verify theclient’s X.509 certificate.

Value(s): <yes|no>

Data Type: boolean

Default: yes

Comment: Any client certificate signed by a known-CA will be accepted. Additionally, the client’s X509 certificate Common Name must meet the value of the Address directive. If the TLSAllowedCN configuration option is used, the client’s x509 certificate Common Name must also correspond to one of the CN specified in the TLS Allowed CN directive. This directive is valid only for a server and not in client context. The default is yes.

Tls Dh File

Description: Path to PEM encoded Diffie-Hellman parameter file.

Value(s): <directory>

Data Type: string

Comment: If this directive is specified, DH key exchange will be used for the ephemeral keying, allowing for forward secrecy of communications. DH key exchange adds an additional level of security because the key used for encryption/decryption by the server and the client is computed on each end and thus is never passed over the network if Diffie-Hellman key exchange is used. Even if DH key exchange is not used, the encryption/decryption key is always passed encrypted. This directive is only valid within a server context.

To generate the parameter file, you may use openssl:

openssl dhparam -out dh4096.pem -5 4096

Tls Ca Certificate Dir

Description: Full path to TLS CA certificate directory. In the current implementation, certificates must be stored PEM encoded with OpenSSL-compatible hashes, which is the subject name’s hash and an extension of .0. One of TLS CA Certificate File or TLS CA Certificate Dir are required in a server context, unless TLS Verify Peer is set to no, and are always required in a client context.

Value(s): <directory>

Data Type: string

Tls Key

Description: The full path and filename of a PEM encoded TLS private key. It must correspond to the TLS certificate.

Value(s): <filename>

Data Type: string

Tls Enable

Description: Enable TLS support.

Value(s): <yes|no>

Data Type: boolean

Comment: If TLS is not enabled, none of the other TLS directives have any effect. In other words, even if you set TLS Require = yes you need to have TLS enabled or TLS will not be used.

Tls Allowed Cn

Description: Common name attribute of allowed peer certificates.

Value(s): <certificate-list>

Data Type: string list

Comment: This directive is valid for a server and in a client context. If this directive is specified, the peer certificate will be verified against this list. In the case this directive is configured on a server side, the allowed CN list will not be checked if TLS Verify Peer is set to no (TLS Verify Peer is yes by default). This can be used to ensure that only the CN-approved component may connect. This directive may be specified more than once.

Example: In the case this directive is configured in a server side, the allowed CN list will only be checked if TLS Verify Peer = yes (default).

Director {
    Name = bacula-dir
    Password = "password"
    Address = director.example.com
    # TLS configuration directives
    TLS Enable = yes
    TLS Require = yes
    # if TLS Verify Peer = no, then TLS Allowed CN will not be checked.
    TLS Verify Peer = yes
    TLS Allowed CN = director.example.com
    TLS CA Certificate File = /opt/bacula/ssl/certs/root_cert.pem
    TLS Certificate = /opt/bacula/ssl/certs/client1_cert.pem
    TLS Key = /opt/bacula/ssl/keys/client1_key.pem
}

In the case this directive is configured in a client side, the allowed CN list will always be checked.

  Client {
      Name = client1-fd
      Address = client1.example.com
      FDPort = 9102
      Catalog = MyCatalog
      Password = "password"
      ...
      # TLS configuration directives
      TLS Enable = yes
      TLS Require = yes
      # the Allowed CN will be checked for this client by director
      # the client's certificate Common Name must match any of
      # the values of the Allowed CN list
      TLS Allowed CN = client1.example.com
      TLS CA Certificate File = /opt/bacula/ssl/certs/ca_client1_cert.pem
      TLS Certificate = /opt/bacula/ssl/certs/director_cert.pem
      TLS Key = /opt/bacula/ssl/keys/director_key.pem
}

If the client doesn’t provide a certificate with a Common Name that meets any value in the TLS Allowed CN list, an error message will be issued:

16-Nov 17:30 bacula-dir JobId 0: Fatal error: bnet.c:273 TLS certificate
verification failed. Peer certificate did not match a required commonName
16-Nov 17:30 bacula-dir JobId 0: Fatal error: TLS negotiation failed with FD at
"192.168.100.2:9102".

Tls Require

Description: Require TLS or TLS-PSK encryption.

Value(s): <yes|no>

Data Type: boolean

Comment: This directive is ignored unless one of TLS Enable or TLS PSK Enable is set to yes. If TLS is not required while TLS or TLS-PSK are enabled, then the Bacula component will connect with other components either with or without TLS or TLS-PSK. If TLS or TLS-PSK is enabled and TLS is required, then the Bacula component will refuse any connection request that does not use TLS.

Tls Certificate

Description: The full path and filename of a PEM encoded TLS certificate.

Value(s): <filename>

Data Type: string

Comment: It will be used as either a client or server certificate, depending on the connection direction. PEM stands for Privacy Enhanced Mail, but in this context refers to how the certificates are encoded. This format is used because PEM files are base64 encoded and hence ASCII text based rather than binary. They may also contain encrypted information.

Example: This directive is required in a server context, but it may not be specified in a client context if TLS Verify Peer is set to no in the corresponding server context.

Example:

File Daemon configuration file (bacula-fd.conf), resource configuration has TLS Verify Peer=no:

Director {
    Name = bacula-dir
    Password = "password"
    Address = director.example.com
    # TLS configuration directives
    TLS Enable = yes
    TLS Require = yes
    TLS Verify Peer = no
    TLS CA Certificate File = /opt/bacula/ssl/certs/root_cert.pem
    TLS Certificate = /opt/bacula/ssl/certs/client1_cert.pem
    TLS Key = /opt/bacula/ssl/keys/client1_key.pem
}

Tls Ca Certificate File

Description: The full path and filename specifying a PEM encoded TLS CA certificate(s).

Value(s): <filename>

Data Type: string

Comment: Multiple certificates are permitted in the file. One of TLS CA Certificate File or TLS CA Certificate Dir are required in a server context, unless TLS Verify Peer (see above) is set to no, and are always required in a client context.

Note

TLS Directives in the Console resource of bconsole.conf

Bacula has built-in network encryption code to provide secure network transport similar to that offered by stunnel or ssh . The Bacula TLS encryption applies only to information transmitted across a network, so the data written to Volumes by the Storage daemon is not encrypted by this code.

For more information how to enable TLS encryption, click here.

Use Cases

If we define the following in the user’s bconsole.conf file (or perhaps the bwx-console.conf file):

Director {
    Name = bacula-dir
    DIRport = 9101
    Address = baculadir.example.com
    Password = "XXXXXXXXXXX" # no, really. this is not obfuscation.
}

Console {
    Name = restricted-user
    Password = "UntrustedUser"
}

where the Password in the Director section is deliberately incorrect, and the Console resource is given a name, in this case restricted-user. Then, in the Director’s bacula-dir.conf file (not directly accessible by the user), we define:

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 = BaculaCatalog
    CommandACL = run
}

The user logging into the Director from his Console will get logged in as restricted-user, and he will only be able to see or access a Job with the name Restricted Client Save, a Client with the name restricted-client, a Storage device main-storage, any Schedule or Pool, a Fileset named Restricted Client’s Fileset, a Catalog named DefaultCatalog, and the only command they can use in the Console is the run command. In other words, this user is rather limited in what he can see and do with Bacula.

The following is an example of a bconsole conf file that can access several Directors and have different Consoles depending on the director:

Director {
    Name = bacula1-dir
    DIRport = 9101
    Address = bacula1.example.com
    Password = "XXXXXXXXXXX" # no, really. this is not obfuscation.
}
Director {
    Name = bacula2-dir
    DIRport = 9101
    Address = bacula2.example.com
    Password = "XXXXXXXXXXX" # no, really. this is not obfuscation.
}

Console {
    Name = restricted-user
    Password = "UntrustedUser"
    Director = bacula1-dir
}
Console {
    Name = restricted-user-2
    Password = "A different UntrustedUser"
    Director = bacula2-dir
}

The second Director referenced at “bacula2-dir” might look like the following:

Console {
    Name = restricted-user-2
    Password = "A different UntrustedUser"
    JobACL = "Restricted Client Save"
    ClientACL = restricted-client
    StorageACL = second-storage
    ScheduleACL = *all*
    PoolACL = *all*
    FilesetACL = "Restricted Client’s Fileset"
    CatalogACL = Bacula2Catalog
    CommandACL = run, restore
    WhereACL = "/"
}

To use the same Console name on both Directors, you must create two bconsole.conf to store the two Director/Console groups.

Console Commands

For more details on running the console and its commands, see the Bacula Console chapter.

Go back to Console Resource Types page.

Go back to the Technical Reference for Console Daemon.

Go back to the main Technical Reference page.