Prima di iniziare
Quattro cose. Tre le puoi fornire solo tu.
La macchina
Sezione intitolata “La macchina”Ubuntu 26.04 LTS è ciò per cui l’installer è tarato; va bene qualsiasi cosa da 22.04 in su. 2 vCPU, 4 GB RAM, almeno 20 GB di disco.
3,7 GB di RAM vanno bene — l’installer provisiona uno swapfile da 4 GB. Sotto quella soglia, le build delle superfici falliscono: una build terminata con segnale 137 è la macchina che finisce la memoria. Il nodo si installa e gira comunque quando fallisce la build di una superficie; solo quel portale viene saltato, e rieseguire l’installazione la ritenta.
Il profilo da 4 GB fa girare il database, l’accesso, il REST, le edge function, il gateway, l’archiviazione e il realtime. Studio, l’analitica, il proxy delle immagini e il connection pooler sono spenti per impostazione predefinita.
Non devi installare Docker, Node.js o pnpm da solo. Il preflight dell’installazione lo fa, e configura il firewall per permettere le porte 22, 80 e 443.
Il dominio
Sezione intitolata “Il dominio”Un dominio che controlli per il nodo — node1.esempio.com, per dire — e la
possibilità di impostare un record A che punti all’IP pubblico della macchina.
Ogni superficie web che attivi ha bisogno del proprio record A a sua volta
(admin.node1.esempio.com, my.node1.esempio.com, e così via). L’installer
stampa ogni record di cui ha bisogno.
Il provider email
Sezione intitolata “Il provider email”Necessario per andare in produzione. Un solo provider SMTP porta tutta la posta del nodo: link di accesso, conferma di registrazione e ripristino password dal servizio di autenticazione, e inviti, notifiche e codici di verifica dalle edge function.
L’installer chiede host, porta, utente e password, verifica la configurazione rispetto al provider live prima di installare qualsiasi cosa, e offre di inviarti un messaggio di prova.
| Provider | Host | Porta | Utente | Password |
|---|---|---|---|---|
| Resend | smtp.resend.com | 465 | resend | la tua API key |
| Postmark | smtp.postmarkapp.com | 465 | server token | server token |
| Il tuo | secondo il provider | 465 | secondo il provider | secondo il provider |
Usa la porta 465, che è TLS implicito. Non è una preferenza. Sulla porta 587 il runtime delle function del nodo non completa l’upgrade STARTTLS. L’invio resta in attesa, va in timeout e fallisce, quindi inviti, notifiche e codici di verifica non escono.
Due controlli passano comunque, ed è questo che rende la cosa difficile da individuare. Il controllo dell’installazione usa un client di posta diverso e si connette sulla 587 senza problemi. I link di accesso e i ripristini password continuano ad arrivare, perché il servizio di accesso è un programma separato con un proprio client di posta — quindi inviarti un link di accesso, il test che il checklist chiede, riesce su un nodo la cui posta applicativa è rotta.
L’uscita sulla porta 25 è bloccata dalla maggior parte dei provider di hosting.
L’indirizzo del mittente deve essere un dominio verificato. Il nodo invia
come noreply@<home_server> per impostazione predefinita, e i provider
rifiutano qualsiasi invio da un dominio che non hanno verificato per SPF e DKIM.
Questo non è il tuo admin_email — quello è il tuo indirizzo di accesso e
contatto personale, e il suo dominio non è verificato. Se il tuo nodo è un
sottodominio su un account dove solo il dominio principale è verificato, imposta
smtp.sender_email sul dominio principale verificato. L’email di prova
all’installazione lo intercetta prima che tu vada in produzione.
Senza email, il nodo è quasi inerte. Gli utenti si uniscono tramite link di
invito legati a un’email, quindi un nodo che non può inviare posta non può
accogliere nessuno. L’installer forza anche ogni superficie di federazione a
spenta quando non è configurato alcun trasporto, e te lo dice. L’unico nodo che
gira legittimamente senza email è uno impostato su registration_mode: closed,
che non accetta affatto nuovi utenti. Le registrazioni non vengono mai
confermate automaticamente su un nodo.
Il software
Sezione intitolata “Il software”tc-operator gira da un albero sorgente completo. Ricevi da Trusted Codes
l’archivio di distribuzione dell’operatore — un tarball contenente l’intero
albero compilabile, senza cronologia del controllo versione e senza documenti
interni.
Se ti è stato dato un token di arruolamento, non recuperi affatto l’archivio a mano; l’installer in una riga lo fa per te e verifica il download rispetto al manifest di release firmato e pubblicato. Vedi Installare un nodo.
Che cosa non configuri
Sezione intitolata “Che cosa non configuri”La radice di fiducia della federazione — l’URL del registro centrale e la sua chiave pubblica radice — è incorporata nell’installer. È un unico valore per l’intera mesh, identico su ogni nodo, e non lo fornisci né lo cambi.
Ogni segreto specifico del nodo (il segreto JWT, le chiavi anon e service, la
password di Postgres, la chiave di cifratura, la chiave di firma della
federazione) viene generato per te in /etc/trusted-codes/secrets.env,
modalità 0600. Non copi mai un segreto a mano. L’unica eccezione è la tua
password SMTP, che metti in operator.yaml.
Una prova, se ne vuoi una
Sezione intitolata “Una prova, se ne vuoi una”Su una workstation Mac o Linux con Docker, puoi far girare l’intero flusso dei container senza alcun provisioning dell’host o TLS:
scripts/tc-operator/tc-operator install --local --config operator.yaml--local avvia il nodo su un progetto loopback isolato e salta del tutto apt,
il firewall, lo swapfile e il TLS. Smantellalo con
tc-operator uninstall --local --config operator.yaml --purge.