R0 CREW

Создание удаленного сервера и организации работы с базой данных через RDP / Creating a remote server and organizing database operations via RDP

Jobs One-Time Work
, ,
#1
  1. Необходимо поднятие сервера на стороннем ресурсе хостинга.
  2. Обеспечение доступа клиенту через RDP подключение нескольких одновременных пользователей под одной учетной записью с разными не пересекающимися сеансами.
  3. Разработать решения одновременного открытия программ для просмотра исследования, программы не имеют многопользовательского режима, необходимо для каждого пользователя автоматическое создание виртуального подключения что бы запуск одной копии программы для просмотра не мешало открытие другому пользователю исследования в той же программе на сервере.
  4. Написание оболочки для визуализации клиенту базы, состоящей из списка пациентов и кнопок исполнения для открытия исследования через программу просмотра в которой будет выложено исследование на сервер в размеченную область для данного клиента.
  5. Организовать Возможность отправки исследований на указанную в строке адрес почты клиента (указав свою почту, папка с исследованием должна быть упакована в архив и получив ссылку для скачивания с облака, ссылка зашивается в шаблон письма и отправляется с почты предоставляя при получении письма перейти по ссылке и скачать архив с исследованием.
  6. Разработать ограничение прав в ОС Windows и блокирование элементов, не требующихся для клиента.
  7. Разработка административной части для загрузки исследований с интеграцией в облако mail или google.
  8. Тестирование и отладка

You need to raise the server on a third-party hosting resource.
Providing access to the client via RDP connecting multiple simultaneous users under the same account with different non-overlapping sessions.
Develop solutions for simultaneously opening programs for viewing research, programs do not have multi-user mode, it is necessary for each user to automatically create a virtual connection so that running one copy of the program for viewing does not interfere with opening another user of the study in the same program on the server.
Writing a shell for visualizing the database to the client, consisting of a list of patients and execution buttons for opening the study through the viewer in which the study will be uploaded to the server in the marked area for this client.
To organize the Ability to send research specified in the string the email address of the client (putting your email folder with the study must be Packed into the archive and get the link to download from clouds, link is in the email template and sent with the mail, providing email follow the link and download the archive with the study.
Develop rights restrictions in Windows and block elements that are not required by the client.
Development of the administrative part for uploading research with integration into the mail or google cloud.
Testing and debugging
Пример клиентской части оболочки

Screenshot_1
Screenshot_11161×606 196 KB

#2

Будут на меня ругаться модераторы… но молчать не могу )

“Обеспечение доступа клиенту через RDP подключение нескольких одновременных пользователей под одной учетной записью с разными не пересекающимися сеансами”

Вот вы это серьёзно?

#3

Объясните, Что именно смущает в вышеуказанном?

#4

Ок. Раз вы пишите про “подключение нескольких одновременных пользователей под одной учетной записью” стало быть в курсе что это возможно и сколькими щелчками мышки это делается. Зачем это надо и зачем выносить в отдельный пункт ТЗ… Ну допустим у вас были резоны.
Далее “Разработать решения одновременного открытия программ для просмотра исследования, программы не имеют многопользовательского режима” Хорошо, авторы программ были не сильны в защите от запуска на терминальном сервере или мы это отломали. НО с огромной вероятностью различные настройки программ, как то подключение к базе данных и т.д. хранятся в ветке реестра CURRENT_USER Какой будет результат при “подключение нескольких одновременных пользователей под одной учетной записью” думаю очевидно.

#5

Что бы было проще объясню словами из отчета текущего исполнителя который зашел в тупик с реализацией:

Отчет
Настройка системы:
Настройка доступа по rdp:
Наиболее оптимальной системой для подключения по rdp нескольких пользователей является windows server, с подключённой ролью сервера удаленных рабочих столов, но по причинам, описанным ниже, ни одна из ± актуальных версий windows server (были испробованы 2012 2016 2019) не подошла.
В качестве системы была выбрана система windows 10 pro. А для обеспечения доступа по rdp было использовано ПО rdpwrap оно позволяет подключаться по rdp нескольким пользователям, однако имеет некоторые нюансы.
Обеспечение доступа нескольких одновременных пользователей под одной учетной записью (для любой учетной записи кроме администратора) работало только при наличии открытой локально сессии этой учетной записи, реализовано это было при помощи утилиты RDPCheck. С помощью данной утилиты была открыта локальная сессия (в дальнейшем для удобства буду называть ее базовой сессией), внутри сессии администратора, затем от сессии администратора можно было отключиться, но сессия должна работать для работоспособности одновременного подключения нескольких пользователей. При таком подходе возник следующий список сложностей:

  1. для работоспособности необходима постоянная работа базовой сессии пользователя.
    Это вступает в конфликт с тем, что необходимо ограничение сессий пользователя по времени. Так как настройка длительности сессии применяется для всех сессий для всех сессий определенного пользователя (настраивается в редакторе групповых политик).
    Для сохранения базовой сессии было принято решение имитировать активность пользователя с использованием ПО mousejiggler. Это ПО имитирует движение мыши, что создает активность пользователя и базовая сессия не отключается. При таком подходе ограничение активных сессий по времени не представляется возможным.
  2. при подключении по rdp происходило подключение к базовой сессии. Попытки изучить почему так происходит и предотвратить это к успеху не привели, но возможность того что реализуемо есть. При подключении к базовой сессии и затем отключении, сессия становится неактивной что может привести к сбоем возможности множественного подключения.
    Настройка пользователя:
    Учетная запись пользователя должна была обладать рядом ограничений, для того что бы пользователь не смог сделать ничего лишнего, при пользовании конечным продуктом, здесь можно выделить три группы изменений:
  3. то что можно изменить при использовании групповых политик (приложение)
  4. то что необходимо отключать в профиле пользователя (в основном это элементы панели задач и меню “пуск” ) (скрины?)
  5. стороннее ПО (утилита, которая скрывает меню пуск)()

настройка сервера для подключения по ftp :
Для загрузки исследований на сервер был развернут ftp средствами windows 10 (https://techarks.ru/general/kak-nastroit-ftp-server-v-windows-10/), для подключения к необходимым папкам удаленно можно использовать средства windows (http://www.bizkit.ru/2017/01/26/4019/), однако в windows это реализовано не очень гладко, поэтому предпочтительнее использовать иной ftp клиент, например filezilla (https://filezilla.ru/) он более стабилен и при этом тоже достаточно удобен в использовании.
настройка сервера для скачивания данных:
для скачивания данных был развернут nginx сервер (конфиг в приложении)
ПО для пользователя: написано на языке с#
скриншот
выводит список исследований для определенного пользователя
позволяет:

  1. открыть необходимое исследование
    в последней версии, для того что бы исследование отображалось необходимо что бы исследование было размещено в необходимой директории в том виде, в котором оно предоставлено изначально, никаких дополнительных манипуляций производить не нужно

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

  3. просмотреть изображение в папке
    при нажатии на данную кнопку открывается jpg файл, находящийся в папке с исследованием

#6

Это всё весьма познавательно, но не как не отвечает на вопрос - а ЗАЧЕМ нужно "подключение нескольких одновременных пользователей под одной учетной записью " Мне на ум только один ответ приходит - обойти лицензионные ограничения ПО.

#7

В нашем случае клиенту-стоматологии выдается логи и пароль, в RDP ярлык прописывается ip для подключения и логин и пароль, который предоставляет доступ к базе результатов обследования ее пациентов. Установив данный ярлык на каждой рабочем компьютере клиники дает возможность одновременного подключения с разных компьютеров к одно выделенной базе пациентов с возможность просмотра результата в 3х разных программах (в какой программе изначально записано исследование в той оно и открывается)
Каждое полученное исследованные выгружается в программе и должно быть выложено в размеченную область для определенной клиники, с той с которой направили данного пациента.

#8

Объяснено это еще и тем что, выдав клинике разные Логины но доступ предоставляется к одной и той же базе, не упраздняет ограничения запуска на сервере одной и той же программы для просмотра в 2х копиях.

Примерная потребность исходит из минимального количества в клинике 1компьютера до 7, а в связи с этим создания под каждого пользователя своей рабочей среды.
А клиник в свою очередь в районе 200…

#9

Вы какие-то дикие костыли городите.

Я не пойму. Этот софт (программа), которую вы используете для формирования/просмотра результатов, может работать только локально на одной машине, и вы вот к ней организуете доступ через RDP? Или как?

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

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

#10

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

#11

Это я понял. Просто по описанию и скриншоту видно, что у них софт очень простой. Если там и всё остальное такое же, к чему они там доступ организуют, то проще всё переписать.

#12

Ни… Там дорогие программы под стоматологию. Дешевых просто нет. Со скрина же погугли - Ez3D А эти кхм… жлобы… хотят из одноюзерной версии и “говна и палок” себе на всю сеть клиник решение нарисовать. Причём типа не ломая софт а оно и так типа работает не нарушая лицензию. Я их прекрасно понимаю, но с такими желания работать почему то нет.

#13

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

#14

Программы дорогие но отдельно они ни к чему, у нас есть полный объём версий всех программ.
Есть основная программа которая получает , обрабатывает и записывает результат на диск либо выгружает в папку.
Результат выдаваемы на диск предоставляет пользователь запуск/ установка по сути вьювера и ряд инструментов для обработки результата, но так же она рассчитана на одновременно одну рабочий копию программы на компьютере, запустив повторно из папки исследования на запуск оно не открывается, либо как в другой программе говорит об открытой уже версии на данном компьютере.
В общем ограничение разработчиков.
Поэтому и было решение делать виртуальные запуски через песочницу, при данном варианте он даёт работать разным пользователем на одном сервере удаленно по схеме подключения через rdp но это не стабильно, и нет стабильной и синхронизированной связки через это решение.

#15

Почему жлобы? Это то тут причём?
Здесь вопрос реализации задачи, так как при текущих потребностях нет решения у разработчика программы. Если бы и было, то можно было говорит о злобствует на основании цены и возможностей, а так ваш «довод» или поверхностный анализ говорит о не компетенции в данном вопросе и не готовности его реализации.
Решение задачи всегда возможно, но это вопрос средств и времени.

#16

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