There are three methods for capturing vasd debug logs, please follow the method below based on how Syslog-ng PE is being used:
Method 1 - Syslog-ng PE is already capturing all local logs and is storing them locally (no sensitive data is stored).
If Syslog-ng PE has a source set up previously to capture system() logs and has a destination set up to log those logs locally, please enable vasd debugging and provide the entire contents of the local log file as well as the text document containing the commands run with the time and date in which they were run (see Step 2 below).
Please follow the steps below and see the example that follows to see if this is the method to use:
Step 1 - Enable vasd debugging by running:
# /opt/quest/bin/vastool configure vas vasd debug-level 5
NOTE: If troubleshooting Starling 2FA issues please run this command as well.
# /opt/quest/bin/vastool configure vas starling debug-level 5
Step 2 - Reproduce the steps that had failed earlier or wait for the issue to occur again.
Please save the time and date in which the commands were run, as well as the actual commands run to reproduce the failure, in a text document.
NOTE: VASD does not need to be restarted on 4.0 and later. It will read the changes and start logging debug within 30 seconds. However, depending on the level of debugging expected and the state of the system or vasd process, a vasd restart is recommended.
Step 3 - Once the issue has been reproduced or occurred please review the local Syslog-ng log to ensure that it contains the vasd data.
Step 4 - Please copy and upload the local Syslog-ng log file to the Service Request, as well as the text document containing the commands run with the time and date in which they were run (see Step 2).
Step 5 - Disable vasd debugging by running:
# /opt/quest/bin/vastool configure vas vasd debug-level
NOTE: If you configured for Starling debug please run this command as well.
# /opt/quest/bin/vastool configure vas starling debug-level
Example Syslog-ng environment when using Method 1:
@version: 7.0
#Default configuration file for syslog-ng.
#
# For a description of syslog-ng configuration file directives, please read
# the syslog-ng Administrator's guide at:
#
# https://support.oneidentity.com/syslog-ng-premium-edition/technical-document
#
@include "scl.conf"
options {
stats_freq(0);
};
######
# sources
source s_local {
# message generated by Syslog-NG
internal();
system();
monitoring_welf();
};
######
# destinations
destination d_messages { file("/var/log/messages"); };
log {
source(s_local);
destination(d_messages);
};
Method 2 - Syslog-ng PE is already capturing all local logs, however, those logs are either not being stored locally or contain sensitive data.
If Syslog-ng PE has a source set up previously to capture system() logs, however, those logs are either not being stored locally or they contain sensitive data, start by creating a filter to capture the vasd debug logs specifically, then create a destination-specific for vasd debug logs, and lastly create a new log statement to tie everything together. Once done, please enable vasd debugging and provide the /tmp/vasd_debug.log as well as the text document containing the commands run with the time and date in which they were run (see Step 6 below).
Please follow the steps below and see the example that follows to see if this is the method to use:
Step 1 - Edit the syslog-ng.conf (or sub-config if used) to include the following filter:
filter f_vasd_debug { match("vasd" value("PROGRAM"));};
Step 2 - Create a new local destination for vasd logs:
destination d_vasd_debug { file("/tmp/vas_debug.log" create-dirs(yes));};
Step 3 - Create a new log statement including the local source collecting the system() logs to capture the vasd debug logs:
log {
source(s_example_local_logs_source);
filter(f_vasd_debug);
destination(d_vasd_debug);
};
NOTE - Please ensure this log statement is the first log statement in the list of log statements, otherwise logs may not be collected correctly.
Step 4 - Restart the Syslog-ng service to ensure the new configuration is applied:
#systemctl restart syslog-ng
Step 5 - Enable vasd debugging by running:
# /opt/quest/bin/vastool configure vas vasd debug-level 5
NOTE: If troubleshooting Starling 2FA issues please run this command as well.
# /opt/quest/bin/vastool configure vas starling debug-level 5
Step 6 - Reproduce the steps that had failed earlier or wait for the issue to occur again.
Please save the time and date in which the commands were run, as well as the actual commands run to reproduce the failure, in a text document.
NOTE: VASD does not need to be restarted on 4.0 and later. It will read the changes and start logging debug within 30 seconds. However, depending on the level of debugging expected and the state of the system or vasd process, a vasd restart is recommended.
Step 7 - Once the issue has been reproduced or occurred please review the /tmp/vasd_debug.log to ensure that it contains the vasd data.
Step 8 - Please copy and upload the /tmp/vasd_debug.log file to the Service Request, as well as the text document containing the commands run with the time and date in which they were run (see Step 6).
Step 9 - Disable vasd debugging by running:
# /opt/quest/bin/vastool configure vas vasd debug-level
NOTE: If you configured for Starling debug please run this command as well.
# /opt/quest/bin/vastool configure vas starling debug-level
Step 10 - Remove (or comment out) the changes to the Syslog-ng configuration.
Step 11 - Restart the Syslog-ng service to ensure the updated configuration is applied:
#systemctl restart syslog-ng
Example Syslog-ng environment when using Method 2:
@version: 7.0
#Default configuration file for syslog-ng.
#
# For a description of syslog-ng configuration file directives, please read
# the syslog-ng Administrator's guide at:
#
# https://support.oneidentity.com/syslog-ng-premium-edition/technical-document
#
@include "scl.conf"
options {
stats_freq(0);
};
######
# sources
source(s_example_local_logs_source);
# message generated by Syslog-NG
internal();
system();
monitoring_welf();
};
######
# filters
filter f_vasd_debug { match("vasd" value("PROGRAM"));};
######
# destinations
destination d_messages { file("/var/log/messages"); };
destination d_vasd_debug { file("/tmp/vas_debug.log" create-dirs(yes));};
log {
source(s_example_local_logs_source);
filter(f_vasd_debug);
destination(d_vasd_debug);
};
log {
source(s_example_local_logs_source);
destination(d_messages);
};
Method 3 - Syslog-ng PE is not configured to store logs locally.
If Syslog-ng PE is not configured to store logs locally, start by creating a source to capture the local system logs, then create a filter to capture the vasd debug logs, create a destination-specific for those logs, and lastly create a log statement to tie everything together. Once done, please enable vasd debugging and provide the /tmp/vasd_debug.log as well as the text document containing the commands run with the time and date in which they were run (see Step 7 below).
Please follow the steps below and see the example that follows to see if this is the method to use:
Step 1 - Edit the syslog-ng.conf (or sub-config if used) to include the following source:
source s_system { system();};
Step 2 - Edit the syslog-ng.conf (or sub-config if used) to include the following filter:
filter f_vasd_debug { match("vasd" value("PROGRAM"));};
Step 3 - Create a new local destination for vasd logs:
destination d_vasd_debug { file("/tmp/vas_debug.log" create-dirs(yes));};
Step 4 - Create a new log statement including the local source collecting the system() logs to capture the vasd debug logs:
log {
source(s_system);
filter(f_vasd_debug);
destination(d_vasd_debug);
};
NOTE - Please ensure this log statement is the first log statement in the list of log statements, otherwise logs may not be collected correctly.
Step 5 - Restart the Syslog-ng service to ensure the new configuration is applied:
#systemctl restart syslog-ng
Step 6 - Enable vasd debugging by running:
# /opt/quest/bin/vastool configure vas vasd debug-level 5
NOTE: If troubleshooting Starling 2FA issues please run this command as well.
# /opt/quest/bin/vastool configure vas starling debug-level 5
Step 7 - Reproduce the steps that had failed earlier or wait for the issue to occur again.
Please save the time and date in which the commands were run, as well as the actual commands run to reproduce the failure, in a text document.
NOTE: VASD does not need to be restarted on 4.0 and later. It will read the changes and start logging debug within 30 seconds. However, depending on the level of debugging expected and the state of the system or vasd process, a vasd restart is recommended.
Step 8 - Once the issue has been reproduced or occurred please review the /tmp/vasd_debug.log to ensure that it contains the vasd data.
Step 9 - Please copy and upload the /tmp/vasd_debug.log file to the Service Request, as well as the text document containing the commands run with the time and date in which they were run (see Step 7).
Step 10 - Disable vasd debugging by running:
# /opt/quest/bin/vastool configure vas vasd debug-level
NOTE: If you configured for Starling debug please run this command as well.
# /opt/quest/bin/vastool configure vas starling debug-level
Step 11 - Remove (or comment out) the changes to the Syslog-ng configuration.
Step 12 - Restart the Syslog-ng service to ensure the updated configuration is applied:
#systemctl restart syslog-ng
Example Syslog-ng environment when using Method 3:
@version: 7.0
#Default configuration file for syslog-ng.
#
# For a description of syslog-ng configuration file directives, please read
# the syslog-ng Administrator's guide at:
#
# https://support.oneidentity.com/syslog-ng-premium-edition/technical-document
#
@include "scl.conf"
options {
stats_freq(0);
};
######
# sources
source s_system { system();};
######
# filters
filter f_vasd_debug { match("vasd" value("PROGRAM"));};
######
# destinations
destination d_vasd_debug { file("/tmp/vas_debug.log" create-dirs(yes));};
log {
source(s_system);
filter(f_vasd_debug);
destination(d_vasd_debug);
};