Linux with Operating System Concepts

Option
Meaning
-a 
EID
All entries for event # 
EID
-gi 
GID
All entries of processes owned by group 
GID
-i
Convert numeric (UID, GID, etc.) entries into text
-k 
string
All entries that contain 
string
-m 
type
All entries whose message type is listed in 
type
-p 
PID
All entries generated by process 
PID
-pp 
PID
All entries generated by process whose parent is 
PID
-sc 
name
All entries generated by the system call 
name
(name may either be a string or number)
-ui 
UID
All entries generated by user 
UID
-x 
name
All entries generated by the executable program 
name
TABLE 14.5 
Aureport Options
Option
Meaning
-au
Authentication attempts
-c
Configuration changes
-e
Events
-f
File operations
-i
Convert numeric (UID, GID, etc.) entries into text
-l
Login attempts
-m
Modification of user accounts
-n
Anomalous events
-p
Process-initiated events
-s
System calls
-u
User-initiated events
-x
Processes executed

---

600
◾
Linux with Operating System Concepts
Selected time for report: 03/19/2013 10:11:02 –
04/16/2013 10:21:15.081
Number of changes in configuration: 18
Number of changes to accounts, groups, or roles: 47
Number of logins: 20
Number of failed logins: 1
Number of authentications: 164
Number of failed authentications: 5
Number of users: 3
Number of terminals: 16
Number of host names: 5
Number of executables: 21
Number of files: 0
Number of AVC’s: 0
Number of MAC events: 20
Number of failed syscalls: 0
Number of anomaly events: 3
Number of responses to anomaly events: 0
Number of crypto events: 68
Number of keys: 0
Number of process IDs: 4787
Number of events: 29145
Running aureport with an option will provide a listing of all events corresponding to 
the option(s) supplied. For instance, 
aureport –au
generates all authentication events. 
Three such events are listed below. The columns represent the authentication event num-
ber, the date and time, the user account responsible for the event, the host and terminal 
window from which the event was generated, the executable program responsible for the 
event, whether it was successful or not, and the overall event number.
2. 03/19/2013 10:11:16 foxr ? :0 /usr/libexec/gdm-session-
worker yes 35602
3. 03/19/2013 10:15:59 foxr ? ? /usr/sbin/userhelper yes
35609
4. 03/19/2013 10:22:35 root ? pts/0 /bin/su yes 35617
Below is a brief excerpt generated by the command 
aureport –e
. The –e option pro-
vides all events. In this case, we see events from the morning of March 19, 2013. The first 
column, as with the list above, indicates the number within this listing while the number in 
the fourth column is the overall event number. The fifth column is the type of event followed 
by the user’s UID and whether it was successful or not. A UID of -1 would indicate “unset.”
10. 03/19/2013 10:11:16 35607 USER_START 500 yes
11. 03/19/2013 10:11:16 35608 USER_LOGIN 500 yes
12. 03/19/2013 10:15:59 35609 USER_AUTH 500 yes
13. 03/19/2013 10:15:59 35610 USER_ACCT 500 yes

---

Maintaining and Troubleshooting Linux
◾
601
Here, we see the same output with the option 
–i
added to 
–e
so that numeric values are 
translated into names.
10. 03/19/2013 10:11:16 35607 USER_START foxr yes
11. 03/19/2013 10:11:16 35608 USER_LOGIN foxr yes
12. 03/19/2013 10:15:59 35609 USER_AUTH foxr yes
13. 03/19/2013 10:15:59 35610 USER_ACCT foxr yes
If you refer back to the previous output, you will see the last event has an event number 
of 35610. Let us examine that event in more detail using ausearch. We issue the command 
ausearch –a 35610
and we are given the following output:
time-
>
Tue Mar 19 10:11:16 2013
type 
=
USER_START msg 
=
audit(1363702276.674:35607):
user pid 
=
1948 uid 
=
0 auid 
=
500 ses 
=
2 
subj 
=
system_u:system_r:xdm_t:s0-s0:c0.c1023 
msg 
=
‘op 
=
PAM:session_open acct 
=
“foxr”
exe 
=
“/usr/libexec/gdm-session-worker” hostname 
=
? addr 
=
? 
terminal 
=
:0 res 
=
success’
We see the same information that aureport provided us, but we have more information. 
We see the date, type of event, message specifier, PID and UID of the event, AUID (which 
is the effective user, or the user on whose behalf the PID executed), a session number, a sub-
ject, and the full message that includes more detail such as the specific executable program 
and terminal window that the event originated from, and the result (success in this case). 
The above example is a successful login by foxr. Below is another event, an unsuccessful 
attempt to su to root.
time-
>
Tue Apr 16 11:15:48 2013
type 
=
USER_AUTH msg 
=
audit(1366125348.228:13171):
user pid 
=
23909 uid 
=
500 auid 
=
500 ses 
=
1 
subj 
=
unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 
msg 
=
‘op 
=
PAM:authentication acct 
=
“root” exe 
=
“/bin/su” 
hostname 
=
? addr 
=
? terminal 
=
pts/0 res 
=
failed’
14.5.3 Other Log Files of Note
There are numerous log files with the name anaconda such as 
anaconda.log
, 
ana-
conda.ifcfg.log
, 
anaconda.syslog
, and 
anaconda.yum.log
. These log files 
are generated upon system installation. They all store events related to Linux installation. 
For instance, anaconda.log is the log file of the Linux installation itself while anaconda.
ifcfg.log stores information about the network as it is initially configured and anaconda.
yum.log contains information on upgrades to the initial installation.
The following are additional log files of note:
• Xorg—log files generated by X Windows, including modules loaded when X Windows 
is started and failures of X Windows components. There are also messages from the 
audit client for window opening and closing events.

---

602
◾
Linux with Operating System Concepts
• maillog—messages generated by the mail system. Even if your computer is not run-
ning email, email messages are automatically generated and sent to root or users of 
the current system when errors or warnings arise.
• yum.log—entries here indicate yum operations (installations, updates, and deletions).
• lastlog—last log-in attempts for users, this information is not stored in the text; so, 
you cannot view it directly.
• httpd/access_log—the default log file generated by Apache for every received http 
request. This log file can be highly useful website administrators who want to view 
user habits when visiting their site.
• httpd/error_log—also generated by Apache, this file contains events that result in 
errors such as bad or lost connections, bad links and server side script errors.
• cups—messages logged from printer requests and printer errors.
• utmp, wtmp, and btmp—these log files show who is currently logged into the system 
and failed log-in attempts.
14.5.4 Log File Rotation
You will no doubt find multiple files whose names are similar to the above but with numeric 
extensions or a hyphenated date added to the name. These extensions/dates indicate log 
files that have been rotated. The 
logrotate
program is set up to 
rotate
log files. This 
means that a new, empty, log file is created and the older log file(s) is(are) renamed.
The renaming strategy differs by log file. Most log files are renamed by adding the 
date of the rotation to the end of the file name, such as changing 
messages
to be 
mes-
sages-20130829
. The older log rotation approach was to number each file such as 
messages
(the new or newest file), 
messages.1
, 
messages.2,
and so forth. This 
would require that logrotate not only change one file’s name but all file names by rotat-
ing the numbers.
Many rotations are scheduled via anacron to be performed daily, weekly, or monthly. 
Log files are retained for some time. The frequency of log rotations and the number of log 
files retained is usually established by the file /
etc/logrotate.conf
. If set to 
weekly
and 
rotate 4
(the defaults), logrotate will rotate log files once per week, retaining not 
more than four backup logs at a time (thus keeping five total log files, the current file, and 
the four older files). Upon the next rotation, the oldest log file is discarded. As a system 
administrator, you might want to retain log files indefinitely by backing up /var/log at least 
once per month. Alternatively, you can change logrotate.conf to retain more than four log 
files at a time.
The system administrator should know about log rotation to understand when log files 
should be archived so that no logged data are lost. The system administrator should come 
up with a log rotation plan. This log rotation plan should be consistent with the logrotate 
configuration file, /etc/logrotate.conf. In this file, default configurations are provided that 
include the rotate rate, the number of log files to retain, whether to create a new (empty) 

---

Maintaining and Troubleshooting Linux
◾
603
file upon log rotation or not, and whether to compress log files. Then the file lists directives 
for specific log files. You might, for instance, find default values of 
weekly
, 
rotate 4
, 
create,
and 
#compress
(i.e., the compress command is commented out). This may be 
followed by a specific logrotate entry such as the following for the log file wtmp:
/var/log/wtmp {
monthly
create 0664 root utmp
rotate 1
}
As a simple example, the system administrator may choose to back up /var/log every 
4 weeks to correspond with the number of default log files that are retained at a time. 
However, this may itself be insufficient. As we saw above, some log files’ names are altered 
to indicate the date of rotation. In such a case, saving the log file to a backup location does 
not present a problem. But in the case of log files whose names are altered by extending the 
name with a digit as in 
somelog.1
being rotated to 
somelog.2
, then just saving these to 
a location where there are already some log entries would cause older log files to be deleted. 
The system administrator should come up with a naming convention.
Speaking of log names, it should be noted that the naming convention for the Xorg log 
files is different from the others described above. Rather than numeric values or dates to 
indicate the log files’ ages, the log files’ names for Xorg are generated based on the terminal 
window that the file corresponds to. For instance, 
Xorg.0.log
is the log file for console 0 
whereas 
Xorg.1.log
is the log file for console 1.
Now that we have logging taken care of, what about reviewing log files? How often should 
a system administrator examine the contents of these files and which files? Although there 
is no set or recommended policy, a plan should be devised by the system administrator(s) 
based on the size and nature of the organization. The simplest plan is to examine the log 
files whenever the system is running poorly or you suspect a problem has arisen.
We want to work to prevent problems; so, we should be proactive in examining log files. 
Searching log files daily though will not typically be required, with the possible exceptions 
of secure and messages. Assume we have a Linux system of dozens of users. We might use 
the following schedule for examining log files, unless of course, a situation arises requiring 
more immediate attention:
• secure—examine daily to see pattern of log ins and see if there are incidents of 
reported failures that might hint at a hacking attempt.
• messages—examine daily to see if there are services or software reporting failures.
• boot—examine after system boot and initialization to ensure no errors doing the 
boot process.
• cron—examine weekly to ensure that all scheduled cron jobs are executing as 
expected.

---

604
◾
Linux with Operating System Concepts
• yum—examine weekly to see if updates and installation are being handled without 
errors.
• maillog, spooler—examine only as needed if there are email or printer problems.
In addition, run aureport weekly to examine incidents of failures and anomalies. If 
there are an unusual number of entries, use ausearch to find out more.
14.6 DISASTER PLANNING AND RECOVERY