[windows server] service vs application
По большому счету, все, что дает сервис - запуск процесса от системного пользователя, и наличие фреймворка на автостарт/авторестарт сервиса и контроль его состояния.
Если по мнению коллег, написание подобных велосипедов проще, чем написание связи между ГУИ-сервис, то фиг ты их убедишь.
В общем-то, даже ГУИ приложение можно запускать под локал систем как сервис, и более того при логине оно появится на твоем десктопе.
Так что, по большому счету, кроме доводов "это некрасиво" и "вам придется краснеть за ваш код", других особо не придумаешь.
Если по мнению коллег, написание подобных велосипедов проще, чем написание связи между ГУИ-сервис, то фиг ты их убедишь.
В общем-то, даже ГУИ приложение можно запускать под локал систем как сервис, и более того при логине оно появится на твоем десктопе.
Так что, по большому счету, кроме доводов "это некрасиво" и "вам придется краснеть за ваш код", других особо не придумаешь.
даже ГУИ приложение можно запускать под локал систем как сервиса ты порбовал?
Да. У меня в свое время в общаге так жил винамп и регет.
и что, каццно контроллировалась работа?
или ты пользовался какой-то ещё приблудой для этого?
или ты пользовался какой-то ещё приблудой для этого?
идея была не в контроле
идея была в том, чтобы винамп и регет выживали между постоянными релогами юзеров. на компе стояла вин2к3 и поэтому фаст юзер свитчинг там и не пахло, а на комп было три человека желающих =)
идея была в том, чтобы винамп и регет выживали между постоянными релогами юзеров. на компе стояла вин2к3 и поэтому фаст юзер свитчинг там и не пахло, а на комп было три человека желающих =)
сервис - это стандартно
отсюда вытекает следующие виды плюсов:
для сервиса уже многое есть готовое, причем это готовое уже все знают, и под это готовое уже написана куча утилит, программ и т.д.
1. сервис не требует пользовательской сессии (а бесплатных сессий всего 3, а остальные за деньги)
2. запуск сервиса можно настроить при старте машины (это актуально - т.к. перезапуск windows-а может быть настроен в автоматическом режиме при пропадании питания, получения нового обновления и т.д. и в этом случае рядом не будет человека, который сможет запустить gui-ишную прогу.
3. сервис можно штатными средствами запустить, остановить, перезапустить.
4. штатными средствами можно настроить, что происходит в случае отказа сервиса (через какое время делается перезапуск, какое кол-во попыток и т.д.)
5. системые события по сервису такие как (запуск, останов, сдыхание и т.д.) пишутся в системный журнал
6. сервис более безопасен, т.к. его проще запускакть под подпользователем с ограниченными правами.
7. сервисом можно управлять удаленно (не логинясь на машину) через mmc
8. сервис имеет готовый gui по мониторингу и управлению: mmc
9. сервис имеет готовый api по управлению и мониторингу, как из командной строки net start/stop, так и из script-овых языков, так и из полных языков.
10. есть куча утилит (как маленьких, так и больших) - которые собирают инфу о "здоровье" корпоративной IT-среды, соответственно модуль по мониторингу сервисов у них уже есть готовый.
ps
в литературе по безопасности советуют исключать gui-ишную часть из сервера, т.к. gui-ишную часть проще атаковать.
отсюда вытекает следующие виды плюсов:
для сервиса уже многое есть готовое, причем это готовое уже все знают, и под это готовое уже написана куча утилит, программ и т.д.
1. сервис не требует пользовательской сессии (а бесплатных сессий всего 3, а остальные за деньги)
2. запуск сервиса можно настроить при старте машины (это актуально - т.к. перезапуск windows-а может быть настроен в автоматическом режиме при пропадании питания, получения нового обновления и т.д. и в этом случае рядом не будет человека, который сможет запустить gui-ишную прогу.
3. сервис можно штатными средствами запустить, остановить, перезапустить.
4. штатными средствами можно настроить, что происходит в случае отказа сервиса (через какое время делается перезапуск, какое кол-во попыток и т.д.)
5. системые события по сервису такие как (запуск, останов, сдыхание и т.д.) пишутся в системный журнал
6. сервис более безопасен, т.к. его проще запускакть под подпользователем с ограниченными правами.
7. сервисом можно управлять удаленно (не логинясь на машину) через mmc
8. сервис имеет готовый gui по мониторингу и управлению: mmc
9. сервис имеет готовый api по управлению и мониторингу, как из командной строки net start/stop, так и из script-овых языков, так и из полных языков.
10. есть куча утилит (как маленьких, так и больших) - которые собирают инфу о "здоровье" корпоративной IT-среды, соответственно модуль по мониторингу сервисов у них уже есть готовый.
ps
в литературе по безопасности советуют исключать gui-ишную часть из сервера, т.к. gui-ишную часть проще атаковать.
идея была в том, чтобы винамп и регет выживали между постоянными релогами юзеров. на компе стояла вин2к3 и поэтому фаст юзер свитчинг там и не пахло, а на комп было три человека желающих =)можно было запустить еще одну сессию (через зайти локально, а потом зайти еще раз, но через RDP).
соответственно RDP-ишная сессия жила бы вечно (до явного прибития, или перезапуска)
2. запуск сервиса можно настроить при старте машины
Это можно и для обычного приложения сделать - просто шорткат в стартап кинуть.
6. сервис более безопасен, т.к. его проще запускакть под подпользователем с ограниченными правами.
а как из этого следует безопасность? Я бы наоборот подумал, что это менее безопасно.
10. есть куча утилит (как маленьких, так и больших) - которые собирают инфу о "здоровье" корпоративной IT-среды, соответственно модуль по мониторингу сервисов у них уже есть готовый.
а можно примеры?
gui-ишную часть проще атаковать.По-подробнее можно? Каким образом?
Это можно и для обычного приложения сделать - просто шорткат в стартап кинуть.в startup чего?
а как из этого следует безопасность? Я бы наоборот подумал, что это менее безопасноправильный сервис по умолчанию запускает под network_service
а у network_service на столько урезаны, что даже если сервис атаковали и он полностью захвачен, то это никак не поможет получить доступ над компьютером где развернут этот сервис.
gui-ишная же прога обычно запускается под админским юзером, в крайнем случае - под юзерским.
По-подробнее можно? Каким образом?атака возможна если есть другой логин на этой же машине
http://www.compulenta.ru/2002/8/8/33090/
в startup чего?Я имею ввиду меню Start -> programs -> startup.
Так же можно через реестр такое сделать.
атака возможна если есть другой логин на этой же машине
В моем случае это не актуально - сервак будет стоять в стойке датацентра.
А еще он будет использоваться исключительно для работы этой программы, так что если программу взломают, то уже неважно что потом взломщик может натворить в системе.
З.Ы. зря я наверное в девелопменте создал... наверное тема ближе к H&S
то уже неважно что потом взломщик может натворить в системе1) Получить более лёгкий доступ к другим компам
2) Рассылать спам, вирусы
3) Саботировать работу сети
Я имею ввиду меню Start -> programs -> startup.а логин кто будет запускать?
Так же можно через реестр такое сделать.
а можно примеры?например, такой зверь как IBM Tivoli Netcool (бывший Micromuse Netcool)
Я имею ввиду меню Start -> programs -> startup.а дальше будет изобретание велосипеда
Так же можно через реестр такое сделать.
1. во первых, как сделать чтобы не запускался второй экземпляр - если на машине умудрулись запустить две сессии того пользователя у которого в startup-е стоит запуск
2. во-вторых, как определить, что программа по каким-то причинам вылетела/закрылась и т.д., и ее надо запустить заново.
Думаю, теперь кол-во и качество аргументов меня пожалуй удовлетворяет и можно идти убеждать.
Спасибо!
Спасибо!
можно было запустить еще одну сессию (через зайти локально, а потом зайти еще раз, но через RDP).Так и делалось поначалу. Но винампом и регетом хотелось управлять из любой сессии. Потому в итоге был реализован вариант с сервисом.
соответственно RDP-ишная сессия жила бы вечно (до явного прибития, или перезапуска)
Оставить комментарий
dangerr
В конторе где я работаю пишется некое клиент-серверное приложение высокой сложности. В качестве платформы для сервера к моему глубокому сожалению была выбрана Windows Server. Я пишу клиентскую часть, поэтому это казалось бы меня не должно волновать. И это меня не волновало, пока я не увидел, что сервер представляет собой гуи-приложение, что расходится с моим представлением о серверных приложениях для windows. Однако, на вопрос а почему же не сервис мне ответили вопросом же "А чем сервис будет лучше?" На который я смог привести только 2 аргумента: сервис остается работать если разлогиниться (однако это решается запуском приложения через RDP и нажатием на "крестик" вместо Log off) и то, что в "серверной" винде стоит оптимизация именно под работу сервисов (однако, это легко переключается в стандартный режим оптимизации под приложения). Очень все-таки моя религия хочет убедить коллег в том, что надо писать именно сервис.В связи с этим так же возник вопрос про daemon vs обычное приложение в unix (обычное приложение, скажем, можно запустить с помощью nohup или screen).
З.Ы. не хотелось бы видеть доставший холливар win vs unix, а только service\daemon vs application