Application: VMware Server 2.
Почти год назад я тиснул заметку о локализации проблемы, выражающейся в том, что виртуальные машины VMware не стартовали в рабочем порядке после аварийного отключения электропитания при том, что повреждений файловой системы не детектировалось, и вообще, всё выглядело вполне себе прилично. Тогда я больше в шутку писал о трагедии администратора серверной мелкого пошиба, которому не дают денег на источник бесперебойного питания; меня лично такие ситуации не особо трогают, так как наличие ИБП - это первое, чего я добиваюсь при проработке деталей запуска того или иного сервиса, попросту не приступая к его реализации до удовлетворения минимальных требований.
Но вот, проблема показалась с новой стороны, не менее забавной. Пару лет назад обслуживание серверов в сегментах сетей частично было передано парочке сотрудников, в задачи которых входило обнаружение причин возникновения проблем связи между сервисами и клиентами, их пользующими, с последующими попытками устранения таковых проблем. Идея в том, что есть так называемые "бегунки", которые обеспечивают поддержку работоспособности сетевых рабочих станций, есть администраторы, обеспечивающие поддержку работоспособности сервисов, а для полного счастья мы ввели прослойку универсальных специалистов, не обладающих глубокими познаниями в каждой из используемых технологий, но имеющими более широкий кругозор, нежели те-же "бегунки", позволяющий оценить проблему в целом и принять меры для её устранения или выведения на более высокий уровень в предварительно обработанном виде.
Так вот, суть в том, что эти самые "специалисты" широкого профиля по первому времени ещё пытались включать свой мозг для локализации проблем, а потом энтропия, полагаю, взяла своё и методы их стали грубеть дальше-больше. "Спешиал ребут девайс" (строго вытянутый указательный палец на одной из конечностей) из последнего страшного аргумента приобрёл у них статус повседневного инструмента. В частности, для локализации выгоревшего сетевого интерфейса, засоряющего паразитным широковещательным трафиком в одноранговой сети, эти "специалисты" запросто могут выключить всё активное оборудование (и сервер тоже) и включать его по очереди, дожидаясь возобновления проблемы, с упрощённом виде используя методу "поимки льва в пустыне", да не по одному разу порой.
Пару-тройку раз вручную удалив файлы блокировки, понял, что это не дело - пора писать скрипт, компенсирующий отсутствующее у службы технической поддержки "нечто".
Первым делом инсталлируем пакет утилит поиска и обработки результатов поиска файлов:
# aptitude install findutils
Создаём скрипт, как таковой:
# touch /etc/init.d/vmware-unlock-before-start.sh
# chmod ugo+x /etc/init.d/vmware-unlock-before-start.sh
# chmod ugo+x /etc/init.d/vmware-unlock-before-start.sh
#!/bin/bash
export PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin
export LANG="en_US.UTF-8"
# Принимаем в переменные с "говорящими" именами входящие аргументы
INSTANCE=${0}
# Задаём корень, от которого будем искать файлы блокировки
PLACE="/var/lib/vmware/storage"
case "$1" in
start)
find ${PLACE} -name "*.lck" -print0 | xargs --null rm --recursive --force
;;
*)
echo "Usage: $0 {start}"
;;
esac
exit 0
export PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin
export LANG="en_US.UTF-8"
# Принимаем в переменные с "говорящими" именами входящие аргументы
INSTANCE=${0}
# Задаём корень, от которого будем искать файлы блокировки
PLACE="/var/lib/vmware/storage"
case "$1" in
start)
find ${PLACE} -name "*.lck" -print0 | xargs --null rm --recursive --force
;;
*)
echo "Usage: $0 {start}"
;;
esac
exit 0
В принципе, в скрипте всё должно быть очевидным. На пару опций обращу особое внимание:
"-print0" в "find" - указываем формировать вывод в виде строк, завершая из специальным символом "null character";
"--null" в "xargs" - указываем разбирать входящий поток на строки, не по пробелам и символам табуляции, как обычно, а по специальному символу "null character".
"--null" в "xargs" - указываем разбирать входящий поток на строки, не по пробелам и символам табуляции, как обычно, а по специальному символу "null character".
Явное использование "null character" при передаче аргументов между "find" и "xargs" нужно для того, чтобы исключить восприятие имени файла, включающее в себя пробельные и специальные символы, как не монолитное.
Теперь нужно сделать так, чтобы наш скрипт запускался только один раз при старте системы, причём до старта сервиса VMware. Система инициализации Debian отрабатывает скрипты "/etc/init.d/*" по ссылкам в директории соответствующего "ранлевела" (для Debian Lenny/Squeeze это второй уровень исполнения), последовательно, приступая к делу с тех, что начинаются с буквы "K" (условно "kill"), посылая им аргумент "stop", и заканчивая исполнением тех, что начинаются с буквы "S" (условно "start"), посылая им аргумент "start". Подсмотрим, какой порядковый номер у ссылки на сценарий запуска сервиса VMware и подберём себе нумерацию, позволяющую запустить скрипт зачистки до запуска сервиса VMware. В моём случае у VMware порядковый номер "S90", а у сервиса SSH - "S16", я подумал, что для скрипта зачистки номер "S18" будет в самый раз; после SSH, если что - сможем посмотреть, что к чему, и задолго до VMware, чтобы подготовить площадку.
Прописываем наш скрипт для определённых уровней исполнения в системе:
# update-rc.d vmware-unlock-before-start.sh start 18 2 3 4 5 .
Ну и напоследок, специально для "специалистов", деяния которых побудили меня к написанию заметки, в сотый раз прошу: "Не выключайте серверы и маршрутизаторы без явного на это указания администратора, в непосредственные обязанности которого входит обслуживание этих устройств" - не говоря уже о том, что на практике вероятность сбоя в аппаратной составляющей Cisco, Intel, HP, IBM по отношению к вероятности сбоя оборудования D-Link, TP-Link и тому подобного хлама крайне мала, просто опасно неожиданно прерывать работу любых сервисов, которые постоянно записывают рабочую и статусную информацию.