Často kladené otázky (FAQ)

Nejčastější dotazy

Praktické, stručné návody pro nastavení služeb, přístupů a běžných zákaznických postupů.

> Jak funguje kreditní systém Cli>_?

Jeden sdílený předplacený zůstatek financuje všechny způsobilé služby a kredit se čerpá jen za jejich aktivního běhu.
faq/prepaid-credit-how-it-works

Účet Cli>_ má jeden sdílený předplacený kreditní zůstatek. Způsobilí noví zákazníci mohou Starter Credit získat až po dokončení požadovaného ověření účtu a ochrany proti zneužití. Aktivní způsobilé služby zůstatek postupně čerpají. Měsíční odhad počítá s 31 dny a nová služba se spustí jen tehdy, když zůstatek pokryje alespoň 7 dnů. Červené upozornění se zobrazí, když odhadovaná výdrž klesne pod 7 dnů; jinak se oranžové upozornění zobrazí, když klesne pod 14 dnů.

Po vyčerpání zůstatku se služba po 7 dnech pozastaví, přestane spotřebovávat kredit a začne lhůta uchování a vymazání v délce 7 dnů. Před zobrazeným termínem ji lze s dostatkem kreditu znovu spustit. Zrušení provisionované služby ji také pozastaví a spustí stejnou lhůtu. Čekající neprovisionovaná služba se může deaktivovat okamžitě. Po termínu začne deaktivace a odstranění provisionované služby. Force delete službu okamžitě deaktivuje, přeskočí uchování a zahájí odstranění z aktivního runtime; dokončení následuje po zpracování deploymentu a GitOps. Zálohy a Offsite Archive mají vlastní pravidla uchování.

Ilustrační příklad OpenCode za 9,90 EUR: 9,90 / 31 ≈ 0,319 EUR denně. Po 10 celých dnech se spotřebuje přibližně 3,19 EUR. Pokud byl počáteční zůstatek přesně 9,90 EUR a žádná jiná služba jej nečerpala, zbývá asi 6,71 EUR. Po vypnutí se další spotřeba zastaví.

Příklad je pouze ilustrační. Vždy platí aktuální ceny zobrazené v Cli>_.

> Jak vygenerovat veřejný SSH klíč pomocí příkazového řádku

Vytvořte veřejný SSH klíč pro bezpečný přístup k VPS. Sdílejte pouze veřejný klíč; soukromý klíč ponechte na svém zařízení.
faq/jak-vygenerovat-verejny-ssh-klic

Použijte pouze veřejný klíč

SSH používá pár klíčů. Do nastavení služby vložte pouze veřejný klíč, obvykle soubor s příponou .pub. Soukromý klíč zůstává na vašem zařízení.

Postup v terminalu

  1. Otevřete terminál na svém počítači.
  2. Spusťte příkaz: ssh-keygen -t ed25519 -C "your-email@example.com".
  3. Potvrďte umístění souboru nebo zvolte vlastní cestu. Soukromý klíč nikdy nikomu neposílejte.
  4. Veřejný klíč zobrazte příkazem: cat ~/.ssh/id_ed25519.pub.
  5. Zkopírujte celý řádek začínající ssh-ed25519 a vložte jej do pole "SSH veřejný klíč" při objednávce nebo nastavení služby.
  6. Zkopírujte celý řádek s `ssh-ed25519` a vložte ho do pole "SSH veřejný klíč".

Zkontroluj pred vlozenim

  1. Otevřete PowerShell nebo Windows Terminal.
  2. Spusťte příkaz: ssh-keygen -t ed25519 -C "tvůj-email@example.com".
  3. Stiskněte klávesu Enter pro uložení klíče do adresáře C:\Users\tvůj-uživatel\.ssh\id_ed25519, nebo zadejte vlastní cestu.
  4. Pokud Windows vyžádá heslo (passphrase), použijte takové, které můžete bezpečně uložit, nebo pro jednoduché nastavení stiskněte Enter.
  5. Veřejný klíč zobrazíte příkazem: Get-Content $env:USERPROFILE\.ssh\id_ed25519.pub.
  6. Zkopírujte pouze celý řádek začínající ssh-ed25519. Nekopírujte ani nahrávejte soubor se soukromým klíčem.
> Jak graficky vytvořit SSH klíč ve Windows

Grafický postup v systému Windows pro vytvoření páru klíčů SSH bez použití příkazového řádku.
faq/jak-vytvorit-ssh-klic-graficky-ve-windows

Použijte nástroj pro Windows a vložte pouze veřejný klíč

Pár SSH klíčů můžete vytvořit graficky pomocí klienta SSH pro Windows, jako je PuTTYgen. Cli>_ potřebuje pouze veřejný klíč. Soubor se soukromým klíčem ponechte na svém počítači a nahrávejte ho do webového formuláře.

Postup ve Windows

  1. Nainstalujte PuTTY nebo otevřete PuTTYgen, pokud jej již máte nainstalován.
  2. Vyberte EdDSA/Ed25519, pokud je k dispozici, jinak zvolte RSA 4096.
  3. Klikněte na Generuj a pohybujte myší v prázdném prostoru, dokud se klíč nevytvoří.
  4. Přidejte heslo, pokud chcete lokální ochranu pro soukromý klíč.
  5. Uložte si soukromý klíč na svém počítači a uchovávejte ho v tajnosti.
  6. Zkopírujte text veřejného klíče a vložte jej do pole SSH public key.

Nesdílejte tajná data

Neposílejte .ppk soubory, soukromé klíče, hesla ani tokeny do podpory nebo do formulářů.

> Přineste si vlastní doménu

Zjistěte, jak nasměrovat vaši vlastní doménu nebo subdoménu na službu CLIopen před aktivací funkce Přineste si vlastní doménu.
faq/pripojeni-vlastni-domeny

Co toto nastavení dělá

Funkce "Použijte vlastní doménu" umožňuje, aby vaše služba odpovídala na vašem vlastním hostname, např. app.example.com, namísto použití výchozího generovaného hostname *.co.cliopen.cloud. DNS záznamy musí směřovat na CLIopen, než bude možné bezpečně použít hostname ve službě.

Před začátkem

  1. Vyberte přesný název hostitele (hostname), který chcete použít, například app.example.com. Použití poddomény je nejjednodušší možnost.
  2. Přihlaste se do administrace DNS u registrátora domény nebo poskytovatele DNS.
  3. Odstraňte konfliktní záznamy typu A, AAAA, CNAME, ALIAS nebo přesměrování pro stejný název hostitele.
  4. Nechte vygenerovaný hostname CLIopen aktivní, dokud váš vlastní hostname nebude ověřen a plně funkční.

Doporučené nastavení DNS pro poddoménu

Vytvořte DNS záznamy pro přesný název hostitele, který zadáte v CLIopen. Pro app.example.com je DNS label app. Směřujte ho na adresy CLIopen ingress, které obdržíte od podpory CLIopen nebo v dokumentaci služby. Pokud váš poskytovatel vyžaduje typ záznamu, použijte záznam typu A pro IPv4 a záznam typu AAAA pro IPv6, pokud jsou tyto adresy k dispozici.

Příklad:

app.example.com.  A     <Adresa CLIopen IPv4>
app.example.com.  AAAA  <Adresa CLIopen IPv6, pokud je dostupná>

Když CLIopen poskytne cílovou adresu CNAME

Některé služby mohou poskytnout generované hostname, například service.customer.co.cliopen.cloud. Pokud instrukce pro vaši službu výslovně vyžadují použití záznamu CNAME, vytvořte záznam jako app.example.com CNAME service.customer.co.cliopen.cloud. Používejte záznamy CNAME pouze pro poddomény, nikoli pro hlavní/kořenové domény, pokud váš poskytovatel DNS nepodporuje funkce ALIAS nebo ANAME flattening.

Použití hlavní domény

Pro hlavní doménu, jako je example.com, většina poskytovatelů DNS nepovoluje standardní záznam CNAME. Použijte A/AAAA záznamy směřující na adresy CLIopen ingress nebo funkci ALIAS/ANAME vašeho poskytovatele, pokud vám CLIopen poskytl cílovou adresu.

Delegování celé podzóny

Pokud chcete, aby CLIopen spravoval záznamy v poddoméně, jako je apps.example.com, vytvořte NS záznamy pro tuto poddoménu a nasměrujte je na servery CLIopen, které obdržíte. Nezměňujte nameservery celé domény, pokud neplánujete záměrně přesunout správu všech záznamů do jiného systému.

Kontrolní seznam

  1. Počkejte na propagaci DNS. Menší změny jsou často viditelné během několika minut, ale někteří poskytovatelé je mohou dočasně ukládat (cache).
  2. Ujistěte se, že název hostitele směřuje na cílový server CLIopen a ne na starého poskytovatele.
  3. Do pole Bring your own domain zadejte přesnou doménu, bez `https://` a cesty.
  4. Po aktualizaci služby otestujte `https://app.example.com` ve svém prohlížeči.
  5. Staré DNS záznamy ponechte pouze v případě, že nekolidují s novou doménou.
> Jak přenést DNS zónu do CLIopen

Delegujte doménu na ns1.cliopen.com a ns2.cliopen.com, aby CLIopen publikoval záznamy pro celou zónu.
faq/predani-dns-zony

Co zde znamená přenos zóny

U zákaznického DNS přenosu se mění autoritativní nameservery u registrátora domény. Po delegování na CLIopen jsou záznamy DNS přidávané v CLIopen publikovány z našich autoritativních nameserverů.

Před změnou nameserverů

  1. Zkopírujte existující DNS záznamy, které stále potřebujete, například pro webové stránky, e-maily, ověření, SPF, DKIM, DMARC a servisní záznamy.
  2. Přidejte zónu v CLIopen DNS. Pokud delegace ještě není připravena, CLIopen ji uloží, ale neaktivuje pro zákazníky, dokud proběhne ověření.
  3. Pokud je to možné, vytvořte potřebné záznamy v CLIopen DNS ještě před změnou nameserverů.
  4. CAA záznam nastavujte opatrně, protože nesprávná hodnota může zablokovat vydání certifikátu.

Delegujte doménu

  1. Otevřete nastavení domény u vašeho registrátora, například example.com.
  2. Najděte položky Nameservers, DNS delegace nebo Nastavení autoritativního DNS.
  3. Nahraďte aktuální nameservry hodnotami ns1.cliopen.com a ns2.cliopen.com.
  4. Uložte změnu a počkejte na propagaci v registrech a resolverech.

Ověření

Vraťte se do CLIopen DNS a klikněte na „Znovu ověřit delegaci“. Pokud veřejné NS záznamy ukazují ns1.cliopen.com a ns2.cliopen.com, doména bude zařazena do synchronizace a záznamy budou aktivní prostřednictvím CLIopen.

> Registrace účtu a první přihlášení

Vytvořte jeden zákaznický účet pro objednávky, vyplňte platební údaje a používejte e-mailovou adresu, kterou váš tým bude mít v dohledu.
faq/account-registration-and-login

Jeden účet pro objednávky a správu

Používejte jeden účet pro objednávky, fakturační údaje, služby, domény a komunikaci s podporou. Nejvhodnější je firemní e-mailová adresa, ke které bude mít váš tým přístup i po personálních změnách.

Před první objednávkou

  1. Zaregistrujte se pomocí pracovní e-mailové adresy.
  2. Dokončete ověření e-mailu, pokud to webová stránka vyžaduje.
  3. Doplňte fakturační údaje před odesláním placené objednávky.
  4. Pokud bude dostupné dvoufaktorové ověření, aktivujte ho ihned po prvním přihlášení.

Přístup pro tým

Hesla neposílejte kolegům přes chat ani e-mail. Pokud k účtu potřebuje mít přístup více osob, používejte interní správce hesel nebo se obraťte na podporu s žádostí o doporučený postup pro týmy; podpora nepotřebuje vaše heslo ani přihlašovací tokeny.

> Měsíční odhad, roční odhad a reálná denní spotřeba

Měsíční a roční ceny slouží pro srovnání; u předplacených služeb se po potvrzení změny uplatňuje denní spotřeba.
faq/billing-periods-and-credit-burn

Porovnání není fakturační kalendář

Měsíční odhad používejte jako srovnání za 31 dní, roční odhad pak jako srovnání za 372 dní. Skutečné čerpání kreditu u předplacených služeb probíhá podle aktivního času služby a potvrzené konfigurace.

Co je třeba ověřit při změně ceny

  1. Porovnejte denní spotřebu před změnou a po změně.
  2. Vyšší výkon CPU, více RAM, větší disk nebo placené volby znamenají vyšší denní spotřebu.
  3. Změna se stane platnou až po potvrzení, případné platbě a aplikaci.
  4. Pro účetnictví si uložte potvrzení objednávky a historii kreditu.

Při řešení sporu uveďte konkrétní období.

Podpoře pomůže číslo objednávky, název služby a data, za která chcete čerpání prověřit. Neposílejte bankovní údaje ani screenshoty s nechtěnými osobními údaji.

> Stav objednávky po platbě

Objednávka může po zaplacení chvíli čekat na potvrzení od poskytovatele; duplikujte objednávku až poté, co bude původní jasně zrušena nebo vyprší.
faq/order-status-and-payment-confirmation

"Pending" nemusí znamenat selhání

Po návratu ze stránky platební brány může objednávka ještě čekat na potvrzení od poskytovatele plateb. Dokud stav není jednoznačně označen jako neúspěšný nebo vypršel, duplicitní objednávka může zbytečně komplikovat párování.

Postup po platbě

  1. Po dokončení platby se vraťte zpět do Cli>_.
  2. V účtu zkontrolujte stav objednávky a případnou zprávu u platby.
  3. Pokud objednávka stále čeká, dejte poskytovateli čas na potvrzení.
  4. Pokud máte problém, kontaktujte podporu a uveďte číslo objednávky a referenci platby, pokud ji vidíte.

Co neposílat

Podpora nepotřebuje údaje z platební karty, přihlašovací heslo ani celé bankovní potvrzení. Stačí číslo objednávky, čas platby, viditelný stav a screenshot s odstraněnými citlivými informacemi, pokud se zobrazuje chyba.

> Údaje, které urychlí nastavení služby

Připravte název služby, doménu, velikost úložiště, e-mail pro přístup a veřejný SSH klíč; citlivé údaje do formulářů nepatří.
faq/service-setup-information-needed

Přesné údaje vám ušetří čas

V objednávkových formulářích uvádějte pouze veřejně dostupné nebo nedůvěrné údaje: název služby, doménu, nastavení DNS, velikost úložiště, CPU, RAM, e-mail administrátora nebo veřejný SSH klíč. Hesla, soukromé klíče a tokeny by neměla být vkládána do formulářů.

Připravte si vše před kliknutím na objednávku

  1. Vyberte snadno rozpoznatelný název služby pro váš tým.
  2. Rozhodněte se, zda chcete použít vlastní doménu nebo dočasný systémový hostname.
  3. Připravte si veřejný SSH klíč, pokud jej služba vyžaduje.
  4. Zkontrolujte velikost úložiště a dostupné zdroje v závislosti na aplikaci, kterou chcete provozovat.

Citlivá data neodesílejte

Pokud si nejste jisti, zda je údaj citlivý, raději se zeptejte, než ho odešlete. Soukromé klíče, hesla, tokeny, databázové exporty a celé konfigurační soubory neposílejte do chatu ani do objednávky.

> Změna CPU, RAM, disku nebo doby uchování po objednání

Upravte stávající službu prostřednictvím jejího detailu, nikoli novou duplicitní objednávkou; změna zdroje může ovlivnit cenu služby, denní spotřebu kreditu, restart a riziko výpadku.
faq/change-service-resources-after-order

Upravujete existující službu?

Pokud už služba běží, změnu zdrojů provádějte z jejího detailu. Nová objednávka vytvoří další službu namísto úpravy stávající a může změnit cenu, denní spotřebu kreditu i provozní chování po potvrzení, zaplacení a aplikaci změny.

Před potvrzením změny

  1. Zkontrolujte aktuální využití CPU, RAM, disku, zálohy a retenci Offsite Archive.
  2. Zkontrolujte novou denní cenu a její vliv na kredit.
  3. Přečtěte si upozornění týkající se restartu, údržby nebo výpadku.
  4. Před provedením rizikové změny si vytvořte vlastní zálohu důležitých dat.

Co dělat, když změna proběhne jinak, než jste očekávali

Zašlete název služby, čas změny, viditelný stav a chybovou zprávu. Neposílejte soukromé klíče, hesla ani tokeny; pro diagnostiku stačí veřejný kontext a screenshot se zakrytými citlivými informacemi.

> Zrušení služby a doba uchovávání dat

Zrušená služba je nejprve dočasně pozastavena, poté se zobrazí nastavitelný termín smazání dat a až následně může proběhnout trvalé vyčištění.
faq/cancel-service-and-data-retention

Zrušení není vždy okamžité smazání

U již zřízené služby se služba nejprve pozastaví a zobrazí nastavitelný termín smazání, do kterého lze řešit obnovení nebo export. Nezaplacené čekající objednávky bez běžících dat se mohou chovat jinak.

Před zrušením si ověřte

  1. Vytvořte si vlastní export dat, která potřebujete dlouhodobě uchovávat.
  2. Přečtěte si datum a čas plánovaného smazání u pozastavené služby.
  3. Nezaměňujte zálohy a Offsite Archive se smazáním v životním cyklu služby.
  4. Pokud si nejste jisti, kontaktujte podporu ještě před termínem smazání.

Obnova po uplynutí lhůty nemusí být možná

Po uplynutí viditelného termínu se s daty nepočítejte jako s dostupnými. Při dotazu zašlete číslo objednávky a název služby, nikoli databázové exporty ani tajné přihlašovací údaje.

> Zálohy a žádosti o obnovu

Zálohy slouží k provozní obnově, nikoli jako náhrada za export. Obnova může přepsat novější data.
faq/backups-and-restore-requests

Zálohování není archív ani export

Doba uchovávání záloh závisí na zvoleném produktu a nastavených možnostech. Záloha slouží k obnově provozu v případě chyby, ale nenahrazuje vlastní export, auditní archiv ani Offsite Archive. Obnova může přepsat novější změny.

Jak připravit žádost o obnovu

  1. Uveďte název služby a číslo objednávky.
  2. Popište přibližný čas, ke kterému chcete obnovit data.
  3. Napište, zda má být obnovena celá služba nebo pouze její část, pokud je to možné.
  4. Přiložte viditelnou chybu nebo kontext bez hesel, tokenů a soukromých klíčů.

Před obnovou zvažte dopady

Pokud služba mezitím přijala nová data, obnova je může nahradit starším stavem. Před potvrzením obnovy informujte tým a proveďte export všeho, co nechcete ztratit.

> K čemu slouží Offsite Archive

Offsite Archive uchovává vzdálené archivní kopie odděleně od krátkodobých provozních záloh a životního cyklu služby.
faq/offsite-archive-purpose

Archiv mimo běžný provoz

Offsite Archive je určen pro vzdálené archivní kopie a delší uchovávání dat. Není to živý disk pro aplikaci, náhrada lokálního exportu ani totéž co krátkodobé operační zálohy.

Kdy ho zapnout

  1. Použijte jej pro data, která chcete uchovávat i mimo běžný provoz služby.
  2. Vyberte si dobu uchování dat podle požadavků na dodržování předpisů, obchodních potřeb nebo cílů obnovy.
  3. Sledujte, jak cena roste v závislosti na uloženém objemu a době uchovávání.
  4. U velkých dat plánujte archivaci společně s vlastním exportním procesem.

Jak přemýšlet o ceně

Základ tvoří MB-dny: kolik dat je uloženo a jak dlouho jsou uchovávána. Cena se zákazníkovi zobrazuje jako EUR/GB/měsíc a výsledek se zaokrouhluje na celé centy.

> Výběr CPU, RAM a disku pro VPS

Velikost VPS volte podle aplikace, databáze, mezipaměti, logů a očekávaného růstu. Pokud dochází k přetížení paměti (OOM) nebo se používá swapování, je to signál, že potřebujete více RAM.
faq/vps-cpu-ram-and-disk-sizing

Začněte podle reálné zátěže

Malá statická webová stránka má jiné potřeby než databáze, Java aplikace, vyhledávání nebo kontejner s buildy. Při plánování počítejte s aplikační pamětí, cache, databází, logy, uploady a rezervou pro růst.

Signály, že plán je malý

  1. Zvyšte paměť RAM v případě chyb OOM (out of memory), ukončení procesů nebo častého používání swapu.
  2. Zvyšte výkon CPU při dlouhodobé vysoké výpočetní zátěži, kompresi dat, sestavování softwaru nebo vytížených pracovních procesech.
  3. Zvětšete velikost disku dříve, než bude souborový systém, logy nebo databáze plné.
  4. Po každé změně sledujte, zda aplikace přestala narážet na původní limit.

Co sdělit při dotazu ohledně nastavení parametrů

Pomůže název služby, typ aplikace, viditelná chyba, přibližný čas problému a aktuálně zvolené CPU, RAM a disk. Neposílejte hesla, soukromé klíče ani interní konfigurační soubory.

> Kdy má smysl mít veřejnou IP adresu pro VPS

Vyhrazená veřejná IP adresa je užitečná pro seznamy povolených adres (allowlist), přístup zvenčí, stabilní zdroj pro odchozí provoz nebo služby vázané na konkrétní adresu.
faq/vps-public-ip-options

Nejprve zjistěte směr komunikace

Veřejná IP adresa není automaticky nutná pro každou službu. Nejčastěji řeší požadavky externích partnerů, poskytovatelů nebo firewallů na allowlist, stabilní zdroj pro odchozí provoz nebo přístup do konkrétního portu.

Otázky před objednáním IP

  1. Zeptejte se partnera, zda povoluje provoz z/do sítě (inbound), provoz do sítě (outbound) nebo oba směry.
  2. Používejte DNS názvy namísto číselných IP adres, kde je to možné.
  3. Otevírejte pouze porty, které aplikace skutečně potřebuje.
  4. Požadavek na allowlist zašlete podpoře dříve, než změníte produkční přístup.

Co je dobré nechat vypnuté

Veřejná IP adresa neznamená otevření všech portů. Přístup navrhujte pouze pro minimálně potřebné služby a neposílejte hesla, soukromé klíče ani interní pravidla firewallu jako snímky obrazovky s utajovanými údaji.

> Sdílený SSH přístup pro VPS

Bez zakoupené veřejné IP adresy se VPS připojuje přes sdílený SSH endpoint s vysokým portem; při zakoupené veřejné IP adrese bude k dispozici i přímé SSH připojení na této adrese.
faq/shared-ssh-access-for-vps

Proč sdílené SSH používá vysoký port

Více VPS služeb může sdílet stejný veřejný SSH endpoint, proto každá služba obdrží vlastní vysoký port. Port je součástí směrování k vaší službě; bez něj by se připojení nedalo jednoznačně doručit na správnou VPS.

Jak se připojovat podle typu přístupu

  1. Při použití sdíleného SSH zkopírujte uživatelské jméno, hostitele a port přesně tak, jak jsou uvedeny.
  2. Připojte se pomocí příkazu ssh -p <port> <uživatelské_jméno>@<veřejný_hostitel> z vašeho lokálního terminálu.
  3. Pokud služba má zakoupenou veřejnou IP adresu, může mít i druhý SSH endpoint přímo na této adrese nebo její DNS doméně podle nastavení služby.
  4. Soukromý klíč používejte pouze lokálně prostřednictvím vašeho SSH klienta nebo agenta; do podpory uveďte pouze veřejný host, port, uživatelské jméno a viditelnou chybu.

Když máte zakoupenou veřejnou IP adresu

Veřejná IP nenahrazuje sdílený SSH endpoint; přidává samostatný způsob přístupu vhodný pro allowlisty, monitorování nebo přímé připojení. V praxi můžete tedy vidět dva způsoby připojení přes SSH: sdílený host s vysokým portem a přímý host nebo IP adresa pro službu s veřejnou IP adresou.

> Kontrola před připojením vlastní domény

Před přepnutím domény ověřte autoritativní DNS servery, přesný hostname, typ záznamu (A, CNAME, atd.), zda se jedná o hlavní doménu nebo subdoménu a případné konfliktní staré záznamy.
faq/custom-domain-readiness-checklist

Rozhodující je přesná doména

Nejprve si ujasněte, zda připojujete hlavní doménu (např. example.com) nebo subdoménu (např. app.example.com). Každá varianta může vyžadovat jiný typ DNS záznamu a různá omezení poskytovatele DNS.

Před změnou DNS

  1. Ověřte, kde se upravují autoritativní DNS záznamy pro doménu.
  2. Odstraňte nebo upravte konfliktní A/AAAA, CNAME, ALIAS, ANAME nebo redirect záznamy.
  3. Použijte typ záznamu doporučený pro danou službu a hostname.
  4. Po změně počkejte na propagaci DNS a až poté otestujte finální HTTPS.

Bezpečný návrat ke starší verzi

Nevypínejte původní hosting, dokud nový hostname neodpovídá správně. Při řešení problémů uveďte doménu, očekávaný cíl a veřejně viditelný výsledek DNS, nikoli přístupy k registrátorovi.

> Typy DNS záznamů pro služby

Záznamy A/AAAA odkazují na IP adresy, CNAME slouží jako alias, MX se používá pro poštovní servery a TXT záznamy se využívají pro ověření, SPF, DKIM nebo DMARC.
faq/dns-record-types-for-services

Nekombinujte záznamy naslepo

Každý typ DNS záznamu řeší jiný úkol. Záznamy A a AAAA ukazují na IP adresy, CNAME vytváří alias pro subdoménu, MX směruje poštu, TXT nese ověření a e-mailové politiky, CAA omezuje certifikační autority.

Při kopírování záznamů

  1. Zkopírujte název, typ a hodnotu přesně podle instrukcí služby.
  2. Používejte A/AAAA pro adresy, CNAME pro povolené aliasy poddomén, MX pro e-mail a TXT pro SPF, DKIM, DMARC nebo ověření.
  3. Umístěte DKIM pod selektor poskytovatele a DMARC typicky pod _dmarc.
  4. CAA nastavujte opatrně, protože nesprávná hodnota může zablokovat vystavení certifikátu.

Když DNS nefunguje

Podpoře zašlete hostname, typ záznamu, očekávanou hodnotu a veřejně viditelný výsledek. Neposílejte přihlašovací údaje do DNS administrace ani screenshoty s API tokeny.

> Propagace DNS a TTL: Bez záruky rychlosti

TTL (Time To Live) určuje, jak dlouho mohou resolvery uchovávat starou odpověď. Během přechodu se mohou vedle sebe vyskytovat staré i nové výsledky.
faq/dns-propagation-and-ttl

Propagace je cache, ne magie

U DNS neexistuje pevný slib ohledně přesného času propagace. Různé resolvry mohou vracet staré i nové odpovědi, dokud jim nevyprší mezipaměť (TTL), a to i poté, co byla změněna autoritativní záznam.

Při plánované změně

  1. Pokud to poskytovatel dovolí, snižte TTL ještě před plánovanou změnou.
  2. Po úpravě DNS nedělejte opakované náhodné změny, dokud nevyprší mezipaměť.
  3. Otestujte z více resolverů, pokud se výsledky liší.
  4. Zapište si čas změny, původní hodnotu, novou hodnotu a TTL.

Co poslat při diagnostice

Uveďte hostname, očekávaný cíl, zobrazenou starou odpověď, zobrazenou novou odpověď, TTL a čas změny. Neposílejte přihlašovací údaje k DNS účtu ani interní poznámky poskytovatele.

> Plánování úložného prostoru pro Workspace Suite

Při plánování kapacity zvažte soubory uživatelů, sdílené složky, verze, koš, náhledy, režii synchronizace a očekávaný růst týmu.
faq/nextcloud-storage-planning

Workspace Suite roste i mimo viditelné soubory

Kapacitu spotřebovávají uživatelské soubory, sdílené složky, smazané soubory, verzování, náhledy, miniaturky, synchronizační klienti a importy. Pokud se úložiště blíží limitu, mohou selhávat nahrávání nebo synchronizace.

Před objednáním kapacity

  1. Sečtěte aktuální data uživatelů a sdílené složky.
  2. Přidejte rezervu pro verze, koš, náhledy a režii synchronizace.
  3. Zohledněte velké importy, nové týmy a očekávaný růst.
  4. Zvyšte kapacitu dříve, než uživatelé narazí na limit.

Při problémech se synchronizací

Pošlete velikost služby, přibližné využití, čas problému a viditelnou chybu klienta. Neposílejte osobní soubory, hesla ani exporty uživatelských dat, pokud si je podpora výslovně nevyžádá bezpečným způsobem.

> Migrace repozitářů do Gitea

Plánujte migraci repozitářů do Gitea včetně Git LFS, submodule, chráněných větví a tagů, deploy klíčů, tokenů, webhooků, CI/CD a testování klonování a odesílání.
faq/gitea-repository-migration

Migrace není jen `git clone`

Kromě historie repozitáře je nutné přenést nebo znovu nastavit vlastníky, týmy, chráněné větve, chráněné tagy, Git LFS, submoduly, klíče pro nasazení, webhooky a CI/CD propojení.

Kontrola před cutoverem

  1. Zahrnuje repozitáře, vlastníky, spolupracovníky, objekty Git LFS, moduly, chráněné větve a značky a účty pro automatizaci.
  2. Ověřte objekty Git LFS, moduly, ochranu větví a značek.
  3. Po migraci otestujte klonování, nahrávání, Git LFS, moduly a běh CI.
  4. Staré přístupové údaje po migraci zrušte nebo bezpečně změňte, přičemž neposkytujte jejich hodnoty.

Citlivá data při migraci

Do podpory neposílejte soukromé klíče, privátní část klíčů pro nasazení ani citlivá data CI. Sdělte pouze názvy repozitářů, typ integrace, viditelné chyby a informace o tom, co fungovalo před migrací.

> Odesílací doména pro Listmonk

Při přípravě kampaní si vytvořte odesílací doménu nebo subdoménu, nastavte identitu 'From', SPF, DKIM, DMARC, zpracování odchozích zpráv a nastavení pro odhlášení odběru.
faq/listmonk-sender-domain-basics

Doručitelnost začíná u domény

Listmonk potřebuje jasnou identitu odesílatele a DNS záznamy, které poštovní systém dokáže ověřit. SPF, DKIM a DMARC musí být správně nastaveny pro doménu nebo subdoménu, ze které chcete zasílat kampaně.

Před první kampaní

  1. Vyberte doménu nebo subdoménu pro odesílání e-mailů a nastavte identitu 'From'.
  2. Přidejte ověřovací DNS záznamy, SPF, DKIM selektor a DMARC.
  3. Otestujte doručení, chybové zprávy (bounces) nebo adresu Return-Path a odkazy ve zprávě.
  4. Zkontrolujte nastavení odhlášení a List-Unsubscribe před odesláním ostré verze.

Citlivé údaje související s emaily nepatří do ticketu.

Při diagnostice uveďte doménu, typ záznamu, veřejně dostupnou hodnotu DNS a chybovou hlášku. Neposílejte hesla SMTP, API tokeny, soukromý DKIM klíč ani export adresářů s osobními údaji.

> Nastavení běhového prostředí pro Classic Hosting

Classic Hosting může běžet v automatickém nebo manuálním režimu. Výkonnostní parametry jako CPU, RAM, paměť, úložiště, doba uchovávání záloh, Offsite Archive, nahrávání souborů, cache a logy ovlivňují cenu i stabilitu.
faq/classic-hosting-runtime-settings

Automatický režim nemusí být vždy správná volba

Funkce Auto Runtime pomáhá s rozpoznanými projekty, ale manuální režim je vhodný, pokud chcete přesně vybrat Nginx, Apache, FrankenPHP nebo konkrétní jazykový runtime. PHP selector používejte pouze tam, kde jej zvolený runtime podporuje.

Nastavení před nasazením

  1. Vyberte automatický režim pro detekované sestavení nebo manuální režim pro kontrolu runtime Nginx, Apache nebo FrankenPHP.
  2. Zvolte PHP 8.2/8.3/8.4 pouze tam, kde vybraný runtime tuto možnost podporuje.
  3. Nastavte CPU, RAM, paměť, úložiště, retenci záloh a retenci Offsite Archive podle provozu a dat.
  4. Po nasazení otestujte nahrávání souborů, cache, protokoly a viditelné aplikační chyby.

Když aplikace nespustí

Zašlete informace o režimu běhu, jazyku nebo verzi PHP, zobrazenou chybu, změny a přibližný čas nasazení. Neposílejte soubory .env, hesla, tokeny ani celé protokoly obsahující citlivá data.

> Jaké informace je bezpečné zaslat podpoře?

Nejužitečnější jsou čísla objednávek, názvy služeb, domény, časová razítka, veřejné servery, porty, nastavení zálohování, retence Offsite Archive, nahrávání souborů, cache, logy, screenshoty a viditelné chyby bez citlivých údajů.
faq/support-safe-information-to-share

Kvalitní žádost obsahuje relevantní informace, nikoli utajené údaje.

Technická podpora může rychleji reagovat, pokud obdrží číslo objednávky, název služby, doménu, veřejný host nebo port, čas výskytu problému, informace o provedených změnách a přesné zobrazené chybové hlášení.

Bezpečný obsah zprávy

  1. Uveďte číslo objednávky, název služby, doménu, přibližný čas a relevantní veřejný host nebo port.
  2. Při problémech s hostingem uveďte režim runtime, jazyk nebo verzi PHP, CPU, RAM, úložiště, dobu uchovávání záloh, dobu uchovávání Offsite Archive, uploady, cache a logy, a také jakékoli nedávné změny.
  3. Před odesláním screenshotů skryjte hesla, tokeny, soukromé klíče, relace a osobní údaje.
  4. Pokud si nejste jisti, zda údaj patří do ticketu, nejdříve se zeptejte bez jeho odeslání.

Co nikdy neposílejte

Neposílejte hesla, soukromé klíče, recovery seedy, API tokeny, session cookies, databázové exporty, celé .env soubory, kompletní logy s citlivými hodnotami ani interní infrastrukturní detaily.