Implementovat rozhraní pro uživatelsky nastavenitelné subdomény a certifikáty #8
No Assignees
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: Spotter-Cluster/vmmgr#8
Loading…
x
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?
V setupu Decidimu je možné vyrobit více než jednu site.
Vyrobil jsem tedy na svém hostingu další, která by měla doménu https://demon.spotter.cz
to se sice uloží, ale při přístupu na URL mne to upozorní že je neplatný certifikát, který u Decidim platí na jednu doménu.
pak mne to přesměruje na Nextcloud, kde je napsáno: Přístup prostřednictvím nedůvěryhodné domény
Chápu, že z bezpečnostních důvodů svévolné tvoření domén u certifikátu neprojde, tak se chci jen zeptat jestli pro tento případ vidíte nějaký workaround.
Pokud ano, lze ho nějak doplnit?
Pokud ne, lze alespoň zmínit v dokumentaci, že to má toto chování?
Druhá věc je, že jsem se pokoušel ověřit, jak říkáte u issue k dokumentaci:
Je to případ Decidim? Nevím, ale zjistím přeinstalací. Tak jsem na demo site https://spotter.dasm.cz:8443/ odinstaloval a smazal Decidim a znovu ho stáhnul a nainstaloval. Z vypisované hlášky o verzi software mi připadalo, že verze je pořád stejná. Přitom vývoj v Decidim na githubu probíhá, tak jsem čekal že bude verze SW vyšší.
Jelikož jsem se dál než do admin setupu nedostal, tak už jsem nemohl ověřit, zda je aplikace v nové verzi.
Protože ta doména není nastavena ani v konfiguraci Apache, takže Apache neví, co s ní má dělat a fallbackne na výchozího virtualhosta, kterým je NextCloud.
Na hostingu samozřejmě ano. Na VM taky, ale ale vyžadovalo by to komplet přepsání logiky pro nastavení proxy pravidel, což, když tak nad tím uvažuji, není vlastně vůbec blbý nápad. Teď to funguje tak, že aplikace se při instalaci registruje ve VMMgr a ten jí dle předaných parametrů automaticky nastaví subdoménu, na které je přístupná. Ale mohlo by to fungovat tak, že proxy bude moct kompletně ovládat i člověk. Bylo by to tak lepší, protože by to umožnilo třeba i podrobnější správu TLS certifikátů. Možnost změny subdomény je v backendu již implementována, akorát to nemáme vytažené do frontendu, protože to v téhle fázi vývoje není vůbec důležité. Představuji si to nějak takhle:
Aplikace by si po instalací stále sama vlezla na nějakou výchozí subdoménu, takže nebude bezpodmínečně nutné, aby uživatel něco nastavoval, ale bylo by plně v jeho moci nastavení proxy serveru zrušit nebo upravit dle libosti.
Tak zmínit to určitě lze, ale jednak je tohle spíš do uživatelské dokumentace než do technické a jednak mi to připadá poněkud tautologické. "Pokud nastavíte, aby nová site Decidimu byla na samostatné doméně, bude na samostatné doméně." To pole, do kterého se ta hodnota zadává se totiž jmenuje "Host" a "Secondary host".
Instaluje se poslední dostupná verze v našem repozitáři. Co je na GitHubu nehraje roli, protože by to musel někdo vzít, sestavit z toho image a publikovat je, což jste mi explicitně řekl, že nemám dělat, pokud k tomu nebudu donucen okolnostmi nebo Vámi. Pokud by byl ke kterékoliv aplikaci nějaký update, bude to na Vás svítit v rozhraní VMMgr.
jojo, to mi došlo, jen jsem to popsal :)
ano, to by bylo fajn.
obrázek: ano, to by bylo super. Tedy že název subdomény bude nastavitelný uživatelsky. Uvažuji totiž, že mohou vzniknout situace, kdy si někdo bude chtít nastavit konkrétní subdoménu + certifikát. Nebo ho to jeho dispozice v jeho IT prostředí přímo nutí.
jasně :) cílem je, aby to bylo buď jako srozumitelná funkce, nebo když funkce neexistuje, tak aby v dokumentaci byla zmínka typu: Víme že to tam není, tak to ani nehledejte. Bude to tam ANO / NE / ZA PODMÏNEK....
aha :) tady asi došlo k nedorozumnění. Moje přikázání bylo ve smyslu, že nemáte dělat nekonečnou činnost neustálého updatování balíků z githubu. Což je ok, jak ve fázi vývoje, tak ve fázi provozu.
Nicméně ve věci dokumentace je asi vhodné vysvětlit čerstvému adminovi, jakým procesem se tedy získá aktuální verze SW. Že to je vymyšleno jako:
Cizí Github (nebo jiné orig. repo) ----> Vlastní repo (zde konkrétně na hostingu Spotter) ---> instalace ve VM.
Z toho co jsem četl jsem mylně nabyl dojmu, že sestavovací skript je tak advanced, že udělá:
Zkontroluje, zda na Github.com je něco nového a pak:
Cizí Github ---> pošle tyto data do vlastní repo, kde je nějaký démon na serveru zabalí do balíčku a vzápětí plynnule pošle k downloadu do VM, kde ho rozbalí a nainstaluje. Zde by pochopitelně bylo nepopsatelné riziko při změnách verzí a podmínek instalace, což by hrozilo neúspěchem instalace.
Prosím nefacepalmujte :) snažím se simulovat čerstvého člověka, který něco očekává. A v dokumentaci neměl napsáno, že pokud si chce něco do své VM stáhnout, tak si to na svou repo taky musí nejdřív zkopírovat. Protože rovnou z originálních zdrojů to nebude.
Důvod je právě ten, že tím chráníme VM před divokou instalací, protože žádná serverová aplikace co máme, se neinstaluje zcela bez admin-fu. Benefitem je pak rychlá a okamžitá instalace té prozkoumané verze.
Aha, to je pro mne novinka. Což jsem vlastně asi zatím neměl šanci vidět,
Ale to nemusí. Od toho je tu to naše repo. Pokud si chce uživatel něco stáhnout, tak jen musí říct odkud (protože jste chtěl mít repo chráněné individuálními přístupy, jinak by ani tohle nebylo úplně nutné) a pak si to prostě stáhne. Své repo potřebuje jen na své image a aplikace, které si sám vybuildil. Tohle je právě něco, k čemu by se asi hodil nějaký diagram z Spotter-Cluster/-#316.
Mějme tři role. Administrátor distribučního serveru, buildera a uživatele. Můžou to být úplně rozdílní lidé.
Administátor:
Builder (zjednodušeno):
Uživatel:
Kliknutí na čudlik způsobí:
Prostě to funguje úplně stejně jako tisíce již existujících distribučních systémů. Takové RPM nebo DEB balíky se principiálně vytváří úplně stejně - builder stáhne a zkompiluje zdrojáky, nadefinuje závislosti, přiohne pár souborů pro danou distribuci a vyrobí instalační balík. Je pravděpodobné, že to za něj dělá nějaký skript, aby to nemusel dělat pokaždé ručně. Balík se umístí do nějakého repozitáře a kdo jej chce stáhnout, musí si na straně klienta repozitář nastavit. Stažení balíku rozbalí soubory, pustí nějaký post-install skript a existenci instalovaného balíku zapíše do nějaké lokální databáze. Nevymyslel jsem nic unikátního a inovativního, jen jsem postopáté znovuvynalezl kolo v takové velikosti, tloušťce a materiálu, který je žádoucí pro naše použití.
jojo, přesně tak:)
to dělení rolí. Ano, to je výstižně shrnuto.
Jasné, jsem s tím v pohodě. Tohle celé issue je pro mne jen synchronizace jak to oba vidíme, případně jakou třešničku v dokumentaci dodat. A vy mi napíšete, že třešeň tam už je, jen zabalená v čokoládě, já ji považoval za něco jiného. :)
A s tím jsem upe v pohodě, nesnažím se vás nachytat. Jen míříme ke stejnému cíli a jsem poněkud pomalejší.
mentioned in issue Spotter-Cluster/vmmgr#7
moved from Podhorecky/Hosting#40
changed title from {-Decidim - při vytvoření druhé site není přijat certifikát-} to {+Implementovat rozhraní pro uživatelsky nastavenitelné subdomény a certifikáty+}
Aha, my už to tu máme jako #7. V tom případě zavírám. Funkce Decidimu byla zdokumentována, na další vývoj máme separátní ticket. Tady už není co víc řešit.