Logging

EPM-UL has a flexible logging capability that enables you to control what is logged, when, and where. There are four types of logs:

• Event logs
• I/O logs (sometimes called session logs)
• Diagnostic logs
• Debug trace logs

Event logs

Event logs are produced by default and record the following information:

• Accept and Reject status
• The user’s pbrun environment when an attempt is made to run pbrun
• Keystroke action events
• Task status (if task finished successfully or unsuccessfully)

Starting with v10.3.0, the event log can be a flat file, a local SQLite database, or sent to an external Oracle or MySQL database.

📘

For more information, see Auditing and Logging.

Example of event log entries

The output from a pblog session that simply reads the event log is:

Accept 2018/09/20 11:37:57 chris@sparky -> chris@sparky
kill -9 570
Command finished with exit status 0
Accept 2018/09/20 11:38:09 chris@sparky -> chris@sparky
ls /export/home
Command finished with exit status 0
Reject 2018/09/20 11:37:39 chris@sparky
umount

Read verbose event log entries

Example

Given the following simple policy:

/* This is a test */
if (user == "sandy")
reject;

The output when pblog -l is run is as follows:

Reject 2010/06/23 11:33:34 [email protected] by [email protected]
ls
Request rejected by pbmasterd on octopus.company.com.

argc = 1
argv = {"ls"} bkgd = 0
clienthost = "octopus.company.com" 
command = "ls"
cwd = "/var/log" 
date = "2010/06/23"

day = 23 dayname = "Wed"
env = {"LANG=C", "PATH=.:/usr/local/bin", "EDITOR=vi", "LOGNAME=sandy", "MAIL=/var/mail/sandy", "TERM=dtterm", "USER=sandy"}
event = "Reject"
eventlog = "/var/log/pb.eventlog"
exitstatus = "Request rejected by pbmasterd on octopus.company.com.[a]" false = 0
group = "uts" groups = {"uts"}
host = "octopus.company.com" hour = 11
i18n_date = "06/23/10" i18n_day = "23"
i18n_dayname = "Wed" i18n_hour = "11"
i18n_minute = "33"
i18n_month = "06"
i18n_time = "11:33:34"
i18n_year = "2010" iolog = ""
lineinfile = "/opt/pbul/policies/pb.conf"
linenum = "1"
localmode = 0
lognopassword = 1
logport = "32224" logservers = {"sandy"} 
logstderr = 1
logstdin = 1
logstdout = 1
masterhost = "octopus.company.com"
masterlocale = "C"
minute = 33
month = 6
nice = 0 optarg = "" 
opterr = 1
optimizedrunmode = 1
optind = 1
optopt = "" 
optreset = 1
optstrictparameters = 1 
pbclientmode = "run" 
pbclientname = "pbrun" 
pblogdmachine = "i686" 
pblogdnodename = "sandy"
pblogdrelease = "2.6.22.5-31-default" 
pblogdsysname = "Linux"
pblogdversion = "#1 SMP 2007/09/21 22:29:00 UTC" 
pbmasterdmachine = "i686"
pbmasterdnodename = "sandy" 
pbmasterdrelease = "2.6.22.5-31-default" 
pbmasterdsysname = "Linux"
pbmasterdversion = "#1 SMP 2007/09/21 22:29:00 UTC" 
pbrunmachine = "i686"
pbrunnodename = "sandy"
pbrunrelease = "2.6.22.5-31-default"
pbrunsysname = "Linux"
pbrunversion = "#1 SMP 2007/09/21 22:29:00 UTC" 
pbversion = "6.1.0-15"
pid = 18511
psmcmapid = "7f0000024c22537e484D" 
ptyflags = 7
rejectnullpasswords = 0 requestuser = "sandy" rlimit_as = -977616896
rlimit_core = 0
rlimit_cpu = -1
rlimit_data = -1
rlimit_fsize = -1
rlimit_locks = -1
rlimit_memlock = 32768
rlimit_nofile = 1024
rlimit_nproc = 15349
rlimit_rss = 1692928000
rlimit_stack = 8388608 
runargv = {"ls"}
runbkgd = 0
runcommand = "ls" 
runcwd = "/var/log" 
runenablerlimits = 0
runenv = {"LANG=C", "PATH=.:/usr/local/bin", "EDITOR=vi", "LOGNAME=sandy", "MAIL=/var/mail/sandy", "TERM=dtterm", "USER=sandy"}
rungroup = "sandy"
rungroups = {"sandy", "amanda"} 
runhost = "octopus.company.com" 
runlocalmode = 0
runnice = 0
runoptimizedrunmode = 1
runptyflags = 7
runrlimit_as = -977616896
runrlimit_core = 0
runrlimit_cpu = -1
runrlimit_data = -1
runrlimit_fsize = -1
runrlimit_locks = -1
runrlimit_memlock = 32768
runrlimit_nofile = 1024
runrlimit_nproc = 15349
runrlimit_rss = 1692928000
runrlimit_stack = 8388608 
runsolarisproject = "" 
runtimeout = 0
runtimeoutoverride = 0
runumask = 18 runuser = "sandy" 
solarisproject = "" status = 0
submithost = "octopus.company.com" 
submithostip = "127.0.0.2" 
submitlocale = "en_US.UTF-8" submitpid = 18509
subprocuser = "sandy" time = "11:33:34"
timezone = "PDT" true = 1
ttyname = "/dev/pts/20" 
umask = 18
uniqueid = "7f0000024c22537e484F"
user = "sandy"
year = 2010

This log can be read as the request was rejected. The reject statement is on line 3 (linenum) in the file /opt/pbul/policies/pb.conf (lineinfile).

Example

Given a policy where an accept can happen:

/* Another test policy */
adminusers = {"sandy", "happy"};
okcommands = {"ls", "mount"};
if ((user in adminusers) && (command in okcommands))
{
runuser = "root"; accept;
}

sandy executes the command:

pbrun ls

The event log from a pblog -l is similar to:

Accept 2010/06/23 11:43:44 [email protected] -> [email protected] by octopus.company.com ls
Command finished with exit status 0 argc = 1
argv = {"ls"} bkgd = 0
clienthost = "octopus.company.com" 
command = "ls"
cwd = "/tmp"
date = "2010/06/23" day = 23
dayname = "Wed"
env = {"LANG=C", "PATH=.:/usr/local/bin", "EDITOR=vi", "LOGNAME=sandy", "MAIL=/var/mail/sandy", "TERM=dtterm", "USER=sandy"}
event = "Accept"
eventlog = "/var/log/pb.eventlog" 
exitdate = "2010/06/23"
exitstatus = "Command finished with exit status 0" 
exittime = "11:43:45"
false = 0 group = "uts"
groups = {"uts"}
host = "octopus.company.com" 
hour = 11
i18n_date = "06/23/10" i18n_day = "23" 
i18n_dayname = "Wed" 
i18n_exitdate = "06/23/10" 
i18n_exittime = "11:43:45"
i18n_hour = "11"
i18n_minute = "43"
i18n_month = "06"
i18n_time = "11:43:44"
i18n_year = "2010" iolog = ""
lineinfile = "/opt/pbul/policies/pb.conf" 
linenum = "1"
localmode = 0
lognopassword = 1
logpid = 18829
logport = "32224" logservers = {"octopus"}
logstderr = 1
logstdin = 1
logstdout = 1
masterhost = "octopus.company.com" 
masterlocale = "C"
minute = 43
month = 6
nice = 0 
optarg = "" 
opterr = 1
optimizedrunmode = 1
optind = 1
optopt = ""
optreset = 1
optstrictparameters = 1 
pbclientmode = "run" 
pbclientname = "pbrun" 
pblogdmachine = "i686"
pblogdnodename = "octopus"
pblogdrelease = "2.6.22.5-31-default" 
pblogdsysname = "Linux"
pblogdversion = "#1 SMP 2007/09/21 22:29:00 UTC" 
pbmasterdmachine = "i686"
pbmasterdnodename = "octopus"
pbmasterdrelease = "2.6.22.5-31-default" 
pbmasterdsysname = "Linux"
pbmasterdversion = "#1 SMP 2007/09/21 22:29:00 UTC" 
pbrunmachine = "i686"
pbrunnodename = "octopus" 
pbrunrelease = "2.6.22.5-31-default" 
pbrunsysname = "Linux"
pbrunversion = "#1 SMP 2007/09/21 22:29:00 UTC" 
pbversion = "6.1.0-15"
pid = 18824
psmcmapid = "7f0000024c2255e04986"

ptyflags = 7
rejectnullpasswords = 0 requestuser = "sandy" 
rlimit_as = -977616896
rlimit_core = 0
rlimit_cpu = -1
rlimit_data = -1
rlimit_fsize = -1
rlimit_locks = -1
rlimit_memlock = 32768
rlimit_nofile = 1024
rlimit_nproc = 15349
rlimit_rss = 1692928000
rlimit_stack = 8388608 
runargv = {"ls"} runbkgd = 0
runcommand = "ls" 
runcwd = "/tmp" 
runenablerlimits = 0
runenv = {"LANG=C", "PATH=.:/usr/local/bin", "EDITOR=vi", "LOGNAME=sandy", "MAIL=/var/mail/sandy", "TERM=dtterm", "USER=sandy"}
rungroup = "uts"
rungroups = {"uts"}
runhost = "octopus.company.com" 
runlocalmode = 0
runnice = 0
runoptimizedrunmode = 1
runpid = 18822
runptyflags = 7
runrlimit_as = -977616896
runrlimit_core = 0
runrlimit_cpu = -1
runrlimit_data = -1
runrlimit_fsize = -1
runrlimit_locks = -1
runrlimit_memlock = 32768
runrlimit_nofile = 1024
runrlimit_nproc = 15349
runrlimit_rss = 1692928000
runrlimit_stack = 8388608 
runsolarisproject = "" 
runtimeout = 0
runtimeoutoverride = 0
runumask = 18
runuser = "sandy" 
solarisproject = "" 
status = 0
submithost = "octopus.company.com"
submithostip = "127.0.0.2" 
submitlocale = "en_US.UTF-8" 
submitpid = 18822
subprocuser = "root" 
time = "11:43:44"
timezone = "PDT" true = 1
ttyname = "/dev/pts/20" 
umask = 18
uniqueid = "7f0000024c2255e04988" 
user = "sandy"
year = 2010

The major differences between the output of this pblog -v example and the previous one are:

• The inclusion of the run variables (runcommand, runuser, rungroup, and so forth)
• The inclusion of the exit variables (exittime, exitdate, and an updated exitstatus)
• The user-defined variables adminusers and okcommands

By looking at the values in this output, you can determine the following:

• When a user ran a command (time and date)
• Where a user ran the command (ttyname and submithost)
• The command that the user requested (command)
• Which command was actually run (runcommand)
• What user the command was run as (runuser)
• How it terminated (exitstatus)
• The value of locale settings (values of LC_xxxx environment variables) on the submithost and Policy Server host (submitlocale and masterlocale)

ℹ️

Note

The value listed for these variables can differ depending on the platform, and also whether the LC_ xxxx variables are all set to the same value.

For example, on a Linux platform when all LC_xxxx (LC_CTYPE, LC_MONETARY, LC_TIME, etc.) variables are set to the same value, submitlocale displays as "C"; however, on an HP or AIX platform, it displays as "C C C C C".

In addition on the same Linux platform where LC_CTYPE is set to "POSIX" for example and everything else is set to "C", then submitlocale displays as follows:

LC_CTYPE=POSIX;LC_NUMERIC=C;LC_TIME=C;LC_COLLATE=C;LC_MONETARY=C;LC_ MESSAGES=C;LC_PAPER=C;LC_NAME=C;LC_ADDRESS=C;LC_TELEPHONE=C;LC_ MEASUREMENT=C;LC_IDENTIFICATION=C

On HP with those same settings, submitlocale displays as "C POSIX C C C C".

Accept/reject logging

Event log entries are generated that note when a job is accepted or rejected and when an accepted job finishes running. The pblog program enables you to selectively choose and display log entries in a file that is specified by eventlog. The variable event is set to the event type (Accept, Reject, or Finish). pblog’s options enable you to specify only certain entries to print, set the output, and specify the format for each event type, or print all of the variables that are stored with each entry. When a job finishes running, the variable exitstatus describes how it finished; exitdate and exittime specify when it finished running.

ℹ️

Note

If the exitstatus is undefined, then the exittime is not logged to the event log. It thus becomes unavailable for the event on which the exitstatus is undefined.

Whenever an attempt is made to run a command through pbrun, the attempt is appended to the event log. The default location of the event log is usually /var/adm/pb.eventlog, /usr/adm/pb.eventlog, or /var/log/pb.eventlog, depending on your operating system. The location of this log file can be changed by setting the eventlog setting in the settings file or by using the eventlog variable in a policy file. The event log is a data file and any attempt to edit the file or it might corrupt it. To read the contents of an event log, execute the pblog command.

Keystroke action events

EPM-UL records various keystroke action events in the event log. The administrator can specify that various words or patterns, when typed into a secured task, be logged to the event log and optionally terminate the job.

The easiest way to see the logged or rejected keystrokes in a session is to execute:

pblog

📘

To enable keystroke action events, see setkeystrokeaction.

Reporting and data extraction

EPM-UL provides the ability to extract keyword data from the event log. This data can be displayed or used by other programs (database import programs, spreadsheets, and report writers, for example).

Use the pblog -c option to extract the required data and/or use various Unix/Linux search tools (grep, awk, sed) to extract and redirect the data to a file. Here is a shell script to format pblog output:

#!/usr/bin/sh
NOTE: only root can run pblog
echo " "
echo " "
echo " "
echo "Report: Successful Root-Level Events " 
echo "------------------------------------ "
echo " "
echo " "
echo "Submitted from: User Command"
pblog -c 'event=="Accept"' -a 'submithost + " " + user + " " + runcommand'
echo " "
echo " "
echo " "
echo "Report: Unsuccessful Attempts "
echo "----------------------------- "
echo " "
echo " "
pblog -c 'event=="Reject"'

Example

A sample report:

Report: Successful Root-Level Events
------------------------------------
Submitted from: User Command 
sparky.company.com chris kill 
sparky.company.com chris csh 
sparky.company.com chris csh

Report: Unsuccessful Attempts
-----------------------------
Reject 1999/07/31 10:40:50 [email protected]
kill -9 396
Reject 1999/07/31 10:44:10 [email protected] 
mount /dev/rmt0l /mnt

Merge multiple event logs

If event logs are kept on different machines, then they can be merged into a single log by using the pbsync -L command. This feature is useful if there are separate dedicated log servers or if a secondary log server was used because of a log server failover.

Advanced reporting

Endpoint Privilege Management for Unix and Linux provides advanced event log reporting using the pbreport utility. After this utility is configured using the Endpoint Privilege Management for Unix and Linux browser, it allows the system administrator to perform advanced reporting tasks such as extracting selected fields and designing customized reports.

📘

For more information, see pbreport.

Event log rotation

Both pbmasterd and pblogd have the ability to rotate the event log. The current event log is renamed with a date/time tag, and a new event log is created with the specified event log name.

Event log rotation based on size

The eventlogrotate keyword specifies a rotate size and an optional path for the resulting rotated file. The size may include a k, m, or g, indicating the specified number is multiplied by 1024, 1048576, or 1073741824, respectively. This mechanism rotates the event log only during Accept and Reject events. The optional path specifies a new path only (not the file name portion). The rotated event log has the file name format pb.eventlog_YYYYMMDD_HHMMSS.

Example

eventlogrotate size=8k,path=/somewhere/else/

If the optional path is specified, the event log is renamed to the new file name (on the original file system) while the event log lock is held, then after the lock is released, the old renamed event log is moved to the optional path (possibly on a different file system). If the specified path does not exist, it is created.

This mechanism works with the event log /path/filename specified in the pb.settings file, or as changed via policy.

Variable substitution in the path

The path portion of the eventlogrotate keyword supports variable substitution. This is most useful to rotate to directories based on hostname or date. This mechanism works only when rotating by size during an Accept or Reject event. When rotating via command line (or cron), no policy variables are available. Variables used in the path portion of the eventlogrotate keyword must be variables that exist in every Accept and Reject event.

ℹ️

Note

The date variable results in a yyyy/mm/dd format, which includes subdirectories. For a yyyymmdd format without subdirectories, use %year%%i18n_month%%i18n_day%.

Example

eventlogrotate "size=8k, path=/var/log/pb/eventlogs/%masterhost%/%date%/"

Manual event log rotation

The --rotate option (-R), for both pbmasterd and pblogd, allows manual rotation, or rotation via cron, for the event log /path/filename specified in pb.settings. The --rotate option does not operate on event log /path/filenames changed via policy. The file name of a specific event log to rotate can be specified as an optional argument to the --rotate (-R) option. This mechanism uses the path element of the eventlogrotate keyword (ignoring any size specification).

Example

pbmasterd --rotate

Example

pbmasterd --rotate /var/log/pbeventlogA

Example

pblogd --rotate

Example

pblogd --rotate /var/log/pbeventlogA

Event log rotation based on age

Cron can be configured to execute either pbmasterd or pblogd with the --rotate option, to periodically rotate the event log.

📘

For more information, see _Configure eventlog rotation via cron _in the installation guide.

I/O logs

EPM-UL provides the ability to log any input to, or output from, a secured job. This feature tracks everything that a user does in a Unix/Linux shell or terminal session, including the standard input, standard output, and standard error streams.

📘

Prior to v8.5, applications that use their own non-standard file descriptors, such as X-Windows applications, cannot be logged through the I/O logs. A feature was added in v8.5.0 to capture X11 applications. For more information, see X Window System Session Capturing.

The contents of the I/O log file can also be limited to specific streams. The policy writer can limit the amount of data that is recorded from each of these streams.

I/O logging is configured in the policy file. Set the variable iolog to the name of a unique log file. If you want to turn off any of the standard streams, then you can set the variables logstdin, logstdout, and logstderr to false, as appropriate. After the command has started, you can use the pbreplay command to replay whatever was logged to that point in time, even if the session is still in progress.

Example

In this example, the policy file settings have been modified to ensure that all input and output is logged in logtoday when the adduser program is run through EPM-UL:

if(command=="adduser") {
iolog=logmktemp("/var/log/pb.logs/adduser.XXXXXX");
}

We do not recommend the use of a hard-coded file name, because I/O logs are not overwritten. An attempt to write to an existing I/O log file results in an error.

The function logmktemp() is useful for generating unique file names for log files. Like the Unix/Linux mktemp library call, this function takes a template pattern as its argument and returns a string with the filled template, creating a unique file name.

Example

This example sets the file name for recording input and output to a uniquely named file in /usr/adm. The file name begins with pboutput and ends with a unique number that logmktemp substitutes for the X characters:

iolog=logmktemp("/usr/adm/pboutputXXXXXX");

Different machines might have different file system structures, so when using a log server, you should specify log files using the log server’s file system. Environment variables are recorded in the I/O log file. If you want to suppress the logging of some of those environment variables, then use the logomit list. This variable is a list that contains the names of variables to omit from the log file. This feature is used when there is either no need to log certain variables or when it is wasteful to do so.

The lognopassword variable enables the security administrator to control the logging of non-echoed text (which is traditionally used for passwords) so that no one can see what is typed. If lognopassword is set to true, then only echoed text is logged. If lognopassword is set to false, then everything a user types is logged.

Some commands generate a large amount of output. Two examples are a tar of a complete file system or a daemon that sends output to stdout. It may be useful to limit the amount of output that is recorded in an I/O log for each command so that the logs do not get too large.

The number of characters that are logged from the stdin, stdout, and stderr streams can be limited.

Example

logstdinlimit=150;
logstdoutlimit=200;
logstderrlimit=4096;

This example limits the I/O log to 150 characters for standard input, 200 characters for standard output, and 4096 characters for standard error.

If the command is interactive, such as with a shell, then the characters come from stdin, stdout, and possibly stderr. Each time the output stream changes, stdout to stdin or stdout to stderr, the amount that is logged returns to 0 (unlimited).

⚠️

Important

To avoid file corruption, do not attempt to edit an I/O log file.

Password logging

📘

To control password logging, see passwordlogging.

Display I/O logs

The pbreplay command shows the contents of an I/O log. pbreplay has two modes:

• Interactive
• Batch

Interactive mode displays the stdout and stderr of any session. Batch mode can show the stderr, stdout, or stdin of a session. In batch mode it is also possible to specify a switch so that end-of-line characters are displayed as usual rather than just a carriage return, thereby preventing the output from overwriting itself.

The nature of I/O logging means that when a user has certain options enabled in some shells (set -o vi in the Korn shell, for example), the input keys are escape sequences. The shells interpret these and the output is displayed on stdout for a given input. EPM-UL does not interpret these input keystrokes. To determine what command is being entered, look at the stdout (pbreplay -o) and extract when a command is run.

I/O logging and system crashes

Should a log server crash or the network connection to the log server is lost, then EPM-UL attempts to fail over to an alternative log server. In this case, the start and end events for a task might be stored on two or more different machines. If you need to consolidate the event logs, then you can use pbsyncd.

Additionally, an I/O log could be split between two or more machines. I/O logs can be merged with pbsync.

📘

For more information, see pbsyncd.

Diagnostic logging

Diagnostic messages can be logged in syslog and into EPM-UL diagnostic log files. The log files are specified by the settings keywords.

📘

For more information, see Diagnostic Logging.

Debug trace logging

If you encounter difficulties or problems with EPM-UL, you can enable certain components to produce trace logs associated with each secured task processing. A non-zero debug level from 1 (lowest) to 9 (highest) controls the depth and detail of the debug trace messages that is logged. A zero debug level means no tracing is performed. Currently, this feature is available in pbrun, pbsh, pbksh, pbmasterd, pblocald, and pblogd.

The resulting trace log file names have the format:

<prefix><PBUL_program_name><suffix>.<version>.debug.<PID>

and are created in the same location as the corresponding diagnostics log.

To ensure security, the debug trace logs are only generated if the parent directories specified in the relevant diagnostics log settings pbrunlog, pbkshlog, pbshlog, pbmasterdlog, pblogdlog, and pblocaldlog are owned and writable only by root.

When debug tracing the clients pbrun, pbksh, and pbsh, if the corresponding diagnostic keywords pbrunlog, kshlog, and shlog are not present in the settings file, EPM-UL attempts to use the directory location specified in pblocaldlog or pbmasterdlog.

When on-demand tracing is enabled from the clients (pbrun, pbksh, pbsh), the client and any associated daemon that participates in the secured task processing produce a trace log for that session.

The daemons, on the other hand, can be set up to always start in a trace-enabled state on a host using one of the following methods:

• Use the debug option of the server program for daemons that are either stand-alone or started by a superdaemon.
• Manually create a hidden file containing a numeric debug level (1-9) in specific locations:
  • pbmasterd: /etc/.pbmasterd.debug.setting
  • pblogd: /etc/.pblogd.debug.setting
  • pblocald: /etc/.pblocald.debug.setting
• If running pbrun as root, use options in pbrun to enable tracing for the appropriate daemon. To initiate and permanently turn on tracing for pbmasterd, pblocald, and pblogd, use pbrun’s -d mlog, -d llog, and -d glog, respectively. The appropriate /etc/.*debug.setting file is created.

To disable debug trace logging for the server programs, locate and delete the hidden debug setting files created from one of the steps mentioned above:

• pbmasterd: /etc/.pbmasterd.debug.setting
• pblogd: /etc/.pblogd.debug.setting
• pblocald: /etc/.pblocald.debug.setting

📘

For more information, see Diagnostic logging, Enable debug trace logging for pbsh and pbksh, pbmasterd, pblocald, pblogd

For the syntax information of the specific EPM-UL program to learn how to turn on debug tracing: pbrun

Log synchronization

Endpoint Privilege Management for Unix and Linux supports redundant servers to allow for the continuity of the security rules in the event the policy server host becomes unavailable. In such an environment, the log file is created on the primary log server.

If the primary log server becomes unavailable, then transactions are no longer recorded on the primary log server, and the secondary server takes over to continue to log events and I/O streams.

When the network is restored, the primary policy server resumes logging to the destination system. Network administrators who want to monitor an I/O log or an event log would have to manually collect the logs from the primary and secondary servers, determine which occurred first, and finally merge and synchronize the logs.

The log synchronization feature reduces the workload for system administrators by providing automated log consolidation and merging of logs across the network using a single command.

📘

For more information, see Log synchronization, pbsync, pbsyncd

Log cleanup and rotation

The required retention period for log files varies from organization to organization. The log files are invaluable as security audit trails and system administration history logs.

The event log grows in length and contains more data than you see when executing a simple pblog command. Execute pblog -l and you will see a list of the variables. We suggest you run a nightly Unix/Linux cron (or similar) job to rename the event log.

Example

mv pb.eventlog pb.eventlog.prev

or

mv pb.eventlog pb.eventlog(datestamp)

The I/O log files increase in number rather than length. Their number should also be controlled using Unix/Linux cron. For example, you might want to keep two weeks of I/O logs before removing them from the system.

Log host file system space

If left unchecked, log files consume an increasing amount of disk space on the log host. This degrades log host performance and results in the loss of log files if space runs out. The file system space on the log host can be controlled and the system can be configured to fail over to the next log server with the logreservedfilesystems and logreservedblocks settings.

📘

For more information, see logreservedfilesystems and logreservedblocks.

Log archiving

Beginning with v9.0, Endpoint Privilege Management for Unix and Linux provides a logfile tracking and archiving mechanism for I/O logs and event logs. Each log file created can have its location recorded in a centralized database for future searches. Log files can be archived from the original logserver hosts, for the purpose of freeing up space on the log servers or for consolidating logs on designated archive hosts.

The log archiving process is performed by hosts that are installed and configured with the server components. Those components mandatorily install the Endpoint Privilege Management REST service which is essential in log file movement and tracking.

The hosts involved in log archiving are categorized as:

Log server

The host where the event log or I/O log is created either by pblogd or pbmasterd.

The pblogarchive program found on this host initiates the log file movement. After a successful archive, the log file exists on the destination Log Archive Storage Server and is removed from this host.

The settings file on this machine requires enablelogtrackingdb, logarchivehost, and logarchivedbhost.

📘

For more information, see pblogarchive, Settings.

Log archive storage server

The destination host of the archived logfiles.

The settings file on this machine requires logarchivedir, the main directory under which the archived logfiles are organized.

To support multi-tier archiving, this host can also function as a log server, transferring files to another archive server. In such case, the required settings mentioned above are needed as well.

📘

For more information, see Settings.

Log archive database server

The host where the centralized log tracking database is created and maintained.

The settings file on this machine requires logarchivedb, which is the path name of the SQLite database file.

We recommend you do not designate a primary log server/policy server as the database server to avoid degrading log host performance. Plan for growth of the database file, depending on the volume of log files that get created.

Regardless of function, all hosts involved in log archiving are required to have pbrestport configured in the settings file. Optionally, pbresturi may also be used.

📘

For more information, see Settings.

Archive encrypted log files

The log archiving feature supports encrypted logfiles.

⚠️

Important

The log server sending files to be archived and the Log Archive Storage Server receiving the archived logs must use the same encryption algorithm and key.

For event logs, eventlogencryption setting must be the same on the source and the destination. For I/O logs, the iologencryption setting must be the same on the source and the destination. Otherwise, the log file transfer could fail.

Archive by age

Archiving by age may be achieved by configuring cron to invoke the pblogarchive program.

Other logging limitations

EPM-UL has a local mode that can be used when an administrator needs only to monitor who started tasks, and whether or not they were approved. This feature reduces resource usage by making EPM-UL programs leave the job stream as soon as a secured task is approved. When using local mode, only the start of the secured task is logged.

📘

For more information about local mode, see Optimized Run Mode Processing, Local Mode Processing, allowlocalmode.