Форум программистов «Весельчак У»
  *
Добро пожаловать, Гость. Пожалуйста, войдите или зарегистрируйтесь.
Вам не пришло письмо с кодом активации?

  • Рекомендуем проверить настройки временной зоны в вашем профиле (страница "Внешний вид форума", пункт "Часовой пояс:").
  • У нас больше нет рассылок. Если вам приходят письма от наших бывших рассылок mail.ru и subscribe.ru, то знайте, что это не мы рассылаем.
   Начало  
Наши сайты
Помощь Поиск Календарь Почта Войти Регистрация  
 
Страниц: [1]   Вниз
  Печать  
Автор Тема: Архитектура само-обновляемого корпоративного ПО.  (Прочитано 22352 раз)
0 Пользователей и 1 Гость смотрят эту тему.
RXL
Технический
Администратор

ru
Offline Offline
Пол: Мужской

WWW
« : 21-11-2009 17:04 » 

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

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

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

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

... мы преодолеваем эту трудность без синтеза распределенных прототипов. (с) Жуков М.С.
Sla
Команда клуба

ua
Offline Offline
Пол: Мужской

WWW
« Ответ #1 : 23-11-2009 06:44 » 

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

Мы все учились понемногу... Чему-нибудь и как-нибудь.
RXL
Технический
Администратор

ru
Offline Offline
Пол: Мужской

WWW
« Ответ #2 : 23-11-2009 06:58 » 

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

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

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

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

Сейчас оба шага выполняются одновременно исключительно для простоты обновления и первоначальной установки. Думаю можно п.2 сделать разовым запуском под админом при настройке машины.
Остается п.1: нужно под любым пользователем перезаписывать ПО на машине и не конфликтовать с защитой ОС.
« Последнее редактирование: 23-11-2009 07:01 от RXL » Записан

... мы преодолеваем эту трудность без синтеза распределенных прототипов. (с) Жуков М.С.
Алексей++
глобальный и пушистый
Глобальный модератор

ru
Offline Offline
Сообщений: 13


« Ответ #3 : 23-11-2009 07:06 » 

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

zubr
Гость
« Ответ #4 : 23-11-2009 07:24 » 

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

ru
Offline Offline
Пол: Мужской

WWW
« Ответ #5 : 23-11-2009 07:58 » 

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

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

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

... мы преодолеваем эту трудность без синтеза распределенных прототипов. (с) Жуков М.С.
zubr
Гость
« Ответ #6 : 23-11-2009 08:11 » 

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

ru
Offline Offline
Пол: Мужской

WWW
« Ответ #7 : 23-11-2009 08:16 » new

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

... мы преодолеваем эту трудность без синтеза распределенных прототипов. (с) Жуков М.С.
Алексей++
глобальный и пушистый
Глобальный модератор

ru
Offline Offline
Сообщений: 13


« Ответ #8 : 23-11-2009 08:38 » 

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

zubr
Гость
« Ответ #9 : 23-11-2009 09:02 » 

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

ru
Offline Offline
Пол: Мужской

WWW
« Ответ #10 : 23-11-2009 09:59 » 

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

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

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

... мы преодолеваем эту трудность без синтеза распределенных прототипов. (с) Жуков М.С.
Dimka
Деятель
Модератор

ru
Offline Offline
Пол: Мужской

« Ответ #11 : 23-11-2009 10:34 » 

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

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

Программировать - значит понимать (К. Нюгард)
Невывернутое лучше, чем вправленное (М. Аврелий)
Многие готовы скорее умереть, чем подумать (Б. Рассел)
RXL
Технический
Администратор

ru
Offline Offline
Пол: Мужской

WWW
« Ответ #12 : 23-11-2009 10:54 » 

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

... мы преодолеваем эту трудность без синтеза распределенных прототипов. (с) Жуков М.С.
zubr
Гость
« Ответ #13 : 23-11-2009 10:58 » 

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

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

ru
Offline Offline
Пол: Мужской

« Ответ #14 : 23-11-2009 15:39 » 

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

Программировать - значит понимать (К. Нюгард)
Невывернутое лучше, чем вправленное (М. Аврелий)
Многие готовы скорее умереть, чем подумать (Б. Рассел)
RXL
Технический
Администратор

ru
Offline Offline
Пол: Мужской

WWW
« Ответ #15 : 23-11-2009 17:40 » 

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

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

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

... мы преодолеваем эту трудность без синтеза распределенных прототипов. (с) Жуков М.С.
Страниц: [1]   Вверх
  Печать  
 

Powered by SMF 1.1.21 | SMF © 2015, Simple Machines