|
Компьютерный форум OSzone.net » Автоматическая установка Windows » Автоматическая установка приложений » InnoSetup - обновления в домене под ограниченным пользователем |
|
|
InnoSetup - обновления в домене под ограниченным пользователем
|
Новый участник Сообщения: 8 |
Профиль | Отправить PM | Цитировать Здравствуйте!
Возникла следующая ситуация. Есть корпоративная программа - тонкий "клиент" в виде приложения под windows. Несколько лет назад был сделан в InnoSetup инсталлятор. При установке программа по дефолту устанавливается в Program files (x86) - копируется exe-файл, несколько dll-ок, создаётся папка с шаблонами word-файлов. В принципе - всё. Есс-но создаются ярлыки в меню "Пуск". Вроде всё. Размер небольшой, мегабайт 35. Теперь важный нюанс - программа продолжает разрабатываться, по сути практически всегда только ехе-шник стабильно заменяется на новый, приблизительно раз-два в месяц. Иногда, но очень редко, добавляются ещё файлы, например, dll-ка очередной используемой сторонней библиотеки. Сейчас проблема решалась примитивно - программа при старте проверяла наличие обновления и при необходимости запускала инсталлятор с ключом /silent И вот, пришло время - всех пользователей предприятия загоняют в домен. Под ограниченным пользователем по какой-то причине (думаю, это попытка сразу писать в реестр?) даже не запускается инсталлятор. Запись в папку с программой так же запрещена. Как я понял, у меня две проблемы: 1. InnoSetup не поддерживает в принципе удалённую и массовую установку в домене - нужно создавать MSI ? 2. Проблема с заменой exe-файла под ограниченным пользователем (ну и остальных файлов) Честно, сейчас совсем нет времени этим заниматься. Проблему нужно решить быстро. Проблему номер один решили организационно: админы готовы устанавливать под админом моё приложение всем сотням пользователям, которых вводят в домен. Проблему номер два пытаюсь решить следующим образом: инсталляция приложения будет производиться не в c:\program files..., а в отдельную папку, например, в C:\OurCorporateApplication решит ли такой подход проблему с обновлением, и не получу ли я в дальнейшем каких-либо серьёзных проблем? |
|
Отправлено: 23:33, 25-01-2017 |
Ветеран Сообщения: 27449
|
Профиль | Отправить PM | Цитировать Цитата Teml:
В любом случае, лучше один раз перейти на MSI. Тем самым Вы зараз решите проблемы и с массовым распространением, и с обновлением (точнее, не Вы, конечно, а те, кто будет пользоваться). |
|
Отправлено: 02:48, 26-01-2017 | #2 |
Для отключения данного рекламного блока вам необходимо зарегистрироваться или войти с учетной записью социальной сети. Если же вы забыли свой пароль на форуме, то воспользуйтесь данной ссылкой для восстановления пароля. |
Новый участник Сообщения: 8
|
Профиль | Отправить PM | Цитировать Спасибо. Но вот именно процесс обновления меня беспокоит. Насколько я понимаю, все эти бубны и пляски вокруг безопасности возникли для того, чтобы под ограниченным пользователем невозможно было править исполняемый код.
Моя программа при старте иногда обновляется, а именно: правит сама себя а так же dll, то есть, именно исполняемые файлы. Теперь она будет запускаться из под ограниченного пользователя. Решают ли эту проблему Advanced installer или WiX? Не смутит ли их что, к примеру, ехе-файл вытягивает какой-то ехе по http c удалённого сервера, а затем запускает его? Обновлять программу под админским пользователем - не вариант. Слишком много машин, на которых она находится и слишком часто она обновляется. С другой стороны, с моей дилетантской точки зрения - на политику безопасности майкрософта "забили" даже такие гиганты, как гугл: например, браузер хром хранит исполняемый код в папке Application Data, туда же сваливаются плагины, которые так же зачастую представляют собой исполняемый код. Подобным же образом себя ведут и файрфокс и т.д. У меня возник вопрос, какой великий смысл в инсталляторах? Не могу понять что конкретно они делают, кроме как регистрируют программу в реестре, регистрируют ком-сервера и копируют в системные папки нужные библиотеки? Но пользователь теперь для получения обновления должен обратиться к администратору домена (?) У меня программа, по сути - совсем "тонкий" клиент, базовая вещь - ехе файл. Остальное я вообще могу получать с сервера, немного поменяв бизнес-логику. |
Отправлено: 06:13, 26-01-2017 | #3 |
Ветеран Сообщения: 27449
|
Профиль | Отправить PM | Цитировать Цитата Teml:
Установка программного обеспечения средствами групповой политики. Часть 1 Установка программного обеспечения средствами групповой политики. Часть 2 Установка программного обеспечения средствами групповой политики. Часть 3 Простые пользователи никакого участия в установке/наложении патчей/обновлении в этом случае не принимают. Цитата Teml:
Цитата Teml:
Цитата Teml:
Цитата Teml:
Послушайте совета, делайте инсталляцию в формате MSI. Если в Вашем приложении есть настройки, которыми так же есть смысл управлять централизованно — внедрите в приложение поддержку групповых политик (не, администраторы, конечно, могут и неуправляемую политику нарисовать, но это уже не то будет), снабдите установку соответствующими шаблонами — администраторы Вам спасибо скажут. |
|||||
Отправлено: 08:13, 26-01-2017 | #4 |
Новый участник Сообщения: 8
|
Профиль | Отправить PM | Цитировать да, ещё одна проблема вырисовывается. Уровень компетентности администраторов домена. Честно, пока он оставляет желать лучшего, есть сомнения. Вот и реальный перевод людей в домен начали внезапно, без предупреждения, видимо, решив, "попробуем а там посмотрим, война не страшно - главное ввязаться".
На самом деле, сейчас программа дорабатывается в достаточно "экстренном" режиме и обновления иногда достаточно часты. Через админов... спасибо большое за ссылки, посмотрю сейчас. Вот и настала пора знать. Но всё же, вдруг будут варианты "штатного" решения, когда программа (а не пользователь, точнее, не совсем пользователь) таки копирует обновлённые исполняемые файлы, т.е. ехе-шники и dll-ки, а потом их запускает всё же, акцентирую внимание, в ближайшие ГОДЫ введение в приложение групповых политик не предвидится. Максимум - добавление нескольких файлов (шаблонов ms-word) и замена/добавление в папку с программой сторонних dll-ок, в количестве одна-две штуки. Планируется переезд в веб. Хотя не факт, но примерно такая тенденция. Поэтому простенький "обновлятор" подошёл бы. Единственное - хочется узнать про минусы такого решения. |
|
Отправлено: 10:57, 26-01-2017 | #5 |
Ветеран Сообщения: 27449
|
Профиль | Отправить PM | Цитировать Цитата Teml:
Цитата Teml:
Главный минус всех этих локальных игр в обновления — закономерный разнобой в ПО и библиотеках. Цитата Teml:
Цитата Teml:
|
||||
Отправлено: 12:59, 26-01-2017 | #6 |
Новый участник Сообщения: 8
|
Профиль | Отправить PM | Цитировать Про службу обновления - понятно! Направление для изучения ясно.
Я имел в виду, следующее: сейчас реализован "тонкий" клиент, то есть, вся бизнес-логика, в том числе полное разграничение прав пользователей реализовано на сервере, то есть на сервере опубликованы 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 по схожей логике периодически проверяет наличие обновлений, и, в случае необходимости предупреждает пользователя и запускает обновлятор. Вроде как это решение решает все наши проблемы - без вмешательства "админов" при каждом запуске, хоть каждые пять минут можно проверять наличие версий, и в случае их наличия - получать полное обновление. Вопрос в следующем - какие "грабли" есть у такого решения, которые я, в силу неопытности в области администрирования, не вижу? |
Отправлено: 15:06, 26-01-2017 | #7 |
Новый участник Сообщения: 8
|
Профиль | Отправить PM | Цитировать Подумалось, что есть значительно более простой вариант - просто программу целиком устанавливать в свою подпапку в application data
а там пусть она ломится сама на сервер (куда и так и так ходит за данными), узнаёт про наличие обновлений, выкачивает, при необходимости все новые файлы и заменяет ими существующие..... |
Отправлено: 23:24, 26-01-2017 | #8 |
Новый участник Сообщения: 8
|
Профиль | Отправить PM | Цитировать Сегодня обсудили, я ещё немного обдумал, и мне вспомнился ещё один важный момент. У нас ещё есть следующая "схема". Иногда мы дорабатываем существенный новый функционал, и после запуска программы у пользователя висит сообщения, что вышла бета-версия. По щелчку она устанавливается, программа перезагружается (на всё это у программы уходит от силы секунд пять-пятнадцать, как и любое обновление до новой версии). Если что-то в новой версии не устраивается и/или идёт не так - то так же по щелчку можно откатиться на штатную.
Функционал довольно активно используется, и очень важен для нас, т.к. альфа-тестеров нехватка, их практически нет. Все довольны - и разрабы, и пользователи-бета-тестеры. Как мне кажется, ТАКУЮ схему обновлений в домене реализовать просто нереально. Даже если что-то и придумать. Сегодня было принято решение однозначно "костылить" своё обновление, в процессе работы программы подменяя исполняемый код на новый, и перезапуская её. Единственное, что нужно будет сделать для работы в домене - это при установке указать папку, в которой затем возможна замена исполняемого кода при работе под ограниченной пользовательской учёткой. Iska, спасибо большое за Ваши ответы. Вы резко ускорили моё "самообразование" в этом направлении. |
Отправлено: 23:22, 27-01-2017 | #9 |
Новый участник Сообщения: 8
|
Профиль | Отправить PM | Цитировать Здравствуйте. Столкнулся со следующей проблемой.
Сто лет назад был написан инсталлятор на InnoSetup, который делал следующее: "штатные" функции: 1. создавал папку (по умолчанию в program files (x86)) 2. в папку распаковывал структуру подпапок с файлами 3. создавал ярлыки в пуск-выполнить собственная добавка 4. прописывал в реестре путь к ехе-файлу (этот путь использовался затем в сторонних программах) этот же инсталлятор использовался для обновления программы, т.е. программа проверяла, новая ли версия у инсталлятора на сервере, если есть - качала инсталлятор и запускала его с ключом /silent, убив предварительно себя Теперь всё предприятие загнали в домен. Времени на переезд на всякие WIX-ы нет, было принято решение изменить у инсталлятора путь установки в C:\НашаПрограмма\ всё отлично, программа ставится, пути прописываются, и политика домена такова, что в этой папке можно делать всё что угодно, в т.ч. перезаписать все файлы но есть проблема - по какой-то причине инсталлятор НЕ запускается под ограниченным пользователем, в сообщении от операционки пишется "для запуска этой программы требуются права администратора". Сразу, при старте. есть подозрения, что дело в манифесте, который генерирует IDE InnoSetup-а подскажите, кто знает - нет ли каких настроек, позволяющих: а) изменить настройки манифеста, чтобы инсталлятор запускался без амдинских прав б) запустить тот же самый иснсталлятор в режиме "обновление", но не просто /silent, а чтобы из всех пунктов, перечисленных выше, он выполнил только один: 1. создавал папку (по умолчанию в program files (x86)) 2. в папку распаковывал структуру подпапок с файлами 3. создавал ярлыки в пуск-выполнить 4. прописывал в реестре путь к ехе-файлу (этот путь использовался затем в сторонних программах) такая возможность решила бы все наши проблемы |
Отправлено: 13:46, 21-02-2017 | #10 |
|
Участник сейчас на форуме | Участник вне форума | Автор темы | Сообщение прикреплено |
| |||||
Название темы | Автор | Информация о форуме | Ответов | Последнее сообщение | |
Доступ - [решено] О работе под пользователем | sameuser | Microsoft Windows 10 | 11 | 05-06-2016 00:11 | |
Доступ - Групповая политика ... работает!(с ограниченным пользователем) | Crissaegrim | Microsoft Windows 2000/XP | 18 | 19-11-2011 18:59 | |
FAQ - "Сетевые подключения" (Network Connections) - свойства под ограниченным пользователем | Raistlin | Сетевые технологии | 0 | 28-05-2011 20:23 | |
Доступ - Запуск программы пользователем (с правами админа) на ПК в домене | Axiles_UA | Microsoft Windows 7 | 2 | 01-09-2010 18:30 | |
Ошибка - Проблема печати в IE под пользователем | Emulty | Microsoft Windows 2000/XP | 1 | 14-09-2007 23:11 |
|