В , разказах за предисторията на създаването на Veliam и решението за разпространение му чрез SaaS система. В тази статия ще разкажа какво беше необходимо, за да стане продуктът публичен, а не локален. За това как стартирахме разпространението и с какви проблеми се сблъсквахме.
Планиране
Текущата сървърна част за потребителите беше на Linux. Почти във всяка организация има Windows сървъри, което не може да се каже за Linux. Основната сила на Veliam е удалеченото свързване към сървъри и мрежово оборудване зад NAT. Но този функционал беше много строго свързан с факта, че маршрутизаторът трябваше задължително да бъде Mikrotik. И това явно много хора няма да удовлетворява. Първоначално започнах да мисля за добавяне на подкрепа за маршрутизатори на най-разпространените производители. Но разбирах, че това е безкрайна надпревара с разширяването на списъка на поддържаните компании. Освен това, дори тези, които вече се поддържат, от модел на модел могат да имат различен набор от команди за промяна на правилата на NAT. Единственото решение, което виждах, беше VPN.
Тъй като решихме да разпространяваме продукта, но не като open source, не можем да включваме в него различни библиотеки с отворени лицензионни условия, като GPL. Това е отделна тема — след решението за продажба на продукта, трябваше да преразгледаме половината от библиотеките заради GPL лиценза. Когато го разработвахме за себе си, това беше наред. Но за разпространение не става. Първият VPN, който идва на ум, е OpenVPN. Но той е GPL. Имаше и опция да използваме японския SoftEther VPN. Лицензията му позволяваше да го включим в нашия продукт. След няколко дни различни тестове как да го интегрираме така, че потребителят да не трябва да настройва нищо и да не знае за SoftEther VPN — се получи прототип. Всичко беше както трябва. Но по някаква причина тази схема ни смущаваше и в крайна сметка се отказахме от нея. Разбира се, отказахме се след като измислихме друг вариант. В крайна сметка всичко е направено на обикновени TCP връзки. Част от свързванията работят през координатор, част директно чрез технологията Nat Hole Punching (NHP), която също се реализираше на Free Pascal. Трябва да кажа, че преди това не бях чувал за NHP. Не ми беше хрумвало, че е възможно да свържа две мрежови устройства, и двете от които са зад 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, не можеше да се променят праговете за задействане на известия и много други. Закупихме сертификат за подписване на код, подписахме клиентската и сървърната части. Написахме сайт за продукта, започнахме процедурите за регистрация на софтуера, търговска марка и т.н. В общи линии, готови сме да започнем. Лека еуфория от свършената работа и от това, че е възможно някой да ползва продукта ни, въпреки че по този въпрос нямахме съмнения. И тук спираме. Партньорът каза, че без известия в месинджърите не можем да излезем на пазара. Можем и без много други неща, но не и без това. След кратки спорове, беше добавена интеграция с Telegram, която ни устройва. От всички настоящи месинджъри, това е единственият, който предоставя достъп до своето API безплатно и без сложни процедури за одобрение. WhatsApp предлага да се свържете с доставчици, които таксуват добра сума за ползването на техните услуги, всички писма с искания за предоставяне на достъп без посредници бяха игнорирани. А за Viber… Не знам кой го ползва в момента, тъй като спамът и реклама там са в излишък. В края на декември, след редица вътрешни тестове и тестове сред приятели, отворихме регистрация за всички и публикувахме софтуера за изтегляне.
Начало на разпространението
Още от самото начало разбрахме, че ни е необходим малък поток потребители на системата, за да те да тестват продукта в реални условия и да предоставят първоначална обратна връзка. Няколко платени поста в ВК дадоха резултат. Появиха се първите регистрации.
Тук трябва да споменем, че излизането на пазара, когато вашата компания няма известно име, и предоставянето на функционалности за безагентен мониторинг, в които трябва да се въвеждат акаунти от собствени сървъри и работни станции, е много трудно. Това плаши много хора. От самото начало разбирахме, че ще имаме проблеми с това и бяхме подготвени както технически, така и морално. Всички дистанционни връзки, въпреки че RDP и SSH по подразбиране вече са криптирани, се криптират допълнително от нашия софтуер по стандарт AES. Всички данни от локалните сървъри се предават в облака по HTTPS. Акаунтите се съхраняват в криптиран вид. Ключовете за криптиране на всички подсистеми за всички клиенти са индивидуални. За дистанционните връзки се използват сесийни ключове за криптиране.
Всичко, което можем да направим в тази ситуация, за да успокоим хората, е да бъдем максимално открити, да работим върху сигурността и да не се уморяваме да отговаряме на задаваните им въпроси.
За много хора удобството и функционалността на софтуера преодоляват страха и те се регистрират. Някои лица в публикувани постове във ВК писали, че този софтуер не бива да се използва, защото е събирач на техните пароли и изобщо е ноунейм компания. Трябва да се подчертае, че такова мнение не е само на един човек. Много просто не разбират, че когато инсталират друг собствен софтуер на сървър, който работи като услуга, той има същите пълни права в системата и не им трябват потребителски акаунти, за да правят нещо незаконно (разбира се, че може да сменят потребителя, от който се стартира услугата, но и тук, може да се въведе какъвто и да е акаунт). Всъщност — притесненията на хората са разбираеми. Инсталирането на софтуер на сървър е обичайно дело, но въвеждането на акаунт е малко плашещо и интимно, тъй като при добрата половина от хората един и същ парола се използва за всички услуги, а да създадат отделен акаунт, дори за тест, им е мързеливо. Но в момента има огромно количество услуги, на които хората се доверяват със своите акаунти и не само. И ние се стремим да станем сред тях.
Много коментари звучаха в смисъл, че сме откраднали нещо. Това ни учуди малко. Да, мнението на един човек, но такива коментари се появиха в различни публикации от различни хора. Първоначално не знаехме как да реагираме. Да тъгуваме за това, че някои хора мислят, че в Русия никой не може да направи нещо сам, а само да открадне, или да се радваме, че смятат, че нещо такова може да бъде откраднато.
Сега завършихме процедурата за получаване на EV Code Sign сертификат. За неговото получаване трябва да преминем през редица проверки и да подадем куп документи за компанията, част от които трябва да бъдат заверени от адвокат. Получаването на EV Code Sign сертификат в условията на пандемията - това е напълно отделна тема за статия. Процедурата отне един месец. И това не беше месец на изчакване, а постоянни искания за допълнителни документи. Може би пандемията няма общо с това, и при всички процедурата е отнела толкова време? Споделете.
Някои казват, че няма да ползваме, защото нямаме сертификат от ФСТЭК. Налага се да обясняваме, че не можем да го получим и няма да го направим, защото за получения сертификат - криптирането трябва да бъде по ГОСТ, а ние планираме разпространение на софтуер не само в Русия и използваме AES.
Всички тези коментари навяваха малка несигурност относно възможността да се промотира продукт, който изисква въвеждане на акаунти, без да сме известни. Дори с оглед на факта, че знаехме, че ще има хора, които са много негативно настроени към това. След като броят на регистрациите премина хиляда, престанахме да се тревожим за това. Особено след като, освен негативните коментари от тези, които дори не са опитали продукта, започнаха да се появяват и много положителни отзиви. Трябва да се каже, че тези положителни отзиви са най-голямият мотиватор за развитието на продукта.
Добавяне на функционалност за отдалечен достъп за служителите.
Една от честите задачи на клиентите е "достъп до компютъра на Ваня от вкъщи". Настравахме VPN на MikroTik и създавахме акаунти за потребителите. Но това наистина е проблем. Потребителите не успяват да четат инструкциите и да ги следват стъпка по стъпка, за да се свържат през VPN. Различни версии на Windows. В един 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
Необходимо беше да се премести HelpDesk системата от вътрешната версия в SaaS версия, но с някои изменения. Първото, което искахме да направим, е интеграцията с домейна на клиента за прозрачна авторизация на потребителите в системата. Сега потребителят, за да влезе в HelpDesk и да подаде заявка, просто натиска иконата на работния плот и се отваря браузър. Потребителят не въвежда никакви данни за вход. Модулът за Apache SSPI, който е част от Veliam Server, автоматично авторизира потребителя с домейнната му учетна записа. Когато потребителят е извън корпоративната мрежа и иска да подаде заявка, натиска бутона и на имейла му идва линк, с който той се авторизира в системата HelpDesk без пароли. Ако потребителят бъде изключен или изтрит от домейна, и учетната му записка в HelpDesk спира да работи. Така системният администратор не трябва сам да следи учетните записа и в домейна, и в HelpDesk. Уволнил се е служител — изключил е учетната записка в домейна и всичко, вече не може да влезе в системата, нито от корпоративната мрежа, нито по линка. За работа на тази интеграция, системният администратор трябва да направи една GPO, която и .
Второто, което считаме за крайно необходимо за системите HelpDesk, поне за нас самите, е свързването с подателя на заявката с един клик директно от самата заявка. Освен това, свързванията трябва да се осъществяват, дори ако системният администратор е в друга мрежа. За аутсорсинга това е задължително, а за вътрешните системни администратори също е много необходимо. Вече има няколко продукта, които прекрасно вършат работата по отдалечен достъп. И ние решихме да направим интеграции за тях. В момента сме направили интеграция за VNC, а в бъдеще планираме да добавим Radmin и TeamViewer. Използвайки нашия мрежов транспорт за отдалечен достъп до инфраструктурата, направихме така, че VNC да се свързва с отдалечените работни станции зад NAT. Същото ще е и с Radmin. В момента, за да се свържете с потребителя, е нужно просто в самата заявка да натиснете бутона “свържи се с подателя”. Отваря се VNC клиент и се свързва с подателя, независимо дали сте в една мрежа или си седите вкъщи в пантофи. Предварително системният администратор, чрез GPO, трябва да инсталира VNC Server на всички работни станции.
В момента ние сами преминаваме на новия HelpDesk и ползваме интеграцията с домейна и VNC. Това е много удобно за нас. Сега можем да спестим от TeamViewer, който използвахме повече от три години за работата на нашата поддръжка.
Какво планираме да правим по-нататък
Когато пуснахме продукта, не направихме никакви платени тарифи, а просто ограничихме безплатния тариф до 50 мониторируеми обекта. Петдесет мрежови устройства и сървъри би трябвало да са достатъчни за всички, помислихме ние. И тук започнаха да постъпват искания за увеличаване на лимита. Да кажем, че бяхме малко шокирани — нищо не е сказать. Дали наистина нашият софтуер интересува компании, които имат толкова много сървъри? Безплатно разширявахме лимита за тези, които правеха такива искания. На някои от тях в отговор на искането попитахме защо им трябват толкова много, нали не разполагат с такова голямо количество сървъри и мрежово оборудване? И се оказа, че системните администратори започнаха да използват системата по начин, който въобще не сме планирали. Всичко стана просто — с нашия софтуер започнаха да се наблюдават не само сървърите, но и работните станции. Оттук и многото искания за увеличение на лимитите. Вече въведохме платени тарифи и лимитите могат да се разширяват самостоятелно.
Сървърите почти винаги работят или с СХД, или с локални дискове в RAID масив. И ние първоначално създадохме продукта за тях. Мониторингът на SMART не беше интересен за тази задача. Но с оглед на факта, че хората адаптираха софтуера за мониторинг на работни станции, се появиха искания за реализиране на мониторинг на SMART. Скоро ще го реализираме.
С появата на Veliam Connector, разгръщането на VPN сървър в корпоративната мрежа стана ненужно, или правенето на RDGW, или просто пренасочването на портовете до необходимите машини за свързване чрез RDP. Много хора използват нашата система само за тези отдалечени връзки. Veliam Connector е наличен само за Windows, а някои потребители на компаниите се свързват от домашните си лаптопи с MacOS към работни станции или терминали в корпоративната мрежа. И така системният администратор е принуден заради няколко потребители все пак да се върне към проблема с пренасочванията или VPN. Затова в момента завършваме версията на Veliam Connector за MacOS. Потребителите на любимата си ябълкова техника също ще получат възможност с един клик да се свързват с корпоративната инфраструктура.
Много ми харесва, че, когато имам голям брой потребители на системата, не трябва да се чудя какво е необходимо на хората и какво ще им е по-удобно. Те сами пишат своите предложения, така че плановете за разработка за близкото бъдеще са много.
В същото време планираме сега да се заемем с превода на системата на английски език и разпространението ѝ в чужбина. Все още не знаем как ще разпространяваме продукта извън нашата страна, търсим варианти. Може би по-късно ще има отделна статия за това. Може би някой от онези, които прочетоха тази статия, ще може да подсказе нужната посока, или сам знае и може да предложи своите услуги. Ще бъдем благодарни за помощта.
Източник: habr.com
