InnoSetup - обновления в домене под ограниченным пользователем
 

Здравствуйте!
Возникла следующая ситуация. Есть корпоративная программа - тонкий "клиент" в виде приложения под windows.

Несколько лет назад был сделан в InnoSetup инсталлятор. При установке программа по дефолту устанавливается в Program files (x86) - копируется exe-файл, несколько dll-ок, создаётся папка с шаблонами word-файлов. В принципе - всё. Есс-но создаются ярлыки в меню "Пуск". Вроде всё. Размер небольшой, мегабайт 35.

Теперь важный нюанс - программа продолжает разрабатываться, по сути практически всегда только ехе-шник стабильно заменяется на новый, приблизительно раз-два в месяц. Иногда, но очень редко, добавляются ещё файлы, например, dll-ка очередной используемой сторонней библиотеки. Сейчас проблема решалась примитивно - программа при старте проверяла наличие обновления и при необходимости запускала инсталлятор с ключом /silent

И вот, пришло время - всех пользователей предприятия загоняют в домен. Под ограниченным пользователем по какой-то причине (думаю, это попытка сразу писать в реестр?) даже не запускается инсталлятор. Запись в папку с программой так же запрещена.

Как я понял, у меня две проблемы:

1. InnoSetup не поддерживает в принципе удалённую и массовую установку в домене - нужно создавать MSI ?
2. Проблема с заменой exe-файла под ограниченным пользователем (ну и остальных файлов)

Честно, сейчас совсем нет времени этим заниматься. Проблему нужно решить быстро.

Проблему номер один решили организационно: админы готовы устанавливать под админом моё приложение всем сотням пользователям, которых вводят в домен.

Проблему номер два пытаюсь решить следующим образом: инсталляция приложения будет производиться не в c:\program files..., а в отдельную папку, например, в C:\OurCorporateApplication

решит ли такой подход проблему с обновлением, и не получу ли я в дальнейшем каких-либо серьёзных проблем?

Advansed Installer. Или: медленно, надёжно и бесплатно — WiX.

В любом случае, лучше один раз перейти на MSI. Тем самым Вы зараз решите проблемы и с массовым распространением, и с обновлением (точнее, не Вы, конечно, а те, кто будет пользоваться).

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

Моя программа при старте иногда обновляется, а именно: правит сама себя а так же dll, то есть, именно исполняемые файлы. Теперь она будет запускаться из под ограниченного пользователя. Решают ли эту проблему Advanced installer или WiX?

Не смутит ли их что, к примеру, ехе-файл вытягивает какой-то ехе по http c удалённого сервера, а затем запускает его? Обновлять программу под админским пользователем - не вариант. Слишком много машин, на которых она находится и слишком часто она обновляется.

С другой стороны, с моей дилетантской точки зрения - на политику безопасности майкрософта "забили" даже такие гиганты, как гугл: например, браузер хром хранит исполняемый код в папке Application Data, туда же сваливаются плагины, которые так же зачастую представляют собой исполняемый код. Подобным же образом себя ведут и файрфокс и т.д.

У меня возник вопрос, какой великий смысл в инсталляторах? Не могу понять что конкретно они делают, кроме как регистрируют программу в реестре, регистрируют ком-сервера и копируют в системные папки нужные библиотеки? Но пользователь теперь для получения обновления должен обратиться к администратору домена (?)

У меня программа, по сути - совсем "тонкий" клиент, базовая вещь - ехе файл. Остальное я вообще могу получать с сервера, немного поменяв бизнес-логику.

В домене эта задача ложится на плечи администратора. Вкратце это выглядит так:

Установка программного обеспечения средствами групповой политики. Часть 1
Установка программного обеспечения средствами групповой политики. Часть 2
Установка программного обеспечения средствами групповой политики. Часть 3

Простые пользователи никакого участия в установке/наложении патчей/обновлении в этом случае не принимают.

Приложение может быть установлено в режиме «На машину» и «На пользователя». В первом случае приложение устанавливается в %ProgramFiles%, настройки, общие для всех пользователей, хранятся в общем профиле AllUsers и HKLM, персональные настройки каждого пользователя — в его личном профиле и HKCU. Во втором случае приложение устанавливается непосредственно в профиль конкретного пользователя (при этом административные привелегии ему не нужны), персональные настройки пользователя хранятся так же в его личном профиле и HKCU, общих настроек нет.

Именно это и делают. И кроме того — обеспечивают корректное удаление/восстановление/обновление/наложение патчей и кучу прочих вещей. Главное, что позволяет msi (точнее службы каталогов на серверах и службы Windows Installer на клиентах) — управлять всем этим хозяйством прозрачно и централизованно.

Так было. Так есть. Пользователь-сам себе администратор — зло.

Без разницы.

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

да, ещё одна проблема вырисовывается. Уровень компетентности администраторов домена. Честно, пока он оставляет желать лучшего, есть сомнения. Вот и реальный перевод людей в домен начали внезапно, без предупреждения, видимо, решив, "попробуем а там посмотрим, война не страшно - главное ввязаться".

На самом деле, сейчас программа дорабатывается в достаточно "экстренном" режиме и обновления иногда достаточно часты. Через админов... спасибо большое за ссылки, посмотрю сейчас. Вот и настала пора знать.

Но всё же, вдруг будут варианты "штатного" решения, когда программа (а не пользователь, точнее, не совсем пользователь) таки копирует обновлённые исполняемые файлы, т.е. ехе-шники и dll-ки, а потом их запускает

всё же, акцентирую внимание, в ближайшие ГОДЫ введение в приложение групповых политик не предвидится. Максимум - добавление нескольких файлов (шаблонов ms-word) и замена/добавление в папку с программой сторонних dll-ок, в количестве одна-две штуки.

Планируется переезд в веб. Хотя не факт, но примерно такая тенденция. Поэтому простенький "обновлятор" подошёл бы. Единственное - хочется узнать про минусы такого решения.

Teml, это и есть штатное решение уже восемнадцать лет как.

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

Главный минус всех этих локальных игр в обновления — закономерный разнобой в ПО и библиотеках.

Шаблоны Word и библиотеки к шаблонам групповой политики не относятся. Видимо, Вы не понимаете.

Э… А какие там будут обновления, я что-то не понял? Там ить один токмо браузер, не?

Про службу обновления - понятно! Направление для изучения ясно.

Я имел в виду, следующее: сейчас реализован "тонкий" клиент, то есть, вся бизнес-логика, в том числе полное разграничение прав пользователей реализовано на сервере, то есть на сервере опубликованы web-сервисы, доступ к которым реализован через http (SOAP). Сторонние dll - это реализация модуля сканирование, расчёт хеша для пароля. Всё. Хранится ещё пара doc-файлов, но их можно убрать.

Что ещё использует программа? Свою папку в Application Data, которую создаёт при старте - в ней временно сохраняются скаченные файлы. Что-то типа хеша для временных файлов.

То есть, практически всё описанное с лёгкостью реализуемо в веб-версии клиента. Некоторые части уже давно выполнены в виде веб-интерфейса: пользователь заходит на сайт, авторизуется и наблюдает оперирует уже в браузере со своими данными.

Клиента под windows сделали в качестве "прототипа", т.к. скорость разработки в RAD для нас значительно выше, да и наработок много. Но как обычное - всё временное затягивается на постоянное. К тому же, все годы работали только под "админскими" правами на машине, но я даже не могу себе представить, в каком месте программы буду обращаться к групповым политикам и для чего мне это вообще может понадобиться.

Удручает то, что не знаю пока о проблемах, с которыми могу столкнуться. Учитывая и то, что админы нашего не маленького предприятия "только учатся". И вот только только начинают "наводить порядок". А обновления у меня сейчас идут по десять-двадцать раз на месяц.


Уже подумываю, а не сделать ли, грешным делом, следующий финт ушами:

1. создать инсталлятор, который будет ставить "программу", состоящую из одного-единственного файла: MyProgramLauncher.exe - который никогда не будет заменяться.

2. Этот файл будет являться неким "обновлятором" - после запуска будет ломиться в Application Data, создавать там свою папку, если таковой ещё не существует, затем копировать с сервера обновлений в него файл MyProgram.exe, рядом с ним раскладывать все используемые dll-библиотеки и прочие файлы. Рядом же будет находиться и "рабочая папка программы"

3. При повторных запусках, конечно же, если папка в Application data уже есть, и версия MyProgram.exe, а так же остальных файлов, не поменялась - то он ничего копировать не будет

4. После копирования процесс "Обновлятора" MyProgramLauncher.exe запускает процесс MyProgram.exe, а сам самоудаляется.

5. Сам процесс MyProgram.exe по схожей логике периодически проверяет наличие обновлений, и, в случае необходимости предупреждает пользователя и запускает обновлятор.

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

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

Подумалось, что есть значительно более простой вариант - просто программу целиком устанавливать в свою подпапку в application data

а там пусть она ломится сама на сервер (куда и так и так ходит за данными), узнаёт про наличие обновлений, выкачивает, при необходимости все новые файлы и заменяет ими существующие.....

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

Функционал довольно активно используется, и очень важен для нас, т.к. альфа-тестеров нехватка, их практически нет. Все довольны - и разрабы, и пользователи-бета-тестеры.

Как мне кажется, ТАКУЮ схему обновлений в домене реализовать просто нереально. Даже если что-то и придумать.

Сегодня было принято решение однозначно "костылить" своё обновление, в процессе работы программы подменяя исполняемый код на новый, и перезапуская её. Единственное, что нужно будет сделать для работы в домене - это при установке указать папку, в которой затем возможна замена исполняемого кода при работе под ограниченной пользовательской учёткой.

Iska, спасибо большое за Ваши ответы. Вы резко ускорили моё "самообразование" в этом направлении.

InnoSetup - запуск инсталлятора под ограниченным пользователем
 

Здравствуйте. Столкнулся со следующей проблемой.

Сто лет назад был написан инсталлятор на InnoSetup, который делал следующее:

"штатные" функции:
1. создавал папку (по умолчанию в program files (x86))
2. в папку распаковывал структуру подпапок с файлами
3. создавал ярлыки в пуск-выполнить

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

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

Теперь всё предприятие загнали в домен. Времени на переезд на всякие WIX-ы нет, было принято решение изменить у инсталлятора путь установки в C:\НашаПрограмма\
всё отлично, программа ставится, пути прописываются, и политика домена такова, что в этой папке можно делать всё что угодно, в т.ч. перезаписать все файлы

но есть проблема - по какой-то причине инсталлятор НЕ запускается под ограниченным пользователем, в сообщении от операционки пишется "для запуска этой программы требуются права администратора". Сразу, при старте.

есть подозрения, что дело в манифесте, который генерирует IDE InnoSetup-а

подскажите, кто знает - нет ли каких настроек, позволяющих:
а) изменить настройки манифеста, чтобы инсталлятор запускался без амдинских прав
б) запустить тот же самый иснсталлятор в режиме "обновление", но не просто /silent, а чтобы из всех пунктов, перечисленных выше, он выполнил только один:

1. создавал папку (по умолчанию в program files (x86))
2. в папку распаковывал структуру подпапок с файлами
3. создавал ярлыки в пуск-выполнить
4. прописывал в реестре путь к ехе-файлу (этот путь использовался затем в сторонних программах)

такая возможность решила бы все наши проблемы

Всем спасибо. Проблема решилась одной строкой в скрипте. Дольше формулировал вопрос. privilegies.

Главное, что проблему решили:
быстро ;). Теперь-то уж точно, спокойно и не торопясь, можете начинать осваивать MSI.