Дельта синхронизация без облака

Ранее мы показывали разные способы синхронизации криптодиска между ПК и Android-устройством.

Смотрим плавность хода с помощью BMW Rheingold

Всем знакома ситуация, когда двигатель немного "троит", но пропусков зажигания нет...

Облачный хостинг VDS за 2 минуты

Настоящий облачный VDS-хостинг от UltraVDS: тестируем производительность

Дельта-синхронизация крипто-дисков

Существуют разные способы зашифровать "облако". Один из них - поместить в облако крипто-диск. В предыдущей статье мы писали, почему это не всегда удобно.

Протоколирование


В этой статье будет рассмотрен демон syslogd, а также как управлять протоколированием сообщений системы и ядра с помощью этого демона.

Прежде всего, нужно отметить, что демон находится в пакете sysklogd (если, вы, конечно, используете Red Hat-совместисую систему), поэтому перед его использованием нужно установить этот пакет. В большинстве случаев у вас пакет уже будет установлен, а демон syslogd - запущен. Чтобы проверить это введите команду syslogd. Вы должны получить сообщение: syslogd: Already running.

В пакет sysklogd на самом деле входят две программы: syslogd и klogd. Syslogd отвечает за протоколирования сообщений системы, а klogd - ядра.

Демон Syslogd

Syslogd обеспечивает вид протоколирования, который используется большинством программ. Демон syslogd пишет сообщения в файл /var/log/syslog. Обычно записи в этом файле содержат такие поля: дата и время, хост, программа, сообщение. Пример этого файла предстален ниже:


Jan 27 17:09:35 dhsilabs modprobe: modprobe: Can't locate module sound-service-1-0
Jan 27 17:09:35 dhsilabs modprobe: modprobe: Can't locate module sound-slot-1
Jan 27 17:09:35 dhsilabs modprobe: modprobe: Can't locate module sound-service-1-0
Янв 27 17:10:07 dhsilabs DrakX: trying to load ru_RU.KOI8-R.po from ./po.cz2
Янв 27 17:11:23 dhsilabs DrakX: default cancel_clicked
Jan 27 17:12:28 dhsilabs kernel: VFS: Disk change detected on device ide1(22,64)
Jan 27 17:12:31 dhsilabs kernel: ISO 9660 Extensions: Microsoft Joliet Level 1
Jan 27 17:12:31 dhsilabs kernel: ISOFS: changing to secondary root
Jan 27 17:12:32 dhsilabs kernel: VFS: Disk change detected on device fd(2,0)
Jan 27 17:12:32 dhsilabs kernel: end_request: I/O error, dev 02:00 (floppy), sector 0

Например, из предпоследней записи мы можем узнать, что 27-го января 2002 года в 17:12 произошла смена носителя в устройстве fd, о чем нам любезно сообщило ядро системы (запись "программа" - kernel).

Демон syslogd автоматически при старте системы. Для его запуска предназначен сценарий /etc/rc.d/init.d/syslog. Как обычно, запустить демон самостоятельно мы можем с помощью команды: /etc/rc.d/init.d/syslog start, а остановить - /etc/rc.d/init.d/syslog stop. Для обеспечения автоматической загрузки нажно создать символическую ссылку на этот файла, например: ls -s /etc/rc.d/rc5.d/@S30syslog /etc/rc.d/init.d/syslog В этом случае мы обеспечим запуск демона на пятом уровне запуска (автоматический запуск X Window). Если вы используете Linux Mandrake, включить и отключить автоматический запуск вы можете с помощью команды drakxservices(см. рис. 1)

Параметры запуска

Демон syslogd можно запускать с опциями, указанными в таблице 1.

Таблица 1

Опция Описание
-s socket Этот параметр позволяет указать дополнительный сокет, который syslog должен прослушивать
-d Включает режим отладки. В этом режиме демон не будет использовать системный вызов fork(2) для переключения себя в фоновый режим и будет выводить больше отладочной информации
-f file Этот параметр определяет альтернативный файл конфигурации
-h По умолчанию демон не перенаправляет сообщения, которые он получает от других узлов. Этот параметр позволяет перенаправить сообщения другим хостам, которые определены
-n Этот параметр нужен, если syslogd запускается и контролируется программой init
-p socket Позволяетт задать другой сокет Unix вместо /dev/log
-r Позволяет принимать сообщения из сети. Данная опция появилась в версии syslogd 1.3
-v Выводит версию syslogd

В таблице 1 указаны не все опции демона. Назначение всех остальных опций вы можете найти в справочной системе, введя команду man syslogd.

Сигналы

Демон syslogd реагирует на следующие сигналы: SYGTERM, SIGINT, SIGQUIT, SIGHUP, SIGUSR1, SIGCHLD. Реакция демона на сигналы указана в таблице 2.

Таблица 2.

Сигнал Реакция
SIGTERM Завершает работу демона
SIGINT, SIGQUIT Завершает работу демона, если выключена отладка (debugging). Если же отладка включена, эти сигналы игнорируются
SIGUSR1 Включает/выключает отладку
SIGHUP Перезапуск демона

Файл конфигурации

По умолчанию используеся файл конфигурации /etc/syslog.conf. Вы можете указать другой файл конфигурации с помощью опции -f. Рассмотрим установки демона на примере обычного файла конфигурации:


# Протоколирование аутентификации. Файл протокола /var/log/auth.log
auth,authpriv.*							/var/log/auth.log
# Префикс "-" используется, если вы хотите синхронизировать 
# файл после каждой записи в него.
*.*;auth,authpriv.none						-/var/log/syslog
# Сообщения пользовательских программ
user.*								-/var/log/user.log

# Протоколировать все (кроме mail (почты)). Уровень info и выше
# Частные (private) сообщения протоколироваться не будут (none)
*.info;mail.none;authpriv.none					-/var/log/messages

# Файл регистрации частных сообщения имеет ограниченный доступ. Обычно в этот
# файл записываются сообщения об удаленном доступе к этой машине, например, 
# cообщения от демона FTP о том, какие пользователи и когда 
# регистрировались на данном сервере. 
authpriv.*							/var/log/secure

# Протоколирование почты
#    Уровень отладки, информации и замечаний
mail.=debug;mail.=info;mail.=notice				-/var/log/mail/info
#    Уровень предупреждений
mail.=warn							-/var/log/mail/warnings
#    Уровень ошибок
mail.err							-/var/log/mail/errors

# Протоколирование демона cron. Уровни отладки, информации, 
# предупреждений и ошибок
cron.=debug;cron.=info;cron.=notice				-/var/log/cron/info
cron.=warn							-/var/log/cron/warnings
cron.err							-/var/log/cron/errors

# Протоколирование ядра
kern.=debug;kern.=info;kern.=notice				-/var/log/kernel/info
kern.=warn							-/var/log/kernel/warnings
kern.err							/var/log/kernel/errors

# Протоколирование очереди печати
lpr.=debug;lpr.=info;lpr.=notice				-/var/log/lpr/info
lpr.=warn							-/var/log/lpr/warnings
lpr.err								-/var/log/lpr/errors

# Протоколирование новостей
news.=debug;news.=info;news.=notice				-/var/log/news/info
news.=warn							-/var/log/news/warnings
news.err							-/var/log/news/errors

# Протоколирование демонов.
daemon.=debug;daemon.=info;daemon.=notice			-/var/log/daemons/info
daemon.=warn							-/var/log/daemons/warnings
daemon.err							-/var/log/daemons/errors


# Критические сообщения
*.emerg								*

# Сохранять ошибки почты и новостей (уровень err и выше) 
# в отдельном файле
uucp,news.crit							-/var/log/spooler

# Заргрузочные сообщения
local7.*							-/var/log/boot.log

Как вы уже заметили, файл конфигурации состоит из двух полей: объект протоколирования и файл, в который будут записыватся сообщения, порождаемые этим объектом. Для каждого объекта можно указать один из уровней протоколирования: debug, info, notice, warn, err. Первые три относятся к информационным сообщениям. Уровень warn - это предупреждения, а err - ошибки. Существуют специальные сообщения - критические. Обычно они выводятся прямо на консоль. Как для обозначения объектов, так и для обозначения уровней протоколирования можно использовать символ *, который обозначает все объекты или все уровни. Например, вы хотите протоколировать все сообщения демонов в файл /var/log/daemons, используйте такую конструкцию: daemon.* /var/log/daemons

Пример протоколирования всех сообщений уровня emerg (критический уровень) приведен выше. Если вы хотите отправлять сообщения не в файл, а в поименованный канал (FIFO), используйте символ | перед именем файла-потока.

Сетевое протоколирование

Сейчас разберемся как обеспечить протоколирование в сети. Это означает перенаправление сообщений на демон syslogd, запущенный на другой машине, где они будут записаны на диск.

Для передачи сообщений используется протокол UDP. Он менее надежный, чем TCP, но отправление пакетов происходит несколько быстрее. Убедитесь, что в вашем файле /etc/service раскомментирована строка syslog 514/udp

Затем нужно внести некоторые коррективы в наш файл конфигурации. Как и прежде, определите объекты протоколирования, а вместо файлов протоколов используйте параметр @hostname, где hostname - это имя компьютера, на который будут перенаправлены сообщения. Например, для перенаправления всех сообщений об ошибках на узел сети hostname можно использовать такую запись:


*.err      @hostname

Для перенаправления всех сообщений используется запись:


*.*        @hostname

Имя узла желательно указать в файле /etc/hosts, так как демон syslogd может быть запущен после сервера доменных имен или сервер DNS окажется недоступным.

Вы можете организовать центральный сервер протоколирования для всей вашей локальной сети. Для того, чтобы указать какие хосты вы хотите протоколировать, используйте опцию -l список_хостов. В списке указываются простые имена машин, то есть без указания имени домена. Имена машин разделяются двоеточием (:). Возможно, вы захотите использовать опцию -s для указания дополнительного сокета для прослушивания. Для перенаправления сообщений используйте опцию -r на машине-клиенте для перенаправления сообщений на сервер (см. таблицу 1).

Демон klogd

Демон klogd предназначен для перехвата и протоколирования сообщений ядра Linux. Вы можете использовать параметры демона, указанные в таблице 3.

Таблица 3.

Параметр Описание
-c n Устанавливает уровень сообщений, которые будут выводиться на экран
-d Режим отладки
-f file Записывать сообщения в указанный файл раньше демона syslogd
-i Позволяет перезагрузить символьную информацию ядра о модулях.
-I Перезагружает статическую символьную информацию и информацию о модулях ядра
-n Не переходить в фоновый режим. Этот параметр используется, когда демон управляется программой init
-o Демон читает и протоколирует все сообщения, которые он найден в буферах сообщений ядра. После одно цикла чтения/протоколирования демон завершает работу
-s Заставляет демон klogd использовать системные вызовы для обращений к буферам сообщений ядра
-k file Использует указаный файл в качестве файла, содержащего символьную информацию ядра
-v Выводит версию и завершает работу

Для просмотра сообщений ядра используется команда dmesg. Обычно она используется так: dmesg | less

Данная программа выводит сообщения ядра при запуске системы. С помощью параметра -с этой программы можно очистить ring-буфер ядра. Параметр -n задает уровень собщений, которые будут выводиться на консоль.

По умолчанию демон klogd вызывается системным вызовом для того, чтобы препятствовать отображению всех сообщений на консоль. Это не распостраняется на критические сообщения ядра (kernel panic). Эти сообщения все равно будут отображены на консоли.

Демон реагирует на сигналы: SIGHUP, SIGKILL, SIGINT, SIGTERM, SIGTSTP, SIGUSR1, SIGUSR2, SIGCONT. Сигналы SIGTSTP и SIGCONT используются для начала и завершения протоколирования сообщений ядра. Сигналы SIGUSR1 и SIGUSR2 аналогичны опциям -i и -I соответственно. То есть первый перезагружает информацию о модулях, а второй статическую информацию и информацию о модулях. Использовать сигнал GIGUSR1(как и все остальные) можно так:


# kill -USR1 PID
Параметры ядра

Параметр debug ядра Linux задает уровень отладки. Сообщения ядра (важные и не очень) передаются через функцию printk(). Если сообщение очень важно, его копия будет передана на консоль, а также демону klogd для его регистрации на жестком диске. Сообщения передаются на консоль, потому что иногда невозможно
запротоколировать сообщение на жестком диске (например, отказ диска).
Предел того, что будет отображаться на консоли, задается переменной console_loglevel. По умолчанию на консоли отображается все, что выше уровня DEBUG (7). Список уровней можно найти в файле kernel.h