FAQ

Domande frequenti

Guide brevi e pratiche per la configurazione dei servizi, l'accesso e le operazioni più comuni.

> Come funziona il sistema di credito Cli>_?

Un unico saldo prepagato condiviso finanzia tutti i servizi idonei e viene consumato solo mentre sono attivi.
faq/prepaid-credit-how-it-works

Il tuo account Cli>_ ha un unico saldo di credito prepagato condiviso. I nuovi clienti idonei possono richiedere Starter Credit solo dopo aver completato la verifica obbligatoria dell’account e antiabuso. I servizi idonei attivi consumano il saldo nel tempo. La stima mensile usa 31 giorni e un nuovo servizio può avviarsi solo se il saldo copre almeno 7 giorni. L’avviso rosso appare quando l’autonomia stimata scende sotto 7 giorni; altrimenti l’avviso arancione appare quando scende sotto 14 giorni.

Esaurito il saldo, il servizio viene sospeso dopo 7 giorni, smette di consumare credito e inizia il periodo di conservazione ed eliminazione di 7 giorni. Prima della scadenza mostrata puoi riavviarlo con credito sufficiente. L’annullamento di un servizio già provisionato lo sospende e avvia lo stesso periodo. Un servizio in attesa e non provisionato può essere disattivato subito. Dopo la scadenza iniziano la disattivazione e la rimozione del servizio provisionato. Force delete disattiva subito il servizio, salta la conservazione e avvia la rimozione dal runtime attivo; il completamento segue l’elaborazione del deployment e GitOps. Backup e Offsite Archive seguono politiche di conservazione separate.

Esempio OpenCode a 9,90 EUR: 9,90 / 31 ≈ 0,319 EUR al giorno. Dopo 10 giorni completi sono stati consumati circa 3,19 EUR. Con saldo iniziale esatto di 9,90 EUR e nessun altro servizio restano circa 6,71 EUR. Il consumo si ferma dopo la disabilitazione.

L’esempio è solo illustrativo. Fanno sempre fede i prezzi correnti mostrati in Cli>_.

> Come generare una chiave SSH pubblica dalla riga di comando

Crea una chiave SSH pubblica per accedere in modo sicuro al tuo server virtuale privato (VPS). Condividi solo la chiave pubblica con Cli>_; conserva la chiave privata sul tuo dispositivo.
faq/come-generare-una-chiave-ssh-pubblica

La chiave pubblica è condivisa, quella privata resta al sicuro con te

Inserisci solo la chiave SSH pubblica durante l'ordine o la configurazione del servizio. La chiave privata rimane sul tuo computer e non viene inviata all'assistenza né inserita in un modulo web.

Procedura

  1. Apri il terminale sul tuo computer.
  2. Esegui il comando: ssh-keygen -t ed25519 -C "your-email@example.com".
  3. Conferma la posizione del file o scegli un percorso personalizzato. Non inviare mai la tua chiave privata a nessuno.
  4. Visualizza la chiave pubblica con il comando: cat ~/.ssh/id_ed25519.pub.
  5. Copia l'intera riga che inizia con ssh-ed25519 e incollala nel campo "Chiave pubblica SSH" durante il processo di acquisto o la configurazione del servizio.
  6. Copia l'intera riga contenente ssh-ed25519 e incollala nel campo "Chiave pubblica SSH".

PowerShell per Windows 10/11

  1. Apri PowerShell o Windows Terminal.
  2. Esegui il comando: ssh-keygen -t ed25519 -C "tua_email@example.com".
  3. Premi Invio per salvare la chiave in C:\Users\tuo_utente\.ssh\id_ed25519, oppure inserisci un percorso personalizzato.
  4. Se Windows richiede una passphrase, utilizza una che puoi conservare in modo sicuro, oppure premi Invio per saltarla durante una configurazione semplice.
  5. Per visualizzare la chiave pubblica, utilizza il comando: Get-Content $env:USERPROFILE\.ssh\id_ed25519.pub.
  6. Copia solo l'intera riga che inizia con ssh-ed25519. Non copiare né caricare il file della chiave privata.
> Come creare una chiave SSH con un'interfaccia grafica su Windows

Guida grafica su Windows per creare una coppia di chiavi SSH senza utilizzare la riga di comando.
faq/creare-chiave-ssh-windows-interfaccia-grafica

Utilizza uno strumento di Windows e inserisci solo la chiave pubblica

Puoi creare una coppia di chiavi SSH anche tramite un client SSH per Windows come PuTTYgen. Cli>_ richiede solo la chiave pubblica. Mantieni il file della chiave privata sul tuo computer e non caricarlo in nessun modulo web.

Procedura

  1. Installa PuTTY o apri PuTTYgen se è già installato.
  2. Se disponibile, scegli EdDSA/Ed25519; altrimenti, scegli RSA 4096.
  3. Clicca su Genera e muovi il mouse nell'area vuota finché la chiave non viene creata.
  4. Aggiungi una passphrase se desideri una protezione locale aggiuntiva per la chiave privata.
  5. Salva la chiave privata sul tuo dispositivo e mantienila confidenziale.
  6. Copia il testo della chiave pubblica e incollalo nel campo "SSH public key" in Cli>_.

Non condividere dati sensibili

Non inviare file .ppk, chiavi private, frasi di accesso, password o token all'assistenza o nei moduli.

> Porta con te il tuo dominio

Scopri come collegare il tuo dominio o sottodominio a un servizio CLIopen prima di attivare la funzionalità "Porta con te il tuo dominio".
faq/collegare-il-proprio-dominio

Cosa fa questa impostazione

L'opzione "Bring your own domain" consente al tuo servizio di rispondere utilizzando il tuo hostname personalizzato, ad esempio app.example.com, invece del nome host generato predefinito *.co.cliopen.cloud. Il DNS deve essere configurato per puntare a CLIopen prima che il nome host possa essere utilizzato in modo sicuro dal servizio.

Prima di iniziare

  1. Scegli l'hostname esatto che desideri utilizzare, ad esempio app.example.com. L'opzione più semplice è utilizzare un sottodominio.
  2. Accedi al pannello di gestione DNS del tuo registrar di domini o del tuo provider DNS.
  3. Elimina eventuali record A, AAAA, CNAME, ALIAS o redirect in conflitto per lo stesso hostname.
  4. Mantieni attivo l'hostname CLIopen generato automaticamente finché il tuo hostname personalizzato non viene verificato e funziona correttamente.

Configurazione DNS consigliata per un sottodominio

Crea record DNS per il nome host esatto che inserirai in CLIopen. Per app.example.com, il nome DNS è app. Puntalo agli indirizzi ingress di CLIopen forniti dal supporto CLIopen o nella documentazione del servizio. Se il tuo provider richiede un tipo di record, utilizza un record A per IPv4 e un record AAAA per IPv6 quando vengono forniti tali indirizzi.

Esempio:

app.example.com.  A     <Indirizzo IPv4 CLIopen>
app.example.com.  AAAA  <Indirizzo IPv6 CLIopen, se disponibile>

Quando CLIopen fornisce un target CNAME

Alcuni servizi forniscono un hostname generato, ad esempio service.customer.co.cliopen.cloud. Se le istruzioni del tuo servizio richiedono esplicitamente l'uso di un record CNAME, crea un record come app.example.com CNAME service.customer.co.cliopen.cloud. Utilizza i record CNAME solo per i sottodomini, non per il dominio principale (apex/root), a meno che il tuo provider DNS supporti la funzionalità ALIAS o ANAME flattening.

Utilizzo del dominio principale

Per un dominio base come example.com, la maggior parte dei provider DNS non consente l'utilizzo di un record CNAME standard. Utilizza i record A/AAAA che puntano agli indirizzi ingress di CLIopen, oppure utilizza la funzione ALIAS/ANAME specifica del tuo provider se CLIopen ti ha fornito un hostname di destinazione.

Delegare un'intera sottosezione

Se desideri che CLIopen gestisca i record in una sottodominio come apps.example.com, crea dei record NS per tale sottodominio, indirizzandoli ai server nameserver di CLIopen che hai ricevuto. Non modificare i server nameserver dell'intero dominio a meno che tu non voglia intenzionalmente che CLIopen (o un altro servizio DNS) gestisca tutti i record.

Checklist

  1. Attendere la propagazione DNS. Le piccole modifiche spesso diventano visibili in pochi minuti, ma alcuni fornitori potrebbero memorizzarle nella cache più a lungo.
  2. Verificare che il nome host punti alla destinazione CLIopen e non al provider precedente.
  3. Nel campo "Bring your own domain", inserisci l'hostname esatto, senza `https://` e senza percorsi.
  4. Dopo aver aggiornato il servizio, verifica `https://app.example.com` nel tuo browser.
  5. Conserva le vecchie voci DNS solo se non sono in conflitto con il nuovo hostname.
> Come trasferire una zona DNS a CLIopen

Delega il dominio a ns1.cliopen.com e ns2.cliopen.com, così che CLIopen possa pubblicare i record per l'intera zona.
faq/delegare-una-zona-dns

Cosa significa trasferimento di zona qui

Nel contesto del DNS per i clienti, il trasferimento indica la modifica dei server dei nomi autoritativi presso il registrar del dominio. Dopo aver delegato a CLIopen, i record DNS aggiunti in CLIopen vengono pubblicati dai nostri server dei nomi autoritativi.

Prima di modificare i nameserver

  1. Copia le voci DNS esistenti che sono ancora necessarie, ad esempio per il sito web, la posta elettronica, le verifiche, SPF, DKIM, DMARC e le voci dei servizi.
  2. Aggiungi la zona in CLIopen DNS. Se la delega non è ancora pronta, CLIopen la salva ma non la attiva per i clienti finché la convalida non viene superata.
  3. Crea le voci necessarie in CLIopen DNS prima di cambiare i nameserver, se possibile.
  4. Presta attenzione alla configurazione del record CAA, poiché valori errati possono impedire l'emissione dei certificati.

Delega la zona

  1. Apri le impostazioni del dominio presso il tuo registrar, ad esempio example.com.
  2. Trova le impostazioni dei Nameserver, della delega DNS o dei server DNS autoritativi.
  3. Sostituisci i nameserver esistenti con ns1.cliopen.com e ns2.cliopen.com.
  4. Salva le modifiche e attendi la propagazione nel registro e nei resolver.

Validazione

Torna a CLIopen DNS e fai clic su "Verifica nuovamente la delega". Quando i record NS pubblici mostrano ns1.cliopen.com e ns2.cliopen.com, la zona viene inserita nella coda di sincronizzazione e i record diventano attivi da CLIopen.

> Registrazione dell'account e primo accesso

Crea un account aziendale, aggiungi i dettagli di fatturazione e salva le informazioni di accesso in una casella di posta elettronica a cui il tuo team può accedere.
faq/account-registration-and-login

Un unico account per ordini e gestione

Utilizza l'account come punto di riferimento stabile per ordini, dati di fatturazione, servizi, domini e comunicazioni con il supporto. È preferibile utilizzare un indirizzo email aziendale a cui il team possa accedere anche in caso di cambiamenti del personale.

Prima del tuo primo ordine

  1. Registrati utilizzando il tuo indirizzo email aziendale.
  2. Completa la verifica dell'email, se richiesta dal sito.
  3. Inserisci i dati di fatturazione prima di effettuare un ordine a pagamento.
  4. Abilita l'autenticazione a due fattori non appena disponibile.

Accesso per il team

Non inviare la password ai colleghi tramite chat o email. Se è necessario che più persone vi accedano, utilizzate un gestore di password interno oppure richiedete una procedura consigliata; il supporto tecnico non ha bisogno della tua password né del token.

> Stima mensile, stima annuale e consumo giornaliero reale

I prezzi mensili e annuali servono come riferimento; per i servizi con pagamento anticipato, il consumo giornaliero è determinante dopo la conferma dell'ordine o della modifica.
faq/billing-periods-and-credit-burn

Il confronto non è un calendario di addebito

Utilizza la stima mensile come riferimento per 31 giorni e quella annuale come riferimento per 372 giorni. Il consumo effettivo del credito avviene in base al tempo di utilizzo del servizio e alla configurazione confermata, nel caso di servizi prepagati.

Cosa controllare quando si modifica il prezzo

  1. Confronta il consumo giornaliero prima e dopo la modifica.
  2. Un aumento di CPU, RAM, disco o l'attivazione di opzioni a pagamento comporta un maggiore consumo giornaliero.
  3. La modifica diventa effettiva solo dopo la conferma, l'eventuale pagamento e l'applicazione.
  4. Per la contabilità, salva le conferme d'ordine e la cronologia dei crediti.

Considera un periodo specifico per l'analisi.

Per assistere meglio l'assistenza clienti, fornisci il numero dell'ordine, il nome del servizio e le date da verificare. Non inviare dati bancari completi, estratti conto o screenshot con informazioni personali non necessarie.

> Stato dell'ordine dopo il pagamento

L'ordine potrebbe richiedere del tempo per la conferma da parte del fornitore di pagamento. Crea una nuova copia solo quando l'ordine originale è stato chiaramente annullato o è scaduto.
faq/order-status-and-payment-confirmation

"In attesa" non significa necessariamente un errore

Dopo il ritorno dalla pagina di pagamento, l'ordine potrebbe essere in attesa della conferma da parte del fornitore di servizi di pagamento. Fino a quando lo stato non risulta chiaramente fallito o scaduto, un nuovo ordine duplicato potrebbe complicare l'abbinamento.

Cosa fare dopo il pagamento

  1. Dopo aver completato il pagamento, torna alla pagina di Cli>_.
  2. Controlla l'account per verificare lo stato dell'ordine e eventuali messaggi relativi al pagamento.
  3. Se l'ordine è ancora in attesa, concedi al fornitore il tempo necessario per confermare la transazione.
  4. In caso di problemi, invia al supporto il numero dell'ordine e il riferimento della transazione, se disponibile.

Cosa non inviare

L'assistenza clienti non richiede i dati della carta di credito, la password o l'intera ricevuta bancaria. È sufficiente fornire il numero dell'ordine, l'ora del pagamento, lo stato visualizzato e uno screenshot oscurato in caso di errore.

> Informazioni per velocizzare la configurazione del servizio

Prepara il nome del servizio, il dominio, le dimensioni dello spazio di archiviazione, l'indirizzo email di accesso e la chiave SSH pubblica; i dati sensibili non devono essere inseriti nei moduli.
faq/service-setup-information-needed

Inserire dati precisi fa risparmiare tempo

Utilizza i moduli d'ordine per inserire valori pubblici o non riservati: nome del servizio, dominio, piano DNS, dimensione dello storage, CPU, RAM, email di amministrazione o chiave SSH pubblica. Le password, le chiavi private e i token devono essere esclusi dai campi del modulo.

Preparati prima di effettuare l'ordine

  1. Scegli un nome di servizio facilmente riconoscibile per il tuo team.
  2. Decidi se utilizzare un dominio personalizzato o un hostname temporaneo fornito dal sistema.
  3. Prepara una chiave SSH pubblica, se richiesta dal servizio.
  4. Verifica le dimensioni dello storage e le risorse in base all'applicazione che intendi utilizzare.

Non inviare informazioni riservate

Se non sei sicuro se un dato sia riservato, chiedi senza inviarlo. Non inviare chiavi private, password, token, dump di database o file di configurazione completi nella chat o nell'ordine.

> Modifica della CPU, della RAM, del disco o dello spazio di archiviazione dopo l'ordine

Modifica il servizio esistente tramite i dettagli del servizio stesso, non creando un nuovo ordine duplicato. La modifica delle risorse può influire sul prezzo, sul consumo giornaliero di crediti, sulla necessità di riavvio e sul rischio di interruzione del servizio.
faq/change-service-resources-after-order

Stai modificando un servizio esistente, non ne stai creando uno nuovo

Se il servizio è già attivo, modifica le risorse dalla sua pagina dei dettagli. Un nuovo ordine creerebbe un altro servizio invece di modificare quello esistente e potrebbe cambiare il prezzo, il consumo giornaliero di crediti e il comportamento del servizio solo dopo la conferma, l'eventuale pagamento e l'applicazione della modifica.

Prima di confermare la modifica

  1. Visualizza l'utilizzo attuale di CPU, RAM, spazio su disco, backup e la conservazione dell'archivio Offsite.
  2. Controlla il nuovo costo giornaliero e l'impatto sul credito.
  3. Leggi gli avvisi relativi a riavvii, manutenzione o interruzioni di servizio.
  4. Esegui un'esportazione dei dati importanti prima di apportare modifiche potenzialmente rischiose.

Cosa fare quando la modifica non avviene come previsto

Invia il nome del servizio, l'ora della modifica, lo stato visibile e il messaggio di errore. Non inviare chiavi private, password o token; per la diagnostica è sufficiente fornire un contesto pubblico e uno screenshot con le informazioni sensibili oscurate.

> Cancellazione del servizio e data di cancellazione dei dati

Il servizio attivo viene prima interrotto, quindi viene mostrato un periodo visibile e configurabile per la conservazione dei dati, dopodiché è possibile procedere con l'eliminazione definitiva.
faq/cancel-service-and-data-retention

L'annullamento non comporta sempre l'eliminazione immediata

Quando un servizio è già attivo, viene prima sospeso e viene visualizzato un termine configurabile entro il quale è possibile valutare il ripristino o l'esportazione dei dati. Gli ordini in attesa non pagati senza dati attivi potrebbero avere un comportamento diverso, mentre la rimozione definitiva avviene solo dopo lo scadere del periodo di conservazione.

Verifica prima della cancellazione

  1. Crea un'esportazione personalizzata dei dati che desideri conservare a lungo termine.
  2. Leggi la data e l'ora previste per l'eliminazione del servizio sospeso.
  3. Non confondere i backup e l'archiviazione offsite con l'eliminazione automatica dei dati.
  4. Se non sei sicuro, contatta l'assistenza prima della data di eliminazione.

Il ripristino potrebbe non essere possibile dopo la scadenza.

Dopo la scadenza visibile, i dati non devono essere considerati disponibili. In caso di domande, fornisci il numero d'ordine e il nome del servizio, evitando esportazioni di database o credenziali riservate.

> Backup e richieste di ripristino

I backup servono per il ripristino operativo, non come alternativa all'esportazione; l'operazione di ripristino può sovrascrivere dati più recenti.
faq/backups-and-restore-requests

Il backup non è un archivio né un'esportazione

La durata della conservazione dei backup dipende dal prodotto e dalle opzioni scelte. Il backup aiuta nel ripristino operativo in caso di errore, ma non sostituisce l'esportazione manuale, l'archivio di controllo o l'Offsite Archive. Un ripristino potrebbe sovrascrivere modifiche più recenti.

Come preparare una richiesta di ripristino

  1. Inserisci il nome del servizio e il numero d'ordine.
  2. Descrivi l'orario approssimativo a cui desideri tornare.
  3. Specifica se è necessario ripristinare l'intero servizio o solo una parte, se supportato.
  4. Allega un errore visibile o un contesto senza password, token o chiavi private.

Considera l'impatto prima del ripristino

Se il servizio ha ricevuto nuovi dati nel frattempo, il ripristino potrebbe sostituirli con uno stato precedente. Prima di confermare il ripristino, informa il team ed esegui un backup di ciò che non vuoi perdere.

> A cosa serve Offsite Archive

Offsite Archive conserva copie di archivio remote, separate dai backup operativi a breve termine e dal ciclo di vita del servizio.
faq/offsite-archive-purpose

Archivio esterno per dati non in uso quotidiano

Offsite Archive è progettato per creare copie di archivio remote e per la conservazione a lungo termine dei dati. Non è un disco attivo per l'applicazione, né sostituisce le esportazioni locali o i backup operativi brevi.

Quando attivarlo

  1. Utilizzalo per i dati che desideri conservare anche al di fuori delle normali operazioni del servizio.
  2. Seleziona il numero di giorni di conservazione in base ai requisiti di conformità, alle esigenze aziendali o all'obiettivo di ripristino.
  3. Tieni presente che il costo aumenta in base al volume archiviato e al tempo di conservazione.
  4. Per grandi volumi di dati, pianifica l'archiviazione insieme al tuo processo di esportazione.

Come valutare il costo

La base è MB-giorni: la quantità di dati archiviati e il numero di giorni di conservazione. La tariffa viene visualizzata come EUR/GB/mese e il risultato viene arrotondato ai centesimi.

> Selezione CPU, RAM e disco per VPS

Scegli le dimensioni del tuo VPS in base all'applicazione, al database, alla cache, ai log e alla crescita prevista. L'utilizzo eccessivo della memoria (OOM) o lo swap indicano la necessità di più RAM.
faq/vps-cpu-ram-and-disk-sizing

Inizia considerando il carico reale, non le sensazioni

Un piccolo sito web statico ha esigenze diverse da un database, un'applicazione Java, una ricerca o un container con build. Quando pianifichi, considera la memoria applicativa, la cache, il database, i log, gli upload e lo spazio per la crescita.

Segnali che il piano è troppo piccolo

  1. Aumenta la RAM in caso di errori OOM (Out Of Memory), terminazione dei processi o swap eccessivo.
  2. Aumenta la CPU quando si verifica un carico computazionale elevato e prolungato, compressione, compilazione o attività intensa dei worker.
  3. Aumenta lo spazio su disco prima che il file system, i log o il database si riempiano.
  4. Dopo ogni modifica, verifica se l'applicazione ha effettivamente smesso di raggiungere il limite originale.

Cosa inviare quando si ha una domanda sulle specifiche tecniche

Fornisci il nome del servizio, il tipo di applicazione, eventuali errori visibili, l'ora approssimativa e le risorse attuali (CPU, RAM e disco). Non inviare password, chiavi private o file di configurazione interni.

> Quando ha senso avere un indirizzo IP pubblico per un VPS

Un indirizzo IP pubblico dedicato è utile per le liste di autorizzazione, l'accesso in entrata, una sorgente di uscita stabile o i servizi associati a un determinato indirizzo.
faq/vps-public-ip-options

Innanzitutto, determina la direzione della comunicazione

Un indirizzo IP pubblico non è sempre necessario per ogni servizio. Spesso soddisfa le esigenze di partner esterni, fornitori o firewall in termini di liste consentite, una sorgente in uscita stabile o l'accesso in entrata a una porta specifica.

Domande da porre prima di ordinare un indirizzo IP

  1. Chiedi al partner se è necessario consentire il traffico in entrata, in uscita o entrambi tramite la lista consentita.
  2. Utilizza i nomi DNS invece degli indirizzi IP numerici quando possibile.
  3. Apri solo le porte effettivamente necessarie all'applicazione.
  4. Invia la richiesta per l'aggiunta alla lista consentita al supporto prima di modificare le impostazioni di accesso in ambiente di produzione.

Cosa tenere disattivato

Un indirizzo IP pubblico non significa aprire tutte le porte. Progetta l'accesso limitandolo ai servizi strettamente necessari e non inviare password, chiavi private o regole del firewall interne sotto forma di screenshot contenenti informazioni sensibili.

> Accesso SSH condiviso a una VPS

Senza un indirizzo IP pubblico acquistato, la VPS si connette tramite un endpoint SSH condiviso con una porta elevata; con un indirizzo IP pubblico, è disponibile anche l'accesso SSH diretto su tale indirizzo.
faq/shared-ssh-access-for-vps

Perché l'accesso SSH condiviso utilizza una porta elevata

Più servizi VPS possono condividere lo stesso endpoint SSH pubblico, motivo per cui ogni servizio riceve la propria porta dedicata. La porta fa parte del routing verso il tuo servizio; senza di essa, la connessione non potrebbe essere univocamente indirizzata al server VPS corretto.

Come connettersi in base al tipo di accesso

  1. Per l'SSH condiviso, copia dal servizio lo username, l'host pubblico e la porta.
  2. Utilizza il formato ssh -p <porta> <username>@<public-host>.
  3. Se il servizio dispone di un indirizzo IP pubblico, potrebbe essere disponibile anche un endpoint SSH diretto su quell'indirizzo IP o sul suo DNS, a seconda della configurazione del servizio.
  4. Utilizza la chiave privata solo localmente tramite il tuo client SSH o agente; fornisci al supporto solo l'host pubblico, la porta, il nome utente e eventuali errori visibili.

Quando hai acquistato un indirizzo IP pubblico

L'indirizzo IP pubblico non sostituisce necessariamente un endpoint SSH condiviso. Aggiunge un metodo di accesso diretto utile per le liste consentite, il monitoraggio o le integrazioni; nella pratica, potresti vedere due tipi di accesso SSH: un host condiviso con una porta elevata e un host o indirizzo IP diretto per il servizio con indirizzo IP pubblico.

> Verifica preliminare per il collegamento del tuo dominio

Prima di passare a un dominio personalizzato, verifica le impostazioni DNS autorevoli, l'hostname corretto, il tipo di record (A, CNAME, ecc.), se si tratta di un dominio principale o di un sottodominio e la presenza di eventuali vecchi record in conflitto.
faq/custom-domain-readiness-checklist

L'hostname preciso è fondamentale

Innanzitutto, chiarisci se stai collegando un dominio principale (come example.com) o un sottodominio (come app.example.com). Ogni opzione potrebbe richiedere tipi di record DNS diversi, restrizioni diverse dal tuo provider DNS e verifiche con il registrar.

Prima di modificare le impostazioni DNS

  1. Verifica dove vengono modificati i record DNS autoritativi del dominio.
  2. Rimuovi o modifica i record A/AAAA, CNAME, ALIAS, ANAME o di reindirizzamento in conflitto.
  3. Utilizza il tipo di record consigliato per il servizio e l'hostname specifici.
  4. Dopo aver effettuato la modifica, attendere la propagazione DNS e quindi verificare il corretto funzionamento di HTTPS.

Ripristino sicuro

Non disattivare l'hosting precedente finché il nuovo nome host non risponde correttamente. In caso di problemi, fornire il dominio, la destinazione prevista e i risultati DNS pubblici, evitando di condividere le credenziali del registrar.

> Tipi di record DNS per i servizi

I record A/AAAA puntano agli indirizzi, CNAME crea un alias, MX è utilizzato per la posta elettronica e TXT viene utilizzato per le verifiche, inclusi SPF, DKIM o DMARC.
faq/dns-record-types-for-services

Non combinare i record DNS senza una ragione specifica

Ogni tipo di record DNS ha uno scopo specifico. I record A e AAAA puntano a indirizzi IP, CNAME crea un alias per un sottodominio, MX instrada la posta elettronica, TXT contiene verifiche e politiche email, e CAA limita le autorità di certificazione.

Quando si copiano i record

  1. Copia esattamente nome, tipo e valore seguendo le istruzioni del servizio.
  2. Non utilizzare CNAME su un hostname che ha già altri record, se le regole DNS lo vietano.
  3. Inserisci DKIM sotto il selettore fornito dal provider e DMARC di solito sotto _dmarc.
  4. Configura CAA con attenzione, perché un valore errato può bloccare l'emissione del certificato.

Quando il DNS non funziona

Invia al supporto hostname, tipo di record, valore atteso e risultato pubblico. Non inviare credenziali per l'accesso all'amministrazione DNS né screenshot contenenti token API.

> Propagazione DNS e TTL: nessuna garanzia di tempi precisi

Il TTL (Time To Live) determina per quanto tempo i server DNS possono conservare una risposta precedente. Durante la propagazione, vecchi e nuovi risultati possono coesistere fino a quando le cache non vengono aggiornate.
faq/dns-propagation-and-ttl

La propagazione è una questione di cache, non di magia

Nel DNS non esiste una garanzia precisa in termini di tempo. Dopo una modifica ai server DNS autorevoli, diversi resolver potrebbero restituire risposte vecchie o nuove finché la loro cache non viene aggiornata secondo il valore TTL. Pertanto, i risultati possono variare a seconda della rete, del paese o del resolver DNS utilizzato.

Durante una modifica pianificata

  1. Se il provider lo consente, riduci il TTL prima della modifica pianificata.
  2. Dopo aver modificato le impostazioni DNS, evita modifiche ripetute e casuali finché la cache non viene aggiornata.
  3. Esegui test da diversi resolver se i risultati sono discordanti.
  4. Annota l'ora della modifica, il valore precedente, il nuovo valore e il TTL.

Cosa inviare durante la diagnostica

Indica hostname, destinazione prevista, risposta vecchia visibile, risposta nuova visibile, TTL e ora della modifica. Non inviare credenziali DNS né note interne del fornitore.

> Pianificazione dello spazio di archiviazione per Workspace Suite

Nella pianificazione della capacità, considerare i file degli utenti, le cartelle condivise, le versioni, il cestino, le anteprime, l'overhead di sincronizzazione e la crescita del team.
faq/nextcloud-storage-planning

Workspace Suite cresce anche oltre i file visibili

Lo spazio utilizzato comprende file utente, cartelle condivise, file eliminati, versioni, anteprime, miniature, client di sincronizzazione e importazioni. Se lo spazio di archiviazione si avvicina al limite, potrebbero verificarsi errori durante il caricamento o la sincronizzazione.

Prima di richiedere risorse aggiuntive

  1. Calcola i dati attuali degli utenti e le cartelle condivise.
  2. Aggiungi spazio per le versioni, il cestino, le anteprime e l'attività di sincronizzazione.
  3. Considera importazioni di grandi dimensioni, nuovi team e la crescita prevista.
  4. Aumenta la capacità prima che gli utenti raggiungano il limite.

In caso di problemi di sincronizzazione

Invia le informazioni relative al servizio, l'utilizzo previsto, l'ora del problema e l'errore visualizzato dal cliente. Non inviare file personali, password o esportazioni di dati utente, a meno che non siano esplicitamente richieste dal supporto tramite un canale sicuro.

> Migrazione dei repository a Gitea

Pianificare la migrazione dei repository includendo LFS, submodule, permessi, chiavi di deploy, webhook e CI/CD.
faq/gitea-repository-migration

La migrazione non consiste solo in un 'git clone'

Oltre alla cronologia del repository, è necessario trasferire o riconfigurare proprietari, team, rami protetti, tag protetti, Git LFS, submodule, chiavi di deployment, webhook e connessioni CI/CD.

Controlli preliminari alla migrazione

  1. Elenca repository, proprietari, gruppi di accesso e account di automazione.
  2. Verifica oggetti Git LFS, submodule, protezioni dei rami e protezioni dei tag.
  3. Dopo il trasferimento, testa le operazioni di clone, push, Git LFS, submodule e l'esecuzione del CI.
  4. Dopo la migrazione, revoca o sostituisci i vecchi token senza condividere i loro valori.

Dati sensibili durante la migrazione

Non inviare al supporto token, chiavi private, parti private delle chiavi di deployment né segreti CI. Fornisci solo nomi dei repository, tipo di integrazione, errori visibili e informazioni su cosa funzionava prima della migrazione.

> Dominio di invio per Listmonk

Per le campagne, prepara un dominio o sottodominio di invio, l'identità del mittente, i record SPF, DKIM, DMARC, la gestione dei messaggi di errore e le opzioni di disiscrizione.
faq/listmonk-sender-domain-basics

La deliverability inizia dal dominio

Listmonk richiede un'identità del mittente chiara e record DNS verificabili. SPF, DKIM e DMARC devono essere coerenti con il dominio o sottodominio da cui invii le campagne.

Prima della prima campagna

  1. Scegli un dominio o sottodominio da utilizzare per le campagne e imposta l'identità del mittente (From).
  2. Aggiungi i record DNS di verifica, inclusi SPF, selettore DKIM e DMARC, richiesti dal tuo provider di posta elettronica.
  3. Invia messaggi di prova prima di una campagna reale e controlla la classificazione come spam, il comportamento in caso di mancata consegna (bounce), l'indirizzo di ritorno (Return-Path) e i link.
  4. Verifica le impostazioni di disiscrizione e List-Unsubscribe prima dell'invio effettivo.

I segreti relativi alla posta elettronica non devono essere inclusi nei ticket.

Per la diagnostica, invia il dominio, il tipo di record, il valore DNS pubblico e il messaggio di errore. Non inviare password SMTP, token API, chiavi DKIM private o elenchi di destinatari con dati personali.

> Impostazioni del runtime per Classic Hosting

Classic Hosting può funzionare in modalità runtime automatica o manuale. CPU, RAM, memoria, spazio di archiviazione, conservazione dei backup, conservazione dell'archivio offsite, caricamenti, cache e log influiscono sui costi e sulla stabilità.
faq/classic-hosting-runtime-settings

La modalità automatica non è sempre la scelta giusta

Auto Runtime aiuta con i progetti riconosciuti, ma la modalità manuale è utile quando si desidera scegliere specificamente Nginx, Apache, FrankenPHP o un runtime specifico. Utilizza il selettore PHP solo dove supportato dal runtime selezionato.

Impostazioni preliminari al rilascio

  1. Scegli la modalità Runtime automatica o manuale in base al framework e al metodo di build.
  2. Seleziona PHP 8.2, 8.3 o 8.4 solo per gli scenari PHP supportati.
  3. Configura CPU, RAM, spazio su disco, conservazione dei backup e archiviazione offsite in base ai dati e al traffico.
  4. Dopo il rilascio, testa gli upload, la cache, i log e gli errori visibili dell'applicazione.

Quando l'applicazione non si avvia

Invia informazioni sulla modalità di runtime, sulla lingua o sulla versione di PHP, eventuali errori visibili, le modifiche apportate e l'ora approssimativa del rilascio. Non inviare file .env, password, token o log completi contenenti dati sensibili.

> Quali informazioni inviare in modo sicuro al supporto

Sono utili i numeri d'ordine, i nomi dei servizi, i domini, gli orari, gli host pubblici, le porte, la conservazione dei backup, la conservazione dell'archivio offsite, i caricamenti, la cache, i log, gli screenshot e gli errori visibili, senza informazioni riservate.
faq/support-safe-information-to-share

Una richiesta efficace contiene informazioni pertinenti, non dati riservati.

L'assistenza può rispondere più velocemente quando riceve il numero d'ordine, il nome del servizio, il dominio, l'host pubblico o la porta, l'ora in cui si è verificato il problema, le modifiche apportate e un messaggio di errore dettagliato.

Contenuto sicuro del messaggio

  1. Indica l'ordine, il servizio, il dominio, l'ora e la fase in cui si è verificato il problema.
  2. Per i problemi relativi all'hosting, specifica l'ambiente di runtime, il linguaggio o la versione di PHP, la CPU, la RAM, lo spazio su disco, i backup, l'archiviazione offsite, gli upload, la cache e i log, evitando di includere informazioni sensibili.
  3. Ritaglia o oscura le informazioni sensibili negli screenshot prima di inviarli.
  4. Se non sei sicuro che un'informazione sia appropriata per il ticket, chiedi prima senza inviarla.

Cosa non inviare mai

Non inviare password, chiavi private, seed di recupero, token API, cookie di sessione, esportazioni di database, file .env completi, log con informazioni sensibili o dettagli interni dell'infrastruttura.