3www.net.ua - подробная инструкция для ОС Linux !

:: Меню ::

Головна

ВВЕДЕНИЕ

Часть I. Добро пожаловать в Linux

ЧТО ТАКОЕ LINUX?
BЫБОР ДИСТРИБУТИВА

Часть II. Установка Linux Red Hat 7.1

ПОДГОТОВКА К УСТАНОВКЕ LINUX RED HAT 7.1
УСТАНОВКА LINUX RED НАТ 7.1
ОСОБЫЕ ВАРИАНТЫ УСТАНОВКИ

Часть III. Использование среды рабочего стола в Linux Red Hat 7.1

ОБЗОР X WINDOWS
УСТАНОВКА И КОНФИГУРИРОВАНИЕ X WINDОWS
РАБОТА С GNOME И Х WINDOWS
РАБОТА С ПРОГРАММАМИ В GNOME И X WINDOWS
ДОПОЛНИТЕЛЬНОЕ КОНФИГУРИРОВАНИЕ GNOME
КDЕ
ДОПОЛНИТЕЛЬНАЯ КОНФИГУРАЦИЯ XWINDOWS

Часть IV. Углубленное изучение

ВВЕДЕНИЕ В СИСТЕМУ КОМАНД LINUX
РАБОТА С ФАЙЛАМИ
КОНФИГУРИРОВАНИЕ СИСТЕМЫ СРЕДСТВАМИ LINUXCONF И ПАНЕЛИ УПРАВЛЕНИЯ
ВВЕДЕНИЕ В ОБОЛОЧКИ
ОБЩЕЕ АДМИНИСТРИРОВАНИЕ СИСТЕМЫ
ИСПОЛЬЗОВАНИЕ ПЕРИФЕРИЙНЫХ УСТРОЙСТВ
СРЕДСТВА МУЛЬТИМЕДИА В LINUX
РЕКОМПИЛЯЦИЯ ЯДРА LINUX

Часть V. Основы сетей

РАБОТА В СЕТЯХ LINUX. Основы TCP/IP
СОЕДИНЕНИЕ LINUX С INTERNET
ИСПОЛЬЗОВАНИЕ WORLD WIDE WЕВ
ПРОСМОТР Е-MAIL
РАБОТА С ФАКСОМ В LINUX

Часть VI. Применение Linux для SOHO

ИСПОЛЬЗОВАНИЕ LINUX В SOHO
ИНСТАЛЛЯЦИЯ LIN UX RED HAT 7.1 ДЛЯ SOHO
КОНФИГУРИРОВАНИЕ LINUX RED HAT 7.1 ДЛЯ СЕТИ ETHERNET
РАБОТА LINUX REDHAT7.1 B СЕТЯХ WINDOWS И NOVELL
LINUX RED HAT 7.1 И DOS/WINDOWS
БЕЗОПАСНОСТЬ И LINUX RED HAT 7.1 КАК ЭФФЕКТИВНЫЙ МАРШРУТИЗАТОР

Часть VII. Использование Linux Red Hat 7.1 в качестве сервера Web и электронной почты

ПОСТРОЕНИЕ СОБСТВЕННОГО WEB-СЕРВЕРА.
LINUX RED HAT 7.1 КАК ПОЧТОВЫЙ СЕРВЕР: МОЩЬ SENDMAIL

Приложения

A. LINUX ВО ВСЕМ МИРЕ (НЕ АНГЛОЯЗЫЧНЫЕ ДИСТРИБУТИВЫ).
В. ИНФОРМАЦИОННЫЕ ИСТОЧНИКИ LINUX
С. ОБЗОР КОМАНД LINUX
D. GNU - ОБЩЕСТВЕННАЯ ЛИЦЕНЗИЯ ОБЩЕГО ВИДА
Е. LINUX НА ПЛАТФОРМЕ, ОТЛИЧНОЙ ОТ INTEL
:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
Добавить в избранное

:: Друзья:

-

Статті

 

:: Статистика ::

 

 

 

 

 

 

Что заносится в журнал

Очень важно понимать различия между журналами системы Linux. Существует два основных типа журналов: системные журналы и журналы приложений. В этом параграфе мы рассматриваем системные журналы, поскольку они есть в любой системе. Что касается журналов приложений, то каждое приложение (программа) может иметь (или не иметь) свой журнал, зависящий от конфигурации этой программы.

В системные журналы, как правило, записываются сообщения и предупреждения ядра системы, в том числе о загрузке модулей, данные от демона sendmail, отслеживающего сообщения, обрабатываемые системой, а также сообщения об успешных или неудачных попытках входа в систему.

Записи в системные журналы заносятся демоном syslogd, запускаемым при загрузке системы. Демон получает сообщения восьми уровней серьезности от различных процессов - ядра, системы электронной почты, пользовательских программ, конфигурированных на использование syslogd, а также аутентификационных программ, наподобие программы входа в систему.

Перечислим уровни серьезности сообщений в порядке возрастания:

  • debug (отладочные);
  • info (информационные);
  • notiсе (извещения);
  • warning (предупреждения);
  • err (сообщения об ошибках);
  • crit (критические);
  • alert (предостережения);
  • emerg (аварийные).

По этим уровням, записанным в файле /etc/syslog. conf, демон syslogd определяет, в какие журналы заносить те или иные сведения. Файл /etc/ syslog. conf содержит множество записей - по одной на строку по два поля, разделенных пробелами, в каждой. Левое поле содержит список источников и уровней сообщений, правое - файл журнала, в который они заносятся.

Пары источник-уровень в левом поле перечисляются через точку с запятой. Источники указаны по именам — например, mail (электронная почта), kern (ядро системы), user (программы пользователей) или auth (аутентификационные программы). Примеры пар источник-уровень:

  • mail. err: сообщения об ошибках, генерируемые демоном электронной почты;
  • * . info: все информационные сообщения;
  • kern. emerg: аварийные сообщения от ядра.

Рассмотрим файл / etc / sys log . conf, входящий в дистрибутив Linux Red Hat 7.1.

# Запись всех сообщений ядра" на 'консоль.

# Не записывать больше, чтобы не засорять экран.

# kern.* /dev/console .

# Записывать все (кроме почты) уровня info и выше.

# Не записывать частных аутентификационных рообщений!

*.info;mail.none;news.none;authpriv.none /var/log/messages

# Ограниченный доступ к файлу authpriv.

authpriv.* /var/log/secure

# Запись всех почтовых сообщений в одном месте.

mail.* /var/log/maillog

# Аварийные сообщения рассылаются всем и записываются

# на другой машине.

*. emerg *

# Запись сообщений об ошибках электронной почты и новостей уровня err

# и выше в отдельном файле.

uucp,news.crit /var/log/spooler

# Запись сообщений о загрузке также в файл bopt.log

loca17.* /var/log/boot.log

Первая важная строка этого файла:

*.info;mail.none,news.none;authpriv.none /var/log/messages

В ней указана запись всех информационных сообщений, кроме сообщений от программ электронной почты, групп новостей и аутентификационных программ (обозначенных составляющими

mail .none;news .none; authpriv.none), в файл /var/log/messages. Далее следует строка

authpriv.* /var/log/secure

предписывающая запись всех аутентификационных сообщений в файл /var / log /secure.

В следующей строке указано помещать все сообщения от программ электронной почты в файл/var/log/maillog.

mail.* /var/log/maillog

Наконец, строка

uucp,news.crit /var/log/spooler

указывает, что определенные сообщения, связанные с работой программ электронной почты и новостей, записываются в файл /var /log/spooler.

Вероятно, вы обратили внимание, что сообщения распределяются по разным файлам. Это делается для ограничения объемов журналов, а также для частичной классификации сообщений. Если сваливать в один файл сообщения от всех источников и всех уровней серьезности, разобраться в этом файле будет невозможно.

Стратегию ведения регистрационных журналов можно поменять, изменив файл /etc/syslog. conf и заставив демон syslogd загрузить новые конфигурационные данные командой

# kill -HUP `cat /var/run/syslogd.pid"

Обратите внимание на применение обратных кавычек, указывающих, что стандартный вывод заключенной в них команды используется как аргумент команды kill -HUP. Флажок -HUP команды kill указывает, что процесс должен заново считать конфигурационные данные без завершения работы.

 


:: Реклама ::

-

 


:: Cсылки ::


:: Баннеры ::

 

 

 


Copyright © Kivik, 2012