Întrebări frecvente

Întrebări frecvente

Ghiduri scurte și practice pentru configurarea serviciilor, accesare și efectuarea de acțiuni comune ale clienților.

> Cum funcționează sistemul de credit Cli>_?

Un singur sold preplătit comun finanțează toate serviciile eligibile și se consumă doar cât timp acestea sunt active.
faq/prepaid-credit-how-it-works

Contul tău Cli>_ are un singur sold comun de credit preplătit. Clienții noi eligibili pot solicita Starter Credit numai după finalizarea verificării obligatorii a contului și împotriva abuzurilor. Serviciile eligibile active consumă soldul în timp. Estimarea lunară folosește 31 de zile, iar un serviciu nou poate porni doar dacă soldul acoperă cel puțin 7 zile. Avertizarea roșie apare când durata estimată scade sub 7 zile; în caz contrar, avertizarea portocalie apare când scade sub 14 zile.

După epuizarea soldului, serviciul este suspendat după 7 zile, nu mai consumă credit și începe termenul de păstrare și ștergere de 7 zile. Înainte de termenul afișat, acesta poate fi repornit cu suficient credit. Anularea unui serviciu provisionat îl suspendă de asemenea și pornește același termen. Un serviciu în așteptare și neprovisionat poate fi dezactivat imediat. După termen încep dezactivarea și eliminarea serviciului provisionat. Force delete dezactivează imediat serviciul, sare peste păstrare și pornește eliminarea din runtime-ul activ; finalizarea urmează procesării deploymentului și GitOps. Backupurile și Offsite Archive au politici de păstrare separate.

Exemplu OpenCode la 9,90 EUR: 9,90 / 31 ≈ 0,319 EUR pe zi. După 10 zile complete se consumă aproximativ 3,19 EUR. Dacă soldul inițial a fost exact 9,90 EUR și nu au existat alte servicii, rămân aproximativ 6,71 EUR. Consumul se oprește după dezactivare.

Exemplul este orientativ. Se aplică întotdeauna prețurile curente afișate în Cli>_.

> Cum să generezi o cheie SSH publică prin linia de comandă

Creați o cheie SSH publică pentru acces securizat la VPS. Distribuiți doar cheia publică către Cli>_; păstrați cheia privată pe dispozitivul dumneavoastră.
faq/generate-public-ssh-key-ro

Cheia publică este partajată, cheia privată rămâne la tine

Introduceți doar cheia SSH publică în formularul de comandă sau în setările serviciului. Cheia privată rămâne pe computerul dumneavoastră și nu este trimisă către departamentul de asistență sau introdusă într-un formular web.

Pași

  1. Deschideți terminalul pe computerul dumneavoastră.
  2. Executați comanda: ssh-keygen -t ed25519 -C "adresa_ta_de_email@example.com".
  3. Confirmați locația fișierului sau alegeți o cale personalizată. Nu trimiteți niciodată cheia privată nimănui.
  4. Afișați cheia publică folosind comanda: cat ~/.ssh/id_ed25519.pub.
  5. Copiați întreaga linie care începe cu ssh-ed25519 și lipiți-o în câmpul "Cheie publică SSH" la finalizarea comenzii sau la configurarea serviciului.
  6. Copiază întreaga linie ssh-ed25519 în câmpul Cheie publică SSH.

PowerShell pentru Windows 10/11

  1. Deschideți PowerShell sau Windows Terminal.
  2. Executați comanda: ssh-keygen -t ed25519 -C "adresa_ta_de_email@example.com".
  3. Apăsați Enter pentru a salva cheia în C:\Users\numele_utilizatorului\.ssh\id_ed25519 sau introduceți calea dorită.
  4. Dacă Windows solicită o parolă, utilizați una pe care o puteți stoca în siguranță sau apăsați Enter pentru a o omite la configurarea simplă.
  5. Afișați cheia publică cu comanda: Get-Content $env:USERPROFILE\.ssh\id_ed25519.pub.
  6. Copiați doar linia completă care începe cu ssh-ed25519. Nu copiați și nu încărcați fișierul cu cheia privată.
> Cum să creați o cheie SSH grafic în Windows

Un ghid pas cu pas în Windows pentru crearea unei perechi de chei SSH folosind o interfață grafică, fără a utiliza linia de comandă.
faq/create-ssh-key-windows-gui-ro

Utilizați un instrument Windows și introduceți doar cheia publică

Puteți crea o pereche de chei SSH folosind un client SSH pentru Windows, cum ar fi PuTTYgen. Cli>_ are nevoie doar de cheia publică. Păstrați fișierul cu cheia privată pe computerul dumneavoastră și nu îl încărcați într-un formular web.

Pași

  1. Instalează PuTTY sau deschide PuTTYgen, dacă este deja instalat.
  2. Alege EdDSA/Ed25519, dacă este disponibil, altfel alege RSA 4096.
  3. Dă clic pe Generate și mișcă mouse-ul în spațiul gol până când cheia este generată.
  4. Adaugă o parolă dacă dorești o protecție locală suplimentară pentru cheia privată.
  5. Salvează cheia privată pe dispozitivul tău și păstreaz-o confidențială.
  6. Copiază textul cheii publice și inserează-l în câmpul "SSH public key" din Cli>_.

Nu transmiteți informații confidențiale

Nu trimiteți fișiere .ppk, chei private, parole sau token-uri către departamentul de asistență sau în formulare.

> Adu-ți propriul domeniu

Află cum să direcționezi un domeniu sau subdomeniu către serviciul CLIopen înainte de a activa opțiunea "Bring your own domain".
faq/conecteaza-domeniul-tau

Ce face această setare

Utilizarea propriului domeniu permite ca serviciul să răspundă pe hostname-ul dumneavoastră, de exemplu app.example.com, în loc să utilizeze doar un nume de domeniu generat, cum ar fi *.co.cliopen.cloud. DNS-ul trebuie să indice către CLIopen înainte ca numele de domeniu să poată fi utilizat în siguranță de serviciu.

Înainte de a începe

  1. Selectați numele exact al domeniului pe care doriți să îl utilizați, de exemplu, app.example.com. Cea mai simplă opțiune este utilizarea unui subdomeniu.
  2. Accesați panoul de administrare DNS al registrarului dumneavoastră de domenii sau al furnizorului de servicii DNS.
  3. Ștergeți orice înregistrări A, AAAA, CNAME, ALIAS sau redirecționări conflictuale pentru același nume de domeniu.
  4. Păstrați numele de gazdă CLIopen generat automat activ până când numele de gazdă personalizat este verificat și funcțional.

Configurarea recomandată a DNS pentru un subdomeniu

Creați înregistrări DNS pentru numele de gazdă exact pe care îl introduceți în CLIopen. Pentru app.example.com, eticheta DNS este app. Direcționați-o către adresele de intrare CLIopen furnizate de suportul CLIopen sau în documentația serviciului dumneavoastră. Dacă furnizorul dumneavoastră solicită un tip de înregistrare, utilizați o înregistrare A pentru IPv4 și o înregistrare AAAA pentru IPv6 atunci când aceste adrese sunt furnizate.

Exemplu:

app.example.com.  A     <Adresă IPv4 CLIopen>
app.example.com.  AAAA  <Adresă IPv6 CLIopen, dacă este disponibilă>

Când CLIopen oferă o țintă CNAME

Unele servicii vă pot oferi un nume de gazdă generat, cum ar fi service.customer.co.cliopen.cloud. Dacă instrucțiunile serviciului dvs. specifică în mod explicit utilizarea unui CNAME, creați o înregistrare precum app.example.com CNAME service.customer.co.cliopen.cloud. Utilizați CNAME doar pentru subdomenii, nu pentru domeniul principal (apex/root), cu excepția cazului în care furnizorul dvs. de DNS acceptă funcționalitatea ALIAS sau ANAME flattening.

Utilizarea domeniului principal

Pentru un domeniu fără subdomeniu, cum ar fi example.com, majoritatea furnizorilor DNS nu permit utilizarea unui CNAME standard. Utilizați înregistrări A/AAAA care indică către adresele de intrare CLIopen sau utilizați funcția ALIAS/ANAME specifică a furnizorului dumneavoastră, dacă CLIopen v-a furnizat un nume de gazdă țintă.

Delegarea unei subzone întregi

Dacă doriți ca CLIopen să gestioneze înregistrările într-o subzonă, cum ar fi apps.example.com, creați înregistrări NS pentru această subzonă care indică către serverele DNS CLIopen pe care le-ați primit. Nu modificați serverele de nume ale întregului domeniu decât dacă doriți intenționat ca CLIopen (sau un alt serviciu DNS) să gestioneze toate înregistrările.

Lista de verificare

  1. Așteptați propagarea DNS. Modificările minore sunt adesea vizibile în câteva minute, dar unii furnizori au o durată mai mare de stocare în cache.
  2. Verificați dacă numele de gazdă indică către destinația CLIopen și nu către un furnizor anterior.
  3. Introduceți numele de gazdă exact în câmpul "Bring your own domain", fără `https://` și fără calea specifică.
  4. După actualizare, testați `https://app.example.com` în browser.
  5. Păstrați vechile înregistrări DNS numai dacă acestea nu intră în conflict cu noul nume de gazdă.
> Cum să transferați o zonă DNS către CLIopen

Delegați domeniul către ns1.cliopen.com și ns2.cliopen.com, astfel încât CLIopen să poată publica înregistrări pentru întreaga zonă.
faq/delegarea-unei-zone-dns

Ce înseamnă transferul de zonă aici

În contextul DNS pentru clienți, transferul reprezintă modificarea serverelor de nume autoritative la registratorul domeniului dumneavoastră. După delegare către CLIopen, înregistrările adăugate în DNS CLIopen sunt publicate prin intermediul serverelor noastre de nume autoritative.

Înainte de a modifica serverele de nume

  1. Copiază înregistrările DNS existente pe care le mai ai nevoie, cum ar fi cele pentru site-ul web, e-mail, verificări, SPF, DKIM, DMARC și înregistrările de servicii.
  2. Adaugă zona în CLIopen DNS. Dacă delegarea nu este încă pregătită, CLIopen o salvează, dar nu o activează pentru clienți până când validarea nu este finalizată.
  3. Creează înregistrările necesare în CLIopen DNS înainte de a schimba serverele de nume, dacă este posibil.
  4. Asigurați-vă că setați corect CAA, deoarece valorile incorecte pot bloca emiterea certificatelor.

Delegați zona

  1. Deschideți setările domeniului la registrator, de exemplu example.com.
  2. Găsiți secțiunea Nameservers, delegare DNS sau setări DNS autoritative.
  3. Înlocuiți nameserver-ele existente cu ns1.cliopen.com și ns2.cliopen.com.
  4. Salvați modificarea și așteptați propagarea în registrul și rezolvarea DNS.

Validare

Reveniți la CLIopen DNS și faceți clic pe "Verificați din nou delegarea". Când înregistrările NS publice afișează ns1.cliopen.com și ns2.cliopen.com, zona este adăugată la sincronizare, iar înregistrările vor deveni active de la CLIopen.

> Înregistrare cont și prima conectare

Creați un singur cont pentru comenzi, detalii de facturare și gestionarea serviciilor. Utilizați o adresă de e-mail la care echipa dumneavoastră poate accesa.
faq/account-registration-and-login

Un singur cont pentru comenzi și administrare

Utilizați contul ca un spațiu permanent pentru comenzile, detaliile de facturare, serviciile, domeniile și comunicarea cu echipa de suport. Cea mai potrivită este o adresă de e-mail profesională, la care echipa va avea acces chiar și după schimbări de personal.

Înainte de prima comandă

  1. Înregistrează-te folosind adresa ta de e-mail profesională.
  2. Finalizează confirmarea e-mailului, dacă este solicitată de site.
  3. Completează informațiile de facturare înainte de a plasa o comandă contra cost.
  4. Dacă este disponibilă autentificarea cu doi factori, activați-o imediat după prima conectare.

Acces pentru echipă

Nu trimiteți parola colegilor prin chat sau e-mail. Dacă mai multe persoane au nevoie de acces, utilizați un manager de parole intern sau solicitați procedura recomandată pentru echipă; echipa de suport nu are nevoie de parola dumneavoastră sau de tokenul de autentificare.

> Estimare lunară, estimare anuală și consum zilnic real

Prețurile lunare și anuale sunt oferite pentru comparație; în cazul serviciilor cu plată anticipată, consumul zilnic este cel care contează după confirmarea modificării.
faq/billing-periods-and-credit-burn

Comparația nu este un calendar de facturare

Utilizați estimările lunare ca o comparație pentru 31 de zile, iar cele anuale ca o comparație pentru 372 de zile. Consumul real al creditului pentru serviciile preplătite se face în funcție de timpul efectiv de utilizare a serviciului și de configurația confirmată.

Ce trebuie verificat când se schimbă prețul

  1. Comparați consumul zilnic înainte și după modificare.
  2. Dacă alegeți un CPU, RAM sau disc mai mare, sau opțiuni contra cost, anticipați un consum zilnic mai ridicat.
  3. Modificarea devine valabilă numai după confirmare, plata (dacă este necesară) și aplicare.
  4. Pentru departamentul financiar, salvați confirmarea comenzii și istoricul creditului.

În cazul unei dispute, analizați perioada specifică.

Pentru a oferi suportul informațiile necesare sunt numărul comenzii, numele serviciului și datele pentru care doriți să verificați utilizarea. Nu trimiteți detalii bancare, extrase de cont complete sau capturi de ecran cu informații personale nedorite.

> Starea comenzii după efectuarea plății

Comanda poate necesita un timp pentru a fi confirmată de către furnizor. Creați o comandă duplicat(ă) doar dacă prima comandă este clar anulată sau expirată.
faq/order-status-and-payment-confirmation

Starea "în așteptare" nu înseamnă neapărat eșec

După ce reveniți de pe pagina de plată, comanda poate rămâne în starea de așteptare până când procesatorul de plăți o confirmă. Până când starea nu este clar indicată ca fiind "eșuată" sau expirată, crearea unei noi comenzi duplicate poate complica inutil procesul.

Ce trebuie să faceți după efectuarea plății

  1. După finalizarea plății, reveniți la Cli>_.
  2. Verificați în cont starea comenzii și eventualele mesaje asociate plății.
  3. Dacă comanda este încă în așteptare, acordați furnizorului timp pentru confirmare.
  4. În cazul unei probleme, trimiteți echipei de suport numărul comenzii și referința plății, dacă este disponibilă.

Ce să nu trimiteți

Echipa de asistență nu are nevoie de datele cardului de plată, parola sau întregul extras bancar. Este suficient numărul comenzii, ora efectuării plății, starea vizibilă și o captură de ecran anonimizată, dacă apare o eroare.

> Informații care accelerează configurarea serviciului

Pregătiți numele serviciului, domeniul, capacitatea de stocare, adresa de e-mail de acces și cheia SSH publică; datele confidențiale nu trebuie introduse în formulare.
faq/service-setup-information-needed

Introducerea corectă a datelor economisește timp

Utilizați formularele de comandă pentru valorile publice sau non-confidențiale: numele serviciului, domeniul, planul DNS, dimensiunea stocării, CPU, RAM, adresa de e-mail administrativă sau cheia SSH publică. Parolele, cheile private și tokenurile nu trebuie introduse în formulare.

Pregătiți-vă înainte de a plasa comanda

  1. Alegeți un nume sugestiv pentru serviciul echipei dumneavoastră.
  2. Decideți dacă veți utiliza un domeniu propriu sau un hostname temporar al sistemului.
  3. Pregătiți o cheie SSH publică, dacă este necesară de către serviciu.
  4. Verificați dimensiunea spațiului de stocare și resursele, în funcție de aplicația pe care doriți să o utilizați.

Nu trimite informații confidențiale

Dacă nu sunteți sigur dacă o informație este confidențială, întrebați fără a o trimite. Nu trimiteți chei private, parole, token-uri, exporturi de baze de date și fișiere de configurare complete în chat sau în comenzi.

> Modificarea CPU, RAM, a discului sau a perioadei de retenție după plasarea comenzii

Modificați serviciul existent prin intermediul detaliilor acestuia, nu printr-o nouă comandă duplicată; modificarea resurselor poate afecta prețul, consumul zilnic și poate necesita o repornire.
faq/change-service-resources-after-order

Modificați un serviciu existent, nu creați unul nou

Dacă serviciul este deja activ, efectuați modificările din detaliile acestuia. O nouă comandă ar crea un alt serviciu în loc să modifice cel existent și poate schimba prețul, consumul zilnic de credit și comportamentul sistemului după confirmare, plată și aplicarea modificărilor.

Înainte de a confirma modificarea

  1. Vizualizați utilizarea actuală a CPU, RAM, spațiului pe disc, a backup-urilor și perioada de retenție pentru arhivele externe.
  2. Verificați noul preț zilnic și impactul asupra creditelor disponibile.
  3. Citiți notificările despre reporniri, întreținere sau întreruperi.
  4. Înainte de a efectua o modificare care prezintă riscuri, creați o copie de rezervă a datelor importante.

Ce se întâmplă dacă modificările nu au loc conform așteptărilor

Trimiteți numele serviciului, ora modificării, starea vizibilă și mesajele de eroare. Nu trimiteți chei private, parole sau token-uri; pentru diagnosticare este suficient contextul public și un screenshot cu informațiile sensibile mascate.

> Anulare serviciu și perioada de ștergere a datelor

Serviciul activat este inițial suspendat, afișează o perioadă vizibilă configurabilă pentru ștergere și ulterior poate urma o curățare definitivă.
faq/cancel-service-and-data-retention

Anularea nu implică ștergerea imediată a tuturor serviciilor

Pentru un serviciu deja activat, acesta este mai întâi suspendat și afișează o perioadă configurabilă până la data de expirare, timp în care se poate efectua o restaurare sau export. Comenzile neplătite aflate în așteptare, fără date active, pot avea un comportament diferit, iar ștergerea definitivă are loc abia după expirarea perioadei de valabilitate.

Verificați înainte de ștergere

  1. Gestionați exportul propriu al datelor pe care doriți să le păstrați pe termen lung.
  2. Citiți data și ora programată pentru ștergerea serviciului în cazul în care acesta este suspendat.
  3. Nu confundați backup-urile și arhivele externe cu ștergerea ciclului de viață a serviciului.
  4. Dacă nu sunteți sigur, contactați echipa de suport înainte de data limită pentru ștergere.

Restaurarea după termenul limită poate să nu fie posibilă.

După expirarea perioadei vizibile, datele nu trebuie considerate disponibile. Când solicitați asistență, vă rugăm să trimiteți numărul comenzii și numele serviciului, dar nu exporturi de baze de date sau informații confidențiale de autentificare.

> Backups și cereri de restaurare

Backup-urile sunt utilizate pentru recuperarea operațională, nu înlocuiesc exporturile; restaurarea poate suprascrie datele mai recente.
faq/backups-and-restore-requests

Backup-ul nu este o arhivă sau o exportare

Perioada de retenție a backup-urilor depinde de produsul selectat și de opțiunile alese. Backup-urile ajută la recuperarea operațională în caz de eroare, dar nu înlocuiesc exporturile proprii, arhivele de audit sau arhiva offsite. Restaurarea poate suprascrie modificările mai recente.

Cum pregătiți o cerere de restaurare

  1. Introduceți numele serviciului și numărul comenzii.
  2. Descrieți timpul aproximativ la care doriți să reveniți.
  3. Specificați dacă se va restaura întregul serviciu sau doar o parte, dacă este posibil.
  4. Includeți o eroare vizibilă sau context, fără parole, token-uri și chei private.

Evaluați impactul înainte de a restaura

Dacă serviciul a primit date noi între timp, acestea pot înlocui starea anterioară. Înainte de a confirma restaurarea, informați echipa și faceți o copie de rezervă a datelor pe care nu doriți să le pierdeți.

> La ce servește Offsite Archive

Offsite Archive stochează copii de rezervă la distanță, separate de backup-urile operaționale și de ciclul de viață al serviciului.
faq/offsite-archive-purpose

Arhivă externă pentru operațiuni speciale

Arhiva externă este destinată creării de copii de rezervă la distanță și stocării pe termen lung a datelor. Nu este un disc activ pentru aplicații, o înlocuire a exportului local sau același lucru cu backup-uri operaționale scurte.

Când să-l activați

  1. Utilizați-l pentru date pe care doriți să le păstrați și în afara funcționării normale a serviciului.
  2. Selectați numărul de zile de retenție în funcție de cerințele de conformitate, nevoile comerciale sau obiectivele de recuperare.
  3. Monitorizați modul în care prețul crește în funcție de volumul stocat și de durata de păstrare.
  4. Pentru volume mari de date, planificați arhiva împreună cu propriul proces de export.

Cum să abordăm costul

Baza este MB-days: cantitatea de date stocate și numărul de zile pe parcursul cărora sunt păstrate. Tariful este afișat clientului ca EUR/GB/lună, iar rezultatul este rotunjit la cea mai apropiată sutime.

> Selectarea procesorului (CPU), a memoriei RAM și a discului pentru un server virtual privat (VPS)

Alegeți dimensiunea VPS în funcție de aplicație, bază de date, cache, jurnale și creștere; OOM sau utilizarea swap-ului indică necesitatea unei cantități mai mari de memorie RAM.
faq/vps-cpu-ram-and-disk-sizing

Începeți în funcție de încărcarea reală, nu de presupuneri

Un site web static mic are nevoi diferite față de o bază de date, o aplicație Java, un motor de căutare sau un container cu build-uri. Când planificați, luați în considerare memoria aplicației, cache-ul, baza de date, jurnalele, încărcările și rezervele pentru creștere.

Semne că planul este insuficient

  1. Crește memoria RAM în cazul apariției situațiilor OOM (out of memory), a terminării proceselor sau a utilizării constante a swap-ului.
  2. Crește puterea CPU în cazul unei încărcări de lucru constante, a compresiei, a compilărilor sau a activității intense a aplicațiilor.
  3. Mărește spațiul pe disc înainte ca sistemul de fișiere, jurnalele sau baza de date să se umple.
  4. După fiecare modificare, verificați dacă aplicația a încetat să mai atingă limita inițială.

Ce informații să trimiteți când aveți întrebări despre capacitate

Pentru a ne ajuta, vă rugăm să furnizați numele serviciului, tipul de aplicație, erorile vizibile, ora aproximativă a problemei și resursele CPU, RAM și spațiul pe disc alocate în prezent. Vă rugăm să nu trimiteți parole, chei private sau fișiere de configurare interne.

> Când are sens o adresă IP publică pentru un VPS

O adresă IP publică dedicată poate fi utilă pentru liste de permisiuni, acces inbound, o sursă outbound stabilă sau servicii asociate unei adrese.
faq/vps-public-ip-options

Înțelegeți mai întâi direcția comunicării

O adresă IP publică nu este necesară pentru fiecare serviciu. De obicei, aceasta rezolvă cerințele partenerilor externi, ale furnizorilor sau ale firewall-urilor pentru liste de permisiuni (allowlist), o sursă stabilă de ieșire (outbound) sau acces de intrare (inbound) pe un anumit port.

Întrebări înainte de a comanda un IP

  1. Întrebați partenerul dacă este necesară o listă de permisiuni (allowlist) pentru traficul inbound, outbound sau pentru ambele direcții.
  2. Utilizați numele DNS în loc de adrese IP numerice ori de câte ori sistemul extern permite acest lucru.
  3. Deschideți doar porturile care sunt necesare aplicației.
  4. Trimiteți cererea pentru lista de permisiuni către suport înainte de a modifica accesul în mediul de producție.

Ce să lăsați închis

Un IP public nu trebuie să însemne deschiderea tuturor porturilor. Planificați accesul doar pentru serviciile strict necesare și nu trimiteți parole, chei private sau reguli interne ale firewall-ului sub formă de capturi de ecran care conțin informații confidențiale.

> Acces SSH partajat pentru VPS

Fără o adresă IP publică achiziționată, serverul VPS se conectează printr-un punct de acces SSH partajat, folosind un port înalt. Dacă aveți o adresă IP publică, puteți accesa direct și prin SSH la acea adresă.
faq/shared-ssh-access-for-vps

De ce se folosește un port înalt pentru SSH partajat

Mai multe servicii VPS pot utiliza același endpoint SSH public, de aceea fiecare serviciu primește propriul port înalt. Portul face parte din rutarea către serviciul tău; fără el, conexiunea nu poate fi livrată clar către VPS-ul corect.

Cum vă conectați în funcție de tipul de acces

  1. Atunci când utilizați SSH partajat, copiați numele de utilizator, host-ul și portul exact așa cum sunt afișate în serviciul SSH.
  2. Conectați folosind comanda ssh -p <port> <username>@<public-host> din terminalul local.
  3. Dacă serviciul are o adresă IP publică achiziționată, poate exista un al doilea endpoint SSH direct pe acea adresă IP sau pe numele său DNS.
  4. Utilizați cheia privată doar local, prin intermediul clientului SSH sau al agentului; către suport trimiteți doar host-ul public, portul, numele de utilizator și eroarea vizibilă.

Când aveți o adresă IP publică suplimentară

Adresa IP publică nu înlocuiește endpoint-ul SSH partajat; adaugă o cale directă separată pentru liste de permisiuni, monitorizare sau integrări. De aceea, puteți vedea atât un host partajat cu un port ridicat, cât și un host sau o adresă IP directă.

> Verificare înainte de conectarea domeniului dumneavoastră

Înainte de a comuta domeniul, verificați DNS-ul autoritativ, numele de gazdă exact, tipul înregistrării (domeniu sau subdomeniu) și eventualele înregistrări vechi conflictuale.
faq/custom-domain-readiness-checklist

Este important să cunoașteți numele de domeniu exact

În primul rând, clarificați dacă conectați domeniul principal (de exemplu, example.com) sau un subdomeniu (de exemplu, app.example.com). Fiecare variantă poate necesita un tip diferit de înregistrare DNS, restricții diferite impuse de furnizorul DNS și verificări la registrator.

Înainte de a modifica setările DNS

  1. Verificați unde sunt gestionate înregistrările DNS autoritative pentru domeniu.
  2. Eliminați sau modificați înregistrările A/AAAA, CNAME, ALIAS, ANAME sau de redirecționare conflictuale.
  3. Utilizați tipul de înregistrare recomandat pentru serviciul și numele de gazdă specific.
  4. După ce efectuați modificarea, așteptați propagarea DNS și testați conexiunea HTTPS înainte de a trece traficul în producție.

Restaurare sigură

Nu dezactivați serverul vechi până când noul nume de domeniu răspunde corect. Când raportați o problemă, vă rugăm să furnizați domeniul, destinația așteptată și rezultatele DNS vizibile, nu informațiile de autentificare ale registrului.

> Tipuri de înregistrări DNS pentru servicii

Înregistrările A/AAAA indică adresele, CNAME creează aliasuri, MX este utilizat pentru e-mail și TXT pentru verificări, SPF, DKIM sau DMARC.
faq/dns-record-types-for-services

Nu combinați înregistrările la întâmplare

Fiecare tip de înregistrare DNS are un rol diferit. Înregistrările A și AAAA indică adrese IP, CNAME creează un alias pentru subdomeniu, MX direcționează e-mailurile, TXT conține verificări și politici de e-mail, iar CAA restricționează autoritățile de certificare.

Când copiați înregistrări

  1. Copiază exact numele, tipul și valoarea conform instrucțiunilor serviciului.
  2. Nu utiliza CNAME pentru un nume de gazdă care are deja alte înregistrări, dacă regulile DNS interzic acest lucru.
  3. Introdu DKIM sub selectorul furnizat de provider și DMARC de obicei sub _dmarc.
  4. Configurați CAA cu atenție, deoarece valorile incorecte pot bloca emiterea certificatului.

Ce se întâmplă când DNS-ul nu funcționează

Trimiteți echipei de suport numele gazdă, tipul înregistrării, valoarea așteptată și rezultatul vizibil public. Nu trimiteți datele de autentificare pentru administrarea DNS sau capturi de ecran cu token-uri API.

> Propagarea DNS și TTL: fără garanții de precizie

TTL (Time To Live) determină durata pentru care serverele DNS stochează răspunsurile vechi. În timpul propagării, atât rezultatele vechi, cât și cele noi pot coexista până când memoria cache expiră.
faq/dns-propagation-and-ttl

Propagarea DNS: un proces de actualizare a cache-ului, nu o magie instantanee

În sistemul DNS, nu există o garanție fixă pentru timpul de propagare. După modificarea serverelor DNS autoritative, diferite rezolvitoare pot returna încă răspunsuri vechi și noi până când memoria lor cache expiră conform valorii TTL. Prin urmare, rezultatul poate varia în funcție de rețea, țară sau rezolvitorul DNS utilizat.

În cazul unei schimbări planificate

  1. Dacă furnizorul permite, reduceți TTL-ul înainte de schimbarea planificată.
  2. După modificarea DNS, evitați modificările repetate până când memoria cache expiră.
  3. Testați din mai multe rețele dacă rezultatele sunt diferite.
  4. Notați ora modificării, valoarea veche, noua valoare și TTL.

Ce informații să trimiteți în timpul diagnosticului

Furnizați numele gazdă, ținta așteptată, răspunsul vechi vizibil, noul răspuns vizibil, TTL și ora modificării. Nu trimiteți date de autentificare pentru contul DNS sau note interne ale furnizorului.

> Planificarea spațiului de stocare pentru Workspace Suite

În calculul capacității, includeți fișierele utilizatorilor, folderele partajate, versiunile, coșul de reciclare, previzualizările, overhead-ul sincronizării și creșterea echipei.
faq/nextcloud-storage-planning

Workspace Suite crește chiar și dincolo de fișierele vizibile

Spațiul de stocare este utilizat de fișierele utilizatorilor, folderele partajate, fișierele șterse, versiuni, previzualizări, imagini miniaturale, clienții de sincronizare și importuri. Dacă spațiul de stocare se apropie de limită, încărcările sau sincronizarea pot eșua.

Înainte de a solicita capacitate suplimentară

  1. Calculați numărul actual de utilizatori și spațiul ocupat de folderele partajate.
  2. Adăugați un buffer pentru versiuni, coș de reciclare, previzualizări și activitatea de sincronizare.
  3. Țineți cont de importuri mari, echipe noi și creșterea estimată.
  4. Crește capacitatea înainte ca utilizatorii să atingă limita.

În cazul problemelor de sincronizare

Trimite informații despre dimensiunea serviciului, utilizarea estimată, ora problemei și mesajul de eroare vizibil clientului. Nu trimite fișiere personale, parole sau exporturi de date ale utilizatorilor decât dacă echipa de suport le solicită în mod explicit printr-un canal sigur.

> Migrarea repository-urilor către Gitea

Planificați migrarea repository-urilor Git, incluzând LFS, submodule, drepturi de acces, chei de implementare, webhook-uri și CI/CD.
faq/gitea-repository-migration

Migrarea nu este doar un simplu `git clone`

Pe lângă istoricul depozitului, trebuie transferați sau reconfigurați proprietarii, echipele, ramurile protejate, etichetele protejate, Git LFS, submodulele, cheile de implementare, webhook-urile și conexiunile CI/CD.

Verificare pre-tranziție

  1. Listează depozitele, proprietarii, colaboratorii, obiectele Git LFS, modulele secundare, ramurile protejate și utilizatorii de automatizare.
  2. Copiază sau exportă depozitele de la furnizorul vechi și verifică ramurile și etichetele.
  3. Actualizează URL-urile remote pentru dezvoltatori, integrările CI/CD, webhook-urile și cheile de implementare, apoi verifică funcționalitatea clonei, a push-ului, a Git LFS, a modulelor secundare și a comportamentului CI.
  4. Anulează sau schimbă token-urile vechi după finalizarea migrării, fără a partaja valorile acestora.

Date sensibile în timpul migrării

Nu trimite către suport token-uri, chei private, secțiuni private ale cheilor de implementare sau secrete CI. Trimite doar numele depozitelor, tipul de integrare, erori vizibile și informații despre ceea ce funcționa înainte de migrare.

> Domeniul de trimitere pentru Listmonk

Pentru campanii, pregătiți un domeniu sau subdomeniu de trimitere, identitatea "From", înregistrările SPF, DKIM, DMARC, gestionarea mesajelor returnate și opțiunea de dezabonare.
faq/listmonk-sender-domain-basics

Livrarea începe cu domeniul

Listmonk are nevoie de o identitate "From" clară și de înregistrări DNS pe care lumea poștală le poate verifica. SPF, DKIM și DMARC trebuie să fie configurate corect pentru domeniul sau subdomeniul din care doriți să trimiteți campanii.

Înainte de prima campanie

  1. Selectați domeniul sau subdomeniul expeditorului și specificați numele "From".
  2. Adăugați înregistrările DNS de verificare, SPF, selectorul DKIM și DMARC solicitate de furnizorul dvs. de e-mail.
  3. Trimiteți mesaje de test înainte de o campanie reală și verificați dacă mesajele ajung în spam, comportamentul mesajelor returnate, Return-Path și linkurile din mesaj.
  4. Verificați opțiunea de dezabonare și funcția List-Unsubscribe înainte de a trimite campania.

Informațiile confidențiale despre e-mail nu trebuie incluse în solicitările de asistență.

Când solicitați asistență, vă rugăm să furnizați domeniul, tipul înregistrării, valoarea DNS vizibilă public și mesajul de eroare. Nu trimiteți parole SMTP, tokenuri API, chei DKIM private sau exporturi de adrese cu date personale.

> Setări de runtime pentru Classic Hosting

Classic Hosting poate funcționa în modul automat sau manual. CPU, RAM, memorie, stocare, perioada de păstrare a backup-urilor, perioada de păstrare a arhivei Offsite, upload-uri, cache și log-uri influențează prețul și stabilitatea.
faq/classic-hosting-runtime-settings

Modul automat nu este întotdeauna cea mai bună opțiune

Auto Runtime ajută la proiectele detectate, dar modul manual este potrivit atunci când doriți să alegeți exact Nginx, Apache, FrankenPHP sau un anumit runtime pentru limbaj. Utilizați selectorul PHP numai acolo unde acesta este suportat de runtime-ul selectat.

Setări pre-implementare

  1. Alege modul automat pentru compilările detectate sau modul manual pentru controlul runtime-ului Nginx, Apache sau FrankenPHP.
  2. Selectează PHP 8.2/8.3/8.4 doar acolo unde runtime-ul ales suportă această opțiune.
  3. Configurează CPU, RAM, memorie, stocare, retenția backup și retenția arhivei externe în funcție de trafic și date.
  4. După implementare, testați încărcările, memoria cache, jurnalele și erorile vizibile ale aplicației.

Când aplicația nu pornește

Trimiteți modul de execuție, limba sau versiunea PHP, orice eroare vizibilă, modificările efectuate și ora aproximativă a implementării. Nu trimiteți fișiere .env, parole, token-uri sau jurnale complete care conțin informații sensibile.

> Ce informații puteți trimite în siguranță către suport

Cel mai util sunt numerele comenzilor, numele serviciilor, domeniile, orele, serverele publice, porturile, perioadele de retenție a backup-urilor, perioada de păstrare a datelor în Offsite Archive, upload-urile, cache-ul, log-urile și capturi de ecran, precum și erorile vizibile, fără a include informații confidențiale.
faq/support-safe-information-to-share

O solicitare de calitate trebuie să conțină informații relevante, nu date confidențiale.

Echipa de asistență poate răspunde mai rapid dacă primește numărul comenzii, numele serviciului, domeniul, host-ul sau portul public, ora problemei, modificările efectuate și mesajul exact al erorii afișate.

Conținut sigur pentru mesaj

  1. Specificați comanda, serviciul, domeniul, ora și etapa în care a apărut problema.
  2. Pentru probleme legate de hosting, includeți mediul de rulare, versiunea PHP sau limbajul, CPU, RAM, spațiu pe disc, upload-uri, cache și log-uri, fără informații confidențiale.
  3. Înainte de a trimite capturi de ecran, eliminați sau mascați zonele sensibile.
  4. Dacă nu sunteți sigur dacă o informație este relevantă pentru tichet, întrebați mai întâi înainte de a o trimite.

Ce să nu trimiteți niciodată

Nu trimiteți parole, chei private, coduri de recuperare, token-uri API, cookie-uri de sesiune, exporturi de baze de date, fișiere .env complete, log-uri complete cu informații sensibile sau detalii despre infrastructura internă.