Prevent the PostInstallDBSetup utility from breaking your Siebel 20 update procedure
Each month Oracle releases a new update for Oracle Siebel CRM. In order to keep your environments up to date, it’s a good habit to automate this monthly rollout. With Siebel update 20.3, some changes were introduced in the installer of the Siebel Enterprise Server, which might result into exiting with a non-zero exit code. This might break your automated update flow, or the build of your Siebel Docker images. In this article I’ll describe the problem including a solution.
Since Siebel update 20.3, Oracle made some changes in the installation of the Siebel Enterprise Server updates. Nowadays, a new Post Install DB Setup utility is integrated in the installer. Using this utility, the Siebel database is updated in order to support the new features such as the Siebel Seamless Repository Delivery Framework. The idea behind this framework is great, but I’m not that keen on the way it’s now integrated in the software installer.
Installation vs Configuration
In order to let the Post Install DB Setup utility do its job, it requires some details about the configuration of the Siebel database including the corresponding credentials. I personally prefer to keep installation and configuration separate as much as possible. An installation should be repeatable and should preferably be independent from an environment. Configuration, on the other hand, can be rather specific and match a certain environment.
In a previous article I’ve described the advantages of running a Siebel (lab) environment in Docker. The same principles apply: a Docker Image serves as a blueprint and should primarily contain the required installation, which is independent from any environment. The environment-specific configuration on the other hand (including the Siebel deployment using the Siebel Management Console for example), can be applied later into a Docker container and stored on a persistent volume for example.
Installation response file requires database configuration
First of all, while running the installer for Siebel update 20.3 or higher, it requests several details about the Siebel database. When performing a silent installation using a response file, these database details have to be included as well. If you forget to update the response file to include these new additional fields, the software installation would fail with an error message:
However, during a fresh installation, or while creating generic Siebel Docker images, a database configuration would be irrelevant, because there is no database yet at that point in time.
Non-zero exit code while updating Siebel Enterprise Server
The Post Install DB Setup utility runs directly after the update of the Siebel software binaries has completed successfully. If the utility fails, it can always be run later on, independently from the installer itself. There is no direct harm in letting the Post Install DB Setup utility fail. However, since Oracle decided to include it in the installer. When the installer cannot reach a Siebel database, a non-zero exit code will be the result.
While automating the update procedure, or during the build of a Docker image, you want to make sure the Siebel software has been updated successfully before proceeding. Using the exit code of the installer would be most convenient and suitable for this purpose.
What’s an exit code?
An exit code is a number that identifies whether or not a command was successful. The 0 means the command was successful and a value between 1 and 255 indicates anything else. The non-zero return values differ per command and might reveal some more details about possible issues.
On Linux, you can retrieve the exit code of the last command by using the $? variable. To print it, you might use:
In most cases, the execution of next steps in an update pipeline, or the build of a Docker Image, is decided upon the exit code of the previous step. The same principle applies when chaining commands in Linux using e.g. ‘&&’. This means that the second command only runs if the first one succeeded. For example:
install_server.sh && start_server.sh
In this example, the script “start_server.sh” will only run when “install_server.sh” succeeded. Again, in order to determine if a command succeeded, the exit code will be evaluated.
Post Install DB Setup utility running per Siebel enterprise server
If you do fill out the relevant database details during the software update, you will see that the Post Install DB Setup utility will be executed on every Siebel Enterprise Server you’re upgrading (in case servers are updated individually). This is quite some overhead, because it has to be run only once per Siebel database/enterprise and not for each Siebel server individually. From that perspective it could be argued that running the Post Install DB Setup utility is actually expected to fail under certain conditions anyway, to prevent it from running on each and every server. This again results in the non-zero exit code as indicated above, possibly breaking automated follow-up actions.
Include empty database configuration in the response file
Firstly, the response file for a silent install of the Siebel enterprise server should be expanded with the variables shown in the following screenshot:
As indicated above, I want to keep the installation and configuration as much separated as possible, so I’ve left most values empty. This way, no database is being touched, and as a result, the update installer fails and exits with a non-zero exit code.
Workaround for the non-zero exit code
In order to verify if the update of the Siebel software itself succeeded, I could simply use the Linux grep-utility to search for the statement “Installation Completed Successfully” in the standard output generated by the installer. If that is found, the grep utility will return an exit code 0, providing enough certainty to proceed with the next steps. The drawback of that approach is that the standard output generated by the installer wouldn’t be shown anymore, as it’s all filtered out with grep. The only output shown, is the statement “Installation Completed Successfully”, when the installation succeeds. However, in case of a failure, there wouldn’t be any other helpful standard output shown anymore at all. Keeping the standard output intact is rather beneficial when using build tools like Jenkins and Docker, so no additional log files have to be inspected manually.
Therefore, instead of grepping the standard output, I’m validating the OraInstall log instead, in order to determine if the software update succeeded, which is written to the /tmp folder. This way the standard output is still preserved, so installation details can also still be easily viewed from within my build tools. The complete command looks like this:
grep ‘Installation Completed Successfully’ $(ls -t /tmpOraInstall* | head -n 1)
Since Siebel update 20.3, Oracle included running the Post Install DB Setup utility in the Siebel Installer. If you want to skip the database update, the installer ends with a non-zero exit code, which might break your automated update procedure, or the build of your Docker images. In this article I’ve described an easy way to override this non-zero exit code without sacrificing a reliable way to check if the installation did succeed and to preserve the installation standard output as well. Also, I feel it would be better if Oracle would separate running the Post Install DB Setup utility from the Siebel update installer.
Wij willen je graag op de hoogte houden van het nieuws rondom onze diensten die jou interesseren. Het enige wat je daar voor dient achter te laten zijn jouw mailadres en je voornaam. Vanaf dat moment zullen we je van tijd tot tijd een Ebicus update sturen.