FAQ

Најчесто поставувани прашања

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

> Креирање јавен SSH клуч во терминал

Направи јавен SSH клуч за пристап и споделувај само јавен дел.
faq/generate-public-ssh-key-mk

Користи само јавен клуч

SSH користи пар клучеви. Во поставките на услугата внеси само јавен клуч, најчесто .pub датотеката. Приватниот клуч останува на твојот уред.

Чекори во терминал

  1. Отвори Terminal, Windows Terminal или PowerShell.
  2. Изврши: ssh-keygen -t ed25519 -C "your-email@example.com".
  3. Прифати ја стандардната локација или избери безбедна патека.
  4. Прикажи го јавниот клуч со: cat ~/.ssh/id_ed25519.pub.
  5. Во Windows PowerShell користи: Get-Content $env:USERPROFILE\.ssh\id_ed25519.pub.
  6. Копирај ја целата ssh-ed25519 линија во полето SSH public key.

Провери пред внесување

Не копирај приватен клуч. Ако поставиш passphrase, чувај ја безбедно.

> Креирање SSH клуч графички во Windows

Користи PuTTYgen во Windows и копирај само јавен клуч.
faq/create-ssh-key-windows-gui-mk

Доволен е јавниот дел

PuTTYgen креира јавен и приватен клуч. Во Cli>_ додади само јавен клуч, а приватниот чувај го локално.

Чекори во Windows

  1. Отвори PuTTYgen.
  2. Избери EdDSA / Ed25519 кога е достапно.
  3. RSA 4096 користи само како резерва.
  4. Кликни Generate и движи го глувчето додека се создаде клучот.
  5. Зачувај го приватниот клуч на твојот компјутер.
  6. Копирај го текстот на јавниот клуч во полето SSH public key.

Не споделувај тајни податоци

Не праќај .ppk датотеки, приватни клучеви, passphrase, лозинки или token-и до поддршка или формулари.

> Povrzete sopstven domen

Пред префрлање домен провери registrar, авторитативни nameserver-и, точен hostname, apex или subdomain, тип на запис и конфликти.
faq/povrzete-sopstven-domen

Најважен е точниот hostname

Прво одлучи дали поврзуваш apex домен како example.com или subdomain како app.example.com. Од тоа зависи дали се дозволени CNAME, A/AAAA, ALIAS или ANAME записи и каде се уредуваат.

Пред DNS промена

  1. Потврди дека DNS се уредува кај авторитативните nameserver-и или registrar.
  2. Отстрани конфликтни A/AAAA, CNAME, ALIAS, ANAME или redirect записи за истиот hostname.
  3. Користи тип на запис што одговара на hostname и поддршката на DNS провајдерот.
  4. Почекај DNS пропагација и проверка на сертификат пред продукциско префрлање.

Безбеден rollback

Стариот hosting не го гаси додека новиот hostname не одговара правилно. За помош испрати домен, очекувана цел и јавно видлив DNS резултат, а не пристап до registrar или API токени.

> Prenos na DNS zona

A/AAAA водат кон адреси, CNAME кон alias, MX кон пошта, TXT кон верификации, SPF, DKIM и DMARC, а CAA може да влијае на сертификати.
faq/prenos-na-dns-zona

Секој запис има своја улога

A и AAAA покажуваат кон IP адреси, CNAME прави alias за дозволен subdomain, MX насочува пошта, TXT носи верификации и mail политики, а CAA ограничува сертификациски авторитети.

Копирање DNS вредности

  1. Препиши име, тип и вредност точно како што бара услугата.
  2. Не ставај CNAME на hostname што веќе има конфликтни записи ако DNS правилата го забрануваат тоа.
  3. DKIM постави го под selector на провајдерот, а DMARC најчесто под _dmarc.
  4. CAA менувај го внимателно бидејќи погрешна вредност може да блокира сертификат.

Дијагностика на DNS проблем

До поддршката испрати hostname, тип на запис, очекувана вредност и јавно видлив резултат. Не испраќај login за DNS панел, API токен или screenshot со тајни вредности.

> Регистрација на сметка и прво најавување

Користи една работна сметка за нарачки, наплата и управување со услуги, со е-пошта до која тимот долгорочно има пристап.
faq/account-registration-and-login

Сметка што останува кај тимот

Корисничката сметка ги поврзува нарачките, фактурирањето, домените и активните услуги. Најдобро е да се користи работна е-пошта до која тимот ќе има пристап и по кадровски промени.

Пред првата нарачка

  1. Регистрирај се со работна е-пошта.
  2. Потврди ја е-поштата ако системот побара верификација.
  3. Пополни точни податоци за фактурирање пред платена нарачка.
  4. Вклучи двофакторска заштита кога ќе биде достапна.

Пристап без споделување тајни

Не ја праќај лозинката преку чат, тикет или е-пошта. Ако повеќе луѓе мора да работат со сметката, користете интерен password manager или договорена тимска постапка; поддршката не треба лозинка или приватен токен.

> Како работи prepaid кредитот

Prepaid кредитот го покажува салдото, проценетото траење, дневната цена на активните услуги и ризикот од суспензија или видлив рок за бришење.
faq/prepaid-credit-how-it-works

Кредитот се троши додека услугата работи

Кај подобните услуги кредитот се намалува според активното време, ресурсите и платените опции. Затоа видливото салдо, проценката на преостанати денови и дневната цена се клучни за навремено дополнување.

Како да избегнеш прекин

  1. Дополнувај кредит од корисничката зона со резерва.
  2. Пред потврда на нарачка или промена провери ја новата дневна цена.
  3. Следи предупредувања за ниско салдо, суспензија и видлив рок за бришење.
  4. Кај суспендирана услуга реагирај пред рокот по кој податоците може да се избришат.

Кога салдото не изгледа очекувано

За проверка испрати број на нарачка, име на услуга и период за споредба. Не испраќај податоци од картичка, лозинки, приватни клучеви или целосни изводи со чувствителни информации.

> Месечна проценка, годишна проценка и дневно трошење кредит

Месечните и годишните суми се за споредба; prepaid услугите реално трошат кредит дневно по потврда, плаќање ако треба и примена.
faq/billing-periods-and-credit-burn

Проценката не е календар за фактура

Месечната проценка користи 31 ден, а годишната 372 дена за полесна споредба. Кај prepaid услугите реалната потрошувачка зависи од активното време, CPU, RAM, диск и платени опции.

Пред прифаќање нова цена

  1. Спореди ја дневната потрошувачка пред и по промената.
  2. Сметај дека поголем CPU, RAM, диск или дополнителни опции ја менуваат цената.
  3. Промената важи дури кога е потврдена, платена ако треба и применета.
  4. Зачувај потврди за нарачки и видлива историја на кредит за сметководство.

Проверка на наплата

До поддршката испрати број на нарачка, име на услуга и датуми за проверка. Не испраќај целосни банкарски изводи, картични податоци или screenshot-и со непотребни лични податоци.

> Статус на нарачка по плаќање

Нарачката може кратко да чека потврда од платежниот провајдер; дупликат прави само кога првата е јасно истечена или откажана.
faq/order-status-and-payment-confirmation

Pending не значи веднаш неуспех

По плаќање нарачката може да остане во чекање додека платежниот провајдер не ја испрати потврдата. Нова нарачка пред јасен истек или откажување може да го отежни спарувањето на плаќањето.

Чекори по плаќање

  1. Врати се од страницата за плаќање назад во Cli>_.
  2. Во сметката провери го видливиот статус на нарачката.
  3. Ако статусот е pending, почекај потврда од платежниот провајдер.
  4. Ако статусот не се менува, испрати број на нарачка и референца на плаќање ако ја гледаш.

Што не треба да се испраќа

На поддршката не ѝ треба број на картичка, лозинка или целосна банкарска потврда. Доволни се број на нарачка, време на плаќање, видлив статус и маскиран screenshot од грешка ако постои.

> Податоци што го забрзуваат поставувањето услуга

Подготви име на услуга, домен, DNS план, ресурси, admin е-пошта и јавен SSH клуч; тајните вредности не се внесуваат во формулари.
faq/service-setup-information-needed

Точни влезови спречуваат застој

Формуларите за нарачка бараат име на услуга, домен, DNS цел, storage, CPU, RAM, пристапна е-пошта или јавен SSH клуч. Лозинки, приватни клучеви и токени не припаѓаат во тие полиња.

Подготовка пред checkout

  1. Избери име на услуга што тимот ќе го препознае.
  2. Подготви точен домен или одлучи да користиш привремен hostname.
  3. Подготви јавен SSH клуч ако производот го бара.
  4. Провери ресурси и големина на диск според апликацијата.

Ако не си сигурен што е тајно

Прашај без да ја испратиш самата вредност. Приватни клучеви, лозинки, API токени, бази и целосни конфигурации не се праќаат преку нарачка или тикет.

> Промена на CPU, RAM, диск или ретенција по нарачка

Постоечка услуга менувај од нејзиниот детал, со проверка на нова цена, дневна потрошувачка, плаќање, рестарт, прекин и потреба за export.
faq/change-service-resources-after-order

Се менува постоечка услуга

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

Проверка пред потврда

  1. Погледни тековен CPU, RAM, диск, backup ретенција и Offsite Archive ретенција.
  2. Провери ја новата цена и влијанието врз дневното трошење кредит.
  3. Прочитај предупредување за рестарт, одржување или прекин.
  4. Пред ризична промена направи сопствен export на важни податоци.

Ако промената не помине очекувано

Испрати име на услуга, време на промена, видлив статус и текст на грешка. Не испраќај лозинки, приватни клучеви, токени или конфигурации со тајни вредности.

> Откажување услуга и рок за бришење податоци

Provisioned услуга прво се суспендира, покажува подеслив видлив рок за бришење, а трајно чистење следи по lifecycle рокот.
faq/cancel-service-and-data-retention

Откажување не е секогаш моментално бришење

Кај веќе provisioned услуга, откажувањето прво води до суспензија и приказ на подеслив видлив рок за бришење. Неплатени нарачки што никогаш не стартувале податоци може да имаат друг тек.

Пред откажување

  1. Направи сопствен export на податоците што сакаш да ги задржиш.
  2. Прочитај датум и време на можно бришење прикажани кај услугата.
  3. Не мешај backup ретенција и Offsite Archive ретенција со бришење на самата услуга.
  4. Контактирај поддршка пред рокот ако не си сигурен што ќе се избрише.

По рокот опоравување не е сигурно

Кога видливиот рок ќе помине, не треба да се смета дека податоците се уште достапни. Во тикет наведи број на нарачка и име на услуга, но не испраќај export од база или тајни пристапни податоци.

> Backup и барања за restore

Backup служи за оперативно опоравување, не како замена за сопствен export; restore може да препише понови податоци.
faq/backups-and-restore-requests

Backup не е архива за секоја потреба

Ретенцијата зависи од производот и избраните опции. Backup помага при оперативни грешки, но не заменува деловен export, долгорочна архива или Offsite Archive; restore може да врати постара состојба врз понови измени.

Добро restore барање

  1. Наведи име на услуга и број на нарачка.
  2. Напиши приближно време на кое сакаш враќање.
  3. Објасни дали треба цела услуга или одреден дел ако е поддржано.
  4. Додај видлива грешка или контекст без лозинки, токени и приватни клучеви.

Планирај го влијанието

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

> За што служи Offsite Archive

Offsite Archive чува оддалечени архивски копии одвоено од кратки оперативни backup-и и од lifecycle на услугата.
faq/offsite-archive-purpose

Архива надвор од секојдневната работа

Offsite Archive е за оддалечени копии и подолго чување податоци. Не е live диск за апликација, не е замена за локален export и не е исто што краток backup за оперативен restore.

Кога да се користи

  1. Вклучи го за податоци што сакаш да ги чуваш надвор од редовниот lifecycle на услугата.
  2. Избери број на денови ретенција според правила или recovery цел.
  3. Сметај дека цената расте со количина податоци и време на чување.
  4. За големи податоци планирај и сопствен export процес.

Како се чита цената

Основата се MB-days: колку мегабајти се зачувани и колку денови се чуваат. Цената се прикажува како EUR/GB/месец, а пресметката се заокружува на цели центи.

> Избор на CPU, RAM и диск за VPS

Големината на VPS избери ја според апликација, база, cache, логови и раст; OOM, out of memory и process killed укажуваат на недостиг RAM.
faq/vps-cpu-ram-and-disk-sizing

Почни од реално оптоварување

Статична страница, база, Java апликација, пребарување или build процес имаат различни потреби. Во планот вклучи меморија на апликација, cache, база, логови, upload фајлови и резерва за раст.

Кога да зголемиш ресурси

  1. Зголеми RAM при OOM, out of memory, process killed пораки или постојано swap-ување.
  2. Зголеми CPU при долго compute оптоварување, компресија, build-ови или зафатени workers.
  3. Зголеми диск пред filesystem, логови или база да дојдат до лимит.
  4. По промената следи дали исчезнал првичниот проблем.

Контекст за sizing прашање

Корисно е да испратиш име на услуга, тип на апликација, видлива грешка, приближно време на проблем и тековни CPU, RAM и диск вредности. Не испраќај лозинки, приватни клучеви или целосни интерни конфигурации.

> Кога VPS треба јавна IP адреса

Посветена јавна IP помага кај allowlist, inbound пристап, стабилен outbound извор и услуги врзани за адреса.
faq/vps-public-ip-options

Прво утврди насока на сообраќај

Јавна IP не е потребна за секоја апликација. Најчесто ја бараат надворешни партнери, провајдери или firewall правила што очекуваат стабилна адреса за inbound пристап, outbound извор или двете насоки.

Прашања пред нарачка на IP

  1. Прашај го партнерот дали allowlist важи за inbound, outbound или двете насоки.
  2. Користи DNS имиња наместо бројчени адреси каде што е можно.
  3. Отвори само портови што апликацијата навистина ги користи.
  4. Сподели го allowlist барањето со поддршка пред промена на продукциски пристап.

Јавна адреса не е отворен сервер

Посветена IP не значи дека сите портови треба да се отворат. Пристапот држи го на минимални потребни сервиси и не испраќај приватни клучеви, лозинки или screenshot-и од firewall правила со чувствителни вредности.

> Споделен SSH пристап за VPS

Без посветена јавна IP, VPS користи споделен SSH пристап преку висок порт; јавна IP може да овозможи директен SSH само ако е така поставено.
faq/shared-ssh-access-for-vps

Зошто постои висок порт

Повеќе VPS услуги може да делат ист јавен SSH host, па секоја добива свој висок порт. Тој порт ја насочува врската до твојата конкретна VPS услуга; без него споделениот host не би знаел кон која машина да ја проследи врската.

Како да се поврзеш

  1. За споделен SSH копирај SSH корисничко име, јавен host и висок порт од страницата на услугата.
  2. Користи команда ssh -p <port> <username>@<public-host>.
  3. Ако услугата има посветена јавна IP, директен SSH на таа IP адреса работи само ако SSH сервисот и firewall правилото се поставени за тоа.
  4. Приватниот клуч користи го само локално преку SSH клиент или agent.

Две можни SSH патеки

Посветената јавна IP не го укинува автоматски споделениот пристап и не значи дека портата 22 е отворена. Таа може да додаде директен пристап за allowlist, monitoring или интеграции. Во поддршка испраќај само јавен host, port, корисничко име и видлива грешка, никогаш приватен клуч.

> Проверка пред поврзување сопствен домен

Пред префрлање домен провери registrar, авторитативни nameserver-и, точен hostname, apex или subdomain, тип на запис и конфликти.
faq/custom-domain-readiness-checklist

Најважен е точниот hostname

Прво одлучи дали поврзуваш apex домен како example.com или subdomain како app.example.com. Од тоа зависи дали се дозволени CNAME, A/AAAA, ALIAS или ANAME записи и каде се уредуваат.

Пред DNS промена

  1. Потврди дека DNS се уредува кај авторитативните nameserver-и или registrar.
  2. Отстрани конфликтни A/AAAA, CNAME, ALIAS, ANAME или redirect записи за истиот hostname.
  3. Користи тип на запис што одговара на hostname и поддршката на DNS провајдерот.
  4. Почекај DNS пропагација и проверка на сертификат пред продукциско префрлање.

Безбеден rollback

Стариот hosting не го гаси додека новиот hostname не одговара правилно. За помош испрати домен, очекувана цел и јавно видлив DNS резултат, а не пристап до registrar или API токени.

> Типови DNS записи за услуги

A/AAAA водат кон адреси, CNAME кон alias, MX кон пошта, TXT кон верификации, SPF, DKIM и DMARC, а CAA може да влијае на сертификати.
faq/dns-record-types-for-services

Секој запис има своја улога

A и AAAA покажуваат кон IP адреси, CNAME прави alias за дозволен subdomain, MX насочува пошта, TXT носи верификации и mail политики, а CAA ограничува сертификациски авторитети.

Копирање DNS вредности

  1. Препиши име, тип и вредност точно како што бара услугата.
  2. Не ставај CNAME на hostname што веќе има конфликтни записи ако DNS правилата го забрануваат тоа.
  3. DKIM постави го под selector на провајдерот, а DMARC најчесто под _dmarc.
  4. CAA менувај го внимателно бидејќи погрешна вредност може да блокира сертификат.

Дијагностика на DNS проблем

До поддршката испрати hostname, тип на запис, очекувана вредност и јавно видлив резултат. Не испраќај login за DNS панел, API токен или screenshot со тајни вредности.

> DNS пропагација и TTL без ветување на минута

TTL и cache на resolver-и одредуваат колку долго старите и новите DNS вредности може да коегзистираат по промена.
faq/dns-propagation-and-ttl

Пропагацијата е однесување на cache

Нема фиксно ветување колку точно трае DNS пропагација. По промена на авторитативниот запис, различни resolver-и може да враќаат стари и нови одговори додека не им истече cache според TTL.

Планирана DNS промена

  1. Ако провајдерот дозволува, намали TTL пред планираното префрлање.
  2. Направи ја промената еднаш и избегнувај случајно препишување додека cache истекува.
  3. Тестирај од повеќе resolver-и или мрежи кога резултатите се разликуваат.
  4. Запиши време на промена, стара вредност, нова вредност и TTL.

Што да се испрати до поддршка

Испрати hostname, очекувана цел, видлив стар одговор, видлив нов одговор, TTL и време на промена. Не испраќај пристап до DNS сметка или интерни белешки на провајдер.

> Планирање Nextcloud storage

Во капацитет вклучи кориснички фајлови, споделени папки, верзии, корпа, previews, thumbnails, sync overhead и раст на тимот.
faq/nextcloud-storage-planning

Просторот го трошат и невидливи слоеви

Покрај корисничките фајлови, капацитет користат споделувања, избришани фајлови, историја на верзии, previews, thumbnails, sync клиенти и увози. Блиску до лимит може да прекинат upload и sync.

Пред нарачка на капацитет

  1. Измери тековни кориснички фајлови и заеднички папки.
  2. Додај резерва за верзии, корпа, previews и thumbnails.
  3. Вклучи големи увози, нови тимови и очекуван раст.
  4. Зголеми storage пред корисниците да дојдат до лимит.

Кога sync почнува да греши

Испрати големина на услуга, приближна зафатеност, време на проблем и видлива грешка од клиентот. Не испраќај приватни фајлови, лозинки или export-и од кориснички податоци без договорен безбеден канал.

> Миграција на репозиториуми во Gitea

Миграција на Git репозиториуми планирај ја со LFS, submodules, права, protected branches, deploy keys, webhook-и и CI/CD.
faq/gitea-repository-migration

Миграција не е само git clone

Покрај историјата на кодот треба да се проверат сопственици, тимови, protected branches, protected tags, Git LFS, submodules, deploy keys, токени, webhook-и и CI/CD текови. Тајните вредности на токените не се споделуваат.

Проверка пред cutover

  1. Попиши репозиториуми, сопственици, групи за пристап и automation сметки.
  2. Провери Git LFS објекти, submodules, protected branches и protected tags.
  3. По пренос тестирај clone, push, Git LFS, submodules и CI.
  4. Старите токени по миграција отповикај ги или ротирај ги без испраќање вредности.

Безбедни податоци за помош

Во тикет не испраќај токени, приватни клучеви, приватен дел од deploy key или CI secrets. Доволни се имиња на репозиториуми, тип на интеграција, видлива грешка и што работело порано.

> Sender домен за Listmonk

За кампањи подготви sender домен или subdomain, From идентитет, SPF, DKIM, DMARC, bounce и одјава.
faq/listmonk-sender-domain-basics

Испорачливоста почнува од доменот

Listmonk кампањите подобро поминуваат кога sender доменот има точни DNS записи и јасен From идентитет. SPF, DKIM и DMARC мора да одговараат на доменот или subdomain-от од кој испраќаш.

Пред првата кампања

  1. Избери sender домен или subdomain и From име.
  2. Додај верификациски DNS записи, SPF, DKIM selector и DMARC на _dmarc.
  3. Тестирај пораки, bounce или Return-Path и линкови пред вистинска кампања.
  4. Провери одјава и List-Unsubscribe пред праќање на поголема листа.

Mail тајните не одат во тикет

За дијагностика испрати домен, тип на запис, јавно видлива DNS вредност и грешка. Не испраќај SMTP лозинки, API токени, приватен DKIM клуч или export од листа примачи.

> Runtime поставки за Classic Hosting

Classic Hosting може да користи auto или manual Runtime; CPU, RAM, storage, backup, Offsite Archive, upload-и, cache и логови влијаат на цена и стабилност.
faq/classic-hosting-runtime-settings

Auto режим не е единствен правилен избор

Auto Runtime помага кај препознаени проекти, но manual режим е подобар кога сакаш да избереш Nginx, Apache, FrankenPHP или конкретен јазичен runtime. PHP selector користи го само каде што избраниот runtime го поддржува.

Поставки пред deploy

  1. Избери auto или manual Runtime според framework и build процес.
  2. Одбери PHP 8.2, 8.3 или 8.4 само за поддржани PHP сценарија.
  3. Постави CPU, RAM, диск, backup ретенција и Offsite Archive според податоци и посети.
  4. По deploy тестирај upload, cache, логови и видливи грешки од апликацијата.

Ако апликацијата не стартува

Испрати runtime режим, јазик или PHP верзија, видлива грешка, што е сменето и време на deploy. Не испраќај .env фајлови, лозинки, токени или цели логови со чувствителни вредности.

> Кои информации е безбедно да се испратат до поддршка

Најмногу помагаат броеви на нарачки, имиња на услуги, домени, времиња, public host, port, backup ретенција, Offsite Archive, upload-и, cache, логови и видливи грешки без тајни.
faq/support-safe-information-to-share

Добар тикет има контекст, не тајни

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

Безбедна содржина на порака

  1. Наведи нарачка, услуга, домен, време и чекор каде настанува проблемот.
  2. За hosting додај runtime, PHP или јазик, CPU, RAM, диск, backup ретенција, Offsite Archive ретенција, upload-и, cache и логови без тајни вредности.
  3. Screenshot-и пред праќање маскирај ги на места со лични или тајни податоци.
  4. Ако не си сигурен дали податок припаѓа во тикет, прашај без да ја испратиш вредноста.

Што никогаш не се праќа

Не испраќај лозинки, приватни клучеви, recovery seed, API токени, session cookies, export-и од бази, целосни .env фајлови, цели логови со тајни или доверливи технички детали.