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
Trei probleme gasite pregatind migrarea unui client de pe Oracle XE 11 pe XE 21c.
1. sys-grants.sql nu era rulat de niciun script PowerShell. Era referit doar din
run-all-sys.sql, care se lanseaza manual. Pe orice instalare facuta cu
RunAll.cmd lipseau sinonimele SYS (SYN_NEWSCHEMA, SYN_NEWSCHEMAJOB,
EXECUTESCRIPTOS, SYN_PINFO), DMPDIR si granturile pe DBMS_SCHEDULER / UTL_* /
DBMS_CRYPTO catre CONTAFIN_ORACLE. Legat ca STEP 3 in 04-create-synonyms-grants,
dupa import - unde propriul header al fisierului spune ca trebuie rulat.
2. Granturile de dictionar cerute de PACK_DIAG_SPATIU lipseau complet. Consolidez
sys_2026_08_03_05, sys_2026_08_03_07 si sys_2026_08_06_07 in sectiunea [5/5]
din sys-grants.sql: SELECT direct pe 18 vederi dba_*/v$*, idempotent, cu
ORA-00942 tratat pentru vederile absente pe alte editii/versiuni. Grantul prin
rolul DBA nu ajunge - rolurile nu se aplica in pachetele cu drepturi de
definitor, iar PACK_DIAG_SPATIU e exact asa; fara ele ramane INVALID si
DIAGSPATIU_ZILNIC nu ruleaza.
3. Capcana la migrari: tabela de versiuni a lui PACK_MIGRARE traieste in
CONTAFIN_ORACLE si vine cu DMP-ul, deci baza noua raporteaza scripturile sys_*
drept aplicate si ROAACTUALIZARI le sare, desi in SYS nu exista nimic. De aceea
obiectele si granturile SYS se pun la instalare, nu prin actualizator.
Documentat in sys-updates/README.md si in ghidul nou.
07-verify-installation raporteaza nominal care dintre cele 18 granturi lipsesc.
Documentatie: docs/instalare-si-migrare-oracle.md - arbore de decizie intre
roa-windows-setup/ (client pe Windows), migration/ (Oracle in Docker pe LXC 108) si
new-roa-oracle-server/ (arhiva). Include de ce migration/ nu se foloseste la un
client Windows: creeaza PDB ROA cu OraclePass123, sinonime minimale, fara
SERVER_INFO / ROAUPDATE / ACL / sqlnet.ora, iar sys_objects.sql de acolo creeaza
INFO in SYSTEM - cauza cunoscuta a ORA-01653 la actualizare. Plus comenzile de
export din XE 11 / 10g si plafonul XE de 12 GB.
Corectat pe drum: dual-edition-test-plan si issues-se-prod indicau clonarea
VM 302 -> 303 pentru testul SE, dar 303 e ocupat de Win11-Adina. Mutat pe 304.
NETESTAT pe baza reala - VM 302 e oprit. Scripturile trec doar parse-check
PowerShell.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01SzF1hf4aFS1tmJWpPMiwGp
VM 109 a eșuat testul DR fără să apuce să pornească Windows (zero
evenimente în event log, CPU minim, host-side curat). Test de restore
manual imediat după a confirmat că backup-urile sunt intacte. Adăugat
serial0 socket + EMS pe guest ca să prindem live blocajul dacă se repetă.
- exportul e manual, nu exista cron/job automat
- ce face export-roa2.sh: expdp per schema + arhiva .tar.gz separata
- directoarele de destinatie pe LXC 108 (18c vs 21c) si conventia de nume
- copierea finala pe Windows in E:\backups\oracle\
- corectat: "Export Complet ROA2" spunea un singur .zip, sunt doua .tar.gz
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01SJyKjALp1WmoH8Z7kAzMqx
Docker host-ul era singurul guest fara replicare. Adaugate job-urile 102-0
(pve1, 21:20) si 102-1 (pveelite, 21:21), in sloturi libere. Sync initial
rulat manual: ~88s fiecare, ambele OK.
Prima incercare a esuat cu "No common base snapshot": ambele noduri tinta
aveau volume orfane ramase de la o replicare stearsa candva (pve1 50 GB,
pveelite 30 GB, din epoci diferite, nefolosite). Sterse prin API, apoi sync
complet.
Documentate: capcana volumelor orfane si faptul ca SSH intre noduri trece
prin Tailscale — pentru inspectii pe alt nod se foloseste `pvesh get
/nodes/<nod>/...`, nu ssh imbricat.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01MoFGxftQw92PX4Sdkn94pv
LXC 102 nu avea nici backup, nici replicare — singurul guest fara nicio
protectie. Ultimele arhive erau din 10 ianuarie 2026: trecerea de la job-ul
unic la job-urile per-guest l-a scapat pe dinafara, 7 luni fara sa semnaleze
nimic.
Creat `backup-pare-docker` (zile pare 03:00, keep-last=2 keep-weekly=1) si
rulat un backup imediat — 9 GB arhiva din 12.3 GB folositi.
Toate guest-urile `running` sunt acum acoperite. Notata in README capcana:
job-urile care ruleaza cu succes nu spun nimic despre guest-urile care nu
sunt in ele.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01MoFGxftQw92PX4Sdkn94pv
LXC 103 avea replicare ZFS zilnica (21:02 pve1, 21:03 pveelite) dar niciun
backup. Replicarea oglindeste starea curenta: o stergere sau o coruptie
ajunge pe toate nodurile la urmatorul sync, fara punct de revenire.
Adaugat in job-ul de containere usoare (zile impare 03:00, keep-last=2
keep-weekly=1) — 8.24 GB folositi, 4.3 GB arhiva. Rulat si un backup
initial, fiindca urmatoarea rulare automata era abia pe 13 august.
Ramane descoperit doar LXC 102, singurul `running` fara backup.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01MoFGxftQw92PX4Sdkn94pv
`backup-impare-adina` (la 2 zile) inlocuit cu `backup-lunar-adina`:
prima sambata din luna la 04:30, keep-monthly=3.
Ora 04:30 evita coliziunea cu job-urile pare/impare de la 03:30 — prima
sambata a lunii poate cadea in orice zi.
Notat in README ca `sat *-1..7` inseamna prima sambata: un job lunar adaugat
la mijlocul lunii nu ruleaza pana luna urmatoare.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01MoFGxftQw92PX4Sdkn94pv
VM 303 nu era in niciun job de backup dupa transformarea in full clone.
Adaugat `backup-impare-adina` (zile impare 03:30, storage backup,
keep-last=2 keep-weekly=1), pe zile impare ca sa nu se suprapuna cu VM 201
care ruleaza in acelasi slot pe zile pare.
Sectiunea "Backup Job Configuration" din README descria un job unic
(`backup-fbb668c0-726e`, daily 02:00) care nu mai exista de mult. Inlocuita
cu cele 8 job-uri reale.
Semnalate guest-urile fara backup: LXC 102 si 103, ambele `running`.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01MoFGxftQw92PX4Sdkn94pv
`qm move-disk <vmid> <disk> local-zfs --delete 1` esueaza intotdeauna pentru
zvol-uri: PVE respinge mutarea pe acelasi storage, iar conditia din
Qemu.pm:4688 e mereu adevarata fiindca numele volumului n-are sufix de format.
Nici storage-ul `local` nu e ruta de ocolire — n-are `images` in content.
Documentata metoda care functioneaza (zfs send/recv local + swap de volid),
asa cum a fost aplicata pe VM 303.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01MoFGxftQw92PX4Sdkn94pv
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
deploy.sh era documentat doar in README-ul VM 109; nu aparea nicaieri in
proxmox/README.md, deci nu il gaseai daca nu stiai deja ca exista. Iar
`deploy.sh --help` raspundea cu o singura linie pe stderr si exit 2 - o
unealta documentata trebuie sa se poata explica singura.
- deploy.sh: --help / -h cu utilizare completa (optiuni, ce verifica inainte
sa copieze, distributia pe noduri si de ce e asimetrica, ce face --guest cu
VM 109 oprit, si faptul ca nu atinge cron-ul). Exit 0 pentru --help, exit 2
cu mesaj pe stderr pentru optiune necunoscuta.
- proxmox/README.md: deploy.sh, vm109-patch-window.sh si check_servicing.ps1
in tabelul de fisiere, bloc "Deploy modificari" in Quick Start, plus intrari
in "Vreau sa..." pentru deploy, pentru patching si pentru simptomul
"Restore failed fara log RMAN".
- README VM 109: --help in lista de comenzi si un exemplu de output --check,
ca sa se vada diferenta dintre "DIFERA" si "LIPSESTE pe nod".
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01BhQBTegE4PiMPPaapLHjkc
Doar line endings, zero modificari de continut (verificat cu
git diff --ignore-cr-at-eol: fara diferente ramase pe aceste fisiere).
Fisierele aveau CRLF comis efectiv in repo, nu doar in working tree.
Sunt scripturi care ruleaza pe Linux (migrarea Oracle, LXC 171 claude-agent),
iar deployate direct din working tree bash le refuza cu
"$'\r': command not found" - exact capcana pe care .gitattributes (comis in
9475842) o previne de acum inainte pentru fisierele noi.
Nu sunt incluse fisierele .md/.sql din roa-windows-setup: acelea au
modificari reale de continut, in curs, si apartin altui commit.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01BhQBTegE4PiMPPaapLHjkc
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
Pana acum deploy-ul se facea manual (`cp ... /opt/scripts/`), nedocumentat
nicaieri - de unde si fisierele weekly-dr-test-proxmox.sh.bak-* ramase pe
pveelite. deploy.sh face aceiasi pasi, dar refuza situatiile care au costat
deja timp:
- suprascrierea unui script AFLAT IN EXECUTIE: bash citeste scriptul
incremental de pe disc, iar suprascrierea unui test DR in curs (~18 min)
corupe executia;
- CRLF: bash pe Linux raspunde "$'\r': command not found";
- transfer trunchiat: bash -n local si inca o data pe nod dupa copiere;
- flag-ul vm109-debug.flag lasat in urma dupa deploy pe guest (dezarmeaza
permanent watchdog-ul, exact apararea care a prins incidentul 04-20).
Distributia pe noduri e asimetrica intentionat si e codificata explicit in
script: scripturile cluster-aware (test DR, patch window, watchdog) pe ambele
noduri fiindca urmaresc VM 109 dupa failover HA; ZFS/mirror doar pe pveelite
unde traieste datasetul; alertele si failover-ul doar pe pvemini, fiindca
reactioneaza la caderea pveelite - puse pe pveelite ar fi inutile si ar
inlesni exact split-brain-ul pe care incearca sa-l previna.
Verificarea "ruleaza acum" foloseste pgrep -f '[/]opt/scripts/x.sh'.
Parantezele nu sunt cosmetice: comanda trimisa prin ssh apare ea insasi in
lista de procese, deci forma fara paranteze se gaseste pe sine si raporteaza
orice script ca fiind in executie (verificat: exit 0 vs exit 1).
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01BhQBTegE4PiMPPaapLHjkc
Testul DR din 2026-08-08 a raportat "Restore failed" dupa 11 secunde, fara
niciun log RMAN. Cauza nu a fost restore-ul: KB5101001 fusese descarcat in
timpul testului din 2026-08-01 (singurul moment in care VM 109 e pornit),
a ramas staged dupa qm stop si s-a finalizat la boot-ul testului urmator.
Cronologie din Event Log-ul guest-ului:
06:00:58 RestartManager 10010 - nu poate reporni powershell.exe (restore-ul)
06:01:04 SCM 7034 - OpenSSH SSH Server terminat neasteptat
06:01:06 pveelite: client_loop: send disconnect: Broken pipe -> FAILED
06:01:38 VM-ul se reboteaza singur
Fereastra testului (Sambata 06:00) era in afara Active Hours (08:00-17:00),
deci pentru Windows era fereastra de mentenanta valida - iar VM 109 fiind
pornit doar in timpul testului, aceea era singura fereastra posibila.
Agravant: sshd nu avea acsiuni de recovery (RESET_PERIOD 0), deci dupa ce a
murit a ramas mort si au esuat si colectarea logului si shutdown-ul gratios.
Masuri:
- NoAutoUpdate=1 + AUOptions=2 pe VM 109 (aplicat direct in registry)
- actiuni de recovery pentru sshd: restart la 5s/10s/30s, reset=86400
- guard "STEP 3b: Windows servicing" inainte de restore (check_servicing.ps1):
asteapta idle 300s, consuma controlat un reboot in asteptare, altfel
abandoneaza cu "ABORTED - Windows servicing" in loc de un "Restore failed"
inselator. Fail-open daca checkul lipseste - nu are voie sa pice testul.
- fereastra lunara de patching (vm109-patch-window.sh + install_updates.ps1),
prima duminica 03:00, cu re-armare NoAutoUpdate=1 indiferent de rezultat
Adaugat si .gitattributes: cu core.autocrlf=true scripturile .sh ajungeau in
working tree cu CRLF, iar ele se deployeaza prin scp direct pe Proxmox.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01BhQBTegE4PiMPPaapLHjkc
- scripts/install-sbt.sh: instalare idempotentă (scripturi + statusline +
patch settings.json) cu verificări de mediu
- README: replicare de la zero (transfer prin pct exec, installer, sandbox,
ce se pierde la recrearea sandbox-ului), verificare rapidă, căi noi
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
- fără agent implicit: ambele pane-uri sunt shell în sandbox, agentul se
pornește manual; argumentul 3 rămâne pentru lansare explicită
- al doilea pane intră în sandbox cu 4s întârziere (SBT_PANE_DELAY):
două `sbx exec` simultane se calcă pe lock-ul de refresh Docker Hub și
scot "could not acquire docker hub refresh lock"
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
- sbt: sesiuni tmux (sbx1..3) care intră în sandbox și lansează agentul
(claude/opencode/orice binar); tmux rulează pe host, panes prin sbx exec
- statusline.sh + bootstrap-statusline.sh pe /home/workspace/.agent
(virtiofs persistent), reinstalat la fiecare intrare fiindcă /home/agent
din sandbox e overlay efemer
- fix printf "--" -> printf -- "--" (eroare de usage când API-ul de cote
nu răspunde)
- copii versionate ale scripturilor agents/sb + documentație README
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Alerta "OOM x2 on pvemini" (09:36) arata procese mici ucise (dbus-daemon,
oom_score_adj:200), dar mesajul kernel dadea containerul real:
oom_memcg=/lxc/102. OOM local containerului, nu presiune de host - pvemini
avea 24Gi disponibili si zram functional.
Baseline masurat cu ZERO sandbox-uri active: ~1.9GB (sbx 863M + claude 317M +
VS Code Remote 450M + docker/tailscale/portainer 205M). Un sandbox real mai
adauga ~1.9GB (containerd-shim) -> plafonul de 4GB era depasit sistematic.
Contoare cumulate: oom_kill 24, 9279 depasiri memory.high, memory.peak fix pe
limita, swap 510/512 epuizat.
Verificat explicit ca sbx NU are memory leak: RSS urca la ~863M la pornire si
se plafoneaza (esantionat la 10s timp de un minut).
Fix: pct set 102 --memory 12288 --swap 4096 (live, fara restart).
Tabelul de resurse din cluster/README.md era vechi (102 aparea ca "coolify
stopped", lipseau 110 si 171, RAM gresit peste tot) - regenerat din pvesh.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
LXC 110 (moltbot) a picat dupa un OOM local containerului urmat de reboot:
tailscaled a ramas delogat, iar containerul mostenea resolv.conf-ul Tailscale
de la host-ul pve1 (doar MagicDNS 100.100.100.100) -> rezolutie DNS zero desi
L3 era functional -> echo-core in crash-loop pe telegram.error.TimedOut.
Fixuri aplicate:
- pct set 110 --nameserver '10.0.20.1 1.1.1.1' (elimina dependenta de Tailscale)
- zram-tools pe pve1 (8G zstd, prio 100) - `swap: 4096` din config era fictiv,
host-ul nu avea niciun swap; root pe ZFS deci zram, nu swapfile
- MemoryHigh/MemoryMax pe pocket-tts + supertonic-tts - toate serviciile user
rulau cu limite `infinity`, de unde OOM-uri recurente (Apr 25, May 28 x4)
cu victime aleatorii alese dupa oom_score_adj
Documentatie:
- nou post-mortem in cluster/incidents/, adaugat in indexuri
- README lxc110: host corectat pveelite -> pve1 (+ RAM/CPU/storage reale),
comenzile pct redirectionate spre nodul corect
- README lxc171: tabel cu starea swap pe cele 3 noduri (pveelite are zvol,
nu zram - nu necesita acelasi fix)
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Documentează LXC 102 și depanarea erorii "500: failed to run sandbox
container" la crearea sandbox-urilor opencode: build docker-sbx pentru
Ubuntu 26.04 instalat pe Debian 13 (libsailor.so cere GLIBC_2.43),
userul work lipsă din grupul kvm și /usr/sbin absent din PATH
(mkfs.ext4 pentru snapshotter-ul erofs).
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Documentate doua probleme intalnite la deploy: variabile env noi
(AUTOPASS_RAR_ENV, AUTOPASS_SESSION_SECRET, AUTOPASS_WORKER_SEND_ENABLED)
devenite obligatorii in docker-compose.yml fara actualizare in Dokploy,
si crash-loop api/worker cu "readonly database" dupa ce imaginea a trecut
la user non-root (uid 10001) fara chown pe volumul SQLite existent.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Flux de lucru pentru mediu staging autopass: un branch = un environment
(main->prod, staging->test), serviciu Dokploy separat autopass-test, domeniu
via wildcard *.roa (fara IIS/cert nou), env care opreste trimiterile reale la
RAR. Link incrucisat din autopass.md.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
- ghid deploy Dokploy (Custom Git, autodeploy webhook, domain via roa-apps wildcard)
- probleme intampinate: Gitea Unauthorized, api crash-loop (itsdangerous lipsa), 303 /login
- link in indexul docs din README
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Cauza ERR_CERT_DATE_INVALID pe roa-qr.romfast.ro: renewal-ul win-acme
avea Installation plugin "None" in loc de IIS -> certul se reinnoia in
store dar binding-ul SNI ramanea pe certul vechi (expirat 31 mai).
- monitor-ssl-certificates.sh: adaugat roa-qr.romfast.ro (Site ID 5);
normalizat CRLF->LF (CRLF dadea exit 127 la exec pe Linux)
- docs: box incident 2026-06-25 cu cauza-radacina + diagnostic per renewal
Fix aplicat pe VM 201: plugin install None->IIS in renewal.json + force
renew (cert nou valid pana 23 sep 2026, binding auto-actualizat).
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Incident 2026-06-24: OOM-uri repetate în cgroup /lxc/171 cauzate de swap
nebacked pe host (pvemini fără swap) + acumulare de forks vscode-server
orfane și sesiuni logind zombie.
- scripts/reap-orphans.sh: reaping conservator (forks ~/.vscode-server
orfane >24h + sesiuni closing cu leader mort), rulat din cron la 6h
- README: secțiune Memorie & OOM (zram pe host ZFS, reaper, diagnostic),
corectat date stale host/RAM/CPU (pvemini, 16GB, 4 cores)
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Script Windows interactiv pentru client VADECO_20240227:
- verificare TCP port 1521 (fail-fast fara tunel SSH)
- verificare calendar Oracle: deschidere luna noua (tnDeschidere=1)
sau redeschidere cu avertisment stergere date (tnDeschidere=0)
- apel ACOPIE_BAZA_DATE + pack_deschidere_luna.deschidere_luna
- mod Dry Run (afiseaza SQL fara executie) si suport argumente CLI
- valori implicite: anul si luna anterioara curenta
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Procedura completa import DMP client pentru teste in LXC 108 Oracle 21c.
Parfile expdp ACN cu tabele mari excluse (40 tabele, ~2.4GB date excluse).
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
- Proxmox default-matcher acum trimite doar la mail-to-root (pve1 smtp
eliminat din matcher → fix emailuri duble pentru backup/vzdump)
- Adaugat tabel cron jobs per nod cu motivul redirect-ului > /dev/null
- Regula: scripturi cu propriile notificari trebuie sa aiba redirect in
crontab, altfel cron genereaza email suplimentar de confirmare
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Documenteaza incidentul Kingston SNV3S2000G hang la 2026-04-30 (Sensor 2
74°C → emergency mode + restart loop) si masurile aplicate: distantare
temporala backup-uri par/impar, mutare CT 101+110 pe pve1 backup-ssd,
nofail in fstab, hardware watchdog iTCO_wdt, monitoring CSV la 30 min.
Adauga scripturile /opt/scripts/kingston-thermal-{monitor,report}.sh
pentru tracking trend si alertare la depasirea pragurilor termale.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Documentat fluxul complet modificare → redeploy: manual vs auto-deploy
prin webhook Gitea/GitHub. Tabel repo-uri curente per serviciu.
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
