Читаем журналы Linux #3.

Всем привет.

Показывая Как читать журналы также необходимо сказать Что именно читать. Поэтому сказав вчера "А" сегодня скажу "Б", т.е. продолжу серию заметок про журналы Linux.

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

Стандартные журналы.

По умолчанию журналы в Linux хранятся в  /var/log.

Для просмотра списка журналов, находящихся в данном каталоге, используйте команду ls -l /var/log.

Примеры журналов:

/var/log/syslog или /var/log/messages - глобальный системный журнал

/var/log/auth.log или /var/log/secure - информация об авторизации пользователей

/var/log/dmesg - оборудование и драйверы устройств

/var/log/anaconda.log - лог установки системы

/var/log/audit - лог демона auditd

/var/log/boot.log - лог загрузки системы

/var/log/cron - лог демона crond

Для каждого дистрибутива создается отдельный журнал менеджера пакетов:

/var/log/yum.log — для программ установленных с помощью yum в RedHat

/var/log/emerge.log — для ebuild-ов установленных из Portage с помощью emerge в Gentoo

/var/log/dpkg.log — для программ установленных с помощью dpkg в Debian и всем семействе родственных дистрибутивов

/var/log/mysql - логи базы данных MySQL

/var/log/apache2 - логи веб-сервера Apache

/var/log/nginx - логи веб-сервера NGINX

root@logs ~]# dmesg -l err

[1131424.604352] logs kernel: end_request: I/O error, dev sdc, sector 

[1131424.604352] logs kernel: Buffer I/O error on device sdc, logical 

[1131424.604352] logs kernel: Buffer I/O error on device sdc, logical 

Ускоряем Ansible #4.

Всем привет.

Финальная часть по ускорению сценариев Ansible.

#4 Параллелизм.

Для каждой задачи Ansible устанавливает соединения параллельно с несколькими хостами и запускает на них одну и ту же задачу параллельно. Однако Ansible необязательно будет устанавливать соединения сразу со всеми хостами -уровень параллелизма контролируется параметром по умолчанию, равным 5. Изменить его можно одним из двух способов. Можно настроить переменную среды ANSIBLE_FORKS, как это показано в примере 11.

Пример 11 Настройка ANSIBLE_FORKS

$ export ANSIBLE_FORKS=20

$ ansible-playbook playbook.yml

Можно также изменить настройки в файле конфигурации Ansible (ansible.cfg), определив параметр forks в секции default, как показано в примере 12.

Пример 12 ansible.cfg. Настройка параллелизма

[defaults]

forks = 26

Ускоряем Ansible #3.

Всем привет.

Ну что, продолжим разгон?

#3 Кэширование фактов.

Если в вашем сценарии не используются факты, их сбор можно отключить с помощью выражения gather_facts. Например:

- name: an example play that doesn't need facts 

  hosts: myhosts

  gather_facts: False 

  tasks:

# здесь находятся сами задачи

Также можно отключить сбор фактов по умолчанию, добавив в файл ansible.cfg:

[defaults]

gathering = explicit

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

В примере 7 приводятся строки, которые необходимо добавить в файл ansible.cfg для включения кэширования фактов. Значение fact_caching_tineout выражается в секундах, в примере используется тайм-аут, равный 24 часам (86 400 секундам). Как это всегда бывает с решениями, использующими кэширование, существует опасность, что кэшированные данные станут неактуальными. Некоторые факты, такие как архитектура CPU (факт ansible_architecture), редко изменяются. Другие, такие как дата и время, сообщаемые машиной (факт ansible_date_tine), гарантированно изменяются очень часто. Если вы решили включить кэширование фактов, убедитесь, что знаете, как часто изменяются факты, используемые вашим сценарием, и задайте соответствующее значение тайм-аута кэширования. Чтобы очистить кэш до запуска сценария, передайте параметр --flush-cache утилите ansible-playbook.

Скрипт очистки базы WSUS.

Всем привет.

Собственно я не планировал возвращаться к теме WSUS, так как я уже писал про него. Но на днях надо было оживлять WSUS-сервер у коллег. И главной проблемой там стало почти полное отсутствие свободного места на диске. Мой интерес к ситуации подогрелся тем что  на сервере был найден скрипт WsusCleanup.ps1 который, по непонятным причинам, не использовался.

Что он может сделать? Собственно WsusCleanup.ps1 это Powershell-скрипт очистки базы WSUS от некой фирмы "Экспресс АйТи, 2012".

Справка его гласит:

WsusCleanup.ps1 [Server] [Port] [/SSL] [/SkipGroups [group1][, group2]...]

Server -  имя WSUS. По умолчанию localhost

Port -   порт WSUS. По умолчанию 80 (443, если указан ключ /SSL)

/SSL -  использовать защищённое (SSL) соединение

/SkipGroups [group1][, group2]...  - имена групп компьютеров на WSUS, состояние установки которых не влияет на выбор заменённых обновлений.

Примеры:

WsusCleanup.ps1

WsusCleanup.ps1 Server01

WsusCleanup.ps1 Server01 1000 /SSL

WsusCleanup.ps1 Server01 /SkipGroups `"Unassigned Computers`", Deprecated

$commandLineHelp = "Наберите WsusCleanup.ps1 /? для помощи."

Не хотите его искать? Ложу его сюда, вдруг вам пригодиться. Мне пригодился, плюс еще понадобилось перегрузить web-пул самого WSUS. На будущее целесообразно включить выполнение этого скрипта на сервере по расписанию.

Успехов.

Ускоряем Ansible #2.

Всем привет.

Продолжим наши гонки с Ansible. Рассмотрим конвейерный режим выполнения задач.

#2 Конвейерный режим.

Вспомним, как Ansible выполняет задачу:

1.Генерирует сценарий на Python, основанный на вызываемом модуле.

2.Копирует его на хост.

3.И запускает его там.

Ansible поддерживает прием оптимизации - конвейерный режим, - объединяя открытие сеанса SSH с запуском сценария на Python. Экономия достигается за счет того, что в этом случае требуется открыть только один сеанс SSH вместо двух. По умолчанию конвейерный режим не используется, потому что требует настройки удаленных хостов, но мне нравится использовать его, поскольку он ускоряет процесс. Чтобы включить этот режим, внесите изменения в файл ansible.cfg, как показано в примере 3.

Пример 3 ansible.cfg, включение конвейерного режима

[defaults] 

pipelining = True

1) Настройка хостов для поддержки конвейерного режима

Для поддержки конвейерного режима необходимо убедиться, что на хостах в файле /etc/sudoers выключен параметр requiretty. Иначе при выполнении сценария вы будете получать ошибки, как показано в примере 4.