V , vyprávěl jsem o historii vzniku Veliamu a o rozhodnutí jeho distribuce prostřednictvím systému SaaS. V tomto článku se podělím o to, co bylo třeba udělat, aby se produkt stal veřejným, nikoli lokálním. O tom, jak jsme začali s distribucí a s jakými problémy jsme se setkali.
Plánování
Současná serverová část pro uživatele byla na Linuxu. V téměř každé organizaci jsou Windows servery, což nelze říci o Linuxu. Hlavní silnou stránkou Veliam je vzdálené připojení k serverům a síťovým zařízením za NAT. Ale tahle funkce byla velmi silně vázána na to, že routerem musel být nutně Mikrotik. A to by mnohé evidentně neuspokojovalo. Nejprve jsem začal přemýšlet o přidání podpory pro routery od nejběžnějších výrobců. Ale chápal jsem, že je to nekonečný závod s rozšiřováním seznamu podporovaných značek. Navíc i ty, které jsou již podporovány, mohou mít od modelu k modelu různý soubor příkazů pro změnu pravidel NAT. Jediným východiskem ze situace se jevilo VPN.
Když jsme se rozhodli produkt distribuovat, avšak nikoli jako open source, nebylo možné zahrnout do něj různé knihovny s otevřenými licencemi typu GPL. To je vůbec jiné téma; po rozhodnutí o prodeji produktu bylo nutné přezkoumat polovinu knihoven, protože byly pod GPL. Když jsme to psali pro sebe, bylo to v pořádku. Ale pro distribuci to nevyhovovalo. První VPN, které mě napadne, je OpenVPN. Ale to je GPL. Ještě byla možnost použít japonský SoftEther VPN. Jeho licence umožňovala zahrnout ho do našeho produktu. Po pár dnech různých testů, jak ho integrovat tak, aby uživatel vůbec nic nemusel nastavovat a znát o SoftEther VPN, vznikl prototyp. Všechno fungovalo jak mělo. Ale z nějakého důvodu nás tento systém přesto znervózňoval a nakonec jsme od něj ustoupili. Samozřejmě jsme však odstoupili až poté, co jsme vymysleli jinou variantu. Nakonec jsme všechno udělali na běžných TCP připojeních. Část připojení funguje přes koordinátor, část přímo pomocí technologie Nat Hole Punching (NHP), která byla také implementována ve Free Pascal. Musím říct, že o NHP jsem předtím vůbec neslyšel. A ani mě nenapadlo, že je možné spojit 2 síťová zařízení, která obě za NAT stojí, přímo. Prostudoval jsem téma, pochopil princip fungování a pustil se do psaní. Plánované bylo uskutečněno, uživatel se připojuje jedním kliknutím k požadovanému zařízení za NAT přes RDP, SSH nebo Winbox bez zadávání hesel a nastavování VPN. A většina těchto připojení obchází našeho koordinátora, což má dobrý vliv na ping a náklady na údržbu těchto připojení.
Převod serverové části z Linuxu na Windows
Problémů při přechodu na Windows bylo hned několik. První — vestavěný wmic ve Windows neumožňuje provádět WQL dotazy. A v našem systému už bylo vše postaveno na nich. A bylo ještě něco, ale teď si nepamatuji, proč jsme nakonec ustoupili od jeho používání. Možná rozdíly mezi verzemi Windows. Druhý problém — vícest threading. Nenašel jsem dobrou externí utilitu s "přijatelnou" licencí, takže jsem znovu spustil IDE Lazarus. A napsal jsem potřebnou utilitu. Na vstupu se zadá potřebný seznam objektů a jaké konkrétní dotazy je třeba provádět, a na výstupu dostávám data. A to vše v mnohovláknovém režimu. Skvěle.
Po nastavení pthreads pro PHP na Windows jsem si myslel, že všechno poběží, ale bylo to jinak. Po nějakém čase ladění jsem pochopil, že pthreads sice funguje, ale konkrétně v našem systému nepracoval. Ukázalo se, že s pthreads v systému Windows je nějaká zvláštnost. A skutečně to tak bylo. Přečetl jsem dokumentaci, kde bylo uvedeno, že pro Windows je počet vláken omezen, přičemž, pokud si dobře pamatuji, implicitně. To se stalo problémem. Protože když jsem začal snižovat počet vláken, při kterých aplikace fungovala, její provoz byl velmi pomalý. Znovu jsem otevřel IDE a do té samé utility byla přidána funkce pro vícenásobné pingování objektů. No a nakonec i skenování portů. Po této změně potřeba pthreads pro PHP zmizela a už se nepoužívá. Do této utility bylo přidáno ještě několik funkcí a funguje dodnes. Poté byl vytvořen instalátor pro Windows, který zahrnoval Apache, PHP, MariaDB, samotnou PHP aplikaci a sadu utilit pro interakci se systémem napsaných ve Free Pascal. Co se týče instalátoru, myslel jsem si, že tento problém rychle vyřeším, protože je to běžný a potřebný prvek téměř pro každý software. Ať už jsem hledal špatně, nebo z jiného důvodu, stále jsem narazil na produkty, které byly buď nedostatečně flexibilní, nebo příliš drahé a zároveň také nepružné. A přece jsem našel bezplatný instalátor, ve kterém lze předpokládat jakékoli požadavky. To je InnoSetup. Píšu o tom zde, protože jsem musel chvíli hledat, snad tím někomu ušetřím čas.
Odmítnutí pluginu ve prospěch vlastního klienta
Dříve jsem psal, že klientskou částí byl prohlížeč s "pluginem". Byly doby, kdy se Chrome aktualizoval a rozvržení se trochu rozcházelo, nebo když se aktualizoval Windows a custom uri schéma se ztrácela. Opravdu jsem nechtěl mít takové překvapení v veřejné verzi produktu. Navíc, custom uri začala mizet po každé aktualizaci Windows. Microsoft jednoduše odstraňoval všechny její větve v potřebné sekci. Také Google Chrome nyní nedovoluje zapamatovat si výběr, zda otevřít aplikaci z custom uri, a klade tuto otázku při každém kliknutí na objekt sledování. A celkově bylo nutné mít normální interakci s místním systémem uživatele, což prohlížeč nenabízí. Nejjednodušší variantou v tomto schématu se zdá být prostě vytvořit svůj prohlížeč, jak nyní dělá mnoho lidí pomocí Electronu. Ale už bylo napsáno mnoho věcí ve Free Pascalu, včetně serverové části, proto jsme se rozhodli udělat klienta ve stejném jazyce, abychom nevytvářeli zoo. Tak byl napsán klient s Chromium na palubě. Poté začal získávat různé obvazové vrstvy.
Uvolnění
Nakonec jsme vybrali název pro systém. Po celou dobu transformace lokální verze na SaaS jsme neustále zvažovali různé možnosti. Protože jsme původně plánovali vstoupit nejen na domácí trh, hlavním kritériem pro výběr názvu byla dostupnost nezaplacené nebo levné domény v zóně “.com”. Některé funkce/modules ještě nebyly portovány z lokální verze do Veliamu, ale rozhodli jsme se, že vydáme produkt s aktuálními funkcemi a zbytek doladíme jako aktualizace. V první verzi chyběl HelpDesk, Veliam Connector, nebylo možné měnit prahy pro spouštění upozornění a mnoho dalšího. Zakoupili jsme Code Sign Certificate, podepsali klientskou a serverovou část. Napsali jsme webové stránky pro produkt, zahájili postup registrace softwaru, ochranné známky atd. Celkově jsme připraveni začít. Malá euforie z odvedené práce a toho, že může být někdo, kdo bude používat váš produkt, i když o tom jsme neměli pochybnosti. A pak stop. Partner řekl, že bez upozornění do messengerů nemůžeme vstoupit na trh. Bez mnoha jiných věcí to jde, ale bez toho ne. Po krátkých sporech byla přidána integrace s Telegramem, což nám vyhovovalo. Z všech současných messengerů je to jediný, který nabízí přístup k API zdarma a bez složitých schvalovacích procedur. WhatsApp nabízí kontaktovat poskytovatele, kteří si účtují nemalé peníze za používání jejich služeb, všechny žádosti o poskytnutí přístupu bez zprostředkovatelů byly ignorovány. No a Viber… Nevím, kdo ho teď používá, protože spam a reklama tam překračují míru. Na konci prosince, po sérii interních testování a testování mezi přáteli, jsme otevřeli registraci pro všechny a umístili software k dispozici ke stažení.
Začátek šíření
Od samého začátku jsme věděli, že potřebujeme malý tok uživatelů systému, aby produkt již v provozním režimu otestovali a dali nějakou prvotní zpětnou vazbu. Několik zakoupených příspěvků na VK přineslo výsledky. Přišly první registrace.
Je třeba říci, že je velmi obtížné vstoupit na trh, když vaše společnost nemá slavné jméno, a současně poskytovat funkci bezagentního monitorování, do které je potřeba zadávat účty ze svých serverů a pracovních stanic. Mnoho lidí to odrazuje. Od začátku jsme chápali, že s tím budou problémy, a byli jsme na to připraveni jak technicky, tak morálně. Všechna vzdálená připojení, i když jsou RDP a SSH standardně šifrována, jsou navíc šifrována naším softwarem podle standardu AES. Všechna data z lokálních serverů jsou přenášena do cloudu pomocí HTTPS. Účty jsou uchovávány v zašifrované podobě. Klíče šifrování pro všechny podsystémy mají všichni klienti individuální. Pro vzdálená připojení se používají sezení šifrovací klíče.
Vše, co můžeme v této situaci udělat, aby se lidé cítili klidněji, je být co nejvíce otevření, pracovat na bezpečnosti a neúnavně odpovídat lidem na jejich znepokojivé otázky.
Pro mnohé převažuje pohodlí a funkčnost softwaru nad strachem, a tak se registrují. Někteří jedinci v publikovaných příspěvcích na VK psali, že tento software nelze používat, protože sbírá jejich hesla a jde o naprosto neznámou společnost. Je třeba říci, že tento názor neměl jen jeden člověk. Mnozí prostě nechápou, že když si na server instalují jiný proprietární software, který funguje jako služba, má stejná práva v systému a nepotřebují účty, aby mohli dělat něco nezákonného (je jasné, že je možné změnit uživatele, pod kterým služba běží, ale zde je to stejné, můžete zadat jakýkoliv účet). Ve skutečnosti jsou obavy lidí pochopitelné. Instalace softwaru na server je běžná záležitost, ale zadání účtu je už trochu děsivé a intimní, protože polovina lidí má jedno heslo pro všechny služby a být líní vytvořit si samostatný účet i pro testování. Nicméně v současné době existuje obrovské množství služeb, kterým lidé důvěřují se svými přihlašovacími údaji a nejen s těmi. A my se snažíme stát jednou z nich.
Mnoho komentářů bylo takového rázu, že jsme to někde ukradli. To nás trochu překvapilo. Dobře, názor jednoho člověka, ale takové komentáře se objevovaly v různých publikacích od různých lidí. Nevěděli jsme zpočátku, jak na to reagovat. Měli bychom smutnit nad tím, že někteří lidé mají názor, že v Rusku nikdo nic sám neudělá a může jen krást, nebo se radovat, že si myslí, že takové věci lze pouze ukrást.
Nyní jsme dokončili proceduru získání certifikátu EV Code Sign. Pro jeho získání je nutné projít řadou kontrol a poslat spoustu dokumentů o společnosti, z nichž části musí být ověřeny právníkem. Získání certifikátu EV Code Sign za podmínek pandemie je vůbec samostatné téma pro článek. Procedura se protáhla na měsíc. A to byl měsíc nikoli čekání, ale neustálých žádostí o dodatečné dokumenty. Možná pandemie za to nemůže a u všech byla procedura tak dlouhá? Podělte se.
Někteří říkají, že nebudeme používat, protože nemáme certifikát FSTEK. Musíme vysvětlit, že ho nemůžeme získat a nebudeme, protože pro jeho získání musí být šifrování podle GOST, a my plánujeme distribuci softwaru nejen v Rusku a používáme AES.
Všechny tyto komentáře vyvolávaly určitou nejistotu, zda je možné propagovat produkt, do kterého je třeba zadávat účty, aniž bychom byli přitom na veřejnosti. I s ohledem na to, že jsme věděli, že budou ti, kdo se k tomu postaví velmi negativně. Poté, co počet registrací překročil tisíc, jsme na to přestali myslet. Zvlášť po tom, co kromě negativity těch, kdo to ani nezkusili, se začaly objevovat i velmi příjemné recenze. Musím říct, že tyto pozitivní recenze jsou největším motivátorem pro rozvoj produktu.
Přidání funkce vzdáleného přístupu pro zaměstnance
Jedním z častých požadavků od klientů je: "Umožněte Vaňovi přístup k jeho počítači z domova." Vytvářeli jsme VPN na MikroTiku a nastavovali účty pro uživatele. Ale to je skutečný problém. Uživatelé nejsou schopní sledovat návod a vykonávat ho krok za krokem, aby se připojili přes VPN. Různé verze Windows. Na jedné verzi Windows se vše připojuje bez problémů, na jiné je potřeba jiný protokol. A obecně to vždy souviselo s přenastavením síťového zařízení, které fungovalo jako VPN server, a ne všichni zaměstnanci mají k němu přístup, což je nepohodlné.
Máme již vzdálené připojení k serverům a síťovému vybavení. Proč tedy nevyužít hotového transportu a nevytvořit malou utilitu, kterou bychom mohli jednoduše poskytnout uživateli pro připojení? Chtělo by to udělat tak, aby uživatel nic složitého nezadával. Jen jedno tlačítko 'připojit se'. Ale jak bude tato utilita vědět, kam se připojit, když má jen jedno tlačítko? Byla myšlenka na online sestavení potřebné aplikace na našich serverech. Systémový administrátor stiskne tlačítko 'stáhnout zástupce' a k nám do cloudu se podá příkaz na sestavení individuálního binárního souboru s zabudovanou informací o připojení k požadovanému serveru / počítači přes RDP. Celkově to bylo možné udělat. Ale trvalo by to dlouho, administrátor by musel čekat, až se binárník zkompiluje a poté stáhne. Mohli bychom samozřejmě přidat druhý soubor s konfigurací, ale to by už byly 2 soubory a pro jednoduchost uživatele je potřeba jeden. Jeden soubor, jedno tlačítko a žádné instalátory. Po přečtení několika informací na Googlu jsem dospěl k závěru, že pokud na konec zkompilovaného '.exe' přidáme nějaké informace, tak se neporuší (no skoro). Můžete tam přidat třeba Válku a mír a bude fungovat stejně jako dřív. Nemůžeme toho nevyužít. Nyní můžeme přímo v klientovi na místě rozbalovat aplikaci, která se mimochodem nazývá Veliam Connector, a jednoduše k ní na konci přidávat potřebné informace pro připojení. A samo o sobě ví, co s tím dělat. Proč jsem výše v závorkách napsal 'no skoro'? Protože za toto pohodlí musíme zaplatit tím, že aplikace ztrácí svůj podpis kvalifikovaného certifikátu. Ale v tomto stádiu považujeme, že to je malá cena za takové pohodlí.
Licencování třetích stran modulů
Již jsem psal, že poté, co bylo rozhodnuto učinit produkt veřejně dostupným, a ne jen pro vlastní použití, bylo nutné usilovně pracovat a hledat náhrady za určité moduly, které nebyly schopny být součástí našeho produktu. Ale po vydání jsme náhodou objevili velmi nepříjemnou věc. V rámci Veliam Serveru, který byl na straně klienta, byla databáze MariaDB. A ta má licenci GPL. Licence GPL předpokládá, že software musí být s otevřeným zdrojovým kódem, a pokud je v našem produktu zahrnuta MariaDB, která tuto licenci má, musí být i náš produkt pod touto licencí. Naštěstí je účelem této licence otevřený zdrojový kód, nikoli trestání soudem těch, kteří udělali chybu. Pokud se držitel práv ozve s nárokem, musí písemně informovat porušitele a ten musí během 30 dnů porušení odstranit. Naši chybu jsme objevili sami a nedostali jsme žádné dopisy, proto jsme se ihned začali zabývat možnostmi, jak problém vyřešit. Řešení se ukázalo jako zřejmé - přechod na SQLite. Tato databáze nemá žádná licenční omezení. Většina moderních prohlížečů používá SQLite a také spousta dalších programů. Na internetu jsem našel informace, že SQLite se považuje za nejrozšířenější databázový systém na světě, právě díky prohlížečům, ale nehledal jsem důkazy, takže to je nepřesná informace. Začal jsem zkoumat, co obnáší přechod na SQLite.
Stává se to již netriviální úkol, když je u klientů nainstalováno několik stovek serverů s MariaDB a daty v ní. Některé funkce MariaDB nejsou dostupné v SQLite. Například v kódu jsme používali dotazy typu
Select * FROM `table` WHERE `id`>1000 FOR UPDATE
Tato konstrukce nejen vybírá z tabulky, ale také blokuje dané řádky. A také bylo nutné přepsat několik dalších konstrukcí. Kromě toho, že bylo nutné přepsat mnoho dotazů, bylo potřeba vymyslet mechanismus, který při aktualizaci Veliam Serveru u klienta převede všechna data do nové databáze a odstraní tu starou. Také nefungovaly transakce v SQLite a to byla skutečná problém. Ale po prostudování internetu jsem bez problémů zjistil, že transakce v SQLite lze zapnout jednoduchým příkazem při připojení.
PRAGMA journal_mode=WAL;Nakonec byla úloha splněna a nyní serverová část klientů běží na SQLite. Žádné změny ve fungování systému jsme si nevšimli.
Nový HelpDesk
Bylo nutné portovat systém HelpDesk z interní verze na verzi SaaS, ale s určitými změnami. První krok, který jsme chtěli provést, byla integrace s doménou klienta pro zajištění průhledné autorizace uživatelů v systému. Nyní, aby se uživatel přihlásil do HelpDesku a mohl podat žádost, stačí, když klikne na zástupce na pracovní ploše a otevře se mu prohlížeč. Uživatel nemusí zadávat žádné přihlašovací údaje. Modul pro Apache SSPI, který je součástí Veliam Server, automaticky autorizuje uživatele použitím doménového účtu. Aby mohl uživatel podat žádost zevně mimo firemní síť, klikne na tlačítko a na jeho e-mail přijde odkaz, pomocí kterého se bez hesel přihlásí do systému HelpDesk. Pokud bude uživatel v doméně deaktivován nebo odstraněn, jeho účet v HelpDesku přestane také fungovat. Tímto způsobem není pro systémového administrátora nutné sledovat účty jak v doméně, tak v HelpDesku. Když zaměstnanec odchází, deaktivuje účet v doméně a tím to končí; nemůže se přihlásit ani z firemní sítě, ani pomocí odkazu. Pro zajištění této integrace je nutné, aby systémový administrátor vytvořil jedno GPO, které a .
Druhá věc, kterou považujeme za naprosto nezbytnou pro systémy HelpDesk, alespoň pro nás – je připojení k žadateli přímo z žádosti jedním kliknutím. Navíc by se měla připojení provádět, i když je systémový administrátor v jiné síti. Pro outsourcing je to nutné, pro stálé systémové administrátory to také často velmi potřebné. Již existuje několik produktů, které skvěle zvládají úkol vzdálených připojení. A rozhodli jsme se pro ně vytvořit integrace. Momentálně jsme vytvořili integraci pro VNC, a v budoucnu plánujeme přidat Radmin a TeamViewer. S využitím našeho síťového transportu pro vzdálená připojení k infrastruktuře jsme zajistili, že se VNC připojuje k vzdáleným pracovním stanicím za NAT. Totéž bude platit pro Radmin. Nyní, abyste se mohli připojit k uživateli, stačí v samotné žádosti stisknout tlačítko „připojit se k žadateli“. Otevře se klient VNC a připojí se k žadateli bez ohledu na to, zda jste v jedné síti, nebo sedíte doma v pantoflích. Předem by měl systémový administrátor prostřednictvím GPO nainstalovat všem pracovní stanice VNC Server.
Nyní sami přecházíme na nový HelpDesk a využíváme integraci s doménou a VNC. To je pro nás velmi pohodlné. Teď nemusíme platit za TeamViewer, který jsme používali více než tři roky pro naši podporu.
Co plánujeme dělat dál
Když jsme uvedli produkt na trh, neudělali jsme žádné placené tarify, ale jednoduše jsme omezili bezplatný tarif na 50 monitorovaných objektů. Padesát síťových zařízení a serverů by mělo stačit každému, pomysleli jsme si. A pak začaly přicházet žádosti o zvýšení limitu. Říct, že jsme byli trochu v šoku, je slabé slovo. Opravdu se naším softwarem zajímají společnosti, které mají tolik serverů? Bezplatně jsme zvyšovali limit pro ty, kteří takové žádosti podávali. U některých jsme se ptali, proč potřebují tolik, jestli mají skutečně tak velké množství serverů a síťového vybavení. A ukázalo se, že systémoví administrátoři začali používat systém způsobem, jakým jsme to vůbec neplánovali. Všechno bylo jednoduché — naši softwaru začali monitorovat nejen servery, ale i pracovní stanice. Odtud pramenilo mnoho žádostí o rozšíření limitů. Nyní už máme zavedené placené tarify a limity lze rozšířit samostatně.
Servery obvykle pracují buď s externími úložišti, nebo s místními disky v RAID poli. A původně jsme produkt vytvářeli pro ně. Monitoring SMART nebyl pro tuto úlohu zajímavý. Ale vzhledem k tomu, že lidé přizpůsobili software k monitorování pracovních stanic, objevily se žádosti o realizaci monitorování SMART. Brzy ho implementujeme.
S příchodem Veliam Connectoru už není nutné nasazení VPN serveru v podnikové síti, ani vytvářet RDGW, nebo pouze prohazovat porty k potřebným strojům pro připojení přes RDP. Velmi mnoho lidí používá náš systém pouze pro tato vzdálená připojení. Veliam Connector existuje pouze pro Windows, ale někteří uživatelé firem se připojují z domácích notebooků s MacOS k pracovním stanicím nebo terminálům v podnikové síti. A tak se systémový administrátor kvůli několika uživatelům opět dostává k otázce prohazování portů nebo VPN. Proto nyní dokončujeme verzi Veliam Connectoru pro MacOS. Uživatelé své oblíbené Apple techniky získají také možnost připojit se jedním kliknutím k podnikové infrastruktuře.
Oceňuji, že s velkým počtem uživatelů systému se nemusíme trápit tím, co lidé potřebují a co by bylo pohodlnější. Oni sami píší své požadavky, takže plánů na vývoj na nejbližší dobu máme opravdu hodně.
Současně plánujeme přeložit systém do angličtiny a jeho distribuci do zahraničí. Zatím nevíme, jak budeme produkt šířit mimo naši zemi, hledáme možnosti. Možná o tom později napíšeme samostatný článek. Možná nás někdo, kdo si přečetl tento článek, dokáže nasměrovat správným směrem, nebo to zná a umí udělat a nabídne své služby. Budeme vděční za pomoc.
Zdroj: habr.com
