Veritas NetBackup™ Logging Reference Guide
- Using logs- About logs
- About UNIX system logs
- About log retention in NetBackup
- About limiting the size of unified and legacy logs
- About unified logging- Gathering unified logs for NetBackup
- Types of unified logging messages
- File name format for unified logging
- Originator IDs for the entities that use unified logging
- About changing the location of unified log files
- About rolling over unified log files
- About recycling unified log files
- About using the vxlogview command to view unified logs
- About query strings used with the vxlogview command
- Examples of using vxlogview to view unified logs
- Examples of using vxlogmgr to manage unified logs
- Examples of using vxlogcfg to configure unified logs
 
- About legacy logging- UNIX client processes that use legacy logging
- PC client processes that use legacy logging
- File name format for legacy logging
- Directory names for legacy debug logs for servers
- Directory names for legacy debug logs for media and device management
- How to control the amount of information written to legacy logging files
- About limiting the size and the retention of legacy logs
- Configuring the legacy log rotation
 
- About global logging levels
- Setting retention limits for logs on clients
- Logging options with the Windows Event Viewer
- Troubleshooting error messages in the NetBackup Administration Console
 
- Backup process and logging
- Media and device processes and logging
- Restore process and logging
- Advanced Backup and Restore Features
- Storage logging
- NetBackup Deduplication logging
- OpenStorage Technology (OST) logging
- Snapshot technologies
- Locating logs- acsssi logging
- bpbackup logging
- bpbkar logging
- bpbrm logging
- bpcd logging
- bpcompatd logging
- bpdbm logging
- bpjobd logging
- bprd logging
- bprestore logging
- bptm logging
- daemon logging
- ltid logging
- nbemm logging
- nbjm logging
- nbpem logging
- nbproxy logging
- nbrb logging
- NetBackup web services logging
- NetBackup web server certificate logging
- PBX logging
- reqlib logging
- robots logging
- tar logging
- txxd and txxcd logging
- vnetd logging
 
- Java-based administration console logging- About the Java-based administration console logging
- Java-based administration console logging process flow
- Setting up a secure channel between the Java-based administration console and bpjava-*
- Setting up a secure channel between the Java-based administration console and either nbsl or nbvault
- Java-based administration console logging configuration on NetBackup servers and clients
- Java-based remote administration console logging on a Windows computer where NetBackup is not installed
- Configuring and gathering logs when troubleshooting Java GUI issues
- Undo logging
 
Setting up a secure channel between the Java-based administration console and either nbsl or nbvault
The following steps describe the process flow to set up a secure channel between the Java-based administration console and either nbsl or nbvault:
- Trust is already set up between the Java-based administration console and bpjava-*. The user information and session token already exist in a designated location with a name similar to the following: - hash(session token)_susvc_pid - See Setting up a secure channel between the Java-based administration console and bpjava-*. 
- The Java-based administration console sends a request to nbsl/nbvault for a secure connection. 
- nbsl/nbvault accepts the request and initiates a secure channel using the security certificate on the host. These daemons run with root/administrator privileges and can access the security certificate. 
- This is a one-way authenticated SSL channel where only the server certificate is present and there is no peer certificate. There is no certificate from the Java-based administration console side. 
- The trust options for the security certificate are as follows: - The Java-based administration console accepts the security certificate (or gives approval for this secure channel) if it trusts the NetBackup Certificate Authority (CA) who signed the security certificate. 
- If the Java-based administration console does not trust the CA who signed the security certificate, it displays a pop-up dialog box. This dialog box asks if the user trusts the CA who has signed the certificate (This is a one-time activity. After the user gives consent to trust the CA, the dialog box does not display again.). 
 
- The Java-based administration console sends a session token to nbsl/nbvault. See Setting up a secure channel between the Java-based administration console and bpjava-*. 
- nbsl/nbvault verifies this session token by performing the following procedure: - Generates a hash of the session token that was received 
- Searches for the file with the name that starts with this hash at the designated location 
- If the file is found, it extracts the PID from it (see step 1) 
- Checks to see if the PID is valid 
 
- The success of the verification creates a trust between nbsl/nbvault and the Java-based administration console. 
- All further communication occurs between nbsl/nbvault and the Java-based administration console on this trusted secure channel.