FAQ
BRICK FAQ: The script displays “Out of memory”
The script might display a message “Out of memory” and dies. This can happen when the filesize of the debug.log is too big (at least 1 GB). In this case try to cycle the debug.log.
BRICK FAQ: The script cannot be started on RedHat
As the script was developed with the 32bit version of Perl (for compatibility), on RedHat systems you may receive the error: ‘/lib/ld-linux.so.2: bad ELF interpreter: No such file or directory’. In this case you may install some required libs with the command ‘yum -y install glibc.i686’ before you can use BRICK.
BRICK FAQ: The generated BRICK reports show wrong values for Data Protector 8.0 environments
The reports generated in BRICK utilize the standard Data Protector commands. As there is a bug in this version the result presented by BRICK might be wrong too. Please open a support request to get the fix. After applying the fix the advanced reports should display the correct values in reports.
BRICK FAQ: The runtime of the BRICK script is very long and seems to hang for the DNS check
In larger environments with many clients in cell or with slower DNS servers the runtime of BRICK might be higher than expected. In this case use the parameter -no_dns
to skip this specific check. This will increase the runtime of BRICK.
BRICK FAQ: The listing of the local groups is very slow and produces a large file
The root cause of this problem can be found in the WMI query used in BRICK. If nested groups are used, the WMI query walks through the AD and will no limit the search to local groups, even if specified explicitly. This will cause a very long runtime of BRICK. At the moment no solution is available, however, the mechanism to retrieve local groups will be changed with version 1.1 of BRICK and will be configurable.
BRICK FAQ: During the execution of BRICK the RDS daemon / service dies unexpectly
For the checks done by BRICK Data Protector commands are used only. The unexpected event will be accour as well when the command is used without BRICK. The problem was reproducable in a non patched DP 6.20 cell. With the installation of the current patches the problem was solved.