ROMFASTSQL/docs/handoff_instalare-doua-faze.md

Handoff — instalare ROA în două faze, licențe, IIS, export zilnic

Stare la 2026-08-25. Blocul de lucru e terminat; nimic nu e într-o stare periculoasă. Toate modificările sunt scrise pe disc, necomise.

Ce s-a livrat

Fișier	Stare
proxmox/lxc108-oracle/roa-windows-setup/FAZA1.cmd	nou, parsare testată
proxmox/lxc108-oracle/roa-windows-setup/FAZA2.cmd	nou, parsare testată
.../scripts/09-copy-licenses.ps1	nou, nerulat pe o bază reală
.../scripts/10-setup-roaupdate-iis.ps1	nou, nerulat
.../scripts/11-setup-backup-export.ps1	nou, nerulat; blocat pe backupora.exe
.../scripts/drop-contafin.ps1	nou, nerulat
.../sql/export-licente.sql	nou, nerulat
.../backup/settings.ini.template	nou, format presupus, nu confirmat
.../scripts/07-verify-installation.ps1	modificat: +268 linii de verificări noi
.../README.md	rescris, 846 → 620 linii
proxmox/lxc108-oracle/scripts/build-client-kit.ps1	modificat: text CITESTE-MA.txt + avertisment backupora.exe
proxmox/lxc108-oracle/docs/instalare-si-migrare-oracle.md	modificat: tabelul pașilor + cele trei fluxuri

Ce s-a verificat efectiv

• Toate cele 13 scripturi .ps1 din roa-windows-setup/scripts/ plus build-client-kit.ps1 parsează curat (PSParser::Tokenize).
• FAZA1.cmd și FAZA2.cmd: parsarea argumentelor, inclusiv căile cu literă de disc (/roaupdate:D:\RU ajunge întreg), flagurile fără valoare, ecranul de utilizare, codurile de ieșire.
• Toate cele 12 linkuri relative din README-ul nou duc la fișiere existente.

Ce NU s-a verificat

Niciun script nou nu a fost rulat pe o bază Oracle. Nu există mediu pornit — VM 302 e oprit. Toate verificările de mai sus sunt statice.

Blocajul de la backupora.exe — REZOLVAT

Găsit local, în D:\ROA\EXPORT_ORADMP\ pe stația de dezvoltare. Copiat în kit (roa-windows-setup/backup/): backupora.exe (49 KB), config.fpw, setari.ini.tmpl, schema.tmpl, changelog_backupora.txt.

Presupunerile mele inițiale erau greșite pe trei puncte, toate corectate:

1. Fișierul de config se cheamă setari.ini, nu settings.ini. Redenumit peste tot: scriptul 11, verificarea 07, README, build-client-kit.ps1, instalare-si-migrare-oracle.md. (Referințele la settings.ini rămase în proxmox/vm201-windows/ sunt alt fișier — endpointul de raportare erori din D:\ROAUPDATE — corect, nu se ating.)

2. Secțiunile reale sunt [schema], [backup], [oracle]. Nu există host/port/ service/parole în ini. Șablonul backup/setari.ini.template are acum formatul real, cu 10 marcaje: {{EXPORT_DIR}}, {{BACKUP_PATH}}, {{SCHEMA_FILE}}, {{RETENTION_DAYS}}, {{EXPDP_EXE}}, {{DMPDIR_PATH}}, {{DMPDIR_NAME}}, {{ORACLE_HOME}}, {{DB_SERVICE}}, {{DATA_GENERARII}}. Verificat automat: toate 10 sunt substituite de script.

3. schema.txt nu e o listă de nume de scheme. Formatul (din schema.tmpl) e SCHEMA;PAROLA@SERVICIU, câte una pe linie. New-SchemaFile citește acum și NOM_FIRME.parola, nu doar schema. Fișierul conține parole în clar — scriptul avertizează să nu fie scos de pe server.

Două capcane confirmate în sursa VFP (main.prg), documentate în script:

• programul scrie în ini-ul implicit cheia delete_backups_olther_xdays (cu typo, main.prg:76) dar citește delete_backups_older_xdays (main.prg:117). Șablonul o are pe cea corectă — nu o „corecta" înapoi.
• alege între exp clasic și Data Pump după numele executabilului din oracleexpfile (changelog v3.0.0: „Numele executabilului trebuie sa fie expdp.exe"). De aceea {{EXPDP_EXE}} arată către <OracleHome>\bin\expdp.exe, nu către stub-ul de 0 octeți din directorul programului.

Decizie de confirmat cu Marius: backuppath (unde ajung dump-urile) e acum implicit egal cu ExportPath, deci D:\ROA\EXPORT_ORADMP\<AAAALLZZ>\. Pe instalarea de referință de pe stația de dezvoltare valoarea era C:\BACKUP_ORACLE, cu programul în D:\ROA\EXPORT_ORADMP. Există parametrul -BackupPath pentru convenția veche. Nu știu care e corectă la clienți.

Decizii deja luate — nu se reiau

1. Faza 1 importă contafin-ul REAL al clientului, nu șablonul. Motiv: pe CONTAFIN_ORACLE nu se lucrează activ, deci poate fi exportat în timpul programului. Doar firmele se schimbă sub picioare. Șablonul rămâne ca fallback.
2. Faza 2 înlocuiește contafin prin DROP USER CASCADE + import curat, nu prin TABLE_EXISTS_ACTION=REPLACE. Opțional, prin /reimportcontafin.
3. Pasul 08 se reia obligatoriu în faza 2. SERVER_INFO e o tabelă în CONTAFIN_ORACLE (sql/synonyms-public.sql:270); dump-ul clientului aduce cu el căile, parolele și SMTP-ul serverului vechi.
4. Licențele: rețea întâi, fișier ca fallback. sql/export-licente.sql produce INSERT-uri pe stdout; 09-copy-licenses.ps1 fie îl rulează prin rețea pe serverul vechi, fie citește rezultatul cu -FromFile.
5. IIS: scriptul instalează rolul dacă lipsește (Install-WindowsFeature pe Server, Enable-WindowsOptionalFeature pe Windows Pro). Poate cere restart.
6. Directoarele de modul se creează în două locuri diferite, intenționat: pasul 08 face _ARHIVE\<MODUL> (pentru obiectele Oracle DIRECTORY), pasul 10 face D:\ROAUPDATE\<MODUL> (binarele curente, servite de IIS). Lista de 55 de module e duplicată în ambele scripturi — la adăugarea unui modul se modifică ambele.

Comenzi de testare, când există mediu

ssh root@10.0.20.201 "qm start 302"

Pe VM 302, din rădăcina kitului:

Run.cmd 99-uninstall-roa.ps1 -Force
FAZA1.cmd 999 /faralicente /farabackup
FAZA2.cmd 999
Run.cmd 07-verify-installation.ps1

Logurile: roa-windows-setup\logs\<script>_<data>.log. Codul de ieșire 0 la pasul 07 = instalare bună.

Ordinea de testat, de la ieftin la scump:

1. 10-setup-roaupdate-iis.ps1 — nu atinge baza, se poate rula izolat;
2. 09-copy-licenses.ps1 -ExportOnly pe o bază existentă — doar SELECT;
3. FAZA1.cmd complet;
4. FAZA2.cmd cu și fără /reimportcontafin;
5. 11-setup-backup-export.ps1 — abia după ce apare backupora.exe.

Ce mai lipsește

• Confirmarea lui backuppath — vezi decizia de mai sus (ExportPath vs C:\BACKUP_ORACLE).
• Confirmarea că numele obiectului Oracle DIRECTORY pentru export e chiar BACKUP_ORACLE (așa l-am scris în 11-setup-backup-export.ps1).
• Dacă backupora.exe are nevoie de runtime VFP9 (vfp9r.dll, vfp9renu.dll) pe un server curat. Pe stația de dezvoltare merge pentru că runtime-ul e deja instalat. Dacă la client dă „Cannot locate the Microsoft Visual FoxPro support library", trebuie adăugate DLL-urile în backup/ sau instalat runtime-ul. Netestat.
• schema.txt folosește @$ServiceName (deci XEPDB1). De verificat că backupora.exe acceptă un service name EZConnect, nu doar un SID/alias TNS — pe instalările vechi acolo era un SID (ORASID în șablon).
• Verificarea că aplicația ROA de pe stații acceptă http://localhost/roaupdate/ ca sursă — scriptul publică acolo, dar configurarea stațiilor nu e acoperită de kit.
• SERVER_INFO.UPD_URL_APP rămâne https://update.romfast.ro/roa/ (serverul clientului trage de la ROMFAST). Dacă undeva trebuie scrisă adresa oglinzii locale pentru stații, nu e în baza de date — nu am găsit unde.

Ce e interzis

• Nu comite config.ps1 — poate conține parolele altui client.
• Nu comite fișiere .dmp.
• Nu rula scripturile pe 10.0.20.121 (LXC 108) — e sursa șabloanelor, nu o țintă de instalare. PDB ROA de acolo e producția ROA_CENTRAL.