Pogosto zastavljana vprašanja

Pogosto zastavljena vprašanja

Praktični kratki vodniki za nastavitev storitev, dostop in pogosta dejanja strank.

> Kako deluje kreditni sistem Cli>_?

En skupni predplačniški saldo financira vse upravičene storitve in se porablja samo med njihovim aktivnim delovanjem.
faq/prepaid-credit-how-it-works

Tvoj račun Cli>_ ima en skupni predplačniški kreditni saldo. Upravičene nove stranke lahko Starter Credit zahtevajo šele po opravljeni obvezni preveritvi računa in zaščite pred zlorabami. Aktivne upravičene storitve saldo sčasoma porabljajo. Mesečna ocena uporablja 31 dni, nova storitev pa se lahko zažene le, če saldo pokriva najmanj 7 dni. Rdeče opozorilo se prikaže, ko ocenjeno delovanje pade pod 7 dni; sicer se oranžno opozorilo prikaže, ko pade pod 14 dni.

Po izpraznitvi salda se storitev po 7 dneh ustavi, preneha porabljati kredit in začne teči 7-dnevni rok hrambe in izbrisa. Pred prikazanim rokom jo lahko z dovolj kredita znova zaženeš. Preklic provisionirane storitve jo prav tako ustavi in začne isti rok. Čakajoča, še neprovisionirana storitev se lahko takoj deaktivira. Po roku se začneta deaktivacija in odstranjevanje provisionirane storitve. Force delete storitev takoj deaktivira, preskoči hrambo in začne odstranjevanje iz aktivnega runtimea; dokončanje sledi obdelavi deploymenta in GitOps. Varnostne kopije in Offsite Archive imajo ločena pravila hrambe.

Primer OpenCode za 9,90 EUR: 9,90 / 31 ≈ 0,319 EUR na dan. Po 10 polnih dneh se porabi približno 3,19 EUR. Če je bil začetni saldo natanko 9,90 EUR in ni bilo drugih storitev, ostane približno 6,71 EUR. Po onemogočenju se poraba ustavi.

Primer je le ponazoritev. Vedno veljajo trenutne cene, prikazane v Cli>_.

> Kako generirati javni SSH ključ prek ukazne vrstice

Ustvarite javni SSH ključ za varen dostop do VPS. Z delitvijo samo javnega ključa s Cli>_ ohranite zasebni ključ na svoji napravi.
faq/generate-public-ssh-key-sl

Uporabite samo javni ključ

Za uporabo SSH potrebujete par ključev. V nastavitve storitve vstavite le javni ključ, običajno datoteko z razširitvijo .pub. Zasebni ključ ostane na vašem računalniku.

Postopek

  1. Odprite terminal na vašem računalniku.
  2. Zaženite ukaz: ssh-keygen -t ed25519 -C "your-email@example.com".
  3. Potrdite lokacijo datoteke ali izberite lastno pot. Nikoli ne posredujte svoje zasebne ključke.
  4. Prikažite javni ključ z ukazom: cat ~/.ssh/id_ed25519.pub.
  5. Kopirajte celotno vrstico, ki se začne z 'ssh-ed25519', in jo vstavite v polje 'SSH javni ključ' med naročanjem ali nastavitvijo storitve.
  6. Kopirajte celotno vrstico s 'ssh-ed25519' in jo vstavite v polje 'SSH javni ključ'.

Preveri pred lepljenjem

  1. Odprite PowerShell ali Windows Terminal.
  2. Zaženite ukaz: ssh-keygen -t ed25519 -C "vaša_e-pošta@example.com".
  3. Pritisnite Enter za shranjevanje ključa v mapo C:\Users\vaš_uporabnik\.ssh\id_ed25519 ali vnesite lastno pot.
  4. Če Windows zahteva geslo, uporabite takšno, ki ga lahko varno shranite, ali pritisnite Enter za preprosto nastavitev.
  5. Javni ključ prikažite z ukazom: Get-Content $env:USERPROFILE\.ssh\id_ed25519.pub.
  6. Kopirajte samo celo vrstico, ki se začne z 'ssh-ed25519'. Ne kopirajte in ne naložite datoteke s privatnim ključem.
> Kako ustvariti SSH ključ grafično v operacijskem sistemu Windows

Grafičen postopek v operacijskem sistemu Windows za ustvarjanje para SSH ključev brez uporabe ukazne vrstice.
faq/create-ssh-key-windows-gui-sl

Uporabite orodje za Windows in vstavite samo javni ključ

Par ključev SSH lahko ustvarite tudi vizualno z uporabo odjemalnika SSH za Windows, kot je PuTTYgen. Cli>_ potrebuje samo javni ključ. Zasebnega ključa ne shranjujte na računalniku in ga ne nahrani v spletni obrazec.

Postopek

  1. Odpri PuTTYgen.
  2. Izberite EdDSA/Ed25519, če je na voljo, ali pa RSA 4096, če orodje Ed25519 te možnosti ne ponuja.
  3. Kliknite gumb Ustvari in premikajte miško po praznem območju, dokler se ključ ne ustvari.
  4. Dodajte geslo, če želite dodatno lokalno zaščito zasebnega ključa.
  5. Shranjevanje zasebnega ključa na vašem računalniku in ga ohranite zaupnost.
  6. Kopirajte besedilo javnega ključa in ga vstavite v polje SSH public key.

Ne delite občutljivih podatkov

Ne posredujte datotek .ppk, zasebnih ključev, gesel ali tokenov službi za podporo ali preko obrazcev.

> Prinesi svojo lastno domeno

Naučite se, kako usmeriti vašo lastno domeno ali poddomeno na storitev CLIopen, preden omogočite funkcijo 'Prinesite svojo domeno'.
faq/povezite-svojo-domeno

Kaj ta nastavitev počne

Uporaba lastnega domačega naslova omogoča, da vaša storitev odgovarja na vašem osebni domeni, npr. app.example.com, namesto uporabe privzetega generiranega naslova *.co.cliopen.cloud. Vaš DNS mora najprej usmerjati proti CLIopen, preden se lahko domači naslov varno uporabi v storitvi.

Pred začetkom

  1. Izberite natančen naslov gostovanja, ki ga želite uporabiti, na primer app.example.com. Najenostavnejša možnost je uporaba poddomene.
  2. Odprite upravljanje DNS pri registratorju domene ali ponudniku storitev DNS.
  3. Izbrišite morebitne konflikte A, AAAA, CNAME, ALIAS ali preusmeritvene zapise za isti naslov gostovanja.
  4. Časovno generirano ime gostitelja CLIopen naj bo aktivno, dokler vaše lastno ime gostitelja ne bo preverjeno in popolnoma funkcionalno.

Priporočena nastavitev DNS za poddomen

Ustvarite DNS zapise za natančno ime gostitelja, ki ga vnesete v CLIopen. Za app.example.com je DNS oznaka app. Usmerite ga na naslove CLIopen ingress, ki jih prejmete od podpore CLIopen ali v dokumentaciji storitve. Če vaš ponudnik zahteva vrsto zapisa, uporabite zapis A za IPv4 in zapis AAAA za IPv6, če so ti naslovi na voljo.

Vzorec:

app.example.com.  A     <Naslov CLIopen IPv4>
app.example.com.  AAAA  <Naslov CLIopen IPv6, če je na voljo>

Ko CLIopen zagotovi cilj CNAME

Nekatere storitve vam lahko ponudijo generirano ime gostitelja, na primer service.customer.co.cliopen.cloud. Če vaše navodila za storitev izrecno zahtevajo uporabo CNAME, ustvarite zapis, kot je app.example.com CNAME service.customer.co.cliopen.cloud. Uporabljajte CNAME samo za poddomene, ne pa tudi za glavno/korensko domeno, razen če vaš ponudnik DNS podpira funkciji ALIAS ali ANAME flattening.

Uporaba glavnega domena

Za glavno ime domene, kot je example.com, večina ponudnikov DNS ne dovoljuje standardnega CNAME zapisa. Uporabite A/AAAA zapise, ki usmerjajo na naslove CLIopen ingress ali uporabite funkcijo ALIAS/ANAME vašega ponudnika, če vam CLIopen zagotovi ciljno ime domene.

Delegiranje celotne poddomene

Če želite, da CLIopen upravlja z evidence v poddomeni, kot je apps.example.com, ustvarite NS zapise za to poddomeno in jih usmerite na strežnike CLIopen, ki ste jih prejeli. Ne spreminjajte DNS strežnikov za celotno domeno, razen če želite namerno, da CLIopen (ali druga storitev za upravljanje DNS) upravlja vse evidence.

Preverjanje

  1. Počakajte na propagacijo DNS. Manjše spremembe so pogosto vidne v nekaj minutah, vendar nekateri ponudniki shranjujejo podatke dlje.
  2. Preverite, ali ime domene usmerja na cilj CLIopen in ne na prejšnjega ponudnika.
  3. V polje "Uporabite svojo domeno" vnesite natančno ime gostitelja, brez `https://` in poti.
  4. Po posodobitvi preizkusite `https://app.example.com` v brskalniku.
  5. Stare DNS zapise ohranite samo, če ne pridejo v konflikt z novim imenom gostitelja.
> Kako prenesete območje DNS v CLIopen

Delegirajte domeno na ns1.cliopen.com in ns2.cliopen.com, da bo CLIopen objavljal zapise za celotno območje.
faq/prenos-dns-cone

Kaj pomeni prenos zone tukaj?

Pri storitvi DNS za stranke prenos pomeni spremembo avtorizativnih imen servisov pri vašem registratorju domene. Po delegiranju na CLIopen se DNS zapisi, dodani v CLIopen, objavljajo iz naših avtorizativnih imen servisov.

Preden spremenite strežnike imenske domene

  1. Kopirajte obstoječe DNS zapise, ki jih še potrebujete, kot so spletno mesto, e-pošta, preverjanja, SPF, DKIM, DMARC in servisni zapisi.
  2. Dodajte območje v CLIopen DNS. Če delegacija še ni pripravljena, jo CLIopen shrani, vendar je ne aktivira za stranke, dokler se ne opravi preverjanje.
  3. Če je mogoče, ustvarite potrebne zapise v CLIopen DNS pred preklopom name serverjev.
  4. Bodite pozorni pri nastavljanju CAA, saj nepravilne vrednosti lahko preprečijo izdajo certifikatov.

Delegirajte območje

  1. Odprite nastavitve domene pri registratorju, na primer example.com.
  2. Poiščite nastavitev imen servisov (nameservers), delegacijo DNS ali avtorizativne DNS nastavitve.
  3. Zamenjajte trenutne imenske servise z vrednostmi ns1.cliopen.com in ns2.cliopen.com.
  4. Shranjujte spremembe in počakajte na propagacijo v registru in resolverjih.

Preverjanje

Vrnite se v CLIopen DNS in kliknite na Ponovno preverjanje delegiranja. Ko javni NS zapisi prikazujejo ns1.cliopen.com in ns2.cliopen.com, bo območje dodano v vrsto za sinhronizacijo, zapis pa bo aktiven iz CLIopen.

> Registracija računa in prva prijava

Ustvarite en poslovni račun za naročila, podatke za zaračunavanje in upravljanje storitev.
faq/account-registration-and-login

Ena spletna stran za naročila in upravljanje

Uporabite račun kot trajno mesto za naročila, podatke o računu, storitve, domene in komunikacijo s podporo. Najbolje je uporabiti poslovni e-naslov, do katerega bo imela ekipa dostop tudi po spremembah v osebju.

Pred prvim naročilom

  1. Registrirajte se s poslovnim e-poštnim naslovom.
  2. Potrdite e-poštno sporočilo, če vas spletna stran pozove k temu.
  3. Izpolnite podatke za obračunavanje, preden oddate naročilo z plačilom.
  4. Vklopite dvofaktorsko zaščito, ko je na voljo.

Dostop za ekipo

Gesel ne posredujte kolegom preko klepeta ali e-pošte. Če dostop potrebuje več oseb, uporabite notranji upravitelj gesel ali zahtevajte priporočeno postopek za ekipo; podpora ne potrebuje vašega gesla ali avtentifikacijske kode.

> Ocena mesečne porabe, ocena letne porabe in dejanska dnevna poraba

Mesečne in letne cene služita za primerjavo; pri storitvah z napolnjenim računom se kredit odšteva vsak dan po potrditvi naročila ali spremembe.
faq/billing-periods-and-credit-burn

Ocena ni obračunski koledar

Mesečna ocena predstavlja primerjavo za 31 dni, letna pa za 372 dni. Dejanska poraba kreditov pri predplačniških storitvah poteka glede na aktivno uporabo storitev in potrjeno konfiguracijo.

Kaj morate preveriti ob spremembi cene

  1. Primerjajte dnevno porabo pred in po spremembi.
  2. Pri večji količini CPU, RAM-a, diska ali plačljivih funkcijah upoštevajte višjo dnevno porabo.
  3. Sprememba začne veljati šele po potrditvi, morebitnem plačilu in uporabi.
  4. Za računovodstvo shranite potrdila naročil in zgodovino kredita.

Pri težavah preverite specifično obdobje.

Podpora bo lahko pomagala s številko naročila, imenom storitve in datumi, za katere želite preveriti porabo. Ne posredujte bančnih podatkov, celotnih izpisov plačil ali posnetkov zaslona z neželenimi osebnimi podatki.

> Stanje naročila po plačilu

Naročilo lahko po plačilu nekaj časa čaka na potrditev ponudnika; ustvarite kopijo šele, ko je prvo naročilo jasno preklicano ali iztečeno.
faq/order-status-and-payment-confirmation

Stanje 'pending' še ne pomeni napake

Po vrnitvi s plačilne strani lahko naročilo še čaka na potrditev od ponudnika plačilnih storitev. Dokler stanje ni jasno označeno kot neuspešno ali poteklo, lahko novo podvojeno naročilo nepotrebno zaplete proces.

Kako ravnati po plačilu

  1. Po opravljeni plačilni transakciji se vrnite nazaj na stran Cli>_.
  2. Preverite stanje naročila v svojem računu in morebitno sporočilo o plačilu.
  3. Če naročilo še vedno čaka, počakajte, da ponudnik potrdi.
  4. V primeru težav, kontaktirajte podporo in jim posredujte številko naročila ter referenco plačila, če je vidna.

Katere informacije ne posredovati

Podpora ne potrebuje podatkov o kreditni kartici, gesel ali celotnih bančnih potrdil. Potrebne so le številka naročila, čas plačila, prikazan status in zakrita slika morebitne napake.

> Podatki, ki pospešijo nastavitev storitve

Pripravite ime storitve, domeno, zaledje, e-poštni naslov za dostop in javni SSH ključ; skrivne podatke ne vključujte.
faq/service-setup-information-needed

Natančni podatki prihranijo čas

Uporabite obrazce za javne ali nečlane vrednosti: ime storitve, domeno, načrt DNS, velikost shrambe, CPU, RAM, e-poštni naslov administratorja ali javni SSH ključ. Gesla, zasebni ključi in tokeni se vnašajo drugam.

Pripravite se preden oddate naročilo

  1. Izberite prepoznavno ime storitve za vašo ekipo.
  2. Odločite se, ali boste uporabili lastno domeno ali začasen sistemski naslov.
  3. Pripravite javni SSH ključ, če ga storitev zahteva.
  4. Preverite velikost shrambe in vire glede na aplikacijo, ki jo nameravate uporabljati.

Ne posredujte zaupnih informacij

Če niste prepričani, ali je podatek zaupen, se raje vprašajte, preden ga pošljete. Zasebne ključe, gesla, tokene, varnostne kopije podatkovnih baz in celotne konfiguracijske datoteke ne posredujte preko klepeta ali v naročilu.

> Sprememba procesorja, pomnilnika, diska ali shranjevanja po naročilu

Spremenite obstoječo storitev prek podrobnosti o njej, ne ustvarjajte nove duplicitne naročile; pri spremembi virov se lahko spremeni cena, cena storitve, dnevna poraba kreditov, ponoven zagon in tveganje izpada.
faq/change-service-resources-after-order

Spremenite že obstoječo storitev, ne zaženite nove.

Če storitev že deluje, spremembo virov opravite v podrobnostih te storitve. Novo naročilo bi ustvarilo novo storitev namesto posodobitve obstoječe in lahko spremeni ceno, dnevno porabo kreditov ter obratovalno vedenje po potrditvi, plačilu in uporabi spremembe.

Pred potrditvijo spremembe

  1. Oglejte si trenutno porabo CPU, RAM-a in prostora na disku ter nastavitve varnostnih kopij in arhiviranja.
  2. Preverite novo dnevno ceno in vpliv na kredit.
  3. Preberite opozorila o ponovnem zagonu, vzdrževanju ali izpadu.
  4. Pred kakršnokoli pomembno spremembo naredite lasten varnostni kopiji pomembnih podatkov.

Kaj storiti, če se sprememba ne izvede po pričakovanjih

Pošljite ime storitve, čas spremembe, vidni status in sporočilo o napaki. Ne posredujte zasebnih ključev, gesel ali tokenov; za diagnostiko je dovolj javni kontekst in zaslon z izključenimi občutljivimi podatki.

> Odjava storitve in rok brisanja podatkov

Aktivirana storitev se najprej ustavi, nato pa je prikazan nastavljiv rok za vidno brisanje podatkov, po katerem sledi trajna izbris.
faq/cancel-service-and-data-retention

Preklic ni vedno takojšnje brisanje

Pri že aktivirani storitvi se ta najprej ustavi in prikaže nastavljiv, viden rok za izbris, do katerega je mogoče obnoviti ali izvesti izvoz podatkov. Neplačane naročilnice, ki še niso aktivirane in nimajo tekočih podatkov, imajo lahko drugačno obnašanje, medtem ko trajno čiščenje poteka šele po preteku določenega obdobja življenjskega cikla.

Pred preklicem preverite

  1. Ustvarite lasten izvoz podatkov, ki jih želite trajno shraniti.
  2. Preberite datum in uro predvidenega brisanja pri začasni ustavitvi storitve.
  3. Ne zamenujte varnostnih kopij in arhiviranja z izbrisom zaradi pretečenega življenjskega cikla.
  4. Če niste prepričani, se obrnite na podporo pred rokom izbrisa.

Po preteku določenega časa obnovitev morda ne bo možna.

Po poteku prikazanega roka podatkov ne smatrajte kot dostopnih. Pri vprašanjih pošljite številko naročila in ime storitve, ne pa datotek s podatki.

> Varnostne kopije in zahtevki za obnovitev

Varnostne kopije se uporabljajo za operativno obnovo, ne pa kot nadomestilo za izvažanje podatkov; proces obnovitve lahko prepiše novejše podatke.
faq/backups-and-restore-requests

Varnostno kopiranje ni arhiv ali izvoz

Obdobje shranjevanja varnostnih kopij je odvisno od izdelka in izbranih možnosti. Varnostne kopije so namenjene obnovitvi sistema v primeru napake, vendar ne nadomestijo lastnega izvoza podatkov, arhiviranja ali zunanjega arhiva. Obnova lahko povrne starejšo različico podatkov in prepiše novejše.

Kako pripraviti zahtevo za obnovitev

  1. Vnesite ime storitve in številko naročila.
  2. Opisujte približen čas, do katerega želite obnoviti podatke.
  3. Navedite, ali želite obnoviti celotno storitev ali samo določen del, če je to podprto.
  4. Priložite vidno napako ali kontekst brez gesel, tokenov in zasebnih ključev.

Pred izvedbo obnovitve upoštevajte možne posledice.

Če je storitev medtem prejela nove podatke, lahko ti nadomestijo starejšo stanje. Pred potrditvijo obnovitve obvestite ekipo in shranite podatke, ki jih ne želite izgubiti.

> čemu je namenjen Offsite Archive

Offsite Archive shranjuje oddaljene arhivske kopije, ločene od krajših operativnih varnostnih kopij in življenjskega cikla storitve.
faq/offsite-archive-purpose

Arhiv zunaj običajne uporabe

Offsite Archive je namenjen za oddaljene arhivske kopije in daljše shranjevanje podatkov. Ni to disk za aplikacijo, nadomestilo lokalnega izvoza ali enako kot kratkoročne varnostne kopije.

Kdaj ga vklopiti

  1. Uporabite Offsite Archive za arhivirane kopije, izvozne datoteke in starejšo gradivo, ne pa za aktivno shranjevanje v aplikaciji.
  2. Izberite število dni zadržanja glede na vaše zahteve skladnosti ali cilje obnovitve.
  3. Spremljajte ceno glede na količino shranjenih podatkov in število dni hrambe.
  4. Pri velikih količinah podatkov načrtujte arhiv skupaj z lastnim procesom izvoza.

Kako razumeti ceno

Osnova so MB-dnevi: koliko podatkov je shranjenih in koliko dni jih hranite. Cena se uporabniku prikaže kot EUR/GB/mesec, rezultat pa se zaokroži na najbližji cel številke.

> Izbira procesorja (CPU), pomnilnika (RAM) in diska za VPS

Velikost VPS izberite glede na vašo aplikacijo, podatkovno zbirko, predpomnilnik, datoteke evidenc in pričakovano rast; OOM ali uporaba swap prostora sta znak, da potrebujete več RAM-a.
faq/vps-cpu-ram-and-disk-sizing

Začnite pri realni obremenitvi

Statična spletna stran ima drugačne zahteve kot baza podatkov, Java aplikacija ali procesi gradnje. Pri načrtovanju upoštevajte predpomnilnik (cache), loge, nalaganja in rezervno kapaciteto za rast.

Znaki premajhnega paketa

  1. Povečajte količino RAM-a, če pride do napak OOM (out of memory), zaključenih procesov ali stalnega swapanja.
  2. Povečajte zmogljivost CPU-ja pri dolgotrajni visoki obremenitvi, kompresiji, gradnji programske opreme ali aktivnih delovnih procesov.
  3. Povečajte prostor na disku, preden se sistem datotek zapolni z logi ali podatkovno bazo.
  4. Po vsaki spremembi preverite, ali aplikacija res ne dosega več prvotne omejitve.

Kaj poslati, ko imate vprašanja o velikosti

Pomagajo informacije o imenu storitve, vrsti aplikacije, vidni napaki, približnem času problema ter trenutno izbrani količini CPU, RAM in diska. Ne posredujte gesel, zasebnih ključev ali notranjih konfiguracijskih datotek.

> Kdaj je javni IP naslov smiseln za VPS strežnik?

Posvečen javni IP naslov pomaga pri seznamih dovoljenih naslovov, notranjem dostopu, stabilnem izhodnem viru ali storitvah, ki so vezane na določen naslov.
faq/vps-public-ip-options

Najprej ugotovite smer komunikacije

Javni IP naslov ni nujno potreben za vsako storitev. Pogosto se uporablja za reševanje zahtev zunanjih partnerjev, ponudnikov ali požarnih sten glede dovoljenega seznama (allowlist), stabilnega izhodnega vira ali dostopa do določenega vratu.

Vprašanja pred naročilom IP

  1. Vprašajte partnerja, ali dovoli promet v obe smeri (inbound in outbound).
  2. Uporabljajte DNS imena namesto številčnih IP naslovov, kjer je to mogoče.
  3. Odprite samo tiste porte, ki so aplikaciji res potrebne.
  4. Zahtevo za seznam dovoljenih naslov pošljite podpori, preden spremenite dostop do produkcijskega okolja.

Kaj naj ostane zaprto

Javni IP ne pomeni odpiranja vseh vrat. Dostop načrtujte samo za minimalno potrebne storitve in ne posredujte gesel, zasebnih ključev ali notranjih pravil požarnega stika kot posnetkov zaslona z občutljivimi podatki.

> Skupni dostop do SSH za VPS

Brez kupljenega javnega IP naslova se VPS priključi preko skupne točke za SSH z visokim portom; ob uporabi javnega IP je na voljo tudi neposreden dostop do SSH na tej naslovi.
faq/shared-ssh-access-for-vps

Zakaj se uporablja visok port pri skupnem SSH dostopu?

Več storitev VPS lahko uporablja isto javno točko za SSH povezavo, zato vsaka storitev dobi svoj lasten visoki port. Ta vrata so del usmerjanja do vaše storitve; brez nje se povezava ne more enoznačno dostaviti do pravilne VPS.

Kako se povežete glede na vrsto dostopa

  1. Pri skupnem dostopu do SSH kopirajte uporabniško ime, javni naslov in visoko številko vrat iz storitve SSH.
  2. Uporabite format `ssh -p <port> <username>@<public-host>`.
  3. Če ima storitev kupljen javni IP naslov, lahko ima tudi drugi SSH vmesnik neposredno na tem IP naslovu ali njegovem DNS imenu, odvisno od nastavitev storitve.
  4. Za podporo posredujte samo javni naslov (host), vrata (port), uporabniško ime in vidno napako, ne pa zasebnega ključa.

Ko imate dodaten javni IP naslov

Lahko opazite deljen gostiteljski strežnik z visokim priključkom ter neposreden gostiteljski strežnik ali IP naslov za storitev z javnim IP naslovom. Izberite pot glede na dovoljena pravila, požarne stene in operativne potrebe.

> Preverjanje pred povezavo vaše domene

Pred preklopom domene preverite avtoritativne DNS nastavitve, natančno ime gostitelja, vrsto zapisa in morebitne konfliktne stare zapise.
faq/custom-domain-readiness-checklist

Pomembno je natančen naslov

Najprej ugotovite, ali povezujete glavno domeno (npr. example.com) ali poddomeno (npr. app.example.com). Vsaka možnost lahko zahteva različne vrste DNS zapisa, druge omejitve ponudnika storitev in preverjanje pri registratorju.

Pred spremembo DNS

  1. Preverite, kje urejate avtoritativne DNS zapise za domeno.
  2. Odstranite ali uredite konfliktne A/AAAA, CNAME, ALIAS, ANAME ali redirect zapise.
  3. Uporabite vrsto zapisa, ki je priporočena za določeno storitev in ime gostitelja.
  4. Po spremembi počakajte na propagacijo DNS in šele nato preizkusite končni HTTPS.

Varno vračanje

Stari gostiteljski strežnik ne izklopite, dokler novi naslov ne deluje pravilno. Pri reševanju težav pošljite domeno, pričakovani cilj in javno vidne rezultate DNS, ne pa tudi podatkov za dostop do registratorja.

> Vrste DNS zapiskov za storitve

A/AAAA usmerjajo na naslove, CNAME je nadomestno ime, MX služi za e-pošto, TXT pa za preverjanja in druge namene.
faq/dns-record-types-for-services

Vsak tip ima svojo nalogo

A in AAAA zapisa kažeta naslove IP, CNAME ustvarja nadomestno ime za poddomeno, MX usmerja pošto, TXT vsebuje preverjanja in e-poštne politike, CAA pa omejuje izdajatelje certifikatov.

Pri kopiranju zapisov

  1. Natančno prepišite ime, tip in vrednost po navodilih storitve.
  2. CNAME ne dodajajte na naslov, ki že ima druge zapise, če pravila to prepovedujejo.
  3. DKIM vstavite pod izbiro ponudnika in DMARC običajno pod _dmarc.
  4. CAA nastavite previdno, saj lahko napačne vrednosti preprečijo izdajo certifikata.

Kaj storiti, če DNS ne deluje

Podprti ekipi pošljite ime gostitelja, vrsto zapisa, pričakovano vrednost in javno vidni rezultat. Ne posredujte gesel za dostop do DNS administracije ali posnetkov zaslona z API ključi.

> Propagacija DNS in TTL brez zagotavljanja minute

TTL (Time To Live) določa, koliko časa lahko resolverji shranijo stare podatke; med prehodom lahko obstajajo stare in nove različice rezultatov.
faq/dns-propagation-and-ttl

Propagacija je predpomnilnik, ne čarobno čakanje

Pri DNS ne obstaja fiksna obljuba glede časa propagacije. Po spremembi avtoritativnega DNS lahko različni resolverji še vedno vračajo stare in nove odgovore, dokler njihovi predpomnilniki ne potečejo v skladu z nastavitvami TTL. Zato se lahko rezultat razlikuje med omrežji, državami ali DNS resolverji.

Pri načrtovani spremembi

  1. Če to vaš ponudnik omogoča, zmanjšajte TTL pred načrtovano spremembo.
  2. Po izvedeni spremembi DNS ne spreminjajte ničesar več, dokler se ne izpraznijo predpomnilniki (cache).
  3. Preverite rezultate z več resolverji, če so različni.
  4. Zapišite čas spremembe, staro vrednost, novo vrednost in TTL.

Kaj poslati pri diagnostiki

Navedite ime strežnika (hostname), pričakovani cilj, prikazan stari odgovor, prikazan nov odgovor, TTL in čas spremembe. Ne posredujte podatkov za dostop do DNS računa.

> Načrtovanje shrambe za Workspace Suite

Pri načrtovanju shrambe upoštevajte uporabniške datoteke, skupne mape, različice, koš, predoglednike in pričakovano rast ekipe.
faq/nextcloud-storage-planning

Workspace Suite raste tudi zunaj vidnih datotek

Prostor porabljajo uporabniške datoteke, skupne mape, izbrisane datoteke, zgodovina različic, predogledi, sličice, sinhronizacija in importi. Če je prostor blizu omejitve, lahko nalaganje ali sinhronizacija ne uspe.

Pred naročilom kapacitete

  1. Izračunajte trenutne podatke uporabnikov in skupne mape.
  2. Dodajte rezervno mesto za različice, koš in predoglede.
  3. Upoštevajte velike uvoze, nove ekipe in pričakovano rast.
  4. Povečajte prostor za shranjevanje, preden uporabniki dosežejo omejitev.

V primeru težav z sinhronizacijo

Pošljite velikost storitve, približno izrabo, čas in vidno napako stranke. Ne pošiljajte osebnih datotek.

> Migracija repozitorijev v Gitea

Načrtujte migracijo Git repozitorijev skupaj z LFS, podmoduli, pravicami, ključi za razmnoževanje, webhooki in CI/CD.
faq/gitea-repository-migration

Migracija ni le kloniranje

Poleg zgodovine repozitorija je treba prenesti ali ponovno nastaviti lastnike, ekipe, zaščitene podružnice, zaščitene oznake, Git LFS, podmoduli, ključi za razmnoževanje, webhooki in povezave CI/CD.

Preverjanje pred prehodom

  1. Seznam repozitorijev, lastnikov in skupin uporabnikov.
  2. Preverite predmete Git LFS, podmodule, zaščito vej in oznak.
  3. Po prenosu testirajte kloniranje, potiskanje, Git LFS, podmodule in izvajanje CI.
  4. Stare varnostne oznake (tokene) izbrišite ali zamenjajte, ne da bi delili njihove vrednosti.

Občutljivi podatki pri migraciji

V podporo ne posredujte varnostnih oznak, zasebnih ključev, zasebnega dela ključa za razmislitev ali skrivnosti CI. Posredujte samo imena repozitorijev, vrsto integracije, vidno napako in informacije o tem, kaj je delovalo pred migracijo.

> Domena za pošiljanje v Listmonku

Za uspešno izvedbo kampanj je pomembno, da pripravite domeno ali poddomeno za pošiljanje, nastavite identiteto 'From', konfigurirate SPF, DKIM, DMARC, obravnavate odbite sporočila in omogočite možnost odjave.
faq/listmonk-sender-domain-basics

Dostavljivost se začne pri domeni

Listmonk potrebuje jasno identiteto pošiljatelja in DNS zapise, ki jih lahko poštni sistemi preverijo. SPF, DKIM in DMARC morajo biti usklajeni z domeno ali poddomeno, iz katere želite posredovati kampanje.

Pred prvo kampanjo

  1. Izberite domeno ali poddomeno za pošiljanje e-pošte ter nastavite identiteto 'Od'.
  2. Dodajte potrebne DNS zapise za preverjanje, vključno z SPF, DKIM in DMARC.
  3. Pred začetkom kampanje pošljite testna sporočila in preverite pravilnost dostave, obnašanje pri vračilu (bounce) ter povezave.
  4. Preverite možnosti za odjavo in funkcijo List-Unsubscribe pred pošiljanjem.

Mail dostopi ostanejo zunaj tiketa

Pri diagnostiki posredujte domeno, vrsto zapisa, javno vidno DNS vrednost in sporočilo o napaki. Ne posredujte gesel SMTP, API ključev, zasebnih DKIM ključev ali izvoznih datotek s podatki o naročnikih.

> Nastavitve delovanja za Classic Hosting

Classic Hosting omogoča avtomatski ali ročni način delovanja; procesor, RAM, pomnilnik, shramba, zadržanje varnostnih kopij, zadržanje arhivov, nalaganje datotek, predpomnilnik in dnevniki vplivajo na ceno in stabilnost.
faq/classic-hosting-runtime-settings

Samodejni način ni edina pravilna izbira

Avtomatski način delovanja pomaga pri prepoznanih projektih, vendar je ročni način primeren, če želite natančno izbrati Nginx, Apache, FrankenPHP ali določen jezikovni runtime. Uporabite izbirnik PHP samo tam, kjer ga podpirata izbrani runtime.

Nastavitve pred izvedbo

  1. Izberite samodejni ali ročni način delovanja (Runtime).
  2. Izberite različico PHP 8.2, 8.3 ali 8.4 samo za podprte scenarije.
  3. Nastavite procesor, RAM, disk, zadržanje varnostnih kopij in zunanjo arhivsko lokacijo glede na obremenitev in količino podatkov.
  4. Po izvedbi preizkusite nalaganja, predpomnilnik, dnevnike in vidne napake aplikacije.

Ko se aplikacija ne zažene

Posredujte način delovanja, jezik ali različico PHP, vidno napako, spremembe in približen čas izvedbe. Ne posredujte datotek .env, gesel, ključev ali celotnih dnevnikov z občutljivimi podatki.

> Katere informacije lahko varno posredujete službi za pomoč?

Najbolj koristne so številke naročil, imena storitev, domene, časovnice, javni strežniki, vrata, obdobje shranjevanja varnostnih kopij, obdobje shranjevanja Offsite Archive, nalaganje datotek, predpomnilnik, dnevniki, posnetki zaslona in vidne napake. Ne posredujte občutljivih podatkov.
faq/support-safe-information-to-share

Dobra zahteva vsebuje relevantne informacije, ne pa tudi zaupnih podatkov.

Podpora lahko hitreje odgovori, če prejme številko naročila, ime storitve, domeno, javni naslov ali vrata, čas nastanka težave, informacije o spremembah in natančno prikazano sporočilo o napaki.

Varna vsebina sporočila

  1. Opisujte korak, kjer je nastala težava.
  2. Pri gostovanju dodajte informacije o runtime okolju, programskem jeziku ali različici PHP, CPU, RAM-u, disku, naložbenih datotekah, predpomnilniku in logih, pri čemer izpustite občutljive podatke.
  3. Preden priložite posnetke zaslona, izbrišite ali prekrijte občutljive informacije.
  4. Če niste prepričani, ali je določen podatek primeren za vključitev v zahtevo, se najprej posvetujte, ne da bi ga poslali.

Kaj nikoli ne posredujte

Ne pošiljajte gesel, zasebnih ključev, obnovitvenih fraz, API ključev, shranjenih piškotkov (session cookies), izvoznih datotek podatavane baze, celotnih .env datotek ali popolnih logov z občutljivimi podatki.