про приложения: у меня например сбор идет через опрос запущенных процессов. Ибо по определению пользователи ничего не поставят без админов. а админы в соответствии с протоколом одобрямс будут запрашивать. домен как-бэ намекает. и если я в течении дня увижу не одобренный процесс - кара непокорным :). поэтому логичнее пользовать то, что уже есть в системе и как-бэ разрешено. это конечно сугубо мое мнение, ибо ситуации топикстартера я точно не знаю до конца.
Про маршрутизатор - не совсем понял идею.... Если есть желание - можете подробнее ее изложить?
RDS - это тот же RDP, только опубликованный в http. RDP - это процесс mstsc в памяти без контекста. Плюс. если вам не закрыли mstsc при таких драконовских условиях - так может и остальное - только показуха и можно спокойно "рыбачить"?
Вроде нет. Это наверное лучше у производителя программы узнать, прикинувшись потенциальным покупателем в чате :).
Если не игрушки, то что? Аж любопытно стало - тыкать мышкой, рабочий стол, но не игрушка.... Извините, если лишнее спрашиваю, а специальность, по которой вы работаете и то чем занимаетесь дома - совпадают?
Игрушки!!!! Прикольно. СтарКрафт поди. Теоретически можно попробовать опубликовать RDS и будет "мышечный" доступ к РабСтолу. Надо пробовать с конкретным ПО.
Вот еще для размышлений: https://support.google.com/chrome/answer/1649523?hl=ru
В вашем случае необходимо использовать для удаленного доступа проги, на которые сразу и не подумаешь. Ну или часто используются для многого другого. браузер - это первое, что пришло в голову.
Понимаешь в чем дело... Вебдав - это конечно руль, но не сильно отличается от ВПН-канала. При таком выборе я отдам предпочтение ВПН, ибо работал с ним достаточно. Аппаратно опять же могу запилить, что надежнее. Вопрос именно в возможности _запуска_ ворда на локальной машине из веб-файлового менеджера, с обратной транспортировкой изменений. Все остальные варианты или их аналоги я уже поставил в план рассмотрения. Видимо завтра поставлю вариант как нереализуемый в предложенных границах и оставлю на когда будет время еще раз, уже спокойно подумать.
Кстати, в п.1 - можно было тогда проверенный временем SharePoint поднять - лицухи есть, серваки тоже. А не экспериментировать с неочевидными механизмами. Время жмет :(. Грю же - проекты в активной стадии, а этот - это помощь младшим братьям-строителям.
1. Некорректно. У нас и так Office365. Те шило менять на непонятно мыло - не решение. Задача стоит немного иначе - дать возможность прорабам на стройплощадке с ноута и GPRS-свистка загрузить (открыть из веба) фаил, отредактировать его (непонятно сколько по времени и с прерываниями связи) )и сохранить обратно. Я сейчас выбираю между несколькими подходами - VPN (неудачно наличием дополнительных телодвижений по организации канала), hfs - загрузил/выгрузил, открывать в локальном приложении с _нашего_ веб-стора (тоже есть пара минусов, научить бы его открывать сразу в Таблицу и записывать потом обратно- зело дело бы было), 1с-Документооборот - держу прозапас, т.к. есть пара нерешенных вопросов, ну и остаться на офисе365. Вопрос был вполне конкретным: возможность запускать _локальный_ офис с подтягиванием файла из _нашего_ веб-хранилища. Не спорю, Ваш ответ может быть решением, но при других условиях, бюджетах и временных сроках. В перспективу я в любом случае его рассмотрю, но точно не сейчас.
2. Не совсем понял предложение. Великий и ужасный Гугл выдал инфу по которой.... по которой я ничего не понял. Есть возможность чуть подробнее о продуктах? Ибо если я правильно понял - Ваш вариант заключается в публикации RDS-приложения? Тогда не катит. Или я таки ошибаюсь?
Почему это не совсем бэкап? Идея такая, что с этих дисков с реплики, можно как запустить практически мгновенно ВМ, там и сам виртуальный диск перенести в любое место. Я использую схему "трамвайного билета" (анекдот. если интересно - расскажу): с боевой hyper-v осуществляется репликация на d_hyper, а с него скрипт с *засекреченного места* забирает в свой схрон диски. Примерно раз в месяц проверяем работоспособность. Начальник параноик, то да, но и я не далеко ушел :).
А если идею феникса добавить, то вообще о правах нет необходимости думать - проверил есть нет изменения в файле, если есть отработал, релоаднул. Нет - ждем дальше.
1. на DNS-хостинге, *.vasya.ru IN A 192.168.1.1
2. на принимающем прокси (в моем случае nginx) добавлять секцию
server {
listen main_ip;
server %3th_server_name%.vasya.ru;
location / { proxy_pass backend;}
}
Причем папку с добавляемыми конфигами можно сделать доступной для группы веб-сервера, ребутить апач скажем раз в час по крону. (пользователя предупредить о паузе). Кстати, апач - мое слабое место, я не знаю можно ли его мягко релоадить, как nginx.
Конфиг nginx тоже доступен на изменение со стороны группы веб-сервера. Я просто слабо себе представляю, как не зная где лежит скрипт - узнать, что _только конфиг_ доступен на изменение. Ну и бэкапы никто не отменял в какое-нить другое место.
Такая схема позволит разводить в том числе и по разным бэкендам и портам, при необходимости. обрабатывать имена доменов третьего уровня уже на входе, не и скрипт:
3. 1. передаваемые параметры из командной строки
3.2. скрипт по правилам выстраивает и запоняет новую секцию сервер из шаблона. Добавляет к существующему конфигу. крон делает софтрелоад nginx каждые n минут.
Как-то так. пишу в ветке ответа на Павла - ибо по большому счету это просто конкретизированная и получившая некоторое развитие его мысль.