Показать полную графическую версию : [решено] Выполнение скриптов на удаленной машине... в частности js
Всем доброго времени суток...
В данный момент проблема мною решается так:
есть скриптик который сначала компилит в exe, а затем подкидывает
выбранный скрипт перечисленным в ini-шке юзверям в служебную шару (ADMI$)..
потом запускает батничек - который по средствам psexec их там запускает. потом удаляет
из процессов и с диска.
Работает честно вам скажу "через жопу" и "через раз"... что-то да, что-то нет и в основном заморочки
с учеткой которой коннектится psexec...
Видимо я не въезжаю в суть...
но скрипт который правит реестр - срабатывает "на ура", а вот скриптик который
тупо подключает сетевой диск - тупо зависает в процессах, а если-же запустить локально -
кажет ошибку, что-то вроде "невозможно подключиться с одной машины двумя юзерами к одному ресурсу"
какие два? но не в этом суть... несмотря на то, что я явно в скрипте указываю user/password дом.админа.
Существуют-же более цивилизованные способы скриптово запускать скрипты...
Один из них через WMI его-же по мнению google правильнее всего использовать для этих целей...
Нижайше прошу, что ни будь по этому поводу объяснить, примерчик какой дать...
google - жесток :( я ни хрена не понял, хотя о WMI в общем представление имею.
Или может какие альтернативы...
или пример удаленного запуска с помощью WSH
если-же запустить локально -
кажет ошибку, что-то вроде "невозможно подключиться с одной машины двумя юзерами к одному ресурсу"
какие два? »случаем не такая ошибка?
The network folder specified is currently mapped using a different user name and password (http://support.microsoft.com/kb/938120/en-us)
Существуют-же более цивилизованные способы скриптово запускать скрипты...
Один из них через WMI его-же по мнению google правильнее всего использовать для этих целей... »
AFAIK ни один (штатный) способ не позволит скрыто перепланировать диски удаленной пользовательской сессии - для этого предназначены процедуры регистрации...
This behavior is by design.
пример удаленного запуска »
7 способов выполнить команду на удалённом компьютере (http://itband.ru/2009/11/remote-execution/)
ни один (штатный) способ не позволит скрыто перепланировать диски удаленной пользовательской сессии - для этого предназначены процедуры регистрации... »
т.е. Суть вещей как бы не предусматривает удаленное выполнение некотрых операций - таких как "мап дисков" ?
но вот например попытка запустить "calc.exe" через WMI
Set objWMIService = GetObject ("winmgmts:{impersonationLevel=impersonate}!\\" & "Zmes_01" & "\root\cimv2:Win32_Process")
Result = objWMIService.Create ("calc.exe", Null, Null, intProcessID)
Приводит к тому, что процесс-то стартует на удаленной машине, его видо в диспетчере, он висит в процессах- запущен "Администратор", но только самого calc - нет, а ведь смысл, именно в том, чтобы он запустился у конечного пользователя не так-ли?
RUVATA, смысл в том, что при удаленном подключении создается отдельная сессия,
а так как она без рабочего стола, то графические программы запускать бессмысленно
amel27,
Я в принципе догадывался :) ... но не был уверен, спасибо...
и еще один "контрольный" вопрос:
т.е. такие оперции как "мап сетвого диска" удаленно выполняются, но не отображаются у конечного пользователя?
т.е. он примонтируется в выделенной сесии, и там его можно будет его использовать?
или все таки существуют ограничения по командам которые можно выполнять удаленно...
просто практикуясь методом тыка... я единожды запустив скрипт который мапит к примеру диск J: ...
пытаясь выполнить его повторно натыкаюсь на вполне адекватную ошибку "что такой диск уже используется"... т.е. скрипт выполнил свою функцию, настараживает только то, что он зависает в процессах... ежели бы он коректно завершился, он бы выгрузился, верно?
настараживает только то, что он зависает в процессах »
тут надо смотреть конкретно... например, при запуске "CMD.EXE \\server\share\script.cmd" скрипт отработает, но останется висеть командное окно, чтобы этого не было, нужно запускать CMD с ключом /C: "CMD.EXE /C \\server\share\script.cmd"
а если это js или vbs ? они вроде бы как через WBSH (Windows Basic Script Host) должны отрабатывать, я кстати не уверен в том что я првильно мыслю:
что запуская скрипт на удаленной машине, она его сама сопоставляет с WBSH, или это тоже надо делать принудительно... т.е. запускать на ней WSH и в него в качестве параметра передавать скрипт?
RUVATA, WSH как "движок" работает на обоих концах, соответственно и скрипта два - "управляющий" (запускается локально) и "исполняемый" (запускается удаленно)... При этом удаленной машине не требуется доступ к файлу исполняемого скрипта - его код передается по протоколу DCOM непосредственно в память удаленной машины... как-то так
amel27, как вы думаете, компилирование скриптов в exe сильно меняет суть процесса ?
или допустим это изначально программа .NET к примеру, скомпилированное...
( Хотя я Java-шник, но это уже совсем другая песня :ninja2: с этим вопросом я наверное к собратьям )
И еще... а раз выделенная сессия не имеет граф.интерфеса, а вобщем-то все ошибки при помощи него отображаются,
как тогда получать информацию о состоянии, или коде ошибки, т.е. как бы иметь "вывод" ? ...
раз выделенная сессия не имеет граф.интерфеса, а вобщем-то все ошибки при помощи него отображаются,
как тогда получать информацию о состоянии, или коде ошибки, т.е. как бы иметь "вывод" ? »
у объекта WshRemote (http://msdn.microsoft.com/en-us/library/x9t3ze5y(VS.85).aspx) есть параметры Error (http://msdn.microsoft.com/en-us/library/tw2w7268(v=VS.85).aspx) и Status (http://msdn.microsoft.com/en-us/library/443b45a5(v=VS.85).aspx) для слежения за удаленным процессом
...ну и вывод в файл (скажем, на сетевую шару) никто не отменял
так а про exe все таки ?... его ситема реализует без помощи WSH, верно?
RUVATA, PsExec работает непосредственно по RPC, WMI/WSH используют DCOM (над RPC)
AFAIK .NET имеет свои механизмы удаленного запуска, но если на другом конце нет .NET можно задействовать любые доступные
обзорная статья: Эволюция связей: от RPC до .Net Remoting (http://www.pcweek.ru/themes/detail.php?ID=68996)
© OSzone.net 2001-2012
vBulletin v3.6.4, Copyright ©2000-2025, Jelsoft Enterprises Ltd.