VRP - Catalogo dei Database

Stato: 2026-07-10. Elenco di TUTTI i database della piattaforma: tabelle,

scopo, credenziali, migrazioni, + accesso CLI e utenti del server. Modello di

riferimento in VRP_B200_architettura. Un solo

server MariaDB.

Regola d'oro

• Identita' (utenti + sessione) = UN DB condiviso: vrp_auth.
• Contenuti = un DB per servizio (federati). I JOIN cross-DB restano

possibili (stesso server).

• Per vedere TUTTI i database e per scrivere/DDL serve root (con la sua

password, in cassaforte): l'utente di default della CLI (vv_backup via

~/.my.cnf) e' in sola-lettura e vede solo photo e vittrosviaggi.

Dettagli in "Accesso da riga di comando (CLI)" e "Utenti del server MariaDB".

I database

vrp_auth [ESISTE - identita' condivisa + sessioni/azioni]

Identita' unica di piattaforma (login UNICO) + ruoli per-servizio + registro

accessi/azioni. Letto via vrp_db('vrp_auth'). Tabelle e vista:

• users (8 righe) - anagrafica dell'identita' unica (una persona = una riga).

id [PK], username [UNIQUE], email, pass_hash (password_hash), display_name,

avatar, is_active (0=disattivato), created_at, last_login_at. Letta da

vrp_login/vrp_current_user.

• user_services (23 righe) - la mappa "chi puo' cosa": il RUOLO dell'utente in

ogni servizio. user_id+service [PK composta], role (es. admin/editor/viewer/

registrato/amik_nat), granted_at. Un utente ha piu' righe (una per servizio).

Letta da vrp_current_user -> roles[service]=role.

• sessions (registro del portinaio E registro-azioni, opzione A) - id [PK],

php_sid, user_id [FK->users.id, NULL=ospite], ip, user_agent, service,

version, action, detail, started_at, last_activity, ended_at.

Due tipi di riga: (1) CICLO-SESSIONE action in login/logout/timeout, la riga viva

si aggiorna via UPDATE (vrp_login/vrp_logout/vrp_session_check); (2) EVENTO

(azione utente) action in upload/download/delete/create_dir/... con detail umano

("caricato il file X"), INSERT nuova via vrp_insert_action (lib vrp_action.php).

• vista sessions_h - sessions LEFT JOIN users -> aggiunge username e

display_name leggibili. La legge la pagina Admin Sessioni (pages/sessioni.php,

filtri username/action, colonne configurabili incl. detail). Suffisso _h=vista umana.

• Creds: vittrosviaggi_shared/secrets/db_vrp_auth.php (utente app vrp_auth_app, solo

SELECT/INSERT/UPDATE/DELETE -> le DDL le lancia root).

vittrosviaggi [ESISTE - VRV, diario]

Contenuti del diario. Tabelle principali:

• post, post_drafts, post_versions, post_translations, post_trad_cache
• post_foto (link post<->foto, oggi VUOTA), foto (stub, 2 righe)
• categorie, configurazione, last_conf, vv_last_versions
• utenti, utenti_h, user_history (utenti VRV -> confluiscono in vrp_auth)
• richieste_accesso
• share_dirs, share_files (contenuti del servizio Share/vrs; vivono QUI)
• viste: vw_post_effective, vw_post_effective_public, vw_post_effective_staff
• Registrato nella piattaforma come DB vrv (env.json) -> letto da vrp_db('vrv').
• Creds: vittrosviaggi_shared/secrets/db_vrv.php (utente vviaggi_app, posto STABILE

fuori dai release). Il VRV storico usa ancora meta/secrets.local.json.

lenostre [ESISTE - indice foto, 35.022 righe]

Indice delle foto dell'archivio leNostre.

• foto: id, path (unique), cartella, nome, anw (flag naturista),

larghezza, altezza, orientation, lat, lon, scattata_il, bytes,

mtime, hash_md5, indicizzata_il.

• Mantenuto da wiz_foto/lenostre_index.php (ln_upsert, ln_delete_under,

ln_reindex_target) + popola_foto_index.php. Ogni mutazione FS lo riallinea.

• gestore_foto.php ha gia' l'endpoint ?azione=cerca (LIKE su nome/cartella).
• Creds: vittrosviaggi_shared/secrets/db_lenostre.php (posto STABILE, fuori dai release).

photo [ESISTE - LEGACY, da dismettere]

Solo tabelle utente di leNostre50: users, user_h, user_history,

user_history_sav. -> Migrare gli utenti in vrp_auth, poi dismettere.

(NB: si chiama "photo" ma NON contiene foto: quelle sono in lenostre.)

vv_tmp [ESISTE - da verificare]

Scopo da verificare (temporaneo?).

vrs / share [SERVIZIO VIVO - dati in vittrosviaggi]

Il servizio Share (/lab/public/share/, lib platform/lib/vrs.php) e' in produzione nel

lab. I dati vivono in vittrosviaggi, letti via DB vrv. Modello = due tabelle + i file su

disco (share_storage/dirs/<dir_id>/<filename_stored>); le miniature NON si copiano (al volo

via vrp_img, cappello thumb.php). Cancellazione HARD (rimuove file+tupla).

• share_dirs (7 righe) - l'ALBERO delle cartelle. id [PK], parent_id (la cartella

madre; NULL/radice=root_dir_id 1), name, owner_user_id (proprietario, per i permessi),

created_at, updated_at, is_deleted (colonna soft-delete presente ma oggi si cancella

hard). L'albero e' "ognuno sa il padre".

• share_files (135 righe) - i FILE. id [PK], dir_id (in che cartella sta),

filename_original (nome mostrato all'utente), filename_stored (nome sul disco, con

suffisso _N anti-collisione), mime_type, size_bytes, owner_user_id, created_at,

updated_at, is_deleted. I due nomi servono perche' due utenti possono caricare "foto.jpg".

Azioni loggate nel registro (vrp_insert_action('vrs',...)): create_dir, upload, download,

delete (file e cartella). Da valutare (non urgente) se estrarre in un DB dedicato vrs.

registro azioni utente [FATTO 09/07 - opzione A]

Log DB di "chi ha fatto cosa/quando" in italiano. SCELTA: opzione A = riga nella sessions

(colonna detail aggiunta, action='upload'/'delete'/...) mostrata nella pagina Sessioni coi

filtri. Funzione vrp_insert_action(service,action,detail) in platform/lib/vrp_action.php

(riusa vrp_insert, non-bloccante). Agganciata nello share (create_dir/upload/download/delete).

DA FARE: agganci import-foto/crea-post + bottone Purge nella pagina Admin (svuota le

righe-evento vecchie; distinto dal logrotate, che tocca i file di log non il DB).

Credenziali (da centralizzare)

Stato attuale: i segreti dei DB usati dalla piattaforma sono TUTTI nel posto STABILE

/srv/http/vittrosviaggi_shared/secrets/ (fuori dai release che ruotano), puntati da

env.json (registro db) e letti da platform/lib/vrp_db.php:

• db_lenostre.php -> DB lenostre (indice foto)
• db_vrp_auth.php -> DB vrp_auth (identita' + sessioni)
• db_vrv.php -> DB vrv (= vittrosviaggi: diario + share)

Il VRV storico (fuori piattaforma) usa ancora meta/secrets.local.json.

LEZIONE APPRESA (02/07): le creds di lenostre stavano in vv_work/testing/

(un release DEV). Ritirando vv_work col B500, il path si e' rotto e wiz_foto

e' andato giu'. I segreti/config NON vanno in un release che ruota: spostati

nello shared stabile. Lavoro-piattaforma: un solo punto in platform/boot/,

letto da vrp_db.php.

Accesso da riga di comando (CLI)

Attenzione: root NON e' piu' passwordless. Tre modi, in ordine d'uso:

1. mariadb (senza argomenti) -> entra come vv_backup grazie a

~/.my.cnf (utente unix vitti): sola-lettura su photo e vittrosviaggi,

e show databases mostra SOLO quei due (+ information_schema). Comodo per

sbirciare il diario; NON vede vrp_auth/lenostre e non scrive.

2. root (vede tutto, DDL) -> mariadb -u root -p e incolla la password

dalla cassaforte (KeePass VittRos.kdbx). ATTENZIONE: mariadb -u root

SENZA -p FALLISCE ("Access denied ... using password: YES") perche' il

password= di ~/.my.cnf (di vv_backup) viene iniettato lo stesso; il -p

sulla riga di comando lo scavalca. Il -p (senza valore attaccato) chiede la

password in modo NASCOSTO: non finisce ne' in ps ne' nella history. NON

usare mai -p<password> attaccato (finirebbe in chiaro).

3. Da script/PHP -> mai root: usa gli utenti-app via i secrets in

/srv/http/vittrosviaggi_shared/secrets/ (letti da vrp_db()). Es.:

require '.../platform/boot/3_2_1_Go.php'; vrp_row('vrp_auth', "SELECT ...");

E' il percorso collaudato (ogni servizio col suo utente, un DB ciascuno).

Piu' utenti in ~/.my.cnf (dal 10/07): oltre al [client] di default

(vv_backup), il file ha gruppi extra selezionabili con --defaults-group-suffix:

mariadb --defaults-group-suffix=vitti -> utente vitti (scrive su

vittrosviaggi); mariadb --defaults-group-suffix=mig -> utente vviaggi_mig

(DDL su vittrosviaggi). Le password stanno in chiaro nel file (mode 600, e in

cassaforte).

Utenti del server MariaDB

Ricognizione 2026-07-10 (letta da mysql.user come root). 16 utenti + il

mariadb.sys di sistema. Le PASSWORD non stanno qui (solo in cassaforte e nei

secrets): qui utente, host, privilegi e SCOPO.

In uso - NON toccare

Relitti / da rivedere

Pulizia pronta (10/07, la lancia root): prima un backup dei grant in un file

protetto fuori dal web, poi i DROP:

DROP USER 'SantUtto'@'localhost','SantUtto'@'127.0.0.1','SantUtto'@'::1';
DROP USER 'lella'@'localhost';
DROP USER 'wordpress_user'@'localhost';
DROP USER 'backup'@'localhost';
DROP USER 'vitti_user'@'%';   -- consigliato (superuser remoto)
FLUSH PRIVILEGES;

Nota sicurezza (CHIUSA 10/07): prima 7 utenti condividevano lo STESSO

hash-password (una sola password debole riusata). Dopo i DROP dei relitti

restavano vitti, vv_backup, vviaggi_mig su quella password -> **RUOTATE

10/07**, ora 3 password forti DISTINTE (32 char, non-umane) via ALTER USER,

allineate in ~/.my.cnf (gruppi) e in cassaforte. root, vrp_auth_app,

vviaggi_app, lenostre_app avevano gia' password proprie.

Migrazioni previste

1. vrp_auth: unificare utenti VRV + leNostre50 (delicato: ruoli, chi-puo-cosa).

2. dismettere photo dopo la migrazione utenti.

3. (eventuale) estrarre share in vrs.