GYIK

Gyakori kérdések

Hasznos, rövid útmutatók a szolgáltatások beállításához, hozzáféréshez és az ügyfelek által végzett gyakori műveletekhez.

> Hogyan működik a Cli>_ kreditrendszere?

Egy közös előre fizetett egyenleg finanszírozza az összes jogosult szolgáltatást, és csak aktív működés közben fogy.
faq/prepaid-credit-how-it-works

A Cli>_ fiókodhoz egy közös előre fizetett kreditegyenleg tartozik. A jogosult új ügyfelek csak a kötelező fiók- és visszaélés-megelőzési ellenőrzés elvégzése után igényelhetik a Starter Credit jóváírást. Az aktív jogosult szolgáltatások időarányosan fogyasztják az egyenleget. A havi becslés 31 nappal számol, új szolgáltatás pedig csak akkor indulhat, ha az egyenleg legalább 7 napot fedez. Piros figyelmeztetés akkor jelenik meg, amikor a becsült üzemidő 7 nap alá csökken; egyébként narancssárga figyelmeztetés jelenik meg, amikor 14 nap alá csökken.

Az egyenleg elfogyása után a szolgáltatást 7 nap elteltével felfüggesztik, megszűnik a kreditfogyasztás, és elindul a 7 napos megőrzési és törlési határidő. A kijelzett határidő előtt elegendő kredittel újraindítható. Egy kiépített szolgáltatás lemondása szintén felfüggeszti azt, és elindítja ugyanezt a határidőt. Egy függőben lévő, még ki nem épített szolgáltatás azonnal inaktiválható. A határidő után megkezdődik a kiépített szolgáltatás inaktiválása és eltávolítása. A Force delete azonnal inaktiválja a szolgáltatást, kihagyja a megőrzést és elindítja az eltávolítást az aktív runtime-ból; a befejezés a deployment- és GitOps-feldolgozás után történik. A biztonsági mentésekre és az Offsite Archive-ra külön megőrzés vonatkozik.

OpenCode példa 9,90 EUR áron: 9,90 / 31 ≈ 0,319 EUR naponta. 10 teljes nap után körülbelül 3,19 EUR fogy el. Pontosan 9,90 EUR kezdőegyenleg és más szolgáltatás nélkül körülbelül 6,71 EUR marad. Letiltás után a további fogyás megszűnik.

A példa szemléltető jellegű. Mindig a Cli>_-ban aktuálisan megjelenített árak érvényesek.

> Hogyan generáljunk nyilvános SSH-kulcsot a parancssorban

Hozzon létre egy nyilvános SSH-kulcsot a VPS-hez való biztonságos hozzáférés érdekében. Oszd meg csak a nyilvános kulcsot a Cli>_ szolgáltatással; a privát kulcsot tartsd a saját készülékeden.
faq/generate-public-ssh-key-hu

A nyilvános kulcs megosztható, a magánkulcs nálad marad

Csak a nyilvános SSH kulcsot add meg a rendelés során vagy a szolgáltatás beállításakor. A magánkulcs a számítógépeden marad, és nem kerül továbbításra a támogatásnak, sem pedig webes űrlapba.

Lépések

  1. Nyisson meg egy terminált a számítógépén.
  2. Futtassa a következő parancsot: ssh-keygen -t ed25519 -C "your-email@example.com".
  3. Erősítse meg a fájl helyét, vagy válasszon egy saját útvonalat. Soha ne küldje el a privát kulcsát senkinek.
  4. A nyilvános kulcs megjelenítéséhez futtassa a következő parancsot: cat ~/.ssh/id_ed25519.pub.
  5. Másolja ki az ssh-ed25519-rel kezdődő teljes sort, és illessze be az SSH nyilvános kulcs mezőbe a megrendelés vagy szolgáltatás beállítása során.
  6. Másolja ki a teljes ssh-ed25519 sort, és illessze be az "SSH Public Key" mezőbe.

Ellenőrizd beillesztés előtt

  1. Nyissa meg a PowerShellt vagy a Windows Terminált.
  2. Futtassa a következő parancsot: ssh-keygen -t ed25519 -C "a_te_e_mail_címe@example.com".
  3. Nyomja meg az Enter billentyűt a kulcs C:\Users\a_felhasználó_név\.ssh\id_ed25519 helyre történő mentéséhez, vagy adja meg saját elérési útvonalat.
  4. Ha a Windows jelszót kér, használjon egy olyan jelszót, amelyet biztonságosan tárolhat, vagy nyomja meg az Enter billentyűt a jelszó nélküli egyszerű beállítás érdekében.
  5. A nyilvános kulcs megjelenítéséhez használja a következő parancsot: Get-Content $env:USERPROFILE\.ssh\id_ed25519.pub.
  6. Másolja ki kizárólag az 'ssh-ed25519' szóval kezdődő teljes sort. Ne másolja át és ne töltse fel a privát kulcsfájlt.
> Hogyan hozhatunk létre SSH-kulcsot grafikus felületen a Windows alatt?

Grafikus útmutató a Windows alatt futó SSH-kulcspár létrehozásához parancssor nélkül.
faq/create-ssh-key-windows-gui-hu

Használjon Windows-programot, és csak a nyilvános kulcsot másolja be

Az SSH kulcspárt grafikus felületen is létrehozhatja egy Windows SSH klienssel, például a PuTTYgen segítségével. A Cli>_ rendszernek csak a nyilvános kulcs szükséges. A privát kulcsmegfelelést tartsa meg számítógépén, és ne töltse fel webes űrlapon.

Eljárás

  1. Telepítse a PuTTY-t, vagy nyissa meg a PuTTYgen alkalmazást, ha már telepítve van.
  2. Válassza az EdDSA/Ed25519 opciót, ha elérhető, különben válassza az RSA 4096-ot.
  3. Kattintson a Generate gombra, és mozgassa az egér kurzorát a szabad területen, amíg meg nem jelenik a kulcs.
  4. Adjon meg egy jelszót, ha helyi védelemhez szeretné használni a privát kulcsot.
  5. Tárolja a privát kulcsot a számítógépén, és tartsa titokban.
  6. Másolja ki a nyilvános kulcs szövegét, és illessze be az SSH nyilvános kulcs mezőbe a Cli>_ alkalmazásban.

Ne osszon meg titkos adatokat

Ne küldjön .ppk fájlokat, privát kulcsokat, jelszavakat vagy tokeneket a támogatási szolgálatnak, sem pedig űrlapon keresztül.

> Hozza saját domainjét

Tudjon meg többet arról, hogyan irányíthatja saját domainjét vagy altartományát egy CLIopen szolgáltatáshoz, mielőtt aktiválná a saját domain funkciót.
faq/sajat-domain-csatlakoztatasa

Mit csinál ez a beállítás?

A saját domain használata lehetővé teszi, hogy a szolgáltatás a saját hostname-jén keresztül érhető legyen (pl. app.example.com), ahelyett, hogy csak a generált *.co.cliopen.cloud hostname-t használná. A DNS beállításoknak a CLIopen felé kell mutatniuk, mielőtt a hostname biztonságosan használható lenne a szolgáltatásban.

Elkezdés előtt

  1. Válassza ki a pontosan használni kívánt hosztnevet, például: app.example.com. A legegyszerűbb megoldás egy altartomány használata.
  2. Nyissa meg a DNS beállításokat a domainregisztrátornál vagy a DNS szolgáltatónál.
  3. Törölje az összes konfliktusos A, AAAA, CNAME, ALIAS vagy átirányítási bejegyzést ugyanahhoz a hosztnévhez.
  4. Tartsa aktívnak a generált CLIopen hostnevet, amíg az Ön által beállított hostnév nem ellenőrizhető és teljesen működőképes.

Ajánlott DNS beállítások egy alkönyvtár számára

Hozzon létre DNS-bejegyzéseket az Ön által a CLIopenben megadott pontos hostnévhez. A app.example.com esetén a DNS címke a app. Irányítsa ezt a CLIopen bejárati címekre, amelyeket a CLIopen támogatása biztosít, vagy a szolgáltatás dokumentációjában találja. Ha a szolgáltató kér egy rekordtípust, használjon A rekordot IPv4-hez és AAAA rekordot IPv6-hoz, ha ezeket a címeket megkapta.

Példa:

app.example.com.  A     <CLIopen IPv4 cím>
app.example.com.  AAAA  <CLIopen IPv6 cím, amennyiben rendelkezésre áll>

Amikor a CLIopen CNAME célt biztosít

Egyes szolgáltatások generált hosztnevet adnak meg, például service.customer.co.cliopen.cloud. Ha a szolgáltatás használati útmutatója kifejezetten CNAME-et igényel, hozzon létre egy bejegyzést, például: app.example.com CNAME service.customer.co.cliopen.cloud. Csak alkönyvtárakhoz használjon CNAME-et, nem pedig a fő/gyökér domainhez, kivéve, ha a DNS szolgáltatója támogatja az ALIAS vagy ANAME leegyszerűsítést.

A gyökérdomain használata

Ha egy example.com szerű domainhez nincs aldomén hozzáadva, a legtöbb DNS-szolgáltató nem engedélyezi a standard CNAME beállítását. Használjon A/AAAA rekordokat a CLIopen bejövő címekre mutatóan, vagy használja a szolgáltató ALIAS/ANAME funkcióját, ha a CLIopen egy célhostname-t adott meg.

Egy teljes aldomén delegálása

Ha szeretné, hogy a CLIopen kezelje az apps.example.com szerű aldomének rekordjait, hozzon létre NS (névszolgáltató) rekordokat az adott aldomén számára, amelyek a kapott CLIopen névszolgáltatókhoz mutatnak. Ne változtassa meg a teljes domain névszolgáltatóit, hacsak nem szeretné, hogy a CLIopen (vagy más DNS-szolgáltatás) kezelje minden rekordot.

Ellenőrzési lista

  1. Várja meg a DNS propagáció befejezését. A kisebb változások gyakran néhány perc alatt láthatóvá válnak, de egyes szolgáltatók hosszabb ideig tárolják az adatokat a gyorsítótárban.
  2. Ellenőrizze, hogy a hostname a CLIopen célpontra mutat-e, és nem egy korábbi szolgáltatóra.
  3. A "Saját domain" mezőbe adja meg a pontos hosztnevet, `https://` nélkül és könyvtárutvonal nélkül.
  4. A szolgáltatás frissítése után tesztelje a `https://app.example.com` címet a böngészőjében.
  5. Tartsa meg a régi DNS-bejegyzéseket csak akkor, ha azok nem ütköznek az új hosztnévvel.
> Hogyan migrálhatjuk át egy DNS-zónát a CLIopen rendszerbe?

Delegálja a domént az ns1.cliopen.com és az ns2.cliopen.com címekre, hogy a CLIopen közzétehesse a teljes zóna bejegyzéseit.
faq/dns-zona-atadasa

Mit jelent itt a zónaátvitel?

Az ügyfél által használt DNS-szolgáltatás esetén a zónaátvétel azt jelenti, hogy meg kell változtatni az autoritatív nameszervereket a domain regisztrátoránál. A CLIopen felé történő delegálás után a CLIopenben hozzáadott DNS-rekordok a mi autoritatív nameszervereinkről kerülnek publikálásra.

Névserversorok módosítása előtt

  1. Másolja át a meglévő DNS-rekordokat, amelyekre továbbra is szüksége van, például weboldal, e-mail, ellenőrzés, SPF, DKIM, DMARC és szolgáltatási rekordok.
  2. Adjon hozzá egy zónát a CLIopen DNS rendszerben. Ha a delegálás még nem áll készen, a CLIopen elmenti azt, de nem aktiválja ügyfelek számára, amíg a validáció sikeresen lezárul.
  3. Ha lehetséges, hozzon létre a szükséges bejegyzéseket a CLIopen DNS rendszerben a nameszerverek váltása előtt.
  4. Ügyeljen arra, hogy a CAA bejegyzést helyesen konfigurálja, mivel a helytelen értékek megakadályozhatják a tanúsítványok kiállítását.

Zónadelegálás

  1. Nyissa meg a tartomány beállításait a regisztrátornál, például az example.com oldalon.
  2. Keresse meg a nameszerverek, a DNS delegálás vagy a hatósági DNS beállításai között.
  3. Cserélje ki a jelenlegi nameszervereket a ns1.cliopen.com és a ns2.cliopen.com értékekre.
  4. Mentse el a módosítást, és várja a regisztrár és a resolverek által végzett propagációt.

Érvényesítés

Visszatérjen a CLIopen DNS-hez, és kattintson az Újraellenőrizni kívánt delegálásra. Amikor a nyilvános NS rekordok ns1.cliopen.com és ns2.cliopen.com-ot mutatnak, a zóna bekerül a szinkronizációs sorba, és a rekordok a CLIopen-ből válnak aktívvá.

> Fiókregisztráció és első bejelentkezés

Hozzon létre egyetlen felhasználói fiókot rendelésekhez, számlázáshoz és szolgáltatások kezeléséhez. Használjon olyan e-mail címet, amelyhez a csapatának hozzáférése van.
faq/account-registration-and-login

Egy fiók mindenhez: rendelések és ügyfélszolgálat

Használja a fiókot hosszú távú helyként rendelésekhez, számlázási adatokhoz, szolgáltatásokhoz, domainekhez és az ügyfélszolgálattal való kommunikációhoz. A legjobb egy munkahelyi e-mail címet használni, amelyhez a csapat hozzáféréssel rendelkezhet személyzet változásai után is.

Első rendelés előtt

  1. Regisztráljon munkahelyi e-mail címmel.
  2. Ha a weboldal ezt kéri, fejezze be az e-mail megerősítést.
  3. Add meg a számlázási adatokat, mielőtt fizetett rendelést küld el.
  4. Amikor elérhetővé válik a kétfaktoros hitelesítés, aktiválja azt az első bejelentkezés után.

Csapat számára készült hozzáférés

Ne küldje el a jelszavát kollégáknak chat vagy e-mail úton. Ha több embernek is szüksége van hozzáférésre, használjon belső jelszókezelőt, vagy kérjen ajánlott csapatmunkafolyamatot; a támogatási csapatnak nincs szüksége a jelszavára vagy a bejelentkezési tokenjére.

> Havi becslés, éves becslés és tényleges napi felhasználás

A havi és az éves árak összehasonlítási célokat szolgálnak; előre fizetett szolgáltatások esetén a napi fogyasztás számít a módosítás jóváhagyása után.
faq/billing-periods-and-credit-burn

A táblázat nem egy számlázási naptár

Használja a havi becsléseket 31 napos, az éves becsléseket pedig 372 napos referenciaértéknek. A előre fizetett szolgáltatásoknál a kredit felhasználása a ténylegesen használt időtartam és a beállított konfiguráció alapján történik.

Mit érdemes ellenőrizni az ár módosításakor

  1. Hasonlítsa össze a napi fogyasztást a változtatás előtt és után.
  2. Ha magasabb CPU-erőforrást, RAM-ot, meghajtót vagy fizetős szolgáltatásokat választasz, számíts nagyobb napi fogyasztásra.
  3. A módosítás csak akkor lép érvénybe, ha azt megerősíted, esetleg kifizeted, és alkalmazzuk.
  4. A könyveléshez mentsd el a rendelési visszaigazolást és a kreditelőzményeket.

Viták esetén konkrét időszakokra fókuszáljon

A támogatási csapat számára hasznos lehet a rendelési szám, a szolgáltatás neve és azoknak a dátumoknak a megadása, amelyekre vonatkozóan szeretnéd ellenőrizni a felhasználást. Ne küldj bankszámlaszámokat, teljes fizetési kimutatásokat vagy olyan képernyőképeket, amelyeken nem kívánt személyes adatok szerepelnek.

> A megrendelés állapota fizetés után

A rendelésnek lehet időbe telnie a szolgáltató által történő visszaigazolásig a fizetés után; csak akkor hozzon létre duplikáltat, ha az első egyértelműen törölve vagy lejárt.
faq/order-status-and-payment-confirmation

A "felfüggesztett" állapot nem feltétlenül jelent hibát

A fizetési oldalon való távozás után a rendelés még várakozhat a fizető rendszer szolgáltatója által történő jóváhagyására. Amíg az állapot egyértelműen sikertelen vagy lejárt, addig egy új, duplikált rendelés feleslegesen bonyolulttá teheti a párosítást.

Mit kell tennie a fizetés után

  1. A fizetés befejezése után térjen vissza a Cli>_ oldalra.
  2. Ellenőrizze a fiókjában a megrendelés állapotát és esetleges üzenetet a fizetéssel kapcsolatban.
  3. Ha a megrendelés még mindig várakozó állapotban van, hagyjon időt a szolgáltató számára a visszaigazolásra.
  4. Ha problémája van, küldje el a supportnak a rendelési számot és a fizetési tranzakció azonosítóját, amennyiben látja azt.

Mit ne küldjön

A támogatási csapatnak nem szükségesek a bankkártya adatai, a bejelentkezési jelszavak vagy a teljes bankszámlai kivonat. Elég a rendelési szám, a fizetés időpontja, a látható állapot és egy elmaszkolt képernyőképe, ha hibaüzenet jelenik meg.

> Azok az adatok, amelyek felgyorsítják a szolgáltatás beállítását

Készítsen elő egy szolgáltatási nevet, domént, tárhelyméretet, hozzáférési e-mail címet és nyilvános SSH kulcsot; a titkos adatokat nem szabad az űrlapokba írni.
faq/service-setup-information-needed

A pontos adatok időt takarítanak meg

Használja a rendelési űrlapokat nyilvános vagy nem titkos értékekhez: szolgáltatásnév, domain, DNS beállítások, tárhelyméret, CPU, RAM, admin e-mail cím vagy nyilvános SSH kulcs. Jelszavak, privát kulcsok és tokenek ne kerüljenek az űrlapokba.

Készülj fel a megrendelés elküldése előtt

  1. Válasszon egy könnyen felismerhető nevet a szolgáltatásnak a csapatod számára.
  2. Döntse el, hogy saját domént használ-e vagy ideiglenes rendszernevet.
  3. Készítsen elő nyilvános SSH kulcsot, ha a szolgáltatás ezt igényli.
  4. Ellenőrizd az adattároló méretét és az erőforrásokat az alkalmazásodhoz szükségesek szerint.

Fontos figyelmeztetés

Ha bizonytalan vagy abban, hogy egy információ bizalmas-e, inkább kérdezz meg, mielőtt elküldenéd. Ne küldj privát kulcsokat, jelszavakat, tokeneket, adatbázis mentéseket és teljes konfigurációs fájlokat a chatben vagy a megrendelésben.

> A CPU, RAM, meghajtó vagy tárhely módosítása rendelés után

A meglévő szolgáltatást a részletei alatt kell módosítani, nem új megrendeléssel. Az erőforrások változtatása befolyásolhatja az árat, a napi kreditfelhasználást és újraindítást igényelhet.
faq/change-service-resources-after-order

Meglévő szolgáltatást módosítja?

Ha egy szolgáltatás már fut, a források módosítását a szolgáltatás részleteinél végezze el. Egy új megrendelés egy új szolgáltatást hoz létre, nem pedig a meglévőt módosítja, és ez változtathatja meg az árat, a napi kreditfelhasználást és a működési viselkedést a visszaigazolás, fizetés és alkalmazás után.

A módosítás jóváhagyása előtt

  1. Tekintse meg a jelenlegi CPU-, RAM-, tárhely- és biztonsági mentési adatokat, valamint az Offsite Archive tárolási idejét.
  2. Ellenőrizze az új napi árat és annak hatását a kreditre.
  3. Olvassa el az újraindításról, karbantartásról vagy leállásról szóló figyelmeztetéseket.
  4. Mielőtt egy kockázatos változást végrehajtana, készítsen saját biztonsági másolatot a fontos adatokról.

Miért nem történik meg a változás az elvárásoknak megfelelően?

Kérjük, küldje el a szolgáltatás nevét, a módosítás időpontját, a látható állapotot és az esetleges hibaüzenetet. Ne küldjön privát kulcsokat, jelszavakat vagy tokeneket; a diagnosztikához elegendő a nyilvános kontextus és egy elrejtett részletekkel ellátott képernyőképe.

> Szolgáltatás megszüntetése és az adatok törlésének időpontja

A bekapcsolt szolgáltatás először felfüggesztésre kerül, megjelenik a konfigurálható, látható adatvédelmi határidő, majd később véglegesen törölhető.
faq/cancel-service-and-data-retention

A szolgáltatás törlése nem jelenti azonnali eltűnését

Egy már aktivált szolgáltatás esetében a rendszer először felfüggeszti azt, majd megjeleníti egy konfigurálható időtartamot, amíg a visszaállítás vagy adatmentés lehetséges. A még be nem állított, fizetetlen rendelések eltérő viselkedést mutathatnak, és a végleges törlés csak az életciklus lejáratát követően történik.

Ellenőrizze törlés előtt

  1. Mentse le saját exportját azokhoz az adatokhoz, amelyeket hosszú távon szeretne megőrizni.
  2. Olvassa el a szolgáltatás felfüggesztésekor megjelenő dátumot és időpontot, amely a törlés tervezett idejét jelzi.
  3. A biztonsági mentések és az offsite archívum nem helyettesítik a szolgáltatás életciklusának részeként történő törlést.
  4. Ha bizonytalan, vegye fel a kapcsolatot a támogatással a törlési határidő előtt.

A szolgáltatás lemondása után a visszaállítás nem feltétlenül lehetséges

A megjelenített időtartam lejártával az adatokat nem tekintheti elérhetőnek. Kérdés esetén küldje el a rendelés számát és a szolgáltatás nevét, ne adatbázis exportokat vagy jelszavakat.

> Visszaállítási lehetőségek

A biztonsági másolatok a rendszer működésének helyreállításához szükségesek, és nem helyettesítik az export funkciót. A visszaállítás során előfordulhat, hogy régebbi adatok íródnak felül.
faq/backups-and-restore-requests

A biztonsági mentés nem archiválás vagy export funkció

A biztonsági mentések tárolási ideje a kiválasztott terméktől és beállításoktól függ. A biztonsági mentés az operációs helyreállítást támogatja, de nem helyettesíti a saját exportot, audit naplót vagy a külső archívumot. A visszaállítás (restore) felülírhatja az újabb változásokat.

Hogyan kell egy visszaállítási kérést előkészíteni

  1. Adja meg a szolgáltatás nevét és a rendelési számot.
  2. Írja le, hogy mely időpontra szeretné visszaállítani az adatokat.
  3. Tüntesse fel, hogy a teljes szolgáltatást vagy csak egy részét kell-e visszaállítani, amennyiben ez támogatott.
  4. Csatoljon egy látható hibát vagy kontextust, de ne tartalmazzon jelszavakat, tokeneket és privát kulcsokat.

A helyreállítás hatásai

Ha a szolgáltatás közben új adatokat fogadott, azok felülírhatják a régebbi állapotot. A visszaállítás megerősítése előtt tájékoztassa a csapatot, és készítsen biztonsági másolatot arról, amit nem szeretne elveszíteni.

> Mi az Offsite Archive?

Az Offsite Archive távoli archív másolatokat tárol, amelyek elkülönülnek a rövid távú operációs biztonsági mentésektől és a szolgáltatás életciklusától. Ez nem élő alkalmazás tároló.
faq/offsite-archive-purpose

Archívum a rendszeren kívül

Az Offsite Archive távoli archív másolatok készítésére és adatok hosszabb távú tárolására szolgál. Nem egy alkalmazás számára elérhető meghajtó, nem helyettesíti a helyi exportot, és nem ugyanaz, mint a rövid, operációs biztonsági mentések.

Mikor aktiválja?

  1. Használja a pontos szolgáltatásnévhez, doménhez, időponthoz és látható hibaüzenethez kapcsolódó adatok tárolására, amelyeknek akkor is elérhetőnek kell lenniük, amikor a rendszer nem aktív.
  2. Válassza ki a megőrzési napokat a megfelelőségi vagy helyreállítási céloknak megfelelően.
  3. Figyelje, hogy az ár az eltárolt adatmennyiség és a tárolási idő függvényében nő.
  4. Nagy adatmennyiségek esetén tervezze meg az archívumot a saját exportfolyamataival együtt.

Hogyan gondolkodjunk az árakról

Az alapvető egység az MB-nap: ez azt jelenti, hogy mennyi adat van tárolva és hány napig tartja meg. Az ár a felhasználónak EUR/GB/hó formában jelenik meg, és az eredmény egész centekre kerekítve kerül megjelenítésre.

> CPU, RAM és tárhely kiválasztása virtuális szerverhez

A virtuális szerver méretét az alkalmazás, adatbázis, gyorsítótár, naplók és a várható növekedés alapján válassza ki. Az OOM (memóriakezelési hiba) vagy a swap használata jelezheti, hogy több RAM szükséges.
faq/vps-cpu-ram-and-disk-sizing

Kezdje a tényleges terhelés alapján, ne pedig ösztönösen

Egy kis statikus weboldal más igényekkel rendelkezik, mint egy adatbázis, Java alkalmazás, kereső vagy build-ök konténer. A tervezés során vegye figyelembe az alkalmazás memóriáját, a gyorsítótárat, az adatbázist, a naplókat, a feltöltéseket és a növekedési tartalékot.

Jelzések arra, hogy a rendszertervezés korlátozott

  1. Növelje a RAM-ot, ha memóriahiány (OOM) lép fel, folyamat leáll, vagy állandó swapolás történik.
  2. Növelje a CPU-t, ha tartósan magas számítási terhelés, tömörítés, buildelés vagy intenzív alkalmazás fut.
  3. Nagyobbítsa a diszket, mielőtt a fájlrendszer, a naplófájlok vagy az adatbázis megtelne.
  4. Minden változás után ellenőrizze, hogy az alkalmazás valóban nem ütközik-e a korábbi limitnek.

Mit kell elküldeni méretezési kérdés esetén?

A szolgáltatás neve, az alkalmazás típusa, a látható hibaüzenet, a probléma időtartama és a jelenleg beállított CPU, RAM és tárhely segíthet. Ne küldjön jelszavakat, privát kulcsokat vagy belső konfigurációs fájlokat.

> Mikor érdemes nyilvános IP-címet használni VPS esetén?

A dedikált nyilvános IP-cím segít a hozzáférési listáknál, a bejövő kapcsolatoknál, egy stabil külső forrásnál vagy olyan szolgáltatásoknál, amelyek egy adott IP-címhez vannak kötve.
faq/vps-public-ip-options

Először tisztázd a kommunikáció irányát

A nyilvános IP-cím nem minden szolgáltatáshoz szükséges. Gyakran külső partnerek, szolgáltatók vagy tűzfalak által használt allowlist funkcióhoz, stabil kimenő forráshoz vagy egy adott porton keresztül történő bejövő hozzáféréshez használják.

IP-cím megrendelés előtti kérdések

  1. Kérdezd meg a partnert, hogy engedélyezi-e a bejövő, a kimenő vagy mindkét irányú forgalmat.
  2. Használj DNS-neveket az IP-címek helyett, ahol csak lehetséges.
  3. Nyisd meg csak azokat a portokat, amelyekre az alkalmazásnak valóban szüksége van.
  4. Kérjük, küldje el az allowlist igényét a támogatásnak, mielőtt módosítja a termelési környezet hozzáféréseit.

Mit érdemes zártan hagyni

A nyilvános IP-cím nem jelenti azt, hogy minden port nyitva van. Kérjük, tervezze a hozzáférést csak a minimálisan szükséges szolgáltatásokhoz, és ne küldjön jelszavakat, privát kulcsokat vagy belső tűzfalszabályokat képernyőképeken, amelyek titkos értékeket tartalmaznak.

> Megosztott SSH hozzáférés VPS-hez

Nyilvános IP cím vásárlása nélkül a VPS egy megosztott SSH kapcsolaton keresztül csatlakozik, magas port használatával; nyilvános IP esetén közvetlen SSH hozzáférést is biztosítunk ezen a címen.
faq/shared-ssh-access-for-vps

Miért használ magas portot a megosztott SSH?

Több VPS szolgáltatás is oszthatja ugyanazt a nyilvános SSH végpontot, ezért minden szolgáltatáshoz egyedi magas port tartozik. A port része az Ön szolgáltatásához való útvonalnak; nélküle a kapcsolat nem irányítható egyértelműen a megfelelő VPS-re.

Kapcsolódás a hozzáférési típusnak megfelelően

  1. Megosztott SSH esetén másolja ki a szolgáltatásból az SSH felhasználónevet, a publikus hosztot és a magas portszámot.
  2. Használja ezt a formátumot: ssh -p <port> <felhasználónév>@<publikus_hoszt>.
  3. Ha a szolgáltatáshoz nyilvános IP-cím van vásárolva, akkor lehet egy második SSH végpont közvetlenül erre az IP-címre vagy annak DNS névre.
  4. A privát kulcsot kizárólag helyi gépen, SSH kliens vagy agent segítségével használja; a támogatási csapat számára elegendő a szolgáltatás neve, a nyilvános host, a port, a felhasználónév és a látható hibaüzenet.

Ha külön vásárolt nyilvános IP-címet

A nyilvános IP-cím nem helyettesíti a megosztott SSH végpontot; egy különleges hozzáférési módot biztosít engedélyezési listákhoz, monitorozáshoz vagy közvetlen integrációkhoz. Ezért gyakran láthat kétféle SSH kapcsolatot: egy megosztott hostot magas porttal és egy közvetlen hostot vagy IP-címet a nyilvános IP-című szolgáltatás számára.

> Saját tartomány csatlakoztatása előtti ellenőrzés

A tartomány átállítása előtt ellenőrizze a hiteles DNS-t, a pontos hosztnév-et, a rekordtípust, hogy az egy teljes domain vagy aldomain-e, valamint a potenciálisan ütköző régi bejegyzéseket.
faq/custom-domain-readiness-checklist

A pontos hosztnév számít

Először tisztázzuk, hogy a fődomain-t (például example.com) vagy egy altartományt (például app.example.com) kapcsoljuk-e hozzá. Mindkét lehetőség más típusú DNS bejegyzést, más DNS szolgáltatói korlátozásokat és regisztrátori ellenőrzést igényelhet.

DNS-változtatás előtt

  1. Ellenőrizze, hogy hol módosíthatók a domén hatósági DNS-rekordjai.
  2. Törölje vagy módosítsa az ütköző A/AAAA, CNAME, ALIAS, ANAME vagy átirányítási rekordokat.
  3. Használja a szolgáltatáshoz és hosztnévhez ajánlott rekordtípust.
  4. A módosítás után várja meg a DNS propagálódást, majd tesztelje a végleges HTTPS kapcsolatot.

Biztonságos visszaállítás

Ne tiltsa le a régi hosztingot addig, amíg az új hostname helyesen nem válaszol. Ha problémája van, küldje el a domént, a várható célt és a látható DNS eredményt, de ne a regisztrátorhoz tartozó hozzáféréseket.

> DNS-rekordtípusok szolgáltatásokhoz

Az A/AAAA rekordok IP-címekre mutatnak, a CNAME aliasokra, az MX levelezésre, a TXT pedig ellenőrzésekhez, például SPF, DKIM vagy DMARC céljából szolgál.
faq/dns-record-types-for-services

Amit érdemes először tudni

Minden DNS-típus más feladatot lát el. Az A és AAAA rekordok IP-címekre mutatnak, a CNAME alias létrehozására szolgál egy altartomány számára, az MX a levelezést irányítja, a TXT ellenőrzéseket és e-mail szabályzatokat tartalmaz, a CAA pedig korlátozza a tanúsítványkiadó hatóságokat.

Rekordok másolásakor

  1. Másolja le a szolgáltatás által megadott DNS típust és célpontot pontosan.
  2. A/AAAA rekordokat használjon címekhez, CNAME rekordokat engedélyezett aldomén aliasokhoz, MX rekordokat e-mailhez, és TXT rekordokat SPF, DKIM, DMARC vagy hitelesítéshez.
  3. Helyezze a DKIM bejegyzést a szolgáltató választható részévé, és a DMARC bejegyzést az _dmarc alatt a küldő domain számára.
  4. Legyen óvatos a CAA beállításokkal, mert helytelen értékek megakadályozhatják a tanúsítvány kiadását.

Miért nem működik a DNS?

Kérjük, küldje el a támogatási csapatnak a hostname-t, a rekord típusát, az elvárt értéket és a nyilvánosan látható eredményt. Ne küldjön bejelentkezési adatokat a DNS adminisztrációhoz, vagy képernyőképeket API tokenekkel.

> DNS propagáció: A TTL értékre vonatkozóan percekig tartó pontosságot nem garantálunk

A TTL határozza meg, hogy a keresőmotorok meddig tárolhatják a régi választ; az átmenet során előfordulhat, hogy régi és új eredmények is megjelennek.
faq/dns-propagation-and-ttl

A propagáció egy gyorsítótár, nem pedig varázslatos várakozás

A DNS esetében nincs garantált időtartam percben. A hatósági DNS módosítása után a különböző resolver-ek továbbra is régi és új válaszokat adhatnak vissza, amíg a gyorsítótár nem jár le a TTL érték alapján. Ezért az eredmény hálózatok, országok vagy DNS-resolver-ek között is eltérő lehet.

Tervzett változtatás esetén

  1. Ha a szolgáltatója lehetővé teszi, csökkentse a TTL értéket a tervezett módosítás előtt.
  2. A DNS beállítás módosítása után egyszer végezze el a változtatást, és kerülje az ismételt szerkesztéseket, amíg a gyorsítótárak le nem járnak.
  3. Tesztelje több különböző resolverről vagy hálózatról, ha eltérő eredményeket tapasztal.
  4. Jegyezze fel a módosítás időpontját, a régi értéket, az új értéket és a TTL-t.

Mit kell elküldeni a diagnózis során?

Adja meg a hostname-t, a várt célt, a látható régi választ, a látható új választ, a TTL-t és a módosítás időpontját. Ne küldje el a DNS-fiók hozzáférési adatait vagy a szolgáltató belső megjegyzéseit.

> Workspace Suite tárhelyigények tervezése

A tárolási kapacitás tervezésénél vegye figyelembe a felhasználói fájlokat, a megosztott mappákat, a verziókat, a törölt fájlokat (kukát), az előnézeteket, a szinkronizálási overhead-et és a csapat bővülését.
faq/nextcloud-storage-planning

A Workspace Suite tárolóhasználat nem csak a fájlokról szól

A tárhelyet felhasználói fájlok, megosztott mappák, törölt fájlok, verziótörténetek, előnézetek, miniatúrák, szinkronizálási folyamatok és importok is igénybe veszik. Ha a tároló közel van a limithez, az feltöltési vagy szinkronizálási hibákhoz vezethet.

Kapacitás foglalása előtt

  1. Számolja ki a jelenlegi felhasználói adatok és megosztott mappák mennyiségét.
  2. Változtassa át a verziókat, a törölt fájlokat, az előnézeteket és a szinkronizálási terhelést tartalmazó tartalmakat.
  3. Vegye figyelembe a nagy importokat, az új csapatokat és a várható növekedést.
  4. Növelje a kapacitást, mielőtt a felhasználók elérnék a korlátot.

Szinkronizációs problémák esetén

Küldje el a szolgáltatás méretét, a hozzávetőleges használatot, a probléma időpontját és az ügyfél által látott hibát. Ne küldjön személyes fájlokat, jelszavakat vagy felhasználói adatok exportjait, kivéve, ha a támogatási csapat kifejezetten biztonságos módon kérte őket.

> Repozitóriók migrálása a Gitea rendszerbe

A Git repozitóriók migrálásának megtervezése LFS, submodule-ok, jogosultságok, deploy key-ek, webhook-ok és CI/CD funkciók figyelembevételével.
faq/gitea-repository-migration

A migrálás több, mint egy egyszerű git clone

A repozitórium történetén túl át kell vinni vagy újra be kell állítani a tulajdonosokat, csapatokat, védett ágakat, védett tageket, Git LFS-t, szubmodulokat, deploy kulcsokat, webes horgonyokat és CI/CD kapcsolatokat.

Változás előtti ellenőrzés

  1. Adja meg a repozitóriumokat, tulajdonosokat, felhasználókat, Git LFS objektumokat, szubmodulokat, védett ágakat, címkéket és automatizált fiókokat.
  2. Ellenőrizze a Git LFS objektumokat, szubmodulokat, védett ágakat és címkéket.
  3. A migrálás után tesztelje a klónozást, feltöltést, Git LFS-t, szubmodulokat és a CI futtatást.
  4. A migrálás után törölje vagy cserélje le a régi hozzáférési tokeneket úgy, hogy azok értékei ne legyenek megosztva.

Fontos adatok migráció során

Ne küldjön a támogatási csapathoz tokeneket, privát kulcsokat, deploy key-ek magját vagy CI titkokat. Elég a repozitóriumnak neve, az integráció típusa, a látható hiba és információ arról, hogy mi működött a migrálás előtt.

> Listmonk küldési domain

Készítsen elő egy küldő domaint vagy aldomaint a kampányokhoz, valamint a 'From' azonosítót, SPF, DKIM, DMARC beállításokat, visszaküldéskezelést és leiratkozási lehetőséget.
faq/listmonk-sender-domain-basics

A szállítás a doménről indul

A Listmonk-nak egyértelmű küldői identitásra és olyan DNS bejegyzésekre van szüksége, amelyeket a postaleküldő világ ellenőrizhet. Az SPF, DKIM és DMARC bejegyzéseknek a doménhez vagy aldoménhez kell kapcsolódniuk, ahonnan kampányokat szeretne küldeni.

A kampány elindítása előtt

  1. Válassza ki a küldő domaint vagy altartományt, és állítsa be a "From" azonosítót.
  2. Adja hozzá a szükséges DNS-bejegyzéseket a hitelesítéshez: SPF, DKIM (válasszon kulcsszavakat) és DMARC.
  3. Tesztelje az átadást, a visszaküldést (bounce), a Return-Path címet és a levélben szereplő linkeket.
  4. Ellenőrizze a leiratkozási lehetőségeket és a List-Unsubscribe beállításokat, mielőtt ténylegesen küldeni kezdené az üzeneteket.

A levelezési beállítások nem tartoznak a jegyekhez.

Hibaelhárítás során kérjük, ossza meg a domaint, a rekordtípust, a nyilvánosan elérhető DNS-értéket és a hibaüzenetet. Ne küldje el az SMTP jelszavakat, API tokeneket, privát DKIM kulcsokat vagy az ügyféladatokkal rendelkező címjegyzék exportját.

> A Classic Hosting futtatókörnyezet beállításai

A Classic Hosting automatikus vagy manuális üzemmódban működhet; a CPU, RAM, tárhely, biztonsági mentések, az Offsite Archive tárolási ideje, a feltöltések, a gyorsítótár és a naplófájlok befolyásolják az árat és a stabilitást.
faq/classic-hosting-runtime-settings

Az automatikus mód nem mindig a legjobb választás

Az Auto Runtime segít a felismerhető projekteknél, de a manuális mód akkor hasznos, ha pontosan szeretnéd kiválasztani az Nginx-et, Apache-ot, FrankenPHP-t vagy egy adott programnyelvi futtatókörnyezetet. A PHP válaszót csak ott használd, ahol a kiválasztott futtatókörnyezet támogatja.

Telepítési előkészületek

  1. Válassza ki az automatikus vagy manuális futtatókört a használt keretrendszernek és a buildelés módjának megfelelően.
  2. Válassza a PHP 8.2, 8.3 vagy 8.4 verziót csak akkor, ha a kiválasztott futtatókör támogatja azt.
  3. Állítsa be a CPU-t, RAM-ot, tárhelyet, biztonsági mentés megtartási idejét és az Offsite Archive-ot a forgalomnak és az adatmennyiségnek megfelelően.
  4. A telepítés után tesztelje a feltöltéseket, a gyorsítótárat, a naplókat és az alkalmazás látható hibáit.

Ha az alkalmazás nem indul el

Kérjük, küldje el a futtató környezet beállításait, a nyelvet vagy a PHP verziót, a látható hibát, a változásokat és a telepítés hozzávetőleges időpontját. Ne küldje el a .env fájlokat, jelszavakat, tokeneket vagy teljes naplókat, amelyek érzékeny adatokat tartalmaznak.

> Milyen információkat osszon meg biztonságosan a támogatással?

A leginkább hasznosak az alábbi adatok: rendelési számok, szolgáltatásnevek, domain-ek, időpontok, nyilvános szerverek és portok, kiválasztott futtatókörnyezet, PHP verzió, CPU, RAM, tárhely, biztonsági mentések tárolási ideje, az Offsite Archive tárolási ideje, feltöltések, cache, naplók, egy közelítő időpont, elmaszkolt képernyőképek és látható hibaüzenetek. Soha ne küldjön jelszavakat, privát kulcsokat, tokeneket, seed phrase-eket, titkokat tartalmazó teljes naplókat, adatbázis exportokat vagy belső infrastruktúra részleteket.
faq/support-safe-information-to-share

Egy jó támogatási kérés tartalmazza a szükséges információkat, nem pedig bizalmas adatokat.

A támogatási csapat gyorsabban tud reagálni, ha megkapja a rendelési számot, a szolgáltatás nevét, a domaint, a nyilvános hosztot vagy portot, a probléma időpontját, az elvégzett módosításokat és a pontos, látható hibaüzenetet.

Biztonságos üzenet tartalma

  1. Kérjük, adja meg a rendelési számot, a szolgáltatás nevét, a domaint, az időpontot és azt a lépést, ahol a probléma jelentkezett.
  2. A hostinggal kapcsolatos problémák esetén kérjük, tüntesse fel a futtási módot, a nyelvet vagy a PHP verziót, az CPU-t, a RAM-ot, a tárhelyet, a feltöltéseket, a gyorsítótárat és a naplókat (ne tartalmazzanak érzékeny adatokat).
  3. A képernyőképeket kérjük, küldés előtt vágja le vagy takarja el az érzékeny területeket.
  4. Ha nem biztos benne, hogy egy információ releváns a jegyhez, először kérdezze meg, mielőtt elküldi.

Mit sem szabad küldeni

Ne küldjön jelszavakat, privát kulcsokat, helyreállítási kódokat, API-kulcsokat, session cookie-kat, adatbázis-exportokat, teljes .env fájlokat, érzékeny adatokkal teli teljes naplókat vagy belső infrastruktúra részleteket.