- configura.sh e progetti.sh escono 1 se un passo non riesce (scrittura di
~/.ssh/config, chiave SSH, clone, chiave AWS), e lo dicono in rosso;
- git: per l'indirizzo di Gitea si usa solo il gestore "store", e un token
vecchio rimasto in ~/.git-credentials si sostituisce (prima si aggiungeva
solo se mancava: API buona e git clone rotto). verifica.sh chiede a git la
credenziale che userebbe davvero, invece di accontentarsi di un gestore
qualsiasi;
- AWS: la chiave si controlla PRIMA di salvarla, e deve essere l'utente della
persona nell'account di OTO (ARN completo, non solo il nome). Senza Gitea il
passo si salta e verifica.sh non da' piu' verde a una chiave qualsiasi.
Avviso se AWS_PROFILE o AWS_ACCESS_KEY_ID... fanno usare un'altra chiave;
- API di Gitea: codice HTTP controllato, "Gitea non risponde" distinto da
"token non valido", elenco dei progetti interrotto solo su una pagina vuota
vera; token passato a curl da stdin; JSON letto anche con gli spazi;
- progetti.sh: nomi confrontati in modo esatto, accetta organizzazione/nome
e dice quando un nome corto e' ambiguo;
- la chiave ~/.ssh/oto_ed25519 viene collegata anche ai nomi che cercano i
deploy dei progetti (oto_staging_ed25519, oto_production_ed25519): su un
PC preparato da qui il primo deploy si fermava con "Chiave privata non
trovata";
- verifica.sh --senza-vpn, per chi non ha la VPN: staging giallo e non rosso.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
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>
In ~/.ssh/config c'era solo oto-production-old. Adesso c'e' anche
oto-production (10.110.137.20, dietro VPN), con il suo utente
admin.produzione: l'utente non e' piu' uno solo per tutti i server.
verifica.sh controlla tutte e due le produzioni, un tentativo per macchina.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Regola nuova nel CLAUDE.md e tabella "cosa le chiedi e dove lo trova".
configura.sh dice da dove vengono utente e password Gitea, l'email e i
passi della console per la chiave AWS (AWS_CONSOLE in comune.sh);
verifica.sh rimanda a configura.sh invece che ad aws configure.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Sul PC di marco.laterza c'era la chiave AWS di fabio.riva: configura.sh la
trovava valida, scriveva "accesso AWS: fabio.riva" e non chiedeva la sua.
Tutto quello che la persona faceva su AWS sarebbe risultato fatto da un
altro.
Adesso Gitea viene prima di AWS, perche' e' lui (con la password) a dire
chi e' la persona. Se la chiave trovata e' di un altro, lo script lo dice,
chiede quella giusta e controlla che lo sia; verifica.sh segna rosso.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Chi arriva installa Claude e gli scrive una frase: i programmi li installa
l'assistente (winget o Homebrew). configura.sh chiede la password Gitea e
crea da solo il token, salva la chiave AWS senza aws configure e carica la
chiave SSH pubblica sul profilo Gitea, da dove la prende l'amministratore.
verifica.sh non usa piu' timeout, che sul Mac non c'e'. Il repository e'
pubblico: non ha segreti.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
configura.sh (token Gitea, git, chiave SSH, nomi dei server), verifica.sh
(verde/rosso per ogni accesso), progetti.sh (scarica i repository visibili),
e un CLAUDE.md che guida la persona senza chiederle mai un segreto in chat.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
