Автоматическое тестирование исправлений
Прежде чем приступать к развертыванию исправлений, их необходимо протестировать, чтобы не нарушить функциональность системы. Однако число исправлений для всего многообразия продуктов и их версий так велико, что процесс тестирования должен быть максимально автоматизированным. В данной статье речь пойдет о том, как организовать лабораторию и тестировать исправления с помощью сценариев, которые помогают обнаружить ошибки быстро и с минимальным количеством операций, производимых вручную.
Как построить тестовую лабораторию
Тестовая лаборатория должна быть миниатюрной копией леса Active Directory (AD). Чтобы избежать лишних расходов, можно сымитировать аппаратные средства с использованием программ VMware Workstation или Microsoft Virtual PC 2004, а затем установить полнофункциональные операционные системы и приложения. Виртуальные системы могут обмениваться данными по физической сети и образовать реальный лес AD.
Для лаборатории необходимо иметь по крайней мере две машины Pentium 4, каждая из которых оснащена оперативной памятью объемом 2 Гбайт и жестким диском емкостью 120 Гбайт. Память большой емкости и мощный процессор необходимы, так как на одной физической системе будет одновременно размещаться несколько виртуальных систем. Дополнительное дисковое пространство предназначено для хранения нескольких десятков файлов образов виртуальных машин (VM), которые придется создать. Чтобы убедить руководство предприятия в эффективности лаборатории, следует подготовить технико-экономическое обоснование и показать убытки, которые причиняет один-единственный сбой, вызванный неудачной программой коррекции. Стоит упомянуть и о других применениях лаборатории, например для обучения администраторов, испытаний обновленных программных продуктов, моделирования изменений в групповых политиках и других программных тестов.
Приступая к устройству лаборатории, нужно иметь по крайней мере один экземпляр каждой операционной системы, работающей в локальной сети, а затем добавлять новые виртуальные машины для различных версий и конфигураций пакетов обновлений по мере необходимости. Сначала следует установить важнейшие для предприятия программы в соответствующих образах виртуальной машины, а затем построить специальные образы для систем Microsoft Exchange Server, Microsoft IIS и Microsoft SQL Server.
В идеальном случае лес AD в лаборатории должен содержать те же домены, доверительные отношения, зоны DNS и объекты групповой политики (Group Policy Objects, GPO), что и реальный лес. Я рекомендую дать лабораторным доменам имена, образованные от имен реальных доменов, на случай, если потребуется организовать взаимодействие между виртуальными и реальными лесами, и не заводить много учетных записей, чтобы сократить размер базы данных AD.
С помощью новой консоли управления Group Policy Management Console (GPMC) можно экспортировать объекты GPO из производственного леса и импортировать в лабораторный. Более подробную информацию о GPMC и ее функции импорта можно найти в статье «Консоль управления групповой политикой для Windows Server 2003», опубликованной в Windows & .NET Magazine/RE № 6 за 2003 г. Можно также экспортировать метабазу корпоративного сервера Internet Information Services (IIS) 6.0 и импортировать в лабораторный Web-сервер, о чем рассказано в статье «Что может IIS 6.0», Windows & .NET Magazine/RE № 4 за 2003 г. Можно даже восстановить резервные копии состояния системы производственных серверов на соответствующих серверах в лаборатории.
Наряду с развертыванием леса, в лаборатории нужно установить инструментарий развертывания исправлений — например, Microsoft Systems Management Server (SMS), Microsoft Software Update Services (SUS), специальные сценарии или продукты независимых поставщиков. Затем следует использовать это решение для установки исправлений в лабораторных условиях.
Как правило, исправления удобнее тестировать и развертывать группами. Испытывать и применять важнейшие исправления на подключенных к Internet серверах необходимо как можно быстрее, но задействовать обычные исправления по одному нерационально. Microsoft выпускает важные исправления во второй вторник каждого месяца, поэтому стоит согласовать цикл тестирования и развертывания исправлений с графиком Microsoft.
Системные и сетевые тесты
После того как лаборатория будет готова, можно начинать тестирование новых исправлений. В сущности, метод испытания состоит в запуске сценария, который выполняет различные тесты, записывает результаты в текстовый файл, применяет исправления, вновь запускает тесты, сохраняет результаты во втором файле и сравнивает два файла в поисках расхождений. Файлы должны быть одинаковыми. Если они отличаются друг от друга, значит, что-то изменилось после применения исправлений, и необходимо установить причину.
В первую очередь в сценариях нужно предусмотреть проверки базовых сетевых функций связи. Следует запустить файл baseline.bat (листинг 1) на тестовой системе, на которой предстоит установить исправление, и перенаправить вывод в текстовый файл следующей командой:
baseline.bat > before.txt
Затем нужно применить исправления, перезагрузиться и вновь запустить командный файл, направив вывод в другой файл:<> baseline.bat > after.txt
Сравнив два выходных файла с помощью команды сравнения файлов,
fc.exe /l /n before.txt
after.txt
можно быстро обнаружить различия. Командный файл полезно дополнить другими инструментами, чтобы расширить его функции. Выходные данные этих инструментов нужно обязательно отфильтровать с помощью такой утилиты, как findstr.exe, чтобы незначительные различия в выходных файлах не вызвали ложной тревоги. Вместо fc.exe, сравнить выходные файлы можно с помощью графического инструмента, в частности windiff.exe из вспомогательного комплекта Windows 2000 Server Support Tools.
Команда gpresult.exe в файле baseline.bat специально предназначена для того, чтобы передавать различные результаты в файлы before.txt и after.txt. Этот инструмент точно определяет время, когда система в последний раз обрабатывала GPO. Данная информация позволит проверить корректность групповой политики.
Достоин внимания и еще один компонент baseline.bat — netdiag.exe, инструмент из комплекта Support Tools, который автоматически выполняет более десятка сетевых тестов. Если запустить его в режиме расширенного вывода (с ключом /v), можно получить подробные сведения о конфигурации и диагностическую информацию о неполадках соединения, вызванных исправлением.
После того как на лабораторной системе будет выполнен baseline.bat, на удаленной системе следует запустить файл remote.bat (листинг 2) для проверки возможностей дистанционного управления лабораторной системой. Для запуска всех инструментов remote.bat удаленный компьютер должен функционировать под Windows Server 2003 или Windows XP, но целевая система может работать под Windows 2000. Утилита rpcdump.exe используется для проверки удаленного доступа ко всем конечным точкам RPC (remote procedure call — вызов удаленных процедур), wmic.exe тестирует доступ по DCOM (Distributed COM) к службе Windows Management Instrumentation (WMI), schtasks.exe взаимодействует с Task Scheduler, net.exe присваивает символьные обозначения дисков административным ресурсам C$, а mstsc.exe обеспечивает подключение к Terminal Services/Remote Desktop по RDP для сеансов тонких клиентов. Для тонкого клиента следует создать и сохранить файл с именем target.rdp, содержащий IP-адрес целевой машины, имя пользователя и пароль, а затем передать имя файла клиенту в качестве первого аргумента. При запуске командного файла на экране появляется окно тонкого клиента, визуально подтверждающее, что администратор автоматически зарегистрирован на удаленной настольной системе. Затем, как и в случае с baseline.bat, следует создать файлы before.txt и after.txt на удаленной системе и сравнить их с помощью fc.exe.
Наконец, если в производственной локальной сети используется протокол IP Security (IPSec), то его необходимо применять и в лаборатории. Если IPSec применяется для доступа по VPN, следует убедиться, что установлена обновленная версия NAT-T (Network Address Translation-Traversal — преобразование-передача сетевых адресов) компании Microsoft (как описано в статье Microsoft «L2TP/IPSec NAT-T Update for Windows XP and Windows 2000», http://support.microsoft.com/?kbid=818043). Прежде чем развертывать исправления в производственной локальной сети, необходимо не только протестировать те исправления, которые могут повлиять на драйвер IPSec, но и запланировать лабораторное тестирование изменений в конфигурации IPSec. Ошибка при конфигурировании может привести к зависанию сотен машин (а также к увольнению администратора).
Важнейшие приложения и службы
Наряду с сетевыми соединениями и дистанционным управлением необходимо протестировать важнейшие для предприятия приложения и службы, в том числе обработку групповых политик. Начать следует с активизации на лабораторных компьютерах всех функций протоколирования, существующих в приложениях и службах, в том числе всех политик аудита и отладочного протоколирования в DNS, RRAS, Certificate Services, SQL Server и Exchange Server. Если исправление вызовет какие-то нарушения, то в распоряжении администратора будут пригодные для поиска журналы аудита, с помощью которых можно обнаружить и диагностировать неполадки.
Для записи подробной информации Group Policy в журнал Application следует присвоить значение 1 параметру RunDiagnosticLoggingGroupPolicy типа REG_DWORD в разделе HKEY_LOCAL_MACHINESOFTWAREMicrosoftWindows NTCurrentVersionDiagnostics реестра (вероятно, для этого придется создать как параметр, так и раздел Diagnostics). Данная процедура описана в документе Microsoft «Troubleshooting Group Policy In Windows 2000» (http://www.microsoft.com/windows2000/ docs/gptshoot.doc). Если требуется еще более подробная информация, то можно активизировать протоколирование пользовательской среды, как описано в статье Microsoft «How to Enable User Environment Debug Logging in Retail Builds of Windows» (http://support.microsoft.com/?kbid=221833).
После активизации протоколирования во всех этих службах следует убедиться в отсутствии неполадок, а затем очистить журналы и применить исправления. Чтобы быстро стереть текстовый журнал (не журнал событий!) или создать пустой текстовый файл, можно выполнить команду
echo 1>nul 2>c:logfile.txt
где 1>nul перенаправляет стандартный выход команды Echo в никуда, а 2>c:logfile.txt перенаправляет стандартные сообщения об ошибках в указанный файл, перезаписывая старые данные или создавая файл, если он отсутствовал.
Для очистки журналов событий Windows можно запустить командный файл со следующими командами:
cscript.exe ClearEventLog.vbs
127.0.0.1 Application
cscript.exe ClearEventLog.vbs
127.0.0.1 Security
cscript.exe ClearEventLog.vbs
127.0.0.1 System
чтобы вызвать сценарий ClearEventLog.vbs (листинг 3). Первый аргумент каждой команды представляет собой IP-адрес или имя компьютера (локального или удаленного), журнал событий которого следует очистить, а второй аргумент — имя журнала. Следует также очистить журналы событий для DNS, AD и других служб, если они существуют.
Очистив журналы, можно начать с чистого листа, устанавливая исправления на тестовых компьютерах, запуская приложения и повышая нагрузку на службы, чтобы вызвать ошибки. Следует проверить все функции, которые запускаются пользователями в процессе работы, обращая особое внимание на сеть, печать, безопасность, доступ к файловой системе и любые другие уязвимые компоненты (в основном те, которые отличались уязвимостью в прошлом).
Например, можно составить командный файл, который будет исполнять команду
winword.exe C:file.doс
Одновременно с запуском Microsoft Word будет автоматически открыт file.doc. В file.doc следует создать макрокоманду с именем AutoOpen, которая распечатывает документ на удаленном принтере, сохраняет копию файла в общей папке или папке службы WebDAV (Web Distributed Authoring and Versioning), преобразует документ в локальный .pdf-файл Adobe Acrobat от Adobe Systems и выполняет другие действия. Открывая файл, Word должен автоматически запустить макрокоманду с названием AutoOpen. Для подготовки макрокоманд Microsoft Office программирования обычно не требуется; например, в Word XP и Word 2000 нужно перейти к пункту Macro в меню Tools, выбрать Record New Macro, присвоить макрокоманде имя AutoOpen, сохранить ее в текущем документе (не в шаблоне), а затем выполнить необходимые действия. Word запишет нажатия клавиш и щелчки мыши за пользователя. В Microsoft Excel XP и Excel 2000 макрокоманду следует назвать Auto_Open, чтобы Excel запустил ее при открывании файла, содержащего макрокоманду. Проверьте, имеются ли похожие функции автоматизации в программах других поставщиков, применяемых на предприятии.
Следует выяснить, какие аргументы командной строки воспринимают приложения, и стараться максимально использовать эти аргументы в командных файлах. В некоторых приложениях очень многие функции доступны через аргументы командной строки. Но даже если требуется протестировать функции, которые можно ввести только вручную через графический интерфейс, выход может быть найден. В сценарии keystrokes.vbs (листинг 4) показано, как использовать метод SendKeys() для перенаправления нажатий на клавиши в графический интерфейс. Рекомендую обратить внимание на команды, вводимые в процессе тестирования программы с графическим интерфейсом, — не забывайте о клавише Alt, с помощью которой можно раскрывать меню, — и организовать ввод тех же команд из сценария.
Как видно из листинга keystrokes.vbs, метод AppActivate(«App Title>») задает приложению с именем App Title указание на ввод, чтобы нажатия на клавиши в сценарии были переданы в нужное приложение. Метод Sleep (Milliseconds) согласует действия приложения со сценарием, заставляя его ждать определенное число миллисекунд перед продолжением работы. В комментариях keystrokes.vbs указаны специальные и часто используемые клавиши и комбинации клавиш. После некоторой отладки методом проб и ошибок большинство графических приложений можно настроить на работу без участия оператора.
С помощью других сценариев можно создать удаленную нагрузку на службы. Для этого следует запустить на удаленной системе приложения, которые взаимодействуют с тестируемой службой на целевой лабораторной системе. В справочных файлах для Support Tools и комплектов ресурсов Microsoft приведены алфавитные списки инструментов и их описания. Проверить IIS-серверы можно с помощью таких имитаторов нагрузки, как Application Center Test (ACT). Он описан в статье Microsoft «INFO: Application Center Test (ACT) Tests Your Web Applications by Simulating Load» (http://support.microsoft.com/?kbid=307492).
При запуске командных файлов и других сценариев, создающих нагрузку на службы, можно заметить некоторые ошибки, такие как «голубой экран смерти» или зависший указатель мыши. Но некорректное функционирование ряда служб никак не проявляется внешне, они лишь регистрируют свои ошибки в одном или нескольких журналах. Просмотр журналов вручную — слишком утомительное занятие, неизбежно связанное со множеством ошибок, и потому такой метод непрактичен. Гораздо эффективнее вести поиск в журналах с помощью инструментов и сценариев, которые автоматически извлекают сообщения об ошибках, предупреждения и другую интересную информацию.
В текстовых журналах поиск вести легко. Утилита findstr.exe из состава Windows извлекает из файлов строки, соответствующие указанным пользователем образцам, в том числе простым регулярным выражениям. Сначала следует проанализировать типичные текстовые журналы, генерируемые службой, и отыскать все строки (например, Fail, Error или 500), указывающие на неполадки. Эти последовательности построчно следует сохранить в текстовом файле с именем signatures.txt. Для каждого регулярно проверяемого типа журнала требуется отдельный файл сигнатур. Затем с помощью команды
findstr.exe /g:signatures.txt
logfile.log > output.txt
следует отыскать в текстовом журнале все строки, содержащие хотя бы один из этих шаблонов, и перенаправить их в выходной файл. Если размер файла output.txt превышает 0 байт, значит, возникли неисправности, которые необходимо исследовать. Более подробная информация о файле findstr.exe приведена в разделе Command Line Reference в Windows Help. По адресу http://www.regular-expressions.info/tutorial.html опубликовано руководство по регулярным выражениям и инструменты, значительно более мощные и удобные для пользователя, чем findstr.exe.
Двоичные журналы событий удобно преобразовать в простой текстовый формат и также провести в них поиск с помощью findstr.exe. Утилита dumpel.exe из комплекта Microsoft Windows 2000 Resource Kit преобразует данные журнала событий в текст с разделением табуляторами, который можно направить в findstr.exe. Например, сценарий dumplog.bat (листинг 5) содержит команды для извлечения только сообщений об ошибках и предупреждений из журналов Application и System и только аудиторскую информацию о сбоях из журнала Security. Ключ /R в сценарии указывает, что необычного вида поисковая строка представляет собой регулярное выражение. Можно воспользоваться встроенным сценарием XP, EventQuery.vbs, чтобы извлечь только предупреждения и сообщения об ошибках или только аудиторскую информацию о сбоях (листинг 6). Если активизировано протоколирование процедуры отладки Group Policy (как упоминалось ранее), то можно получить очень много сообщений об ошибках из источника Userenv в журнале Application, поэтому полезно отключить протоколирование или хотя бы отфильтровать эти записи. Кроме того, при интенсивной работе с командными окнами следует изменить стандартное имя Windows Script Host (WSH) с wscript.exe на cscript.exe; для этого нужно ввести команду
cscript.exe //h:cscript
//nologo //s
Пригодность для аудита
В процессе тестирования необходимо убедиться в возможности дистанционной проверки имеющихся исправлений. Недостаточно запросить реестр удаленной системы и увидеть, что исправление было когда-то установлено (например, с помощью утилиты srvinfo.exe из набора ресурсов Windows 2000); инструмент аудита должен проверить версии файлов на жестком диске.
Если загружаемая XML-база данных об исправлениях Microsoft содержит информацию о тестируемых программах коррекции, то выполнить проверку легко, так как с этой базой данных работают многие инструменты (например, HFNetChk компании Shavlik Technologies, Microsoft Baseline Security Analyzer — MBSA). Но если в XML-базе данных информации об исправлениях нет, то необходимо использовать SMS или специальные сценарии для проверки версии обновленных файлов на диске. Для этой цели можно составить сценарий на основе программы filever.exe (из пакета Support Tools for Windows 2003, XP или Windows 2000), которая выдает подробную информацию о версиях файлов. Если нет времени для проверки незначительных исправлений, то по крайней мере следует проверить наиболее важные.
Некоторые компании предоставляют специализированные инструменты аудита для самых уязвимых мест сетей — например, сканеры Microsoft для «червей» Blaster и Slammer, описанные в статьях «How to Use the KB 824146 Scanning Tool to Identify Host Computers That Do Not Have the 823980 (MS03-026) and the 824146 (MS03-039) Security Patches Installed» (http://support.microsoft.com/?kbid=827363) и «SQL Server 2000 Security Tools» (http://support.microsoft.com/?kbid=813944), а также сканеры фирмы eEye Digital Security для Nimda и CodeRed (http://www.eeye.com/html/research/tools). Но не следует рассчитывать, что такие инструменты будут всегда своевременно поступать потребителям.
Отмена исправлений
Необходимо также проверить метод отмены установки некорректных исправлений. Неэффективно использовать утилиту Add/Remove Programs панели управления для удаления исправления на каждой отдельной системе; поэтому следует выбрать решение для автоматизированной отмены исправлений. Если решение не поддерживает отмены исправлений, то, по крайней мере, можно будет дистанционно запустить процедуру удаления.
В процессе установки большинства исправлений Microsoft создается папка %system root%$ntuninstallpatchnumber$sp-uninst, где patchnumber — номер статьи Microsoft, в которой документировано исправление. В этой папке находится программа spuninst.exe. При запуске из командной строки с ключом -u она удаляет исправление, с ключом -q — закрывает все приложения, а с ключом -f — перезагружает систему. Выполнить эту программу со всеми необходимыми ключами можно различными способами; например, использовать специальный сценарий, доставляемый через Group Policy, задействовать schtasks.exe для дистанционного планирования задания по расписанию, применить сценарий WMI (например, exec.vbs из комплекта ресурсов) для запуска команд на удаленных компьютерах или воспользоваться программой PsExec компании Sysinternals. В 2004 г. Microsoft начнет выпускать исправления .msi, совместимые с Windows Installer 3.0, и в них будет предусмотрен механизм отмены.
После того как исправление удалено, следует проверить возможности дистанционного управления системой с помощью описанных выше сценариев и методов. Установка исправлений может привести к проблемам, но попытка удаления иногда вызывает крах системы, и лучше справляться с этой проблемой в лаборатории, чем в производственной среде.
Испытания на практике
После завершения лабораторных тестов приходит время «испытаний на пациентах», то есть новые исправления применяются на некотором множестве производственных систем перед развертыванием исправлений на всех компьютерах. Лучшими тестировщиками здесь будут программисты и другие сотрудники, обладающие знаниями в области ИТ, так как они часто работают с новыми программами, готовящимися к развертыванию, и скорее заметят мелкие неполадки. Необходима по крайней мере дюжина компьютеров, поскольку для испытаний требуется репрезентативный набор операционных систем, версий пакетов обновлений, приложений и сетевых служб. Развернув исправления на этих компьютерах, можно отслеживать проблемы и жалобы пользователей, и если неполадок нет, приступать к поэтапному внедрению исправлений на всем предприятии. Некоторые администраторы возразят, что у них нет времени для подобного тестирования важнейших исправлений, но при недостатке времени испытания на «подопытных кроликах» можно сократить всего до нескольких часов, так как серьезные проблемы обычно проявляются сразу после установки некорректных исправлений.
Реальные испытания следует провести и на производственных серверах, но сначала необходимо сделать полные резервные копии «подопытных» серверов (например, Web, почтового, контроллера домена DC, принт-сервера) и применять исправления к этим машинам строго по одному. Чтобы обеспечить круглосуточную готовность при частом развертывании исправлений, очень пригодятся кластеризация с резервированием и служба балансировки нагрузки Windows NT Load Balancing Service (WLBS).
Не следует забывать, что многие администраторы сталкиваются с похожими проблемами. Можно просмотреть тематические конференции, посвященные применяемым на предприятии продуктам (такие конференции, в частности, организованы по адресу http://groups.google.com), и подписаться на соответствующие рассылки по проблеме исправлений, такие как NTBugtraq (http://www.ntbugtraq.com) или список управления исправлениями по адресу http://www.patchmanagement.org. Это позволит почерпнуть массу полезной информации от своих коллег, а обнаружив в ходе тестирования ошибки в исправлениях — поделиться опытом со всем сообществом ИТ.