|
|
Remote OPC или танцы с бубном |
|
Интересная мысль возникла в этой ветке. Зачастую по непонятным причинам клиент OPC не может инстацировать удаленный OPC сервер. В то время как локальный без проблем. Microsoft в основном пеняет на безопасть или проблемы с оной в системе. Но если существует установка OPC сервера на хосте клиенте и на хосте сервере, то существует возможность перенацелить прокси OPC сервера удаленного клиента на хост OPC сервера.
И о чудо, клиент который не мог подключиться к удаленному серверу начинает работать без вопросов инстанцируя удаленный OPC через локальный прокси |
|
 |
|
|
Немного позабавившись с этой возможностью я пришел к следующим выводам:
Необходимо снимать ограничения на запуск и активацию для пользователей SYSTEM Администраторы Интерактивные Лучше везде использовать тип запуска указанный пользователь Вероятно пользователю необходимо право входа как службе. Далее по логике вещей можно предположить, что при таком запуске нет необходимости иметь файлы сервера на клиенте. По всей вероятности необходимы только рунтаймы OPC. Исходя из этих соображений я предпринял попытку переноса прокси на другой удаленный хост, на котором имелась подсистема OPC (установлен Genesis32) но нет OPC сервера CoDeSys. Были перенесены следующие разделы реестра: Запись об OPC сервере 
Записи о классе и его расположении 
Затем был переопределен запускающий пользователь (пользователь и пароль переносятся но не работают пока не продублируешь на локального пользователя с корректным SID) В итоге вуаля мы имеем рабочий локальный OPC сервер для клиентов а по факту инстанцируем удаленный OPC 
|
|
|
|
|
Данный вариант сегодня мне позволил решить все имевшиеся проблемы удаленного доступа по DCOM в том числе и доступ клиента с Windows 2003 Server на OPC сервер под Windows XP Pro SP2. Причем интересное наблюдение. Утилита dcomcnfg пытается синхронизировать настройки прокси на обоих хостах одновременно, хотя имхо вне доменной архитектуры без трастовых отношений это пустая трата времени. Но тем не менее видимо маркер доступа сначала формируется на локальном хосте при запуске сервера, а затем либо подтверждается либо дублируется на удаленном в случае перекрытия или избыточности полномочий. В любом случае при наличии локального прокси связывание происходит по какой то более натоптанной тропе это очевидно.
|
|
|
|
|
Продолжаю систематизировать информацию по DCOM в целом и OPC в частности. Буду обновлять ссылку в этом топике. DCOM Help ver 1.0.0 от 24.01.2009 |
|
|
|
|
Доброго времени суток. Ситуация следующая. Сервер - WinXP SP3, группа. Клиент – WinXP SP3, домен. Настроили DCOM на сервере и клиенте. Клиент подключается к серверу. При создании группы выдается ошибка “Could not establish data callback connection on group”. После добавления переменных значения этих переменных не доступны (bad quality). При этом при задании значения переменной на клиенте оно передается на OPC и дальше на контроллер. Т.е. задавать значение можно, а считать нельзя. Как можно решить данную проблему? |
|
|
|
|
Клиент в домене, следовательно, для обмена следует использовать локального пользователя без вариантов. Раз клиент подключается к OPC и настраивает его (создает группу и подписывается на тэги) проблем с безопасностью на сервере нет, однако при попытке авторизоваться на клиенте при обратном вызове сервер получает отказ в доступе, следовательно, необходимо смотреть настройки безопасности клиента.
Дать права на запуск и активацию пользователям: SYSTEM АДМИНИСТРАТОРЫ ИНТКРАКТИВНЫЕ ВСЕ СЛУЖБА
Думаю для начала этого хватит… Планирую до конца месяца выложить на ваш суд новое издание своей справки
|
|
|
|
Прошелся по всем пунктом… №6 у меня не проходит проверку. Комп-клиент имеет доступ, а вот комп-сервер нет (пишет: «возможно у вас нет прав доступа»). При этом ip клиента пингуется, и если попытаться зайти на комп-клиент не под созданной учетной записью, а как «Администратор», то появляется приглашение на ввод логина и пароля. Если ввести параметры доменного пользователя, то доступ на комп-клиент доступен… Это по пункту№6, а после проверки остальных доступ к OPC по-прежнему
ограничен только записью значений переменных… |
|
|
|
|
Можно попробовать следующее: На обоих хостах создать пользователя с правами администратора На стороне сервера создать сетевой пароль для хоста клиента с указанием домена клиента (имеется в виду не домена в который входит клиентская машина а локальная база безопасности) Имя машины\Имя пользователя. После сохранения сетевого пароля лучше всего перезагрузить обе машины, если не уверены что нет открытых сессий. Далее запустите на сервере оснастку консоль mmc и добавьте в нее оснастку управления компьютером, выберите компьютер клиента, если оснастка подключится и покажет пользователей и группы то обратный вызов должен проходить. Обмен реализуйте под этим локальным пользователем. Также на сервере можно попробовать уровень олицетворения “олицетворение” а не идентификация, при этом сервер будет делать обратный вызов с параметрами обратившегося клиента, этот уровень используется при запуске сервера с системной учетной записью. |
|
|
|
Не совсем понятно, как это сделать. Не могли бы вы написать более подробно? |
|
|
|
|
Вот подробно из первоиточника |
|
|
|
Ответить 
|
Страница 123> |
| Переход на форум | Права доступа на форуме  Вы не можете публиковать новые темы в этом форуме Вы не можете отвечать на сообщения в этом форуме Вы не можете удалять Ваши сообщения на этом форуме Вы не можете редактировать Ваши сообщения на этом форуме Вы не можете создавать голосования на этом форуме Вы не можете выражать своё мнение в голосованиях на этом форуме |
