Oracle® Enterprise Manager Configuration Change Console Installation Guide 10g Version 10.2.0.4 for Windows or UNIX Part Number E12914-02 |
|
|
PDF · Mobi · ePub |
This section outlines the steps to install an agent on Unix. There are also sections later in this book that relate to specific requirements for certain operating systems. Please be sure to review those sections as well.
The following sections describe the process for installing the UNIX agents in console or graphical mode. Some operating systems have specific steps you must follow in addition to the standard Unix installation steps.
At any point during a console-based installation process, to return to the previous prompt, type Back.
To install the agents, you must log in as root. Later when the agent is running, it can run as any user as long as specific steps are followed as discussed later in this chapter.
Copy the agent-x.bin file from the Configuration Change Console Installation media where -x will indicate which operating system the agent installer is for.
Ensure that the file is executable by using the following command where <agent executable> is the installation file for the specific platform:
chmod +x <agent executable>
For example: chmod +x agent -lin.bin
For the Linux installation agent there are rules that must be followed that are specifc to Linux. Be sure to review Linux-based chapters.
From the Configuration Change Console Installation media, type the following command where <agent executable> is the installation file for the specific platform listed in the table above.
To run the installer from the command line:
./<agent executable> -i console
To run the installer under X with a graphics-based installer:
./<agentexecutable>
An introduction screen appears. Press Enter to proceed.
You will next be prompted for the agent installation directory.
Press Enter to accept the default installation directory or enter your own path for installation.
Enter the Configuration Change Console server URL. The URL has the format t3s://hostname:port where hostname is the host the primary server is located at if using a non-clustered environment. The Port is the HTTPS port of that server (default was 443 during server installation). If you are using a clustered environment, use t3s://hostname1:port1,hostname2:port2,hostname3:port3, etc where you put host name and port for each server (primary and secondary). Click Next.
The next section asks if you want to automatically start the agent after installation or not. To automatically start the agent after the installation, press Enter. If you do not want the agent to start automatically, enter 2. Press Enter. You will need to start the agent manually if you do not set it to start automatically. Instructions for starting the agent using \etc\init.d\arprobe are discussed later in this chapter.
You will be asked for an administrator user name (default is administrator) for the Configuratioin Change Console Server. This is used to verify that the person installing the agent is authorized to do so.
The Summary screen will display. Verify that the install folder is correct and then click Install to proceed with the installation.
Click Done when the Installation Complete screen appears to exit the installer.
The agent should start automatically if you chose to have it start during installation. In the event that it does not, from the command prompt type the following commands:
cd /etc/init.d/
./arprobe start
To stop the agent, type: ./arprobe stop
Note:
You must be the root user to start the agent unless you follow the steps below on setting up the agent to operate as a non-root user.You must log in as root to uninstall the agent. The manual steps to uninstall the agent are:
From the command prompt, go to the agent uninstaller directory. For example, if you installed as root, you would type:
cd /root/oracle/ConfigurationChangeConsoleAgent/UninstallerData
Run the uninstaller by typing:
./Uninstall_Configuration_Change_Console_Agent
By default, agents are expected to run as the root user on Unix. You can configure the agents however after installation to run as a non-root user following the steps outlined below.
File Permissions
The first thing that needs to be changed are the file ownership for the agent files. The installer sets all files and directories for the agent to be owned by root (the user doing the install) and permissions are turned off completely for GROUP and OTHER USERS. If another user should see these files, then ownership of the files and directories must be changed from root to the desired owning user. The following is an example of how you change this, where you replace newuser with the login name of the user that will own the agent and change {agent_install_dir} to the full path of where the agent is installed:
chown -R newuser {agent_install_dir}
It is not recommended that you add permissions for the GROUP or OTHER USERS to see the files as they have secure information in these directories.
Set Binaries to Run
Two binaries that come with the agent need elevated priviledges to run to collect needed data. To allow this, do the following:
Stop the agent if it is running
Change your directory to {agent_install_dir}/bin where you installed the agent.
Run the following commands:
chown root filewatcha
chown root filewatchp
chmod a+s filewatcha
chmod a+s filewatchp
Edit the file /etc/rc.d/init.d/arprobe and replace every instance of $PROBE_HOME/bin/probe
with sudo -u newuser "$PROBE_HOME/bin/probe"
.
Start the agent. At this point, the agent should be running as user newuser.
The following sections describe the procedure for installing the Linux agent.
Before installing the Linux Agent you must have the Kernel Development package installed. The Kernel Development package is required because a loadable kernel module is compiled at installation time.
To install the Linux Agent, follow these steps. Note that all standard and recent packages must be installed before installing the agent.
Open a terminal window on the managed server. You must be logged in as root.
Insert the Configuration Change Console Installation media into your CD Rom drive. Mount the disk.
At the prompt, copy the agent-lin.bin file from the CD to the tmp directory with the following command where /mnt/cdrom is the path to the mounted cd:
cp /mnt/cdrom/agent-lin.* /tmp
Change directory to the temp directory by entering the command cd /tmp
at the prompt
You will need to change the agent-lin.bin filename to match your version of Linux.
The following names should be used for Redhat Linux. For Oracle Enterprise Linux, rename to the same target name based on which Redhat Linux kernel matches the Oracle Enterprise Linux kernel to which you are deploying:
RedHat Linux v3: agent-lin-v3.bin
RedHat Linux v4: agent-lin-v4.bin
RedHat Linux v7.3: agent-lin-73.bin
From the temp directory, rename the file with the following command where versionFileName is the corresponding filename listed above:
mv agent-lin.bin versionFileName
Run the new file by entering the following command at the prompt, where versionFileName is the new filename you renamed agent-lin.bin to:
./versionFileName -i console
If you want to launch the graphical installer, leave off the -i console switch.
The installer may take a few moments to load. Once ready, the introduction screen will display. The installation screens are the same that you see in this installation guide for Windows and for Unix above. Please refer to the Windows installation section for a walk-through of the screens you will configure.
One additional step that occurs towards the end of installation is the compilation of a loadable kernel module that is for real time file monitoring. You may notice a status message as to whether this succeeded or not.
After installation, delete the installation files in the tmp directory with the command:
rm -i agent-lin*
Change directory to /root/oracle/ConfigurationChangeConsoleAgent/bin
At the prompt enter: ./compmod.sh
If you get a message during installation that compiling native audit modules failed, or if you are unable to get file events reported back to the server, compilation of the Linux auditing kernel module may have failed.
You can confirm if the auditmodule was loaded properly by running the following command.
grep -i auditmodule /proc/modules
If you do not get any output, then the auditmodule is not loaded and the agent will not be able to do real time file monitoring.
You can attempt to force the audit module to rebuild by following these steps:
Open a shell and change to the directory where you installed the agent, for example, /root/oracle/ConfigurationChangeConsoleAgent/bin
At the prompt enter ./compmod.sh
Look at the make.log file and see if there are any errors that might be resolvable
If the module still is not able to load, and if you need to contact Oracle support about the issue, please be sure to include your make.log file and the output of the following command with your support ticket:
uname -a
This information will help Oracle to determine if the agent's real time file monitoring audit module can be built on your environment.
Use the following steps to install the Solaris agent:
At the command prompt, log on to the Managed Server. You must be logged in as root.
From the Configuration Change Console Installation CD sent with the application, verify that the agent-sol.bin file is an executable, by typing:
chmod +x probe.bin
For the remainder of the installation instructions, refer to the UNIX Agent Installation: Console Mode section, starting with Step 2.
The agent should start automatically. In the event that it does not, from the command prompt, type the following commands:
cd /etc/init.d/
./arprobe start
Note:
To stop the probe, type:./arprobe stop
The Solaris Audit is part of the Solaris TM SHIELD Basic Security Model (BSM) which provides additional security features. Auditing allows system administrators to monitor events and to detect user account logins and logouts as well as file changes.
If auditing is already enabled on the server, simply verify that the audit system configuration matches the configurations detailed below.
The audit file can be configured to include specific events. The /etc/security/audit_control file controls which events will be included in the audit file. This section summarizes the configuration; for further details, refer to the Sun Product Online Documentation site.
For FileRunning/Userrunning, the flags line in the file /etc/security/audit_control should be set as follows:
flags: +fw,+fc,+fd,+lo
This configuration enables success/fail auditing for file writes (fw), file creates (fc), file deletes (fd), and login/logout events (lo); where '+' means to only log successful events. The login/logout events are not used by FileRunning but will be used by UserRunning. FileRunning filters the events by throwing away failed events and files that do not match the include/exclude criteria. However, if you are interested in logging the failed events as well, remove the "+" sign before each event in the flag.
The audit_control file also has entries to control where the audit logs are stored, and the maximum amount of disk space used by the audit system. The minimum requirement for FileRunning is approximately 5 minutes worth of data stored on the hard drive or the configured reporting interval time.
The audit_user file controls which users are being audited. The settings in this file are for specific users and override the settings in the audit_control file, which applies to all users.
FileRunning only reads the audit logs; it does not delete the logs. This might flood the system with log files and prevent it from logging additional events. To manage and delete old audit events while maintaining minimum FileRunnning/UserRunning requirements, do the following:
The auditing policy can be set to automatically drop new events (keeping only a count of the dropped events) rather than suspending all processes by running the following command:
# auditconfig -setpolicy cnt
Run the following command to force the audit deamon to close the current audit log file and use a new log file.
/usr/sbin/audit -s
Run the following command to merge all existing closed auditing log files into a single file with an extension of .trash and then delete the files.
/usr/sbin/auditreduce -D trash
Run the crontab command to periodically run the commands in Step 2 and Step 3 above. The frequency at which these two commands are run can be adjusted based on the anticipated event volume and the amount of disk space allocated to auditing. The only requirement is that the time between the audit -s command and the auditreduce - D trash command is at least 2 minutes times the reporting interval for FileRunning and UserRunning.
You must log in as root to uninstall the agent. To manually uninstall the agent, follow these steps:
From the command prompt, go to the agent uninstaller directory. For example, if you installed as root, you would type:
cd /root/oracle/ConfigurationChangeConsoleAgent/bin
Run the uninstaller by typing
./Uninstall_Configuration_Change_Console_Agent
The agent keeps logs of all failures or other application specific events to the Application Log. To view the logs:
Go to Start --> Settings --> Control Panel--> Administrative Tools --> Event Viewer
Click Application Log to view the logs. The product logs are located in the agent installation directory under the logs directory. For example, c:\oracle\ConfigurationChangeConsoleAgent\logs. Here is a list of some of the most common logs that you may need to refer to resolve issues:
Probe.log -- General product log for warnings or critical messages
Probe-err.log -- Only the errors that have caused a problem on the agent
If for some reason the authorization credentials that you supply at agent installation time are incorrect, you can manually force the authorization to run again. You may notice that authorization might have failed because the agent never registered with the server by looking at the Administration > Devices > Devices screen on the Server.
To force reauthorization, follow these steps:
Open a DOS window
Change your directory to {agent_install_dir}/bin
Run the script: resetauth.bat
Answer the prompts providing a user name and password for an administrator-role user in the Configuration Change Console Server
For security reasons, if authentication fails, no message is sent back to the agent indicating this failure.
This section describes the procedure for installing the agent on an HP-UX server. The Configuration Change Console Agent currently supports only HP-UX Version 11.11 and 11.23. Please read the prerequisites carefully to obtain the necessary software and patches before you begin the installation.
The HP-UX agent collects and reports data related to file and process changes, system resource utilization, and server configuration. By default, agents on the HP-UX platform do not report the users associated with file changes unless the Intrusion Detection System (HIDS) application is installed on the system. HIDS provides an auditing feature that logs file changes and the users associated with these reported changes.
The Configuration Change Console agent Supports HIDS 2.2 only. If you intend to install HIDS, you must be running HP-UX 11.11i or higher. HP-UX 11.0 is no longer supported.
This document provides basic instructions from the HIDS section of the HP-UX HIDS System Administrator's Guide.
This section describes the prerequisites for installing the HP-UX agent, including all required patches.
Table 9-3 HP Java Runtime Patches
HP-UX 11i v1 Patches |
---|
PHKL_25367 Solves kernel thread priority inversion problems. |
PHCO_25452 Solves libc problems that cause degradation in Java applications. |
PHKL_25614 Solves several memory and thread problems that affect Java performance. |
PHKL_25728 Solves hangs in Java apps with large numbers of threads. |
PHKL_25729 Solves signal and thread problems that prevent thread cancellation. |
PHKL_25840 Solves severe thread performance problems in Java apps with large numbers of threads. |
PHKL_25871 Supports Solaris-like semantics for concurrent close (kernel_dscrpt). |
PHKL_27091 Solves thread problems that degrade Java apps with large numbers of threads. |
PHKL_28489 Solves kernel trap handler problem causing hang after fork(). |
PHNE_29887 Supports Solaris-like semantics for concurrent close (transport). |
PHCO_29960 Solves pthread synchronization causing hangs. This patch MUST be installed for JRE version 1.3.1.11 or later. |
PHSS_30049 Solves problem with dld while loading native libraries for class ServerSocket |
HIDS auditing features works with the Configuration Change Console agent to provide a list of usernames associated with unauthorized access to files as well as file events such as the addition, creation, modification, and deletion of files.
Agents on the HP-UX platform do not report the users associated with any file changes unless the Intrusion Detection System (HIDS) application is installed and configured on the system.
The HIDS 2.2 application must be installed before the agent is installed. The HIDS 2.2 application requires patches specific to each supported HP-UX version. For basic prerequisites, see those documented in the Prerequisites section above.
The directory structure for the HIDS 2.2 application is as follows:
IDS application files: /opt/ids
Configuration files: /etc/opt/ids
Log files: /var/opt/ids
Refer to the HIDS 2.2 documentation, http://www.docs.hp.com/en/J5083-90011/index.html, for installation and configuration instructions for your HP-UX version.
Before proceeding with the installation, verify that you have all required patches installed on the system, as documented in the Prerequisites section above. All references to hostname must be replaced by the actual server hostname as provided by your System Administrator.
Follow these steps:
From the command prompt, login as root
Type the following commands:
mkdir /var/depot <Enter>
mkdir /var/depot/ids_11.i_admin+agent <Enter>
mkdir /var/tmp/idspatch_11.i <Enter>
mkdir /var/tmp/idsprod <Enter>
Copy the following patch into the /idspatch_11.i directory:
PHKL_26074 s700_800 11.11 libaudit.a cumulative patch
Note:
HP-UX 11i v1.6 and 11i v2 do not need this patch.Unpack the patch file sets into their separate depots:
sh -c 'for i in /var/tmp/idspatch_11.i/PH*; do sh $i; done'
Copy the patch depots into the ids_11.i_admin+agent depot by typing the following command in one line:
sh -c 'for i in /var/tmp/idspatch_11.i/PH*.depot; do swcopy -s $i \* @ /var/depot/ids_11.i_admin+agent; done'
Download the 11.i IDS product depot into the following directory:
var/tmp/idsprod/J5083AA_11.i.depot
Copy the entire 11.i product into the ids_11.i_admin+agent depot:
swcopy -s /var/tmp/idsprod/J5083AA_11.i.depot \* \@ /var/depot/ids_11.i_admin+agent
Install the IDS software by typing the following command. Note that you must reboot the system after the installation.
# swinstall -x autoreboot=true -s hostname:/var/depot/ids_11.i_admin+agent \*
Note:
To start IDS, run the command:/sbin/init.d/idsagent start
To stop IDS, run the command: /sbin/init.d/idsagent stop
This section documents the required procedural steps to complete after having installed the HIDS application on the server:
After the system has rebooted, run the IDS_checkInstall script to verify the HIDS application installation.
/opt/ids/bin/IDS_checkInstall
Log in as user ids and generate the administrator keys by typing the following at the command prompt:
./IDS_genAdminKeys install
Generate the keys for the agent by typing the following at the command prompt:
./IDS_genAgentCerts
When prompted for which hosts the keys will be generated, type the hostname:
The key file will be located in: /var/opt/ids/tmp/hostname.tar.Z
Install the agent key by typing the following command:
./IDS_importAgentKeys /var/opt/ids/tmp/hostname.tar.Z hostname
Start the agent program by typing the following command:
/opt/ids/bin/idsagent
HIDS log files increase rapidly; however, the Configuration Change Console agent keeps log files truncated to save disk space. To ensure that the log files do not increase in file size while the agent is not running, run a script to periodically truncate the HIDS log files.
A sample script to manage your log files is provided below. You may want to customize the script according to your environment. This script should be run from the crontab and the trunclog.sh should be an executable file.
Sample contents of the trunclog.sh file:
#!/bin/sh filesize=`/bin/ls -l /var/opt/ids/alert.log | /bin/awk '{print $5}'` if [ "$filesize" -gt "5000000" ] then rm /var/opt/ids/alert.log fi rm /var/opt/ids/ids_1*
Sample entry to configure the crontab to run every hour where the bold letters are replaced by the actual path of the trunclog.sh file:
0 * * * * /<location of script>/trunclog.sh
.
Refer to the UNIX Agent Installation: Console Mode section for instructions on installing the HP-UX agent.
The agent should start automatically. In the event that it does not, from the command prompt, type the following commands:
cd /etc/init.d/
./arprobe start
To stop the agent, type: ./arprobe stop
You must log in as root to uninstall the agent. To uninstall the agent manually, follow these steps:
From the command prompt, go to the agent uninstaller directory. For example, if you installed by root, you would type:
cd /root/oracle/Configuration_Change_Console_Agent
Run the uninstaller by typing:
./Uninstall_Configuration_Change_Console_Agent
The agent keeps logs of all failures or other application specific events to the Application Log. To view the logs:
Go to Start --> Settings --> Control Panel--> Administrative Tools --> Event Viewer
Click Application Log to view the logs. The product logs are located in the agent installation directory under the logs directory. For example, c:\oracle\ConfigurationChangeConsoleAgent\logs. Here is a list of some of the most common logs that you may need to refer to resolve issues:
Probe.log -- General product log for warnings or critical messages
Probe-err.log -- Only the errors that have caused a problem on the agent
If for some reason the authorization credentials that you supply at agent installation time are incorrect, you can manually force the authorization to run again. You may notice that authorization might have failed because the agent never registered with the server by looking at the Administration > Devices > Devices screen on the Server.
To force reauthorization, follow these steps:
Open a DOS window
Change your directory to {agent_install_dir}/bin
Run the script: resetauth.bat
Answer the prompts providing a user name and password for an administrator-role user in the Configuration Change Console Server
For security reasons, if authentication fails, no message is sent back to the agent indicating this failure.
The following section describes the installation process for installing AIX agents.
To improve system performance, install the AIX 5.1 maintenance package ML510008 or higher before installing the AIX 5.1 agent. The maintenance package is available from the following site: http://www-1.ibm.com/support/docview.wss?uid=isg1IY70781
Refer to the UNIX Agent Installation: Console Mode section for instructions on installing, configuring and uninstalling the AIX agent.
The AIX auditing subsystem allows an administrator to record security-relevant information, such as User Logins, Logouts, and file changes, for analysis against existing security policies and detection of security violations.
Setting up Auditing involves modification of the existing auditing configuration files. To set up auditing:
Log into the AIX machine as the root user.
Open a terminal window and change directory to /etc/security/audit
Open the config file in vi.
Locate the following sections, and update or add the listed values:
start: binmode = off streammode = on … classes: … filewatch = PROC_Create,PROC_Delete,FILE_Open,FILE_Write,FILE_Close,FILE_Link,FILE_Unlink,FILE_Rename,FILE_Owner,FILE_Mode,FILE_Fchmod,FILE_Fchown,FS_Chdir,FS_Fchdir,FS_Chroot,FS_Mkdir,FS_Rmdir,FILE_Symlink,FILE_Dupfd,FILE_Mknod,FILE_Utimes users: root = filewatch default = filewatch
Note:
In this case default refers to all users that are not root. Further note that the last line of the config file should be a blank line.Save your modifications and edit vi.
In the same directory (/etc/security/audit/) open the file streamcmds in vi.
Clear all text from the file. The default configuration for this file is not necessary, as the FileRunning agent module will operate as a direct audit reader. Clearing the file helps to reduce CPU usage and improve overall auditing performance.
Save the file and exit vi.
At the terminal prompt, enter the following command to initialize Auditing at system startup:
mkitab "audit:2:once:/usr/sbin/audit start"
Certain agent modules may require extra configuration be done on the machine where the AIX agent is installed.
The InformixAuditMonitor agent module requires Audit Masks to be configured on the machine on which the AIX agent is installed. To configure audit masks, follow these steps:
Log into the AIX machine as the root user.
Open a terminal window and change directory to $activereasoningprobe/bin where activereasoningprobe is the directory in which the AIX agent is installed.
Open the ifxaudits file in vi.
Update the following values:
INFORMIXDIR - The installation directory of the Informix database.
INFORMIXSERVER - The Informix Database server name
ONCONFIG - the location of the Informix onconfig file.
Save the file and exit vi.
Open the file ifxauditconf in vi.
Modify the events associations for the following event masks, located at the bottom of the ifxauditconf file, as needed:
DEFAULTMASK - Events to monitor by default.
REQUIREMASK - Events which must be audited.
EXCLUDEMASK - Events to exclude from auditing.
Each audit mask can have its member event and event groups modified to suit your needs. Similarly you can also modify the membership of an event group that is included in an audit mask. Note that multiple events and event groups are separated by commas.
The full list of audit configuration settings, as found within the ifxauditconf file, is reprinted in the next section.
Optionally, you can create audit masks for specific users by adding lines in the following format where user is the username the event mask is intended for, and events are a list of the individual event mnemonics or event groups, separated by commas:
./ifxaudits -a -u <user> <events>
When finished editing, save the file and exit vi.
Run the modified ifxauditconf file to create the audit masks by entering the following at the terminal prompt:
./ifxauditconf
You will now use the modified ifxaudits file to configure the Informix Audit settings. At the terminal prompt, enter the following two commands:
./ifxaudits -e 0
./ifxaudits -l 7 -p /home/informix/aaodir
Where /home/informix is the directory of your Informix installation.
You can specify events that you want to audit in an audit mask. Auditing in Dynamic Server is based on audit events and audit masks. Each audit mask can have its own set of Audit Events to detect. The table below lists the four basic types of audit masks configurable in the ifxauditconf file:
Mask Type | Mask Name |
---|---|
Individual user masks | Username |
Default mask | _default |
Compulsory masks | _require and _exclude |
Template masks | _maskname |
The following table lists the audit events you can choose to include in, or exclude from monitoring, along with the mnemonic used to specify them in the ifxauditconf file. Audit events are defined as database server activities that can be used to alter or query data or be used to possibly reveal the auditing configuration.
Mnemonic | Event Name |
---|---|
ACTB |
Access Table |
ADCK |
Add Chunk |
ADLG |
Add Transaction Log |
ALFR |
Alter Fragment |
ALIX |
Alter Index |
ALOP |
Alter Optical Cluster |
ALTB |
Alter Table |
BGTX |
Begin Transaction |
CLDB |
Close Database |
CMTX |
Commit Transaction |
CRAM |
Create Audit Mask |
CRBS |
Create Storage Space |
CRDB |
Create Database |
CRDS |
Create Dbspace |
CRIX |
Create Index |
CROP |
Create Optical Cluster |
CRRL |
Create Role |
CRSN |
Create Synonym |
CRSP |
Create Stored Procedure |
CRTB |
Create Table |
CRTR |
Create Trigger |
CRVW |
Create View |
DLRW |
Delete Row |
DNCK |
Bring Chunk Off-line |
DNDM |
Disable Disk Mirroring |
DRAM |
Delete Audit Mask |
DRBS |
Drop Storage Space |
DRCK |
Drop Chunk |
DRDB |
Drop Database |
DRDS |
Drop Dbspace |
DRIX |
Drop Index |
DRLG |
Drop Transaction Log |
DROP |
Drop Optical Cluster |
DRRL |
Drop Role |
DRSN |
Drop Synonym |
DRSP |
Drop Stored Procedure |
DRTB |
Drop Table |
DRTR |
Drop Trigger |
DRVW |
Drop View |
EXSP |
Execute Stored Procedure |
GRDB |
Grant Database Access |
GRFR |
Grant Fragment Access |
GRRL |
Grant Role |
GRTB |
Grant Table Access |
INRW |
Insert Row |
LGDB |
Change Database Log Mode |
LKTB |
Lock Table |
LSAM |
List Audit Masks |
LSDB |
List Databases |
MDLG |
Modify Transaction Logging |
ONAU |
onaudit |
ONCH |
oncheck |
ONIN |
oninit |
ONLG |
onlog |
ONLO |
onload |
ONMN |
onmonitor |
ONMO |
onmode |
ONPA |
onparams |
ONSP |
onspaces |
ONST |
onstat |
ONTP |
ontape |
ONUL |
onunload |
OPDB |
Open Database |
RDRW |
Read Row |
RLOP |
Release Optical Cluster |
RLTX |
Rollback Transaction |
RMCK |
Clear Mirrored Chunks |
RNDB |
Rename Database |
RNTX |
Rename Table/Column |
RSOP |
Reserve Optical Cluster |
RVDB |
Revoke Database Access |
RVFR |
Revoke Fragment Access |
RVRL |
Revoke Role |
RVTB |
Revoke Table Access |
SCSP |
System Command Stored Procedure |
STCN |
Set Constraint |
STDF |
Set Debug File |
STDP |
Set Dabase Password |
STDS |
Set Dataskip |
STEX |
Set Explain |
STIL |
Set Isolation Level |
STLM |
Set Lock Mode |
STOM |
Set Object Mode |
STOP |
Stop Statement |
STPR |
Set Pdqpriority |
STRL |
Set Role |
STRT |
Start Statement |
STSA |
Set Session Authorization |
STSN |
Start New Session |
STTX |
Set Transaction Mode |
TMOP |
Time Optical Cluster |
ULTB |
Unlock Table |
UPAM |
Update Audit Mask |
UPCK |
Bring Chunk On-line |
UPDM |
Enable Disk Mirroring |
UPRW |
Update Current Row |
USSP |
Update Statistics Stored Procedure |
USTB |
Update Statistics Table |
The agent keeps logs of all failures or other application specific events to the Application Log. To view the logs:
Go to Start --> Settings --> Control Panel--> Administrative Tools --> Event Viewer
Click Application Log to view the logs. The product logs are located in the agent installation directory under the logs directory. For example, c:\oracle\ConfigurationChangeConsoleAgent\logs. Here is a list of some of the most common logs that you may need to refer to resolve issues:
Probe.log -- General product log for warnings or critical messages
Probe-err.log -- Only the errors that have caused a problem on the agent
If for some reason the authorization credentials that you supply at agent installation time are incorrect, you can manually force the authorization to run again. You may notice that authorization might have failed because the agent never registered with the server by looking at the Administration > Devices > Devices screen on the Server.
To force reauthorization, follow these steps:
Open a DOS window
Change your directory to {agent_install_dir}/bin
Run the script: resetauth.bat
Answer the prompts providing a user name and password for an administrator-role user in the Configuration Change Console Server
For security reasons, if authentication fails, no message is sent back to the agent indicating this failure.