ЧЗВ

Често задавани въпроси

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

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

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

Акаунтът ти в Cli>_ има един общ предплатен кредитен баланс. Допустимите нови клиенти могат да заявят Starter Credit само след като завършат задължителната проверка на акаунта и срещу злоупотреби. Активните допустими услуги използват баланса с времето. Месечната оценка е за 31 дни, а нова услуга може да стартира само ако балансът покрива поне 7 дни. Червено предупреждение се показва, когато очакваното време за работа падне под 7 дни; в противен случай се показва оранжево, когато падне под 14 дни.

След изчерпване на баланса услугата се спира след 7 дни, престава да използва кредит и започва 7-дневният срок за съхранение и изтриване. Преди показания срок тя може да се рестартира с достатъчно кредит. Отказът от provisioned услуга също я спира и започва същия срок. Чакаща, непровизирана услуга може да се деактивира веднага. След срока започват деактивирането и премахването на provisioned услугата. Force delete деактивира услугата веднага, пропуска съхранението и започва премахването от активния runtime; завършването следва обработката на deployment и GitOps. Архивите и 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-bg

Публичният ключ се споделя, частният остава при вас

Въведете само публичния SSH ключ в поръчката или настройките на услугата. Частният ключ остава на вашия компютър и не се изпраща до поддръжката, нито се въвежда във уеб форма.

Инструкции

  1. Отворете терминал на вашия компютър.
  2. Изпълнете командата: ssh-keygen -t ed25519 -C "your-email@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 "your-email@example.com".
  3. Натиснете Enter, за да запазите ключа в C:\Users\your-user\.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-bg

Използвайте инструмент за Windows и поставете само публичния ключ

Можете да създадете SSH ключова двойка визуално с клиент за SSH на Windows, като PuTTYgen. Cli>_ се нуждае само от публичния ключ. Съхранете частния ключ на вашия компютър и не го качвайте през уеб форма.

Инструкции

  1. Инсталирайте PuTTY или отворете PuTTYgen, ако вече е инсталиран.
  2. Изберете EdDSA/Ed25519, ако е налично, или RSA 4096, ако инструментът Ed25519 не предлага тази опция.
  3. Кликнете върху Generate и движете мишката над празното пространство, докато ключът бъде генериран.
  4. Добавете парола, ако желаете допълнителна локална защита за частния ключ.
  5. Съхранете частния ключ на вашето устройство и го дръжте конфиденциален.
  6. Копирайте текста на публичния ключ и го поставете в полето SSH public key.

Не споделяйте поверителни данни

Не изпращайте .ppk файлове, лични ключове, пароли или токени към отдела за поддръжка или във формуляри.

> Принесете своя собствен домейн

Ако искате да насочите вашия собствен домейн или поддомейн към услуга на CLIopen, направете го преди да активирате функцията "Принесете своя собствен домейн".
faq/svarzhete-sobstven-domen

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

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

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

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

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

Създайте DNS записи за точното име на хост, което ще въведете в CLIopen. За app.example.com етикетът на DNS е app. Насочете го към адресите на CLIopen ingress, които получавате от поддръжката на CLIopen или в документацията на услугата. Ако вашият доставчик пита за тип запис, използвайте A запис за IPv4 и AAAA запис за IPv6, когато тези адреси са предоставени.

Пример:

app.example.com.  A     <CLIopen IPv4 адрес>
app.example.com.  AAAA  <CLIopen IPv6 адрес, ако е наличен>

Когато CLIopen предоставя CNAME целеви адрес

Някои услуги ви предоставят генерирано име на хост, например 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/delegirane-na-dns-zona

Какво означава пренос на зона тук

При DNS пренос за клиенти, това означава промяна на авторитетните имена на сървърите при вашия регистър на домейна. След делегиране към CLIopen, DNS записите, добавени в CLIopen, се публикуват от нашите авторитетни сървъри.

Преди промяна на сървърите за имена

  1. Копирайте съществуващите DNS записи, които все още са ви необходими, например за уебсайт, поща, проверки, SPF, DKIM, DMARC и сервизни записи.
  2. Добавете зоната в CLIopen DNS. Ако делегацията все още не е готова, CLIopen я запазва, но не я активира за клиентите, докато валидацията не бъде успешна.
  3. Ако е възможно, създайте необходимите записи в CLIopen DNS преди превключването на сървърите.
  4. Внимавайте да конфигурирате правилно записа CAA, тъй като неправилни стойности могат да попречат на издаването на сертификати.

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

  1. Отворете настройките на домейна при вашия регистрант, например example.com.
  2. Намерете настройките за Nameservers, DNS делегация или Авторитетни DNS сървъри.
  3. Заменете текущите nameservers със стойностите 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. При по-висока мощност на процесора, RAM паметта или диска, както и при платени опции, очаквайте по-висока дневна консумация.
  3. Промяната влиза в сила след потвърждение, евентуално плащане и прилагане.
  4. За счетоводството запазете потвържденията за поръчки и историята на кредита.

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

Поддръжката ще ви помогне, ако предоставите номера на поръчката, името на услугата и датите, за които искате да проверите потреблението. Не изпращайте банкови данни, пълни платежни извлечения или снимки с нежелана лична информация.

> Статус на поръчката след плащане

Поръчката може да изчаква потвърждение от доставчика на платежни услуги преди да бъде обработена; създавайте дубликати само когато първата поръчка е ясно анулирана или изтекла.
faq/order-status-and-payment-confirmation

Състояние "в очакване" не означава непременно неуспех

След връщане от страницата за плащане, поръчката може все още да чака потвърждение от платежната система. Докато състоянието не е ясно обозначено като неуспешно или изтекло, създаването на нова, дублирана поръчка може ненужно да усложни процеса.

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

  1. След като плащането бъде завършено, върнете се обратно към Cli>_.
  2. Проверете статуса на поръчката и всякакви съобщения, свързани с плащането, във вашия акаунт.
  3. Ако поръчката все още се обработва, дайте време на доставчика да я потвърди.
  4. Ако възникне проблем, изпратете на отдела за поддръжка номера на поръчката и референтния номер на плащането, ако е видим.

Какво не трябва да изпращате

Отделът за поддръжка не се нуждае от данни за дебитна/кредитна карта, пароли или пълни банкови извлечения. Достатъчни са номерата на поръчките, времето на плащане, видимият статус и скрийншот с маскирани данни, ако има грешка.

> Данни, които ще ускорят настройката на услугата

Моля, подгответе името на услугата, домейна, размера на хранилището, имейла за достъп и публичния SSH ключ; не включвайте секретни данни във формулярите.
faq/service-setup-information-needed

Точните данни спестяват време

Използвайте формулярите за публични или неконфиденциални стойности: име на услуга, домейн, DNS план, размер на хранилището, CPU, RAM, административен имейл или публичен SSH ключ. Паролите, частните ключове и токените трябва да се въвеждат отделно.

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

  1. Изберете разпознаваемо име на услугата за вашия екип.
  2. Решете дали да използвате собствен домейн или временен системен хостнейм.
  3. Подгответе публичен SSH ключ, ако услугата го изисква.
  4. Проверете размера на диска и ресурсите според приложението, което ще използвате.

Важно: Не изпращайте поверителни данни

Ако не сте сигурни дали дадена информация е поверителна, попитайте преди да я изпратите. Не изпращайте частни ключове, пароли, токени, копия на бази данни или цели конфигурационни файлове в чата или в поръчката.

> Промяна на процесор, RAM, диск или период на задържане след поръчка

Редактирайте съществуващата услуга чрез нейните подробности, а не като създавате нова, дублирана поръчка. При промяна на ресурсите може да се промени цената, цената на услугата, дневният разход на кредити, необходимостта от рестартиране и рискът от прекъсване.
faq/change-service-resources-after-order

Променяте съществуваща услуга, а не създавате нова

Ако услугата вече е активна, промените в ресурсите трябва да се правят от детайлите ѝ. Нова поръчка ще създаде допълнителна услуга вместо да модифицира съществуващата и може да промени цената, дневния разход на кредити и поведението на системата след потвърждаване, плащане и прилагане на промяната.

Преди да потвърдите промяната

  1. Вижте текущите стойности на процесора, 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 приложение, система за търсене или контейнер с build-ове. При планирането вземете предвид паметта на приложенията, кеша, базата данни, логовете, качванията и резерва за растеж.

Сигнали, че планът е малък

  1. Увеличете RAM при грешки OOM (out of memory), когато процесите бъдат прекратени или има постоянно използване на swap паметта.
  2. Увеличете CPU при продължително високо изчислително натоварване, компресиране, компилации или интензивна работа на приложения.
  3. Увеличете дисковото пространство преди файловата система да се запълни, включително местата за логове и бази данни.
  4. След всяка промяна следете дали приложението наистина спря да достига първоначалния лимит.

Какво да предоставите, когато имате въпрос относно размера на ресурсите

Полезно е да предоставите име на услугата, тип на приложението, видима грешка, приблизително време на проблема и текущо използваните CPU, RAM и дисково пространство. Не изпращайте пароли, частни ключове или вътрешни конфигурационни файлове.

> Кога е подходяща публична IP адреса за VPS?

Отделен публичен IP адрес може да помогне при създаването на списъци за разрешени връзки, осигуряване на входящ достъп или предоставяне на стабилен изходящ източник за услуги, които са обвързани с конкретен адрес.
faq/vps-public-ip-options

Първо определете посоката на комуникация

Публичен IP адрес не е необходим автоматично за всяка услуга. Най-често се използва за изискванията на външни партньори, доставчици или защитни стени (firewall) за списък с разрешени адреси (allowlist), стабилен изходящ източник или входящ достъп до конкретен порт.

Въпроси преди поръчка на IP адрес

  1. Попитайте партньора дали разрешава входящи, изходящи или и двата типа връзки.
  2. Използвайте DNS имена вместо IP адреси, когато е възможно.
  3. Отваряйте само портовете, които приложението действително използва.
  4. Изпратете заявка за allowlist до поддръжката, преди да промените продуктовия достъп.

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

Публичният IP адрес не трябва да означава отваряне на всички портове. Препоръчваме ви да дефинирате достъпа само за минимално необходимите услуги и не изпращайте пароли, частни ключове или вътрешни правила на защитната стена като екранни снимки със секретни данни.

> Споделен SSH достъп до VPS

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

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

Многобройните VPS услуги могат да споделят един и същ публичен SSH хост, поради което всяка услуга получава свое собствено високо порт. Този порт е част от маршрутизацията към вашата услуга; без него връзката не може да бъде доставена еднозначно до правилния VPS.

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

  1. Когато използвате споделен SSH, копирайте потребителското име, хоста и порта точно както са показани.
  2. Свържете се с помощта на командата ssh -p <порт> <потребителско_име>@<публичен_хост> от вашия локален терминал.
  3. Използвайте своя частен ключ локално; никога не поставяйте частния ключ в чат или билети.
  4. Използвайте частния ключ само локално чрез вашия SSH клиент или агент; към поддръжката изпращайте само публичния хост, порта, потребителското име и видимата грешка.

Когато сте закупили допълнителен публичен IP адрес

Публичният IP адрес не заменя споделения SSH endpoint; той добавя отделен начин за достъп, подходящ за списъци за разрешаване, мониторинг или директно свързване. На практика може да видите два начина за SSH достъп: споделен хост с висок порт и директен хост или IP адрес за услугата с публичен IP адрес.

> Проверка преди свързване на собствен домейн

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

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

Първо, определете дали свързвате основен домейн (като example.com) или поддомейн (като app.example.com). Всеки вариант може да изисква различен тип DNS запис и различни ограничения от вашия доставчик на услуги.

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

  1. Уточнете къде се редактират авторитетните DNS записи за домейна.
  2. Премахнете или променете конфликтни A/AAAA, CNAME, ALIAS, ANAME или redirect записи.
  3. Използвайте типа запис, препоръчан за съответната услуга и хостнейм.
  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. Не използвайте CNAME за хостнейм, който вече има други записи, ако правилата на DNS го забраняват.
  3. Поставете DKIM под селектора на доставчика и 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. Тествайте от множество сървъри за разрешаване на имена (resolvers), ако резултатите са различни.
  4. Запишете времето на промяната, старата стойност, новата стойност и TTL.

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

Посочете hostname, очакваната цел, видимия стар отговор, видимия нов отговор, TTL и времето на промяната. Не изпращайте данни за достъп до DNS акаунт.

> Планиране на дисковото пространство за Workspace Suite

При планирането на капацитета трябва да се вземат предвид потребителските файлове, споделените папки, версиите, кошчето, прегледите и очакваният растеж.
faq/nextcloud-storage-planning

Workspace Suite расте дори извън видимите файлове

Място заемат потребителските файлове, споделените папки, изтритите файлове, версиите, прегледите, миниатюрите, клиентите за синхронизация и импортирането. Ако мястото е близо до лимита, качването или синхронизацията може да се провалят.

Преди да увеличите капацитета

  1. Изчислете текущите данни на потребителите и споделените папки.
  2. Добавете допълнително място за версии, кошче, прегледи и синхронизация.
  3. Вземете предвид големите импорти, новите екипи и очаквания растеж.
  4. Увеличете капацитета преди потребителите да достигнат лимита.

При проблеми със синхронизацията

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

> Миграция на репозитории към Gitea

Планирайте миграцията на Git репозиториите заедно с LFS, подмодули, права, ключове за разгръщане, уебхукове и CI/CD.
faq/gitea-repository-migration

Миграцията не е просто клониране

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

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

  1. Избройте хранилищата, собствениците, групите за достъп и потребителските акаунти за автоматизация.
  2. Проверете Git LFS обектите, подмодулите, защитените клонове и защитените тагове.
  3. След прехвърлянето тествайте клонирането, качването, Git LFS, подмодулите и изпълнението на CI.
  4. След миграцията анулирайте или променете старите токени, без да споделяте техните стойности.

Важна информация относно чувствителните данни при миграция

Не изпращайте към поддръжката токени, частни ключове, частни ключове за разгръщане или CI секрети. Достатъчни са имената на хранилищата, типът интеграция, видимата грешка и информация за това какво е работило преди миграцията.

> Домейн на подателя за Listmonk

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

Доставяемостта започва от домейна

Listmonk се нуждае от ясна From идентичност и DNS записи, които пощенските системи могат да проверят. SPF, DKIM и DMARC трябва да съответстват на домейна или поддомейна, от който искате да изпращате кампании.

Преди първата кампания

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

Поверителната информация за имейлите не трябва да се споделя в тикетите.

При диагностика, моля, предоставете домейна, типа запис, публично видимата DNS стойност и съобщението за грешка. Не предоставяйте SMTP пароли, API токени, частни DKIM ключове или експортирани списъци с лични данни.

> Настройки за времето на работа за Classic Hosting

Classic Hosting може да работи в автоматичен или ръчен режим. Ресурсите като процесор, RAM памет, памет, място за съхранение, запазване на резервни копия, запазване на Offsite Archive, качвания, кеш и логове влияят върху цената и стабилността.
faq/classic-hosting-runtime-settings

Автоматичният режим не винаги е най-добрият избор

Auto Runtime помага за разпознаването на проекти, но ръчният режим е подходящ, когато искате да изберете точно Nginx, Apache, FrankenPHP или конкретен runtime. Използвайте PHP selector само там, където избраният runtime го поддържа.

Настройки преди внедряване

  1. Изберете автоматичен или ръчен режим на работа в зависимост от използваната рамка и начина на компилация.
  2. Изберете PHP 8.2, 8.3 или 8.4 само за поддържани сценарии с PHP.
  3. Настройте процесор (CPU), памет (RAM), дисково пространство, период на запазване на резервни копия и Offsite Archive според данните и трафика.
  4. След внедряването тествайте качванията, кеша, логовете и видимите грешки в приложението.

Когато приложението не стартира

Изпратете информация за режима на работа, езика или версията на PHP, видими грешки и промените, които са били направени. Не изпращайте .env файлове, пароли, токени или цели логове, съдържащи чувствителна информация.

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

Най-полезни са номерата на поръчките, имената на услугите, домейните, часовете, публичните хостове, портовете, настройките за запазване на резервни копия, настройките за Offsite Archive, качванията, кешът, логовете, екранните снимки и видимите грешки (без секретна информация).
faq/support-safe-information-to-share

Качествената заявка трябва да включва релевантна информация, а не поверителни данни.

Екипът за поддръжка може да реагира по-бързо, когато получи номер на поръчка, име на услуга, домейн, публичен хост или порт, време на проблема, извършени промени и точно съобщение за грешка.

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

  1. Моля, посочете номера на поръчката, услугата, домейна, приблизителното време и стъпката, в която е възникнал проблемът.
  2. При проблеми с хостинга, моля, предоставете информация за средата на изпълнение, PHP или езика, процесора, RAM паметта, дисковото пространство, качванията, кеша и логовете, като премахнете чувствителна информация.
  3. Моля, изрязвайте или скривайте чувствителни данни от прикачени снимки преди изпращане.
  4. Ако не сте сигурни дали дадена информация е подходяща за заявката, първо попитайте, без да я изпращате.

Какво никога не трябва да се изпраща

Не изпращайте пароли, частни ключове, фрази за възстановяване, API токени, session cookies, експортирани бази данни, цели .env файлове, пълни логове със чувствителни стойности или вътрешни детайли на инфраструктурата.