ODK Collect - připojení k ODK Aggregate - SSL protocol error #235

Closed
opened 2018-03-18 18:07:53 +01:00 by Podhorecky · 13 comments
Podhorecky commented 2018-03-18 18:07:53 +01:00 (Migrated from git.spotter.cz)

Zkoušel jsem z Androidu a aplikace ODK Collect připojit se k serveru. Zatim se nedařilo zobrazit cokoliv že se spojil se serverem a vyskakovaly chybová okna jako toto:

IMG_0606

Taky jsem usiloval o něco podobného i s appkou GeoODK collect, ale taky se nedařilo.
Vzhledem k okolnostem však nemohu zcela přesně formulovat problém, aby se dal zopakovat.
Moje testy přes Android jsou hrozně otravné peklo. (pomalý tablet, mizerný internet, router který odpojuje wifi, mizerné světelné podmínky a jiné záludnosti. Běžně tak doma simuluji takovou krizovou událost, ještě bych mohl vytopit sklep nebo zapálit dům a bude to komplet :)

Pokud se vám podaří ověřit, že klient komunikuje se serverem, tak super, já se k tomu postupně prokoušu.

Pro kontrolu jsem zkoušel připojení z iOS s Ushahidi Mobile, tak tam klient se serverem komunikuje.
(jasně, vim že to je zcela jiná věc a jinak navržená appka, ale neměl jsem jinou možnost jak ověřovat žijící server.)

Zkoušel jsem z Androidu a aplikace ODK Collect připojit se k serveru. Zatim se nedařilo zobrazit cokoliv že se spojil se serverem a vyskakovaly chybová okna jako toto: ![IMG_0606](/uploads/3e9478c6dfb776379261bbbd4e44587f/IMG_0606.png) Taky jsem usiloval o něco podobného i s appkou GeoODK collect, ale taky se nedařilo. Vzhledem k okolnostem však nemohu zcela přesně formulovat problém, aby se dal zopakovat. Moje testy přes Android jsou hrozně otravné peklo. (pomalý tablet, mizerný internet, router který odpojuje wifi, mizerné světelné podmínky a jiné záludnosti. Běžně tak doma simuluji takovou krizovou událost, ještě bych mohl vytopit sklep nebo zapálit dům a bude to komplet :) Pokud se vám podaří ověřit, že klient komunikuje se serverem, tak super, já se k tomu postupně prokoušu. Pro kontrolu jsem zkoušel připojení z iOS s Ushahidi Mobile, tak tam klient se serverem komunikuje. (jasně, vim že to je zcela jiná věc a jinak navržená appka, ale neměl jsem jinou možnost jak ověřovat žijící server.)
Disassembler commented 2018-03-18 18:11:40 +01:00 (Migrated from git.spotter.cz)

Správná adresa - http://dasm.dasm.cz:8815/aggregate - je uvedena na dlaždici ODK Collect na vstupní straně.

HTTPS nebude fungovat v drtivé většině aplikací, protože máme selfsigned certifikát.

Správná adresa - http://dasm.dasm.cz:8815/aggregate - je uvedena na dlaždici *ODK Collect* na vstupní straně. HTTPS nebude fungovat v drtivé většině aplikací, protože máme selfsigned certifikát.
Disassembler commented 2018-03-18 18:11:41 +01:00 (Migrated from git.spotter.cz)

closed

closed
Podhorecky commented 2018-03-18 18:23:02 +01:00 (Migrated from git.spotter.cz)

Ha, zkusil jsem a máte samozřejmě pravdu, funguje to.
URL jsem lovil na mobilu a pak přepsal ručně, ono taky používat na téhle parodii tabletu copy+paste je komplikovaný porod.

až budu řešit design vstupní strany, tak to bude muset být o kapku víc friendly pro špatně vidící spoluobčany :)

Ha, zkusil jsem a máte samozřejmě pravdu, funguje to. URL jsem lovil na mobilu a pak přepsal ručně, ono taky používat na téhle parodii tabletu copy+paste je komplikovaný porod. až budu řešit design vstupní strany, tak to bude muset být o kapku víc friendly pro špatně vidící spoluobčany :)
Disassembler commented 2018-03-18 18:40:15 +01:00 (Migrated from git.spotter.cz)

No ono by možná stálo za úvahu, jestli nepřehodnotit, jak vlastně má být celá VM deploynuta, protože tenhle systém, kdy máme HTTPS jen někde a někdy a máme aplikace rozházené po různých portech, je celkem na prd.

Ideální případ by byl použít nějakou skutečnou doménu, aplikace nastrkat na její subdomény a k těm requestovat Let's encrypt certifikáty. Pak bychom prostě měli https://odk.spotter.xx nebo https://odk.nejaka-ngo.cz, všude by mohlo být pouze HTTPS, takže by uživatel nemusel zjišťovat, který že to protokol má použít a doménový název je také o poznání lépe zapamatovatelný něž nějaké hauznumero následované dvojtečkou a dalším kratším hauznumerem. Také bychom eliminovali problém s průchodností portů přes některé přehnaně restriktivní firewally. Ale v takovém případě by skutečně muselo být zajištěno, že VM poběží na adrese, která je dostupná z internetu a bude mít platné DNS záznamy.

Technologicky schůdnou alternativou by pak bylo naopak HTTPS nepoužívat vůbec a všude použít plain HTTP, čímž by se eliminovalo alespoň zmatení protokolů. Nicméně posílat osobní údaje z nějakého knihovního hotspotu nešifrovaně je recept na katastrofu. Bohužel plain HTTP musí být u mobilních aplikací použito stejně, protože selfsigned certifikáty nežerou a neexistuje jednoduchý univerzální způsob, jak je k tomu donutit.

No ono by možná stálo za úvahu, jestli nepřehodnotit, jak vlastně má být celá VM deploynuta, protože tenhle systém, kdy máme HTTPS jen někde a někdy a máme aplikace rozházené po různých portech, je celkem na prd. Ideální případ by byl použít nějakou skutečnou doménu, aplikace nastrkat na její subdomény a k těm requestovat Let's encrypt certifikáty. Pak bychom prostě měli https://odk.spotter.xx nebo https://odk.nejaka-ngo.cz, všude by mohlo být pouze HTTPS, takže by uživatel nemusel zjišťovat, který že to protokol má použít a doménový název je také o poznání lépe zapamatovatelný něž nějaké hauznumero následované dvojtečkou a dalším kratším hauznumerem. Také bychom eliminovali problém s průchodností portů přes některé přehnaně restriktivní firewally. Ale v takovém případě by skutečně muselo být zajištěno, že VM poběží na adrese, která je dostupná z internetu a bude mít platné DNS záznamy. Technologicky schůdnou alternativou by pak bylo naopak HTTPS nepoužívat vůbec a všude použít plain HTTP, čímž by se eliminovalo alespoň zmatení protokolů. Nicméně posílat osobní údaje z nějakého knihovního hotspotu nešifrovaně je recept na katastrofu. Bohužel plain HTTP musí být u mobilních aplikací použito stejně, protože selfsigned certifikáty nežerou a neexistuje jednoduchý univerzální způsob, jak je k tomu donutit.
Podhorecky commented 2018-03-18 21:47:49 +01:00 (Migrated from git.spotter.cz)

Jasné, díky za návrh. Poladit domény určitě dává smysl , jen nejdřív rozmyslet jak.

Co se týče subdomén, tak bych byl zatím ještě opatrný, výběr aplikací není definitivní. jsme stále v příliš ranné fázi, kde přežiju i nepohodlí a omyly.

Pro funkční úpravu vstupní strany si plánuji úlohy pro kodera, chtěl bych oddělit vstupní stranu pro uživatele a pro admina.

Napadlo mne co by mohlo vylepšit přístup k VM:

Samotná Úvodní strana (s nějakým easy setupem) by mohla být na mém hostingu a doméně.
Kde by byly nakonfigurovány redirecty vedoucí na neveřejnou IP běžící VM, SW by zůstal na VM jak je.

Tohle by asi muselo být nějak mazaně udělané, v setupu strany a já nevím co ještě.. (doufám že zde není nějaký principielní problém?) Při spuštěné VM, nastavit IP a počkat až se přepíší záznamy v DNS?

Zatím zkusme ještě chvíli pracovat na VM, kde sice bude ukrutné trápení s URL, HTTP HTTPS, SSL i s jinými okolnostmi, ale bude to stále pokus o přenositelnou VM.

Je to možná cesta jak zjednodušit URL?

Jasné, díky za návrh. Poladit domény určitě dává smysl , jen nejdřív rozmyslet jak. Co se týče subdomén, tak bych byl zatím ještě opatrný, výběr aplikací není definitivní. jsme stále v příliš ranné fázi, kde přežiju i nepohodlí a omyly. Pro funkční úpravu vstupní strany si plánuji úlohy pro kodera, chtěl bych oddělit vstupní stranu pro uživatele a pro admina. Napadlo mne co by mohlo vylepšit přístup k VM: Samotná Úvodní strana (s nějakým easy setupem) by mohla být na mém hostingu a doméně. Kde by byly nakonfigurovány redirecty vedoucí na neveřejnou IP běžící VM, SW by zůstal na VM jak je. Tohle by asi muselo být nějak mazaně udělané, v setupu strany a já nevím co ještě.. (doufám že zde není nějaký principielní problém?) Při spuštěné VM, nastavit IP a počkat až se přepíší záznamy v DNS? Zatím zkusme ještě chvíli pracovat na VM, kde sice bude ukrutné trápení s URL, HTTP HTTPS, SSL i s jinými okolnostmi, ale bude to stále pokus o přenositelnou VM. Je to možná cesta jak zjednodušit URL?
Disassembler commented 2018-03-18 23:11:39 +01:00 (Migrated from git.spotter.cz)

Pro admina rozhodně oddělené rozhraní bude potřeba. Už jen proto, že se skrze něj budou nastavovat různé konfigurační parametry předávané aplikacím a taky updatovat kontejnery.

Zjednodušení přístupu nerozumím. Certifikát se ověřuje při každém připojení klienta k serveru. Takže jediný případ, kdy by něco takového mohlo fungovat by bylo, kdyby váš server na forpsi fungoval jako proxy a zároveň nejspíše i jako VPN server, ke kterému by se VM připojila jako klient. Všechny požadavky by pak šly přes něj, což by nebylo ani rychlé, ani přenositelné.

Flow HTTPS požadavku z pohledu klienta je:

  1. Přeložit plně kvalifikované doménové jméno (FQDN) serveru na IP pomocí DNS (tzn. je vyžadován přístup na internet nebo statický záznam u klienta, případně na DNS serveru, který klient používá, zpravidla na routeru. Na mobilech se nastavit většinou nedá).
  2. Připojit se na IP uvedenou v DNS záznamu, od serveru dostane TLS certifikát.
  3. Zkontrolovat certifikát a sestavit chain of trust. K tomu musí mimo jiné být splněny následující podmínky
  • FQDN serveru musí odpovídat subjektu uvedeném v certifikátu (tzn. pokud klient přistoupí na adresu https://192.168.12.34 a dostane certifikát pro https://odk.spotter.xx nebo naopak, spojení se nesestaví).
  • Vystavitel certifikátu musí být na straně klienta veden jako důvěryhodný (tzn. certifikát nesmí být self-signed, musí být podepsán autoritou, kterou klient už zná. Autority se sice dají přidávat, ale na mobilech opět ne všude, kde potřebujeme).
  1. Pokud byl certifikát bez problémů ověřen, poslat HTTP požadavek.

A pokud se bavíme o certifikátech Let's Encrypt, tak tam žádosti o certifikáty a recertifikaci fungují z pohledu HTTPS serveru následovně:

  1. Vytvořit certificate signing request k požadovanému FQDN společně se soukromým klíčem. Ten opravňuje držitele daným certifikátem se prokazovat.
  2. Připojit se na ACME server (certificate enrollment server provozovaný Let's Encryptem) a předat signing request. Na základě tohoto requestu je HTTPS server instruován vystavit jednorázový klíč na zadané URL.
  3. ACME server přeloží FQDN HTTPS serveru pomocí DNS na IP. Tentokrát bude vždy použit doménový server registrátora domény.
  4. ACME server se pokusí připojit skrze plain HTTP na IP adresu uvedenou v DNS záznamu a vyžádat si jednorázový klíč na URL odeslané v kroku 2. Tím ověří, že žadatel o certifikát je skutečně dostupný na zadaném FQDN pro který certifikát požaduje.
  5. Pokud ACME server klíč najde, signing request podepíše a odešle hotový certifikát HTTPS serveru.
  6. HTTPS server nainstaluje nový certifikát společně se soukromým klíčem a reloadne konfiguraci, aby se načetl.

Některé části je možno dělat trochu jiným (složitějším) způsobem anebo je dělat ručně, ale Let's Encrypt certifikát je takto nutno obnovit každé tři měsíce. Nicméně právě tohle jsou důvody, proč HTTPS server musí být alespoň občas dostupný z internetu (aby se certifikát vůbec dal získat a obnovit) a proč nějaké čarování s redirecty ovoce nejspíš nepřinese (neposkládá se chain of trust).

Zásadní problém vidím v tom, že bereme aplikace, které jsou od začátku do konce navrženy pro bezpečný provoz na serveru a cpeme je na VM, která nemá ani pevně danou adresu, ani FQDN, ani není součástí nějaké infrastruktury. Spíše než "přenositelnou" bych se pokoušel o "instalovatelnou" - tj. nebude s ní možno běhat po lesích a bude nutno na ní udělat nějaké poinstalační nastavení k tomu, aby se dala plnohodnotně používat. Dokud se k ní nezačneme chovat jako k serveru, nebude nám fungovat HTTPS, nebudou nám chodit maily, nebude nám fungovat OAuth (Google, Facebook, Humanitarian ID) a dost možná se k ní z některých míst nebude dát ani připojit, protože používáme nestandardní porty.

Pro admina rozhodně oddělené rozhraní bude potřeba. Už jen proto, že se skrze něj budou nastavovat různé konfigurační parametry předávané aplikacím a taky updatovat kontejnery. Zjednodušení přístupu nerozumím. Certifikát se ověřuje při každém připojení klienta k serveru. Takže jediný případ, kdy by něco takového mohlo fungovat by bylo, kdyby váš server na forpsi fungoval jako proxy a zároveň nejspíše i jako VPN server, ke kterému by se VM připojila jako klient. Všechny požadavky by pak šly přes něj, což by nebylo ani rychlé, ani přenositelné. Flow HTTPS požadavku z pohledu klienta je: 1. Přeložit plně kvalifikované doménové jméno (*FQDN*) serveru na IP pomocí DNS (tzn. je vyžadován přístup na internet nebo statický záznam u klienta, případně na DNS serveru, který klient používá, zpravidla na routeru. Na mobilech se nastavit většinou nedá). 2. Připojit se na IP uvedenou v DNS záznamu, od serveru dostane TLS certifikát. 3. Zkontrolovat certifikát a sestavit *chain of trust*. K tomu musí mimo jiné být splněny následující podmínky - FQDN serveru musí odpovídat subjektu uvedeném v certifikátu (tzn. pokud klient přistoupí na adresu https://192.168.12.34 a dostane certifikát pro https://odk.spotter.xx nebo naopak, spojení se nesestaví). - Vystavitel certifikátu musí být na straně klienta veden jako důvěryhodný (tzn. certifikát nesmí být self-signed, musí být podepsán autoritou, kterou klient už zná. Autority se sice dají přidávat, ale na mobilech opět ne všude, kde potřebujeme). 4. Pokud byl certifikát bez problémů ověřen, poslat HTTP požadavek. A pokud se bavíme o certifikátech Let's Encrypt, tak tam žádosti o certifikáty a recertifikaci fungují z pohledu HTTPS serveru následovně: 1. Vytvořit *certificate signing request* k požadovanému FQDN společně se soukromým klíčem. Ten opravňuje držitele daným certifikátem se prokazovat. 2. Připojit se na ACME server (*certificate enrollment* server provozovaný Let's Encryptem) a předat signing request. Na základě tohoto requestu je HTTPS server instruován vystavit jednorázový klíč na zadané URL. 3. ACME server přeloží FQDN HTTPS serveru pomocí DNS na IP. Tentokrát bude vždy použit doménový server registrátora domény. 4. ACME server se pokusí připojit skrze plain HTTP na IP adresu uvedenou v DNS záznamu a vyžádat si jednorázový klíč na URL odeslané v kroku 2. Tím ověří, že žadatel o certifikát je skutečně dostupný na zadaném FQDN pro který certifikát požaduje. 5. Pokud ACME server klíč najde, signing request podepíše a odešle hotový certifikát HTTPS serveru. 6. HTTPS server nainstaluje nový certifikát společně se soukromým klíčem a reloadne konfiguraci, aby se načetl. Některé části je možno dělat trochu jiným (složitějším) způsobem anebo je dělat ručně, ale Let's Encrypt certifikát je takto nutno obnovit každé tři měsíce. Nicméně právě tohle jsou důvody, proč HTTPS server musí být alespoň občas dostupný z internetu (aby se certifikát vůbec dal získat a obnovit) a proč nějaké čarování s redirecty ovoce nejspíš nepřinese (neposkládá se chain of trust). Zásadní problém vidím v tom, že bereme aplikace, které jsou od začátku do konce navrženy pro bezpečný provoz na serveru a cpeme je na VM, která nemá ani pevně danou adresu, ani FQDN, ani není součástí nějaké infrastruktury. Spíše než "přenositelnou" bych se pokoušel o "instalovatelnou" - tj. nebude s ní možno běhat po lesích a bude nutno na ní udělat nějaké poinstalační nastavení k tomu, aby se dala plnohodnotně používat. Dokud se k ní nezačneme chovat jako k serveru, nebude nám fungovat HTTPS, nebudou nám chodit maily, nebude nám fungovat OAuth (Google, Facebook, Humanitarian ID) a dost možná se k ní z některých míst nebude dát ani připojit, protože používáme nestandardní porty.
Podhorecky commented 2018-03-18 23:25:56 +01:00 (Migrated from git.spotter.cz)

Aha, ok... snad jsem to v principu pochopil.

řekněme že tedy půjdeme cestou instalovatelnosti... znamená to teď nějakou velkou změnu do stávajícího stavu? Poinstalační setup mi nevadí, s tím se dá počítat. Obnova certifikátu - to se dá taky zvládnout.

Aha, ok... snad jsem to v principu pochopil. řekněme že tedy půjdeme cestou instalovatelnosti... znamená to teď nějakou velkou změnu do stávajícího stavu? Poinstalační setup mi nevadí, s tím se dá počítat. Obnova certifikátu - to se dá taky zvládnout.
Disassembler commented 2018-03-19 09:00:00 +01:00 (Migrated from git.spotter.cz)

Jo a ještě na cookies jsem zapomněl. Ty mají taky zásadní problém s tím, že všechny aplikace jedou na stejné adrese a liší se jen porty, protože cookies porty nerozlišují. To je například důvod, proč když se přihlásíte do Sahany a pak ještě do SAMBRO, ze Sahany vás to zase vykopne.

znamená to teď nějakou velkou změnu do stávajícího stavu

Velkou, ve smyslu "složitou a zdlouhavou" ne. Nicméně nějaké překopáníčko bude potřeba. Podobně jako u Dockerizace od toho očekávám usnadnění vývoje i následné práce s jednotlivými aplikacemi. Zrovna třeba u toho ODK Aggregate, kde to se všemi těmi proxynami a redirecty bylo na posrání, myslím, že pomocí FQDN a vynucení validního HTTPS budu schopen všechny ty podivné workaroundy úplně eliminovat. Jediné, co se zásadně změní, budou požadavky na to, kde VM bude moct být nainstalována a provozována.

Jo a ještě na cookies jsem zapomněl. Ty mají taky zásadní problém s tím, že všechny aplikace jedou na stejné adrese a liší se jen porty, protože cookies porty nerozlišují. To je například důvod, proč když se přihlásíte do Sahany a pak ještě do SAMBRO, ze Sahany vás to zase vykopne. > znamená to teď nějakou velkou změnu do stávajícího stavu Velkou, ve smyslu "složitou a zdlouhavou" ne. Nicméně nějaké překopáníčko bude potřeba. Podobně jako u Dockerizace od toho očekávám usnadnění vývoje i následné práce s jednotlivými aplikacemi. Zrovna třeba u toho ODK Aggregate, kde to se všemi těmi proxynami a redirecty bylo na posrání, myslím, že pomocí FQDN a vynucení validního HTTPS budu schopen všechny ty podivné workaroundy úplně eliminovat. Jediné, co se zásadně změní, budou požadavky na to, kde VM bude moct být nainstalována a provozována.
Podhorecky commented 2018-03-19 09:35:44 +01:00 (Migrated from git.spotter.cz)

Ok, vše co píšete mi připadá rozumné. Přiznávám, že tyhle detaily znám jen z uživatelského hlediska. Jsem rád, že nad tím takto přemýšlíte.
Takže ano, představuji si z toho, že výsledek snažení bude adminem "plynule" nainstalovatelný balík SW, nakonfigurovatelný na jím určenou destinaci, tj server. Konfigurací si nastaví a zabezpečí prostředí a bude mít po ruce vše co v základu potřebuje.
Kdyby se rozhodl nainstalovat na desktop HW, tak to bude možné? (například na samostatný diskový oddíl?)
Můžu od toho čekat že připravíte instalační diskovou image, kde nebudou živé SW, ale budou tam všechny zdroje k určitému datu tak, aby ta instalace mohla proběhnout i bez internetu? (a později s internetem možnost updatovat nové verze)
S tím bych neměl problém.

Ok, vše co píšete mi připadá rozumné. Přiznávám, že tyhle detaily znám jen z uživatelského hlediska. Jsem rád, že nad tím takto přemýšlíte. Takže ano, představuji si z toho, že výsledek snažení bude adminem "plynule" nainstalovatelný balík SW, nakonfigurovatelný na jím určenou destinaci, tj server. Konfigurací si nastaví a zabezpečí prostředí a bude mít po ruce vše co v základu potřebuje. Kdyby se rozhodl nainstalovat na desktop HW, tak to bude možné? (například na samostatný diskový oddíl?) Můžu od toho čekat že připravíte instalační diskovou image, kde nebudou živé SW, ale budou tam všechny zdroje k určitému datu tak, aby ta instalace mohla proběhnout i bez internetu? (a později s internetem možnost updatovat nové verze) S tím bych neměl problém.
Disassembler commented 2018-03-19 15:01:34 +01:00 (Migrated from git.spotter.cz)

Kdyby se rozhodl nainstalovat na desktop HW...

Je to pořád virtuálka. Pokud má desktop HW dostatek systémových prostředků a funguje na něm nějaký hypervizor, tak to pojede. Jediný problém, se kterým se dotyčný bude muset poprat je zase jen networking. Ten se jakožto externí závislost programově nijak nastavit nedá. Ten se dá jen vydatně zdokumentovat.

Můžu od toho čekat že připravíte instalační diskovou image, kde nebudou živé SW, ale budou tam všechny zdroje k určitému datu...

Přesně obráceně. Na virtuálce budou Docker image s živými SW (resp. spinkajícími, čekajícími na polibek z pravé lásky aktivaci z administrátorského rozhraní) sestavené k určitému datu. Distribuce zdrojů by zabírala daleko více místa a museli bychom k ní distribuovat i všechny build skripty. Navíc sestavení samotné sežere další hromadu času a systémových prostředků. To byl další z důvodů, proč jsme aplikace nakontejnerovali. Chceš aplikaci? Pusť si kontejner. Nechceš aplikaci? Zastav kontejner. Chceš update? Stáhni si image ze Spotterova webu a kontejner pak restartuj.

Aktualizované image pak mohou být distribuovány na web kýmkoliv, kdo bude disponovat přístupem pro zápis, zdroji (resp. přístupem na GitHub a jiné internety) a build skripty k jejich sestavení. To budu v počátku já a až se vzájemně nasereme, může to být kdokoliv jiný.

> Kdyby se rozhodl nainstalovat na desktop HW... Je to pořád virtuálka. Pokud má desktop HW dostatek systémových prostředků a funguje na něm nějaký hypervizor, tak to pojede. Jediný problém, se kterým se dotyčný bude muset poprat je zase jen networking. Ten se jakožto externí závislost programově nijak nastavit nedá. Ten se dá jen vydatně zdokumentovat. > Můžu od toho čekat že připravíte instalační diskovou image, kde nebudou živé SW, ale budou tam všechny zdroje k určitému datu... Přesně obráceně. Na virtuálce budou Docker image s živými SW (resp. spinkajícími, čekajícími na ~~polibek z pravé lásky~~ aktivaci z administrátorského rozhraní) sestavené k určitému datu. Distribuce zdrojů by zabírala daleko více místa a museli bychom k ní distribuovat i všechny build skripty. Navíc sestavení samotné sežere další hromadu času a systémových prostředků. To byl další z důvodů, proč jsme aplikace nakontejnerovali. Chceš aplikaci? Pusť si kontejner. Nechceš aplikaci? Zastav kontejner. Chceš update? Stáhni si image ze Spotterova webu a kontejner pak restartuj. Aktualizované image pak mohou být distribuovány na web kýmkoliv, kdo bude disponovat přístupem pro zápis, zdroji (resp. přístupem na GitHub a jiné internety) a build skripty k jejich sestavení. To budu v počátku já a až se vzájemně nasereme, může to být kdokoliv jiný.
Podhorecky commented 2018-03-19 15:33:48 +01:00 (Migrated from git.spotter.cz)

ok, zatím mi to připadá jako dobrý návrh. Jaký tedy bude nejbližší postup?
Mam udělat něco ohledně domén?

ok, zatím mi to připadá jako dobrý návrh. Jaký tedy bude nejbližší postup? Mam udělat něco ohledně domén?
Disassembler commented 2018-03-19 15:41:16 +01:00 (Migrated from git.spotter.cz)

Není třeba. Už jsem udělal. Nacpu vám dostupnou testovací VM na svou subdoménu. Tam můžu rozbíjet, žádat certifikáty a testovat dle libosti. Hlavní strana bude tedy dostupná na https://spotter.dasm.cz, Sahana na https://eden.spotter.dasm.cz a tak dále. Až si dohraju, dám vědět.

Není třeba. Už jsem udělal. Nacpu vám dostupnou testovací VM na svou subdoménu. Tam můžu rozbíjet, žádat certifikáty a testovat dle libosti. Hlavní strana bude tedy dostupná na https://spotter.dasm.cz, Sahana na https://eden.spotter.dasm.cz a tak dále. Až si dohraju, dám vědět.
Podhorecky commented 2018-03-20 11:23:27 +01:00 (Migrated from git.spotter.cz)

ok

ok
Sign in to join this conversation.
No project
No Assignees
1 Participants
Notifications
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: Disassembler/Spotter-VM#235
No description provided.