`

СПЕЦИАЛЬНЫЕ
ПАРТНЕРЫ
ПРОЕКТА

Архив номеров

Как изменилось финансирование ИТ-направления в вашей организации?

Best CIO

Определение наиболее профессиональных ИТ-управленцев, лидеров и экспертов в своих отраслях

Человек года

Кто внес наибольший вклад в развитие украинского ИТ-рынка.

Продукт года

Награды «Продукт года» еженедельника «Компьютерное обозрение» за наиболее выдающиеся ИТ-товары

 

"Баллистическое" оружие сисадмина

0 
 
"Баллистическое" оружие сисадмина
Так может выглядеть достаточно универсальный "баллистический" стартер скриптов. Осталось только придумать, что же такое полезное должно выполняться удаленно. Впрочем, для тестовых целей особо мудрить не нужно
"Баллистическое" оружие сисадмина
В мире Windows абсолютным чемпионом в области дистанционного управления является Windows XP, особенно версия Professional, а с недавних пор -- и Windows Server 2003 (хотя данная статья посвящена обслуживанию отдельных компьютеров, а не доменов). Тут вам и традиционное средство Telnet, и терминальное Remote Desktop, и более специализированное Remote Assistant. Однако всем им присущ один очевидный недостаток: они требуют от администратора некоей (большей или меньшей) интерактивности. Еще имеются многочисленные системные утилиты (как стандартные, так и дополнительные, распространяемые в различных Kit-ах), "обученные" работать по сети, но они обычно предназначены для решения узких задач, а комбинировать их не всегда просто. Также можно вспомнить о "тяжеловесных" (и в прямом смысле, и в переносном -- для кошелька) корпоративных пакетах вроде SMS от Microsoft, позволяющих "вытворять" почти все, что душе угодно, но...

Одним словом, все упомянутые подходы лишены "чистоты" и универсальности, поэтому матерому (и даже только матереющему) администратору совсем не помешает более глубоко освоить "аутентичные" скриптовые технологии, обеспечивающие удаленное выполнение утилит и сценариев. Речь идет, как нетрудно догадаться, о WSH (в текущей версии 5.6) и WMI. Собственно обе технологии не новы, они, скорее, ровесницы Windows 2000, однако никогда не лишне освежить свои знания, тем более, что разного рода нюансы появляются постоянно.


Windows Scripting Host

За удаленное выполнение скриптов в WSH отвечают два базовых объекта -- WshController и WshRemote, причем единственная задача первого состоит в порождении второго:

Set wshController =
WScript.CreateObject("WshController")
Set wshRemote =
wshController.CreateScript (<script_name>, <remote_name>)

Вероятно, такое усложнение объектной модели -- некий задел на будущее расширение возможностей.

Для успешного функционирования данного механизма необходимо выполнение определенных условий, в первую очередь на удаленном компьютере:
  • на нем также нужен WSH 5.6;
  • тот, кто выполняет скрипты, должен обладать здесь правами администратора;
  • строковый параметр Remote в разделе реестра HKLM\SOFTWARE\ Microsoft\Windows Script Host\Settings нужно установить в 1 (для этого можно воспользоваться сценарием, приведенным в документации www.microsoft.com/technet/scriptcenter/scrguide/sas_wsh_ ahkp.asp).
Имеется еще один нюанс: все попытки удаленного запуска скриптов с компьютера под управлением Windows XP обычно завершаются характерным сообщением об ошибке -- это связано с некорректной конфигурацией ОС. Подробно проблема описана в Microsoft KnowledgeBase (support.microsoft.com/default.aspx? scid=kb;en-us;311269), а "лечится" довольно просто:

wscript -regserver

Интересно, что этот огрех не был исправлен (случайно или умышленно?) и в Service Pack 1.

После создания "удаленного" сценария вся основная работа выполняется с объектом WshRemote. К примеру, запускается он командой

wshRemote.Execute

Затем можно следить за состоянием процесса:

Do While Not wshRemote.Status = 2
Wscript.Sleep(100)
Wscript.Echo "Пока не готово!"
Loop

Это рекомендуется делать всегда, иначе удаленный сценарий может просто не закончить свою работу (поскольку WSH по завершении деинициализирует все объекты, в том числе, видимо, и удаленные). Контролировать ход выполнения удается даже более гибко, создав обработчики событий, связанных с WshRemote:

...
WScript.ConnectObject wshRemote, "WSH_"
...
Function WSH_Start()
MsgBox "wshRemote запущен"
End Function

Последний механизм делает целесообразным и локальное применение WshController (для этого вполне достаточно просто опустить параметр <remote_name>). Таким образом можно интеллектуально управлять последовательным выполнением различных сценариев и утилит.

Отдельно стоит сказать об ограничениях описанной методики. Прежде всего удаленные скрипты не должны использовать GUI, и вообще с ними невозможен непосредственный обмен информацией. При необходимости следует применять "промежуточный" текстовый файл. Но здесь вступает в силу второе ограничение: удаленный сценарий выполняется с полномочиями удаленного же пользователя, права которого (в том числе на использование файловых ресурсов) могут не совпадать с вашими (администраторскими). Понятно, что обход каждого из этих "подводных камней" потребует определенных дополнительных усилий, однако оставлены они, совершенно очевидно, из соображений надежности и безопасности. Кстати, скрипт никогда не "материализуется" на удаленной машине (разве что в файле подкачки), его код копируется непосредственно в рабочую область памяти процесса WSH.


Windows Management Instrumentation

Впрочем, такие сложности и подробности нужны далеко не всегда. Иногда вполне достаточно дистанционно запустить какую-либо утилиту. Как ни парадоксально, но в этом случае на помощь придет WMI ("Компьютерное Обозрение", # 16, 2000). Хотя сама по себе эта технология весьма сложна в освоении, а в многочисленных объектных моделях и пространствах имен можно попросту заблудиться, она изначально обладает одним замечательным качеством -- локальная сеть для нее полностью прозрачна. Фактически вы совершенно одинаково работаете и с локальной машиной, и с удаленной. Поэтому вполне допустимо и удобно пользоваться некоторыми готовыми решениями, воспринимая их как своего рода заклинания. Кстати, в нашем случае оно совершенно короткое:

Set objWMIService = GetObject("winmgmts:" & _
"impersonationLevel=
impersonate!\\" & _
<remote_name> &
"\root\cimv2:Win32_Process")
Error =
objWMIService.Create(<program_name>, null, null, intProcessID)

В случае успеха Error будет равна 0, а intProcessID -- реальному коду созданного процесса (благодаря чему его, скажем, можно остановить с помощью утилиты taskkill).

Собственно на этом наш небольшой экскурс завершен, ибо углубляться в данную тему (как и вообще -- в системный скриптинг) можно практически бесконечно. Масса полезной информации (и готовых сценариев) находится в соответствующих разделах сайта Microsoft, например www.microsoft.com/technet/scriptcenter. И хотя освоение и применение подобных решений, возможно, потребует дополнительных усилий, заветная мечта всех сисадминов, несомненно, станет немного ближе.
0 
 

Напечатать Отправить другу

Читайте также

 
 
IDC
Реклама

  •  Home  •  Рынок  •  ИТ-директор  •  CloudComputing  •  Hard  •  Soft  •  Сети  •  Безопасность  •  Наука  •  IoT