OS profiles

OS profiles#

What is OS profile#

The OS profiles are a set of defined commands which are executed during deployment process. Bacularis administrator can use pre-defined OS profiles for popular Linux distributions or create own OS profiles adjusted to used operating system.

The pre-defined OS profiles are for the following operating systems:

  • AlmaLinux 8

  • AlmaLinux 9

  • CentOS 8 / RHEL

  • CentOS Stream 8 / RHEL

  • CentOS Stream 9 / RHEL

  • Debian 11 Bullseye

  • Debian 12 Bookworm

  • Fedora 38

  • Fedora 39

  • Fedora 40

  • Fedora 41

  • Oracle Linux 8

  • Oracle Linux 9

  • Rocky Linux 8

  • Rocky Linux 9

  • Ubuntu 20.04 Focal

  • Ubuntu 22.04 Jammy

  • Ubuntu 23.04 Lunar

  • Ubuntu 23.10 Mantic

  • Ubuntu 24.04 Noble

  • Ubuntu 24.10 Oracular

For creating own OS profiles there is an option to inherit commands from existing profiles and extend theirs configuration in the new profile. For example administrator would like to customize the default Bacularis username and password or use other package repository than defined in the pre-defined OS profile. In this case he/she can inheirt an exisiting OS profile settings and change username, password or repository in the new OS profile. Alternatively he/she can create the OS profile from scratch.

Configuration options#

Below you can find description for the OS profile options.

Repositories#

  • OS profile name - name used to identify the profile.

  • Description - an option to describe the OS profile.

  • Add repository entry to remote host - if checked then on new hosts will be configured repository defined in Bacularis repository URL (or entry) option. If the Repository type option is set to the DEB-based systems then there are created repository files in /etc/apt/sources.list.d/. If the Repository type is set to the RPM-based system then the repository files path is /etc/yum.repos.d/.

  • Repository type - defines what type of repository is used. It can be deb or rpm type. This option is available only if Add repository entry to remote host option is checked.

  • Bacularis repository URL (or entry) - Bacularis repository definition. Using this repository Bacularis will be installed during deployment. This option is available only if the Add repository entry to remote host option is checked. For the RPM-based systems it is the repository URL. For the DEB-based systems it is a line in almost the same syntax as is used to define deb package repositories in /etc/apt/sources.list.d/ (but without leading deb word), for example it can be https://pkgs.bacularis.app/stable/debian/ bullseye main.

  • Bacularis repository key URL - URL with a GPG verification key that is capable to verify signed packages. This option is available only if Add repository entry to remote host option is checked.

  • Use default Bacularis repository auth - if checked then for accessing the Bacularis repository is used default repository authentication defined in the Repo auths function. If unchecked then for accessing the Bacularis repository is used selected authentication defined in the Repo auths. For repositories available publicly (without authentication) this option does not matter.

  • Repo auth - selected repository authentication to use with the Bacularis package repository. The repo auths are defined on the Deployment page.

  • Use system repository for Bacula packages - if checked then on new hosts will be used existing system repositories for installing Bacula components. If unchecked then on new hosts will be configured repository defined in the Bacula repository URL (or entry) option.

  • Bacula repository URL (or entry) - Bacula repository definition. Using this repository Bacula components will be installed during deployment. This option is available only if the Use system repository for Bacula packages option is unchecked. For the RPM-based systems it is the repository URL. For the DEB-based systems it is a line in almost the same syntax as is used to define deb package repositories in /etc/apt/sources.list.d/ (but without leading deb word), for example it can be http://ftp.pl.debian.org/debian/ bullseye main.

  • Bacula repository key URL - URL with a GPG verification key that is capable to verify signed packages. This option is available only if the Use system repository for Bacula packages is unchecked.

Bacularis API access#

  • Use HTTPS - if checked then Bacularis installed on new hosts will be available through the secure HTTPS connection. Otherwise the connection to Bacularis will be realized via unprotected HTTP connection.

  • Bacularis admin user - during deployment there is created a new Bacularis user. In this option is possible to set its name. Default is set admin.

  • Bacularis admin password - password for the user defined in the Bacularis admin user option. Default is set admin.

  • Bacularis start command - system command used to start Bacularis after deploying. In most cases it is a good place to define web server start command.

Bacularis API settings#

All of the following settings are added to each new remotely installed Bacularis API that uses selected OS profile.

Package management#

  • Use sudo for commands - if checked then to each command defined in the package management section will be added sudo at the beginning of command. With this option during deployment will be also automatically created on new hosts a sudoers setting for each defined command.

  • Sudo user - it is the web server user or PHP user that will be used in newly created sudoers settings. This option has meaning only together with the Use sudo for commands option.

  • Bacularis installation command - a command used during Bacularis API deployment to install Bacularis on new hosts.

  • Bacularis pre-install command - a command executed on remote hosts before installing Bacularis.

  • Bacularis post-install command - a command executed on remote hosts after installing Bacularis.

  • Director installation command - a command executed on remote hosts in order to install Bacula Director component.

  • Director upgrade command - a command executed on remote hosts in order to upgrade Bacula Director component.

  • Director removal command - a command executed on remote hosts in order to uninstall Bacula Director component.

  • Director info command - a command executed on remote hosts that checks if Director is installed. It should return exit code 0 if the Bacula Director is installed, otherwise it should return exit code other than 0.

  • Director enable command - a command executed on remote hosts that enables the Bacula Director component to autostart after restarting the host.

  • Director pre-install command - a command executed on remote hosts before installing the Bacula Director component.

  • Director pre-upgrade command - a command executed on remote hosts before upgrading the Bacula Director component.

  • Director pre-remove command - a command executed on remote hosts before uninstalling the Bacula Director component.

  • Director post-install command - a command executed on remote hosts after installing the Bacula Director component.

  • Director post-upgrade command - a command executed on remote hosts after upgrading the Bacula Director component.

  • Director post-remove command - a command executed on remote hosts after uninstalling the Bacula Director component.

  • Storage installation command - a command executed on remote hosts in order to install the Bacula Storage component.

  • Storage upgrade command - a command executed on remote hosts in order to upgrade the Bacula Storage component.

  • Storage removal command - a command executed on remote hosts in order to uninstall the Bacula Storage component.

  • Storage info command - a command executed on remote hosts that checks if Storage is installed. It should return exit code 0 if the Bacula Storage is installed, otherwise it should return exit code other than 0.

  • Storage enable command - a command executed on remote hosts that enables the Bacula Storage component to autostart after restarting the host.

  • Storage pre-install command - a command executed on remote hosts before installing the Bacula Storage component.

  • Storage pre-upgrade command - a command executed on remote hosts before upgrading the Bacula Storage component.

  • Storage pre-remove command - a command executed on remote hosts before uninstalling the Bacula Storage component.

  • Storage post-install command - a command executed on remote hosts after installing the Bacula Storage component.

  • Storage post-upgrade command - a command executed on remote hosts after upgrading the Bacula Storage component.

  • Storage post-remove command - a command executed on remote hosts after uninstalling the Bacula Storage component.

  • Client installation command - a command executed on remote hosts in order to install the Bacula Client component.

  • Client upgrade command - a command executed on remote hosts in order to upgrade the Bacula Client component.

  • Client removal command - a command executed on remote hosts in order to uninstall the Bacula Client component.

  • Client info command - a command executed on remote hosts that checks if Client is installed. It should return exit code 0 if the Bacula Client is installed, otherwise it should return exit code other than 0.

  • Client enable command - a command executed on remote hosts that enables the Bacula Client component to autostart after restarting the host.

  • Client pre-install command - a command executed on remote hosts before installing the Bacula Client component.

  • Client pre-upgrade command - a command executed on remote hosts before upgrading the Bacula Client component.

  • Client pre-remove command - a command executed on remote hosts before uninstalling the Bacula Client component.

  • Client post-install command - a command executed on remote hosts after installing the Bacula Client component.

  • Client post-upgrade command - a command executed on remote hosts after upgrading the Bacula Client component.

  • Client post-remove command - a command executed on remote hosts after uninstalling the Bacula Client component.

  • Bconsole installation command - a command executed on remote hosts in order to install the Bacula Bconsole component.

  • Bconsole upgrade command - a command executed on remote hosts in order to upgrade the Bacula Bconsole component.

  • Bconsole removal command - a command executed on remote hosts in order to uninstall the Bacula Bconsole component.

  • Bconsole info command - a command executed on remote hosts that checks if Bconsole is installed. It should return exit code 0 if the Bacula Bconsole is installed, otherwise it should return exit code other than 0.

  • Bconsole pre-install command - a command executed on remote hosts before installing the Bacula Bconsole component.

  • Bconsole pre-upgrade command - a command executed on remote hosts before upgrading the Bacula Bconsole component.

  • Bconsole pre-remove command - a command executed on remote hosts before uninstalling the Bacula Bconsole component.

  • Bconsole post-install command - a command executed on remote hosts after installing the Bacula Bconsole component.

  • Bconsole post-upgrade command - a command executed on remote hosts after upgrading the Bacula Bconsole component.

  • Bconsole post-remove command - a command executed on remote hosts after uninstalling the Bacula Bconsole component.

Configuration#

Bacula configuration settings.

  • Use sudo - if checked then to each configuration b*json command will be added sudo at the beginning of the command. With this option during deployment will be also automatically created on new host a sudoers setting for each defined b*json command.

  • Bdirjson binary file path - a path to bdirjson program.

  • Main Director config file path - a path to the main Bacula Director configuration file. It most cases the file is named bacula-dir.conf.

  • Bsdjson binary file path - a path to bsdjson program.

  • Main Storage config file path - a path to the main Bacula Storage configuration file. Usually it is bacula-sd.conf file.

  • Bfdjson binary file path - a path to bfdjson program.

  • Main Client config file path - a path to the main Bacula Client configuration file. Usually it is bacula-fd.conf file.

  • Bbconsjson binary file path - a path to bbconsjson program.

  • Main Bconsole config file path - a path to the main Bacula Bconsole configuration file. Typically it is bconsole.conf file.

Console#

Bacula bconsole settings.

  • Use sudo - if checked then to bconsole command will be added sudo at the beginning of the command. With this option during deployment will be also automatically created on new hosts a sudoers setting for the bconsole command.

  • Bconsole binary file path - a path to the bconsole program.

  • Bconsole admin config file path - a path to the main bconsole configuration file.

Catalog#

The Bacula catalog database settings.

  • Database type - the Bacula catalog database type. Possible values: PostgreSQL, MySQL or SQLite.

  • Database name - the Bacula catalog database name.

  • Username - the database user.

  • Password - the database password.

  • IP address (or hostname) - the database server address.

  • Port - port used to connection to the database server.

  • Database path (SQLite only) - database file path.

Actions#

The Bacula component action settings.

  • Use sudo - if checked then to each action command will be added sudo at the beginning of the command. With this option during deployment will be also automatically created on new hosts a sudoers setting for each defined action command.

  • Director start command - the Bacula Director start command.

  • Director stop command - the Bacula Director stop command.

  • Director restart command - the Bacula Director restart command.

  • Storage start command - the Bacula Storage start command.

  • Storage stop command - the Bacula Storage stop command.

  • Storage restart command - the Bacula Storage restart command.

  • Client start command - the Bacula Client start command.

  • Client stop command - the Bacula Client stop command.

  • Client restart command - the Bacula Client restart command.