Auditing invocations of the wsadmin tool using 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 running the script.
To set up the application server environment, we must perform multiple tasks. For example, 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 running 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 we 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...
Tasks
- Start the wsadmin tool 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 the wsadmin tool topic. For more information about starting the wsadmin tool, see the Starting the wsadmin scripting client topic.
- Examine the log file for the job ID specified. Use the log files to audit or correlate the wsadmin tool.
Example
The following example outputs to the log of the wsadmin tool when using the -jobid string parameter:
[5/16/05 15:45:49:449 CDT] 0000000a AbstractShell A JobID= scriptTest1
Use wsadmin scripting Enable trace on client and stand-alone applications Running the wsadmin tool remotely in a Java 2 Platform, Standard Edition environment Start the wsadmin scripting client wsadmin scripting tool