Linux Server Security (2nd Edition( [Electronic resources] نسخه متنی

اینجــــا یک کتابخانه دیجیتالی است

با بیش از 100000 منبع الکترونیکی رایگان به زبان فارسی ، عربی و انگلیسی

Linux Server Security (2nd Edition( [Electronic resources] - نسخه متنی

Michael D. Bauer

| نمايش فراداده ، افزودن یک نقد و بررسی
افزودن به کتابخانه شخصی
ارسال به دوستان
جستجو در متن کتاب
بیشتر
تنظیمات قلم

فونت

اندازه قلم

+ - پیش فرض

حالت نمایش

روز نیمروز شب
جستجو در لغت نامه
بیشتر
لیست موضوعات
توضیحات
افزودن یادداشت جدید







12.4. Managing System Logfiles with logrotate


Configuring and
fine-tuning your system-logging facilities is extremely important for
system security and general diagnostics. But if your logs grow too
large and fill up their filesystem, all that work will be
counterproductive.


Just What Do We Mean By "Rotate?"


All log-management mechanisms involve periodically moving/renaming a
logfile to an archive copy and creating a new (empty) logfile.
Rotation is necessary when multiple archive copies are maintained.

In the most common log-rotation scheme, a set of static
filenames is maintained. For example, messages, messages.1,
messages.2, messages.3 is a typical three-archive filename
setmessages being the current logfile and
messages.3 being the oldest archive.

In this scheme, rotation is achieved by copying the second-to-oldest
file over the oldest file (e.g., mv messages.2
messages.3
). The third-oldest file's name
is then changed to that of the second-oldest file's,
and so forth, until the current file is renamed and a new (empty)
"current" logfile is created (e.g.,
mv messages messages.1; touch messages). This is
how logrotate behaves when its
rotate parameter is set to a nonzero
value.

As with syslog itself, most Linux distributions come with a
preconfigured log-rotation scheme; on most of these distributions,
this scheme is built on the utility logrotate.
As with syslog, while this default scheme tends to work adequately
for many users, it's too important a mechanism to
take for granted. It behooves you to understand, periodically
evaluate, and if necessary, customize your log-management setup.


12.4.1. Running logrotate


Red Hat, Fedora, SUSE, and
Debian use logrotate to handle system-log
growth. Global options and low-level (system) logfiles are addressed
in /etc/logrotate.conf, and application-specific
configuration scripts are kept in
/etc/logrotate.d/.

When logrotate is run, all scripts in
/etc/logrotate.d are included into
logrotate.conf and parsed as one big script.
This makes logrotate's
configuration very modular: when you install an RPM or DEB package
(of software that creates logs), your package manager automatically
installs a script in /etc/logrotate.d, which
will be removed later if you uninstall the package.


Actually, the include directive in
logrotate.conf may be used to specify additional
or different directories and files to include. In no event, however,
should you remove the statement that includes
/etc/logrotate.d if you use Red Hat or Debian,
both of whose package managers depend on this directory for
package-specific log-rotation scripts.

12.4.1.1 Syntax of logrotate.conf and its included scripts


There are really only two types of elements in
logrotate.conf and its
included scripts: directives (i.e., options) and logfile
specifications. A directive is simply a
parameter or a variable declaration; a logfile
specification is a group of directives that apply to a
specific logfile or group of logfiles.

In Example 12-25, we see a simple
/etc/logrotate.conf file.

Example 12-25. Simple logrotate.conf file


# Very simple logrotate.conf file
# Global options: rotate logs monthly, saving four old copies and sending
# error-messages to root. After "rotating out" a file, touch a new one
monthly
rotate 4
errors root
create
# Keep an eye on /var/log/messages
/var/log/messages {
size 200k
create
postrotate
/bin/kill -HUP `cat /var/run/syslog-ng.pid 2> /dev/null` 2>
/dev/null || true
endscript
} In Example 12-25, the global options at the top may be
thought of as the default logfile specification. Any directive for a
specific logfile takes precedence over the global options.
Accordingly, we see in this example that although by default logs are
rotated once a month and that four archives will be kept, the file
/var/log/messages will be rotated not on the
basis of time, but on size.

However, the other global directives still apply to
/var/log/messages: four old copies will be kept;
immediately after a log is renamed (which is how
they're
"rotated"), a newly empty current
logfile will be created
("touched"), and error messages
will be emailed to root.

logrotate supports a large number of different
directives, but in practice, you'll probably spend
more time tweaking the subscripts placed in
logrotate.d than you will writing scripts from
scratch. With that in mind, Table 12-12 lists some
commonly encountered
logrotate
directives. A complete list is provided in the manpage
logrotate(8).

Table 12-12. Common logrotate directives


Directive

Description

/path/to/logfile {
directive1
directive2
etc.
}

Logfile specification header/footer (i.e., "apply
these directives to the file
/path/to/logfile"). Whitespace
is ignored.

Applicable global directives are also applied to the logfile, but
when a given directive is specified both globally and locally (within
a logfile specification), the local setting overrules the global one.


rotate number

Tells logrotate to retain
number old versions of the specified
logfile. Setting this to 0 amounts to telling
logrotate to overwrite the old logfile.


daily | weekly | monthly | size=n_bytes

The criterion for rotating the specified file: either because one day
or week or month has passed since the last rotation, or because the
file's size has reached or exceeded
n_bytes since the last time
logrotate was run.

Note that if n_bytes is a number, bytes
are assumed; if expressed as a number followed by a lowercase
"k," kilobytes are assumed; if
expressed as a number followed by a capital
"M," megabytes are assumed.


mail [username|mail@address]

Email old files to the specified local user or email address rather
than deleting them.


errors [username|email@address]

Email logrotate error messages to the specified
local user or email address.


compress

Use gzip to compress old versions of logfiles.


copytruncate

Instead of renaming the current logfile and creating a new (empty)
one, move most of its data out into an archive file. Accommodates
programs that can't interrupt logging (i.e., that
need to keep the logfile open for writing continuously).


create [octalmode owner group]

Re-create the (now empty) logfile immediately after rotation. If
specified, set any or all of these properties:
octalmode (file mode in octal
notatione.g., 0700), owner, and
group properties.


ifempty | notifempty

By default, logrotate rotates a file even if
it's empty. notifempty
cancels this behavior; ifempty restores it
(e.g., overriding a global notifempty
setting).


include file_or_directory

When parsing logrotate.conf, include the
specified file or the files in the specified directory.


missingok | nomissingok

By default, logrotate will return a message if a
logfile doesn't exist.
missingok cancels this behavior (i.e.,
tells logrotate to skip that logfile quietly);
nomissingok restores the default behavior
(e.g., overriding a global missingok
setting).


olddir dir | noolddir

Tells logrotate to keep old versions of a
logfile in dir, whereas
noolddir tells logrotate to
keep old versions in the same directory as the current version
(noolddir is the default behavior).


postrotate
line1
line2
etc.
endscript

Execute specified lines after rotating the
logfile. Can't be declared globally. Typically used
to send a SIGHUP to the application that uses the logfile.


prerotate
line1
line2
etc.
endscript

Execute specified lines before rotating
the logfile. Can't be declared globally.

12.4.1.2 Running logrotate


Usually, logrotate is invoked by the script
/etc/cron.daily/logrotate,
which consists of a single command:

/usr/sbin/logrotate /etc/logrotate.conf This doesn't necessarily mean that logs are rotated
daily; it means that logrotate checks each
logfile daily against its configuration script and rotates or
doesn't rotate the logfile accordingly.

If you want logrotate to be run less frequently,
you can move this script to /etc/cron. weekly or
even /etc/cron.monthly (though the latter is
emphatically not recommended unless
logrotate is, for some strange reason,
configured to rotate each and every file monthly).


/ 94