Архитектура само-обновляемого корпоративного ПО.

[RXL]

Вопрос про само-обновляемое ПО и как его правильно вписать в архитектуру WinPX и более мудренных в плане защиты Vista и W7.

Имеется ПО, написанное за 10 или более лет несколькими программистами. Периодически в нем исправляются баги и добавляются фичи. Соответственно, после этого надо обновить установку на всех машинах, где это ПО используется. Машины не персонализированы — все пользователи логинятся в домене Win2003.

ПО состоит их набора exe, пары dll, сопутствующих неисполняемых файлов и библиотеки в распотрошенном виде.
Библиотека состоит из кучки dll, часть из которых содержит COM и нуждается в регистрации на машине. Той у нее вид из-за того, что надо держать на каждой машине две версии этой библиотеки.
Инсталяция простая: от имени текущего пользователя запускается bat-файл, который копирует на машину файлы по списку и регистрит COM-библиотеки. Пока даем пользователям права на административно созданную для ПО папку, право писать в реестр (в его часть) и право регистрировать библиотеки COM-объектов (последние два права дает встроенная группа Power Users). Процесс установки автоматизирован: при запуске программы она проверяет наличие обновления и по необходимости запускает его сама.

Когда будут появляться машины с Vista и W7, предвижу трудности. Хотелось бы заранее подумать над изменением архитектуры.

[Sla]

можно удаленно устанавливать ПО при логине в домен.

[RXL]

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

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

Имеем следующие компоненты:
1. Exe + N*dll + M * неисполнимых файлов.
2. Библиотека CrystalReports10 в потрошенном виде (версия 8.5 устанавливается другим сторонним ПО и удалять ее нельзя - оттуда и кривая установка.).

Требуется:
1. Программа запускается под любым пользователем и находит обновление - надо переустановить его налету.
2. Инсталляция CrystalReports10.

Сейчас оба шага выполняются одновременно исключительно для простоты обновления и первоначальной установки. Думаю можно п.2 сделать разовым запуском под админом при настройке машины.
Остается п.1: нужно под любым пользователем перезаписывать ПО на машине и не конфликтовать с защитой ОС.

[Алексей++]

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

[zubr]

Требования:
1. При обновлении ничего не должно писаться в реестр.
2. Все необходимые для работы ПО файлы должны размещаться в юзерском каталоге или в профиле (Documents and Settings\UserName\Application Data\..).
Алгоритм:
1. ПО состоит из exe-модуля обновления (далее МО) и собственно самой программы.
2. Запуск программы производится через модуль обновления.
3. МО проверяет дату последнего обновления из текстового или ini-файла.
4. МО заходит в расшаренный каталог компа, на котором размещено обновление. Читает оттуда из текстового или ini-файла дату последнего обновления и в зависимости от даты закачивает обновление в свой каталог.
5. МО запускает основную программу.

[RXL]

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

zubr, правильно ли я понимаю, что из требования 2 выходит, что у каждого пользователя должна быть своя копия программы?

По п.3 и 4: я использую хардкодед номер версии и выкладываю номер обновления в БД. Для неисполнимых файлов (чтобы не менять номер версии исполнимого файла) использую локальный ini и номер обновления в БД.

[zubr]

zubr, правильно ли я понимаю, что из требования 2 выходит, что у каждого пользователя должна быть своя копия программы?

Не обязательно. Зависит от структуры размещения файлов программы. К примеру, программа (exe+dll) может размещаться в любом не системном каталоге, а сохраняемые данные в профиле.

[RXL]

Т.е. делаю c:\myprog и даю полный доступ всем юзерам?

[Алексей++]

Нельзя пользователю давать админские права, особенно если в программе есть диалоги работы с файлами.

Инсталляшка не обязана содержать диалог работы с файлами, можно свою вводилку пути сделать. Для однократного запуска сойдёт

[zubr]

Т.е. делаю c:\myprog и даю полный доступ всем юзерам?

Да, если это ПО для любого юзера. Иначе варианты:
1. Размещать копии программы для каждого юзера в его профиле.
2. Возможно достаточно будет, того, что данные программы сохраняются в профиле. Тогда программа от неуполномоченного юзера или не запустится или будет работать некорректно.
3. В модуле обновления добавить функцию ввода логин-пароль, чтобы ограничить юзеров.

[RXL]

zubr, да, для любого. Более тонкий доступ регулируется уже самой программой.

1. Есть вероятные негативные факторы. Например, копия в профиле может настолько устареть, что откажется запускаться и обновляться. Это большая нагрузка на администраторов: одно дело обновить По на одном компьютере, а другое - следовать за юзером в его путешествии по машинам (в условии - неперсонализированность машин).
2. Все данные хранятся в базе, за исключением ini с текущей версией.
3. Неудобство. Нужно обновление автоматом, без участия пользователя. От него требуется только запустить программу.

В общем, рождается такая схема. ПО разделяется на:
1. Первоначальный установочный комплект. Запускается пользователем, подготавливающим рабочее место и имеющим права администратора машины. Хранится на сети. После настройки системы автоматом вызывает модуль обновления.
2. Модуль обновления. Запускается любым пользователем (типично - основным модулем). Хранится на сети. Исполняется с правами подставного пользователя, имеющего админские права на рабочей машине.
3. Основной модуль. Запускается любым пользователем. Хранится на каждой рабочей машине. При необходимости вызывает модуль обновления.

[Dimka]

А может на машинах повесить маленький трояноподобный демон, работающий под админом и обеспечивающий обновление?

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

[RXL]

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

[zubr]

zubr, да, для любого. Более тонкий доступ регулируется уже самой программой.

1. Есть вероятные негативные факторы. Например, копия в профиле может настолько устареть, что откажется запускаться и обновляться. Это большая нагрузка на администраторов: одно дело обновить По на одном компьютере, а другое - следовать за юзером в его путешествии по машинам (в условии - неперсонализированность машин).
2. Все данные хранятся в базе, за исключением ini с текущей версией.
3. Неудобство. Нужно обновление автоматом, без участия пользователя. От него требуется только запустить программу.

RXL, я предполагал, что запуск будет вестись из модуля обновления. То есть МО располагается на локальном компе, к нему имеют доступ все юзеры. МО запускает экземпляр из профиля в зависимости от текущего пользователя (SHGetFolderPath), предварительно при необходимости сделав обновление версии для текущего пользователя.

[Dimka]

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

[RXL]

zubr, надо думать. Это у меня заделки на следующие месяц-два.

Dimka, как раз текущий юзер используется в управлении правами в ПО. Т.е. запущено оно должно быть только под настоящим юзером.

Тут мне подсказывают, что "All Users\Application Data" тоже неплохой кандидат на местоположение общего ПО.