Тег ‘Linux’

Петр Зайцев и mail.ru

Интересное видео со встречи Петра Зайцева из Percona в компании mail.ru, есть некоторая интересная информация по теме оптимизации работы mysql. Рекомендую для просмотра всем системным администраторам.

Анализ проблем с буферизацией в современных TCP/IP сетях

Интересный цикл статей описывающий проблемы с буферизацией в современных высокоскоростных TCP/IP сетях. Рекомендую к прочтению всем системным администраторам.

rdesktop и переключение раскладок

Пользуюсь программой rdesktop для подключения по RDP к серверам Windows или рабочим станциям, заметил странный глюк, что при переключении раскладок сбивается биндинг некоторых клавиш, то есть вместо . пишется ю, или еще что-нибудь.

Для исправления данной ошибки необходимо создать файл /usr/share/rdesktop/keymaps/en-us.fixed со следующим содержанием:

Далее при запуске rdesktop указываем следующий параметр “-k en-us.fixed”, после этого проблемы не должно быть.

pptp_gre.c Message too long

Недавно настраивал подключение из Linux при помощи pptp клиента к Windows 2003 VPN серверу, после подключения и нескольких секунд активного использования туннеля он разрывался с ошибкой вынесенной в заголовок поста.

В результате анализа причиной оказался высокий MTU, судя по technet MTU на 2003 VPN серверах по умолчанию 1400, соответственно после выставления значения MTU = 1200 и MRU = 1192 все заработало стабильно.

Apache2.2 + mod_fcgid + php

В некоторых проектах на текущий момент использую связку Apache 2.2 + mod_fastcgi + php. Запускаемый PHP при помощи suexec работает с правами пользователя, что дает возможность перенести вопросы связанные с безопасностью и изолированностью выполняемых скриптов на уровень ОС.

В последнее время в такой связке я разочаровался, mod_fastcgi не обеспечивает приемлемый уровень производительности и надежности для WEB проектов использующих язык PHP, в итоге решил протестировать связку Apache 2.2 + mod_fcgid + php.

Ограничения mod_fcgid:

  1. 1 запрос – 1 процесс, mod_fcgid не умеет отправлять несколько паралельных запросов запущенному fastcgi процессу, в случае с PHP это и не требуется, так как для корректной работы данной связки параметр нужно использовать PHP_FCGI_CHILDREN=0.
  2. Низкая эффективность различного рода opcode кешеров, так как каждый запущенный fastcgi не имеет доступ к разделяемой памяти других fastcgi процессов (это описано в документации по mod_fcgid, пока не тестировал)

Непосредственно настройка:

Считаем, что Apache 2.2 + suexec и PHP с поддержкой FastCGI у вас установлен, далее устанавливаем libapache2-mod-fcgid и изменяем стандартную конфигурацию:

Читать полностью ‘Apache2.2 + mod_fcgid + php’ »

Интеграция Jira и ActiveDirectory

Недавно интегрировал Jira v3 с ActiveDirectory (далее AD).

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

Считаем, что вы можете успешно создать XML файл для создания пользователей в Jira, включили Jelly Runner, и можете через WEB интерфейс администрирования Jira выполнить созданный XML файл. Сама Jira у вас настроена, запускается и работает без проблем.

Для автоматизации всего процесса импорта пользователей из AD нужно сделать следующее:

Добавить в cron пользователя, с правами которого работет Jira следующую команду:

Где папка:

~ – домашняя папка пользователя, с правами которого работает Jira, подразумевается, весь дистрибутив Jira распакован в эту директорию.

SOFT/jira-ldap-userimporter-1.1 – папка, в которой находится программа для импорта пользователей из AD и создания XML файла для JellyRunner.

Скрипт buildADul.sh – простой скрипт на bash следующего содержания:

Вместо CHANGE_ME нужно указать логин и пароль пользователя Jira с правами администратора или пользователя с возможностью выполнения Jelly скриптов.

jira:login в данном случае требуется для выполнения авторизации в Jira, и создания нужных переменных в контексте выполнения Jelly скрипта, без этого вы будете получать ошибку при запуске созданного скрипта через com.atlassian.jira.jelly.service.JellyService.

Пример ошибки:

Соответственно XML файл у нас создается в нужном формате, теперь можно создать сервис по запуску данного файла в Jira. Для этого переходим в Администрирование – Services и в разделе Add Service заполняем поля следующим образом:

Имя – AD Import

Class – com.atlassian.jira.jelly.service.JellyService

Delay – 720

Жмем Add Service и в поле Input File указываем полный путь в рамках локальной файловой системы сервера до XML файла с Jelly командами. Пользователь с правами которого работает Jira должен иметь возможность прочитать данный файл.

По идее все, теперь каждые 12 часов у вас будет происходить автоматический импорт пользователей из AD. Удаление пользователей должно производиться вручную, с переносом назначенных багов на кого-нибудь другого.

Ошибка “though module compilation denied by debconf setting”

В случае если при установке VirtualBox на ОС Debian вам встретится такая ошибка:

То для ее решения нужно создать файл vboxconf со следующим содержимым:

И выполнить команду:

После этого установка VirtualBox пройдет без проблем.

EiskaltDC++ 2.0.3

После обновление Debian с lenny до squeeze сменил DC++ клиента на EiskaltDC++. Вцелом впечатления положительные: редко “падает”, интерфейс удобный, хотя немного запутанный (особенно пиктограмки), есть возможность указать персональные настройки для каждого хаба (ник, IP, etc).

Так что с LinuxDC++ пересел на него  и обратно переходить не собираюсь.

Настройка NSCA сервера для системы мониторинга Nagios

В данной заметке я напишу как настроить NSCA демона для работы системы проверки идентичности MySQL сервера.

Для корректной работы NSCA у вас уже должна быть установлена и настроена система мониторинга Nagios, то есть как минимум пробники для сервера localhost должны проверяться и отображаться корректно. Далее, необходимо установить NSCA сервер, в RHEL 5 это можно сделать командой (предварительно подключив epel репозиторий):

После установки управление демоном происходит при помощи скрипта /etc/init.d/nsca, управление конфигурацией происходит при помощи файла /etc/nagios/nsca.cfg. Необходимо проверить, что путь до command_file указан верный, либо исправить, если это не так. У меня данный параметр настрен следующим образом:

Все данные, что NSCA получает по сети он будет обрабатывать и записывать в этот файл, далее Nagios разберет полученную информацию, и, если нет ошибок, обработает и покажет в системе мониторинга.

После вышеописанных действий NSCA сервер настроен, осталось настроить клиента. Для этого устанавливаем его на сервере при помощи команды:

Конфигурационный файл /etc/nagios/send_nsca.cfg в правках не нуждается, проверить корректность работы утилиты send_nsca можно следующим образом – запустить ее со следующими параметрами:

“echo -e” – передает на через pipe утилите send_nsca специальную строку с указанием сервера, сервиса, состояния (0 – все ок, 1 – Warning, 2 – Error, 3 – Unknown), параметр -e отвечает за обработку управляющих символов, то есть \t – табуляция, \n – перевод строки.

nsca.server.hostname – DNS адрес или IP адрес сервера.

После проверки при помощи send_nsca корректной работы связки nsca client – nsca server, осталось настроить систему мониторинга Nagios.

Для этого нужно создать шаблон для сервиса с типом passive, я использую следующий:

Измените его под свои настройки Nagios, и проверте, что у вас есть timeperiod c именем never и содержимым:

Этот период задает нулевую периодичность для проверки сервисов с типом passive. После вышеописанной настройки осталось настроить сам сервис, например так:

Перезапускаем Nagios, для хоста, у которого мы настроили сервис MySQL Checksum Check он находится в состоянии pending, после отправки при помощи send_nsca сообщения указанного выше, через некоторое время он должен перейти в состояние ОК.

Название сервиса MySQL Checksum Check должно быть одинаковым как в конфигурации Nagios, так и для утилиты send_nsca, иначе Nagios не сможет обработать сообщение полученное от NSCA сервера.

Проверка идентичности MySQL Slave сервера, часть 2

В продолжение прошлой заметки – в этой напишу как автоматизировать проверку идентичности slave сервера в рамках компании.

Основной момент, это определиться с периодом проверки СУБД на идентичность, судя по моему опыту – это раз в неделю, либо после проблем с репликацией. Во всех остальных случаях, если разработчики знакомы с ограничениями MySQL при репликации данных, СУБД ведет себя достаточно стабильно.

Для автоматизации проверки я использую скрипт – mysql_consistency.sh. Скрипт достаточно простой, позволяет автоматизировать проверку СУБД на идентичность, с последующей нотификацией через систему Nagios о имеющихся проблемах.

Для его использования достаточно скачать его и скопировать в нужную вам директорию, в обязательном порядке нужно установить набор утилит Maatkit, иначе скрипт не будет работать, так как не будет необходимых программ для реализации проверки идентичности MySQL серверов.

Перед запуском скрипта необходимо указать в нем логин и пароль, при помощи которых он будет подключаться к СУБД, также, если требуется поддержка Nagios, нужно настроить следующие параметры:

nagios_support – включает/выключает поддержку Nagios.

NSCA_HOST  – определяет имя сервера, на котором установлен NSCA сервер.

После запуска скрипт запустит mk-table-checksum, который проверит master MySQL сервер, далее при помощи mk-table-sync проверит консистентность slave MySQL серверов. Если включена поддержка Nagios – скрипт отправит сообщение со статусом проверки, как положительным так и отрицательным, NSCA серверу при помощи утилиты send_nsca.

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