Каморка

vg писал(а):MarkM,

Да и насколько ето рационально, ради десятка команд сервису, городить ДЦОМ?

Издевашься? Там всё уже "за тебя" давно сделано.
Знаешь хоть что-то проще, где в одном флаконе всё?

Возможно. Почти убедил. Надо посмотреть. Подозреваю, что все накрутки ДКОМ нужны чтобы добавить ООП к РПЦ и централизовать поиск объектов в сети. В моем случае это вряд ли нужно.
Надо почитать. Если действительно ДКОМ проще, то почему бы и нет.

Mark,
Я понимаю, что я, конечно, здесь адиозная личность из стана "тупоконечников". Но не до такой же степени. Перестань издеваться.

Если ты мне объяснишь как это зависит от communication layer, то я буду благодарен.

проблема с виндовыми пайпами в том, что они не просто communication layer. к ним implicetly привязана аутентификация из чего собственно и растут все проблемы.

Позволяю. Да уверен, поскольку предыдущее приложение работала и работает в Primus'e, National Bank и еще 5-6 организациях подобного размера. А нынешнее, уже почти год работает на 5-ти 8 процессорных application server, на которых параллельно работают еще 10 других тоже resource hungry приложений.

я рад за примус и банк, но то что приложение работает на 8-ти процессорных application servers никакого отношения к наличию в ней потенциальных explot'ов не имеет. речь не о robustness, reliability или resource consumption, речь о security. так вот - корректное использование named pipes из под сервисов требует нетривиальных телодвижений с тем, чтобы этот сервис не был exploitable.

марк, слушай сюда -

если тебе нужен привязанное к виндам решение, то используй в своей консоли OpenSCManager() с именем target машины, потом OpenService() и стандартный ControlService(). плюс при установке самого сервиса пропиши требуемые access rights. всё

если тебе хочется по---ться, то реализуй rpc поверх reliable sessioned authenticated datagram layer. но траст ми типа - если ни разу не делал и нету времени, то не стоит связываться.

drain bamage,

если тебе нужен привязанное к виндам решение, то используй в своей консоли OpenSCManager() с именем target машины, потом OpenService() и стандартный ControlService(). плюс при установке самого сервиса пропиши требуемые access rights. всё

Вначале МаркК перепутал терминологически всё с сервисами. Теперь тебе вдруг показалось что МаркМ всё же имел ввиду именно сервисы/службы SCM, т.е. сервисы НТ в нормальном смысле этого слова. (хотя, как видно, имел он ввиду не службы SMC).

Кроме того, надоб тогда Марку рассказать, советуя службы, что

плюс при установке самого сервиса пропиши требуемые access rights

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

vg писал(а):drain bamage,

если тебе нужен привязанное к виндам решение, то используй в своей консоли OpenSCManager() с именем target машины, потом OpenService() и стандартный ControlService(). плюс при установке самого сервиса пропиши требуемые access rights. всё

[trn]
Pohozhe to chto nado.
Dazhe esli on ne budet vozvrashat' spisok potokov i ih statusy, to ja mogu zastavit' ego dampat' eto v DB a potom chitat' ottuda.

DKOM ja vse ravno posmotrju. TK vozmozhnostej tam pobole. Bezgranichno. No mne nemnogo nado.

[/trn]

vg писал(а): Вначале МаркК перепутал терминологически всё с сервисами. Теперь тебе вдруг показалось что МаркМ всё же имел ввиду именно сервисы/службы SCM, т.е. сервисы НТ в нормальном смысле этого слова. (хотя, как видно, имел он ввиду не службы SMC).

[trn]
Niche ja ne pereputal. Srazu napisal - "budet Servis NT". A ty kakoj podumal?
[/trn]

vg писал(а):
Кроме того, надоб тогда Марку рассказать, советуя службы, что

плюс при установке самого сервиса пропиши требуемые access rights

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

[trn]
Ne ponjal. Mne nuzhen kak raz dostup dlja upravlenija servisom. K servisu ne budut konnektit'sja usera. Tol'ko adminy, v celjah upravlenija ego rabotoj, trblshutinga i tp...
Dlaj dostupa k servisam nado imet' adminskie prava.
Mne eto poka podhodit.
[/trn]

vg писал(а):

[trn]Nashel tam tak zhe pro [/trn]Interactive Services[trn] chitaju.
Pohozhe chto eto to chto doctor propisal. Ljubopytno, mozhno li interactive okno zapuskat' na drugoj mashine. Esli net, to pechal'no. Pridetsja otkazat'sja ot interacta i rabotat' tol'ko posylaja kastom kody, a servis budet otvechat' cherez BD.
Poka tak.
[/trn]

ДКОМ я все равно посмотрю. ТК возможностей там поболе. Безгранично. Но мне немного надо.
<skip>
Ниче я не перепутал. Сразу написал - \"будет Сервис НТ\". А ты какой подумал?

Mark, если ты имел ввиду сервисы/службы SCM, то DCOM тебе не нужен Сетевой сервис и служба - это разное терминологически. Это не наезд. Правильная терминология- правильная реакция в постингах.

Ред. По-жизни пишу DEE, вместо DDE и SMC вместо SCM Блин.

vg писал(а):

ДКОМ я все равно посмотрю. ТК возможностей там поболе. Безгранично. Но мне немного надо.
<skip>
Ниче я не перепутал. Сразу написал - "будет Сервис НТ". А ты какой подумал?

Mark, если ты имел ввиду сервисы/службы SCM, то DCOM тебе не нужен Сетевой сервис и служба - это разное терминологически. Это не наезд. Правильная терминология- правильная реакция в постингах.

Ред. По-жизни пишу DEE, вместо DDE и SMC вместо SCM Блин.

[trn] Ja i ne pisal srazu chto setevoj servis pishu. Ja pisal - SERVIS NT.
No UPRAVLJAT' im hochu lokal'no i po Vindows seti.
S terminologiej u menja vse OK. Mozhesh pochitat' pervoe pis'mo.
Vse vsio ponjali pravil'no.
DCOM vrjad li nuzhen, tak kak IMHO on ne budet vypolnjat'sja v kontekste processa servisa. Ili budet? Esli net, to togda libo [/trn]ServiceControl[trn], libo paipy.[/trn]

Mark,

Я и не писал сразу что сетевой сервис пишу. Я писал - СЕРВИС НТ.

OK. Возможно я тебя не правильно понял. На то были основания. Ты написал

Будет НТ сервис.

Good.
Но дальше ты написал, что собираешься управлять сервисом, как

Чего выбрать для управления?
Mailslots
Pipes
Sockets
Другое...

Выше не было ни слова про ControlService(), т.е. чем сообщают SCM про управление собственно сервисом.

ДЦОМ вряд ли нужен

Я уже раньше пропостил , что DCOM тебе не нужен в таком случае в принципе, если ты хочешь сервайс SMC. Это совсем другое. SMC - это будет обёртка твоего приложения.

Mark,
вот весьма избитая, но, на мой взгляд хорошая статья
http://www.microsoft.com/msj/0298/service.aspx

А это даже лучше
http://msdn.microsoft.com/library/defau ... ervice.asp

vg писал(а):А это даже лучше
http://msdn.microsoft.com/library/defau ... ervice.asp

Спасибо. Ты вот лучше скажи, Интерактивный Сервис может ли показывать окна удаленно? Сервис на удаленной машине, а окно тут на моей.
А то тут явно не написано
http://msdn.microsoft.com/library/defau ... rvices.asp

Думаю, что нет. По крайней мере без гимора. Но могу ошибаться.
Интерактивный сервис имеет доступ к рабочему столу интерактивного пользователя для рабочей станции Winsta0, если она пущена под учётной записью LocalSystem и имеет флаг SERVICE_INTERACTIVE_PROCESS. Известно, что даже для служб к которым пользователь интерактится при помощи Terminal Services W2k - глючно. Если у тебя получится, напиши, как сделал. Мне интересно. Правда. То, что ты удалённо можешь посылать коды пользовательских команд - понятно (хотя даже здесь в общем случае не так всё розово, как написал drain bamage, могу ошибаться поскольку я как всегда несколько передёргиваю задачу). Но вот писать, как ты хочешь, служба будет .... куда? Думаю, никуда. Нет у неё доступа к твоему рабочему столу. Она ничего не знает про твой рабочий стол и процессы на нём. Она знает только рабочие столы своего компа. Служба не сможет по твоей команде (она-то доедет) создать на твоём рабочем столе окно и написать туда чего-нибудь.
Посмотри пример Рихтера, который я тебе пропостил. Попробуй. Попитка-непитка.

ПС. Извини неграмотного.

Неграмотного в смысле русского языка и языка программирования.