Adauga FAZA1.cmd/FAZA2.cmd, care despart migrarea in partea care se poate
face in timpul programului (contafin, obiecte SYS, sinonime, licente, IIS)
si partea de seara (schemele de firma). Scripturi noi: 09 pentru licentele
din SYS.AUTH_SERII/AUTH_DETALII, 10 pentru publicarea D:\ROAUPDATE in IIS,
11 pentru exportul zilnic cu backupora.exe, drop-contafin pentru reimport.
backupora.exe si sabloanele sale intra in repo ca sa fie kitul autonom.
Pasul 07 primeste verificarile corespunzatoare pentru licente, IIS si task.
Nerulat inca pe o baza reala - vezi docs/handoff_instalare-doua-faze.md.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01SzF1hf4aFS1tmJWpPMiwGp
Blocul de instalare/migrare Oracle 21c XE, terminat si validat pe VM 302.
Kit de instalare (nou)
scripts/build-client-kit.ps1 exporta CONTAFIN_ORACLE si FIRMANOUA de pe
LXC 108 (PDB ROA2, nu ROA - ROA e productia ROA_CENTRAL), le aduce local
prin cele trei hopuri container -> LXC -> host -> statie, le redenumeste la
numele pe care le asteapta scripturile si le impacheteaza cu o copie a
directorului roa-windows-setup. Citeste logul expdp si raporteaza cate
firme are NOM_FIRME, ca sa nu plece din greseala datele unui client.
roa-windows-setup/INSTALEAZA.cmd ruleaza pasii 01..08 fara "set /p", deci
merge si prin SSH - RunAll.cmd nu poate fi rulat neinteractiv. Trateaza
corect codul 5 de la pasul 03 si se opreste la prima eroare reala.
Corectii
01-setup-database.ps1 nu mai scrie SQLNET.RECV_TIMEOUT / SEND_TIMEOUT in
sqlnet.ora. Le hardcoda la 30 s, iar fisierul e citit si de impdp: in timpul
unui import serverul poate lucra minute fara sa trimita un pachet, clientul
murea cu ORA-12609 iar scriptul raporta esec pentru un import care se
terminase cu bine pe server. Reprodus si reparat pe VM 302.
01-setup-database.ps1: Step 4c optional (-ResetSystemPassword) care curata
EXPIRED(GRACE) pe SYSTEM in CDB root; ALTER PROFILE opreste expirarile
viitoare dar nu reseteaza un cont deja intrat in gratie.
uninstall-roa.sql: retry la DROP USER dupa KILL SESSION, plus un bloc final
de verdict care numara ce a ramas si iese cu ORA-20900 daca baza nu e
curata. Pana acum toate sectiunile prindeau exceptiile in WHEN OTHERS si
scriptul tiparea "UNINSTALL COMPLETE" chiar si cand un user supravietuise,
iar instalarea urmatoare dadea ORA-31684 in lant. 99-uninstall-roa.ps1
propaga codul de iesire.
08-post-install-config.ps1: Step 7b seteaza SMTP_OUT_SERVER si ACL-ul de
retea pentru CONTAFIN_ORACLE. UTL_MAIL se instala si primea EXECUTE, adica
destul cat sa compileze, dar nu si cat sa trimita. Privilegiul resolve nu
accepta interval de porturi (ORA-24244), deci se acorda separat de connect.
07-verify-installation.ps1: sectiune noua care verifica prezenta lui
FIRMANOUA.dmp in DMPDIR si o raporteaza ca eroare daca lipseste. Fara el,
adaugarea unei firme noi pica in DBMS_DATAPUMP.ADD_FILE peste luni de la
instalare, cand nimeni nu mai leaga eroarea de instalare.
configure-profile.sql: antetul spune ca e unealta de remediere manuala, nu
parte din flux; pas nou la final pentru CDB root.
Documentatie
README-ul roa-windows-setup descrie acum explicit cele doua scenarii -
instalare pe curat si migrare - de unde se iau DMP-urile sablon, si capcana
ORA-12609. Handoff-urile de sesiune au fost sterse; ce era durabil in ele a
intrat in README-uri si in docs/diagnostic-spatiu-clienti.md.
Validare pe VM 302: ciclu complet din kit, instalare pe curat, verificarea
finala "[OK] All checks passed!".
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01SzF1hf4aFS1tmJWpPMiwGp
VM 303 rula ca linked clone din VM 300, deci template-ul contaminat nu putea
fi sters. Transformat in full clone si VM 300 eliminat din infrastructura.
Metoda: zfs send/recv local + swap de volid in config. `qm move-disk` nu era
o optiune — PVE respinge mutarea pe acelasi storage, iar pentru zvol-uri
conditia din Qemu.pm:4688 e mereu adevarata (numele n-are sufix de format).
- inventarele nu mai listeaza VM 300; VM 310 ramane singurul template
- clone-vm300.sh: comentariul spune de ce sursa e 310 (numele e istoric)
- handoff-ul sters la cererea utilizatorului; faptele care mai conteaza sunt
mutate inline in README-uri, ca sa nu ramana referinte moarte
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01MoFGxftQw92PX4Sdkn94pv
- parola permanenta RustDesk repusa de utilizator; VM 303 accesibil remote
- contul dedicat "fisiere" pe .122 NU se creeaza: se ramane pe romfast.
Sectiunea ramane ca referinta, marcata "nu executa fara cerere explicita".
Singurul punct deschis ramane decuplarea linked clone a VM 303 de template-ul
VM 300, urmata de stergerea VM 300.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01MoFGxftQw92PX4Sdkn94pv
- setup1 si defaultuser0 sterse; pe VM 303 a ramas doar contul romfast
- reteta de acces la \ROACENTRAL\temp fara drepturi de admin: "Everyone" pe
share nu inseamna anonim (guest blocat, LimitBlankPasswordUse=1), dar un
cont simplu din grupul Users primeste deja Modify prin Authenticated Users
- plan pentru sesiunea urmatoare: qm move-disk pe ambele discuri ca sa rupem
legatura de linked clone, apoi VM 300 poate fi sters definitiv
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01MoFGxftQw92PX4Sdkn94pv
Toate intalnite pe bune in timpul reparatiei VM 303:
- HideLocalAccountScreen nu functioneaza pe Win11 26100; OOBE cere oricum cont
- la ecranul OOBE nu introduce numele unui cont existent (agata fluxul)
- nu sterge defaultuser0 cat timp OOBE ruleaza; agentul QEMU raspunde ca
serviciu si mascheaza faptul ca OOBE nu s-a terminat (verifica quser)
- /generalize sterge HKLM\SYSTEM\MountedDevices => se pierd literele D: si E:;
volumele raman intacte, se reasigneaza cu Set-Partition
- sysprep readuce AutoAdminLogon=1
- RustDesk: MachineGuid regenerat => parola permanenta trebuie repusa
Stare finala verificata: volume Healthy, nedirty dupa oprirea fortata, zero
erori disk/Ntfs, NTLM catre .122 raspunde sub=0xc000006a.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01MoFGxftQw92PX4Sdkn94pv
SMB intre VM 303 si VM 201 era blocat de SID-ul de masina duplicat. Reparat
prin sysprep /generalize pe VM 303 insusi, nu prin mutare pe un VM nou:
sysprep schimba identitatea masinii, nu dezinstaleaza aplicatii.
SID: ...1850128657-3079265004-705332634 -> ...3853882515-1460096973-3208817208
Verificat dupa reparatie: 14/14 programe intacte, profilul romfast intact
(2944 MB, se rezolva corect, nu temporary profile), iar .122 evalueaza din
nou parola normal (sub=0xc000006a in loc de sub=0x0).
ATENTIE: IP-ul DHCP s-a schimbat 10.0.20.145 -> 10.0.20.101.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01MoFGxftQw92PX4Sdkn94pv
VM 300 `Win11-Template` nu a fost sysprep-uit: poarta numele ROACENTRAL si
SID-ul de masina al VM 201 (S-1-5-21-1850128657-3079265004-705332634).
Clonele lui mostenesc acea identitate, iar NTLM intre doua masini cu acelasi
SID de masina esueaza — de aici imposibilitatea accesarii share-urilor SMB
intre VM 303 si VM 201, in ambele sensuri.
VM 300 nu poate fi reparat in loc: e template read-only, iar VM 303 e linked
clone din el. Solutia: clona completa 300 -> 310, sysprep acolo, conversie in
template. Verificat pe o clona de proba: nume si SID noi la fiecare pornire.
- clone-vm300.sh: SOURCE_VMID 300 -> 310
- README-uri: VM 310 marcat ca template de clonare, VM 300 ca "nu clona"
- vm302-oracle-test: corectat exemplul care clona in VM 303 (deja ocupat)
- docs/handoff-smb-vm303-roacentral.md: probele, capcanele de sysprep, stare
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01MoFGxftQw92PX4Sdkn94pv
Serverul 10.0.20.36 a parut blocat 20 de minute (12:02-12:22). Nu a fost
blocaj, crash sau oprire: a intrat in standby S3 in urma unei actiuni de
power de la consola. BootId neschimbat, oracle.exe si tnslsnr.exe neintrerupte
din 15 iulie, zero erori in System/Application.
Dovada decisiva e listener.log: clienti serviti normal pana la 12:01:26, apoi
gaura totala pana la 12:22:03 - singura discontinuitate din toata ziua.
Remediere aplicata si verificata:
- somnul eliminat complet (powercfg /a nu mai listeaza nicio stare)
- butoane power si meniu Start -> Shut down; buton sleep -> Do nothing
- Sleep after era 600 s pe profilul DC, adica serverul ar fi adormit la 10 min
dupa o pana de curent; acum 0
- Critical battery action era Hibernate, imposibil dupa dezactivarea hibernarii;
corectat pe Shut down, praguri urcate 5%->20% / 7%->25% / 10%->40%
- ViewPower oprit si dezactivat: comunicatia cu UPS-ul era moarta (QPI NAK), iar
Windows gestioneaza UPS-ul nativ prin HID UPS Battery
- sonda roa2web care lovea listenerul la 30 s: oprita. Verifica portul 1521, adica
listenerul de productie, nu tunelul vending - raporta fals "sanatos". Tunelul e
dezactivat, era oricum cazut de la boot-ul din 15 iulie
Ramane, doar daca se repune vending in functiune: autorizarea cheii pe
79.119.86.134 (plink e respins de server dupa banner-ul de versiune).
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01RoM99w9qRELJefaWrtPRHo
DROP+CREATE in loc de ALTER TABLE MOVE: continutul e log fara valoare, iar
recrearea nu cere spatiu liber cat segmentul si nu tine tabela blocata cat ar
dura copierea. DROP e cu PURGE, altfel segmentul ramane in recyclebin si spatiul
nu se elibereaza. SYS.pINFO ramane INVALID dupa DROP, deci se recompileaza.
Scriptul de livrare: SVN r18010.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Rft5ofNa4Ux5VEh4YnhJRC
SYS.INFO e log de aplicatie (SYS.pINFO din AUTH_PACK scrie ~7 randuri la fiecare
conectare, ~13.500 randuri / ~2 MB pe luna) si nimic din baza nu-l citeste. Creat
de installer in tablespace-ul SYSTEM si nepurjat niciodata, a umplut SYSTEM la doi
clienti si a oprit actualizarea cu ORA-01653 - eroarea apare pe orice script,
pentru ca AUTH_PACK scrie acolo la conectare.
SIGMA 03.08.2026 - ff_2026_07_29_02_COMUN_TVA11 picat pe MARCU
AUTOMOTIVE 08.08.2026 - 552.581 randuri / 80 MB, SYSTEM cu 5 MB liberi
Installer:
- sys-objects.sql: SYS.INFO (tabela + segment LOB) se creeaza in tablespace-ul
ROA, cu fallback pe SYSTEM daca ROA inca nu exista
- scheduler-jobs.sql: job nou SYS.SYSINFO_PURJARE_ZILNIC, zilnic 03:30, retentie
90 zile, stergere in transe de 10.000 randuri; creat ENABLED, pentru ca nu are
nimic de configurat iar uitat dezactivat reproduce chiar problema pe care o
rezolva. In schema SYS: privilegiile ANY nu se aplica pe obiectele SYS cat timp
O7_DICTIONARY_ACCESSIBILITY=FALSE
- uninstall-roa.sql: dezinstalarea sterge si jobul
- 00-INSTALL-ORACLE-XE.md / -SE.md: pas post-instalare pentru plafonul SYSTEM
(maxsize 2000M) si mutarea SYS.INFO la instalarile vechi
Documentatie noua (docs/diagnostic-spatiu-clienti.md): jobul DIAGSPATIU_ZILNIC si
pragurile lui, formatul emailurilor de alerta si cum se citesc din mbox-urile
Thunderbird, procedura de tunel SSH catre serverul unui client, triajul alertelor
si starea la 08.08.2026 pe fiecare client.
Reparatia la AUTOMOTIVE e deja aplicata in productie (plafon 600 -> 2000 MB,
truncate SYS.INFO): SYSTEM a trecut de la 65 MB la 1545 MB de crestere posibila.
Scriptul de livrare pentru ceilalti clienti e scris, dar nepublicat:
COMUN sys_2026_08_08_02_SYS_INFO_TABLESPACE_PURJARE.sql
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Rft5ofNa4Ux5VEh4YnhJRC
