В , говорих за предисторията на създаването на Veliam и решението да се разпространява чрез системата SaaS. В тази статия ще говоря за това какво трябваше да направя, за да направя продукта не местен, а публичен. За това как е започнало разпространението и какви проблеми са срещнали.
планиране
Текущият бекенд за потребителите беше на Linux. Почти всяка организация има Windows сървъри, което не може да се каже за Linux. Основната сила на Veliam са отдалечените връзки към сървъри и мрежово оборудване зад NAT. Но тази функционалност беше много тясно обвързана с факта, че рутерът трябваше да е Mikrotik. И това очевидно няма да задоволи мнозина. Първо започнах да мисля за добавяне на поддръжка за рутери от най-обикновените доставчици. Но разбрах, че това е безкрайна надпревара за разширяване на списъка с поддържани компании. Освен това тези, които вече се поддържат, може да имат различен набор от команди за промяна на NAT правила от модел на модел. Единственият изход от ситуацията изглеждаше VPN.
Тъй като решихме да разпространяваме продукта, но не като отворен код, стана невъзможно да включим различни библиотеки с отворени лицензи като GPL. Това като цяло е отделна тема, след като взех решението да продам продукта, трябваше да прегледам половината библиотеки поради факта, че са GPL. Когато са писали за себе си е нормално. Но не е подходящ за разпространение. Първият VPN, който идва на ум, е OpenVPN. Но това е GPL. Друг вариант беше да се използва японският SoftEther VPN. Неговият лиценз му позволява да го включи в своя продукт. След няколко дни различни тестове за това как да го интегрирате по такъв начин, че потребителят да не е необходимо да конфигурира нищо и да знае за SoftEther VPN, беше получен прототип. Всичко беше както трябва. Но по някаква причина тази схема все още ни объркваше и в крайна сметка я изоставихме. Но те естествено отказаха, след като измислиха друг вариант. В крайна сметка всичко беше направено на обикновени TCP връзки. Някои връзки работят чрез координатор, някои директно чрез технологията Nat Hole Punching (NHP), която също е внедрена във Free Pascal. Трябва да кажа, че никога преди не бях чувал за NHP. И никога не ми е хрумвало, че е възможно да се свържат 2 мрежови устройства, като и двете са директно зад NAT. Проучих темата, разбрах принципа на работа и седнах да пиша. Планът е реализиран, потребителят се свързва с едно кликване към желаното устройство зад NAT чрез RDP, SSH или Winbox без въвеждане на пароли или настройване на VPN. Освен това повечето от тези връзки минават покрай нашия координатор, което се отразява добре на ping и разходите за обслужване на тези връзки.
Прехвърляне на сървърната част от Linux към Windows
Имаше няколко проблема при преминаване към Windows. Първият е, че вграденият wmic в windows не ви позволява да правите WQL заявки. И в нашата система всичко вече беше изградено върху тях. Имаше и още нещо, но вече забравих защо накрая го изоставиха. Възможни разлики между версиите на Windows. И вторият проблем е многопоточността. Тъй като не намерих добра помощна програма на трета страна под „приемлив“ лиценз за нас, стартирах отново Lazarus IDE. И написах необходимата помощна програма. Входът е необходимият списък с обекти и какви конкретни заявки трябва да бъдат направени, а в отговор получавам данни. И всичко това в многонишков режим. Страхотен.
След като настроих pthreads за PHP Windows, мислех, че всичко ще започне веднага, но не беше така. След известно време на отстраняване на грешки осъзнах, че pthreads изглежда работят, но не работят в нашата система. Стана ясно, че има някои особености при работата с pthreads на Windows. Така и беше. Прочетох документацията и там пишеше, че за Windows броят на нишките е ограничен и доколкото си спомням имплицитно. Това се превърна в проблем. Защото, когато започнах да намалявам броя на нишките, на които приложението работи, то вършеше работата много бавно. Отворих отново IDE и към същата помощна програма беше добавена функционалност за многонишков пинг на обекти. Е, там вече има много сканиране на портове. Всъщност след това необходимостта от pthreads за PHP изчезна и той вече не се използва. Освен това към тази помощна програма бяха добавени още няколко функционалности и тя работи и до днес. След това беше сглобен инсталатор за Windows, който включва Apache, PHP, MariaDB, самото PHP приложение и набор от помощни програми за взаимодействие със системата, написани на Free Pascal. Що се отнася до инсталатора, мислех, че бързо ще разреша този проблем, защото... Това е много често срещано нещо и необходимо за почти всеки софтуер. Или търсих на грешното място, или нещо друго. Но постоянно попадах на продукти, които или не бяха достатъчно гъвкави, или скъпи и също негъвкави. И все пак намерих безплатен инсталатор, в който ще бъде възможно да предвидя всякакви желания. Това е InnoSetup. Пиша за това тук, защото трябваше да го потърся, в случай че спестя време на някого.
Отказ от плъгина в полза на вашия клиент
По-рано писах, че клиентската част е браузър с „плъгин“. Така че имаше моменти, когато Chrome беше актуализиран и оформлението беше малко криво, след което Windows беше актуализиран и персонализираната uri схема изчезна. Наистина не исках да имам подобни изненади в публичната версия на продукта. Освен това персонализираният URI започна да изчезва след всяка актуализация на Windows. Microsoft просто изтри всички клонове, които не са негови, в необходимия раздел. Освен това Google Chrome вече не ви позволява да запомните избора да отворите или не дадено приложение от потребителския uri адрес и задава този въпрос всеки път, когато щракнете върху обект за наблюдение. Е, като цяло беше необходимо нормално взаимодействие с локалната система на потребителя, което браузърът не предоставя. Най-простият вариант в тази схема изглежда е просто да направите свой собствен браузър, както мнозина сега правят чрез Electron. Но много неща вече бяха написани на Free Pascal, включително в сървърната част, така че решихме да направим клиента на същия език, а не да създаваме зоопарк. Ето как е написан клиент с Chromium на борда. След това започна да придобива различни ремъци.
Пуснете
Накрая избрахме име за системата. Постоянно преминавахме през различни опции, докато тече процесът на преобразуване от локалната версия към SaaS. Тъй като първоначално планирахме да навлезем не само на вътрешния пазар, основният критерий за избор на име беше наличието на незает или не много скъп домейн в зоната „.com“. Някои функции/модули все още не са пренесени от локалната версия към Veliam, но решихме, че ще ги пуснем с текущата функционалност и ще завършим останалите като актуализации. В първата версия нямаше HelpDesk, Veliam Connector, беше невъзможно да се променят праговете за задействане на известия и много други. Купихме сертификат за кодов знак и подписахме клиентската и сървърната част. Написахме уебсайт за продукта, започнахме процедури за регистрация на софтуер, търговска марка и т.н. Като цяло сме готови да започнем. Лека еуфория от свършената работа и от факта, че може би някой ще използва вашия продукт, въпреки че не сме се съмнявали в това. И тогава спрете. Партньорът каза, че е невъзможно да се влезе на пазара без известия чрез месинджъри. Без много други неща може, но не и без това. След известен дебат беше добавена интеграция с Telegram, което ни устройваше. От всички настоящи месинджъри, това е единственият, който предоставя достъп до своите API безплатно и без сложни процедури за одобрение. Същият WhatsApp предлага да се свържете с доставчици, които таксуват добри пари за използването на техните услуги, всички писма с искане за достъп без уплътнения бяха игнорирани. Ами Viber... Не знам кой го използва сега, защото... спамът и рекламата там са извън класациите. В края на декември, след поредица от вътрешни тестове и тестове сред приятели, регистрацията беше отворена за всички и софтуерът беше достъпен за изтегляне.
Начало на разпространението
От самото начало разбрахме, че имаме нужда от малък поток от системни потребители, за да могат да тестват продукта в боен режим и да дадат някаква първа обратна връзка. Няколко закупени публикации във VK дадоха плод. Пристигнаха първите регистрации.
Тук трябва да се каже, че навлизането на пазара, когато вашата компания няма известно име, и в същото време предоставянето на функция за наблюдение без агенти, в която трябва да въвеждате акаунти от вашите сървъри и работни станции, е много трудно. Това плаши много хора. От самото начало разбрахме, че ще има проблеми с това и бяхме подготвени за това както технически, така и морално. Всички отдалечени връзки, въпреки факта, че RDP и SSH вече са криптирани по подразбиране, са допълнително криптирани от нашия софтуер, използвайки стандарта AES. Всички данни от локалните сървъри се прехвърлят в облака чрез HTTPS. Сметките се съхраняват в криптирана форма. Ключовете за криптиране за всички подсистеми са индивидуални за всички клиенти. За отдалечени връзки обикновено се използват ключове за криптиране на сесии.
Всичко, което можем да направим в тази ситуация, за да накараме хората да се чувстват по-спокойни, е да бъдем максимално отворени, да работим върху безопасността и никога да не се уморяваме да отговаряме на въпросите на хората.
За мнозина удобството и функционалността на софтуера надделяват над страха и те се регистрират. Някои лица написаха в публикувани публикации във VK, че този софтуер не може да се използва, защото Това е колекция от техните пароли и като цяло компания без име. Трябва да се каже, че повече от един човек имаше това мнение. Много хора просто не разбират, че когато инсталират друг частен софтуер на сървър, който работи като услуга, той също има пълни права в системата и не се нуждаят от акаунти, за да направят нещо незаконно (ясно е, че можете да промените потребител, от който се стартира услугата, но и тук можете да въведете всеки акаунт). Всъщност страховете на хората са разбираеми. Инсталирането на софтуер на сървър е обичайно нещо, но влизането в акаунт е малко страшно и интимно, тъй като добрата половина от хората имат една и съща парола за всички услуги и създаването на отделен акаунт дори за тест е мързеливо. Но в момента има огромен брой услуги, на които хората се доверяват със своите идентификационни данни и много повече. И ние се стремим да станем едни от тях.
Имаше много коментари, че сме го откраднали някъде. Това малко ни изненада. Е, добре, мнението на един човек, но такива коментари бяха намерени в различни публикации от различни хора. Първоначално те не знаеха как да реагират на това. Или да са тъжни, че някои хора смятат, че в Русия никой нищо не може да направи сам, а могат само да крадат, или да се радват, че смятат, че това може само да се краде.
Вече приключихме процедурата за получаване на сертификат за EV Code Sign. За да го получите, трябва да преминете през редица проверки и да изпратите куп документи за фирмата, част от които задължително заверени от адвокат. Получаването на сертификат за EV Code Sign по време на пандемия е отделна тема за статия. Процедурата отне месец. И не беше месец чакане, а непрекъснати искания за допълнителни документи. Може би пандемията няма нищо общо с това и процедурата отне толкова време за всички? Дял.
Някои казват, че няма да го използваме, защото няма сертификат на FSTEC. Трябва да обясним, че не можем да го получим и няма да го получим, защото за да получим този сертификат, криптирането трябва да е в съответствие с GOST и планираме да разпространяваме софтуера не само в Русия и да използваме AES.
Всички тези коментари хвърлят известно съмнение, че е възможно да се популяризира продукт, който изисква да въведете акаунти, без да е публично известен. Въпреки че знаехме, че ще има хора, които са много негативно настроени към това. След като броят на регистрациите надхвърли хиляда, спряхме да мислим за това. Особено след като в допълнение към негативизма на тези, които дори не са опитали продукта, започнаха да се появяват много приятни отзиви. Трябва да се каже, че тези положителни отзиви са най-големият мотиватор за развитие на продукта.
Добавяне на функционалност за отдалечен достъп за служители
Една от честите задачи на клиентите е „дайте на Ваня достъп до компютъра му от вкъщи“. Вдигнахме VPN на Mikrotik и създадохме акаунти за потребителите. Но това е истински проблем. Потребителите не могат да гледат инструкциите и да ги следват стъпка по стъпка, за да се свържат чрез VPN. Различни версии на Windows. В един Windows всичко се свързва добре, в друг трябва друг протокол. И като цяло това винаги е било свързано с преконфигуриране на мрежово оборудване, което е действало като VPN сървър и не всички служители имат достъп до него и това е неудобно.
Но вече имаме отдалечени връзки към сървъри и мрежово оборудване. Защо не използвате готов транспорт и не направите отделна малка помощна програма, която можете просто да дадете на потребителя да се свърже. Просто исках да се уверя, че потребителят не е въвел нещо неясно там. Само един бутон „свързване“. Но как тази помощна програма ще разбере къде да се свърже, ако има само един бутон? Имаше идея да изградим необходимото приложение онлайн на нашите сървъри. Системният администратор щраква върху бутона „пряк път за изтегляне“ и към нашия облак се изпраща команда за изграждане на индивидуален двоичен файл с твърдо свързана информация за свързване към желания сървър/компютър чрез RDP. Като цяло това може да се направи. Но това отнема много време; администраторът ще трябва първо да изчака, докато двоичният файл бъде компилиран и след това да бъде изтеглен. Разбира се, би било възможно просто да добавите втори файл с конфигурацията, но това вече са 2 файла и за по-лесно потребителят се нуждае от един. Един файл, един бутон и никакви инсталатори. След като прочетох малко в Google, стигнах до извода, че ако добавите някаква информация в края на компилирания „.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 на клиента да пренесе всички данни към новата СУБД и да изтрие старата. Освен това транзакциите в SQLite не работеха и това беше истински проблем. Но след като прочетох необятността на World Wide Web, открих без никакви проблеми, че транзакциите в SQLite могат да бъдат разрешени чрез подаване на проста команда при свързване
PRAGMA journal_mode=WAL;В резултат на това задачата беше изпълнена и сега сървърната част на клиента работи на SQLite. Не забелязахме промени в работата на системата.
Ново бюро за помощ
Беше необходимо пренасяне на системата HelpDesk от вътрешната версия към SaaS версията, но с някои промени. Първото нещо, което исках да направя, беше интеграция с домейна на клиента по отношение на прозрачно потребителско разрешение в системата. Сега, за да влезе в HelpDesk и да остави заявка в системата, потребителят просто кликва върху прекия път на работния плот и браузърът се отваря. Потребителят не въвежда никакви идентификационни данни. Модулът за Apache SSPI, който е част от Veliam Server, автоматично оторизира потребителя под домейн акаунт. За да оставите заявка в системата, когато потребителят е извън корпоративната мрежа, той натиска бутон и получава линк в имейла си, чрез който влиза в системата HelpDesk без пароли. Ако потребител е деактивиран или изтрит в домейн, акаунтът на HelpDesk също ще спре да работи. По този начин не е необходимо системният администратор да следи акаунтите както в домейна, така и в HelpDesk. Служител напуска - той прекъсва акаунта си в домейна и това е, той няма да влезе в системата нито от корпоративната мрежа, нито чрез връзка. За да работи тази интеграция, системният администратор трябва да създаде един GPO, който и .
Второто нещо, което смятаме за изключително необходимо за HelpDesk системите, поне за нас самите, е свързването с кандидата директно от приложението с едно кликване. Освен това връзките трябва да преминат, ако системният администратор е в друга мрежа. За аутсорсинг това е задължително, за системните администратори на пълен работен ден също често е много необходимо. Вече има няколко продукта, които вършат отлична работа при отдалечени връзки. И ние решихме да направим интеграции за тях. Вече сме интегрирали за VNC и в бъдеще планираме да добавим Radmin и TeamViewer. Използвайки нашия мрежов транспорт за отдалечени инфраструктурни връзки, ние накарахме VNC да се свърже с отдалечени работни станции зад NAT. Същото ще се случи и с Radmin. Сега, за да се свържете с потребител, трябва само да щракнете върху бутона „свързване с кандидат“ в самото приложение. VNC клиентът се отваря и се свързва с кандидата, независимо дали сте в същата мрежа или седите вкъщи в чехли. Първо, системният администратор, използвайки GPO, трябва да инсталира VNC сървър на работните станции на всички.
Сега ние самите преминаваме към новия HelpDesk и използваме интеграция с домейна и VNC. Това е много удобно за нас. Сега можем да избегнем плащането за TeamViewer, който използваме повече от три години, за да поддържаме нашата услуга за поддръжка.
Какво планираме да правим след това?
Когато пуснахме продукта, не направихме никакви платени тарифи, а просто ограничихме безплатната тарифа до 50 обекта за наблюдение. Пет дузини мрежови устройства и сървъри трябва да са достатъчни за всички, помислихме си. И тогава започнаха да идват искания за увеличаване на лимита. Да кажем, че бяхме малко шокирани, означава да не кажем нищо. Наистина ли компаниите, които имат толкова много сървъри, се интересуват от нашия софтуер? Разширихме лимита безплатно за тези, които направиха такива заявки. В отговор на молбата им попитахме някои защо им трябват толкова много, наистина ли имат толкова голям брой сървъри и мрежово оборудване. И се оказа, че системните администратори започнаха да използват системата по начини, които изобщо не бяхме планирали. Всичко се оказа просто - нашият софтуер започна да наблюдава не само сървъри, но и работни станции. Следователно има много искания за разширяване на лимитите. Сега вече въведохме платени тарифи и лимитите могат да се разширяват независимо.
Сървърите почти винаги работят или със системи за съхранение, или с локални дискове в RAID масив. И първоначално направихме продукта за тях. И SMART мониторингът не беше интересен за тази задача. Но имайки предвид факта, че хората са адаптирали софтуер за мониторинг на работни станции, се появиха заявки за внедряване на SMART мониторинг. Скоро ще го приложим.
С появата на Veliam Connector стана ненужно да се разполага VPN сървър в корпоративната мрежа или да се прави RDGW, или просто да се препращат портове към необходимите машини за свързване чрез RDP. Много хора използват нашата система само за тези отдалечени връзки. Veliam Connector е наличен само за Windows и някои фирмени потребители се свързват от домашни лаптопи, работещи с MacOS, към работни станции или терминали в корпоративната мрежа. И се оказва, че системният администратор е принуден поради няколко потребители да се върне към въпроса за пренасочване или VPN. Затова сега завършваме създаването на версия на Veliam Connector за MacOS. Потребителите на любимата си технология на Apple също ще имат възможност да се свържат с корпоративната инфраструктура с едно кликване.
Наистина ми харесва фактът, че имайки голям брой системни потребители, не е нужно да си блъскате мозъка за това от какво се нуждаят хората и какво ще бъде по-удобно. Те сами пишат своите желания, така че има много планове за развитие в близко бъдеще.
Успоредно с това сега планираме да започнем да превеждаме системата на английски и да я разпространяваме в чужбина. Все още не знаем как ще разпространяваме продукта извън нашата страна, търсим варианти. Може би по-късно ще има отделна статия за това. Може би някой, който е прочел тази статия, ще може да предложи необходимия вектор или самият той знае и знае как да го направи и ще предложи услугите си. Ще оценим вашата помощ.
Източник: www.habr.com