# 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

```bash
ssh root@10.0.20.201 "qm start 302"
```

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

```bat
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`.