Every now and then you get customer requests that initially knock you off your feet — because you can tell right away: this isn’t described anywhere in the documentation. Then it’s time to truly understand the problem, clarify the requirements properly (does the problem even exist in that form, or can it be solved differently?), research internally, potentially review a feature request including the use case — and finally think about how to help the customer pragmatically in the short term: the good old “workaround” or “self-fix.”
That was the case here as well.
A customer is using the standalone Veeam Plug-in for Oracle RMAN and wants to install the Veeam plug-in — however, in the customer’s environment it is intentionally used as unmanaged. At the same time, the rollout should be automated, and no one should have to type or “expose” a password.
Die Veeam documentation refers to the option of copying the “configuration file” to other servers; however, you then have to reset the password afterwards by entering:
https://helpcenter.veeam.com/docs/vbr/userguide/import_export_plugin_settings.html?ver=13
At first glance, this sounds somewhat contradictory: unmanaged and automated deployment — is that even possible?
Unmanaged ≠ “not automatable”
In this context, “unmanaged” does not mean “not automatable,” but rather:
- no central push deployment/management as with managed setups
- configuration/registration is performed locally via a wizard
- in backup and restore scenarios you can continue using the familiar RMAN commands/workflows (the plug-in essentially integrates underneath them)
The customer explicitly need this unmanaged feature set. And yes: for Windows/Linux/Mac agents there are deployment kits that can be rolled out well via automation. But for unmanaged Oracle RMAN plug-in installations, there is no ready-made “one-click deployment kit” in that sense.
In practice, this leads to a sticking point:
On every Oracle server, a wizard (the local configuration tool) must be executed to:
- sets the VBR server
- selects the repository
- stores username + password
After execution, the information is stored encrypted — good from a security perspective, but that’s exactly where the problem lies. This encrypted file with credentials and more is not portable. You cannot simply copy the resulting configuration 1:1 to the next Oracle RMAN server and expect it to work. You have to set the user/password manually while or after you copied/created the configuration.
The real hurdle: credentials for repository access
In an unmanaged setup, it works roughly like this:
- download and install RPM packages (depending on OS / openssl + VeeamPlugin)
- open and configure the plug-in wizard:
- specify the VBR server
- select the repository
- enter username/password (the account that has access to the repository)
- the result includes, among other things, a veeam_config.xml (configuration file)
And now the customer’s security requirement:
“We don’t want the password to be known or used in plaintext in documentation or a script—but we still want a repeatable, automated installation.”
Solution idea: Ansible + XML + “set credentials” (without the wizard)
- push the RPM packages to the servers and install them using Linux tools (e.g., zypper, dnf, …)
- copy a veeam_config.xml with the appropriate configuration to the servers
- set the credentials again
This is not “magically passwordless,” but you can provide the password either:
- by prompting for it at runtime (prompt)
or - via Ansible Vault
This prevents password leakage and still allows automated installation across all servers.
Example: Ansible playbook (prompt-based)
1) Install Ansible
dnf install -y ansible-core2) Inventory (local or target host(s))
inventory.ini
127.0.0.1 ansible_connection=local3) Ansible playbook
test_playbook.yml
- name: Configure Veeam Oracle Pluginhosts: allvars_prompt:- name: usernameprompt: What is your VBR username?private: false- name: passwordprompt: What is your VBR password?tasks:- name: Creating a veeam_config.xml with contentcopy:dest: "/opt/veeam/VeeamPluginforOracleRMAN/veeam_config.xml"content: |<Config><CAVerificationParameters /><AdditionalCertificatePaths /><ProxyConfig /><VBRConnectionParams vbrHostName="10.10.10.42" /><Certificate /><AuthenticationContext /><EntitySpecificCertificates /><BackupForRestoreParams /><AgentParams /><RepositoryParams><Repository repositoryName="Default Backup Repository" repositoryID="123456-abc5-4ab4-dd4f-9c31234bcead" /></RepositoryParams><PluginParameters /></Config>- name: Set the Veeam User and Passwordansible.builtin.expect:command: OracleRMANConfigTool --set-credentials {{ username }} --disable-fingerprint-confirmationresponses:"Enter password for veeamadmin:":- "{{ password }}"
Better for security: don’t type the password—pull it from Vault
Instead of vars_prompt, you can use for example:
vars_fileswith Ansible Vaultvars_files: - group_vars/all/vault.yml
or use an integration with your preferred secret manager
Important: even then, the password obviously “exists” somewhere — but not as plaintext in docs/chat/scripts.
What you gain (and what you don’t)
Benefits
- no need to run the wizard manually → reproducible & automatable
- credentials are not exposed
- integrates nicely with Linux tooling (RPM deployment and Ansible playbook)
Limitations
- “without password entry” means: without manual typing, not “without a secret”
- you still need to clarify properly:
- which VBR user is minimally required
- how secrets are stored/rotated
- who has access to the Vault/runner
Links:
Veeam Plug-In for Oracle RMAN
https://helpcenter.veeam.com/docs/vbr/userguide/rman_plugin.html?ver=13
Deployment and Configuration Standalone Veeam Plug-Ins for Oracle RMAN
https://helpcenter.veeam.com/docs/vbr/userguide/rman_plugin_deployment.html?ver=13
Red Hat Ansible Automation
https://www.redhat.com/de/technologies/management/ansible
