Hi all
I am trying to add secure and audit logs to logrotate for a client whom wants the logs for a period of 6 months, compressed/zipped weekly for auditing.
I am terrible with logrotate and since there isn't default settings for both logs, I created two new entries in my /etc/logrotate.d/ and soon I'll remove the secure logs from default syslog logrotate definition
# used by all secure logs
/var/log/secure
{
weekly
rotate 24
compress
notifempty
sharedscripts
postrotate
-------------------------->how do i reload secure logs?
endscript
}
#used by all audit.log
/var/log/audit/audit.log
{
weekly
rotate 24
compress
notifempty
sharedscripts
postrotate
-------------------------->how do i reload audit logs?
endscript
}
Could someone please check and ensure if this setting is correct? Also, how do I restart both logs after it has been compressed and store on the server? My syslog reads like this:
[root@H99AXXX logrotate.d]# more syslog
/var/log/messages /var/log/secure /var/log/maillog /var/log/spooler /var/log/boot.log /var/log/cron {
monthly
rotate 6
compress
sharedscripts
postrotate
/bin/kill -HUP `cat /var/run/syslogd.pid 2> /dev/null` 2> /dev/null || true
/bin/kill -HUP `cat /var/run/rsyslogd.pid 2> /dev/null` 2> /dev/null || true
endscript
}
[root@H99AXXX logrotate.d]# uname -a
Linux H99AXXX 2.6.18-274.7.1.el5 #1 SMP Mon Oct 17 11:57:14 EDT 2011 x86_64 x86_64 x86_64 GNU/Linux
[root@H99AXXX logrotate.d]#
What do you mean by "reload logs"?
Usually logrotate policies are triggered with crond.
Hi verdepollo
I meant to restart audit logs and secure logs at the end of the week, so it appends to a different file and the old logs are zipped
---------- Post updated at 05:59 PM ---------- Previous update was at 05:53 PM ----------
I just realised that it's easier to just add audit logs into the existing syslog logrotate definition (is that alright, or I will be facing problems later?)
[root@H99AXXX logrotate.d]# more syslog
/var/log/messages /var/log/secure /var/log/audit/audit.log /var/log/maillog /var/log/spooler /var/log/boot.log /var/log/cron {
weekly
rotate 24
compress
sharedscripts
postrotate
/bin/kill -HUP `cat /var/run/syslogd.pid 2> /dev/null` 2> /dev/null || true
/bin/kill -HUP `cat /var/run/rsyslogd.pid 2> /dev/null` 2> /dev/null || true
endscript
}
But then there's the question of space used up in /var. I've got SAP running on this VM and there's about 6 users on the system.
I'm still not getting you fully. You want to rotate the logs every 6 months, but also on a weekly basis?
You can indeed use your current syslog and just add more logs to it; Keep in mind however that all other logs will also start to follow the same 6-month rotation rules. Mail spools for instance are prone to eat up large amounts of space when something goes wrong whith the mail daemon. The same is true for "messages" log file if it's keeping a record of debugging information.
Used space in /var depends on the size of the logs as well as the size of the filesystem. Without having a good understanding of your particular system it'd be hard to tell exactly what would be the best approach to follow in order to prevent disk saturation.
Sorry for that, got you confused too
Well, here's the requirement from the end user
- to keep (certain system logs i.e-secure, messages, audit) logs for a period of 6 months (24 weeks)
Here's how I was planning on doing it
- Rotate the logs for 24 weeks on weekly basis before removing them
- But not before compressing the old logs weekly
So my logs would look like this
-rw------- 1 root root 1619422 Dec 5 04:02 messages.1.gz
-rw------- 1 root root 14822696 Dec 12 04:02 messages.2.gz
-rw------- 1 root root 15021180 Dec 19 04:02 messages.3.gz
-rw------- 1 root root 20300421 Dec 26 04:02 messages.4.gz
-rw------- 1 root root 13564183 Jan 2 11:52 messages.5.gz
-rw------- 1 root root 13564183 Jan 5 11:52 messages---------current log
The other way I was planning is it to rotate it on monthly basis:
- Rotate the logs each month for 6 months before removing them
- But not before compressing the old logs monthly
-rw------- 1 root root 1619422 Dec 2 04:02 messages.1.gz
-rw------- 1 root root 14822696 Jan 2 04:02 messages.2.gz
-rw------- 1 root root 15021180 Feb 2 04:02 messages.3.gz
-rw------- 1 root root 20300421 Mar 2 04:02 messages.4.gz
-rw------- 1 root root 13564183 Jan 2 11:52 messages.5.gz
-rw------- 1 root root 13564183 Jan 5 11:52 messages---------current log
Also I have about 4G of space on /var and if disk space is exhausted I can just add in another disk.
I know this will totally consume /var but they're really fussy about the logs so I have no choice but to keep them, however I can definitely housekeep these files if they grow too large and recall later from backup tapes..hope this is clear enough for your understanding :o
Well, seems you've already figured out how to solve it, am I right?
If you just want to hear an opinion, both options are OK. Try them both and see which one fits better to your preference. That's the beauty of linux, there are a plethora of ways to solve a single problem.
1 Like
no no! I just edited the current logs time stamps to show you the desired results.
I was hoping you could check if my syntax is correct, I logged a case with RHEL support and they refuse to check my syntax. Some policy with "no scripting"
[root@H99AXXX logrotate.d]# more syslog
/var/log/messages /var/log/secure /var/log/audit/audit.log /var/log/maillog /var/log/spooler /var/log/boot.log /var/log/cron {
weekly
rotate 24
compress
sharedscripts
postrotate
/bin/kill -HUP `cat /var/run/syslogd.pid 2> /dev/null` 2> /dev/null || true
/bin/kill -HUP `cat /var/run/rsyslogd.pid 2> /dev/null` 2> /dev/null || true
endscript
}
I guess you're right, every time I post a question here I get solution before someone replies. :o weird...
Please close this case. I realised that on RHEL and SLES systems, setting logrotate for audit isn't secure, chances are that it might not work. So this is what I did
- Set the logrotate entry for audit.log anyways; my logs is set for 24 weeks before removed, and rotated weekly
cd /etc/logrotate.d
# vi audit
/var/log/audit/audit.log {
weekly
rotate 24
compress
sharedscripts
postrotate
/etc/init.d/auditd reload
endscript
}
- Edit the conf file anyways, make a backup copy of existing conf file:
RHEL
# cp -p /etc/audit/auditd.conf /etc/audit/auditd.conf.YYYYMMDD
SLES
# cp -p /etc/auditd.conf /etc/auditd.conf.YYYYMMDD
# vi auditd.conf
#
# This file controls the configuration of the audit daemon
#
log_file = /var/log/audit/audit.log
log_format = RAW
log_group = root
priority_boost = 4
3
flush = INCREMENTAL
freq = 20
num_logs = 24-----------------increase log number from 4 to 24
disp_qos = lossy
dispatcher = /sbin/audispd
name_format = NONE
##name = mydomain
max_log_file = 5---------------------leave log file size to 5M
max_log_file_action------------------rotate old logs
space_left = 75
space_left_action = SYSLOG
action_mail_acct = root
admin_space_left = 50
admin_space_left_action = SUSPEND
disk_full_action = SUSPEND
disk_error_action = SUSPEND
##tcp_listen_port =
tcp_listen_queue = 5
tcp_max_per_addr = 1
##tcp_client_ports = 1024-65535
tcp_client_max_idle = 0
enable_krb5 = no
krb5_principal = auditd
##krb5_key_file = /etc/audit/audit.key
- Restart audit daemon
RHEL & SLES
# /etc/init.d/auditd restart