Вопрос

У меня есть несколько подчиненных машин и главная машина, на которых вместе выполняется распределенное приложение.Процессы на каждой подчиненной машине должны иметь графический интерфейс и доступ к сети (думаю, тогда это можно было бы назвать интерактивным процессом).Для простоты использования было бы неплохо, если бы главная машина могла запускать/останавливать процессы на этих подчиненных машинах.

Моей первой идеей было использовать WMI и класс Win32_Process для запуска удаленного процесса, но в ходе дальнейшего расследования выяснилось, что процессы, запущенные таким образом, неинтерактивны и изолированы и, следовательно, не могут иметь графического интерфейса.В примечании говорится, что можно использовать Win32_ScheduledJob.Create для создания удаленного интерактивного процесса, но он запускается под учетной записью LocalSystem, чего мне хотелось бы избежать (к тому же я даже не смог заставить его работать должным образом).

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

Редактировать:Когда я попробовал, PsExec работал очень неуклюже и чертовски медленно (не знаю почему).Если посмотреть дальше на PsExec, то окажется, что он устанавливает временную службу на удаленном компьютере для запуска приложения.Будет ли это единственным способом запустить интерактивный процесс, используя правильную идентификацию?Должен ли я включить вспомогательную службу в настройку узлов?Но даже тогда как бы я тогда с ним общался?

Это было полезно?

Решение

PsExec является частью пакета sysinternals, который может это сделать.

http://technet.microsoft.com/en-us/sysinternals/bb897553.aspx

Если ваши серверы работают под управлением Windows 2008, вы также можете использовать

Удаленное приложение служб терминалов

Другие советы

Вы можете использовать команду «at».

Откройте командную строку и введите

at /?

В терминал.Единственным недостатком является то, что время в удаленной системе должно находиться в пределах некоторой разумной разницы от вашего.Это тоже не мгновенно.Вам придется подождать несколько секунд, чтобы убедиться, что удаленный планировщик не пропустил событие полностью.

Для этого существует WMI-эквивалент, и он имеет те же основные предостережения, что и:

ЛИСТИНГ 3:Код для создания интерактивного процесса на компьютерах с Windows Server 2003, Windows XP и Win2K SP3

Const INTERVAL = "n"
Const MINUTES  = 1

strComputer = "compaq575"
strCommand  = "calc.exe"

Set objWMIService = _
    GetObject("winmgmts:\\" & strComputer & "\root\cimv2")
Set objScheduledJob = objWMIService.Get("Win32_ScheduledJob")

Set objSWbemDateTime = _
    CreateObject("WbemScripting.SWbemDateTime")
objSWbemDateTime.SetVarDate(DateAdd(INTERVAL, _
    MINUTES, Now()))

intReturnValue = objScheduledJob.Create(strCommand, _
    objSWbemDateTime.Value, False, 0, 0, True, intJobID)
WScript.Echo "Job ID: " & intJobID

Я думаю, что большинство других способов сделать это (без установки собственного сервиса) отключены различными пакетами обновлений из-за уязвимостей.

Следующие два поста используют .NET для выполнения удаленных процессов.

  1. Использование WMI

    http://weblogs.asp.net/steveschofield/archive/2006/06/06/WMI---start-a-process-on-remote-machine-passing-credentials_2E00_.aspx

  2. Пример кода проекта

http://www.codeproject.com/KB/IP/RemotingExec.aspx

Примеры выполняются с использованием пользовательских учетных данных, а удаленный исполняемый файл представляет собой приложение Win Form.Надеюсь это поможет.

Если вся группа находится под вашим контролем, возможно, можно будет реализовать эти удаленные процессы как службы Windows.Служба может быть интерактивной (хотя и не по умолчанию), и ею можно удаленно управлять с помощью стандартного диспетчера управления службами, работающего на каждом ПК с Windows.

Могу я спросить, почему подчиненным процессам нужен графический интерфейс?У меня аналогичная настройка, но графический интерфейс понадобился только во время первоначальной настройки.

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

Чтобы дать вам немного предыстории, приложение, которое мне пришлось распространять, было Хадсон, и это была более ранняя версия, в которой ее распространение осуществлялось путем запуска приложения Java WebStart, и, следовательно, требовался графический интерфейс (по крайней мере, во время установки, чтобы помочь в устранении неполадок).

Что я сделал, так это настроил подчиненные приложения как службы на подчиненных машинах с помощью sc.exe (это PITA, чтобы правильно разобраться, к счастью, вы делаете это только один раз).Что-то вроде:

sc.exe create SlaveService binPath= c:\path\to\slave.exe type= interact DisplayName= "The Slave Service"

Обратите внимание на пробелы после параметров (binPath= и т. д.), они необходимы.Также обратите внимание, что мне было проще отказаться от «type= взаимодействия» и вручную изменить его в сервисной консоли.

Затем на мастере, также с помощью sc.exe, запускаю сервис удаленно:

sc.exe \\slavemachine start SlaveService

И проверил, что программа работает на подчиненных машинах.

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

Надеюсь, вы найдете это полезным.

Чтобы это произошло, вам понадобится несколько компонентов.

Во-первых, вам понадобится метод связи с удаленным компьютером.

Во-вторых, вам понадобится что-то на удаленном компьютере, прослушивающее ваше приложение.

Другие предложения, прежде всего, используют что-то встроенное для одного или обоих этих компонентов, и это нормально, если ограничения любого из данных решений являются подходящими.

PsExec выглядит наиболее многообещающим готовым решением.В противном случае вы можете развернуть собственное приложение для прослушивания простых сообщений через TCP/именованные каналы/что угодно и просто запускать соответствующие подпроцессы.Единственное предостережение: вам нужно быть очень осторожным с безопасностью, особенно если какая-либо из машин находится в открытом доступе.

Пакет PSTools был разработан компанией Sysinternals и был настолько хорош, что некоторое время спустя компания была куплена Microsoft.Использование этих инструментов — лучший способ выполнить вашу задачу.

Я вижу, вы упомянули проблему с интерактивным запуском приложений.Могу ли я предложить использовать переключатель /i для интерактивного запуска приложения.PSTools предлагает все функции, которые вам нужны.Вам просто нужно поиграть с переключателями, чтобы получить желаемый результат.

Я никогда не сталкивался с той медлительностью, которую вы описываете, в своих приложениях, использующих PSTools.

МПИХ2 часто используется в кластерах высокопроизводительных вычислений и должен иметь возможность делать то, что вы хотите.Даже если вы не используете его для передачи сообщений между компьютерами, вы можете использовать его средство запуска процессов, чтобы запустить все процессы с главного компьютера.Его можно настроить для аутентификации конкретного пользователя Windows на машинах.

Лицензировано под: CC-BY-SA с атрибуция
Не связан с StackOverflow
scroll top