суббота, 23 мая 2009 г.

Системный эффект (или эффект домино)

Расскажу о любопытном случае, который произошёл у меня на работе.

Однажды начали происходить спонтанно странные вещи с серверами. Первое проявление возникло как будто на пустом месте: неожиданно на файл-сервере под управлением samba стала недоступна часть сетевых папок. Если в этот момент на сервере ввести команду df -h, сервер надолго задумывался, и только примерно спустя минуту-две выдавал список смонтированных разделов. Сервер перезагружать было крайне не желательно: с частью папок пользователи продолжали работать по сети, в том числе большое количество пользователей в этот момент работало с 1С.

Удалось выяснить, что нормально открывалась та часть папок, которая находилась на отдельном дисковом разделе. Команда df -h с указанием этого раздела отрабатывала моментально, а команда df -h с указанием раздела, на котором располагались недоступные папки, опять отрабатывала только через минуту-две.

Я решил принудительно отмонтировать этот дисковый раздел и смонтировать его снова: umount -f /dev/..., mount /dev/.... Заработало нормально почти всё, за исключением одной сетевой папки.

Эта папка монтировалась по протоколу smb с факс-сервера и повторно расшаривалась на файл-сервере samba. В эту папку складывались принятые факсы. Папка была не доступна из-за того, что факс-сервер перестал отзываться по сети.

Я пошёл в серверную, залогинился на сервер, но на этом вся активность факс-сервера была исчерпана. После входа explorer не запустился, а запустить его через диспетчер задач не удавалось, поскольку его попросту не удавалось вызвать по Ctrl-Alt-Del. Перезагрузил файл-сервер и смонтировал сетевой ресурс, всё заработало.

В течение недели эти глюки повторялись от одного до трёх раз в день. Каждый раз сбой происходил с небольшими вариациями: в основном samba-сервер стал работать нормально, только не хотел открывать папку с факсами, а на факс-сервере иногда запускался explorer, но сеть по-прежнему без перезагрузки не восстанавливалась.

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

Через некоторое время отключать стало нечего - в лог не ругалась ни одна из служб, а сбои продолжались. Я решил проверить сервер антивирусом, поскольку он выполнял ещё и функции файлопомойки для нашего отдела ИТ (там лежали дистрибутивы программ) и хранил различные резервные копии.

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

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

Тут в моей голове где-то появилось странное чувство, которое я не мог объяснить. Я решил прислушаться к нему. Я полез в лог факс-сервера, чтобы узнать когда в первый раз проявились сбои. Первый сбой произошёл вторник, примерно в половине третьего.

Я начал припоминать, что в обед какого-то дня на прошлой неделе начальник заменил блоки питания в телефонной станции. Я спросил у него, в какой день это было, не во вторник ли? Он ответил утвердительно. В тот день по внутренней электронной почте всем сотрудникам было отправлено письмо, о том что в обеденное время телефонная станция будет отключена на 15 минут. Я заглянул в архив своего почтового клиента и убедился, что это действительно был вторник. Я припомнил, что на прошлой неделе он говорил о каких-то проблемах, которые возникли при замене блоков питания. После замены блоков питания конфигурация станции сбросилась и её пришлось восстановить из бэкапа, предусмотрительно сделанного перед заменой.

Всё более-менее встало на свои места. Начальник во вторник на прошлой неделе заменил блоки питания в телефонной станции. Конфигурация станции сбросилась. После восстановления конфигурации настройки доступа для сбора статистики с телефонной станции по какой-то причине не восстановились. Демон сбора статистики, стоящий на факс-сервере, не мог подключиться к телефонной станции. В демоне, судя по всему, была какая-то ошибка (этот демон был написан одним из бывших сотрудников организации, поэтому наличие ошибок в нём было весьма вероятно), которая через некоторое время ставила колом факс-сервер. Факс-сервер пропадал из сети, а сервер samba не мог получить к нему доступ и начинал сам жутко тормозить.

Вот так замена блоков питания вызвала системный эффект (или эффект домино). Перестала собираться статистика по телефонным звонкам, из сети стал пропадать факс-сервер, файловый сервер на основе samba стал из-за этого жутко тормозить. Причины - глючная телефонная станция и самодельная программа, написанная вопреки правилам безопасного программирования. Последствия - нервная неделя работы одного админа, недовольство пользователей при невозможности посмотреть принятые факсы, потеряна статистика телефонной станции за неделю.

суббота, 9 мая 2009 г.

Раскручиваем свежеустановленную NetBSD

Решил записать действия по первичной настройке NetBSD, которую я гоняю в виртуалке. В отличие от привычных Linux'ов, эту систему нужно сразу после установки немного донастроить.

Для начала нужно настроить сеть. Смотрим список доступных интерфейсов:
$ ifconfig -a
В моей локальной сети есть DHCP-сервер, поэтому я настроил сетевой интерфейс по DHCP.
# dhclient ne2
Теперь с помощью консольного ftp-клиента скачаем файл ftp.netbsd.org/pub/pkgsrc/pkgsrc-2009Q1/pkgsrc-2009Q1.tar.bz2 в каталог /usr и распакуем его:
# cd /usr
# ftp ftp://ftp.netbsd.org/pub/pkgsrc/pkgsrc-2009Q1/pkgsrc-2009Q1.tar.bz2
# tar xjvf pkgsrc-2009Q1.tar.bz2
Этот архив содержит систему управления пакетами pkgsrc, аналогичную ports из FreeBSD. Суффикс 2009Q1 указывает на то, что это - первая стабильная ветка в 2009 году.

Запускаем процедуру bootstraping'а - самоустановки системы pkgsrc:
# cd /usr/pkgsrc/bootstrap
# ./bootstrap
И ждём, когда система соберёт минимальный набор инструментов для дальнейшего её использования.

В общем и целом система очень сильно напоминает ports FreeBSD:
  • Система ports располагается в каталоге /usr/ports, а pkgsrc - в каталоге /usr/pkgsrc.
  • Система ports устанавливает программы каталог /usr/local, а pkgsrc - в каталог /usr/pkg.
  • В системе ports главный конфигурационный файл находится в файле /etc/mk.conf, а у pkgsrc - в /usr/pkg/etc/mk.conf.
  • В системе ports для поиска порта используются команды make search name=<имя_пакета> и make search key=<ключевое_слово>, а в системе pkgsrc - только make search key=<ключевое_слово_или_имя_пакета>.
  • В системе ports для выбора опций сборки порта используется команда make config, а в pkgsrc доступные опции можно посмотреть с помощью команды make show-options и задать их при сборке в командной строке make, в переменной окружения PKG_DEFAULT_OPTIONS, PKG_DEFAULT_OPTIONS.<имя пакета> или прописать эти переменные в файле /usr/pkg/etc/mk.conf.
Я попробовал установить wget из pkgsrc. В виртуальной машине на копиляцию perl, digest и wget ушло около 3 часов. Мне это не понравилось, поэтому я решил попробовать воспользоваться установкой уже готовых двоичных пакетов.

Для этого найдём подходящее зеркало на странице http://www.netbsd.org/mirrors/#ftp, прописываем выбранное зеркало в переменную окружения PKG_PATH и экспортируем её:
# PKG_PATH="ftp://ftp.fr.netbsd.org/pub/pkgsrc/packages/NetBSD/i386/5.0_2009Q1/All"
# export PKG_PATH
Установим привычный bash:
# pkg_add bash
Посмотрим где он лежит:
# which bash
Пропишем его у root оболочкой по-умолчанию:
# vipw
и заменяем /bin/sh на /usr/pkg/bin/bash
Теперь настроим привычный вид приглашения, любоваться на название оболочки и номер её версии глупо - это не самая востребованная информация. Пропишем приглашение вида "пользователь@узел каталог$ " или "пользователь@узел каталог# " в зависимости от того, является ли текущий пользователь пользователем root. Для этого в файл /root/.profile пропишем строчку:
PS1='\u@\h \w\$ '
Завершим сеанс и войдём в систему снова. Будет запущен привычный bash с привычным удобным приглашением.

Ну и наконец, пропишем немного в начальную конфигурацию системы /etc/rc.conf:
hostname="netbsd.ufanet.ru"
dhclient=YES
dhclient_flags="ne2"
Ссылки:
  1. Настройка DHCP-клиента в NetBSD
  2. Список FTP-зеркал NetBSD
  3. Руководство по системе pkgsrc

понедельник, 4 мая 2009 г.

Настройка GPRS (Sony Ericsson K530i) в Linux (Debian) через Bluetooth-контроллер

В предыдущей статье я настроил доступ в Internet по GPRS через USB-кабель телефона. В той статье также описана настройка доступа через Bluetooth-интерфейс.

28 апреля я из чистого интереса к новым технологиям решил купить Bluetooth-контроллер. Я прошёлся по сайтам местных магазинов и выписал все Bluetooth-контроллеры, которые были в наличии. Их было довольно много и естественно я не знал, какой из них мне выбрать. Выбирать по внешнему виду, цвету и цене было бы глупо. Хотя, я думаю, большинство покупателей интересуют только эти характеристики :)

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

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

2. поддерживать стандарт Bluetooth 2.0 как минимум. Данный стандарт позволяет осуществлять обмен данными на скорости до 3 мегабит в секунду. Опять же, скорость обмена во многом определяется наличием перекрытий, дальностью между источником и приёмником, от зашумлённости радиосреды, от наличия в зоне радиосвязи других Bluetooth-устройств и их активности, а также снижается из-за накладных расходов на передачу служебной информации.
- иметь интерфейс USB 2.0. В принципе, USB 2.0 отличается от USB 1.0 (или 1.1) наличием дополнительной скорости приёма-передачи - 25-480 мегабит в секунду, поэтому для обслуживания радиопередатчика, работающего на скорости 3 мегабита в секунду было бы достаточно и разъёма USB 1.0 (1.1), но душе было угодно пользоваться именно USB 2.0 :)

3. поддерживать как можно больше Bluetooth-профилей. Bluetooth-профиль - это разновидность сервиса, который может поддерживать Bluetooth-устройство. Это могут быть сервисы передачи файлов (OBEX), модемный сервис (DUN), передача звуковой информации (A2DP) и тому подобные сервисы. Самое главное - должны поддерживаться синхронный (SCO) и асинхронный (ACL) режимы передачи данных. Синхронный режим предназначен для передачи аудио-информации, передаваемые пакеты в нём не подтверждаются, поэтому потерянные при передаче данные не передаются повторно. В асинхронном режиме осуществляется подтверждение приёма информации, этот режим ориентирован на передачу разнородных данных.

4. должен работать в Linux. Тут всё понятно и без слов.

Больше всего по этим параметрам мне приглянулся контроллер Tekram TM-308, который я и приобрёл в тот же день.

Итак, вставляем Bluetooth-контроллер в USB-разъём. Устанавливаем служебные программы для работы с Bluetooth-устройствами:
# aptitude install bluez-utils
И подгружаем модуль ядра для работы с Bluetooth-устройствами:
# modprobe hci_usb
Открываем на редактирование файл /etc/bluetooth/hcid.conf и приводим его к следующему виду:
options {
  autoinit yes;
  security auto;
  pairing multi;
  passkey "1234";
}
Где 1234 - PIN-код, который будет использоваться для получения доступа к компьютеру. Это может быть довольно длинный пароль из латинских букв в разном регистре, цифр и знаков препинания.

Запускаем службу Bluetooth:
# /etc/init.d/bluetooth start
Теперь нужно найти телефон. Активируем Bluettoth на телефоне. Запускаем поиск Bluetooth-устройств, находящихся поблизости:
$ hcitool scan
Должно найтись устройство, соответствующее вашему телефону. На телефоне можно выставить Bluetooth-имя устройства. Если вы не выставляли его сами, то скорее всего именем будет модель телефона.

Выписываем MAC-адрес, соответствующий телефону. MAC-адрес моего телефона - 00:21:9E:1D:A5:17, далее в статье будет фигурировать он.

Запускаем перечислтель профилей Bluetooth, поддерживаемых устройством.
$ sdptool browse 00:21:9E:1D:A5:17
В выдаче нужно найти номер канала, соответствующего профилю DUN или Dialup Networking. Если вы не нашли профиль DUN или Dialup Networking, то можно воспользоваться профилем NAP или PAN, хотя он предназначен для создания локальной сети из нескольких Bluetooth-устройств.

Теперь приведём файл /etc/bluetooth/rfcomm.conf в соответствии с найденными MAC-адресом и каналом. У меня получилось вот так:
rfcomm0 {
  bind yes;
  device 00:21:9E:1D:A5:17;
  channel 2;
  comment "Dial-up networking gateway";
}
Где 00:21:9E:1D:A5:17 - MAC-адрес телефона, а 2 - номер профиля DUN.

Проводим первичное подключение к телефону с помощью команды:
$ rfcomm connect 0 00:21:9E:1D:A5:17 2
Где 0 - номер устройства /dev/rfcomm0, 00:21:9E:1D:A5:17 - MAC-адрес телефона и 2 - номер канала DUN.

После выполнения этой команды телефон запросит разрешение на подключение со стороны компьютера. Нужно ввести PIN-код, который мы прописали в соответствие телефону в файле /etc/bluetooth/hcid.conf и указать опцию - "разрешать автоматическое подключение".

Теперь осталось исправить название устройства в файле /etc/ppp/peers/megafon и прописать вместо оставшегося там с прошлой статьи устройства ttyACM0 устройство rfcomm0.

Теперь можно установить GPRS-подключение в Интернет:
# pon megafon
Отключиться можно как и прежде:
# poff megafon
Использованные пр подготовке статьи материалы:
  1. Bluetooth - Википедия - статья в Википедии, где описаны классы и профили Bluetooth
  2. Подключение GPRS/EDGE в GNU/Linux - статья, по которой была написана моя прошлая заметка
  3. Настройка GPRS (Sony Ericsson K530i) в Linux (Debian) - моя прошлая заметка
  4. Bluesnarfing - взлом Bluetooth-устройств с помощью направленной антенны

P.S. Следует заметить, что из той же статьи на википедии явно видно, что защита соединения паролем по сути бесполезна. Она может остановить непрофессионала, однако профессионал, хорошо разбирающийся в Bluetooth, сможет в считанные секунды подобрать пароль, защищающий подключение. Это следует хорошо понимать. Главной защитой здесь может быть только достаточно большое расстояние между злоумышленником и вашими Bluetooth-устройствами. Однако опять же, судя по статье по последней ссылке, взломщики весьма изобретательны и уже существуют направленные Bluetooth-антенны, позволяющие при соответствующей наводке устанавливать связь с Bluetooth-устройствами на значительные расстояния до нескольких сотен метров.

P.P.S. Одним из интересных и, на мой взгляд, спорных моментов Bluetooth-стека в Linux, является жёсткая привязка к подсистеме D-Bus. В FreeBSD и NetBSD такой привязки нет.

Одной из особенностей современных операционных систем на базе Linux является довольно интересное противоречие подходов к разработке системы. Существует как бы два лагеря разработчиков Linux: условно назовём их системщиками и прикладниками. Системщики хорошо помнят ценности Unix и продолжают вести разработки в духе Unix, прикладники по большей части духа Unix не чувствуют и делают в основном так, чтобы было не хуже чем в Windows. Работая с Linux'ом можно понять, что существует два Linux'а: пропитанный Unix-традициями консольный неразговорчивый Linux-раб и гламурный и дружественный Linux-приятель. Если вы знаете Linux только со стороны Gnome или KDE, в большинстве случаев можно с большой уверенностью сказать, что собственно Linux вы и не знаете - вам знакома лишь его оболочка, которая совершенна ему чужда.

В последнее время наблюдается взаимопроникновение этих двух подходов разработки. Одним из таких сигналов является привязка подсистемы D-Bus к Bluetooth-стеку. Другим характерным сигналом является привязка X-сервера к уровню абстракции от оборудования HAL, тоже работающему только совместно с D-Bus. Проблема в том, что прикладники постепенно портят всё то, что нравится в Linux системщикам. Следует заметить, что эта тема волнует не меня одного. Например прямо на этой неделе в рассылке russian-debian уже поднималась эта тема:
xserver-xorg и hal

Эта тенденция довольно печальна и периодически заставляет задумываться о необходимости поиска и освоения "более других" систем...