+

Search Tips   |   Advanced Search

Auditing invocations of wsadmin.sh

Run the following wsadmin scripts as part of the environment setup: create the cluster definition, create data sources and JMS object configuration, or install one or more EAR files that comprise the hosted software on the application server. Each of the scripts, wsadmin and non-wsadmin, need to support the ability to capture a log of the activity performed when you run the script.

To set up the application server environment, you must perform multiple tasks. For example, you must run the following non-wsadmin scripts: create the persistent session database, install the JDBC driver for the database on the system, set up MQ and create MQ queues on the system, or place PDF files in specific locations required as part of the application structure. We must also run the following wsadmin scripts as part of the environment setup: create the cluster definition, create data sources and JMS object configuration, or install one or more EAR files that comprise the hosted software on the product. Each of the scripts, wsadmin and non-wsadmin, need to support the ability to capture a log of the activity performed when you run the script. All of the logs from the scripts are written in a specific directory that archives each time we create an environment.

Each time you set up an environment, the overall process is considered a job and each job has an associated identifier. The identifier is a string that includes the date, environment name, machine name, operator, and approval code as indicated by company policy.

To examine the logs at a later time, after the environment provisioning is complete, and verify that all of the log files for the wsadmin and non-wsadmin scripts reflect the actual output of the script that you ran for a specific job, and that no other logs are mixed in with the ones from that job, perform the following steps:

  1. Start wsadmin.sh using the -jobid string, -appendTrace string, or -tracefile string option.

    Use the -tracefile option to name the logs based on the activity performed by the script to run and to locate the log files in the specific directory for the job.

    Use the -appendtrade true option to append to an existing log file, if one already exists.

    Use the -jobid option to embed an identifier within the log file so that we can validate that all of the logs were the result of the same specific provisioning activity and not some other job.

    We can change the name and location of a file. Modifying the contents of the log file can prove difficult. Also, different log files can have the same job ID and each log file needs a unique name. So the -jobid option provides an important audit and correlation function that the -tracefile option cannot provide.

    For more information about these options, see wsadmin.sh topic. For more information about starting wsadmin.sh, see the Starting the wsadmin scripting client topic.

  2. Examine the log file for the job ID that specified. Use the log files to audit or correlate wsadmin.sh.


Example

The following example outputs to the log of wsadmin.sh when you use the -jobid string parameter:


Related tasks

  • Use wsadmin scripting
  • Enable trace on client and stand-alone applications
  • Running wsadmin.sh remotely in a Java 2 Platform, Standard Edition environment
  • Start the wsadmin scripting client

  • wsadmin scripting tool