Dmitry A. Gunko » Вс авг 28, 2022 11:42 pm
Доброго времени суток, коллеги и ув. тов. разработчики!
Для начала хочу выразить благодарность разработчикам WTware от лица нашей компании, а так же организаций, стоящих на технической поддержке, за хороший отечественный продукт. Напишу сюда, чтобы не плодить новых тем, т.к. речь пойдет о средствах удаленного управления.
Преамбула такова. Импортозамещение набирает реальные обороты и уже не на бумаге. Рабочие станции тотально мигрируем на отечественные линуксы, а там, где технически оправдано, на WTware. Параллельно идет замена зоопарков AmmyyAdmin / AnyDesk / TeamViewer на открытый аналог - RustDesk. Просьба к разработчикам: рассмотреть возможность включения этого средства удаленного управления.
Наши резоны (возможно кому-то окажутся полезными) и ответы на возможные вопросы разработчиков:
1. Унификация средства удаленной помощи пользователям.
2. Текущий механизм удаленной помощи пользователям, основанный на внутреннем протоколе WTware, накладывает ограничения для одновременной работы как нашей внутренней группы helpdesk'a, так и удаленных прикладников, например, специалистов 1с. Для подключения к linux-станциям (и остаткам windows-станций) в данный момент внедряется такой алгоритм: на управляемой машине ставится RustDesk, на управляющих машинах тоже RustDesk, подключенный к RustDesk-серверу, где хранятся адресные книги, права доступа техников и прикладников. Решение хорошо интегрируется с HelpDesk-системами для подключения "one-click" к нужному пользователю, с учетом контроля доступа. Хотелось бы сохранить данные возможности при переводе части станций с локальных операционных систем на WTware.
3. В описанной выше схеме можно использовать присутствующий в WTware протокол VNC, но он обладает всеми недостатками протокола VNC )) и по этому серьезно заставляет задуматься об альтернативе.
4. Для управления большими инфраструктурами мы стараемся использовать подход Infrastructure-as-Code и уходить от схемы "1 Продукт Вендора = 1 Конфигуратор Вендора". Конфигурации с историей изменений хранятся в Git, управление через Ansible. С этой точки зрения WTware хорошо вписывается в нашу систему - конфигурации текстовые, документированы хорошо, правила сборки результирующих конфигов понятны. Как результат, все описывается шаблонами Ansible и отдельный Конфигуратор не требуется.
Еще раз благодарим за проделанную работу. Надеемся, что наша просьба не останется без внимания.
Учитывая открытость кода RustDesk (
https://github.com/rustdesk/rustdesk/bl ... ADME-RU.md)
и наличие его сборок под различные платформы, с точки зрения технической реализации задача не должна быть очень сложной.
Доброго времени суток, коллеги и ув. тов. разработчики!
Для начала хочу выразить благодарность разработчикам WTware от лица нашей компании, а так же организаций, стоящих на технической поддержке, за хороший отечественный продукт. Напишу сюда, чтобы не плодить новых тем, т.к. речь пойдет о средствах удаленного управления.
Преамбула такова. Импортозамещение набирает реальные обороты и уже не на бумаге. Рабочие станции тотально мигрируем на отечественные линуксы, а там, где технически оправдано, на WTware. Параллельно идет замена зоопарков AmmyyAdmin / AnyDesk / TeamViewer на открытый аналог - RustDesk. Просьба к разработчикам: рассмотреть возможность включения этого средства удаленного управления.
Наши резоны (возможно кому-то окажутся полезными) и ответы на возможные вопросы разработчиков:
1. Унификация средства удаленной помощи пользователям.
2. Текущий механизм удаленной помощи пользователям, основанный на внутреннем протоколе WTware, накладывает ограничения для одновременной работы как нашей внутренней группы helpdesk'a, так и удаленных прикладников, например, специалистов 1с. Для подключения к linux-станциям (и остаткам windows-станций) в данный момент внедряется такой алгоритм: на управляемой машине ставится RustDesk, на управляющих машинах тоже RustDesk, подключенный к RustDesk-серверу, где хранятся адресные книги, права доступа техников и прикладников. Решение хорошо интегрируется с HelpDesk-системами для подключения "one-click" к нужному пользователю, с учетом контроля доступа. Хотелось бы сохранить данные возможности при переводе части станций с локальных операционных систем на WTware.
3. В описанной выше схеме можно использовать присутствующий в WTware протокол VNC, но он обладает всеми недостатками протокола VNC )) и по этому серьезно заставляет задуматься об альтернативе.
4. Для управления большими инфраструктурами мы стараемся использовать подход Infrastructure-as-Code и уходить от схемы "1 Продукт Вендора = 1 Конфигуратор Вендора". Конфигурации с историей изменений хранятся в Git, управление через Ansible. С этой точки зрения WTware хорошо вписывается в нашу систему - конфигурации текстовые, документированы хорошо, правила сборки результирующих конфигов понятны. Как результат, все описывается шаблонами Ansible и отдельный Конфигуратор не требуется.
Еще раз благодарим за проделанную работу. Надеемся, что наша просьба не останется без внимания.
Учитывая открытость кода RustDesk (https://github.com/rustdesk/rustdesk/blob/master/README-RU.md)
и наличие его сборок под различные платформы, с точки зрения технической реализации задача не должна быть очень сложной.