Из аутсорса в разработку (Часть 2)

В предыдущей статье, я рассказал о предыстории создания Veliam и о решении его распространении по системе SaaS. В этой статье, я расскажу о том, что пришлось сделать что бы продукт стал не локальным, а публичным. О том, как начинали распространение и с какими проблемами столкнулись.

Планирование

Текущая серверная часть для пользователей была на Linux. Почти в каждой организации есть Windows серверы, чего нельзя сказать о Linux. Основная сильная сторона Veliam — удаленные подключения к серверам и сетевому оборудованию за NAT. Но этот функционал был очень жестко завязан на то, что маршрутизатором должен был быть обязательно микротик. И это явно многих бы не удовлетворяло. Я сначала начал думать о том, чтобы добавить поддержку маршрутизаторов самых распространенных вендоров. Но я понимал, что это бесконечная гонка с расширением списка поддерживаемых фирм. Более того, так и те, которые уже поддерживаются, могут от модели к модели иметь различный набор команд для изменения правил NAT. Единственным выходом из ситуации виделся VPN.

Так как мы решили распространять продукт, но не как open source, то и включать в свой состав различные библиотеки с открытыми лицензиями типа GPL стало нельзя. Это вообще отдельная тема, после принятия решения о продаже продукта, пришлось перебрать половину библиотек из-за того, что они были GPL. Когда писали под себя, это было нормально. Но для распространения не подходит. Первый же VPN который приходит в голову — OpenVPN. Но он GPL. Еще был вариант использовать японский SoftEther VPN. Его лицензия позволяла включить его в состав своего продукта. После пары дней различных тестов как интегрировать его таким образом, чтобы пользователю вообще ничего не нужно было настраивать и знать про SoftEther VPN — получился прототип. Все было как надо. Но, почему-то нас эта схема все равно смущала, и мы от нее в итоге отказались. Но естественно отказались после того как придумали другой вариант. В итоге все сделали на обычных TCP соединениях. Часть подключений работает через координатор, часть напрямую через технологию Nat Hole Punching (NHP), которая также реализовывалась на Free Pascal. Надо сказать, что про NHP я ранее вообще даже не слышал. И в голову не могло прийти, что можно связать 2 сетевых устройства, оба из которых находятся за NAT напрямую. Проштудировал тему, понял принцип работы и сел писать. Задуманное осуществлено, пользователь подключается одним кликом к нужному устройству за NAT по RDP, SSH или Winbox без ввода паролей и настройки VPN. Причем большая часть этих подключений идет мимо нашего координатора, что хорошо сказывается на пинге и себестоимости обслуживания этих подключений.

Перевод серверной части с Linux на Windows

Проблем при переходе на Windows было сразу несколько. Первая — встроенный wmic в windows не позволяет делать WQL запросы. А в нашей системе уже все было построено на них. И было еще что-то, но сейчас запамятовал почему окончательно отказались от его использования. Возможно, различия между версиями Windows. И вторая проблема — многопоточность. Не найдя хорошей сторонней утилиты под “допустимой” для нас лицензией, я снова запустил IDE Lazarus. И написал необходимую утилиту. На вход подается нужный список объектов и какие именно запросы надо делать, а в ответ получаю данные. И все это в многопоточном режиме. Отлично.

После того как настроил pthreads для PHP Windows думал, что все прям запустится, но не тут-то было. По прошествии некоторого времени отладки, я понял, что pthreads вроде работает, но именно в нашей системе не работал. Стало ясно, что есть какая-то особенность работы с pthreads в Windows. Так оно и было. Прочитал документацию, и там было написано, что для Windows число потоков ограничено, причем, насколько я помню неявно. Это стало проблемой. Потому что, когда я начал сокращать число потоков, при которых приложение работало, оно делало работу очень медленно. Опять открыл IDE и в ту же утилиту был добавлен функционал по многопоточной пропинговке объектов. Ну и до кучи уже и сканирование портов туда же. Собственно, после этого, необходимость в pthreads для PHP пропала, и он больше не используется. Далее в эту утилиту были добавлены еще несколько функционалов и работает она по сей день. После этого был собран установщик для Windows, который включал в себя Apache, PHP, MariaDB, само PHP приложение и набор утилит для взаимодействия с системой, написанных на Free Pascal. Что касается установщика, то я думал, что этот вопрос быстро решу, т.к. это сверх распространенная и нужная почти для каждого софта вещь. То ли я не так искал, то ли еще что-то. Но мне попадались постоянно продукты, которые были либо недостаточно гибки, либо дорогие и при этом тоже негибкие. И все-таки я нашел бесплатный установщик, в котором можно будет предусмотреть любые хотелки. Это InnoSetup. Пишу здесь об этом, потому что мне пришлось поискать, вдруг я кому-то сэкономлю время.

Отказ от плагина в пользу своего клиента

Я ранее писал, что клиентской частью был браузер с «плагином». Так вот были такие времена, когда, то Chrome обновится и верстка немного кривится, то Windows обновится и custom uri scheme слетают. Очень не хотелось иметь такого рода сюрпризы в публичной версии продукта. Причем, custom uri начали слетать после каждого обновления Windows. Microsoft попросту удаляла все не ее ветки в нужном разделе. Также Google Chrome теперь не позволяет запомнить выбор открывать или нет приложение из custom uri, и задает этот вопрос при каждом клике на объект мониторинга. Ну и в целом, необходимо было нормальное взаимодействие с локальной системой пользователя, чего браузер не дает. Самый просто вариант в такой схеме видится просто сделать свой браузер, как многие сейчас делают через Electron. Но уже многие вещи были написаны на Free Pascal, в том числе в серверной части, поэтому решили и клиент сделать на том же языке, а не плодить зоопарк. Так был написан клиент с Chromium на борту. После этого он начал обрастать различными обвязками.

Релиз

Наконец выбрали название для системы. Мы постоянно перебирали различные варианты пока шел процесс переделывания из локальной версии в SaaS. Так как мы изначально планировали выход не только на внутренний рынок, то основным критерием подбора названия было наличие незанятого, или не очень дорогого домена в зоне “.com”. Некоторые функции/модули еще не были портированы из локальной версии в Veliam, но мы решили, что будем выпускать с текущим функционалом, а остальное доделывать уже в виде обновлений. В самой первой версии не было HelpDesk’а, Veliam Connector’а, нельзя было менять пороги срабатывания триггеров уведомлений и многое другое. Купили Code Sign Certificate, подписали клиентскую и серверную части. Написали сайт для продукта, начали процедуры регистрации программного обеспечения, товарного знака и т.д. В общем готовы начинать. Легкая эйфория от проделанной работы и от того, что возможно твоим продуктом будет кто-то пользоваться, хотя по этому поводу у нас не было сомнений. И тут стоп. Партнер сказал, что без уведомлений в мессенджеры выходить на рынок нельзя. Можно без многого другого, но не без этого. После непродолжительных споров, была добавлена интеграция с Telegram, которая нас устроила. Из всех текущих мессенджеров, это единственный, который дает доступ к своим API бесплатно и без каких-то сложных процедур согласований. Тот же WhatsApp предлагает обращаться к провайдерам, которые берут неплохие деньги за пользование их услугами, все письма с просьбой предоставить доступ без прокладок были проигнорированы. Ну а вайбер… Я не знаю кто им пользуется сейчас, т.к. спам и реклама там зашкаливают. В конце декабря, после ряда внутренних тестирований, и тестирований среди друзей, открыли регистрацию для всех и выложили софт для скачивания.

Начало распространения

С самого начала мы понимали, что нам нужен небольшой поток пользователей системы для того, чтобы они уже в боевом режиме протестировали продукт и дали какой-то первый фидбэк. Несколько купленных постов в ВК дали плоды. Пошли первые регистрации.

Тут надо сказать, что выходить на рынок, когда у твоей компании нет знаменитого имени, и при этом предоставлять функционал безагентного мониторинга, в который нужно вводить учетные записи от своих серверов и рабочих станций, очень непросто. Очень многих людей это пугает. Мы с самого начала понимали, что с этим будут проблемы и были готовы к этому и технически и морально. Все удаленные подключения, несмотря на то, что RDP и SSH итак шифруются по умолчанию, дополнительно шифруются нашим софтом по стандарту AES. Все данные из локальных серверов передаются в облако по HTTPS. Учетные записи хранятся в зашифрованном виде. Ключи шифрования для всех подсистем у всех клиентов индивидуальные. Для удаленных подключений вообще используются сеансовые ключи шифрования.

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

Для многих, удобство и функционал софта перевешивают страх, и они регистрируются. Некоторые личности в опубликованных постах в ВК писали, что это ПО использовать нельзя т.к. это собиралка их паролей и вообще ноунейм компания. Надо сказать, что такое мнение было не у одного человека. Многие просто не понимают, что, когда они ставят к себе другой проприетарный софт на сервер, который работает как служба, точно так же имеет полные права в системе и им не нужны учетки для того чтобы делать что-то противоправное (понятно, что можно изменить пользователя от которого запускается служба, но так и тут, вводить можно учетную запись любую). На самом деле — опасения людей понятны. Установка софта на сервер — это дело привычное, а вот ввод учетной записи — это уже немного страшно и интимно, так как у доброй половины людей один пароль на все сервисы, а делать отдельную учетку даже для теста лениво. Но на текущий момент есть огромное количество сервисов, которым люди доверяют свои учетные данные и не только. И мы стремимся стать одними из них.

Много комментариев было такого плана, что мы где-то это украли. Нас это слегка удивило. Ну ладно мнение одного человека, но такие комментарии встречались в различных публикациях от разных людей. Не знали сначала как на это реагировать. То ли грустить о том, что у некоторых людей мнение, что в России никто ничего не может сделать сам, а может только украсть то ли радоваться, что считают, что такое можно только украсть.

Сейчас мы завершили процедуру получения EV Code Sign Certificate. Для его получения необходимо пройти ряд проверок и отправить кучу документов о компании, часть из которых должны быть заверены адвокатом. Получение EV Code Sign сертификата в условиях пандемии — это вообще отдельная тема для статьи. Процедура затянулась на месяц. И это был месяц не ожидания, а постоянных запросов дополнительных документов. Может пандемия тут не при чем, и у всех процедура проходила так долго? Поделитесь.

Некоторые говорят, что не будем пользоваться потому, что нет сертификата ФСТЭК. Приходится объяснять, что мы не можем его получить и не будем потому, что для получения этого сертификата — шифрование должно быть по ГОСТ, а мы планируем распространение ПО не только в России и используем AES.

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

Добавление функционала удаленного доступа для сотрудников

Одна из частых задач от клиентов является «сделайте Ване доступ к его компьютеру из дома». Поднимали VPN на микротик и делали для пользователей учетки. Но это реально проблема. Пользователи не в состоянии смотреть инструкцию и сделать ее по шагам чтобы подключиться по VPN. Разные версии Windows. В одной винде все хорошо подключается, в другой нужен другой протокол. И в общем это всегда было связано с перенастройкой сетевого оборудования, которое выступало сервером VPN, а не у всех сотрудников есть до него доступ и это было неудобно.

Но у нас же уже есть удаленные подключения к серверам и сетевому оборудованию. Почему бы не воспользоваться готовым транспортом и не сделать отдельную утилиту маленького размера, которую можно просто дать пользователю для подключения. Хотелось только сделать так, чтобы пользователь там ничего не вводил заумного. Просто одна кнопка «подключиться». Но как эта утилита будет понимать куда подключаться, если в ней только одна кнопка. Была идея онлайн сборки нужного приложения на наших серверах. Системный администратор нажимает кнопку «скачать ярлык», и к нам в облако подается команда на сборку индивидуального бинарника с зашитой информацией по подключению к нужному серверу / компьютеру по RDP. В целом это можно было сделать. Но это долго, администратору пришлось бы ждать сначала пока бинарник скомпилируется, а потом и скачается. Можно было бы конечно добавить просто второй файлик с конфигом, но это уже 2 файла, а для простоты пользователю нужен один. Один файлик, одна кнопка и никаких установщиков. Почитав немного просторы гугла, я пришел к выводу что, если в конец скомпилированного “.exe” добавить какую-то информацию, то он не портится (ну почти). Туда можно хоть войну и мир добавить, и он будет работать, как и раньше. Грех этим не воспользоваться. Теперь можно просто на ходу прямо в самом клиенте распаковывать приложение, кстати оно называется Veliam Connector, и просто дописывать к нему в конец нужную для подключения информацию. А уж само приложение знает, что с этим делать. Почему я чуть выше в скобках написал «ну почти»? Потому, что за это удобство приходится платить тем, что приложение теряет свою подпись ЭЦП. Но мы, на данном этапе, считаем, что это небольшая цена за такое удобство.

Лицензии сторонних модулей

Выше я уже писал, что после того как было решено сделать продукт общедоступным, а не только для своего пользования, пришлось изрядно потрудиться и поискать замены некоторым модулям, которые не позволяли включать себя в состав нашего продукта. Но уже после релиза, случайно обнаружилась весьма неприятная вещь. В составе Veliam Server, который был на стороне клиента была СУБД MariaDB. И она с лицензией GPL. Лицензия GPL предполагает, что софт должен быть с открытым исходным кодом, и если в состав нашего продукта включена MariaDB которая имеет эту лицензию, то и наш продукт должен быть под этой лицензией. Но к счастью, у этой лицензии цель — открытый исходный код, а не наказание в суде тех, кто случайно ошибся. Если у правообладателя появляется претензия, то он письменно уведомляет нарушителя и тот должен в течении 30 дней устранить нарушение. Мы обнаружили свою ошибку сами и писем не получали и сразу принялись рассматривать варианты как решить проблему. Выход оказался очевиден — переход на SQLite. У этой БД нет никаких ограничений по лицензированию. Большинство современных браузеров использует SQLite, да и куча других программ. Находил в интернете информацию, что SQLite считается самой распространенной СУБД в мире, как раз-таки из-за браузеров, но не искал пруфов, так что это неточная информация. Начал изучать чем грозит переход на SQLite.

Это становится уже нетривиальной задачей, когда есть несколько сотен установленных у клиентов серверов с MariaDB и данными в ней. Некоторые фишки MariaDB недоступны в SQLite. Ну, например, в коде использовали запросы типа

Select * FROM `table` WHERE `id`>1000 FOR UPDATE

Данная конструкция делает не только выборку из таблицы, но и блокирует данные строки. И еще несколько конструкций тоже пришлось переписывать. Но помимо того, что пришлось переписывать много запросов, так же пришлось придумывать механизм, который при обновлении Veliam Server у клиента портирует все данные в новую СУБД и удалит старую. Также, не работали транзакции в SQLite и это было реальной проблемой. Но почитав просторы всемирной паутины, я без проблем нашел, что транзакции в SQLite можно включить, передав при подключении простую команду

PRAGMA journal_mode=WAL;

В итоге задача выполнена и теперь серверная часть у клиентов работает на SQLite. Каких-то изменений в работе системы мы не заметили.

Новый HelpDesk

Из внутренней версии в SaaS версию необходимо было портировать HelpDesk систему, но с некоторыми изменениями. Первое, что хотелось сделать — это интеграция с доменом клиента в части прозрачной авторизации пользователей в системе. Сейчас пользователь чтобы зайти в HelpDesk и оставить заявку в системе, просто нажимает на ярлык на рабочем столе и открывается браузер. Пользователь не вводит никаких учетных данных. Модуль для Apache SSPI, который входит в состав Veliam Server автоматически авторизует пользователя под доменной учетной записью. Чтобы оставить заявку в системе, когда пользователь находится за пределами корпоративной сети, он нажимает на кнопку, и ему на почту приходит ссылка, по которой он без паролей авторизуется в системе HelpDesk. Если пользователя выключить или удалить в домене, то и учетная запись в HelpDesk тоже перестанет работать. Таким образом, системному администратору не нужно самому следить за учетными записями и в домене, и в HelpDesk. Уволился сотрудник — отключил учетную запись в домене и все, он не зайдет в систему не из корпоративной сети, не по ссылке. Для работы данной интеграции, системному администратору нужно сделать одну GPO, которая добавляет внутренний сайт в зону интрасети и раскидывает ярлык всем пользователям на рабочий стол.

Второе, что считаем крайне необходимым для систем HelpDesk, во всяком случае для нас самих — это подключение к заявителю прямо из заявки в один клик. Более того, подключения должны проходить, если системный администратор находится в другой сети. Для аутсорса это обязательно, для штатных системных администраторов тоже часто очень нужно. Есть уже несколько продуктов, которые прекрасно справляются с задачей удаленных подключений. И мы решили сделать для них интеграции. Сейчас мы сделали интеграцию для VNC, а в будущем планируем добавить Radmin и TeamViewer. Используя наш сетевой транспорт для удаленных подключений к инфраструктуре, мы сделали так, что VNC подключается к удаленным рабочим станциям за NAT. Тоже самое будет и с Radmin. Сейчас, для того чтобы подключиться к пользователю, нужно просто в самой заявке нажать кнопку “подключиться к заявителю”. Открывается VNC клиент и подключается к заявителю независимо от того в одной вы с ним сети или сидите дома в тапочках. Предварительно, системный администратор, средствами ГПО должен установить всем на рабочие станции VNC Server.

Сейчас мы сами переходим на новый HelpDesk и пользуемся интеграцией с доменом и VNC. Это очень удобно для нас. Теперь мы можем не платить за TeamViewer, которым мы пользовались больше трех лет для работы нашей службы поддержки.

Что планируем делать дальше

Когда мы выпустили продукт, то не делали никаких платных тарифов, а просто ограничили бесплатный тариф 50 объектами мониторинга. Пять десятков сетевых устройств и серверов должно хватить всем, подумали мы. И тут начали поступать запросы на увеличение лимита. Сказать, что мы были немного в шоке — ничего не сказать. Неужели нашим софтом заинтересовались компании, у которых такое количество серверов. Мы бесплатно расширяли лимит для тех, кто делал такие запросы. У некоторых мы в ответ на их запрос спросили зачем им столько, неужели у них такое большое количество серверов и сетевого оборудования. И оказалось, что системные администраторы начали использовать систему так, как мы вообще не планировали. Все оказалось просто — мониторить нашим софтом начали не только серверы, но и рабочие станции. Отсюда и много запросов на расширение лимитов. Сейчас мы уже ввели платные тарифы и лимиты можно расширить самостоятельно.

Серверы, почти всегда работают либо с СХД либо с локальными дисками в RAID массиве. И мы делали изначально продукт для них. И мониторинг SMART был неинтересен для этой задачи. Но с учетом того, что люди приспособили софт для мониторинга рабочих станций, появились запросы на реализацию мониторинга SMART. Вскоре мы его реализуем.

С появлением Veliam Connector, стало ненужным развертывание VPN сервера в корпоративной сети, или делать RDGW, или просто пробрасывать порты до необходимых машин для подключения по RDP. Очень многие пользуются нашей системой только лишь для этих удаленных подключений. Veliam Connector есть только под Windows, а некоторые пользователи компаний подключаются с домашних ноутбуков под управлением MacOS к рабочим станциям или терминалам в корпоративной сети. И получается, что системный администратор вынужден из-за нескольких пользователей все равно возвращаться к вопросу пробросов или VPN. Поэтому сейчас мы уже заканчиваем делать версию Veliam Connector под MacOS. Пользователи своей любимой яблочной техники так же получат возможность в один клик подключаться к корпоративной инфраструктуре.

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

Параллельно, планируем сейчас заняться переводом системы на английский язык и распространением ее зарубеж. Мы пока не знаем, как будем распространять продукт вне нашей страны, ищем варианты. Возможно об этом позже будет отдельная статья. Возможно кто-то из тех, кто прочитал эту статью, сможет подсказать нужный вектор, ну или сам знает и умеет как это делать и предложит свои услуги. Будем признательны за помощь.

Источник: habr.com