Use Autoconfig for common system administrator tasks

Use Autoconfig for common system administrator tasks

Autoconfig is a wonderful tool that may be extended and customized to meet a variety of needs.  One mundane task I don’t deal with anymore is scripting certain basic operating system scripts.  For example:

• Rotating logs
• Cleaning out old trace files
• Init scripts

… are all examples of cron jobs and scripts that must be created post-install.  Many DBAs have a set of scripts they use and modify, but why not use an autoconfig template to generate what you need every time

I’ll use an init script as an example.  Oracle provides adstrtal.sh and adstpall.sh for starting and stopping an apps environment; however neither of those scripts are ready to run out of /etc/init.d for system startup and shutdown.

Below is an Autoconfig template that will generate an init.d script that will call both adstrtal.sh and adstpall.sh on system startup and shutdown, respectively.  The script is designed for a RedHat Linux variant like RHEL, OEL, or CentOS.  The application version was 12.1.1.

#!/bin/bash

exit $RETVAL


To install this script, all I need to do is the following:

Place the script in a template file in my custom application top.

Create a driver that will create the script; I usually create a /tools directory for this sort of thing.

Run autoconfig to create the script.

As root, copy the script to /etc/init.d

Use chkconfig to enable auto start/stop on system boot:


$ chkconfig –-add
$ chkconfig on


That’s it!  Now every time I create a clone, I have a new init script for that node.  If a path or other dependent context value changes, I simply copy the updated script into /etc/init.d and follow the steps above.

I should note that with this script specifically, because it requires the apps password, you should probably find a better way to store and retrieve the apps password.  In this example, I put it in a file called /home/appl/.secret, which had permission bits set to 660.  That’s an “OK” solution, but not great.  The script grabs the password using a function specifically to allow minimal fuss and muss when updating the password storage and retrieval method.

Anyway, it’s pretty easy to see how one could leverage Autoconfig to create simple time-saving scripts because Autoconfig already “knows” where everything is.

Here’s an example of a script to clean up concurrent manager log and output:


#!/bin/sh

exit $?


In this example, I created 3 custom context variables:

c_conc_out_ret
c_conc_log_ret
c_inst_log_ret

Each are set to the retention period in days for their respective logs.

Installation for a script like this is even more hands-off than an init script.  Typically log cleanup scripts are called from cron and are often registered as individual crontab commands.  For this script, a single crontab entry could point to the absolute location of the script.  If the value of an environment or context variable changed at any time, running Autoconfig would automatically update the scheduled job.

Operating system maintenance plays a critical role in a well-organized, automated Apps environment; the less manual scripting there is, the less likely it is to be skipped.