Veeam plugin for Oracle RMAN and dmidecode

Veeam has a plugin for Oracle RMAN. Unfortunately this plugin encountered a slightly grumpy sysadmin who wants to keep servers secure.

the documentation

In the the official documentation they state to run the tool and it should just work. We got the following output (I’ve omitted the output after the error):

user@host:~$ ./OracleRMANConfigTool --wizard
Enter backup server name or IP address [hostname]:
Enter backup server port number [10006]:
Enter username [username]:
Enter password for username [(do not change the existing password)]:
Available backup repositories:
1. some.backup.id
Specify up to 4 Veeam repositories to use as target using whitespace as a separator [1]:
Enter the number of data streams (From 1 to 254) to run in parallel for each repository (RMAN DEVICE PARALLELISM value). Channel count per device [1]:
Do you want to use Veeam compression? (y/N):

The current user is restricted and cannot read required OS information. Please re-run the following command with root rights: OracleRMANConfigTool --set-credentials

So we tried to run the command OracleRMANConfigTool --set-credentials and it of course still did not work. Then I was provided the following error:

Error: Failed to license host: unable to get BIOS UUID with host plug-in due to lack of permissions. Use --set-credentials plug-in configuration option as root.

the binary

In theory the error is correct and yes, I don’t want to run tools with to many permissions, especially if they do not really need it (which they do not). So I took a look at the setup file:

user@host:~$ file OracleRMANConfigTool 
OracleRMANConfigTool: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 2.6.18, with debug_info, not stripped
user@host:~$ ldd OracleRMANConfigTool 
        linux-vdso.so.1 (0x00007ffc81dda000)
        libm.so.6 => /lib64/libm.so.6 (0x00007efc65d4e000)
        libc.so.6 => /lib64/libc.so.6 (0x00007efc65989000)
        /lib64/ld-linux-x86-64.so.2 (0x00007efc660d0000)

Hmmm, a binary, that’s a shame. Can’t and won’t fix proprietary software. Last thing I could try is take a look with strings. And then I found a proper hint to dmidecode:

user@host:~$ strings OracleRMANConfigTool |grep dmidecode
Failed to parse system UUID: Failed to execute 'dmidecode | grep -i uuid' command.
Failed to parse dmidecode system UUID string: %1.
Unable to get BIOS UUID from dmidecode. sysfs BIOS UUID will be used.
Different UUIDs retrieved from sysfs and dmidecode, sysfs %1 dmidecode %2
dmidecode

Uhh, wait, they want/require access to dmidecode? I’d rather not do that.

Nevertheless I tested giving the user full sudo access to dmidecode but still no dice.

the solution

Veeam support hinted towards /etc/veeamagentid. I looked that up and also found references online, but it was not in their documentation unfortunately.

Creating that file (with automation) and putting a UUID in there, fixed the issue. No unneeded elevated permissions needed for that piece of software.

Example if you want to populate the file with the systems UUID via the terminal:

root@host:~# dmidecode -t 1|grep UUID|cut -d\  -f2 > /etc/veeamagentid