FAQ

Често постављана питања

Практични кратки водичи за подешавање услуге, приступ и уобичајене радње корисника.

> Kreiranje javnog SSH ključa u terminalu

Napravi javni SSH ključ za pristup i deli samo javni deo.

faq/generate-public-ssh-key-sr

Koristi samo javni ključ

SSH koristi par ključeva. U podešavanja usluge nalepi samo javni ključ, obično .pub fajl. Privatni ključ ostaje na tvom uređaju.

Koraci u terminalu

  1. Otvori Terminal, Windows Terminal ili PowerShell.
  2. Pokreni: ssh-keygen -t ed25519 -C "your-email@example.com".
  3. Prihvati podrazumevanu lokaciju ili izaberi bezbednu putanju.
  4. Prikaži javni ključ sa: cat ~/.ssh/id_ed25519.pub.
  5. U Windows PowerShell koristi: Get-Content $env:USERPROFILE\.ssh\id_ed25519.pub.
  6. Kopiraj celu ssh-ed25519 liniju u polje SSH public key.

Proveri pre lepljenja

Ne kopiraj privatni ključ. Ako postaviš passphrase, sačuvaj je bezbedno.

> Kreiranje SSH ključa grafički u Windowsu

Koristi PuTTYgen u Windowsu i kopiraj samo javni ključ.

faq/create-ssh-key-windows-gui-sr

Dovoljan je javni deo

PuTTYgen pravi javni i privatni ključ. U Cli>_ dodaj samo javni ključ, a privatni čuvaj lokalno.

Koraci u Windowsu

  1. Otvori PuTTYgen.
  2. Izaberi EdDSA / Ed25519 kada je dostupno.
  3. RSA 4096 koristi samo kao rezervu.
  4. Klikni Generate i pomeraj miš dok se ključ ne napravi.
  5. Sačuvaj privatni ključ na računaru.
  6. Kopiraj tekst javnog ključa u polje SSH public key.

Ne deli tajne podatke

Ne šalji .ppk fajlove, privatne ključeve, passphrase, lozinke ili tokene podršci ili formularima.

> Povezite svoj domen

Pre prebacivanja domena proveri registrar, autoritativne nameservere, tačan hostname, apex ili subdomen, tip zapisa i konflikte.

faq/povezite-svoj-domen

Najvažniji je tačan hostname

Prvo odluči da li povezuješ apex domen kao example.com ili subdomen kao app.example.com. Od toga zavisi da li su dozvoljeni CNAME, A/AAAA, ALIAS ili ANAME zapisi i gde ih uređuješ.

Pre DNS izmene

  1. Potvrdi da uređuješ DNS kod autoritativnih nameservera ili registrara.
  2. Ukloni konfliktne A/AAAA, CNAME, ALIAS, ANAME ili redirect zapise za isti hostname.
  3. Koristi tip zapisa koji odgovara hostnamu i podršci DNS provajdera.
  4. Sačekaj propagaciju DNS-a i proveru sertifikata pre produkcionog prebacivanja.

Bezbedan rollback

Stari hosting ne gasi dok novi hostname ne odgovara ispravno. Za pomoć pošalji domen, očekivani cilj i javno vidljiv DNS rezultat, a ne pristup registraru ili API tokene.

> Prenos DNS zone

A/AAAA vode na adrese, CNAME na alias, MX na poštu, TXT na verifikacije, SPF, DKIM i DMARC, a CAA može uticati na sertifikate.

faq/prenos-dns-zone

Svaki zapis ima svoju ulogu

A i AAAA pokazuju na IP adrese, CNAME pravi alias za dozvoljen subdomen, MX usmerava poštu, TXT nosi verifikacije i mail politike, a CAA ograničava sertifikacione autoritete.

Kopiranje DNS vrednosti

  1. Prepiši naziv, tip i vrednost tačno kako usluga traži.
  2. Ne stavljaj CNAME na hostname koji već ima konfliktne zapise ako DNS pravila to zabranjuju.
  3. DKIM postavi pod selector provajdera, a DMARC najčešće pod _dmarc.
  4. CAA menjaj pažljivo jer pogrešna vrednost može blokirati sertifikat.

Dijagnostika DNS problema

Podršci pošalji hostname, tip zapisa, očekivanu vrednost i javno vidljiv rezultat. Ne šalji login za DNS panel, API token ili screenshot sa tajnim vrednostima.

> Registracija naloga i prvo prijavljivanje

Koristi jedan radni nalog za porudžbine, naplatu i upravljanje uslugama, sa e-mail adresom kojoj tim neće izgubiti pristup.

faq/account-registration-and-login

Nalog koji ostaje timu

Korisnički nalog je mesto gde pratiš porudžbine, fakturisanje, domene i aktivne usluge. Najbolje je koristiti poslovnu e-mail adresu ili adresu kojoj tim može dugoročno da pristupi, umesto ličnog sandučeta jedne osobe.

Pre prve porudžbine

  1. Registruj se radnom e-mail adresom.
  2. Potvrdi e-mail ako sistem zatraži verifikaciju.
  3. Unesi tačne podatke za fakturisanje pre plaćene porudžbine.
  4. Uključi dvofaktorsku zaštitu čim bude dostupna za nalog.

Bezbedan pristup za kolege

Lozinku ne šalji kroz chat, tiket ili e-mail. Ako više ljudi mora da radi sa nalogom, koristi interni menadžer lozinki ili dogovoreni timski postupak; podršci ne treba tvoja lozinka ni privatan token.

> Kako radi prepaid kredit

Prepaid kredit pokazuje stanje, procenu trajanja, dnevnu cenu aktivnih usluga i rizik suspenzije ili vidljivog roka brisanja.

faq/prepaid-credit-how-it-works

Kredit se troši dok usluga radi

Kod podobnih usluga kredit se skida tokom aktivnog rada, prema izabranim resursima i opcijama. Zato su vidljivo stanje, procena koliko dana preostaje i dnevna cena važniji od same mesečne orijentacije.

Kako izbeći prekid usluge

  1. Dopuni kredit iz korisničke zone pre nego što stanje postane kritično.
  2. Pre potvrde porudžbine ili izmene proveri prikazanu dnevnu cenu.
  3. Prati upozorenja o niskom stanju, suspenziji i vidljivom roku brisanja.
  4. Ako je usluga suspendovana, reaguj pre roka posle koga podaci mogu biti obrisani.

Kada stanje izgleda pogrešno

Za proveru pošalji broj porudžbine, naziv usluge i period koji treba uporediti. Ne šalji kartične podatke, lozinke, privatne ključeve ili kompletne izvode sa osetljivim informacijama.

> Mesečna procena, godišnja procena i dnevno trošenje kredita

Mesečni i godišnji iznosi služe za poređenje; prepaid usluge realno troše kredit dnevno posle potvrde, plaćanja ako je potrebno i primene izmene.

faq/billing-periods-and-credit-burn

Procena nije kalendar fakturisanja

Mesečna procena koristi 31 dan, a godišnja 372 dana, da bi se planovi mogli porediti. Kod prepaid usluga stvarno trošenje zavisi od aktivnog vremena, CPU, RAM, diska i plaćenih opcija.

Pre prihvatanja nove cene

  1. Uporedi dnevnu potrošnju pre i posle porudžbine ili izmene.
  2. Računaj da veći CPU, RAM, disk ili dodatne opcije menjaju cenu.
  3. Smatraj izmenu važećom tek kada je potvrđena, plaćena ako treba i primenjena.
  4. Sačuvaj potvrde porudžbina i vidljivu istoriju kredita za računovodstvo.

Provera obračuna

Podršci pošalji broj porudžbine, naziv usluge i datume koje treba proveriti. Ne šalji cele bankovne izvode, kartične podatke ili screenshotove sa ličnim podacima koji nisu potrebni.

> Status porudžbine posle plaćanja

Porudžbina može kratko čekati potvrdu provajdera plaćanja; novu porudžbinu pravi tek kada je prva jasno istekla ili otkazana.

faq/order-status-and-payment-confirmation

Pending nije odmah neuspeh

Nakon plaćanja status može ostati na čekanju dok provajder plaćanja ne pošalje potvrdu. Dupla porudžbina pre jasnog isteka ili otkazivanja može otežati uparivanje plaćanja.

Redosled posle plaćanja

  1. Vrati se sa stranice provajdera plaćanja nazad u Cli>_.
  2. U nalogu proveri vidljiv status porudžbine.
  3. Sačekaj potvrdu provajdera ako je status još pending.
  4. Ako se status ne menja, pošalji broj porudžbine i referencu plaćanja ako je vidiš.

Podaci koji nisu potrebni

Podršci ne trebaju broj kartice, lozinka naloga ili kompletna bankovna potvrda. Dovoljan je broj porudžbine, vreme plaćanja, vidljiv status i maskiran screenshot greške ako postoji.

> Podaci koji ubrzavaju podešavanje usluge

Pripremi naziv usluge, domen, DNS plan, resurse, admin e-mail i javni SSH ključ; tajni podaci ne idu u formulare.

faq/service-setup-information-needed

Tačni ulazi sprečavaju zastoje

Formulari za porudžbinu traže korisničke izbore kao što su naziv usluge, domen, DNS cilj, storage, CPU, RAM, pristupni e-mail ili javni SSH ključ. Lozinke, privatni ključevi i tokeni ne pripadaju tim poljima.

Priprema pre checkouta

  1. Izaberi naziv usluge koji će tim prepoznati.
  2. Pripremi tačan domen ili odluči da koristiš privremeni hostname.
  3. Spremi javni SSH ključ ako ga proizvod traži.
  4. Proveri potrebne resurse i veličinu diska prema aplikaciji koju pokrećeš.

Ako nisi siguran šta je tajno

Pitaj bez slanja same vrednosti. Privatne ključeve, lozinke, API tokene, baze podataka i kompletne konfiguracije ne šalji kroz porudžbinu ili tiket.

> Promena CPU, RAM, diska ili retencije posle porudžbine

Postojeću uslugu menjaj iz njenog detalja, uz proveru nove cene, dnevnog troška, plaćanja, restarta, zastoja i potrebe za exportom.

faq/change-service-resources-after-order

Ne naručuje se nova kopija usluge

Ako usluga već postoji, promenu resursa radi iz njenog detalja. Nova porudžbina obično znači novu uslugu, dok izmena postojeće može promeniti dnevnu potrošnju kredita tek nakon potvrde, eventualnog plaćanja i primene.

Kontrola pre potvrde

  1. Pogledaj trenutni CPU, RAM, disk, backup retenciju i Offsite Archive retenciju.
  2. Proveri novu cenu i uticaj na dnevno trošenje kredita.
  3. Pročitaj upozorenje o restartu, održavanju ili prekidu rada.
  4. Pre rizične izmene napravi svoj export važnih podataka.

Ako izmena ne prođe očekivano

Pošalji naziv usluge, vreme izmene, vidljiv status i tekst greške. Ne šalji lozinke, privatne ključeve, tokene ili konfiguracije sa tajnim vrednostima.

> Otkazivanje usluge i rok brisanja podataka

Provisioned usluga se prvo suspenduje, prikazuje podesiv vidljiv rok brisanja, a trajno čišćenje dolazi tek posle životnog ciklusa.

faq/cancel-service-and-data-retention

Otkazivanje nije uvek trenutno brisanje

Kod već provisioned usluge otkazivanje prvo dovodi do suspenzije i prikaza podesivog vidljivog roka brisanja. Neplaćene porudžbine koje nikada nisu pokrenule podatke mogu imati drugačiji tok.

Pre otkazivanja

  1. Napravi sopstveni export podataka koje želiš da zadržiš.
  2. Pročitaj datum i vreme mogućeg brisanja prikazane kod usluge.
  3. Ne mešaj backup retenciju i Offsite Archive retenciju sa brisanjem same usluge.
  4. Kontaktiraj podršku pre roka ako nisi siguran šta će biti obrisano.

Posle roka nema garancije oporavka

Kada vidljiv rok prođe, ne treba računati da su podaci i dalje dostupni. U tiketu navedi broj porudžbine i naziv usluge, ali ne šalji export baze ili tajne pristupne podatke.

> Backup i zahtevi za restore

Backup služi za operativni oporavak, ne kao zamena za sopstveni export; restore može prepisati novije podatke.

faq/backups-and-restore-requests

Backup nije arhiva za sve potrebe

Retencija zavisi od proizvoda i izabranih opcija. Backup pomaže kod operativnih grešaka, ali ne zamenjuje poslovni export, dugoročnu arhivu ili Offsite Archive; restore može vratiti starije stanje preko novijih izmena.

Dobar restore zahtev

  1. Navedi naziv usluge i broj porudžbine.
  2. Napiši približno vreme na koje želiš povratak.
  3. Objasni da li treba cela usluga ili određeni deo ako je podržano.
  4. Dodaj vidljivu grešku ili kontekst bez lozinki, tokena i privatnih ključeva.

Planiraj uticaj oporavka

Ako su korisnici nastavili da rade posle željenog vremena oporavka, noviji podaci mogu biti izgubljeni. Pre potvrde restorea obavesti tim i sačuvaj ono što ne želiš da prepišeš.

> Čemu služi Offsite Archive

Offsite Archive čuva udaljene arhivske kopije odvojeno od kratkih operativnih backupova i od životnog ciklusa usluge.

faq/offsite-archive-purpose

Arhiva van svakodnevnog rada

Offsite Archive je za udaljene kopije i duže čuvanje podataka. Nije live disk aplikacije, nije zamena za lokalni export i nije isto što i kratki backup za operativni restore.

Kada ga koristiti

  1. Uključi ga za podatke koje želiš zadržati van redovnog životnog ciklusa usluge.
  2. Izaberi broj dana retencije prema pravilima ili recovery cilju.
  3. Računaj da cena raste sa količinom podataka i vremenom čuvanja.
  4. Za velike skupove podataka planiraj i sopstveni export proces.

Kako se čita cena

Osnova su MB-days: koliko megabajta je sačuvano i koliko dana se drže. Cena se prikazuje kao EUR/GB/mesec, a obračun se zaokružuje na cele cente.

> Izbor CPU, RAM i diska za VPS

Veličinu VPS-a biraj prema aplikaciji, bazi, cacheu, logovima i rastu; OOM, out of memory i process killed ukazuju na manjak RAM-a.

faq/vps-cpu-ram-and-disk-sizing

Kreni od realnog opterećenja

Statičan sajt, baza podataka, Java aplikacija, pretraga ili build proces imaju različite potrebe. Pri planiranju uključi memoriju aplikacije, cache, bazu, logove, upload fajlove i rezervu za rast.

Kada povećati resurse

  1. Povećaj RAM kod OOM, out of memory, process killed poruka ili stalnog swapovanja.
  2. Povećaj CPU kod dugog compute opterećenja, kompresije, buildova ili zauzetih workera.
  3. Povećaj disk pre nego što filesystem, logovi ili baza dođu do limita.
  4. Posle izmene prati da li je nestao izvorni problem.

Kontekst za sizing pitanje

Korisno je poslati naziv usluge, tip aplikacije, vidljivu grešku, približno vreme problema i trenutne CPU, RAM i disk vrednosti. Ne šalji lozinke, privatne ključeve ili kompletne interne konfiguracije.

> Kada VPS treba javnu IP adresu

Dedikovana javna IP pomaže kod allowlista, inbound pristupa, stabilnog outbound izvora i servisa vezanih za adresu.

faq/vps-public-ip-options

Prvo utvrdi smer saobraćaja

Javna IP nije potrebna za svaku aplikaciju. Najčešće je traže spoljni partneri, provajderi ili firewall pravila koja očekuju stabilnu adresu za inbound pristup, outbound izvor ili oba smera.

Pitanja pre naručivanja IP-a

  1. Pitaj partnera da li allowlist važi za inbound, outbound ili oba smera.
  2. Koristi DNS imena umesto numeričkih adresa gde je moguće.
  3. Otvori samo portove koje aplikacija zaista koristi.
  4. Podeli zahtev za allowlist sa podrškom pre promene produkcionog pristupa.

Javna adresa nije otvoren server

Dedikovana IP ne znači da treba otvoriti sve portove. Čuvaj pristup minimalnim, neophodnim servisima i ne šalji privatne ključeve, lozinke ili screenshotove firewall pravila sa osetljivim vrednostima.

> Deljeni SSH pristup za VPS

Bez dedikovane javne IP VPS koristi deljeni SSH pristup preko visokog porta; javna IP može omogućiti direktan SSH samo ako je tako podešeno.

faq/shared-ssh-access-for-vps

Zašto postoji visok port

Više VPS usluga može deliti isti javni SSH host, pa svaka dobija svoj visoki port. Taj port usmerava vezu do tvoje konkretne VPS usluge; bez njega deljeni host ne bi znao kojoj mašini da prosledi vezu.

Kako se povezati

  1. Za deljeni SSH kopiraj SSH korisničko ime, javni host i visoki port sa stranice usluge.
  2. Koristi komandu ssh -p <port> <username>@<public-host>.
  3. Ako usluga ima dedikovanu javnu IP, direktan SSH na tu IP adresu radi samo ako je SSH servis i firewall pravilo za to podešeno.
  4. Privatni ključ koristi samo lokalno kroz SSH klijent ili agent.

Dva moguća SSH puta

Dedikovana javna IP ne ukida automatski deljeni pristup i ne znači da je port 22 otvoren. Ona može dodati direktan pristup za allowlist, monitoring ili integracije. U podršku šalji samo javni host, port, korisničko ime i vidljivu grešku, nikad privatni ključ.

> Provera pre povezivanja sopstvenog domena

Pre prebacivanja domena proveri registrar, autoritativne nameservere, tačan hostname, apex ili subdomen, tip zapisa i konflikte.

faq/custom-domain-readiness-checklist

Najvažniji je tačan hostname

Prvo odluči da li povezuješ apex domen kao example.com ili subdomen kao app.example.com. Od toga zavisi da li su dozvoljeni CNAME, A/AAAA, ALIAS ili ANAME zapisi i gde ih uređuješ.

Pre DNS izmene

  1. Potvrdi da uređuješ DNS kod autoritativnih nameservera ili registrara.
  2. Ukloni konfliktne A/AAAA, CNAME, ALIAS, ANAME ili redirect zapise za isti hostname.
  3. Koristi tip zapisa koji odgovara hostnamu i podršci DNS provajdera.
  4. Sačekaj propagaciju DNS-a i proveru sertifikata pre produkcionog prebacivanja.

Bezbedan rollback

Stari hosting ne gasi dok novi hostname ne odgovara ispravno. Za pomoć pošalji domen, očekivani cilj i javno vidljiv DNS rezultat, a ne pristup registraru ili API tokene.

> Tipovi DNS zapisa za usluge

A/AAAA vode na adrese, CNAME na alias, MX na poštu, TXT na verifikacije, SPF, DKIM i DMARC, a CAA može uticati na sertifikate.

faq/dns-record-types-for-services

Svaki zapis ima svoju ulogu

A i AAAA pokazuju na IP adrese, CNAME pravi alias za dozvoljen subdomen, MX usmerava poštu, TXT nosi verifikacije i mail politike, a CAA ograničava sertifikacione autoritete.

Kopiranje DNS vrednosti

  1. Prepiši naziv, tip i vrednost tačno kako usluga traži.
  2. Ne stavljaj CNAME na hostname koji već ima konfliktne zapise ako DNS pravila to zabranjuju.
  3. DKIM postavi pod selector provajdera, a DMARC najčešće pod _dmarc.
  4. CAA menjaj pažljivo jer pogrešna vrednost može blokirati sertifikat.

Dijagnostika DNS problema

Podršci pošalji hostname, tip zapisa, očekivanu vrednost i javno vidljiv rezultat. Ne šalji login za DNS panel, API token ili screenshot sa tajnim vrednostima.

> DNS propagacija i TTL bez obećanja na minut

TTL i cache resolvera određuju koliko dugo stare i nove DNS vrednosti mogu koegzistirati posle izmene.

faq/dns-propagation-and-ttl

Propagacija je ponašanje cachea

Ne postoji fiksno obećanje koliko tačno traje DNS propagacija. Posle promene autoritativnog zapisa različiti resolvery mogu vraćati stare i nove odgovore dok im ne istekne cache prema TTL vrednosti.

Planirana promena DNS-a

  1. Ako provajder dozvoljava, smanji TTL pre planiranog prebacivanja.
  2. Napravi izmenu jednom i izbegavaj nasumično prepisivanje dok cache ističe.
  3. Testiraj sa više resolvera ili mreža kada se rezultati razlikuju.
  4. Zapiši vreme izmene, staru vrednost, novu vrednost i TTL.

Šta poslati podršci

Pošalji hostname, očekivani cilj, vidljiv stari odgovor, vidljiv novi odgovor, TTL i vreme izmene. Ne šalji pristup DNS nalogu ili interne beleške provajdera.

> Planiranje Nextcloud skladišta

U kapacitet uračunaj korisničke fajlove, deljene foldere, verzije, korpu, previews, thumbnails, sync overhead i rast tima.

faq/nextcloud-storage-planning

Prostor troše i nevidljivi slojevi

Pored fajlova korisnika, kapacitet koriste deljenja, obrisani fajlovi, istorija verzija, previews, thumbnails, sinhronizacioni klijenti i uvozi. Blizina limita može lomiti upload i sync.

Pre naručivanja kapaciteta

  1. Izmeri trenutne korisničke fajlove i zajedničke foldere.
  2. Dodaj rezervu za verzije, korpu, previews i thumbnails.
  3. Uračunaj velike uvoze, nove timove i očekivani rast.
  4. Povećaj storage pre nego što korisnici udare u limit.

Kada sync počne da greši

Pošalji veličinu usluge, približno zauzeće, vreme problema i vidljivu grešku klijenta. Ne šalji privatne fajlove, lozinke ili exporte korisničkih podataka bez dogovorenog bezbednog kanala.

> Migracija repozitorijuma u Gitea

Migraciju Git repozitorijuma planiraj zajedno sa LFS, submodules, pravima, protected branches, deploy keys, webhookovima i CI/CD.

faq/gitea-repository-migration

Migracija nije samo git clone

Pored istorije koda treba proveriti vlasnike, timove, protected branches, protected tags, Git LFS, submodules, deploy keys, tokene, webhookove i CI/CD tokove. Tajne vrednosti tokena ne treba deliti.

Kontrola pre cutovera

  1. Popiši repozitorijume, vlasnike, grupe pristupa i automation naloge.
  2. Proveri Git LFS objekte, submodules, protected branches i protected tags.
  3. Posle prenosa testiraj clone, push, Git LFS, submodules i CI.
  4. Stare tokene posle migracije opozovi ili rotiraj bez slanja njihovih vrednosti.

Bezbedni podaci za pomoć

U tiket ne šalji tokene, privatne ključeve, privatni deo deploy keya ili CI secrets. Dovoljni su nazivi repozitorijuma, tip integracije, vidljiva greška i šta je ranije radilo.

> Sender domen za Listmonk

Za kampanje pripremi sender domen ili subdomen, From identitet, SPF, DKIM, DMARC, bounce i odjavu.

faq/listmonk-sender-domain-basics

Dostavljivost počinje domenom

Listmonk kampanje bolje prolaze kada sender domen ima tačne DNS zapise i jasan From identitet. SPF, DKIM i DMARC moraju odgovarati domenu ili subdomenu sa kog šalješ.

Pre prve kampanje

  1. Izaberi sender domen ili subdomen i From naziv.
  2. Dodaj verifikacione DNS zapise, SPF, DKIM selector i DMARC na _dmarc.
  3. Testiraj poruke, bounce ili Return-Path i linkove pre stvarne kampanje.
  4. Proveri odjavu i List-Unsubscribe pre slanja većoj listi.

Mail tajne ne idu u tiket

Za dijagnostiku pošalji domen, tip zapisa, javno vidljivu DNS vrednost i grešku. Ne šalji SMTP lozinke, API tokene, privatni DKIM ključ ili export liste primalaca.

> Runtime podešavanja za Classic Hosting

Classic Hosting može koristiti auto ili manuelni Runtime; CPU, RAM, storage, backup, Offsite Archive, uploadi, cache i logovi utiču na cenu i stabilnost.

faq/classic-hosting-runtime-settings

Auto režim nije jedini ispravan izbor

Auto Runtime pomaže kod prepoznatih projekata, ali manuelni režim je bolji kada želiš da biraš Nginx, Apache, FrankenPHP ili konkretan jezički runtime. PHP selector koristi samo gde ga izabrani runtime podržava.

Podešavanja pre deploya

  1. Izaberi auto ili manuelni Runtime prema frameworku i build procesu.
  2. Odaberi PHP 8.2, 8.3 ili 8.4 samo za podržane PHP scenarije.
  3. Postavi CPU, RAM, disk, backup retenciju i Offsite Archive prema podacima i poseti.
  4. Posle deploya testiraj upload, cache, logove i vidljive greške aplikacije.

Ako aplikacija ne startuje

Pošalji runtime režim, jezik ili PHP verziju, vidljivu grešku, šta se promenilo i vreme deploya. Ne šalji .env fajlove, lozinke, tokene ili cele logove sa osetljivim vrednostima.

> Koje informacije je bezbedno poslati podršci

Najviše pomažu brojevi porudžbina, nazivi usluga, domeni, vremena, javni hostovi, portovi, backup retencija, Offsite Archive, uploadi, cache, logovi i vidljive greške bez tajni.

faq/support-safe-information-to-share

Dobar tiket ima kontekst, ne tajne

Podrška brže reaguje kada dobije broj porudžbine, naziv usluge, domen, javni host ili port, vreme problema, šta se menjalo i tačan vidljiv tekst greške.

Bezbedan sadržaj poruke

  1. Navedi porudžbinu, uslugu, domen, vreme i korak gde nastaje problem.
  2. Za hosting dodaj runtime, PHP ili jezik, CPU, RAM, disk, backup retenciju, Offsite Archive retenciju, uploade, cache i logove bez tajnih vrednosti.
  3. Screenshotove pre slanja maskiraj na mestima sa ličnim ili tajnim podacima.
  4. Ako nisi siguran da li podatak pripada tiketu, pitaj bez slanja same vrednosti.

Šta nikada ne slati

Ne šalji lozinke, privatne ključeve, recovery seedove, API tokene, session cookies, exporte baza, kompletne .env fajlove, pune logove sa tajnama ili poverljive tehničke detalje.