OPERAZIONI

Stato

Verificata in ricognizione su gpt; nessuna etichetta «superfluo» automatica.

Procedura riutilizzabile

Identificare la VPS; misurare df e du; elencare directory e file con ls e find limitati; individuare origine tramite script e systemd; classificare come live, backup, temporaneo, log o ignoto; controllare riferimenti e processi. Non cancellare sulla base del solo nome.

Comando di riferimento

du -x -h -d 1 /var/lib/mcl-dashboard | sort -h | tail -15

Caso reale / Limiti

Registro intervento: VPS, data, comando eseguito, situazione iniziale, risultato e verifiche successive. Non classificare un'operazione come riuscita senza prova.

Stato

Eseguita su gpt per due raccolte Discover con richiesta esplicita; non generalizzare a qualsiasi directory.

Procedura riutilizzabile

Richiedere istruzione esplicita; identificare host, percorsi e file da rimuovere; verificare assenza di processi in conflitto; controllare directory con ls/find; delimitare la cancellazione a pattern e percorsi precisi; eseguire soltanto con permessi autorizzati; ricontare i file e controllare df, servizi e siti. Se necessario effettuare una copia fuori server prima dell'eliminazione. Cancellazioni senza backup sono irreversibili.

Comando di riferimento

find /PERCORSO_BACKUP -maxdepth 1 -type f -name '*.sqlite' -delete

Caso reale / Limiti

Registro intervento: VPS, data, comando eseguito, situazione iniziale, risultato e verifiche successive. Non classificare un'operazione come riuscita senza prova.

Stato

Verificata in lettura su gpt.

Procedura riutilizzabile

Per ogni raccolta contare file/istantanee e dimensioni; esaminare un campione degli archivi senza esporre .env; leggere script generatori e registri; associare backup a dominio e server; non confondere database editoriali con copie CMS complete.

Comando di riferimento

du -x -h -d 2 /var/lib/mcl-discover-cms/_backups | sort -h | tail -25

Caso reale / Limiti

Registro intervento: VPS, data, comando eseguito, situazione iniziale, risultato e verifiche successive. Non classificare un'operazione come riuscita senza prova.

Stato

Verificata su gpt.

Procedura riutilizzabile

Esaminare systemctl list-timers --all e unit/service; leggere ExecStart, OnCalendar e sorgente; cercare funzioni di backup e retention; confrontare timestamp dei file con calendario; verificare ultimi esiti e log. Non disattivare alcuna automazione senza richiesta.

Comando di riferimento

systemctl cat mcl-discover-cms-backup.service mcl-discover-cms-backup.timer

Caso reale / Limiti

Registro intervento: VPS, data, comando eseguito, situazione iniziale, risultato e verifiche successive. Non classificare un'operazione come riuscita senza prova.

Stato

Disabilitazione verificata per mcl-discover-cms-backup.timer su gpt.

Procedura riutilizzabile

Identificare esattamente timer e servizio e dipendenze, leggere calendario e stato prima; eseguire soltanto la modifica richiesta; usare sudo systemctl disable --now TIMER per fermare e disabilitare; ricontrollare is-enabled e is-active; controllare che i timer non interessati restino attivi. Non confondere cron tradizionale con systemd timers.

Comando di riferimento

sudo systemctl disable --now mcl-discover-cms-backup.timer

Caso reale / Limiti

Registro intervento: VPS, data, comando eseguito, situazione iniziale, risultato e verifiche successive. Non classificare un'operazione come riuscita senza prova.

Stato

Verificata su gpt.

Procedura riutilizzabile

Usare systemctl is-active/is-enabled e systemctl status sui nomi esatti; consultare list-units --failed e log bounded con journalctl; controllare health HTTP ove pertinente; registrare separatamente stato e ultimo risultato del servizio, che possono divergere.

Comando di riferimento

systemctl is-active mcl-mcp.service

Caso reale / Limiti

Registro intervento: VPS, data, comando eseguito, situazione iniziale, risultato e verifiche successive. Non classificare un'operazione come riuscita senza prova.

Stato

Verificata per 8 siti Discover su gpt; non ancora generalizzata a ogni stack.

Procedura riutilizzabile

Controllare inventario MCL, vhost Nginx, proxy_pass o root, percorso effettivo di database e media, servizio applicativo; confrontare IP origin DNS, evitando di dedurre il server dagli IP proxy Cloudflare. Verificare che l'installazione sia attiva, non soltanto presente in backup.

Comando di riferimento

ls /etc/nginx/sites-enabled

Caso reale / Limiti

Registro intervento: VPS, data, comando eseguito, situazione iniziale, risultato e verifiche successive. Non classificare un'operazione come riuscita senza prova.

Stato

Verificata parzialmente su gpt dopo la pulizia.

Procedura riutilizzabile

Confrontare df prima/dopo e contare file; eseguire nginx -t; verificare stato MCP e timer richiesti; controllare homepage HTTPS e funzioni critiche; annotare verifiche non eseguite. Lo stato active del timer non prova che il job applicativo funzioni.

Comando di riferimento

df -h /; sudo nginx -t; systemctl is-active mcl-mcp.service

Caso reale / Limiti

Registro intervento: VPS, data, comando eseguito, situazione iniziale, risultato e verifiche successive. Non classificare un'operazione come riuscita senza prova.

Stato

Non certificata: identificati meccanismi, ma nessuna nuova retention attivata.

Procedura riutilizzabile

Per ciascun sito definire ultima copia integra e storage esterno, valutare dipendenze rollback, testare restore; configurare retention idempotente soltanto dopo salvataggio sicuro. Evitare di cancellare l'ultima copia funzionante.

Comando di riferimento

# Nessun comando di retention certificato

Caso reale / Limiti

Registro intervento: VPS, data, comando eseguito, situazione iniziale, risultato e verifiche successive. Non classificare un'operazione come riuscita senza prova.

Quando utilizzare la procedura

Richieste come «fammi vedere cosa contiene la VPS», «quali cartelle occupano più spazio?», «trova i backup», «che file ci sono nella cartella?» oppure «leggi la configurazione di questo servizio». L'operazione è di sola lettura: non cancellare, spostare o modificare nulla se l'utente chiede soltanto un'ispezione.

1 — Identificare il server e lo strumento corretto

1. Consultare server_inventory_registry.json e la matrice delle capacità per risolvere l'ID canonico della VPS.
2. Se il percorso è nel workspace /srv/mcl-workspace, preferire MCL_MCP_2026.list_files(path) e read_file(path), evitando shell superflua. read_file è limitato a 200 KB di testo UTF-8.
3. Per filesystem fuori dal workspace o su VPS remote, utilizzare il percorso diagnostico/amministrativo MCL già autorizzato per quella VPS, verificando prima identità e permessi. Non inventare accessi, non disabilitare SSH host-key checking.

2 — Comandi di ispezione utilizzati realmente

pwd
ls -lah /PERCORSO
find /PERCORSO -maxdepth 2 -type f
du -x -h -d 1 /PERCORSO
du -x -h -d 2 /PERCORSO | sort -h | tail -25
df -h /
df -i /
find /PERCORSO -maxdepth 1 -type f -name '*.sqlite' | wc -l

ls mostra file e permessi; find scopre percorsi e conta file; du stima l'occupazione delle directory; df misura la capacità del filesystem e degli inode. -x evita di attraversare altri filesystem. Per file testuali noti, leggere una sezione limitata con sed -n '1,100p' FILE oppure lo strumento MCP read_file, ove applicabile.

3 — Limiti e sicurezza

• Non stampare file .env, password, token, chiavi SSH, credenziali o dump di database contenenti dati personali.
• Non utilizzare scansioni ricorsive illimitate su directory enormi; limitare profondità, durata e righe di output.
• Non dedurre che una directory chiamata backups sia eliminabile: verificare funzione, processi che la scrivono, data e integrità delle copie.
• Se un comando fallisce per permessi o per controlli della piattaforma, classificarne l'errore e preferire operazioni MCP dedicate disponibili.
• Una lettura riuscita non certifica permessi di modifica o capacità di deployment.

4 — Caso reale: audit disco VPS gpt del 16/10/2026

Con gli stessi comandi abbiamo identificato un filesystem principale da 38 GB al 100%, circa 352 MB disponibili, e individuato le directory con maggiore occupazione:

Nel backup CMS di nwvicenza del 16/10 sono stati identificati cms.sqlite, media.tar.gz e instance.env tramite il solo elenco dei nomi; non è stato necessario leggere il contenuto riservato del file di configurazione.

5 — Risultato da consegnare

VPS identificata:
Directory analizzata:
Comandi o tool usati:
Dimensione e numero file:
File/cartelle principali:
Dati operativi / backup / temporanei:
Problemi o anomalie:
Limiti di accesso:
Modifiche eseguite: nessuna (sola lettura)
Prossimo intervento suggerito:

Stato e campo di applicazione

Verificata in lettura su gpt e mcl-clients, 16/10/2026.

Procedura operativa

Individuare server nel registro; usare fleet_server_diagnostics(server_id, health) se esposto oppure mcl_fleet_diagnostics.py con server_id canonico; leggere uptime, load, df -h / e free -m. Non interpretare RAM free senza available. Controllare soglie e registrare valori e data.

Comando o strumento realmente disponibile

python3 -B mcl_fleet_diagnostics.py gpt health

Evidenza / limitazioni

Chiusura obbligatoria: registrare server, data, file o servizio interessato, risultato, prova della verifica e rollback previsto. Non attribuire certificazione completa a test soltanto parziali.

Stato e campo di applicazione

Verificato il collegamento preesistente a verticali-vps-1; non testato provisioning ex novo.

Procedura operativa

Identificare VPS e IP nell'inventario e identificare chiave client autorizzata; configurare alias SSH con utente corretto e known_hosts verificato; controllare StrictHostKeyChecking=yes; eseguire diagnostica identity e health; aggiornare matrice capacità solo dopo il test; differenziare connettività e permessi amministrativi.

Comando o strumento realmente disponibile

python3 -B mcl_fleet_diagnostics.py verticali-vps-1 identity

Evidenza / limitazioni

Chiusura obbligatoria: registrare server, data, file o servizio interessato, risultato, prova della verifica e rollback previsto. Non attribuire certificazione completa a test soltanto parziali.

Stato e campo di applicazione

Correzione di configurazione testata su verticali-vps-1.

Procedura operativa

Leggere la configurazione SSH esistente e il registro, salvare backup prima della modifica; non disabilitare il controllo host key; correggere solo l'alias interessato; verificare utente e UID in sessione separata; verificare sudo solo dove necessario, senza esporre segreti. Non sostituire chiavi private.

Comando o strumento realmente disponibile

ssh -F /var/lib/mcl-mcp/.ssh/config -o StrictHostKeyChecking=yes -o UserKnownHostsFile=/var/lib/mcl-mcp/.ssh/known_hosts root@91.99.0.230 'hostname; id -u'

Evidenza / limitazioni

Chiusura obbligatoria: registrare server, data, file o servizio interessato, risultato, prova della verifica e rollback previsto. Non attribuire certificazione completa a test soltanto parziali.

Stato e campo di applicazione

Creazione e configurazione di guida-mcp.mclmedia.eu verificate.

Procedura operativa

Identificare VPS e vhost effettivo; backup config; preparare file dedicato con server_name, root/proxy e listener IPv4/IPv6 appropriati; collegare a sites-enabled; validare nginx -t; ricaricare soltanto se valido; testare Host, redirect e risposta HTTPS. Evitare conflitti sui server_name.

Comando o strumento realmente disponibile

sudo -n nginx -t

Evidenza / limitazioni

Chiusura obbligatoria: registrare server, data, file o servizio interessato, risultato, prova della verifica e rollback previsto. Non attribuire certificazione completa a test soltanto parziali.

Stato e campo di applicazione

Emissione certificato e timer di rinnovo verificati; rinnovo futuro non ancora testato.

Procedura operativa

Prima verifica DNS e HTTP challenge, poi certbot certonly --webroot secondo il vhost; configura 443 con fullchain e privkey corretti; nginx -t, reload; curl HTTPS con verifica TLS attiva e test IPv4/IPv6; controlla certbot certificates e timer. Non considerare un timer attivo prova del rinnovo.

Comando o strumento realmente disponibile

sudo -n certbot certificates

Evidenza / limitazioni

Chiusura obbligatoria: registrare server, data, file o servizio interessato, risultato, prova della verifica e rollback previsto. Non attribuire certificazione completa a test soltanto parziali.

Stato e campo di applicazione

Test tecnici verificati sulla guida MCP; collaudo visivo completo non attestato.

Procedura operativa

Controllare URL e host, HTTP->HTTPS, certificato, risposta 200, contenuto corretto, funzionalità richieste, HTML bilanciato, mobile/desktop con browser se disponibile, JS ed errori console, log, regressioni. Registrare verifiche mancanti. Un 200 non certifica grafica o business logic.

Comando o strumento realmente disponibile

curl -4 -I https://guida-mcp.mclmedia.eu/operazioni/

Evidenza / limitazioni

Chiusura obbligatoria: registrare server, data, file o servizio interessato, risultato, prova della verifica e rollback previsto. Non attribuire certificazione completa a test soltanto parziali.

Stato e campo di applicazione

Ripristino HTTP FarmacieOra confermato il 16/10/2026; la causa e la modifica specifica del precedente errore 500 non sono state ricostruite con evidenze sufficienti.

Procedura operativa

Riprodurre errore e annotare URL/status; verificare DNS origin, Nginx error/access log, upstream service, PHP/Python, database e permessi in sola lettura; effettuare backup e correggere una causa dimostrata; testare endpoint e log; rollback in caso di regressione. Non riavviare servizi o cambiare permessi alla cieca.

Comando o strumento realmente disponibile

curl -I https://DOMINIO/

Evidenza / limitazioni

Chiusura obbligatoria: registrare server, data, file o servizio interessato, risultato, prova della verifica e rollback previsto. Non attribuire certificazione completa a test soltanto parziali.

Quando utilizzare questa operazione

Per aggiungere, modificare, verificare o rimuovere record DNS in una zona Cloudflare già gestita da MCL. Non confondere questa procedura con il cambio dei nameserver presso OVH: quello è un runbook separato.

1. Controllo preliminare: identificare la zona esatta

1. Controllare il dominio richiesto e l'IP o destinazione effettiva tramite l'inventario MCL.
2. Richiamare integrations.cloudflare_find_zone(ZONA) e selezionare esclusivamente la zona il cui campo name corrisponde al nome atteso.
3. Leggere i record attuali con integrations.cloudflare_request("GET", "/zones/{zone_id}/dns_records?name=HOST&per_page=100").
4. Prima di qualsiasi scrittura salvare tipo, nome, valore, TTL, proxy e ID del record esistente, per consentire l'eventuale ripristino.

2. Comportamento standard delle modifiche

I record A puntano a indirizzi IPv4, AAAA a IPv6, CNAME a hostname. Per proxied=true Cloudflare mostra ai resolver i suoi IP anziché necessariamente l'IP origin. Impostare il proxy secondo i requisiti del servizio; non applicarlo indiscriminatamente ai record usati per posta o verifiche.

3. File realmente utilizzati

/srv/mcl-workspace/guida_mcp_dns_setup.py
/srv/mcl-workspace/guida_mcp_dns_disable_ipv6.py
/srv/mcl-workspace/tmp/setup_farmacieora_cloudflare.py
/srv/mcl-workspace/mcl_dns_records_readonly.py

I primi tre sono script storici che contengono nomi host o valori fissi. Non riutilizzarli per altri domini così come sono. L'ultimo è uno script di sola lettura creato e testato il 16/10/2026 e controlla esattamente i tre hostname usati nei casi di esempio.

python3 -B mcl_dns_records_readonly.py

4. Risultati verificati

Su guida-mcp.mclmedia.eu era stato creato anche AAAA verso 2a01:4f8:1c1c:1148::1, poi rimosso dopo un errore TLS su IPv6. La lettura API attuale conferma che tale AAAA è assente. L'eliminazione è tracciata nel file guida_mcp_dns_disable_ipv6.py.

5. Verifica e rollback

1. Controllare che l'API restituisca success=true e che la rilettura del record restituisca i parametri voluti.
2. Eseguire dig verso resolver indipendenti. Per i record proxati confrontare le risposte tenendo conto del proxy Cloudflare.
3. Testare il servizio finale via HTTP/HTTPS, IPv4 e se applicabile IPv6, senza disattivare le verifiche TLS.
4. Se l'intervento provoca regressioni, ripristinare il record precedente utilizzando i valori salvati, quindi ricontrollare API e comportamento del sito.

Precauzioni

• Non eliminare o sostituire record TXT/MX/SPF/DKIM/DMARC senza analizzare i servizi email interessati.
• Non aggiungere record AAAA senza confermare il virtual host e il certificato sul percorso IPv6.
• Non sovrascrivere record esistenti solo perché uno script storico contiene valori diversi.
• Non dichiarare «sito operativo» dalla sola riuscita di una modifica DNS: eseguire sempre QA applicativo.

Stato: lettura A/CNAME e ciclo storico creazione/rimozione A/AAAA/CNAME verificati sui casi indicati. I record TXT di verifica Google sono stati letti e verificati in un caso reale, weloveveneto.it, senza modificarli. La procedura di creazione TXT è già implementata nell’onboarding Search Console MCL, ma non è stata eseguita in questa sessione. La configurazione MX resta da certificare su un caso dedicato.

Procedura operativa verificata

Quando utilizzarla

Quando un dominio è già registrato presso OVH e deve utilizzare i nameserver di una zona Cloudflare dell'account MCL. Per un sottodominio della zona mclmedia.eu non serve modificare la delega OVH: si devono creare soltanto i record DNS della zona già esistente.

1 — Leggere la zona, senza modificare nulla

1. Usare integrations.cloudflare_find_zone(DOMINIO): verificare se la zona esiste; se manca, utilizzare cloudflare_create_zone soltanto dopo aver confermato l'account e la richiesta.
2. Leggere result.name_servers dalla zona effettiva. Non riutilizzare automaticamente i nameserver di FarmacieOra: le assegnazioni possono variare per zona.
3. Usare integrations.ovh_request("GET", "/domain/DOMINIO") per verificare proprietà e nameserver attuali, senza esporre dati riservati.

2 — Impostare la delega OVH

La funzione operativa utilizzata nel caso reale è integrations.ovh_set_cloudflare_nameservers(domain, nameservers). Passare il dominio esatto e l'elenco di nameserver restituito da Cloudflare per quella zona. Salvare l'ID dell'eventuale task OVH. Eseguire la modifica una sola volta; se la risposta è incerta, leggere lo stato prima di riprovare.

import integrations as i
domain = "DOMINIO_DA_CONFIGURARE"
status, zone_response = i.cloudflare_find_zone(domain)
# Validare HTTP 200 e selezionare la zona che ha name == domain.
# Leggere zone["name_servers"]; non hardcodare valori storici.
# Solo per dominio approvato e delega non già coerente:
# status, result = i.ovh_set_cloudflare_nameservers(domain, nameservers)

3 — Verificare il task e la delega

Controllare GET /domain/DOMINIO/task/TASK_ID via ovh_request fino a stato done, senza ripetere la mutazione. Verificare poi che la zona Cloudflare sia active e che i nameserver corrispondano.

Script riutilizzabile appena creato e testato: /srv/mcl-workspace/mcl_nameserver_verify.py.

python3 -B mcl_nameserver_verify.py farmacieora.it
python3 -B mcl_nameserver_verify.py farmacieora.com

Lo script confronta nameserver OVH, Cloudflare e risposte dei resolver 1.1.1.1 / 8.8.8.8. Restituisce "consistent": true solo quando sono tutti allineati e Cloudflare è attivo. È di sola lettura: non acquista domini, non modifica la delega e non cambia record DNS.

4 — Prova reale del 16 ottobre 2026

I nomi completi rilevati sono jaxson.ns.cloudflare.com e ulla.ns.cloudflare.com. I file storici di modifica sono tmp/set_farmacieora_ovh_ns.py e tmp/check_farmacieora_progress.py: non eseguirli per altri domini, perché contengono valori fissi.

Prevenzione degli errori

• Non confondere nameserver (delega della zona) con record A, AAAA, CNAME e TXT.
• Non fare modifiche se la delega OVH è già corretta.
• Non utilizzare nameserver copiati da altri domini senza leggere la zona di destinazione.
• Non dichiarare conclusa la configurazione soltanto per una risposta HTTP 200 alla richiesta di modifica: controllare task, Cloudflare e DNS.
• Se la propagazione è incompleta, distinguere cache DNS e fallimento effettivo del task OVH.

Criterio di certificazione: task completato, delega coerente presso registrar, zona Cloudflare attiva e verifiche DNS riuscite. La disponibilità del sito web e il TLS si verificano con una procedura separata.

Scopo

Recuperare l'inventario delle VPS e identificare senza supposizioni server, ruolo, stato del collegamento e limiti amministrativi.

Sequenza collaudata

1. Consultare Organizzazione → Server come vista umana, controllando la data dello snapshot.
2. Leggere con il tool MCL_MCP_2026.read_file il registro server_inventory_registry.json per gli identificativi canonici; in alternativa leggere organizzazione_capability_matrix.json per le capacità già certificate.
3. Distinguere inventario provider, accesso SSH, lettura, sudo, modifiche di produzione e rollback. Una VPS censita non è necessariamente amministrabile.
4. Per un controllo aggiornato utilizzare la diagnostica dedicata fleet_server_capabilities e fleet_server_diagnostics se esposte nel catalogo ChatGPT. Se non sono disponibili, usare il canary già presente, senza inventare strumenti.
5. Indicare all'utente il server individuato e il livello reale di accesso prima di qualsiasi modifica.

Registro: /srv/mcl-workspace/server_inventory_registry.json
Capacità: /srv/mcl-workspace/organizzazione_capability_matrix.json
Canary: python3 -B mcl_mcp_live_canary.py
Output canary: mcl_mcp_live_canary_latest.json

Verifica effettuata il 16/10/2026: 24 server nello snapshot capacità del 11/10; test di identità riuscito per 7 server su 8 selezionati. Non confondere questi numeri con disponibilità live dell'intera flotta.

Perché è una procedura distinta

Un IP noto o un record DNS non dimostrano che MCL possa intervenire nella VPS. Questo controllo è obbligatorio prima di installare, migrare o correggere un sito.

Diagnostica

1. Confermare l'ID server nel registro canonico e consultare la matrice delle capacità.
2. Verificare l'identità remota tramite fleet_server_diagnostics(server_id, "identity") se lo strumento è disponibile; altrimenti l'implementazione già esistente mcl_fleet_diagnostics.py SERVER_ID identity tramite percorso MCP autorizzato.
3. Eseguire i controlli health, services e cron secondo le necessità e registrare data ed esito.
4. Verificare separatamente permessi di scrittura, sudo e capacità di effettuare rollback; senza tali test non dichiarare possibile un deploy produttivo.
5. Quando SSH segnala host key ignota, verificare la fingerprint con una fonte indipendente attendibile; mai disabilitare StrictHostKeyChecking.

python3 -B mcl_fleet_diagnostics.py mcl-clients identity
python3 -B mcl_fleet_diagnostics.py mcl-clients health
python3 -B mcl_fleet_diagnostics.py mcl-clients services

Stato: diagnostica di lettura verificata su sette server prioritari; provisioning produttivo su tutti gli host non ancora certificato.

Obiettivo e prerequisiti

Portare un dominio già registrato su una VPS MCL esistente, evitando di confondere acquisto, DNS, caricamento file e pubblicazione. Questa procedura è un runbook di riferimento: i singoli comandi di deployment cambiano con lo stack (Nginx/PHP/WordPress/MCL Engine) e devono essere verificati sulla VPS scelta.

Sequenza corretta

1. Identificazione: ricavare la VPS dal progetto e da Organizzazione, non dalla risoluzione DNS proxata Cloudflare.
2. Preflight: verificare identità SSH, host key, spazio disco, servizi web, vhost già esistenti, permessi e possibilità di rollback.
3. Backup: salvare configurazioni/file che verranno modificati; evitare sovrascritture non necessarie.
4. Installazione: creare cartella e applicazione, configurare un virtual host specifico, collegare eventuale runtime e database usando le procedure già certificate per quella VPS.
5. DNS: utilizzare l'integrazione integrations.cloudflare_request per zona e record; eventuale delega dei nameserver presso OVH è un passaggio distinto. Usare IP origin verificato e non aggiungere AAAA senza verifica IPv6.
6. SSL: attivare certificato valido per l'hostname tramite metodo supportato dal web server.
7. QA: test configurazione web server, HTTP → HTTPS, risposta 200, certificato, contenuto, permessi, log e verifica esterna. Se non funziona, rollback circoscritto.
8. Registro: annotare quali strumenti sono stati effettivamente usati e quali passaggi restano da certificare.

Caso FarmacieOra

farmacieora.it è stato configurato con origin 91.99.0.230 (verticali-vps-1) e DNS Cloudflare. File rilevanti nel workspace: tmp/setup_farmacieora_cloudflare.py, tmp/set_farmacieora_ovh_ns.py, tmp/farmacieora_health.py. Questi file non costituiscono un installer universale e non vanno lanciati per altri domini senza adeguamento e revisione.

Criterio di successo

Registrazione e DNS verificati, virtual host valido, certificato TLS corretto, pagina/applicazione richiesta funzionante, controlli registrati e rollback disponibile. Fino ad allora stato PARZIALE, mai «100%».

Obiettivo e caso verificato

Registrare un nuovo dominio per MCL usando l'integrazione OVH già presente nel workspace, senza confondere acquisto, delega DNS e installazione del sito. Caso verificato il 16 ottobre 2026: registrazione di farmacieora.it e farmacieora.com, ordine OVH 261268555, stato delivered. Per entrambi, API OVH GET /domain/{domain} ha restituito HTTP 200 con scadenza 16/10/2027. Il totale ordine riportato da OVH è € 13,40 IVA inclusa; non equivale a un prezzo garantito per acquisti futuri.

Passo 1 — Preflight e autorizzazione

1. Controllare la forma esatta del dominio e l'eventuale necessità di acquistare più estensioni.
2. Interrogare OVH per disponibilità, offerte, prezzi, durata e requisiti registrativi specifici del TLD.
3. Identificare l'account OVH autorizzato e verificare il profilo intestatario prima del checkout.
4. Comunicare costo totale, rinnovo e condizioni applicabili e ottenere autorizzazione per l'acquisto a pagamento. Non eseguire checkout per semplice richiesta di verifica.

Passo 2 — Creazione carrello OVH

File effettivamente utilizzato per preparare l'ordine: /srv/mcl-workspace/tmp/prepare_farmacieora_domains.py. Esso usa integrations.ovh_request e le API:

POST /order/cart                    # ovhSubsidiary: IT
GET  /order/cart/{cart_id}/domain?domain=DOMINIO
POST /order/cart/{cart_id}/domain  # offerId, duration, quantity
POST /order/cart/{cart_id}/item/{item_id}/configuration
POST /order/cart/{cart_id}/assign
GET  /order/cart/{cart_id}/checkout

Per domini .it, verificare e compilare le dichiarazioni richieste dal registrar secondo il profilo dell'intestatario. Nel caso reale sono state inviate configurazioni con etichette IT_SECT3_OTHER, IT_SECT4_OTHER e IT_SECT5_OTHER. Non copiare ciecamente le dichiarazioni legali per un altro intestatario.

Passo 3 — Checkout e pagamento

Il carrello preparato non significa acquisto completato. Richiedere il checkout aggiornato e procedere tramite il percorso di pagamento OVH esplicitamente autorizzato per quell'ordine. Registrare soltanto ID ordine, totale, data e stato, mai token di pagamento, password ordine o URL con segreti. Non ritentare il pagamento se lo stato è incerto: interrogare prima l'ordine esistente per evitare acquisti duplicati.

Passo 4 — Certificare la registrazione

File effettivamente utilizzati: tmp/check_farmacieora_order_status.py e tmp/verify_farmacieora_domains_active.py. Endpoint di verifica:

GET /me/order/{order_id}/status
GET /me/order/{order_id}/details
GET /domain/{domain}

La registrazione è VERIFICATA soltanto quando l'ordine risulta consegnato e ogni dominio richiesto è presente nel registrar con una scadenza reale. Salvare prova del riscontro con data e ora, senza dati personali o credenziali.

Passo 5 — DNS e hosting: procedura separata

Solo dopo la registrazione: creare/verificare la zona Cloudflare e delegare i nameserver da OVH con la procedura autorizzata. Nel caso FarmacieOra i riferimenti sono tmp/setup_farmacieora_cloudflare.py e tmp/set_farmacieora_ovh_ns.py. I nameserver previsti erano jaxson.ns.cloudflare.com e ulla.ns.cloudflare.com; per un nuovo dominio leggere sempre quelli della zona effettiva. Configurare poi record DNS e hosting con runbook distinti.

Errori da prevenire

• Non scambiare carrello creato per dominio acquistato.
• Non acquistare automaticamente altre estensioni non autorizzate.
• Non fidarsi di un solo check WHOIS durante la propagazione: usare API OVH e ordine.
• Non ripetere il checkout in caso di timeout senza ricontrollare l'ordine.
• Non esporre ID di pagamento segreti, URL con password o token nei log della guida.
• Non considerare il dominio online fino alla verifica indipendente di DNS, TLS e sito.

Registro caso FarmacieOra · 16/10/2026

Obiettivo

Controllare se un dominio è già presente in Google Search Console, oppure attivare le proprietà Dominio e URL canonica tramite il service account assegnato, configurando il TXT DNS su Cloudflare solo quando necessario. Evitare proprietà o token duplicati.

Passo 1 — Individuare l'account di servizio canonico

1. Leggere il registro /srv/mcl-workspace/gsc_site_account_registry.json e l'inventario degli account, senza esporre chiavi private.
2. Se il dominio ha già un account canonico, non assegnarne uno diverso arbitrariamente.
3. Per i nuovi siti Discover, consultare il runner discover_gsc_onboard.py, che usa l'account MCL Main quando previsto e preserva eventuali assegnazioni preesistenti.

Passo 2 — Verificare prima di scrivere

Utilizzare GSCReader di p4_gsc_reader.py e le API GET https://www.googleapis.com/webmasters/v3/sites/{property} per entrambe le proprietà. Un HTTP 200 con siteOwner oppure siteFullUser conferma l'accesso di lettura/gestione appropriato; il livello di permessi effettivo va considerato per ogni azione.

Controllo effettivamente eseguito: python3 -B weloveveneto_gsc_verify_20261016.py. Non effettuare onboarding se entrambe le proprietà risultano già verificate e correttamente assegnate.

Passo 3 — Solo se assente: TXT di verifica Cloudflare

1. Richiedere tramite gsc_integration.dns_token(domain) il token di verifica per la proprietà Dominio.
2. Controllare la zona Cloudflare corrispondente e cercare l'esatto TXT già presente.
3. Se manca, creare il record TXT con integrations.cloudflare_request("POST", ...) senza cancellare gli altri TXT esistenti.
4. Richiamare gsc_integration.verify_domain(domain) e verificare la risposta di Google.
5. Registrare le proprietà con gsc_integration.add_site(site_url) solo se necessario; verificare nuovamente i permessi tramite API.

La funzione già presente gsc_integration.verify_domain_via_cloudflare(domain) implementa questo flusso e viene usata da discover_gsc_onboard.py. Prima di riutilizzarla verificare proprietà, account previsto e compatibilità con lo stato del dominio.

Passo 4 — Registrazione canonica e verifica finale

1. Confermare via Google le proprietà sc-domain:DOMINIO e https://DOMINIO/ o la URL canonica effettiva, con permessi previsti.
2. Aggiornare gsc_site_account_registry.json tramite la procedura protetta da lock dell'onboarding, mai sovrascrivendo una selezione canonica già verificata.
3. Controllare lo stato nel sistema Discover e distinguere collegamento verificato da disponibilità effettiva di dati SEO, che può richiedere tempo.

Risultati verificati su weloveveneto.it

Riferimenti esistenti: gsc_integration.py, discover_gsc_onboard.py, p4_gsc_reader.py, gsc_site_account_registry.json. File del test reale: weloveveneto_gsc_verify_20261016.py e weloveveneto_txt_audit_20261016.py.

Classificazione: verifica di proprietà già esistenti certificata su weloveveneto.it; il provisioning TXT e l'aggiunta di nuove proprietà risultano implementati nelle procedure MCL esistenti, ma non sono stati rieseguiti su questo dominio già verificato.

Quando applicare questa procedura

Richieste come «modifica questa pagina», «sistema il menu», «migliora la grafica», «rendi perfetta la pagina», «sistema desktop e mobile». Prima di intervenire definire il risultato richiesto e individuare il progetto corretto: non modificare altri siti o componenti.

1 — Identificare la pagina reale

1. Individuare dominio, server, documento o template effettivamente distribuito consultando Organizzazione e il progetto MCL.
2. Leggere l'implementazione corrente con read_file se nel workspace oppure con una procedura amministrativa autorizzata della VPS corretta.
3. Verificare eventuali template condivisi, componenti, CSS, JS, dipendenze e differenze per lingua; distinguere sorgente, build e file pubblicato.
4. Se l'utente ha indicato un problema specifico, riprodurlo prima della correzione, con evidenza dello stato iniziale.

2 — Proteggere lo stato esistente

Salvare una copia datata del file o della release prima di sovrascrivere. Per applicazioni con build eseguire backup della versione pubblicata e predisporre un rollback. Evitare modifiche globali a CSS o navigazione senza controllare le altre pagine interessate.

3 — Applicare modifiche circoscritte

1. Correggere il problema funzionale o strutturale prima dei ritocchi estetici.
2. Usare gerarchie chiare, spaziatura coerente, contrasto leggibile, layout responsive e componenti uniformi.
3. Controllare che menu, schede espandibili, pulsanti, link e selettori di lingua funzionino davvero.
4. Non aggiungere elementi non richiesti, ad esempio selettori di lingua duplicati; non alterare contenuto editoriale o SEO senza necessità.
5. Non introdurre chiavi, password o dati riservati nell'HTML, JavaScript o nei log.

4 — Validazione obbligatoria

1. Controllare la struttura HTML: tag bilanciati, categorie annidate correttamente, ID univoci; verificare CSS e assenza di overflow.
2. Verificare desktop e mobile con browser o screenshot quando lo strumento è disponibile. Se la verifica visuale non è possibile, dichiararlo: HTTP 200 non dimostra un layout corretto.
3. Verificare gli stati interattivi: apertura/chiusura, focus da tastiera, link e menu.
4. Controllare il sito online, risposta HTTP/HTTPS, testi, redirect e regressioni su pagine collegate.
5. Se un controllo fallisce, correggere oppure eseguire rollback; non dichiarare «perfetto» senza QA visivo e funzionale.

5 — Caso realmente risolto: pagina OPERAZIONI

Il 16/10/2026 la sezione «SEO, Analytics e Search Console» appariva fuori dal contenitore principale. Causa: tag HTML chiusi nel punto sbagliato e una sezione introduttiva non chiusa correttamente. È stata corretta la struttura del file /srv/mcl-workspace/guida_mcp_operazioni.html, pubblicata in /var/www/guida-mcp.mclmedia.eu/operazioni/index.html e controllata con un parser HTML Python, verificando categorie all'interno di main, tag bilanciati e schede details chiuse inizialmente. L'endpoint HTTPS ha restituito 200.

6 — Scheda di chiusura intervento

Dominio / URL:
Server e file sorgente:
Problema osservato:
Backup / rollback:
Modifica effettuata:
Test struttura / JS / CSS:
Test desktop e mobile:
Test navigazione e contenuto:
HTTP/HTTPS e risultato:
Eventuali verifiche non svolte:
Esito: VERIFICATO / PARZIALE / BLOCCATO

Regola per l'assistente: usare la procedura ogni volta che viene chiesta una modifica di layout. Non limitarsi a cambiare CSS: identificare, correggere, pubblicare e verificare il risultato effettivo.