3.9 KiB
Executable File
3.9 KiB
Executable File
NetGescon – RUNBOOK (Linux)
Ambiente
- OS: Ubuntu (VM Proxmox) – host:
netgescon-master– IP:192.168.0.200 - Path progetto:
/home/michele/netgescon/netgescon-laravel - Shell: bash
- Repo: Gitea
http://192.168.0.200:3000/(ssh)
Obiettivo
- Questo file contiene i comandi e le procedure per ripartire velocemente dopo reboot/crash senza rispiegare tutto.
Avvio rapido (checklist)
- Vai nel progetto:
cd /home/michele/netgescon/netgescon-laravel - Verifica mount produzione (RO):
mount | egrep -i 'gescon-archives|cifs' || true - Avvia stack / servizi (scegli in base a come lo usi oggi):
- Docker:
docker compose up -d - Nginx/PHP-FPM:
sudo systemctl status nginx php8.3-fpm --no-pager - MySQL/MariaDB:
sudo systemctl status mysql --no-pager
- Docker:
- App Laravel:
php -v ; composer -Vphp artisan --version
- Avvio server (DEV):
- VS Code Task: "Start Laravel Server"
- CLI equivalente:
php artisan serve --host=0.0.0.0 --port=8000
VS Code / Prestazioni
- Workspace settings:
.vscode/settings.json(exclude watcher/search già impostati) - IMPORTANT: apri un workspace che punti direttamente a
netgescon-laravel.- OK:
Miki-Bug-workspace/NetGescon-Laravel.code-workspace - OK:
Miki-Bug-workspace/NetGescon-Development.code-workspace(ora allineato: non punta più alla cartella padre) - DA EVITARE: workspace che includono
/home/michele/netgescon(troppo grande → indicizzazione/estensioni possono inchiodare VS Code)
- OK:
- Nota: evitare di indicizzare
node_modules/,vendor/,storage/,bootstrap/cache/
Database (DEV/TEST)
- Dove gira il DB di test (scegli una sola verità):
- Local service:
mysql(systemd) oppure container docker
- Local service:
- Comandi utili:
- Stato:
sudo systemctl status mysql --no-pager - Connessione:
mysql -u <user> -p -h <host> <db>
- Stato:
Produzione (dati in sola lettura)
- Mount RO:
/mnt/gescon-archives(CIFS) - Scopo: leggere dati aggiornati per import/estrazioni
- Verifica rapida:
ls /mnt/gescon-archives | head
- Se la share non risponde, NON deve bloccare il boot (automount/timeout configurati)
Estrarre dati (procedura standard)
- Script/entrypoint da usare (scegli e mantieni 1 procedura):
./manage-database.sh <azione>- oppure
php artisan <comando>
- Esempi (riempi con quelli che usi davvero):
- Query/estrazione anagrafiche:
<TODO> - Import dati legacy:
<TODO> - Verifica integrità:
<TODO>
- Query/estrazione anagrafiche:
Stato attuale (da aggiornare dopo ogni sessione)
- Ultimo focus:
<es: fix X su modulo Y>
- Cose fatte:
<bullet>
- Cose da fare:
<bullet>
- Decisioni importanti:
<bullet>
“Se il sistema salta” (ripartenza)
-
- fsck solo se serve (initramfs), poi reboot
-
- controlla mount produzione
-
- avvia servizi/docker
-
- apri VS Code e riparti da “Stato attuale”
Continuità chat (anti-blocco contesto)
- La chat può comunque raggiungere un limite di contesto: non si elimina del tutto, ma si evita di perdere il filo con checkpoint brevi.
- Regola pratica: ogni blocco di lavoro importante aggiorna
docs/ai/SESSION_HANDOFF.mdcon:- obiettivo corrente,
- file toccati,
- comandi reali eseguiti + output sintetico,
- prossimo step immediato.
- Prompt di ripartenza standard:
Riparti da docs/ai/SESSION_HANDOFF.md e continua dal prossimo step senza rieseguire analisi generale.
Regola di utilizzo consigliata
- Evita chat infinite: usa 1 chat per argomento/capitolo.
- Apri una nuova chat quando:
- chiudi un blocco funzionale,
- cambi argomento,
- superi ~80-120 richieste,
- noti rallentamenti.
- Prima di cambiare chat, esegui sempre task:
AI: Continuity Auto (Safe).
Ripartenza veloce
- Esegui task:
AI: Restart Brief. - Fai leggere all'agent in ordine:
docs/ai/SESSION_HANDOFF.mddocs/ai/TOPICS_INDEX.mddocs/ai/LATEST_2_CHATS_RECOVERY.mddocs/ai/topics/<topic>.md
- Per guida completa:
docs/ai/START-HERE-AGENT.md