Pyetjet dhe përgjigjet

Pyetjet më të ndërtuara

Udhëzime praktike të shkurtra për konfigurimin e shërbimit, aksesin dhe veprimet e zakonshme të klientit.

> Si funksionon sistemi i kreditit Cli>_?

Një bilanc i përbashkët me parapagesë financon të gjitha shërbimet e pranueshme dhe konsumohet vetëm kur janë aktive.
faq/prepaid-credit-how-it-works

Llogaria jote Cli>_ ka një bilanc të përbashkët krediti të parapaguar. Klientët e rinj të pranueshëm mund të kërkojnë Starter Credit vetëm pasi të kenë përfunduar verifikimin e detyrueshëm të llogarisë dhe kundër abuzimit. Shërbimet aktive të pranueshme e konsumojnë bilancin me kalimin e kohës. Vlerësimi mujor përdor 31 ditë dhe një shërbim i ri nis vetëm kur bilanci mbulon të paktën 7 ditë. Paralajmërimi i kuq shfaqet kur koha e vlerësuar bie nën 7 ditë; përndryshe shfaqet paralajmërimi portokalli kur bie nën 14 ditë.

Pas shterimit të bilancit, shërbimi pezullohet pas 7 ditësh, ndalon konsumimin e kreditit dhe fillon afati 7-ditor i ruajtjes dhe fshirjes. Para afatit të shfaqur mund ta rinisësh me kredit të mjaftueshëm. Anulimi i një shërbimi të provisionuar gjithashtu e pezullon dhe nis të njëjtin afat. Një shërbim në pritje dhe i paprovisionuar mund të çaktivizohet menjëherë. Pas afatit fillojnë çaktivizimi dhe heqja e shërbimit të provisionuar. Force delete e çaktivizon menjëherë shërbimin, anashkalon ruajtjen dhe nis heqjen nga runtime aktiv; përfundimi vjen pas përpunimit të deployment dhe GitOps. Backup-et dhe Offsite Archive kanë politika të veçanta ruajtjeje.

Shembull OpenCode me 9,90 EUR: 9,90 / 31 ≈ 0,319 EUR në ditë. Pas 10 ditësh të plota konsumohen rreth 3,19 EUR. Nëse bilanci fillestar ishte saktësisht 9,90 EUR dhe nuk kishte shërbime të tjera, mbeten rreth 6,71 EUR. Konsumi ndalet pas çaktivizimit.

Shembulli është vetëm ilustrues. Gjithmonë vlejnë çmimet aktuale të shfaqura në Cli>_.

> Si të gjeneroni një çelës publik SSH përmes komandës.

Krijo një çelës publik SSH për akses të sigurt në VPS. Ndaj vetëm çelësin publik me Cli>_; ruaje çelësin privat në pajisjen tënde.
faq/generate-public-ssh-key-sq

Përdojeni vetëm çelësin publik

Vendosni vetëm çelësin publik SSH në procesin e porosisë ose konfigurimit të shërbimit. Çelësi privat mbetet në kompjuterin tuaj dhe nuk dërgohet në mbështetje as nuk futet në një formular web.

Hapat

  1. Hap terminalin në kompjuterin tuaj.
  2. Ekzekutoni komandën: ssh-keygen -t ed25519 -C "your-email@example.com".
  3. Konfirmoni vendndodhjen e skedarit ose zgjidhni një rrugë të dytë. Asnjëherë mos dërgonini çelësin tuaj privat.
  4. Shfaq çelësin publik duke përdorur komandën: cat ~/.ssh/id_ed25519.pub.
  5. Kopjoni të gjithë rreshtin që fillon me ssh-ed25519 dhe ngjiteni në fushën "SSH public key" gjatë porosive ose konfigurimit të shërbimit.
  6. Kopjo të gjithë rreshtin që fillon me ssh-ed25519 dhe ngjitni atë në fushën "SSH Public Key".

PowerShell për Windows 10/11

  1. Hapni PowerShell ose Windows Terminal.
  2. Ekzekutoni komandën: ssh-keygen -t ed25519 -C "emaili-ju@example.com".
  3. Shtypni Enter për të ruajtur çelësin në C:\Users\emri-ju\\.ssh\id_ed25519, ose vendosni një rrugë të caktuar.
  4. Nëse Windows kërkon një fjalëkalim, përdorni një që mund ta ruani në mënyrë të sigurt, ose shtypni Enter për të skipuar atë për konfigurimin e thjeshtë.
  5. Shfaqeni çelësin publik me komandën: Get-Content $env:USERPROFILE\.ssh\id_ed25519.pub.
  6. Kopjoni vetëm linjën e plotë që fillon me ssh-ed25519. Mos kopjoni as mos ngarkoni fajllin e çelësit privat.
> Si të krijoni një çelës SSH grafikisht në Windows

Metodë grafike në Windows për krijimin e një çifti çeljesh SSH pa përdorur komandën.
faq/create-ssh-key-windows-gui-sq

Përdorni një mjet Windows dhe vendosni vetëm çelësin publik

Ju mund të krijoni një çift çelësish SSH vizualisht me një klient SSH Windows, si PuTTYgen. Cli>_ ka nevojë vetëm për çelësin publik. Ruani çelësin privat në kompjuterin tuaj dhe mos e ngarkoni kurrë përmes një forme web.

Hapat

  1. Instaloni PuTTY ose hapni PuTTYgen nëse është tashmë instaluar.
  2. Zgjidhni EdDSA/Ed25519, nëse është e disponueshme, ose RSA 4096, nëse instrumenti Ed25519 nuk ofrohet.
  3. Klikoni Generate dhe lëvizni miun mbi zonën bosh derisa çelja të krijohet.
  4. Shtoni një frazë kalimi nëse dëshironi mbrojtje shtesë lokale për çelësin privat.
  5. Ruani çelësin privat në kompjuterin tuaj dhe ruani atë të konfidencial.
  6. Kopjoni tekstin e çelësit publik dhe ngjiteni në fushën "SSH public key" në Cli>_.

Mos ndani të dhëna sekrete

Mos dërgonit skedarë .ppk, çelësa privatë, passphrase, fjalëkalime ose token te suporti apo në formularë.

> Sill domenin tënd

Mësoni se si ta lidhni domen ose subdomenin tuaj me një shërbim CLIopen përpara se të aktivizoni "Bring your own domain".
faq/lidh-domenin-tend

Çfarë bën ky cilësim

Përvojat tuaja me domainin juaj lejojnë që shërbimi të përgjigjet në emrin tuaj, p.sh., app.example.com, në vend të përdorimit vetëm të emrit të krijuar *.co.cliopen.cloud. DNS duhet të drejtohet te CLIopen para se emri i domenit të përdoret në mënyrë të sigurt nga shërbimi.

Para se të filloni

  1. Zgjidhni emrin e saktë të hostit që dëshironi, si p.sh., app.example.com. Përdorimi i një subdomini është opsioni më i thjeshtë.
  2. Hyni në konsolën e administrimit DNS të regjistruesit tuaj të domenit ose në panelin e kontrollit të ofruesit tuaj të DNS.
  3. Fshihni çdo rekord konfliktuar A, AAAA, CNAME, ALIAS ose redirect për atë emër hosti para se të shtoni hyrjen CLIopen.
  4. Ruani emrin host të krijuar nga CLIopen derisa emri juaj i vetëm është verifikuar dhe funksionon plotësisht.

Konfigurimi i rekomanduar i DNS për një nën-domenë

Krijoni regjistrime DNS për emrin host të saktë që do të futni në CLIopen. Për app.example.com, etiketës DNS është app. Drejtujeni atë në adresat e hyrjes së CLIopen që merrni nga mbështetja e CLIopen ose në dokumentacionin e shërbimit tuaj. Nëse ofruesi juaj kërkon një lloj regjistrimi, përdorni një regjistrim A për IPv4 dhe një regjistrim AAAA për IPv6 kur adresa janë të disponueshme.

Peshim:

app.example.com.  A     <Adresa IPv4 e CLIopen>
app.example.com.  AAAA  <Adresa IPv6 e CLIopen, nëse është e disponueshme>

Kur CLIopen ofron një shënjestër CNAME

Disa shërbime ju japin një emër host të krijuar, si service.customer.co.cliopen.cloud. Nëse udhëzimet për shërbimin tuaj kërkojnë explicitisht një regjistrim CNAME, krijoni një regjistrim të tillë si app.example.com CNAME service.customer.co.cliopen.cloud. Përdorni CNAME vetëm për nën-domenat, jo për domen kryesor/rrënjë, përveçse ofruesi juaj i DNS mbështet "ALIAS" ose "ANAME flattening".

Përdorimi i domenit kryesor

Për një domën si example.com pa subdomaine, shumica e ofruesve të DNS nuk lejojnë një regjistrim CNAME standard. Përdorni regjistrime A/AAAA që drejtojnë në adresat hyrëse CLIopen, ose përdorni funksionin ALIAS/ANAME të ofruesit tuaj nëse CLIopen ju ka dhënë një emër iperie.

Delegimi i të gjithë nënzonës

Nëse dëshironi që CLIopen të menaxhojë regjistrime nën një zonë nën-domeni si apps.example.com, krijoni regjistrime NS për këtë zonë në serveret nameserver CLIopen që merrni. Mos ndryshoni serveret nameserver për gjithë domenin, përveçse dëshironi qëllimisht që CLIopen (ose një shërbim tjetër DNS) të menaxhojë të gjitha regjistrimet.

Lista e kontrolimit

  1. Presni për përhapjen e DNS-it. Ndryshimet e vogla shpesh shihen brenda pak minutave, por disa ofrues e ruajnë më gjatë në cache.
  2. Sigurohuni që emri i host-it drejtohet te destinacioni CLIopen dhe jo tek një ofrues i vjetër.
  3. Në fushën 'Bring your own domain', vendosni emrin e plotë të domenit (hostname), pa përfshirë `https://` dhe pa asnjë rrugë.
  4. Pas përditësimit, testoni `https://app.example.com` në shfletuesin tuaj.
  5. Ruani regjistrimet e vjetra DNS vetëm nëse nuk përputhen me emrin e ri të domenit (hostname).
> Si të transferoni një zonë DNS në CLIopen

Delegoni domenin tek ns1.cliopen.com dhe ns2.cliopen.com, që CLIopen të publikojë regjistrat për gjithë zonën.
faq/delegimi-i-zones-dns

Çfarë do të thotë transferimi i zonës këtu

Kur flasim për transferimin e DNS-it, kjo nënkupton ndryshimin e servereve autoritative tek regjistratori i domenit tuaj. Pas delegimit te CLIopen, rekordet e DNS që shtoni në CLIopen publikohen nga serveret tona autoritative.

Para ndryshimit të nameservereve

  1. Kopjoni regjistrimet ekzistuese DNS që ju nevojiten ende, siç janë regjistrimet për uebin, postën elektronike, verifikimet, SPF, DKIM, DMARC dhe regjistrimet e shërbimit.
  2. Shtoni zonën në CLIopen DNS. Nëse delegimi nuk është gati ende, CLIopen e ruaj, por nuk e aktivizon për klientët derisa validimi të kalojë.
  3. Krijoni regjistrimet e nevojshme në CLIopen DNS para ndryshimit të servereve të emrit, kur është e mundur.
  4. Sigurohuni se regjistrimi CAA është konfiguruar korrektsisht, pasi vlerat e gabuara mund të parandalojnë emetimin e certifikatave.

Delegoni zonën

  1. Hapni konfigurimin e domenit te regjistratorit tuaj, p.sh., example.com.
  2. Gjeni shërbimet Nameservers, delegimin DNS ose konfigurimet Autoritative DNS.
  3. Zgjidhni nameserverët aktualë me vlerat ns1.cliopen.com dhe ns2.cliopen.com.
  4. Ruani ndryshimin dhe prisni përhapjen në regjistër dhe resolverë.

Validimi

Kthehuni te CLIopen DNS dhe klikoni "Verifikoni delegimin". Kur rekordet publike NS tregojnë ns1.cliopen.com dhe ns2.cliopen.com, zona futet në radën e sinkronizimit dhe rekordet bëhen aktive nga CLIopen.

> Regjistrimi i llogarisë dhe hyrja e parë

Krijoni një llogari pune, plotësoni detajet e faturimit dhe siguroni që ekipi juaj të ketë akses në adresën e emailit.
faq/account-registration-and-login

Një llogari për porositë dhe menaxhimin

Përdorni këtë llogari si një vend i qëndrueshëm për porositë, detajet e faturimit, shërbimet, domenet dhe komunikimin me mbështetjen. Preferohet përdorimi i një adrese postare pune, të cilën ekipi juaj mund ta aksesojë edhe pas ndryshimeve në stafin.

Para porosisë së parë

  1. Regjistrohu me adresën tënde elektronike pune.
  2. Përfundoni verifikimin e adresës së postës elektronike, nëse kërkohet.
  3. Plotësoni detajet e faturimit përpara se të porosisni shërbime me pagesë.
  4. Aktivizoni autentikimin me dy faktorë sa më shpejt pasi të bëni hyrjen për herë të parë.

Akses për ekipin

Mos dërgonini fjalëkalimet kolegëve përmes chat-it ose email-it. Nëse disa persona kanë nevojë për akses, përdorni një menaxher fjalëkalimesh të brendshëm ose kërkoni procedurën e rekomanduar për ekipin; mbështetja nuk ka nevojë për fjalëkalimin tuaj as për tokenin e hyrjes.

> Vlerësimi mujor, vjetor dhe konsumi ditor

Çmimet mujore dhe vjetore shërbejnë për krahasim; në rastet e abonamenteve parapagues, konsumi real aplikohet çdo ditë pas konfirmimit të ndryshimeve.
faq/billing-periods-and-credit-burn

Vlerësimi nuk është kalendar faturimi

Përdorni vlerën mujore si një krahasim për 31 ditë dhe atë vjetore si një krahasim për 372 ditë. Konsumi real i kreditit për shërbimet parapaguara ndodh sipas kohës së aktivizimit të shërbimit dhe konfigurimit të konfirmuar.

Çfarë duhet të verifoni kur ndryshoni çmimin

  1. Krahasoj konsumin ditor para dhe pas ndryshimit.
  2. Një CPU, RAM, disk ose opsione me pagesë më të lartë mund të rrisin konsumin e ditur.
  3. Ndryshimi hyn në fuqi vetëm pasi konfirmoni, paguani (nëse është e nevojshme) dhe aplikohet.
  4. Për qëllimet e kontabilitetit, ruani konfirmimet e porosisë dhe historinë e kreditit.

Për një zgjidhje të saktë, përcaktoni periudhën e caktuar

Për mbështetjen teknike, numri i porosisë, emri i shërbimit dhe datat për të cilat dëshironi të verifikoni përdorimin janë të nevojshme. Mos dërgoni detaje bankare, ekstrakte të plotë pagimi ose imazhe me informacione personale që nuk ju nevojiten.

> Gjendja e porosisë pas pagesës

Porosia mund të presë konfirmim nga ofruesi i pagesës; mos krijoni një kopje derisa e para të jetë qartë e skaduar ose e anuluar.
faq/order-status-and-payment-confirmation

"Pending" nuk do të thotë gjithmonë dështim

Pas kthimit nga faqja e pagesës, porosia mund të presë ende për konfirmim nga ofruesi i pagesave. Deri sa statusi nuk është shpallur qartësisht si i pasuksesshëm ose i skaduar, një porosi e dyfishtë mund të komplikojë procesin e lidhjes.

Çfarë duhet të bëni pas pagesës

  1. Pas përfundimit të pagesës, kthehu te Cli>_.
  2. Kontrolloni statusin e porosisë në llogari tuaj dhe çdo mesazh që mund të ketë lidhje me pagesën.
  3. Nëse porosia ende është në pritje, jepni kohë ofruesit për të konfirmuar.
  4. Nëse hasni ndonjë problem, kontaktoni mbështetjen dhe dërgojeni numrin e porosisë dhe referencën e pagesës, nëse është e disponueshme.

Çfarë nuk duhet dërguar

Mbështetja nuk ka nevojë për të dhëna nga karta e kreditit, fjalëkalimin tuaj ose dokumentin bankar plotësisht. Mjaftojnë numri i porosisë, koha e pagesës, statusi i dukshëm dhe një screenshot i maskuar nëse shfaqet ndonjë gabim.

> Të dhënat që përshpejtojnë konfigurimin e shërbimit

Përgatisni emrin e shërbimit, domenin, madhësinë e ruajtjes, adresën së postës elektronike për akses dhe çelësin publik SSH; të dhënat sekrete nuk duhet të futen në formularë.
faq/service-setup-information-needed

Vlerat publike të sakta kursejnë kohë

Formularët e porosisë përdoren për vlera publike ose jo-sekrete: emri i shërbimit, domeni, plani DNS, madhësia e ruajtjes, CPU, RAM, adresa e postës elektronike administrative ose çelësi publik SSH. Fjalëkalimet, çeljet private dhe tokenet nuk duhet të futen në formular.

Përgatituni para se të klikoni "Porosi"

  1. Zgjidh një emër shërbimi që ekipi juaj mund ta njohë.
  2. Vendosni nëse do të përdorni një domen personal ose një hostname të përkohshëm.
  3. Përgatisni një çelës publik SSH, nëse shërbimi e kërkon.
  4. Kontrolloni kapacitetin e ruajtjes dhe burimet sipas aplikacionit që do të ekzekutoni.

Mos dërgonte informacione konfidenciale

Nëse nuk jeni të sigurt nëse një informacion është i konfidencial, pyetni pa e dërguar atë. Mos dërgoni çelësa privatë, fjalëkalime, tokena, dump-e të bazave të dhënave dhe fajlle konfigurimi të kompleta në chat ose në porosi.

> Ndryshmi e CPU-së, RAM-it, disqit ose ruajtjes pas porosisë

Modifikoni shërbimin ekzistues përmes detajeve të tij, dhe jo me një porosi të re. Kur ndryshoni burimet, çmimi, çmimi i shërbimit, konsumi ditor i kreditit, rihaptimi dhe risku i ndërprerjes mund të ndryshohen.
faq/change-service-resources-after-order

Modifikoni një shërbim ekzistues, mos krijoni një të ri

Nëse shërbimi është aktiv, bëni ndryshimet nga detajet e tij. Një porosi e re mund të krijojë një shërbim të ri në vend që të modifikojë njërin ekzistues dhe mund të ndryshojë çmimin, konsumin ditor të kreditës dhe sjelljen e sistemit pas konfirmimit, pagesës (nëse është e nevojshme) dhe zbatimit të ndryshimeve.

Para se të konfirmoni ndryshimin

  1. Shihë CPU, RAM, diskun, ruajtjen e rezervave dhe ruajtjen e Arkivës së Jashtme aktuale.
  2. Kontrollo çmimin e ri dhe ndikimin në kreditën ditore.
  3. Lexo njoftimet për ristartim, mirëmbajtje ose ndërprerje.
  4. Përpara një ndryshimi që mund të sjellë rrezik, eksportoni vetëm të dhënat e rëndësishme.

Çfarë bën nëse ndryshimet nuk kryhen siç pritej

Dërgoni emrin e shërbimit, kohën e ndryshimit, statusin e dukshëm dhe mesazhet e gabimeve. Mos dërgonini çelsat private, fjalëkalimet ose tokenet; për diagnozë mjafton konteksti publik dhe një ekran i maskuar.

> Anulimi i shërbimit dhe data e fshirjes së të dhënave

Shërbimi i krijuar fillimisht pezullohet, duke treguar një afat të konfigurueshëm për fshirje, dhe më pas mund të pastrohet përfundimisht.
faq/cancel-service-and-data-retention

Anulimi nuk është gjithmonë fshirje e menjëhershme

Një shërbim i krijuar pezullohet fillimisht dhe tregon një afat të konfigurueshëm për fshirjen, gjatë të cilit mund të kryhet riaktivimi ose eksporti. Porositë e papaguara që nuk janë aktivizuar ende mund të kenë një sjellje të ndryshme, ndërsa pastrimi i përhershëm ndodh vetëm pas skadimit të periudhës së jetësës.

Para se ta anulloni, verifikoni

  1. Krijo eksportin tuaj për të dhënat që duhet të ruani gjatë kohës.
  2. Lexoni datën dhe orën e planifikuar për fshirjen kur shërbimi është i pezulluar.
  3. Mos ngatërroni kopiat e rezervuara dhe arkivimin jashtë vendit me fshirjen e ciklit të jetës së shërbimit.
  4. Nëse nuk jeni të sigurt, kontaktoni mbështetjen para afatit të fshirjes.

Riprirja pas një kohe të caktuar mund të mos jetë e mundur

Pas skadimit të terminit të dukshëm, të dhënat nuk duhet të konsiderohen si të disponueshme. Kur pyesni, dërgoni numrin e porosisë dhe emrin e shërbimit, jo eksportet e bazës së të dhënave as kredencialet sekrete.

> Rezerva dhe kërkesat për rikthimin e të dhënave

Rezervat shërbejnë për rikuperim operativ, jo si zëvendës i eksportit; rikthimi mund të mbishkruajë të dhëna më të reja.
faq/backups-and-restore-requests

Backup nuk është arkiv apo eksport

Kohëzgjatja e ruajtjes së kopjave rezervë varet nga produkti dhe opsionet e zgjedhura. Kopia rezervë ndihmon në rikuperimin pas një defekti, por nuk zëvendëson eksportin tuaj, arkivin auditues ose Offsite Archive. Ripërqitja mund të shkruajë mbi ndryshimet më të reja.

Si të përgatisni një kërkesë rikuperimi

  1. Shenoni emrin e shërbimit dhe numrin e porosisë.
  2. Përshkruani kohën e afërt për të cilën dëshironi të rikthjani.
  3. Shpjegoni nëse duhet të kryhet një rikuperim i plotë ose vetëm i një pjese, nëse është e mbështetur.
  4. Përfshijeni një gabim të dukshëm ose kontekst pa fjalëkalime, tokena ose çelësa privatë.

Para rimëkëmbjes, vlerëso ndikimin

Një rikuperim mund të prekë gjithë shërbimin ose vetëm një pjesë dhe mund të zbulojë ndryshime të reja. Informoni ekipin përpara se të konfirmoni rikuperimin dhe eksportoni atë që nuk doni ta humbisni.

> Për çfarë shërben Offsite Archive

Offsite Archive ruan kopje arkivore në distancë, të ndara nga backup-et e shkurtra dhe nga cikli i fshirjes së shërbimit.
faq/offsite-archive-purpose

Arkiv jashtë operimit ditor

Offsite Archive krijohet për kopje arkivore në distancë dhe ruajtjen e të dhënave afatgjatë. Nuk është një disk aktiv për aplikacione, nuk zëvendëson eksportin lokal dhe nuk është i njëjtë me backup-et operative të shkurtra.

Kur ta aktivizoni

  1. Përdorni arkivën jashtme për kopjet e arkivuara, eksportet dhe materialin më të vjetër, jo për ruajtjen aktive të aplikacioneve.
  2. Zgjidhni ditët e ruajtjes që përputhen me rregullat tuaja ose objektivin e rikuperimit.
  3. Merrni parasysh MB-ditë si MB të ruajtur shumëzuar me ditët e ruajtura.
  4. Për të dhëna të mëdha, planifikoni arkivimin së bashku me procesin tuaj të eksportimit.

Si të mendoni për çmimin

Baza është MB-ditë: sa data janë ruajtura dhe për sa ditë mbahen. Çmimi shfaqet klientit si EUR/GB/muaj dhe rezultati rrethoret në centa.

> Zgjidhja e CPU-së, RAM-it dhe disqit për VPS

Madhësia e VPS-së zgjidhet sipas aplikacionit, bazës së të dhënave, cache-it, logeve dhe rritjes; OOM ose shkëmbimi janë shenja se ju nevojitet më shumë RAM.
faq/vps-cpu-ram-and-disk-sizing

Filloni sipas ngarkesës reale, jo ndjesave

Një faqe e thjeshtë ka nevojat e saja, ndryshe nga një bazë të dhënash, një aplikacion Java, kërkimi ose një kontejner me build-e. Kur planifikoni, vini në konsideratë memorien e aplikacioneve, cache-in, databazën, log-et, ngarkimet dhe rezervën për rritje.

Shenja që plani është i vogël

  1. Rrisni RAM-in kur shihni mesazhe OOM (Out Of Memory), procese që ndërpriten, ose përdorim i lartë i swapit.
  2. Rritni CPU-në për një ngarkesë të vazhdueshme llogaritëse, kompresim, buildime ose aplikacione me aktivitete të shumta.
  3. Rrisni kapacitetin e disqit para se sistemi i fajllave, logat ose baza e të dhënave të mbushnin.
  4. Pas çdo ndryshimi, kontrolloni nëse aplikacioni nuk has më në kufirin fillestar.

Çfarë duhet dërguar kur keni pyetje lidhur me konfigurimin

Informacionet që mund të ndihmojnë përfshijnë emrin e shërbimit, tipin e aplikacionit, një gabim të dukshëm, kohën e afërt të problemit dhe CPU-në, RAM-in dhe diskun aktualisht të zgjedhur. Mos dërgonini fjalëkalimet, çelsat privatë ose fajllat e konfigurimit të brendshëm.

> Kur është e nevojshme një IP publik për VPS

Një IP publik i dedikuar ndihmon në listat e lejuara, aksesin hyrës (inbound), një burim të qëndrueshëm dalës (outbound) ose shërbime që janë të lidhura me adresën.
faq/vps-public-ip-options

Së pari, kuptoni drejtimin e komunikimit

Një IP publik nuk është gjithmonë i nevojshëm për çdo shërbim. Zakonisht përdoret për të plotësuar kërkesat e partnerëve eksternë, ofruesve ose firewall-eve për një listë lejuar (allowlist), një burim stabil dalës (outbound) ose akses hyrës (inbound) në një port të caktuar.

Pyetje para porosisjes së një IP

  1. Pyet partnerin nëse lejon trafikun hyrës, dalues ose të dy drejtimet.
  2. Përdorni emrat DNS në vend të adresave numerike kur është e mundur.
  3. Hapni vetëm portat që aplikacioni juaj i nevojon vërtet.
  4. Dërgoj kërkesën për allowlist te mbështetja para se të ndryshoni aksesin e prodhimit.

Çfarë duhet lënë të mbyllur

Një IP publike nuk do të thotë hapja e të gjitha porteve. Sugjeroni aksesin vetëm për shërbimet minimale të nevojshme dhe mos dërgonni fjalëkalime, çelsa private ose rregulla të brendshme të firewall si imazhe me vlera sekrete.

> Qasja e përbashkët SSH për VPS

Pa një adresë IP publike dedikuar, VPS lidhet përmes një pike hyrëse SSH të ndarë me një port të lartë; me një adresë IP publike, ju mund të keni gjithashtu SSH drejtëpërpara në atë adresë.
faq/shared-ssh-access-for-vps

Pse SSH i ndarë përdor një port të lartë

Shumë VPS mund të përdorin të njëjtën adresë publike SSH. Prandaj, çdo shërbim merr portin e vet të lartë; ky port është pjesë e rrugës drejt VPS tuaj. Pa të, adresa e përbashkët SSH nuk do ta dinte cilin shërbim ta arrijë.

Si të lidheni sipas llojit të aksesit

  1. Për një lidhje SSH të përbashkët, kopjoni emrin e përdoruesit SSH, hostin publik dhe portin nga faqja e shërbimit.
  2. Përdorni formatin ssh -p <port> <username>@<public-host>.
  3. Nëse shërbimi ka një IP publike të dedikuar, mund të ketë edhe një pikë përfundore SSH drejt kësaj IP ose emrit DNS që i përket.
  4. Përdorni çelësin privat vetëm lokal përmes klientit tuaj SSH ose agjentit; për mbështetje, ju nevojiten vetëm hosti publik, porta, emri i përdoruesit dhe një gabim i dukshëm.

Kur keni blerë një adresë IP publike

IP publike nuk zëvendëson endpointin e përbashkët SSH; ajo ofron një mënyrë të veçantë hyrjeje që është e përshtatshme për listat e lejuara, monitorimin ose lidhjen direkte. Në praktikë, mund të shihni dy lloje hyrjeje SSH: host i përbashkët me portë të lartë dhe host ose IP direkt për një shërbim me IP publike.

> Kontrolloni përpara se të lidheni me domen tuaj

Para se të ndryshoni domenin, verifikoni DNS-in autoritativ, emrin e saktë të hostit, tipin e rekordit, nëse është domën kryesore ose subdomën dhe rekordet e vjetra që mund të shkaktojnë konflikte.
faq/custom-domain-readiness-checklist

Vendosni emrin e saktë të hostit

Fillimisht, përcaktoni nëse lidheni me domen kryesor si example.com ose një subdomën si app.example.com. Çdo variant mund të kërkojë një lloj regjistrimi DNS të ndryshëm, kufizime të ndryshme nga ofruesi i DNS dhe verifikim te regjistratori.

Para ndryshimit të DNS

  1. Kontrolloni se ku redaktohen regjistrimet autoritative DNS për domen.
  2. Hiq ose modifikoni regjistrimet konfliktuese A/AAAA, CNAME, ALIAS, ANAME ose redirect.
  3. Përdorni tipin e regjistrimit të rekomanduar për shërbimin dhe hostname-in specifik.
  4. Pas ndryshimit, prisni përhapjen e DNS dhe më pas testoni HTTPS-in final.

Planifikimi i rikthimit

Mos fikini hostingun origjinal derisa emri i ri i hostit të funksionojë siç duhet. Kur zgjidhni një problem, dërgoni domenën, adresën e destinuar dhe rezultatet e DNS-it që janë shfaqur, por mos dërgonit hyrjet në regjistrues.

> Llojet e regjistrimeve DNS për shërbime

Regjistrimet A/AAAA drejt adresave, CNAME krijon një alias, MX përdoret për postë dhe TXT për verifikime, SPF, DKIM ose DMARC.
faq/dns-record-types-for-services

Çdo record ka rol të veçantë

A dhe AAAA tregojnë adresat IP, CNAME krijon një alias për një subdomain, MX drejton postën, TXT përmban verifikime dhe politika të emaileve, ndërsa CAA kufizon autoritetet e certifikatave.

Kur kopjoni regjistrime

  1. Kopjoni emrin, tipin dhe vlerën saktë sipas udhëzimeve të shërbimit.
  2. Mos vendosni CNAME në hostname që tashmë ka regjistrime të tjera, nëse rregullat e DNS-it e ndalojnë këtë.
  3. Vendosni DKIM nën selectorin e ofruesit dhe DMARC zakonisht nën _dmarc.
  4. Vendosni CAA me kujdes, sepse vlerat e gabuar mund të bllokojnë lëshimin e certifikatës.

Kur DNS nuk funksionon

Dërgojeni në mbështetje emrin e hostit, tipin e regjistrimit, vlerën e pritur dhe rezultatin publikisht të dukshëm. Mos dërgonni login për administrimin DNS as pamjet me token API.

> Propagimi i DNS dhe TTL pa garanci për minuta

TTL (Time To Live) përcakton kohën që serverët e kërkesave DNS mbajnë një përgjigje të vjetër; gjatë tranzicionit, përgjigjet e vjetra dhe ato të reja mund të ekzistojnë paralel.
faq/dns-propagation-and-ttl

Propagimi është një proces cache, jo magji

Në DNS, nuk ka një garanci fiksë për kohën e propagimit. Pas ndryshimit të regjistrimeve DNS autoritative, rezolutorët e ndryshëm mund të vazhdojnë të kthejnë përgjigje të vjetra dhe të reja derisa cache-t e tyre të skadojnë sipas TTL. Prandaj, rezultati mund të ndryshojë midis rreteve, vendeve ose rezolutorëve DNS.

Gjatë një ndryshimi të planifikuar

  1. Nëse ofruesi juaj i DNS e lejon, zvogëloni TTL-in para një ndryshimi të planifikuar.
  2. Bëni ndryshimin një herë dhe evitoni redaktimet e përsëritura derisa cache-t skadojnë.
  3. Testoni nga më shumë se një resolver ose rrjet kur përgjigjet janë të ndryshme.
  4. Shënojeni kohën e ndryshimit, vlerën e vjetër, vlerën e re dhe TTL-në.

Çfarë duhet dërguar gjatë diagnostikimit

Përshkruani emrin e hostit, qëllimin e pritur, përgjigjen e vjetër të dukshme, përgjigjen e re të dukshme, TTL-në dhe kohën e ndryshimit. Mos dërgoni kredencialet për llogarinë DNS as shënime të brendshme nga ofruesi.

> Planifikimi i hapësirës së ruajtjes për Workspace Suite

Për kapacitetin total, përfshijeni fajllat e përdoruesve, folderët e ndarë, versionet, koshin, paraqitjet (thumbnails), overhead-in e sinkronizimit dhe rritjen e grupit.
faq/nextcloud-storage-planning

Workspace Suite rritet edhe përtej fajllave të dukshëm

Hapësira përdoret nga fajllat e përdoruesve, folderët e ndarë, fajllat e fshirë, historiku i versioneve, paraqitjet, miniatura, pamjet parazgjedhura, klientët sinkronizimi dhe importet. Kur ruajtja është afër limitit, ngarkimet ose sinkronizimet mund të dështojnë.

Para porosisë së kapacitetit

  1. Mbledhni të dhënat aktuale të përdoruesve dhe dosjet e përbashkëta.
  2. Shtoni një rezervë për versionet, košin, pamjet paraprake dhe aktivitetin e sinkronizimit.
  3. Merrni parasysh importet e mëdha, ekipet e reja dhe rritjen e pritur.
  4. Rrit kapacitetin para se përdoruesit të arrijnë limitin.

Probleme me sinkronizimin

Dërgo madhësinë e shërbimit, përdorimin e parashikuar, kohën e problemit dhe një ekran gabimi që shihet nga klienti. Mos dërgoni fajlle personale, fjalëkalime ose eksporte të dhënave të përdoruesve, përveç nëse mbështetja i kërkon shprehimisht atë mënyrë të sigurt.

> Migrimi i depo-ve në Gitea

Planifikoni migrimin e depo-ve Git së bashku me LFS, submodule, të drejtat, çeljet për shpërndarje, webhooks dhe CI/CD.
faq/gitea-repository-migration

Migrimi nuk është vetëm një klonim i Git

Përveç historikut të repositorit, duhet të transferohen ose të rigjendësohen pronarët, ekipet, degët e mbrojtura, etiketat e mbrojtura, Git LFS, submodule-t, çelsjet e shpërndarjes, webhooks dhe lidhjet CI/CD.

Kontrolli para ndryshimit

  1. Listoni depozitat, pronarët, grupet dhe llogaritë e automatizimit.
  2. Kontrolloni objektet Git LFS, submodule-t, mbrojtjet e degëve dhe mbrojtjet e etiketave.
  3. Pas transferimit, testoni klonimin, dërgimin, Git LFS, submodule-t dhe ekzekutimin e CI.
  4. Anulloj ose zhdrypuj tokenët e vjetër pas përfundimit të migrimit, pa i ndarë vlerat e tyre.

Të dhëna sensitive gjatë migrimit

Mos dërgoni tek mbështetja asnjë token, çelës privat, pjesën private të çelësit të shpërndarjes ose sekrete CI. Mjaftojnë emrat e repositoreve, tipi i integrimit, një gabim i dukshëm dhe informacioni se çfarë ka funksionuar para migrimit.

> Domaini i dërgimit për Listmonk

Për kampanjat tuaja, përgatisni një doman dërgimi ose subdomain, identitetin "From", SPF, DKIM, DMARC, trajtimin e mesazheve të kthyer dhe detajet për anullimin e abonimit.
faq/listmonk-sender-domain-basics

Dorëzimi fillon nga domeni

Listmonk funksionon më mirë kur domeni i dërguesit ka regjistrime DNS të sakta, një identitet "From" dhe konfigurime SPF, DKIM dhe DMARC që janë në përputhje me domenin ose subdominin nga ku do të dërgohen fushatat.

Para se të filloni kampanjën tuaj

  1. Zgjidh domainin ose subdomanin e dërguesit dhe emrin From.
  2. Publiko regjistrimet e DNS për verifikim, SPF, DKIM selector dhe DMARC.
  3. Dërgo mesazhe testimi para një fushate të vërtetë dhe kontrollo vendosjen në spam, sjelljen e bounce-it, Return-Path dhe lidhet.
  4. Kontrolloni detajet e anullimit dhe List-Unsubscribe përpara dërgimit përfundimtar.

Sekretet e emaileve nuk duhet të jenë pjesë e biletës

Kur diagnostikoni, ju lutemi dërgojeni emrin e domenit, tipin e regjistrimit, vlerën publike të DNS dhe mesazhin e gabimit. Mos dërgonni fjalëkalimet SMTP, tokenat API, çeljet private DKIM ose eksportet e adresave me të dhëna personale.

> Cilësimet e kohës së ekzekutimit për Classic Hosting

Classic Hosting mund të funksionojë në modalitet automatik ose manual; CPU, RAM, memorie, ruajtje, ruajtja e kopjave, ruajtja e Arkivës Offsite, ngarkimet, memoria cache dhe logat ndikojnë në çmimin dhe stabilitetin.
faq/classic-hosting-runtime-settings

Modi automatik është i dobishëm, por jo gjithmonë zgjedhja e duhur

Mjedisi automatik ndihmon për projektet PHP, Node.js, Java, Python, .NET, Go dhe Ruby që njihen automatikisht. Mjedisi manual përshtatet kur dëshironi kontroll mbi Nginx, Apache, FrankenPHP ose gjuhën e caktuar. Zgjedhja e versionit të PHP vlen vetëm aty ku mjedisi e mbështet.

Konfigurimet para publikimit

  1. Zgjidh mes një ambienti automatik ose manual, bazuar në frameworkun dhe mënyrën e ndërtimit.
  2. Përdorni PHP 8.2, 8.3 ose 8.4 vetëm për skenarët e mbështetur nga PHP.
  3. Konfigurojeni CPU-në, RAM-in, diskun, ruajtjen e kopjeve dhe arkivimin jashtë vendit në bazë të trafikut dhe të dhënave.
  4. Pas publikimit, testoni ngarkimet, memorinë cache, regjistrimet dhe gabimet e dukshme të aplikacionit.

Kur aplikacioni nuk fillon

Dërgojini modalitetin e ekzekutimit, gjuhën ose versionin e PHP-së, një gabim të dukshëm, ndryshimet që janë bërë dhe kohën e afërt të publikimit. Mos dërgoni fajllat .env, fjalëkalimet, tokenet as regjistrimet e plota me vlera të ndjeshme.

> Cilët informacion mund t'i dërgoni sigurt mbështetjes

Numrat e porosisë, emrat e shërbimeve, domenet, kohat, hostet dhe portet publike, si edhe gabimet e dukshme janë të dobishëm; mos dërgonit sekrete.
faq/support-safe-information-to-share

Një kërkesë e mirë përmban informacion relevant, jo të fshehtë.

Departamenti i mbështetjes mund të reagojë më shpejt nëse merr numrin e porosisë, emrin e shërbimit, domenin, hostin publik ose portin, kohën e problemit, ndryshimet që janë bërë dhe një mesazh të qartë të gabimit.

Detaje të sigurta në mesazh

  1. Specifikoni numrin e porosisë, emrin e shërbimit, domenit, kohën dhe hapin ku ndodhi problemi.
  2. Për problemet me hosting: përfshini mënyrën e funksionimit, gjuhën ose versionin e PHP-së, CPU-në, RAM-in, diskun, ngarkimet, cache dhe logat pa vlera sekrete.
  3. Maskoni ekranet para dërgimit.
  4. Nëse nuk jeni të sigurt se një informacion i takon ose jo biletës, pyesni para se ta dërgoni.

Çfarë nuk duhet asnjëherë të dërgohet

Mos dërgonini fjalëkalimet, çeljet private, API tokenet, frazat e rikuperimit, eksportet e bazave të dhënave ose logat e plota me vlera sensitive.