VM - průběžné komentáře při testu #287
Labels
No Label
app-basic
app-ckan
app-crisiscleanup
app-cts
app-decidim
app-dhis2
app-frontlinesms
app-gnuhealth
app-kanboard
app-mifosx
app-motech
app-odoo
app-opendatakit
app-pandora
app-sahana
app-seeddms
app-sigmah
app-taarifa
app-ushahidi
critical
CZ
documentation
Doing
enhancement
GMaps
info
Mapbox
needinfo
new-app
OSM
performance
QGIS
regression
suggestion
To Do
upstream
No Milestone
No project
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: Spotter-Cluster/Spotter-VM#287
Loading…
Reference in New Issue
Block a user
No description provided.
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Poznámky k interface, nemusí být řešeno okamžitě
při bootování zmizet i tu větu o startu SpotterVM :)
pokud je vhodné dát najevo že bootuje, můžou být nějaké tečky. Dokud nezadá člověk heslo, bude to blackbox. Pasívní bezpečnostní opatření.
Zviditelnit verzování VM - na více místech v rozhraní
soudím že to může pomoci v orientaci při více stažených VM. Později se možná objeví i nějaké jiné informace vztažené k buildu. Zatím nevím.
uvažuji, že i název VM není tak trvale jistý... co když opustím své těžce placené domény spotter.. Pak bych to pojmenoval i jinak, to je putna.. Jen bych nerad aby s přejmenováním bylo zbytečně moc práce, kdyby to bylo zasocháno moc hluboko. (?)
V sekci aplikací se aplikace zviditelňují a spouští. Nyní je možné zviditelnit aplikaci, která není spuštěná, což lze chápat jako pro informaci. Ovšem kliknutím na aplikaci vznikne chybová strana. Raději bych to omezil tak, že nespuštěná aplikace nebude mít viditelný boxík. Tedy není na co kliknout.
Zároveň však stále bude možné, že spuštěná aplikace nemusí být v rozhraní vidět. O jejím skrytí rozhoduje Admin.
Killer funkce - k diskusi
co byste řekl na to, že admin by mohl z VM vymazat celý kontejner konkrétní aplikace, bez možnosti návratu?
Tj. rozhodl by se, že trvale nepotřebuje aplikaci XY, tak ji smaže. ostatní aplikace by to nepostihlo.
Kdyby ji náhodou chtěl později, jediná cesta by byla, že by musel stáhnout novou VM s kompletním SW.
Nemáte obavu že by vznikl nějaký vedlejší efekt s nefungováním něčeho?
V ostrém buildu:
prvotní heslo bude silné a neveřejné. Jediné místo kde toto první heslo bude, bude moje smlouva s konkrétní NGO.
Pasivní omezení šíření mimo cílové užití. - k diskusi
Co byste řekl na nějaký kryptovaný identifikátor uvnitř VM? Pokud si NGO rozjebe VM na mraky, je mi to jedno... Pokud by se VM dostala mimo neziskový sektor, a někdo by si na tom rozjel byznys, tak mi není jedno. Začnu se ptát té NGO, proč nedodrželi smlouvu v které bude jasné užití.
Další postřehy možná budou, zatím se tím nemusíte zabývat
Tečky už jsou moc pokročilé. Umím jen statický text. Buď tam může být, že "Startuji VM..." bez Spottera nebo teda vůbec nic.
V současnosti žádné verzování nemáme. Jedeme tzv. rolling release, takže jediný použitelný identifikátor by bylo číslo posledního commitu v gitu a datum. Soukromě si verzuji jen generace, které jsou ohraničeny nějakými technologicky důležitými milníky - opuštění Debianu, Dockerizace, přechod na HTTPS a tak. Můžeme si verzovat ty obrazy VM, co si budeme posílat, jestli to pro Vás má nějaký smysl. Až se přehoupneme do nějaké stabilní fáze, má smysl začít mluvit o nějakých replikovatelných a verzovatelných buildech.
Název VM je název produktu, ten přece není závislý na doméně. Můžeme tomu říkat SpotterVM i když to pojede na vocasek.net. V současnosti mi vyhledávání pro "spotter" vyplivne 156 výsledků v 71 souborech. Máme tak pojmenované ledacos. Template pro Sahanu, deploymenty pro Ushahidi, Pandoru a CTS, nějaké interní nástroje a tak. Spousta věcí se dá refaktorovat na nějaké neutrální a nicneříkající názvy, takže jestli to mám udělat, vydejte pokyn.
OK.
Jaký by k tomu byl důvod? Kdovíjak obrovské množství místa se tím neušetří. Největší kontejner má kolem 600 MB. Medián je někde u 200 MB.
Čistě teoreticky by to ale mohlo být komplet celé modulární. Uživatel by si tak stáhl jen VM s "podvozkem" a při prvotní instalaci by si vyklikal, které aplikace chce a k těm by se stáhly kontejnery a provedlo prvotní nastavení. Stahování kontejnerů je stejně plánovaný mechanismus pro upgrade, takže tohle by bylo jen rozšíření plánované funkcionality. Ale musí se říct dopředu, že to tak má fungovat, protože některé věci jsou teď nastaveny dost rigidně a očekávají přítomnost všech aplikací. No a taky to samozřejmě vyžaduje nějaký distribuční server, o kterém jsem mluvil v issue #1 u hostingu
Tak určitě. "password" bych k určení pro veřejnost nevypustil ani s pistolí u hlavy. Problém spíš je, že to heslo je součástí buildu, takže pokud byste chtěl pro každou organizaci jiné prvotní heslo, musel by se distribuovat image pro každou zvlášť. To by ale zase řešil ten systém dotahovací modulární stavebnice, protože pak by ten základní image byl srandovně malý (~400 MB).
Stejný problém jako u prvotního hesla. A stejné řešení.
Může být jen Start VM...
Verzování samože až později. Dokud testujeme, tak je mi to nanic, a vy si svůj vývoj ohlídáte. ale spíš později kvuli komunikaci s okolím.. Až mi bude chtít někdo něco sdělit že nefunguje, tak bude dobré vědět, k čemu se vyjadřuje.
Jasně že název není doména... jen to hlásim, nevadí mi když v kódu bude nějaké obecnější slovo. kdy to uděláte nechám na vás. Snad jedině template Sahana nechat, tam bude hodně práce. No, uvidíme.
ad mazání... asi jen slabý důvod k tomu šetření místem. Ta zcela modulární instalace a aktualizace by to fakt vyřešila elegantněji. Takže máte pravdu. Můžeme se vydat tím směrem.
jo, ještě ,... Až bude "skoro hotovo" (tj. za dlouho) tak bych se rád obrátil na některé vývojáře SW, např. F+D, a ukázal jim VM ať mi napíší dojem, zda jsem se upe zbláznil atd. Třeba mi řeknou něco důležitého, co se dá ještě pořešit. Vlastně stojím o to, aby VM brali jako přidanou hodnotu, která by zpětně pomohla i jednotlivým aplikacím. Tedy alespoň těm pár důležitým.
s heslem bych to viděl jako konkrétní organizace + distribuce + heslo. Pokud by se to stalo nějak nestíhatelné, tak pak jinak.
mentioned in commit
afa81c81cdmentioned in commit
cc20132a1fImplementováno v
afa81c81cd.Odbrandoval jsem hromadu věcí v
bf94306e25. Teď už se "spotter" vyskytuje jen u templatů nebo customizací deploymentů konkrétních aplikací a pak v názvu samotné VM. Vše je případně řešitelné jednouduchým vyhledáním a nahrazením řetězce.Implementováno v
cc20132a1f.Zítra mám v plánu se drbat na hlavě a vymýšlet ten modulární systém. Nějaké nástřely už v hlavě nosím od včerejška, takže to postupně zkusím dát nějak do kupy.
Taky jsem přemýšlel o té identifikaci buildů pro jednotlivé organizace a asi by stačilo jen nějaké pitomé náhodně generované UUID, které ta VM bude hlásit při komunikaci s naším distribučním serverem. Čistě teoreticky by ten identifikátor mohl být párovaný s nějakým heslem a použil by se pro autentizaci, takže nejen, že budete vědět která VM se připojila, ale budete ji schopen i odříznout od distribučního kanálu. Nicméně na straně serveru je pak nutno vést databázi organizací a jejich VM a zaznamenávat jednotlivé přístupy a akce. Takže budeme schopní je přiřadit ke konkrétní VM a nevím, co na to GDPR. Hádám, že to už ale máte ošéfované.
No a pak samozřejmě hrozí, že pokud milá NGO vydá třetí straně image i s heslem k disku, bude si třetí strana schopna VM rozebrat v izolovaném prostředí bez přístupu k internetu, takže se o nějakém úniku nikdy nedozvíme. Pak už bycom se museli bavit o nějakém primitivním DRM a kde je DRM, tam to smrdí.
super, díky... peníze jsem už poslal, takže zítra by FIO měla vykonat.
celé to téma buildování a identifikace... Přiznávám, že nemám úplně ujasněný proces jak konkrétně se dobrat k nějakému cíli, mam tu jen dané záchytné body, které vytyčují nějaký záměr... a to že se pohybujeme v open-source SW a musíme ctít principy, cílíme na NGO, necílíme na komerci a nechceme být onálepkováni jako Big Brother.
Čili vím, že tímto jsem to dost zkomplikoval a vůbec netlačím na pilu.. klidně budu o tom další půlrok přemýšlet, prosejvat internet a hledat nějakou radu, než se do něčeho pouštět.
DRM se mi taky nelíbí, takže DRM ne-e.
To, co dlouhodobě hledám je, aby se software ve VM v nějaké budoucí formě dostal k těm nejpovolanějším uživatelům a pokud možno zůstal "neveřejným" a pro komerční sféru nezajímavým, jako dosud je.
To by ostatně mělo být i v zájmu samotných NGO, pokud svou činnost pojmou tak, jak se od nich čeká. Takže v ideálním případě ty organizace ani nebudou chtít uniknout tento sw mimo svou bublinu, ... leda by to udělal nějaký jednotlivec.
Jsou tu ještě jiné skupiny potenciálních uživatelů, kteří mi nevadí... např, vysokoškolská projektová činnost, nebo teroreticky i místní samospráva... Nicméně zatím k nim nehledám žádný vztah ani plán.
Jiná věc je, že jednoduše použitelná VM by mohla začít zajímat subjekty vyloženě rizikové... A zde jsem taky v koncích, protože ani zde neznám způsob, jak se tomu vyhnout.
K GDPR...
Řekněme, že ve bude nějaký distribuční server, který může poskytnout build na základě smlouvy a požadavku... ten požadavek může být zcela anonymizovaný, např. hash čísla smlouvy. Potřebujem něco jiného?
Distribuovaný build nikdy nebude obsahovat osobní údaje. Nanejvýš může mít openData datasety na právnické organizace, nebo nějaká metadata.
Dále ohledně činnosti v SW: Odpovědnost za nakládání s osobními údaji nese konkrétní organizace, která si řeší své GDPR procesy. tj. jimi používaný software je používán podle jejich organizačních procesů. Většina SW to umožňuje.
Konrétně v Sahaně tam F+D tuším něco dodělávali, aby se dal smazat komplet celý uživatel... a přístup ke kontaktu právnických osob už neobsahuje pár "jméno osoby + telefon" ... to už je pouze v kontaktech osob, ke kterým musí být konkrétní přístupová role.
Pokud by někdo vznesl dotaz jak vyhovuje VM GDPR, tak řeknu, že má zabezpečený přístup, možnost diverzifikovat přístup k datům podle uživatelů a jejich rolí.
něco už jsem rozepsal ve wiki https://git.spotter.cz/Spotter-Cluster/Spotter-Cluster/wikis/GDPR
ještě to projde vývojem.
Po vás ve věci ošetření GDPR tedy zatím nic nepotřebuji, případně pouze naprosté formální minimum.
No to je právě to, co by mělo suplovat to UUID. Technicky a technologicky tam k deanonymizaci nedojde, ale Vy budete schopen zjistit, která VM, potažmo která organizace to byla, protože budete znát všechny vstupní parametry k oné anonymizační metodě. Proto si říkám, že možná bude lepší se na nějakou zabudovanou tajnou identifikaci vykašlat a postavit to na autentizaci. Tím si rozvážeme ruce k tomu, že budeme moci svobodně distribuovat kód u kter0ho všichni uvidí, že "nevolá domů" a jediný způsob připojení k distribučnímu serveru bude obyčejné jméno (nebo nějaké to číslo) a heslo, které admin pokaždé v rozhraní při manuální aktualizaci zadá. Tím pádem bude i možné, aby si někdo jiný, kdo používá náš opensource, stejným způsobem postavil svůj distribuční server se svými obrazy.
Ultimání cíl by byl VM úplně rozdělit na vzájemně neprovázené vrstvy, což je přesně to, o co se v následujících dnech hodlám pokoušet
Přičemž můžeme otevřít a distribuovat pouze podvozek a u poháněcí soustavy tvrdit, že to jsou dockerové kontejnery jako jakékoliv jiné, což je v drtivé většině pravda (bude k nim přibalen nějaký malý customizovaný instalační skript, aby si to celé hezky sedlo a bylo co nejminimalističtější).
Kontejnery pak budou schovány na našem distribučním serveru a kdo se chce stát součástí SpotterClusteru, upíše se
ďábluVám a dostane k němu klíčky. Kdo s Vámi nechce mít nic společného, postaví si vlastní distribuční server s blackjackem a děvkama, ale k Vašim těžce nasysleným datům se nedostane... tedy opět za předpokladu, že si nějaké NGO nepustí hubu na špacír a nevydá přístupové údaje třetí straně, protože takhle část vždycky stojí a padá na lidech.OK, to zní dobře.. :)
Poslat signál k vypnutí VM ve virtualboxu - neudělá nic. furt běží
mno, tak první přilogování jsem udělal, na forpsi jsem nastavil vnější IP na spotter.name vzhledem k nepovoleným portům je mi to sice nanic, ale budiž, pokračoval jsem dál.
nastavil jsem uživatelel a heslo pro přístup na distribuční server a pustil stahování dvou aplikací.
Dnes samozřejmě jako vždy můj domácí internet vykazuje výpadky a jiné zoufalosti, takže stahování apps začalo a pak možná vykyslo, možná že nevykyslo ale běželo strašně pomalu.
při reloadu strany jsem se dostal znovu ke straně, kde nebyla zjevná identifikace dovnloadu, zkusil jsem tedy kliknout na stažení stejných aplikací. Napsalo to že čeká ve frontě.
Potud se to stahování tedy v rámci vývojoví fáze chová očekávatelně.
Fajn, neděsil jsem se a zkusit tedy Resetovat VM.
to se stalo OK. Napsal jsem znovu heslo a spustil VM.
Nově si už pamatovalo že je přiřazena doména, viz obr.
zde ovšem trochu námitka, že v dané situaci bych stejně musel použít IP nikoliv doménu, takže asi vhodné by bylo, aby v této informační obrazovce byly zmíněny jak nastavená doména, tak IP adresa.
Druhý záser je v tom, že dál mě to pustí pouze na tuto stranu
https://192.168.1.103/login
kde je natvrdo napsán admin bez hesla.
Na admina jsem heslo nedostal, ani jsem další hesla v rozhraní neměnil.
aha, dostal, akorát jsem myslel že to je jiný admin. Ok.. pokračuju dál
Heslo do rozhraní je stejné jako pro šifrování disku, zmiňoval jsem to v mailu. Pak jde v rozhraní změnit. Uvažuji, že to prvotní přihlášení bez hesla zruším. Na rušných sítích to nemusí být úplně bezpečné.
Vybavuji si, že námitku pro zobrazení IP i v případě, že je již nastavena doména, jste měl již v minulosti. Pracuji s konceptem, že pokud má být VM použitá v nějakém reálném prostředí, admin bude nejspíš mít přístup i k routeru a bude schopen si IP zjistit nebo zapamatovat z předchozího přihlášení. Nicméně místo na ještě jednu URL se tam asi najde, takže OK, přidám.
jasný... díky. Pro situace, kterých se sám trochu bojim, je reálné prostředí i takové, kde nebude mít ihned přístup k routeru (třeba později ano)...
no, zatim to vypadá, že stahovat něco, je teď přes den tak trochu blbost... začne, ale pak je mrtvo. Nebo 504 Gateway Time-out
Zkusim znovu večer. Ještě musím zařídit asi 5 věcí a ne koukat na kolečko na monitoru :D
Prosím, jestli tam máte někde nějaké expirační časy na sessions nebo pingy nebo nevim, tak zkuste prodloužit, protože jinak nikdy nic nestáhnu.
To je stav který jsem ještě netestoval, nicméně vím, že ošetření chyb při ztrátě spojení mezi klientem a VM je potřeba dodělat. Co se týče spojení mezi VM a distribučním serverem, tam timeouty nejsou žádné. Ve chvíli, kdy se to spojení rozpadne, komponenta která ma starosti stahování vyhodí výjimku, která bude odchycena a zobrazena jako chybový stav. Ale možné, že se u Vás děje něco úplně jiného.
Ta fronta funguje tak, že stav úkolů je zjišťován pouze tou stránkou, ze které byly zadány. Pokud refreshnete nebo přejdete jinam a zase zpátky, budou pořád ve frontě, ale už se u nich nebude zjišťovat stav. Dalo by se udělat, aby ty stavy byly viditelné globálně, ale vyžaduje to, aby se obnovoval stav celé tabulky, bez ohledu na to, zda byla zadána nějaká akce (protože co kdyby ji tam zadal někdo jiný z jiné stránky) a to by v případě zpracování chyb mohlo být dost matoucí. Situace:
Asi by se tomu dalo předcházet tak, že se chybové hlášky budou moci potvrzovat. Takže až instalace selže, admin A odklikne, že ji viděl a globální stav té konkrétní aplikace se se pak vrátí na nominální hodnoty. Pak ale může dojít k situaci
Možnosti jak to řešit určitě jsou, takže jestli myslíte, že to má fungovat jinak, řekněte si. Já vybral tu nejpřímočařejší možnost u které jsem předpokládal, že se nejmíň nadřu (a i tak jsem se k ní dostal asi po třech nebo čtyřech iteracích). Stejně u toho řazení do fronty bude potřeba udělat nějaké změny kvůli tomu vypínání a restartování.
Huh? To by se dít nemělo. To by znamenalo, že webový server na VM nedostává včas odpovědi z toho aplikačního manažera běžícího hned vedle něj. Já si snad budu muset najít nějaký dial-up modem a nasimulovat si váš internet.
Nevím přesně co se u mého internetu celé ty roky děje, ale pokouším se jen odhadovat že výpadky na posledních 5ti metrech můžou být proto, že router v domě má pro připojení přes wifi jen limitovaný počet připojení a tak jakmile se v našem skvotu objeví/probudí/vyskytne další spolubydlící, co má v kapse telefon, tak se telefon začne připojovat a možná ohrozí stabilitu nebo zcela zasekne router a rychlost už tak mizerného signálu. Na posledních 100 metrech k nějakému většímu AP to můžou být i jiné osery, to už nezjistím i neovlivním. Proto je to tady tak v řiti.
K adminům A a B. Zde zřejmě jde o popis přístupů k distribučnímu serveru tak, jak to vidí ten server. Jinak nevím přesně jak by vzniklo víc adminů na jedné VM, pokud to tedy není tentýž s nově otevřeným browserem nebo takněco. Nepředstavuji si, že by na jednu VM vstupovali dva různí admini a ti na této VM spouštěli instalace různých apps. Pokud tedy DS reaguje aktivně na stav stahování v nějaké VM(A) ..VM(B) , asi musí mít ošetřenu vlastní frontu na tyto krizové stavy. Neumím poradit jak to udělat, jen vnímám že to nejde popřít.
Ještě k tomu, jak toužím rozvíjet toto řešení (a něco už jsem psal, tak to přetrpte)
Představuji si asi 2 stavy jak s VM pracovat:
adminovský prvotní download a setup, do nějž tedy patří i ty app-downloady a rekonfigurace. Tato situace může být i v nějak nestandardních podmínkách, které by admina na páteři normálně nenapadly. Řekněme, že když admin zvládne vše rozchodit, pak už potřeba tahat app bude minimální, nebo žádná. Samože updaty, zálohy.
aktivní používání VM jeho uživatelem(li) - a to jak v nějaké ustálené konfiguraci konektivity, tak opět možná i v nestandardních, krajně krizových a proměnlivých podmínkách konektivit.
Popíšu ty nestandardní podmínky, mezi které patří i to moje testovací domácí připojení. Jiné podobné podmínky pro 1) i 2) jsou a mohou v budoucnu být i jinde v terénu. Ať už v narychlo využité pevné síti, APčku, nebo na veřejném prostoru (hromadná doprava, AP na zastávkách MHD, hospody, coworkingy, nebo nezabezpečené wifi dementního souseda odvedle). A samože i vytvořením vlastní privátní sítě na vlastním HW. Když to bude fungovat tak to splní účel. V úterý jsem byl v coworkingu kde jsme dělali další mapathon pro MSF. Je to čím dál tím častější, kdy a) coworking machruje jak má dokonalý net, b) přijde 50+ lidí a rázem se z netu nedá vyloudit vůbec nic protože je přetížený c) přijde někdo s dalším APčkem a chvíli machruje... d) situace se opakuje, net je téměř nepoužitelný.
Jiný příklad, jak pozoruju hemžení kolem SW Crisis Cleanup, tak stačí jeden nadprůměrný hurikán a lidi z CC mají na 2 měsíce přetížená callcentra, online servery, všechno jede na hranici. Protože ty servisy jedou centrálně.
Asi to vypadá jak paranoia, ale nemám moc radosti ze slibů, jak všude bude dokonalá páteř s globálním internetem zdarma z internetových balonů Google, Amazonu, Microsoftu. Možná i bude, ale bude to nakonec znamenat větší kontrolovaný net než je teď. Placeno naší informační nesvobodou. Mam čerstvé historky kamaráda z cest po Číně, který i v Tibetu 4000 mnm v horách měl plný signál 4G net, ale musel si v PC a mobilu neustále aktualizovat 4 různé VPN klienty podle toho, jak jsou pravidelně vládou Číny blokovány a vzápětí ty blokace znovu obcházeny... Bez VPN by mohl zapomenout na většinu toho, co zná z českého internetu... nekoupil by si ani letenku. Pro číňáky to je navíc vylepšeno, že už tam jedou orwellovský model identity reputation. Vlhký sen globálně operujících ISP.
Takže celé toto je hledáním k nějak soběstačnému decentralizovanému konkrétnímu řešení, které musí respektovat technologie, ale zároveň vybírá tu cestu, která bude alespoň trochu odolná proti SHTF. S DS vzniklo issue "co se stane když je výpadek sítě kterou potřebujeme" což směřuje k mojí obecné odpovědi. "výpadek se stát může, pak tedy mít informaci o stavu, buď navázat na předchozí stav, nebo nekompromisně začít znovu".
Možná existují nějaké konkrétní vymyšlené distribuční technologie, které bychom mohli v budoucnu implementovat pro zlepšení odolnosti... ale teď na nich z časových a finančních důvodů netrvám.
Taky neumím odpovědět, čím ještě předcházet, aby se s teoretickým širším použitím více instancí VM nepřetížil DS... Typicky ve chvíli, kdy by to někdo moc potřeboval. (A proto by měl mít tu možnost si natahat do své lokální VM vše kdykoliv dřív a v klidu)
Vše potenciálně ne-bezpečné by asi neprošlo u bezpečnostního auditu.
Měl jsem na PC současné připojení ethernetového kabelu a wifi ze stejného routeru, což sice šlo, ale nikdy se tím moc nevylepšila stabilita. Tak jsem wifi odpojil a používám jen ethernetový kabel. toto je stav sítě při stahování CKAN 1%. Nic jiného nestahuji. A nelepší se to.
a tady jsem paralelně s tím otevřel okno YouTube kde hraje video s auto rozlišením 360p. Zjevně to tahá data.
teď se mi zdá, že u https://192.168.1.103/setup-apps po nějaké době "údajného stahování" strana zemře a už nejde reloadovat. Nejde ani nově načíst v jiném browseru. VM okno se nijak nevyjadřuje, pouze se tváří, že "běží".
Je to tentýž s nově otevřeným browserem, třeba i na jiném počítači. I to reloadnutí stránky je dost na to, aby se ztratila kontinuita. Takže dotaz spíš zní jestli aktuální stavy všech aplikací mají být vidět za všech okolností nebo jestli je to OK tak jako teď, kdy každý "pohled" vidí jen vlastní akce.
Mám sto chutí Vám vytvořit nový obraz, který se mi připojí na VPN server a já se na něj dostanu po SSH a vyčtu z logů co se mu nelíbí, protože z toho, jak popisuje Vaši kvalitní páteřní linku tam může být asi deset různých příčin. Nicméně i tak mě nenapadá žádná, při které by se to chovalo tak, jak popisujete. A to jsem si už vyzkoušel, i jak se VM chová na škrcené IPv6-only síti a i když je úplně bez internetu.
Tohle mi přijde trochu jako problém "vejce nebo slepice". Buďto se VM bude stahovat sakum prdum celá se všemi aplikacemi a pak ten obraz bude mít 10 a víc giga, nebo budeme mít DS, takže základní obraz bude mít 180 MB a aplikace si dotáhne každý takové, které potřebuje. Předpokládám, že ty NGO budou vědět, které aplikace budou potřeba pro jejich pole působnosti. A pokud ne, tak si pořád můžou stáhnout úplně všechny, takže skončí opět s 10+ GB. Pokud dojde k nějakému blackoutu, pak stahování z DS bude úplně stejně nemožné, jako by bylo stahování původního kompletního 10+ GB balíku. Nevím jak se tenhle problém dá řešit jinak, než tím, že na něj bude NGO/uživatel/kdokoliv dopředu připraven.
Pokud jde o to, že 10+ GB obraz VM se může stáhnout jednou a ve SHTF scénáři jej pak na flashce nafasují všichni zúčastnění, tak úplně to samé se dá udělat i s celou VM na kterou byly dodatečně dotaženy nějaké aplikace. Případně se dá ten distribuční server velice snadno rozjet lokálně na intranetu a jednou za čas synchronizovat balíky.
To tak jedině BitTorrent. Ten jste myslím v původním návrhu zmiňoval. A i ten potřebuje internet, protože se musí připojit k nějakému announce serveru nebo DHT routeru. Ono totiž P2P není tak úplně serverless. Loni jsem o tom psal článek - https://www.dasm.cz/clanek/torrent-a-tor-boj-s-vetrnymi-mlyny
DS je úplně obyčejné holý HTTP server. Ty jsou v současnosti stavěné na zvládání desítek tisíc současných spojení. My jsme limitování průtokem linky, takže řekněme že u nás bude ten zdravý strop tak někde u 100 současných downloadů balíků. Když to bude málo, dá se přikoupit nějaký fronting třeba u CloudFlare nebo jiných CDN, takže pak už nebude sebemenší problém, ani když Vaše řešení budou používat úplně všechny NGO na světě.
Vážně by mě zajímalo, jak a kdo si představujete, že ten audit bude dělat. Je to dost složité a nákladné u jediné aplikace, takže moc nevěřím tomu, že někdo bude ochotný udělat audit u pětadvaceti opensource produktů nad rámec nějakého "Ukládá to hesla v plaintextu? Ne. Tak je to dobrý."
1 % je výchozí hodnota. Jinými slovy, vypadá, že to stahování vůbec nezačalo. Už jsem v kódu (
dd5396ae4b) upravil, že se má začít hezky na nule, aby to nevzbuzovalo falešné naděje.Jakože ta aplikace úplně chcípne a je nutno otočit celou VM, aby zase přišla? Na to fakt budu nejspíš potřebovat nějaké logy. Vymyslím na Vás nějaký ten backdoor.
aha... ano, nevadí když každý pohled vidí jen to, co se děje ve vlastním browseru. Kdyby to později začlo někomu vadit, tak to holt vylepšíte.
ok, udělejme to třeba tak. Nicméně od této neděle jsem 7 dní pracovně v Č. Krumlově, tj. zas jiná síť. Trochu se těším, že tam to půjde jinak než doma.
jo, připouštím. To, co jste vymyslel s DS mi přijde jako skvělý nápad, z kterého lze dál něco budovat. A zároveň se o tom nápadu dá srozumitelně komunikovat, což o pouhé hromadě různých open-source sw nejde. Takže bych ho určitě nezatracoval.
Klíčová věta je přesně tato: ... že na něj bude NGO/uživatel/kdokoliv dopředu připraven." Ano, vesměs všechny systémy od IT přes NGO až po GOV zabývající se SHTF jsou o předběžné přípravě. Státní správa hmotných rezerv ČR má vlastní softwary krizových operací, (taková Sahana deluxe) které distribuuje klíčovým státním složkám. Zároveň má na veřejném webu ke stažení nějaký XLS nebo CSV soubor, který obsahuje kritické informace (odhaduji kontakty a lokace ve vzájemném vztahu). Tento volně stažitelný soubor (asi aktualizovaný) může mít každý na svém lokálním HDD, ale nemá heslo. To heslo dostává od SSHR až v případě nějakého konkrétního red allertu. Distribuovat heslo je rychlejší, než distribuovat SW a data v situaci, kdy je webserver pod silnou zátěží.
Náš případ je trochu jiný, ale podobný v tom, že pro NGO by skutečně nejvhodnější metodou mělo být stažení dobře vybavené VM dostatečně včas předem. Zhruba tak několik let před tím, než jí použijí naostro. A do té doby by se na ní měli učit pracovat a ladit používání.
Až budou muset řešit neodkladné záležitosti, tak ať si klidně stáhnou update, nebo jen překonfigurují VM, něco smažou, něco přihrají. Tato operace by v ideálním případě neměla být tak zásadní, jako stahování celé VM pět minut po dvanácté.
Jasné, nic není úplně serverless, ani blockchain. Ta moje poznámka neměla vyznít jako požadavek po BT, ale spíš jestli není nějaká knihovna, nebo kus kódu pro client-server, který se zabývá přenosy dat, udržuje integritu a vyhovoval by pro tento případ (?) nevim.
plán je s https://www.dcit.cz a ano, bude to asi dost drahé. Na druhou stranu bych to viděl, že se to bude týkat pouze vašeho kódu, čili ne kódu všech FOSS aplikací. To by nešlo splnit nikdy. Než požádám o jejich konzultaci, je potřeba doladit tohle workflow.
ano, působí to na mě že to celé chcípne a už se prostě na tutéž ani na jinou stranu pod tou IP nedostanu. Zkusme nějaký průzkum podle vašich instrukcí, teoreticky by šlo udělat i vzdálený přístup.
V pátek a sobotu budu bohužel nekoncentrován, protože musím dohnat vše v Praze, na co nemám jindy čas.
Tyto operace se sítí tedy můžeme naplánovat na jindy, do té doby se dá věnovat jiným věcem...
:)
ani po restartu virtualboxu a celého PC se už nejde dostat při spuštěné VM na IP https://192.168.1.103
aha, takže VM ty IP nějak náhodně mění? To se neřeklo. teď https://192.168.1.102/
nyní to vypadá, že stahuje "rychle". tedy na mé poměry.
aplikace Kanboard se nainstalovala, lze ji v rozhraní administrace spustit, bohužel všechno to končí na tom, že v portálu má Kanboard odkaz doménu. Což pochopitelně v případě předchozího nenastavení domény nelze splnit.
VM ne. MAC adresa VM zůstává stejná. Za tohle nejspíš může Váš router.
No a tady právě přicházejí na řadu kouzla s lokálním překladem pomocí hosts souboru. Spusťte poznámkový blok s administrátorským oprávněním (Start menu -> Příslušenství -> pravý klik na Poznámkový blok -> Spustit jako správce) a v něm přes Soubor -> Otevřít otevřete soubor
C:\Windows\System32\drivers\etc\hostsa do něj nakonec dopišteKde IP je adresa VM a spotter.vm je ten doménový název, který jste zadal (pokud necháte výchozí spotter.vm, bude tímto způsobem fungovat i ten). Pak soubor uložte, restartujte prohlížeč a doménové názvy začnou fungovat.
Ve vašem případě bude potřeba upravit záznam při každé změně IP. Zobrazování obou URL (s doménou i s IP) na úvodní obrazovce VM jsem již implementoval v
7eaab3d6e2, takže až Vám během dneška nebo zítřka pošlu ten "diagnostický" build VM, už tam IP uvidíte za všech okolností.Přes noc jsem stáhl všechny balíčky, nainstalovalo se vše. Po změně hosts a restartu PC doména spotter.vm taky jde.
Na straně Portál tedy vidím aplikace, které mám vidět. Aplikace Kanboard a CTS mají nastavené Login: heslo, ostatní aplikace mají Login: N/A Heslo: N/A
Kanboard i CTS tedy jdou přihlásit.
pak jsem vložil Google API klíč, kolečko se točí, Provádí se změna nastavení, prosím čekejte...
vypadá to že se tento stav už nezmění. Dokud bych někde nezačal používat mapu tak asi nezjistím jestli OK nebo neOK.
Ještě k té předchozí otázce:
předtím jsem to pochopil a napsal tak, že sync stavů mezi dvěma rozdílnými session zatím nebudeme řešit.
Nicméně vidím, že se to týká i neaktualizace stavu v jednom okně browseru, když přejdu na jinou stránku administrace a vrátím se na stránku Nastavení aplikací, pak už nezjistím, co se aktuálně děje s aplikacemi. Což by zjevně zmátlo každého, kdo to nezná. Toto tedy asi do budoucna stejně budeme muset vyřešit.
Ohledně té úvodní obrazovky: Ok... šlo by tam dopsat CZ a AJ zmínku, že pokud nelze nastavit doménu, změňte směrování IP na doménu ve svém souboru hosts. Asi na úkor toho zeleného titulku, který by se mohl stát pouze textem.
A někde uvnitř administrace to tak shrnout jak jste to poslal, protože uživatel neví, dokud nevyzkoumá, jak jsou nastaveny jednotlivé domény aplikací.
Tohle by mělo být univerzálně i na jiné, i budoucí dosud neřešené kontejnery aplikací.
jinak bych chtěl říct, že celý ten instalační postup na mě působí velmi dobře a je v tom hodně neviditelné práce, s kterou bych byl jinak v koncích. Takže když budeme pokračovat tímto směrem a postupným vybavováním nějakými vlastnostmi prostředí, tak to hodně usnadní přípravu na spuštění aplikací. Díky!
Ha! kolečko Google Maps API klíč se konečně dotočilo a nastavilo. Takže kvokání bylo jen na mém přijímači. :D
zkoušel jsem VM vypnout a znovu spustit. Až do spuštění Kanboardu vše OK. Boxík se zjevil, admin + heslo taky.
Po kliknutí na odkaz se objevilo na straně
Internal Error: SQLSTATE[08006] [7] could not connect to server: Connection refused Is the server running on host "postgres" (172.17.0.1) and accepting TCP/IP connections on port 5432?aplikace https://pandora.spotter.vm/ v boxíku bez loginu a hesla.
sice taky "běží" ale po kliknutí se strana nespustí.
CTS to umí takle :)
(asi neběží nějaká služba, takže proto to appky hlásí)
To značí nějaký problém při instalaci. Aplikace jako taková se zaregistruje hned po stažení, ale login k ní se doplní až jako jedna z posledních věcí v jejím instalačním skriptu. Nerozumím tomu, proč by se to mělo stát u všech aplikací mimo těch dvou. Vyřešíme s diagnostickým buildem, pokud se stejný problém vyskytne i tam.
Tady závisí na výkonu stroje. Změna obecných nastavení vynutí restart všech běžících aplikací. Pokud je aplikací hodně a počítač jede na uhlí, trvá to dlouho.
OK, vyřeším to co nejdřív, dokud mám v živé paměti ty iterace, které nikam nevedly a jak to vlastně celé funguje.
Už teď mám pocit, že je v administraci těch návodných textů zbytečně moc, takže bych raději takovéhle záležitosti řešil spíš uživatelským manuálem (který klidně může být dostupný přímo v aplikaci, a klidně i u jednotlivých položek můžou být prokliky přímo na související kapitolu). Tam se můžu rozepsat o všelijakých konkrétních scénářích a jejich řešeních (domácí internety bez veřejné IP, podniková síť s již existujícím webovým serverem, automatizace obnovy 3rd part certifikátu atd.)
Subdoména se po instalaci té dané aplikace zobrazí v nastavení hostitele v sekci o DNS. Pokud ta informace ma být známa dopředu, pak bych opět šel formou dokumentace.
Až zase zatoužíte po kancelářském zaměstnání, běžte dělat testera. Povedlo se Vám rozbít něco, co nebylo možné rozbít. 172.17.0.1 má být adresa hostitele a nikoliv databázového kontejneru. Ta adresa je zadaná natvrdo. Pokud má tuhle adresu postgres, tak muselo dojít ke smazání souboru s alokacemi adres, což netuším jak by se mohlo stát. Evidentně se to ale stát může. A vysvětlovalo by to i ten první problém s neúspěšným během instalačního skriptu.
noční proces stahování, instalace a spuštění byl zcela bez mých zásahů, spal jsem. Pořadí apps ve frontě jsem klikal náhodně, nakonec ale všechny. Na mé plečce to znamenalo, že ntb dostal strašně naloženo na svapování RAM, ale s trpělivostí to udejchal a tak jsem apps postupně vypnul.
Jo, už asi vidím, jak se to rozbilo. Souběhem. Při startu kontejneru se čte soubor s alokacemi, zjistí se první volná adresa, ta se kontejneru přiřadí a do toho souboru se zapíše. Když ale začne kontejner číst ten soubor ve chvíli, kdy ho jiný kontejner zapisuje, přečte ho jako prázdný a ty záznamy, které tam původně existovaly tak samozřejmě zapsat nemůže. Přidám tam zámek. To ale znamená, že ta vaše instance je v současné chvíli nepoužitelná, protože přišla o ten "pevný" záznam pro samotného hostitele.
Pravda. Texty jsou pro dementa mého formátu dobře napsané, ale chtělo by to vyházet do externí nápovědy /dokumentace/. Admin rozhraní pouze minimalistické a nanejvýš u objektu udělat (?) s hyperlinkem.
Tohle se postupně doladí.
zkusil jsem znovu udělat downloady, použil hosts kvuli doménám a pozoruji toto:
u aplikací v portálu se zobrazují v boxiku Login, Heslo
Kanboard a CTS se korektně spouští okamžitě
CKAN po instalaci nejdřív po kliknutí ukazoval chybu 502, Chyba spojení s aplikací
Aplikace ke které se pokoušíte připojit není dostupná. Nejspíše byla vypnuta správcem serveru. ale později po dalším reloadu už se to probudilo a aplikace se zobrazila.
SeedDMS, Pan.do/ra, Sahana, Sahana DEMO, Sambro, Ushahidi po instalaci a kliknutí na boxík nelze nalézt stranu = Tento web není dostupný
další testy udělám v neděli.
To je očekávaný stav. Znamená to, že kontejner se spustil a zaregistroval v proxy serveru hostitele, ale aplikace v něm ještě není úplně vzhůru, takže proxy nemá kam poslat požadavek. Jediné, co se tu dá vymyslet, je změnit tu hlášku.
To zní jako bystě měl špatně zadané záznamy pro lokální překlad v
C:\Windows\System32\drivers\etc\hosts. Pokud totiž aplikace není nainstalovaná nebo neběží, zobrazí se rozcestník, případně 404 Stránka nebyla nalezena. Vaše hláška ale říká, že klient vůbec nenašel cestu k serveru.už jsem to asi objevil, v té řádce hosts od vás byl překlep navíc tečka a vše za ní nemohlo fungovat
šlo by výhledově zprovoznit https://spotter.dasm.cz:8443/ asi momentálně kvůli paměťovým nárokům VM a dispozicím mého 4GB ntb? Virtualbox pochopitelně neuvolňuje paměť, kterou si apps jednou alokují.
Určitě. Ošetřím ty nejpalčivější problémy (myslím, že teď už mi zbývá jen ta "globalizace" fronty), pošlu Vám diagnostický build, který můžete otestovat na internetu z roku 1995 a zároveň jej nainstaluji i u sebe.
Oukej... Obvykle nemám tendence testovat jen pro best-case scenaria a snažím se myslet na to, kde někdo může zadat nějakou kokotinu, kde se můžou potkat kusy kódu, které by se v žádném případě potkat neměly a vůbec jaké havarijní stavy můžou nastat, ale jak teď refaktoruji kód pro tu globální frontu, objevuji si tam čím dál tím víc neošetřených záležitostí.
Takže ještě poprosím o chvíli strpení. Globální frontu už mám, ale než to někam pošlu nebo někde spustím, dořeším ještě ty zbytky. Už jsem (snad) učinil obnovitelnými i takové stavy, kdy v půlce instalace někdo natvrdo vypne celou virtuálku, ale teď jsem zas třeba zjistil, že když do konfigurace přistupuju nejen z více vláken, ale i z více procesů najednou, vznikají mi nekonzistentní stavy, které neřeší ani a systém zámků, který tam mám od začátku.
Stejně očekávám, že až ošetřím všechno, do pěti minut to rozbijete na něčem úplně novém. :)
Já myslím že časově to nechám na vás, to se vyplatí neuspěchat.
jsem teď momentálně jen na wifi v Krumlově. VM mi tvrdošíjně nabízí 127.0.0.1 kde nic neni :)
v hosts jsem ji použil
aha, změnil jsem ve virtualboxu síťový device na wifi a pak už to jde... pardon
poslední build VM jsem stáhl, neměnil jsem host, default spotter.vm vyhovuje. Přihlásil se k IP, pak k DS, oklikal stahování. Začalo to stahovat a strana se v rámci funkčnosti chová jak má. Dokonce i když zavřu celé okno chrome, pak otevřu, tak to ukáže znovu proces a stahování.
Po pár staženích to skončilo
což může být nějaká syntaktická chyba někde ve scriptu, nebo nevim... Zároveň nemůžu vyloučit i krátkodobý výpadek spojení. Dnes jsem totiž řešil konektivitu opakovaným rebootem antény podle rady místního ISP.
Nicméně trochu z toho stavu vyplývá, že z rozhraní momentálně nelze killnout stahovací proces. Takže když to jednou spustím, pak bych jedině musel zastavit VM.
Pak jsem zkoušel se různě odhlašovat a přihlašovat do VM a zkoušel jsem spustit CKAN a Kanboard.
Obě položky se ukázaly jako boxíky. Po kliknutí na https://ckan.spotter.vm/ už to aplikaci nespustilo.
Pak jsem se chtěl vrátit na stranu https://192.168.1.158/setup-apps ale dostal jsem hlášku že je to nedostupné, že zrovna startuje nebo ukončuje. Tato hláška by asi byla OK v případě apps, ale nevim jestli to tedy platí i na webserver (?)
Další návrhy bych mohl rozepsat k rozhraní, ale to teď asi není vhodné, respektive to by asi mělo být v jiném Issue a v jiném milestone.
Pokusím se restartovat VM a pokračovat ve zkoumání a spuštění alespoň něčeho. Jsem trochu limitovaný operační pamětí. Všiml jsem si ve Windows Správci úloh, že se chrome po začátku stahování dost namnožil v procesech a zaujal hodně paměti, předpokládám že to je právě vlastnost aby fronta fungovala.
Tak zdá se, že v tomto stavu se stažené apps asi nespustí. Tj. něco trvale nedovoluje spuštění. Můžu ještě něco dostahovat, nebo vystoupit nastoupit.
Počítač kvuli případnému vzdálenému přístupu můžu mít puštěný asi cca do soboty. dá se v něm rýpat, tedy pokud zas nevypadne připojení antenou.
aha, už vim... to je zase jiná IP v hosts. Pochopitelně :)
Tak ještě prosím tu VM jednou zahoďte a stáhněte OVA, které jsem před pár minutami nahrál. Jsou tam nějaké úpravy kolem logování, ať toho vidím ještě víc, a hlavně persistentně.
Z toho co popisujete to na mě působí, jako by se ta VM potýkala s vážným nedostatkem systémových prostředků. Nestahující se a nestartující aplikace, samotný manažer hlásící chybu 502 (=chcípl), to vše tomu nasvědčuje.
To je pravda. Buď dojede úspěšně do konce nebo zajde na souchotě a dostanete chybovou hlášku.
No to je spíš vlastnost charakteristická pro moderní prohlížeče, s chromem v čele :( Fronta samotná funguje tak, že se každou vteřinu na pozadí javascriptem načte a zobrazí aktuální stav tabulky. Není to až tak závratný rozdíl oproti tomu, co se posílalo předtím (stavy pro jednotlivé řádky ve frontě). Stahování samotné probíhá kompletně na serveru a na klientovi nijak nezávisí, takže jediné, co musí klient dělat, je jednou za vteřinu přechroustat a zobrazit nějakých 7 kB HTML. To, že si na to milý chrome vyhradí 4 procesy a 300 MB RAM, už bohužel neovlivním.
No a protože zítra už je čtvrtek, což je prakticky konec týdne, tak instance na https://spotter.dasm.cz:8443/ jede. Hesla jsou stejná jako k OVA obrazu.
paráda, díky... no, uznávám, že když se k tomu budu chovat slušně a spouštět tak jednu aplikaci, tak to na té mojí plečce s 4GB pujde. A kvokání tím minimalizuji. Za tu online verzi díky, tím doufám odpozoruji nějaké chování zapříčiněné hlavně mými lokálními podmínkami.
Na poslední VM jsem oklikal stahování aplikací odspoda v seznamu a znova se objevily hlášky
(přestože jinde než dříve).
tentokrát u rodiny SE, SE-Demo a Sambro a u CTS. Po restartu už to znova nejde reinstalovat. Tady by asi pomohly v analýze nějaké logy. Připadá mi, že už to znovu nestahuje (čili staženo je) ale pak selže na instalaci.
Na své lokální VM jsem vstoupil na stranu Nastavení aplikací. Tam se mi v seznamu zobrazila nová položka Odoo. Spustil jsem stahování a instalaci. To proběhlo. Pak jsem spustil aplikaci. Aplikace "Spuštěna". Pak jsem zaškrtl box Zobrazena. Přešel na stranu Portál a boxík se nezjevil.
(tady odhaduji, že v kódu staré VM neni kód boxiku Odoo, takže není co by se zjevilo.)
nespěchá
pozorování:
vrátil jsem se ke stavu VM jak jsem se tomu věnoval cca před měsícem.
podobná situace byla i u CTS. Zde se po instalaci znovu stahovalo, ale instalace se také nezdařila. Obávám se ale, že to nemusí být jen konkrétně tyto aplikace. Pojal jsem podezření, že u dřívějších "prvních instalací" nebylo možné doinstalovat i jiné aplikace, když jsem postupně nebo náhodně instaloval celou frontu aplikací.
spekulace:
návrh:
Vím že jste něco psal že do 21. fungujete, pak už ne, ... vpořádku, není nutno to řešit teď, další termín v ČK je 1. týden v lednu nebo jindy.
jiná varianta je, že nemusíte zkoumat vzdáleně, pokud prozkoumáte u sebe, zda to je nějakými instalačními okolnostmi. Případně jak zařídit větší blbovzdornost.
Vyřešit to pak můžete až s dalším buildem VM.
closed