ЧЕСТО ЗАПИТАЊА

Често поставувани прашања

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

> Како работи кредитниот систем Cli>_?

Едно заедничко prepaid салдо ги финансира сите подобни услуги и се троши само додека се активни.
faq/prepaid-credit-how-it-works

Твојата Cli>_ сметка има едно заедничко prepaid кредитно салдо. Подобните нови корисници може да побараат Starter Credit само откако ќе ја завршат задолжителната проверка на сметката и заштитата од злоупотреба. Активните подобни услуги го трошат салдото со текот на времето. Месечната проценка користи 31 ден, а нова услуга може да започне само ако салдото покрива најмалку 7 дена. Црвено предупредување се прикажува кога проценетото време на работа ќе падне под 7 дена; во спротивно се прикажува портокалово кога ќе падне под 14 дена.

Откако ќе се потроши салдото, услугата се суспендира по 7 дена, престанува да троши кредит и започнува 7-дневниот рок за чување и бришење. Пред прикажаниот рок може повторно да се стартува со доволно кредит. Откажувањето на provisioned услуга исто така ја суспендира и го започнува истиот рок. Услуга на чекање што не е provisioned може веднаш да се деактивира. По рокот започнуваат деактивирањето и отстранувањето на provisioned услугата. Force delete веднаш ја деактивира услугата, го прескокнува чувањето и го започнува отстранувањето од активниот runtime; завршувањето следи по обработката на deployment и GitOps. Backup и Offsite Archive имаат посебни правила за чување.

Пример OpenCode за 9,90 EUR: 9,90 / 31 ≈ 0,319 EUR дневно. По 10 цели дена се трошат околу 3,19 EUR. Ако почетното салдо било точно 9,90 EUR и немало други услуги, остануваат околу 6,71 EUR. Потрошувачката престанува по оневозможување.

Примерот е само илустративен. Секогаш важат тековните цени прикажани во Cli>_.

> Како да се генерира јавен SSH клуч преку командниот ред

Создајте јавен SSH клуч за безбеден пристап до VPS. Споделете го само јавниот клуч со Cli>_; приватниот клуч чувајте го на вашето уредување.
faq/generate-public-ssh-key-mk

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

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

Користете ги следниве чекори

  1. Отворете терминал на вашиот компјутер.
  2. Извршете ја командата: ssh-keygen -t ed25519 -C "вашата-електронска-адреса@example.com".
  3. Потврдете ја локацијата за чување на датотеката или изберете сопствена патека. Не споделувајте го приватниот клуч со никој.
  4. Покажете го јавниот клуч со командата: cat ~/.ssh/id_ed25519.pub.
  5. Копирајте ја целата линија што започнува со ssh-ed25519 и залепете ја во полето "SSH public key" при нарачка или поставување на услугата.
  6. Копирајте ја целата линија со ssh-ed25519 и залепете ја во полето "SSH Public Key".

PowerShell за Windows 10/11

  1. Отворете го PowerShell или Windows Terminal.
  2. Извршете ја командата: ssh-keygen -t ed25519 -C "вашата-електронска-адреса@example.com".
  3. Притиснете Enter за да го запаметите кључот во C:\Users\вашиот-корисник\.ssh\id_ed25519 или вклучете сопствен пат.
  4. Ако Windows бара фраза, користете една која можете безбедно да ја чувате, или притиснете Enter за едноставна подеска.
  5. Јавниот клуч може да се покаже со командата: Get-Content $env:USERPROFILE\.ssh\id_ed25519.pub.
  6. Копирајте само целата линија што започнува со ssh-ed25519. Не копирајте и не прикачувајте го фајлот со приватниот клуч.
> Како да го генерирате SSH кључот графички во Windows

Графичка процедура во Windows за создавање пар SSH клучови без користење на командна линија.
faq/create-ssh-key-windows-gui-mk

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

Можете да креирате пар SSH клучови графички преку Windows SSH клиент, како што е PuTTYgen. Cli>_ потребен е само јавниот клуч. Чувајте го приватниот клуч на вашиот компјутер и не го прикачувајте преку веб формулација.

Кораци

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

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

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

> Донесете своја домејн

Научете како да ја насочите вашата сопствена домен или поддомен кон CLIopen услуга пред да ја активирате опцијата „Донесете својата сопствена домен“.
faq/povrzete-sopstven-domen

Што прави оваа поставка?

Функцијата "Користи свој домен" овозможува вашата услуга да одговара на вашето сопствено име на хост, на пример app.example.com, наместо да користи само генерирано име на хост *.co.cliopen.cloud. DNS-от мора да покажува кон CLIopen пред што името на хост може безбедно да се користи во услугата.

Пред да започнете

  1. Изберете го точното име на хост кое сакате да го користите, на пример, app.example.com. Најупростеното решение е да ја користите поддомената.
  2. Отворете ја DNS администрацијата кај вашиот регистар на домени или прувач на DNS услуги.
  3. Отстранете ги сите конфликтни A, AAAA, CNAME, ALIAS или пренасочувачки записи за истото име на хост.
  4. Оставете го генерираното име на хост од CLIopen активно сè додека вашиот прилагоден хост не биде проверен и функционален.

Препорачани DNS поставки за поддомен

Креирајте DNS записи за точното име на хост што ќе го внесете во CLIopen. За app.example.com, DNS етикетата е app. Насочете го кон адресите за влез на CLIopen кои ги добивате од поддршката на CLIopen или во документацијата на услугата. Ако вашиот провајдер бара тип на запис, користете A запис за IPv4 и AAAA запис за IPv6 кога ќе бидат обезбедени овие адреси.

Пример:

app.example.com.  A     <CLIopen IPv4 адреса>
app.example.com.  AAAA  <CLIopen IPv6 адреса, ако е достапна>```

Кога CLIopen обезбедува CNAME цел

Кај некои сервиси, CLIopen може да генерира хост име, на пример service.customer.co.cliopen.cloud. Ако инструкциите за вашиот сервис изрично бараат користење на CNAME, креирај запис како што е app.example.com CNAME service.customer.co.cliopen.cloud. Користи CNAME само за поддомени, а не за главни/корен домени, освен ако вашиот DNS прувач го поддржува ALIAS или ANAME flattening.

Користење на главната област

За празна област како example.com, повеќето DNS провајдери не дозволуваат стандарден CNAME запис. Користите A/AAAA записи кои покажуваат кон CLIopen адресите за влез, или користете ја функцијата ALIAS/ANAME на вашиот провајдер ако CLIopen ви обезбедил целна хост име.

Делегирање на цела подзона

Ако сакате CLIopen да управува со записи под под-зона како apps.example.com, креирајте NS записи за таа под-зона кои покажуваат кон CLIopen серверите што ги добивте. Не променувајте ги серверите за целата област, освен ако намерно сакате CLIopen (или друга DNS услуга) да управува со сите записи.

Контролна листа

  1. Почекајте за ширење на DNS. Малите промени често се видли во неколку минути, но некои пружатели ги кешираат подолго.
  2. Проверете дали хостнемето покажува кон CLIopen целта, а не кон претходниот пружалац.
  3. Во полето "Bring your own domain", внесете го точниот хостнејм, без `https://` и без патека.
  4. По ажурирањето на услугата, тестирајте го `https://app.example.com` во вашиот прелиставач.
  5. Оставете ги старите DNS записи само ако не се судирнуваат со новиот хостнејм.
> Како да пренесете DNS зона во CLIopen

Делегирајте ја доменот на ns1.cliopen.com и ns2.cliopen.com, за да CLIopen може да ги објавува записи за целата зона.
faq/prenos-na-dns-zona

Што значи пренос на зона овде?

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

Пред промена на nameserвери

  1. Копирајте ги постоечките DNS записи кои сè уште ви се потребни, како што се веб-страницата, поштата, верификацијата, SPF, DKIM, DMARC и сервисните записи.
  2. Додадете ја зоната во CLIopen DNS. Ако делегацијата сè уште не е подготвена, CLIopen ќе ја зачува, но нема да ја активира за клиентите додека валидацијата не помине.
  3. Кога е можно, креирајте ги потребните записи во CLIopen DNS пред преминот на сервери.
  4. Внимателно поставете го CAA записот, бидејќи погрешни вредности може да го блокираат издавањето на сертификати.

Делегирајте ја зоната

  1. Отворете ги поставките на доменот кај вашиот регистар, на пример example.com.
  2. Пронајдете ги серверите за именување (nameservers), DNS делегација или поставки за авторитативен DNS.
  3. Заменете ги сегашните сервери за именување со ns1.cliopen.com и ns2.cliopen.com.
  4. Зачувајте ја промената и почекајте додека се шири во регистрите и резолверите.

Валидација

Вратете се во CLIopen DNS и кликнете на Проверете ја делегацијата повторно. Кога јавните NS записи покажуваат ns1.cliopen.com и ns2.cliopen.com, зоната ќе биде ставена во ред за синхронизација и записите ќе станат активни од CLIopen.

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

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

Едно конто за нарачки и управување

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

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

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

Пристап за екипа

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

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

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

Споредбата не е календар за фактурирање

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

Што треба да проверите кога ја менувате цената

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

Решавајте конкретни периоди во случај на спорови

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

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

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

"Pending" не значи секогаш неуспех

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

Што да направите по плаќањето

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

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

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

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

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

Точни податоци штедат време

Користете ги формуларите за нарачка за јавни или непотврдени вредности: име на услуга, домен, DNS план, големина на складиште, процесор, RAM, административен е-пошта или јавен SSH клуч. Лозинките, приватните клучеви и токените не треба да се внесуваат во формулари.

Подгответе се пред да ја завршите нарачката

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

Важни напомени

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

> Промена на процесор, RAM, диск или период на чување по нарачка

Изменете ја постоечката услуга преку нејзините детали, а не со нова дуплирана нарачка; промената на ресурсите може да ја промени цената, цената на услугата, дневната потрошувачка на кредити, рестарт и ризик од прекин.
faq/change-service-resources-after-order

Ја менувате постоечката услуга, а не создавате нова

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

Пред потврдување на промената

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

Кога промената не се извршува според очекувања

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

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

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

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

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

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

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

Враќањето можеби нема да биде возможно по истекот на рокот.

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

> Архивирање и барања за враќање

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

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

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

Како да поднесете барање за враќање

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

Планирајте ги последиците пред обновата

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

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

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

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

Offsite Archive е дизаниран за далечни архивски копии и подолго складирање на податоци. Не е диск во функција за апликација, не е замена за локален експорт ниту исто како кратки оперативни резервни копии.

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

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

Како да се разбере цената

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

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

Големината на VPS изберете ја според апликацијата, базата податоци, кешот, логовите и очекуваниот раст. OOM (недостаток на меморија) или користење на swap простор укажуваат дека е потребна повеќе RAM.
faq/vps-cpu-ram-and-disk-sizing

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

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

Знаци дека планот е мал

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

Што треба да се испрати кога има прашање за спецификациите

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

> Кога има смисол да се користи јавна IP адреса за VPS

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

Прво утврдете ја насоката на комуникација

Јавна IP адреса не е автоматски потребна за секоја услуга. Често се користи за да ги задоволи барањата на надворешни партнери, провајдери или firewall-и за allowlist, стабилен извор за излез или пристап до одредена порта.

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

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

Што треба да оставите затворено

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

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

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

Зошто се користи висок порт за споделен SSH?

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

Како да се поврзете според типот на пристап

  1. При користење на споделен SSH, копирајте го корисничкото име, хостот и портот од услугата за SSH.
  2. Користете ја командата ssh -p <порт> <корисничко_име>@<публичен_хост>.
  3. Ако услугата има купена јавна IP адреса, може да има и друг SSH конектор директно на таа IP адреса или нејзиното DNS име, во зависност од конфигурацијата на услугата.
  4. Приватниот клуч користете го само локално преку вашиот SSH клиент или агент; кон поддршката испратете само јавен хост, порт, корисничко име и видлива грешка.

Кога имате купена јавна IP адреса

Јавната IP не ги менува споделените SSH конекции; таа додаде дополнителен начин на пристап кој е погоден за allowlist, надзор или директна поврзаност. Во пракса, може да видите два вида SSH пристапи: споделен хост со висок порт и директен хост или IP за услуга со јавна IP.

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

Пред да го префрлите доменот, проверете ги DNS серверите, точниот хостнејм, типот на запис (дали е главна област или поддомен) и дали постојат конфликтни стари записи.
faq/custom-domain-readiness-checklist

Важно е точниот хостнејм

Прво, утврдете дали поврзувате главниот домен (apex domain) како example.com или поддомен (subdomain) како app.example.com. Секоја варијанта може да бара различен тип на DNS запис, различни ограничувања од страна на вашиот DNS пружател и проверка кај регистарторот.

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

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

Безопасно враќање

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

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

A/AAAA записи ги насочуваат кон адреси, CNAME се користи за алиаси, MX за пошта, а TXT за верификации, SPF, DKIM или DMARC.
faq/dns-record-types-for-services

Не комбинирајте записи слепо

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

При копирање записи

  1. Препишете ја ознаката, типот и вредноста точно според инструкциите на услугата.
  2. Користете A/AAAA за адреси, CNAME за дозволени алиаси на поддомени, MX за пошта и TXT за SPF, DKIM, DMARC или верификација.
  3. Поставете го DKIM под selector-от на пружателот и DMARC најчесто под _dmarc.
  4. Поставете ги CAA параметрите внимателно, бидејќи погрешна вредност може да го блокира издавањето на сертификатот.

Кога DNS не функционира

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

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

TTL (време на живеење) одредува колку долго серверите можат да чуваат стар одговор; за време на процесот на промена, старите и новите резултати може да постојат заедно.
faq/dns-propagation-and-ttl

Пропагацијата е кеширање, не магично чекање

Кога станува збор за DNS, нема фиксно ветување за времето на пропагација. По промената на авторитетниот DNS, различни резолвери можат да враќаат стари и нови одговори сè додека не истече кешот според вредноста TTL. Затоа, резултатите може да варираат помеѓу мрежи, земји или DNS резолвери.

Кога планирате промена

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

Што треба да се испрати при дијагностика

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

> Планирање складиште за Workspace Suite

При планирањето на капацитетот, вклучете ги корисничките датотеки, споделените папки, верзиите, корпата, прегледите, синхронизацијата и очекуваниот раст.
faq/nextcloud-storage-planning

Workspace Suite расте и надвор од видливите датотеки

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

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

  1. Измерете ги моменталните кориснички датотеки и споделените папки.
  2. Додадете простор за избришани датотеки, историја на верзии, претпрегледи и синхронизација.
  3. Размислете за големите импорти, новите тимови и очекуваниот раст.
  4. Зголемете го капацитетот пред корисниците да почнуваат да наиѓаат на ограничувања.

Кога има проблеми со синхронизацијата

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

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

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

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

Освен историјата на репозиториумот, треба да се пренесат или повторно да се конфигурираат сопствениците, тимовите, заштитени гранки, заштитени ознаки, Git LFS, подмодули, клучови за деплојмент, вебхукови и CI/CD конекции.

Проверка пред префрлување

  1. Наведете репозиториуми, сопственици, групи за пристап и кориснички сметки за автоматизација.
  2. Проверете Git LFS објекти, подмодули, заштитени гранки и заштитени ознаки.
  3. По преносот, тестирајте клонирање, испраќање, Git LFS, подмодули и процеси за непречено интегрирано програмирање (CI).
  4. Старите токени по миграцијата, откажете ги или променете ги без споделување на нивните вредности.

Чувствителни податоци при миграција

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

> Домен за испраќање за Listmonk

За вашите кампањи, подгответе го доменот или поддоменот за испраќање, вклучувајќи ја From идентификацијата, SPF, DKIM, DMARC, обработка на вратени пораки и опциите за откажување.
faq/listmonk-sender-domain-basics

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

Listmonk најдобро функционира кога доменската област на пратителот има точни DNS записи, јасен идентитет за праќачот, SPF, DKIM, DMARC усогласеност, обработка на вратени пораки и детали за откажување од претплата. Објавете го SPF на местото каде што е лоциран вашиот провајдер за електронска пошта, DKIM со селекторот на провајдерот и DMARC на _dmarc. Испратете тестови пораки пред вистинската кампања и не споделувајте ги деталите за вашата електронска пошта.

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

  1. Изберете домен или поддомен за испраќање е-пошта и поставете ја идентификацијата "Од".
  2. Додајте DNS записи за верификација, вклучувајќи ги SPF, DKIM selector и DMARC.
  3. Тестирајте ги пораките пред да започнете со вистинска кампања и проверете дали се сметаат за спам, како реагира системот при враќање на пораката (bounce) и проверете го полето Return-Path и линковите.
  4. Проверете ги опциите за откажување и List-Unsubscribe пред да ја испратите кампањата.

Поштенските тајни не припаѓаат во тикетот

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

> Поставки за runtime за Classic Hosting

Classic Hosting може да работи во автоматски или рачен режим; процесорот (CPU), RAM меморијата, складиштето, резервните копии, чувањето на Offsite Archive, качувањата, кешот и логовите влијаат на цената и стабилноста.
faq/classic-hosting-runtime-settings

Автоматски режим не е единственото решение

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

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

  1. Изберете автоматски режим за откриени компилации или рачен режим за контрола на Nginx, Apache или FrankenPHP runtime.
  2. Изберете PHP 8.2/8.3/8.4 само каде што избраниот runtime го поддржува тој избор.
  3. Поставете CPU, RAM, меморија, складиштење, задржување на резервни копии и задржување на Offsite Archive според сообраќајот и податоците.
  4. После пуштањето во употреба, тестирајте ги качувањата, кешот, логовите и видливите грешки на апликацијата.

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

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

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

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

Една добра барачка содржи релевантни информации, а не чувствителни податоци.

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

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

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

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

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