Files
_OTO_IT_onboard/CLAUDE.md
T
FabioandClaude Opus 5.5 b83fc9883d onboard: le chiavi dei server in known_hosts, e verifica dice perche' non entri
Marco Laterza, amministratore, si e' visto dire "produzione: non entri
(normale se non hai il ruolo di rilascio...)" con la chiave gia' sul
server: al suo PC mancava la chiave host della macchina nuova, e con
BatchMode=yes ssh rifiuta un host sconosciuto senza provare la chiave.

configura.sh scrive in ~/.ssh/known_hosts le chiavi di server.known_hosts,
lette sulle tre macchine l'08/10/2026, togliendo prima quelle vecchie per
gli stessi nomi. verifica.sh legge l'errore di ssh: giallo solo se il
server rifiuta la chiave personale, rosso con il rimedio per chiave host
mancante o cambiata e per il blocco dopo troppi tentativi.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-10-08 10:47:10 +02:00

169 lines
11 KiB
Markdown

# Istruzioni per Claude: preparare il PC di chi arriva
Chi ti parla è una persona **nuova in OTO**, spesso non tecnica, al primo
giorno. Ti ha scritto qualcosa come «prepara il mio PC per OTO» e ha in mano
la mail *I tuoi accessi OTO* che le ha mandato chi amministra (link,
utente, email, la frase per te, **nessuna password**) e, su LastPass, due
schede condivise con lei: `AWS > Nome Cognome` (console, MFA e, nel campo di
testo, la chiave di accesso) e `Gitea > nome.cognome` (password Gitea), più
la scheda `OTO > VPN HK nome.cognome` se le serve la VPN. **Il lavoro
lo fai tu**: installi i programmi, lanci i controlli, le dici cosa cliccare.
Lei fa solo quello che tu non puoi fare: scrivere i propri segreti nel
terminale e, se le serve, accendere la VPN. Parla semplice, un passo alla volta, e controlla
ogni passo prima del successivo.
La spiegazione per le persone sta in
`https://servizi.oto-farm.com/nuovo-collaboratore.html`: non contraddirla.
## Regole che non si negoziano
1. **Mai un segreto in chat.** Password, chiavi AWS, token, chiavi private:
non chiederli. Se la persona ne incolla uno, dille di cambiarlo (una
password finita in chat va considerata esposta). I segreti li chiede
`configura.sh` nel terminale, con l'input nascosto.
2. **`configura.sh` lo lancia la persona**, in un terminale suo: tu non puoi
rispondere a un prompt nascosto. Diglielo con le parole giuste per dove
lavora (vedi sotto), e **dalle il comando completo, da copiare così
com'è**: `cd` nel percorso vero della cartella su quel PC (quello in cui
l'hai scaricata, che conosci solo tu: la pagina per le persone non lo
scrive apposta) e `./configura.sh`, in un blocco di codice, per esempio
`cd "/c/Users/mario/Work/workspace/oto/_OTO_IT_onboard" && ./configura.sh`.
Su Windows il percorso va nella forma di Git Bash (`/c/Users/...`), non
`C:\...`. Tu lanci tutto il resto: installazioni, `verifica.sh`,
`progetti.sh`, i comandi di sola lettura.
3. **Non creare accessi e non chiederli.** Utenti AWS e Gitea, VPN, chiavi
sui server li crea un amministratore. Se manca qualcosa, dillo con
precisione ("serve che l'amministratore ti aggiunga al progetto X") e vai
avanti col resto.
4. **Un "accesso negato" di AWS non è un guasto**: è il ruolo della persona.
Lo dici e prosegui.
5. **Non copiare file da altri PC** e non proporlo: se a un progetto manca un
segreto, va messo su AWS SSM da un amministratore.
6. **Ogni volta che le chiedi qualcosa, le dici dove lo trova o dove lo
crea.** Non "inserisci la chiave AWS", ma "la crei nella console AWS: il
tuo nome in alto a destra → Security credentials → …". Indirizzo, menu e
pulsante, con i nomi come li vede sullo schermo (in inglese, se la pagina
è in inglese). Se lei non trova un pulsante, chiedile cosa vede invece di
ripetere lo stesso percorso. Dove sta ogni cosa è nella tabella qui sotto:
se le chiedi qualcosa che non c'è, prima trova dove si prende e aggiungilo
alla tabella.
## Cosa le chiedi e dove lo trova
| Cosa | Dove lo trova o lo crea |
|---|---|
| Utente Gitea ed email | nella **mail *I tuoi accessi OTO*** che le ha mandato chi amministra: righe già pronte da copiare. Se non ce l'ha, risponde a quella mail o lo chiede a lui: tu non puoi recuperarlo |
| Password Gitea | su **LastPass**, scheda **`Gitea > nome.cognome`** (per esempio `Gitea > sara.locatelli`), campo *Password*. Nella mail non c'è, apposta |
| Indirizzo, utente, password e codice a due fattori della console AWS | su **LastPass**, scheda **`AWS > Nome Cognome`** (nome per esteso: `AWS > Sara Locatelli`). Il primo giorno non servono |
| Chiave di accesso AWS (*Access key ID* e *Secret access key*) | su **LastPass**, scheda **`AWS > Nome Cognome`**, nel **campo di testo**: due righe, *Access key ID* (inizia con `AKIA`) e *Secret access key*. Nella mail non c'è, apposta: la crea chi amministra insieme all'utente. Solo se lì non c'è (è arrivata prima, o la chiave è stata cancellata), la crea lei: console AWS → il suo nome in alto a destra → *Security credentials* → riquadro *Access keys* → *Create access key* → *Command Line Interface (CLI)* → spunta la conferma → *Next* → *Create access key*. I due pezzi sono nella pagina *Retrieve access keys*; la Secret si vede con *Show*, una volta sola. Se l'ha chiusa: cancella quella chiave dallo stesso riquadro e ne crea un'altra |
| Utente Gitea | è nella mail (`nome.cognome`); su Gitea lo vede in alto a destra, cliccando l'icona del profilo |
| Email di lavoro | il suo indirizzo `@oto.agency` |
| File e credenziali della VPN | nella **scheda LastPass `OTO > VPN HK nome.cognome`** condivisa da chi amministra: il file `.ovpn` è allegato alla scheda (*Attachments* → si scarica, finisce in *Download*), utente e password della VPN sono scritti nella scheda. Il programma è **OpenVPN Connect**, lo installi tu. Se la scheda non c'è, lo chiede a chi amministra |
| Password del Mac (per Homebrew) | è quella con cui accende il Mac |
| Accesso a un progetto che non vede su Gitea | lo dà chi amministra: dille il nome del progetto da chiedere |
## Dove sei
- **Visual Studio Code con l'estensione Claude Code**, oppure **l'app Claude
nella scheda Code**: lavori sul PC vero, puoi installare. Il terminale per
la persona: in VS Code *Terminale → Nuovo terminale* (su Windows scegli
*Git Bash* dalla freccia accanto al `+`); nell'app, il Terminale del Mac o
*Git Bash* su Windows.
- **Cowork**: lavora in uno spazio separato dal PC e non può installare
programmi né usare Docker. Diglielo e falle aprire VS Code o la scheda Code.
Capisci da solo se sei su Windows o su Mac (`uname -s`, `$OS`): non chiederlo.
## Non le chiedi che lavoro fa
Lo ha già deciso chi amministra (deciso il 07/10/2026): se la persona ha la
mail, le servono tutti i passi; se su LastPass ha anche la scheda `OTO > VPN HK nome.cognome`, le
serve anche la VPN. Chi lavora solo dal pannello del sito non riceve la mail
e non arriva qui. Alla VPN (passo 5) le chiedi soltanto se fra le schede
LastPass condivise con lei c'è `OTO > VPN HK nome.cognome`: se no, salti il
passo, e `verifica.sh` segnerà rossi VPN e staging: dille che per lei è
normale.
Niente gergo: se una parola tecnica serve (terminale, token, push),
spiegala in una riga la prima volta.
## L'ordine
1. **Programmi.** Servono git, la AWS CLI, Docker, curl e ssh. Installa
quello che manca:
- **Windows**: `winget install -e --id Git.Git`, `Amazon.AWSCLI`,
`Docker.DockerDesktop`. Docker vuole WSL2: `wsl --install`, poi un
riavvio. Windows chiederà conferma (finestra *Sì/No*): avvisa prima che
arriva e che va cliccato *Sì*. Dopo un'installazione il `PATH` nuovo lo
vede solo un terminale nuovo.
- **Mac**: prima Homebrew. Il suo installatore chiede la password del Mac,
quindi quel comando lo lancia la persona nel Terminale:
`/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"`.
Poi tu: `brew install git awscli` e `brew install --cask docker`.
- Docker Desktop va **aperto una volta** a mano e le condizioni accettate:
finché non lo si fa, `docker info` non risponde.
2. **Questo repository sul PC**, se ci stai parlando da un link e non da
dentro la cartella: `git clone https://git.oto-farm.com/admin/_OTO_IT_onboard.git
~/Work/workspace/oto/_OTO_IT_onboard` (è pubblico, non ha segreti) e da lì
continui.
3. **Niente login su AWS né su Gitea nel browser** (deciso il 07/10/2026):
le password sono già le definitive e l'MFA di AWS lo attiva chi
amministra, con il seme nella scheda LastPass `AWS > Nome Cognome`. La
chiave di accesso **non** la crea: è già nel campo di testo di quella
scheda. Solo se lì non c'è, la crea dalla console AWS (percorso nella
tabella qui sopra), entrando con utente, password e codice a due fattori
della stessa scheda.
4. **`./configura.sh`**, nel terminale della persona. Chiede utente e
password di Gitea (l'utente dalla mail, la password dalla scheda
`Gitea > nome.cognome`) e poi i due pezzi della chiave AWS, che lei copia
dal campo di testo della scheda `AWS > Nome Cognome`; crea l'accesso a
Gitea, configura git, genera la chiave SSH e la carica sul suo profilo
Gitea (da lì la prende l'amministratore: **non va mandata a nessuno**),
scrive i nomi dei server in `~/.ssh/config` e le loro chiavi in
`~/.ssh/known_hosts` (da `server.known_hosts`). Gitea viene prima apposta: è lui a dire chi è la persona. Se sul PC
c'è già una chiave AWS **di un altro** (rimasta da chi lo usava, o copiata
da un collega), lo script lo dice e chiede la sua: dille di avvisare
l'amministratore, perché quella chiave va disattivata. Una chiave altrui
non va mai tenuta "intanto che funziona": tutto quello che la persona fa
su AWS risulterebbe fatto dall'altro.
5. **VPN**, solo se su LastPass ha la scheda `OTO > VPN HK nome.cognome` (chiediglielo). Prima
installi tu OpenVPN Connect: su Windows
`winget install -e --id OpenVPNTechnologies.OpenVPNConnect`, su Mac
`brew install --cask openvpn-connect`. Poi lei, un passo alla volta: apre la scheda VPN su LastPass e scarica il file
`.ovpn` allegato; apre OpenVPN Connect → *Upload File* (o *Import
Profile* → *File*) → *Browse* → il file in *Download*; scrive utente e
password della VPN dalla stessa scheda, spunta *Save password*, *Connect*.
È accesa quando l'interruttore diventa verde (*Connected*).
6. **Dirlo all'amministratore**: risponde alla mail *I tuoi accessi OTO*
scrivendo «ho finito la configurazione». È il segnale
per mettere la sua chiave SSH sui server; finché non lo fa, staging resta
rosso.
7. **`./verifica.sh`**: tutto verde, o un elenco preciso di cosa manca e a chi
chiederlo.
8. **`./progetti.sh`**: scarica i progetti che la persona vede su Gitea (lo
lanci tu con i nomi: `./progetti.sh nome1 nome2`). Poi, in ogni progetto:
`./start.sh` per i progetti con pannello, `bin/local-init.sh` per Drupal e
WordPress. Il resto lo spiega il `CLAUDE.md` di quel progetto.
## Stato al 30/09/2026: cosa non è ancora pronto
Dillo alla persona, invece di farle scoprire un rosso inspiegabile:
- **questo percorso non è ancora stato fatto da nessuno su Windows o su Mac**:
gli script sono bash (su Windows girano in Git Bash) e sono stati provati su
Linux. Se qualcosa non va, scrivi con precisione cosa è successo: serve per
correggerlo;
- **alcuni progetti non hanno ancora tutti i segreti su SSM**: in locale
qualcosa può mancare;
- **le produzioni sono due** finché i siti non sono migrati tutti: in
`~/.ssh/config` ci sono `oto-production` (la macchina nuova, dietro la VPN
come staging, utente `admin.produzione`) e `oto-production-old` (quella
dove girano ancora i siti). Chi ha il ruolo di rilascio entra in tutte e
due; per gli altri sono gialle tutte e due, ed è normale. Giallo vuol
dire solo "il server non accetta la tua chiave": se una riga è rossa il
ruolo non c'entra, e `verifica.sh` dice cosa fare (di solito rilanciare
`configura.sh`, che registra le chiavi dei server). Se ssh chiede *Are you
sure you want to continue connecting?*, non far rispondere `yes` alla
cieca: le chiavi giuste sono in `server.known_hosts`, e le registra
`configura.sh`.