Files
_OTO_IT_onboard/CLAUDE.md
T
FabioandClaude Opus 5.5 70d723f613 onboard: niente console AWS il primo giorno, e il comando con il percorso vero
L'MFA lo attiva chi amministra, quindi la persona non entra ne' in AWS ne'
in Gitea dal browser. Per configura.sh Claude le da' il comando completo,
con il percorso della cartella su quel PC: la pagina non lo scrive.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-10-07 21:33:59 +02:00

156 lines
9.9 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,
utenti, password, la frase per te) e, su LastPass, la chiave AWS e, 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 |
|---|---|
| Indirizzo, utente e password di AWS e di Gitea | 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 |
| Chiave di accesso AWS (*Access key ID* e *Secret access key*) | in una **nota LastPass** condivisa da chi amministra (non nella mail, 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 | in una **nota LastPass** condivisa da chi amministra: il file `.ovpn` è allegato alla nota (*Attachments* → si scarica, finisce in *Download*), utente e password della VPN sono scritti nella nota. Il programma è **OpenVPN Connect**, lo installi tu. Se la nota 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 nota *VPN*, 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 note
LastPass condivise con lei ce n'è una che si chiama *VPN*: 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 nota LastPass. La chiave di accesso **non**
la crea: è già nella nota LastPass. Solo se lì non c'è, la crea dalla
console AWS (percorso nella tabella qui sopra), entrando con utente e
password della mail e il codice a due fattori della nota.
4. **`./configura.sh`**, nel terminale della persona. Chiede utente e
password di Gitea e poi i due pezzi della chiave AWS, che lei copia dal
la nota LastPass; 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`. 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 nota *VPN* (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 nota 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 nota, 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.