Biežāk uzdotie jautājumi

Bieži uzdotie jautājumi

Praktiski īsi ceļveži pakalpojumu konfigurēšanai, piekļuvei un parastajām klientu darbībām.

> Kā darbojas Cli>_ kredīta sistēma?

Viens kopīgs priekšapmaksas atlikums finansē visus atbilstošos pakalpojumus un tiek tērēts tikai to aktīvas darbības laikā.
faq/prepaid-credit-how-it-works

Tavam Cli>_ kontam ir viens kopīgs priekšapmaksas kredīta atlikums. Atbilstoši jaunie klienti var pieprasīt Starter Credit tikai pēc obligātās konta un ļaunprātīgas izmantošanas novēršanas pārbaudes pabeigšanas. Aktīvi atbilstošie pakalpojumi atlikumu pakāpeniski patērē. Mēneša aprēķinā izmanto 31 dienu, un jaunu pakalpojumu var sākt tikai tad, ja atlikums sedz vismaz 7 dienas. Sarkans brīdinājums parādās, kad prognozētais darbības laiks nokrītas zem 7 dienām; pretējā gadījumā oranžs brīdinājums parādās, kad tas nokrītas zem 14 dienām.

Pēc atlikuma izsīkšanas pakalpojumu pēc 7 dienām aptur, kredīta patēriņš beidzas un sākas 7 dienu glabāšanas un dzēšanas termiņš. Pirms redzamā termiņa to var restartēt ar pietiekamu kredītu. Nodrošināta pakalpojuma atcelšana arī to aptur un sāk to pašu termiņu. Gaidošu, vēl nenodrošinātu pakalpojumu var deaktivizēt uzreiz. Pēc termiņa sākas nodrošinātā pakalpojuma deaktivizēšana un izņemšana. Force delete pakalpojumu deaktivizē uzreiz, izlaiž glabāšanu un sāk izņemšanu no aktīvā runtime; pabeigšana seko deployment un GitOps apstrādei. Rezerves kopijām un Offsite Archive ir atsevišķi glabāšanas noteikumi.

OpenCode piemērs par 9,90 EUR: 9,90 / 31 ≈ 0,319 EUR dienā. Pēc 10 pilnām dienām patērēti aptuveni 3,19 EUR. Ja sākuma atlikums bija tieši 9,90 EUR un citu pakalpojumu nebija, paliek aptuveni 6,71 EUR. Pēc atspējošanas patēriņš apstājas.

Piemērs ir tikai ilustratīvs. Vienmēr spēkā ir aktuālās Cli>_ parādītās cenas.

> Kā ģenerēt publisku SSH atslēgu, izmantojot komandrindu

Izveidojiet publisko SSH atslēgu, lai droši piekļūtu VPS serverim. Kopīgojiet tikai publisko atslēgu ar Cli>_; privāto atslēgu glabājiet savā ierīcē.
faq/generate-public-ssh-key-lv

Publiskais atslēgas pāris: kopējiet tikai publisko daļu

Ievadiet tikai publisko SSH atslēgu pasūtījuma vai pakalpojuma iestatījumos. Privātā atslēga paliek jūsu datorā un netiek nosūtīta atbalsta dienestam vai ievietota tīmekļa formā.

Instrukcijas

  1. Atveriet termināli savā datorā.
  2. Izpildiet komandu: ssh-keygen -t ed25519 -C "your-email@example.com".
  3. Apstipriniet faila saglabāšanas vietu vai izvēlieties savu ceļu. Nekad neizsūtiet savu privāto atslēgu.
  4. Parādiet publisko atslēgu, izmantojot komandu: cat ~/.ssh/id_ed25519.pub.
  5. Nokopējiet visu rindu, kas sākas ar ssh-ed25519, un ievietojiet to SSH publiskā atslēgas laukā pasūtījuma vai pakalpojuma iestatīšanas laikā.
  6. Nokopējiet visu rindu, kas sākas ar ssh-ed25519, un ievietojiet to SSH publiskā atslēgas laukā.

Pārbaudi pirms ielīmēšanas

  1. Atveriet PowerShell vai Windows Terminal.
  2. Izpildiet komandu: ssh-keygen -t ed25519 -C "your-email@example.com".
  3. Nospiediet Enter, lai saglabātu atslēgu ceļā C:\Users\your-user\.ssh\id_ed25519, vai ievadiet savu custom ceļu.
  4. Ja Windows prasa paroli, izmantojiet tādu, kuru varat droši uzglabāt, vai nospiediet Enter, lai to ignorētu vienkāršai iestatīšanai.
  5. Atvērtās atslēgas parādīšana ar komandu: Get-Content $env:USERPROFILE\.ssh\id_ed25519.pub.
  6. Kopējiet tikai pilnu rindu, kas sākas ar ssh-ed25519. Nekopējiet un neaugšupielādējiet privātās atslēgas failu.
> Kā vizuāli izveidot SSH atslēgu operētājsistēmā Windows

Grafisks veids, kā Windows operētājsistēmā izveidot SSH atslēgu pāri bez komandrindas.
faq/create-ssh-key-windows-gui-lv

Izmantojiet Windows rīku un ievietojiet tikai publisko atslēgu

Jūs varat vizuāli izveidot SSH atslēgu pāri, izmantojot Windows SSH klientu, piemēram, PuTTYgen. Cli>_ ir nepieciešama tikai publiskā atslēga. Privātās atslēgas failu glabājiet savā datorā un nekādā gadījumā neaugšupielādējiet to caur tīmekļa formu.

Solījumi

  1. Instalējiet PuTTY vai atveriet PuTTYgen, ja tas jau ir instalēts.
  2. Izvēlieties EdDSA/Ed25519, ja tāds ir pieejams, pretējā gadījumā izvēlieties RSA 4096.
  3. Noklikšķiniet uz "Generate" un pārvietojiet kursoru pa tukšo laukumu, līdz atslēga tiek ģenerēta.
  4. Pievienojiet paroli, ja vēlaties papildu vietējo aizsardzību privātajai atslēgai.
  5. Saglabājiet privāto atslēgu savā datorā un glabājiet to slepeni.
  6. Nokopējiet publiskās atslēgas tekstu un ielīmējiet to SSH publiskās atslēgas laukā Cli>_.

Nedaliet konfidenciālu informāciju

Neizsūtiet .ppk failus, privātās atslēgas, paroles vai tokenus atbalsta dienestam vai veidlapām.

> Ievadiet savu domēnu

Uzziniet, kā novirzīt savu domēnu vai apakšdomēnu uz CLIopen pakalpojumu, pirms aktivizējat funkciju "Pievienojiet savu domēnu".
faq/pievieno-savu-domenu

Kas šis iestatījums dara

Izmantojot savu domēnu, pakalpojums atbild uz jūsu personīgo hostnames, piemēram, app.example.com, nevis izmantojot noklusējuma ģenerēto *.co.cliopen.cloud hostname. DNS jāvirza uz CLIopen pirms hostnama drošas lietošanas pakalpojumā.

Pirms sākat

  1. Izvēlieties precīzu hostnama nosaukumu, ko vēlaties izmantot, piemēram, app.example.com. Vienkāršākais risinājums ir izmantot apakšdomēnu.
  2. Atveriet DNS administrāciju pie sava domēna reģistrētāja vai DNS pakalpojumu sniedzēja.
  3. Dzēsiet jebkādus konfliktējošus A, AAAA, CNAME, ALIAS vai pārvirzības ierakstus ar to pašu hostnama nosaukumu.
  4. Atstājiet automātiski ģenerēto CLIopen hostnama vārdu aktīvu, līdz jūsu pielāgotais hostnama vārds ir apstiprināts un pilnībā darbojas.

Ieteicamie DNS iestatījumi apakšdomēnam

Izveidojiet DNS ierakstus precīzam hostnama vārdam, kuru ievadīsiet CLIopen. Piemēram, app.example.com DNS etiķete ir app. Norādiet to uz CLIopen ingress adresēm, ko sniedzis CLIopen atbalsta dienests vai jūsu pakalpojuma dokumentācijā. Ja jūsu pakalpojumu sniedzējs prasa ieraksta tipu, izmantojiet A ierakstu IPv4 adresēm un AAAA ierakstu IPv6 adresēm, ja tās ir pieejamas.

Piemērs:

app.example.com.  A     <CLIopen IPv4 adrese>
app.example.com.  AAAA  <CLIopen IPv6 adrese, ja tā ir pieejama>

Kad CLIopen norāda CNAME mērķi

Dažiem pakalpojumiem CLIopen var nodrošināt ģenerētu hostnama, piemēram, service.customer.co.cliopen.cloud. Ja jūsu pakalpojuma instrukcijās ir noteikts, ka jāizmanto CNAME, izveidojiet ierakstu, piemēram, app.example.com CNAME service.customer.co.cliopen.cloud. Izmantojiet CNAME tikai apakšdomēniem, nevis galvenajam/saknes domēnam, ja jūsu DNS pakalpojumu sniedzājs neatbalsta ALIAS vai ANAME flattening.

Saknes domēna izmantošana

Izmantojot tukšā domēnā, piemēram, example.com, lielākā daļa DNS pakalpojumu sniedzēju neļauj izmantot standarta CNAME ierakstu. Izmantojiet A/AAAA ierakstus, kas norāda uz CLIopen ievades adresēm, vai izmantojiet sava pakalpojumu sniedzēja ALIAS/ANAME funkciju, ja CLIopen ir piešķīris mērķa hostname.

Visas apakšzemes delegācija

Ja vēlaties, lai CLIopen pārvaldītu ierakstus apakšzonā, piemēram, apps.example.com, izveidojiet NS ierakstus šai apakšzonai, kas norāda uz CLIopen nameserveriem, kurus esat saņēmuši. Neizmainiet visas domēna nameserverus, ja nevēlaties, lai CLIopen (vai cits DNS pakalpojums) pārvaldītu visus ierakstus.

Kontroles saraksts

  1. Pagaidiet DNS propagāciju. Nelielas izmaiņas bieži kļūst redzamas dažu minūšu laikā, bet daži pakalpojumu sniedzēji to kešē ilgāk.
  2. Pārbaudiet, vai hostvārds norāda uz CLIopen mērķi, nevis uz iepriekšējo pakalpojumu sniedzēju.
  3. Ievadiet precīzo domēna nosaukumu laukā "Bring your own domain", neiekļaujot `https://` un ceļu.
  4. Pēc pakalpojuma atjaunināšanas, pārbaudiet `https://app.example.com` savā pārlūkprogrammā.
  5. Saglabājiet vecus DNS ierakstus tikai tad, ja tie nesastāda konfliktu ar jauno domēna nosaukumu.
> Kā pārskaitīt DNS zonu uz CLIopen

Delegējiet domēnu uz ns1.cliopen.com un ns2.cliopen.com, lai CLIopen varētu publicēt ierakstus visai zonai.
faq/dns-zonas-nodosana

Kas ir zonas pārsūtīšana šeit

Klienta DNS kontekstā, zonas pārsūtīšana nozīmē autoritatīvo vārdu serveru maiņu jūsu domēna reģistrātorā. Pēc delegācijas uz CLIopen, CLIopen DNS pievienotie ieraksti tiek publicēti, izmantojot mūsu autoritatīvos vārdu serverus.

Pirms mainat nameservers

  1. Kopējiet esošos DNS ierakstus, kas jums joprojām ir nepieciešami, piemēram, vietni, pastu, verifikāciju, SPF, DKIM, DMARC un pakalpojumu ierakstus.
  2. Pievienojiet zonu CLIopen DNS. Ja deleģēšana vēl nav gatava, CLIopen to saglabā, bet neaktivizē klientiem, līdz validācija ir veiksmīga.
  3. Ja iespējams, izveidojiet nepieciešamos ierakstus CLIopen DNS pirms nameserveru maiņas.
  4. Lūdzu, pievērsiet uzmanību CAA iestatījumiem, jo nepareizas vērtības var bloķēt sertifikātu izsniegšanu.

Delegējiet zonu

  1. Atveriet domēna iestatījumus pie reģistrētāja, piemēram, example.com.
  2. Atrodiet DNS serveru (Nameservers), DNS delegācijas vai autoritatīvo DNS iestatījumus.
  3. Nomainiet pašreizējos DNS serverus uz ns1.cliopen.com un ns2.cliopen.com.
  4. Saglabājiet izmaiņas un gaidiet, līdz tie tiks izplatīti reģistrā un resolveros.

Validācija

Atgriezieties CLIopen DNS un noklikšķiniet uz "Pārbaudīt delegāciju". Kad publiskie NS ieraksti rāda ns1.cliopen.com un ns2.cliopen.com, zona tiek ievietota sinhronizācijas rindā, un ieraksti kļūst aktīvi no CLIopen.

> Konta reģistrācija un pirmā pieslēgšanās

Izveido vienu darba kontu, pievieno rēķinu informāciju un nodrošini, ka komanda var piekļūt e-pastiem.
faq/account-registration-and-login

Vienots konts pasūtījumiem un pārvaldībai

Izmantojiet kontu kā ilgtermiņa platformu pasūtījumiem, rēķinu datiem, pakalpojumiem, domēniem un komunikācijai ar atbalsta komandu. Ieteicams izmantot darba e-pastu, kam komanda saglabās piekļuvi pat pēc personāla maiņām.

Pirms pirmā pasūtījuma

  1. Reģistrējieties, izmantojot savu darba e-pasta adresi.
  2. Apstipriniet e-pastu, ja tiek pieprasīts apstiprinājums.
  3. Aizpildiet rēķinu datus pirms maksas pasūtījuma noformēšanas.
  4. Kad būs pieejama divu faktoru autentifikācija, ieslēdziet to uzreiz pēc pirmās reģistrēšanās.

Piekļuve komandai

Nepasūta paroles kolēģiem caur tērzēšanu vai e-pastu. Ja kontam ir nepieciešama piekļuve vairākiem cilvēkiem, izmantojiet iekšējo paroļu pārvaldnieku vai pieprasiet ieteikto komandas procedūru; atbalsta dienestam nav nepieciešama jūsu parole vai autentifikācijas marķe.

> Mēneša aplēse, gada aplēse un faktiskais ikdienas patēriņš

Mēneša un gada cenas tiek norādītas salīdzinājumam; gadījumos, kad tiek izmantota priekšapmaksas metode, pēc apstiprināšanas ir svarīgi ņemt vērā ikdienas patēriņu.
faq/billing-periods-and-credit-burn

Salīdzinājums nav rēķinu kalendārs

Mēneša aprēķins ir aptuvena vērtība, kas attiecas uz 31 dienu periodu, savukārt gada aprēķins - uz aptuveni 372 dienām. Faktiskais kredīta patēriņš priekšapmaksas pakalpojumiem notiek atkarībā no aktīvā laika un apstiprinātās konfigurācijas.

Kas jāpārbauda, mainot cenu

  1. Salīdzini dienas patēriņu pirms un pēc izmaiņas.
  2. Ja tiek izmantots vairāk CPU, RAM vai diska, vai ja ir izvēlētas maksas opcijas, jāņem vērā, ka dienas patēriņš var būt lielāks.
  3. Izmaiņas stājas spēkā tikai pēc apstiprināšanas, maksājuma (ja nepieciešams) un ieviešanas.
  4. Grāmatvedībai saglabājiet pasūtījuma apstiprinājumu un kredītvēsturi.

Norādiet konkrētu periodu strīdu gadījumā

Atbalsta dienestam noderēs pasūtījuma numurs, pakalpojuma nosaukums un datumi, par kuriem vēlaties pārbaudīt patēriņu. Nepievienojiet bankas datus, pilnus maksājumu izrakstus vai ekrānattēlus ar nevēlamiem personiskiem datiem.

> Pasūtījuma statuss pēc maksājuma

Pēc apmaksas pasūtījums var gaidīt maksājumu sniedzēja apstiprinājumu; dublikātu veido tikai tad, ja pirmais pasūtījums ir skaidri atcelts vai tā termiņš ir beidzies.
faq/order-status-and-payment-confirmation

Gaidīšana nenozīmē kļūmi

Pēc atgriešanās no maksājumu lapas pasūtījums var vēl gaidīt apstiprinājumu no maksājumu pakalpojuma sniedzēja. Kamēr statusa ziņojums nav skaidri norādījis uz neveiksmi vai ir beidzies, jauns dublikāts pasūtījums var nevajadzīgi sarežģīt apstrādi.

Darbības pēc maksājuma

  1. Pēc maksājuma pabeigšanas atgriezieties uz Cli>_.
  2. Kontā pārbaudiet pasūtījuma statusu un iespējamo ziņu par maksājumu.
  3. Ja pasūtījums joprojām gaida apstiprinājumu, dodiet pakalpojumu sniedzējam laiku.
  4. Problēmu gadījumā sazinieties ar atbalsta dienestu un norādiet pasūtījuma numuru un maksājuma reģistrācijas numuru, ja tas ir pieejams.

Kas jāizvairās nosūtīt

Atbalsta dienestam nav nepieciešami kartes dati, konta parole vai pilns bankas apstiprinājums. Pietiek ar pasūtījuma numuru, maksājuma laiku, redzamo statusu un ekrānattēlu, kurā ir aizklāts sensitīvs saturs, ja tiek parādīta kļūda.

> Dati, kas paātrina pakalpojuma iestatīšanu

Sagatavojiet pakalpojuma nosaukumu, domēnu, uzglabāšanas apjomu, piekļuves e-pastu un publisko SSH atslēgu; slepenus datus ievadiet formās nedrīkst.
faq/service-setup-information-needed

Precīzi dati ietaupa laiku

Izmantojiet pasūtījuma veidlapas, lai ievadītu publiskus vai nekonfidenciālus datus: pakalpojuma nosaukumu, domēnu, DNS plānu, uzglabāšanas apjomu, CPU, RAM, administratora e-pastu vai publisko SSH atslēgu. Paroleles, privātās atslēgas un tokenus ievadiet citur.

Sagatavojieties pirms pasūtījuma veikšanas

  1. Izvēlies komandai saprotamu pakalpojuma nosaukumu.
  2. Nolēmiet, vai izmantosiet savu domēnu vai pagaidu sistēmas hostname.
  3. Sagatavojiet publisko SSH atslēgu, ja pakalpojums to pieprasa.
  4. Pārbaudiet uzglabāšanas vietu un resursus, kas nepieciešami jūsu lietotnei.

Neatsediet sensitīvu informāciju

Ja neesat pārliecināti, vai dati ir konfidenciāli, pirms nosūtīšanas jautājiet.

> CPU, RAM, diska vai atmiņas izmaiņa pēc pasūtījuma

Mainiet esošos pakalpojumu resursus tikai caur tā detaļām, nevis veidot jaunu pasūtījumu; resursu maiņa ietekmē cenu, dienas patēriņu un var prasīt restartu.
faq/change-service-resources-after-order

Mainiet jau esošu pakalpojumu, nevis izveidojiet jaunu

Ja pakalpojums jau ir aktivizēts, resursu maiņu veiciet tā detaļu sadaļā. Jauns pasūtījums radīs jaunu pakalpojumu, nevis modificēs esošo, un pēc apstiprināšanas var mainīt cenu, dienas kredīta patēriņu un darbības uzvedību.

Pirms apstiprināšanas

  1. Skatiet pašreizējo CPU, RAM, diska lietojumu, dublējumu un Offsite Archive saglabāšanas periodu.
  2. Pārbaudiet jauno dienas cenu un tās ietekmi uz kredītu.
  3. Izlasiet brīdinājumus par restartēšanu, apkopi vai darbības pārtraukumiem.
  4. Pirms jebkuras potenciāli riskantas izmaiņas, eksportējiet svarīgus datus.

Ja izmaiņas nenotiek kā paredzēts

Sūtiet pakalpojuma nosaukumu, izmaiņu laiku, redzamo statusu un kļūdas ziņojumu. Nesūtiet privātās atslēgas, paroles vai tokenus; diagnostikai pietiek ar publisko kontekstu un aizklātu ekrānuzņēmumu.

> Pakalpojuma atcelšana un datu dzēšanas termiņš

Aktivizētais pakalpojums vispirms tiek apturēts, tiek parādīts konfigurējams redzams datu dzēšanas termiņš, un pēc tam var notikt datu pilnīga izdzēšana.
faq/cancel-service-and-data-retention

Atcelšana nenozīmē nekavējošu visu datu dzēšanu

Kad pakalpojums ir aktivizēts, tas vispirms tiek apturēts un parādās konfigurējams redzams dzēšanas termiņš, līdz kuram vēl var atjaunot vai eksportēt datus. Neapmaksāti pasūtījumi, kas vēl nav aktivizēti un kuriem nav saistītu datu, var tikt deaktivizēti citādi, savukārt pilnīga dzēšana notiek tikai pēc noteikta perioda beigām.

Pirms dzēšanas pārbaudiet

  1. Izveidojiet savu datu eksportu, kas nepieciešams ilgtermiņa glabāšanai.
  2. Lūdzu, izlasiet apturētā pakalpojuma plānotās dzēšanas datumu un laiku.
  3. Atcerieties, ka dublējumu saglabāšana un Offsite Archive ir atšķirami no pakalpojuma dzīves cikla dzēšanas.
  4. Ja neesat pārliecināti, sazinieties ar atbalsta dienestu pirms dzēšanas termiņa beigām.

Dati var nevis tikt atjaunoti pēc termiņa beigām

Pēc redzamā termiņa beigām nedrīkst uzskatīt, ka dati ir pieejami. Jautājumu gadījumos norādiet pasūtījuma numuru un pakalpojuma nosaukumu, nevis datubāzu eksportus vai slepenas autentifikācijas datus.

> Dubulējumi un atjaunošanas pieprasījumi

Dubulējumi ir paredzēti operatīvai atjaunošanai, nevis eksportu aizstāšanai; atjaunošana var pārrakstīt jaunākus datus.
faq/backups-and-restore-requests

Dublējums nav arhīvs vai eksports

Datu dublējumu glabāšanas laiks ir atkarīgs no atlasītā produkta un opcijām. Dublējums palīdz atjaunot darbību pēc kļūdas, taču tas neaizstāj datu eksportēšanu, audita arhīvu vai Offsite Archive. Atjaunošana var pārrakstīt jaunākas izmaiņas.

Kā sagatavot atjaunošanas pieprasījumu

  1. Norādiet pakalpojuma nosaukumu un pasūtījuma numuru.
  2. Aprakstiet aptuveno laiku, uz kuru vēlaties atgriezties.
  3. Norādiet, vai jāatjauno viss pakalpojums vai tikai konkrēta daļa, ja tas ir iespējams.
  4. Pievienojiet redzamu kļūdu vai kontekstu, neiekļaujot paroles, tokenus un privātās atslēgas.

Pirms atjaunošanas aprēķiniet ietekmi

Ja pakalpojums šajā laikā ir saņēmis jaunus datus, atjaunošana var aizstāt tos ar vecāku stāvokli. Pirms apstiprināt atjaunošanu, informējiet komandu un eksportējiet datus, kurus nevēlaties zaudēt.

> Kas ir Offsite Archive?

Offsite Archive glabā attālinātās arhīva kopijas, kas atrodas citā datu centrā un ir atdalītas no īstermiņa darba dublējumiem un pakalpojuma dzīves cikla. Tas nav aktīvas lietojumprogrammas uzglabāšana.
faq/offsite-archive-purpose

Arhīva kopija ārpus vietējās infrastruktūras

Offsite Archive ir paredzēts attālām arhīva kopijām un datu ilgtermiņa glabāšanai. Tas nav lietojumprogrammu diska, vietējā eksporta aizstājnieks vai tas pats, kas īsi operatīvie dublējumi.

Kad to ieslēgt?

  1. Izmantojiet to datiem, kurus vēlaties saglabāt arī ārpus pakalpojuma ikdienas darbības.
  2. Izvēlieties retences dienas, kas atbilst jūsu atbilstības vai atjaunošanas mērķim.
  3. Ņemiet vērā, ka cena pieaug atkarībā no glabātā apjoma un glabāšanas ilguma.
  4. Lielu datu apjomu gadījumos plānojiet arhīvu kopā ar savu eksportēšanas procesu.

Kā aprēķināt cenu

Pamats ir MB-dienas: cik daudz datu tiek glabāti un cik ilgi tie tiek saglabāti. Klientam tarifs tiek parādīts kā EUR/GB/mēnesis, un rezultāts tiek noapaļots līdz veseliem centiem.

> CPU, RAM un diska izvēle VPS

Izvēlieties VPS izmēru atbilstoši lietojumprogrammai, datubāzei, kešatmiņai, žurnāliem un paredzamajai izaugsmei. OOM vai swap norāda uz nepieciešamību palielināt RAM.
faq/vps-cpu-ram-and-disk-sizing

Sāciet, pamatojoties uz faktisko slodzi, nevis intuīciju

Mazai statiskajai vietnei ir citas prasības nekā datubāzei, Java lietojumprogrammai, meklēšanai vai konteineru izveidei. Plānojot, ņemiet vērā lietojumprogrammas atmiņu, kešatmiņu, datubāzi, žurnālus, augšupielādējumus un rezerves vietu turpmākajai izaugsmei.

Zīmes, kas liecina par ierobežotiem resursiem

  1. Palieliniet RAM, ja rodas OOM (out of memory) kļūdas, tiek noslēgti procesi vai notiek pastāvīga apmainīšana ar disku.
  2. Palieliniet CPU, ja ir ilgstoša augsta aprēķinu slodze, kompresija, build process vai aizņemti apstrādes procesi.
  3. Papildiniet diska vietu pirms failu sistēma, žurnāli vai datubāze tiek pilnībā aizpildīta.
  4. Pēc katras izmaiņas pārbaudiet, vai lietojumprogramma patiešām vairs nesastopas ar sākotnējo limitu.

Kas jāsūtī, ja ir jautājumi par resursu piešķiršanu

Norādiet pakalpojuma nosaukumu, lietotnes tipu, redzamu kļūdu, aptuveno problēmas laiku un pašreizējās CPU, RAM un diska vērtības. Neiesūtiet paroles, privātās atslēgas vai iekšējus konfigurācijas failus.

> Kad ir lietderīgi izmantot publisko IP adresi VPS serverim?

Veltīta publiskā IP adrese var būt noderīga, ja nepieciešams nodrošināt piekļuvi, stabilu izejošu avotu vai pakalpojumus, kas saistīti ar konkrētu adresi.
faq/vps-public-ip-options

Vispirms noskaidrojiet komunikācijas virzienu

Publiskā IP adrese nav automātiski nepieciešama katram pakalpojumam. Tā bieži vien nodrošina prasības, ko izvirza ārēji partneri, pakalpojumu sniedzēji vai ugunsmūri, lai izveidotu allowlist, stabilu izejošu avotu vai ienākošu piekļuvi konkrētam portam.

IP adrešu pasūtīšanas jautājumi

  1. Jautājiet partnerim, vai allowlist attiecas uz ienākošo (inbound), iznākošo (outbound) vai abiem virzieniem.
  2. Izmantojiet DNS nosaukumus, nevis IP adreses, kur tas ir iespējams.
  3. Atveriet tikai tādus portus, kas patiešām ir nepieciešami lietotnei.
  4. Sūtiet allowlist prasību atbalsta dienestam, pirms maināt produkcijas piekļuvi.

Kas jātur slēgts

Publiskā IP adrese nenozīmē visu portu atvēršanu. Plānojiet piekļuvi tikai nepieciešamiem pakalpojumiem un nesūtiet paroles, privātās atslēgas vai iekšējās ugunsmuura noteikumus kā attēlus ar slepenām vērtībām.

> Kopīgais SSH piekļuves veids VPS

Bez nopirktas publiskās IP adreses, VPS pievienojas, izmantojot kopīgu SSH savienojumu ar augstu portu; ja ir iegādāta publiskā IP adrese, būs pieejams arī tiešais SSH piekļuves veids uz šo adresi.
faq/shared-ssh-access-for-vps

Kāpēc kopīgai SSH piekļuvei tiek izmantots augsts ports

Vairāki VPS var koplietot vienu publisko SSH savienojuma punktu, tāpēc katram pakalpojumam tiek piešķirts savs augsts ports. Ports ir maršrutēšanas daļa uz jūsu VPS; bez tā savienojumu nevarētu nepārprotami nogādāt pareizajam pakalpojumam.

Pieslēgšanās atkarībā no piekļuves veida

  1. Koplietotam SSH nokopējiet lietotājvārdu, servera adresi un portu no SSH pakalpojuma.
  2. Izmantojiet formātu `ssh -p <port> <lietotājvārds>@<servera_adrese>`.
  3. Ja pakalpojumam ir iegādāta publiskā IP adrese, var būt arī otrais SSH savienojuma punkts tieši uz šo IP adresi vai tās DNS nosaukumu, atkarībā no pakalpojuma iestatījumiem.
  4. Privāto atslēgu izmantojiet tikai lokāli savā SSH klientā vai agentā; atbalsta komandai nosūtiet tikai publisko hostu, portu, lietotājvārdu un redzamo kļūdu.

Kad ir iegādāta papildu publiskā IP adrese

Publiskā IP adrese nenomaina koplietoto SSH pieslēgšanās punktu; tā pievieno atsevišķu tiešas piekļuves veidu, kas piemērots sarakstiem, monitoringu vai tiešu integrāciju. Praksē jūs varat redzēt gan koplietotu hostu ar augstu portu, gan tiešu hostu vai IP adresi pakalpojumam ar publisko IP.

> Pārbaude pirms sava domēna pievienošanas

Pirms domēna maiņas, lūdzu, pārbaudiet autoritatīvo DNS serveri, precīzo hostname, ieraksta tipu, vai tā ir galvenā domēnname vai apakšdomēnname, un pārbaudiet, vai nav konflikta ar vecajiem ierakstiem.
faq/custom-domain-readiness-checklist

Svarīgi ir precīzs hostvārds

Vispirms noskaidrojiet, vai jūs pieslēdzat galveno domēnu, piemēram, example.com, vai apakšdomēnu, piemēram, app.example.com. Katram variantam var būt nepieciešams atšķirīgs DNS ieraksta tips, citi DNS pakalpojumu sniedzēja ierobežojumi un pārbaude pie reģistrētāja.

Pirms DNS izmaiņām

  1. Pārbaudiet, kur tiek rediģēti autoritatīvie DNS ieraksti domēnā.
  2. Noņemiet vai pielāgojiet konfliktējošus A/AAAA, CNAME, ALIAS, ANAME vai novirzīšanas ierakstus.
  3. Izmantojiet pakalpojumam un hostname ieteikto ieraksta tipu.
  4. Pēc izmaiņām, lūdzu, gaidiet DNS propagācijas procesu un tikai pēc tam pārbaudiet HTTPS savienojumu.

Droša atgriešana

Neizslēdziet vecā servera darbību, līdz jaunais hostings darbojas pareizi. Ja rodas problēmas, norādiet domēnu, paredzamo mērķi un redzamos DNS rezultātus, nevis piekļuves datus reģistratoram.

> DNS ierakstu tipi pakalpojumiem

A/AAAA ieraksti norāda uz adresēm, CNAME ieraksti norāda uz alias, MX ieraksti norāda uz pasta serveriem, un TXT ieraksti tiek izmantoti verifikācijai, piemēram, SPF, DKIM vai DMARC.
faq/dns-record-types-for-services

Nekombinējiet ierakstus nejauši

Katrs DNS tipa ieraksts veic citu funkciju. A un AAAA norāda uz IP adresēm, CNAME izveido saiti (alias) apakšdomēnam, MX novirza e-pastu, TXT satur verifikācijas datus un pasta politikas, CAA ierobežo sertifikātu iestādes.

Kopējot ierakstus

  1. Precīzi kopējiet nosaukumu, tipu un vērtību saskaņā ar pakalpojuma instrukcijām.
  2. Neizveidojiet CNAME ierakstu hostname, kuram jau ir citi ieraksti, ja DNS noteikumi to aizlieg.
  3. Ievietojiet DKIM zem pakalpojuma sniedzēja selectora un DMARC parasti zem _dmarc.
  4. CAA iestatiet uzmanīgi, jo nepareiza vērtība var bloķēt sertifikāta izsniegšanu.

Kad DNS neizdodas

Atbalsta dienestam nosūtiet hostname, ieraksta tipu, paredzēto vērtību un publiski redzamo rezultātu. Nosūtīt DNS administrācijas login datus vai ekrānattēlus ar API atslēgām nav pieļaujams.

> DNS izplatīšana un TTL bez solījumiem par precīzu laiku

TTL nosaka, cik ilgi resolveri var saglabāt iepriekšējo atbildi; pārejas periodā vecās un jaunās atbildes var eksistēt vienlaikus.
faq/dns-propagation-and-ttl

Propagācija ir kešatmiņa, nevis maģiska gaidīšana

DNS sistēmā nav fiksētā laika apņemšanās par propagācijas ātrumu. Pēc autoritatīvā DNS servera izmaiņām dažādi resolveri var vēl turpināt atgriezt vecas vai jaunas atbildes, līdz kešatmiņa tiek atsvaidzināta saskaņā ar TTL (Time To Live) iestatījumiem. Tādēļ rezultāti var atšķirties starp tīkliem un valstīm.

Plānotajām izmaiņām

  1. Ja pakalpojumu sniedzējs to ļauj, samaziniet TTL pirms plānotās izmaiņas.
  2. Pēc DNS iestatījumu maiņas neveiciet atkārtotas nejaušas izmaiņas, līdz kešatmiņa tiek dzēsta.
  3. Testējiet no vairākiem serveriem, ja rezultāti atšķiras.
  4. Atzīmējiet izmaiņu laiku, esošo vērtību, jauno vērtību un TTL.

Kas jānosūta diagnostikai

Norādiet hostname, gaidīto mērķi, redzamo veco atbildi, redzamo jauno atbildi, TTL un izmaiņas laiku. Neatstājiet DNS konta piekļuves datus vai iekšējus piegādātāja komentārus.

> Workspace Suite uzglabāšanas plānošana

Aprēķinot nepieciešamo uzglabāšanas vietu, ņemiet vērā lietotāju failus, koplietotas mapes, versijas, papildu datu apjomu (piemēram, miskastē), priekšskatījumus, sinhronizācijas overhead un komandas izaugsmi.
faq/nextcloud-storage-planning

Workspace Suite palielinās arī ārpus redzamajiem failiem

Kapacitāti patērē lietotāju faili, koplietotas mapes, dzēstie faili, versiju vēsture, priekšskatījumi, sīktēli, sinhronizācijas klienti un importi. Ja uzglabāšanas vieta ir tuvu maksimālajai ietilpībai, augšupielādes vai sinhronizācija varētu neizdoties.

Pirms pasūtījuma veikšanas

  1. Saskaitiet esošos lietotāju datus un koplietotas mapes.
  2. Pievienojiet rezervi versijām, miskastiem, priekšskatījumiem un sinhronizācijas darbībām.
  3. Ņemiet vērā lielus datu importus, jaunas komandas un paredzamo izaugsmi.
  4. Palieliniet kapacitāti pirms lietotāji sasniedz limitu.

Sinhronizācijas problēmu gadījumā

Nosūtiet pakalpojuma izmēru, aptuveno izmantošanu, problēmas laiku un klienta redzamo kļūdu. Nosūtiet tikai klientam redzamus nosaukumus, pasūtījumu numurus, domēnus, ekrānattēlus, kur slepeni dati ir paslēpti, un redzamu kļūdas tekstu. Nesūtiet paroles, privātās atslēgas, tokenus, ģenerētus konfigurācijas failus vai iekšējās infrastruktūras detaļas.

> Repozitoriju migrācija uz Gitea

Git repozitoriju migrēšana: Plānojiet Gitea migrāciju, ņemot vērā Git LFS, submoduļus, aizsargātās filiāles un tagus, deploy atslēgas, tokenus, webhookus, CI/CD un verifikācijas klonēšanas/pārsūtīšanas testus.
faq/gitea-repository-migration

Migrācija ir vairāk nekā tikai `git clone`

Papildus repozitorija vēsturei jāpārnes vai jāiestata īpašnieki, komandas, aizsargātās filiāles, aizsargātās atzīmes, Git LFS, apakšmoduļi, izvietošanas atslēgas, webhooki un CI/CD savienojumi.

Pārbaude pirms pārejas

  1. Uzskaiti repozitorijus, īpašniekus, piekļuves grupas un automatizācijas kontus.
  2. Pārbaudi Git LFS objektus, submoduļus, aizsargātās filiāles un tagus.
  3. Pēc migrēšanas pārbaudi klonēšanu, push operācijas, Git LFS, submoduļus un CI darbību.
  4. Atceliet vai nomainiet vecus piekļuves kodus pēc migrācijas pabeigšanas, nenododot to vērtības.

Jutīgi dati migrācijas laikā

Neiesniedziet atbalsta dienestam atslēgas kodus, privātās atslēgas, deploy key privāto daļu vai CI noslēpumus. Pietiek ar repozitoriju nosaukumiem, integrācijas tipu, redzamo kļūdu un informāciju par to, kas darbojās pirms migrācijas.

> Sūtītāja domēns pakalpojumam Listmonk

Kampaņu sagatavošanai konfigurējiet sūtītāja domēnu vai apakšdomēnu, From identitāti, SPF, DKIM, DMARC, atsakumu apstrādi un iespēju atteikties no abonementa.
faq/listmonk-sender-domain-basics

Piegādājamība sākas ar domēnu

Listmonk ir visefektīvāk izmantojams, ja nosūtītāja domēnā ir pareizi iestatīti DNS ieraksti, From identitāte, SPF, DKIM, DMARC atbilstība, kā arī iespējas apstrādāt atteikumus un atgriešanas ceļus, kā arī informāciju par atcirtēšanos. Publicējiet SPF pie pasta pakalpojumu sniedzēja, DKIM ar pakalpojumu sniedzēja selektoru un DMARC uz _dmarc. Pirms reālas kampaņas nosūtiet testa ziņojumus un neizpaužiet e-pasta paroles.

Pirms pirmās kampaņas

  1. Izvēlieties sūtītāja domēnu vai apakšdomēnu un norādiet "No" adresi.
  2. Pievienojiet verifikācijas DNS ierakstus, SPF, DKIM selektoru un DMARC.
  3. Testējiet piegādi, atbildes ziņojumus (bounce) vai "Atpakaļceļu" (Return-Path) un saites e-pastā.
  4. Pārbaudiet atvienošanos un List-Unsubscribe pirms reālas sūtīšanas.

Pasta noslēpumi neder biļetēs

Diagnostikai nosūtiet domēnu, ieraksta tipu, publiski redzamo DNS vērtību un kļūdas ziņojumu. Nesūtiet SMTP paroles, API atslēgas, privātās DKIM atslēgas vai adresātu eksportus ar personiskiem datiem.

> Classic Hosting darbības režīma iestatījumi

Classic Hosting var darboties automātiskajā vai manuālajā režīmā; CPU, RAM, atmiņa, uzglabāšana, dublējumu saglabāšanas laiks, Offsite Archive saglabāšanas laiks, augšupielādējumi, kešatmiņa un žurnāli ietekmē cenu un stabilitāti.
faq/classic-hosting-runtime-settings

Automātiskais režīms nav vienīgā pareizā izvēle

Auto Runtime palīdz ar atpazītiem projektiem, bet manuālā režīma izmantošana ir piemērota, ja vēlaties precīzi izvēlēties Nginx, Apache, FrankenPHP vai konkrētu valodu vidžu. PHP selectoru izmantojiet tikai tad, kad to atbalsta izvēlētā valodu vidže.

Iestatījumi pirms ieviešanas

  1. Izvēlieties automātisko vai manuālo režīmu, atkarībā no izmantotās platformas un build veida.
  2. Izvēlieties PHP 8.2, 8.3 vai 8.4 tikai tad, ja izvēlētā sistēma to atbalsta.
  3. Iestatiet CPU, RAM, diska apjomu, datu dublējumu un Offsite Archive saglabošanas periodu, ņemot vērā datu apjomu un trafiku.
  4. Pēc ieviešanas pārbaudiet failu augšupielādi, kešatmiņu, žurnālus un redzamas lietotnes kļūdas.

Kad lietotne neuzsākas

Sūtiet informāciju par darbības režīmu, valodu vai PHP versiju, redzamo kļūdu, kas ir mainīts un aptuveno ieviešanas laiku. Nesūtiet .env failus, paroles, tokenus vai pilnus žurnālus ar sensitīvām vērtībām.

> Kādu informāciju droši var nosūtīt atbalsta dienestam?

Visnoderīgāk ir norādīt pasūtījumu numurus, pakalpojumu nosaukumus, domēnus, laikus, publiskos serverus un portus, datu saglabāšanas periodus, failu augšupielādi, kešatmiņu, žurnālus un redzamas kļūdas, neizpaužot sensitīvu informāciju.
faq/support-safe-information-to-share

Labam atbalsta pieprasījumam ir konteksts, nevis noslēpumi

Atbalsta komanda var ātrāk sniegt palīdzību, ja saņem pasūtījuma numuru, pakalpojuma nosaukumu, domēnu, publisko serveri vai portu, problēmas laiku, veikto izmaiņu aprakstu un precīzu redzamo kļūdas ziņojumu.

Droša ziņojuma satura nodrošināšana

  1. Norādiet pasūtījuma numuru, redzamo pakalpojumu nosaukumu, domēnu, aptuveno laiku un serveri vai portu, ja tas ir attiecīgs.
  2. Hostinga problēmām norādiet izpildes režīmu, valodu vai PHP versiju, CPU, RAM, diska vietņu daudzumu, datu dublējumus, Offsite Archive saglabāšanas laiku, failu augšupielādi, kešatmiņu un žurnālus, kā arī informēšanu par nesen veiktiem mainīgumiem.
  3. Pievienojiet ekrānattēpus tikai pēc tam, kad esat paslēpuši paroles, tokenus, privātās atslēgas, sesijas un personīgos datus.
  4. Ja neesat pārliecināts, vai dati ir piemēroti biļetei, vispirms jautājiet, pirms nosūtāt datus.

Informācija, kuru nevajadzētu nosūtīt

Neizmantojiet paroles, privātās atslēgas, atgūšanas kodus, API tokenus, sesijas sīkfailus, datubāzu eksportus, pilnus .env failus, pilnus žurnālus ar sensitīvām vērtībām vai iekšējās infrastruktūras detaļas.