Utilizatorul a verificat fizic: toate trei nodurile intra in UPS printr-un
prelungitor. Elimina necunoscuta ramasa din commit-ul 393cc8c — orchestrarea
shutdown-ului chiar are pe cine opri, pve1 si pveelite sunt vii la momentul in
care pvemini le trimite comanda prin SSH.
Consemnat in schimb ce rezulta din asta: UPS-ul e single point of failure
pentru tot clusterul, iar autonomia nu e masurata (driverul nu raporteaza
battery.runtime, ups.load era 8% cu toate nodurile pornite).
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01RRyaDj39hPQ89SZS6URRpS
Sincronizeaza in git modificarea deja aplicata pe pvemini. upssched ruleaza ca
user `nut`; fara sudo, scriptul de shutdown nu poate face nimic.
Copia din repo e acum identica cu /usr/local/bin/upssched-cmd de pe pvemini.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01RRyaDj39hPQ89SZS6URRpS
upsmon face fork in doua procese, iar NOTIFYCMD ruleaza in cel neprivilegiat,
ca user `nut`: shell nologin, home /var/lib/nut, NICIO cheie SSH. Verificat pe
pvemini — pentru `nut`, `qm list`, `pct list` si `ssh root@pve1` esueaza toate.
Deci ups-shutdown-cluster.sh nu putea opri niciun guest si nu putea ajunge la
niciun nod. Singurul lucru care mergea erau emailurile, pentru care exista deja
`nut ALL=(root) NOPASSWD: /usr/bin/perl`. De asta /var/log/ups-shutdown.log nu
continea nicio oprire reusita din 2025-10-06 incoace: la fiecare pana de curent
se trimiteau emailuri si nu se oprea nimic, iar pve1/pveelite mergeau pana se
termina bateria.
Reparat:
- /etc/sudoers.d/nut-shutdown da userului nut dreptul sa ruleze scriptul ca root
- upssched-cmd il invoca prin sudo (liniile 355 si 413)
- scriptul refuza sa porneasca daca nu e root, cu mesaj explicit
Rescris scriptul:
- seteaza shutdown_policy=freeze INAINTE de orice. Fara asta, politica
implicita `conditional` transforma fiecare poweroff de nod in failover catre
un nod care se stinge si el imediat — exact incidentul 2026-01-11, cu VM 201
migrat in timpul unei pene
- guest-urile HA se opresc cu `ha-manager set --state stopped`, nu cu
pct/qm shutdown, care din CLI nu actualizeaza state-ul HA
- Oracle primeste `shutdown immediate` inainte de oprirea containerului
- consumatorii se opresc in paralel, Oracle ultimul
- detecteaza lipsa quorumului si cade pe oprire directa, in loc sa blocheze
- flock: ONBATT si LOWBATT pot declansa amandoua scriptul
- sare peste nodurile care nu raspund la ping in loc sa astepte timeout SSH
- timeout pe notificarile email: nu consumam baterie pe SMTP
- --dry-run si --force; credentialele UPS pot veni din
/etc/nut/ups-shutdown.conf in loc sa fie in script
ups-shutdown-test.sh nu mai duplica logica: invoca scriptul real cu --dry-run.
Un test cu cod propriu testeaza altceva decat ce ruleaza in realitate.
Testat pe pvemini prin lantul complet:
sudo -u nut sudo /usr/local/bin/ups-shutdown-cluster.sh --dry-run --force
Descopera corect toate cele 11 guest-uri, inclusiv cele de pe pve1 (deci SSH-ul
merge), si gaseste shutdown.stayoff pe UPS.
RAMANE DE VERIFICAT FIZIC: ups.load e 8%, putin pentru trei servere. Daca pve1
si pveelite nu sunt alimentate din UPS, mor instant la pana si toata
orchestrarea e decorativa. Nu se poate verifica din software.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01RRyaDj39hPQ89SZS6URRpS
Statia de admin e Windows si nu ruleaza .sh direct: `bash` din PATH e cel din
WSL, cu alt filesystem si alta configuratie de chei SSH. Adaug echivalentele
native PowerShell.
- cluster-shutdown.ps1 / cluster-startup.ps1, aceeasi logica si aceleasi
garantii ca variantele bash
- folosesc clientul OpenSSH din Windows, deja prezent in System32
- compatibile PowerShell 5.1: fara &&/||, fara ternar, fara ?., fara
-AsHashtable; ping prin System.Net.NetworkInformation.Ping, nu
Test-Connection (WMI, lent si des blocat)
- nu redirecteaza stderr-ul lui ssh: in 5.1 asta transforma fiecare linie
intr-un ErrorRecord si strica $LASTEXITCODE chiar cand comanda a reusit
- parsarea `pct list` / `qm list` se face in PowerShell, nu prin awk remote,
ca sa nu se incurce interpolarea $1/$2 din stringurile PowerShell
- scriu acelasi format de fisier de stare ca variantele bash, deci poti opri
cu una si porni cu cealalta
Ambele testate cu -DryRun pe clusterul live, rezultat identic cu bash.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01RRyaDj39hPQ89SZS6URRpS
cluster-shutdown.sh / cluster-startup.sh — automatizeaza procedura din
docs/oprire-planificata-cluster.md. Ruleaza de pe statia de admin prin SSH,
nu de pe un nod: nodul care se opreste ultimul nu poate raporta rezultatul,
iar la pornire scriptul trebuie sa astepte nodurile din afara.
Decizii importante:
- guest-urile din HA se opresc/pornesc cu `ha-manager set --state`, NU cu
pct/qm shutdown; din CLI acestea nu actualizeaza state-ul HA si CRM-ul
poate reporni guest-ul in mijlocul opririi
- apartenenta la HA se descopera dinamic din `ha-manager config`
- ordinea de oprire e pe dependente: consumatorii intai, CT 108 Oracle
ultimul, cu `shutdown immediate` in baza inainte de a opri containerul
- shutdown-ul salveaza local ce rula; startup-ul porneste exact atat, ca sa
nu reporneasca VM-uri oprite intentionat
- NEVER_AUTOSTART (109, 301, 310) protejeaza fallback-ul fara fisier de
stare: VM 109 e DR-ul a carui pornire nedorita a declansat incidentul
2026-04-20, restul sunt template-uri
- garda impotriva rularii de pe un nod sau din CT 171 (s-ar sinucide)
- ping_host() portabil Git Bash / Linux
Corectat in runbook: ordinea de oprire spunea "Oracle primul", gresit ca
ordine de dependente — VM 201 si CT 104 consuma baza.
Ambele testate cu --dry-run pe clusterul live.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01RRyaDj39hPQ89SZS6URRpS
- vm109-watchdog.sh ruleaza si pe pvemini, nu doar pe pveelite (contine
`qm start 109`); tabelul de cron-uri de dezactivat era incomplet
- weekly-dr-test-proxmox.sh ruleaza sambata 06:00 pe AMBELE noduri si
porneste VM 109 — avertisment nou, cu trimitere la incidentul 2026-04-20
- comanda gata de rulat pentru dezactivare + comanda de restaurare din backup
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01RRyaDj39hPQ89SZS6URRpS
Runbook nou pentru oprirea controlata a celor 3 noduri (lucrari electrice,
mutare rack, mentenanta UPS) fara ca HA sa relocheze resursele si fara ca
watchdog-ul sa reseteze hard nodul ramas fara quorum.
Doua capcane documentate:
- /etc/pve/datacenter.cfg nu exista => shutdown_policy implicit `conditional`
=> poweroff pe nod declanseaza FAILOVER, nu freeze
- watchdog-ul face reset hard dupa ~60s pe nodul care pierde quorumul cu
servicii HA inca active
Corectii in failover/README.md, verificate pe clusterul live:
- VM 201 ESTE in HA (grup ha-prefer-pvemini), docul spunea ca nu e
- CT 108 e in ha-prefer-pvemini (pvemini:100, pve1:50, pveelite:10),
nu in ha-group-main cu pveelite:50/pve1:33
- replicare CT 108 si VM 201 la */15 min, nu */5 => RPO real 15 min
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01RRyaDj39hPQ89SZS6URRpS
Gasite la prima rulare reala a FAZA2 la VADECO. Toate trei importurile de firma
au picat, si scriptul a raportat "Successful: 3, Failed: 0".
1. sql/sys-grants.sql facea CREATE OR REPLACE DIRECTORY DMPDIR AS 'C:\DMPDIR'
neconditionat. Ruleaza in pasul 04, deci DUPA importul contafin-ului din 03:
importul acela reusea cu calea corecta, iar obiectul era mutat imediat dupa.
Pe VADECO, unde procesul Oracle nu ajunge la nicio cale de pe C:, esecul a
aparut abia in faza 2, ca ORA-39002 / ORA-39070 / ORA-29283 - ore mai tarziu
si fara nicio legatura vizibila cu pasul care il provocase.
E aceeasi clasa de defect ca cel reparat in ec66377 pentru pasul 02, dar
ascuns intr-un fisier .sql, deci corectia de atunci l-a ratat. Acum calea
existenta se pastreaza si se raporteaza, ca in grants-public.sql; se creeaza
doar daca DMPDIR lipseste cu totul, caz in care se si avertizeaza ca pasul 01
nu a rulat.
2. 05-import-companies.ps1 incrementa $successCount si pe ramura de cod de
iesire nenul, iar numarul de obiecte de dupa import nu era verificat deloc.
Rezultatul: trei scheme goale raportate ca importate cu succes, faza 2
terminata "cu observatii", si defectul descoperit doar pentru ca schemele
goale sar in ochi la verificare.
Acum: 0 obiecte inseamna esec, oricare ar fi codul de iesire - un import care
lasa schema goala nu e un succes. Codul 5 ramane acceptat (ORA-31684 pe user,
ORA-39082 pe obiecte compilate, normale la ROA), orice alt cod nenul e esec.
Sumarul si codul de iesire spun adevarul, deci FAZA2.cmd se opreste pe
:esec_05 in loc sa continue peste un import inexistent.
3. 07-verify-installation.ps1 verifica acum ca baza chiar poate SCRIE in DMPDIR,
printr-o runda UTL_FILE (deschide, scrie, sterge). Calea din dba_directories
e doar un sir de caractere si nu spune nimic despre acces - exact motivul
pentru care New-OracleDirectory primise deja acelasi tratament in ec66377.
Verificarea asta ar fi prins defectul de mai sus inainte de faza 2.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01SzF1hf4aFS1tmJWpPMiwGp
Continuarea corectiei 3 din ec66377. Aceea rezolva doar jumatatea vizibila a
problemei; jumatatea ascunsa ar fi lovit la primul reboot al serverului, dupa
plecarea de la client. Gasit la VADECO, verificat pe loc.
1. ORA-12514 la toti clientii, cu baza perfect sanatoasa.
TNS_ADMIN de masina nu decide doar de unde se citeste sqlnet.ora: instanta
rezolva de acolo si aliasurile din tnsnames.ora. La Oracle XE LOCAL_LISTENER
e implicit aliasul LISTENER_XE, definit doar in tnsnames.ora din Oracle Home.
Cand serviciul reporneste dupa ce ROAClient a pus TNS_ADMIN pe folderul
instantclient-ului, aliasul nu se mai rezolva, instanta nu se mai
inregistreaza la listener, si atunci: v$instance OPEN, v$pdbs READ WRITE,
listener pornit pe 0.0.0.0:1521, lsnrctl arata doar CLRExtProc, si absolut
orice client primeste ORA-12514.
Capcana e de timp, nu de continut: o instanta pornita inainte ca TNS_ADMIN
sa existe nu il vede, deci instalarea pare impecabila si cade la primul
reboot. Reprodus la VADECO cu un simplu Restart-Service OracleServiceXE.
Pasul 01 scrie acum si tnsnames.ora in TNS_ADMIN (aliasul ROA pentru
ROAClient - sablonul livrat cu el arata spre HOST=SERVER_ROA, inexistent -
plus LISTENER_XE pentru instanta) si, mai important, fixeaza LOCAL_LISTENER
pe adresa literala. Doar asta din urma rezista si daca ROAClient se
instaleaza dupa kit, sau daca folderul instantclient se muta.
2. ORA-01017 desi parola e corecta.
Cu SQLNET.ALLOWED_LOGON_VERSION_SERVER=8 serverul autentifica orice client
pre-12c pe baza verificatorului 10G. Un cont fara 10G in PASSWORD_VERSIONS
nu se mai poate conecta din Instant Client 10/11, si eroarea nu e ORA-28040,
ci ORA-01017 - fix cea care trimite pe pista parolei. Dupa o instalare 21c,
SYSTEM are doar 11G 12C; CONTAFIN_ORACLE scapa doar pentru ca pasul 01 ii
rescrie parola dupa ce a scris sqlnet.ora. Pasul 01 rescrie acum si parola
lui SYSTEM, din CDB$ROOT, cu aceeasi valoare.
Subtilitate: interogat din PDB, PASSWORD_VERSIONS al unui utilizator comun
ramane cel vechi si dupa reparatie, desi autentificarea foloseste definitia
din root si functioneaza. Coloana nu e o dovada pentru SYSTEM; conectarea e.
3. Pasul 07 verifica acum ce nu se vede pe hartie.
Toate cele trei erori trec de verificarile de pana acum: fisierul exista,
parametrul e setat, contul e OPEN, obiectele sunt valide. Sectiunea noua
"Conectivitate client vechi (Instant Client)" verifica unde se citeste
efectiv sqlnet.ora, daca tnsnames.ora din TNS_ADMIN mai e sablonul, daca
LOCAL_LISTENER e alias sau adresa, ce verificatoare de parola au conturile,
si - singurul lucru care le prinde pe toate - face o conectare adevarata cu
Instant Client-ul gasit pe masina. La esec, raportul spune si unde sa te
uiti. Parametri noi: -ContafinPassword, -InstantClientDir.
4. Get-ServerLanIPv4, in biblioteca.
Pe serverele la care intram prin Tailscale, un tnsnames.ora cu 100.x nu duce
nicaieri de pe o statie. Functia alege IP-ul din LAN sarind peste Tailscale
(100.64.0.0/10) si APIPA, dupa ruta implicita cand sunt mai multe placi.
Get-ListenerHost o foloseste si el la fallback-ul pe 0.0.0.0, unde inainte
lua prima adresa nefiltrata.
La VADECO a mai fost nevoie de o corectie manuala, in afara kitului: listener.ora
avea HOST = <nume>.ts.net, deci pornirea listenerului depindea de Tailscale.
Regula generala e in documentatie.
Detaliile, cu dovezi si comenzi de diagnostic: docs/lectii-conectare-client-oracle.md
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01SzF1hf4aFS1tmJWpPMiwGp
Starea instalarii pe serverul nou, ruta de transfer a DMP-urilor prin
DBMS_DATAPUMP + IIS (serverul vechi e 11.2.0.2 si nu are shell), capcana cu
discul C: inaccesibil procesului Oracle, si pasii ramasi: firmele, tnsnames.ora
al ROAClient si sqlnet.ora in TNS_ADMIN.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01SzF1hf4aFS1tmJWpPMiwGp
Gasite la instalarea de productie VADECO (Oracle 21c XE, Windows Server 2019).
1. Pe serverul VADECO procesul Oracle nu poate atinge nicio cale de pe C:,
nici macar C:\Windows\Temp, desi ACL-urile sunt corecte si serviciul ruleaza
ca NT SERVICE\OracleServiceXE. D: merge cu exact acelasi grant. Calea DMP
era insa hardcodata "C:\DMPDIR" in 01, 02, 05, 06 si in biblioteca, deci
instalarea nu se putea muta. Acum e parametrul -DmpDir, expus ca /dmpdest:
in FAZA1.cmd si FAZA2.cmd si transmis tuturor pasilor.
Cel mai perfid era pasul 02: recrea DIRECTORY DMPDIR pe 'C:\DMPDIR' peste
valoarea pusa de 01. Chiar cu restul instalarii mutata, SYS.NEWSCHEMA ar fi
cautat FIRMANOUA.dmp in alta parte, iar adaugarea unei firme noi ar fi picat
peste luni, fara legatura vizibila cu instalarea.
2. New-OracleDirectory compara doar siruri de caractere: verifica ce scrie in
dba_directories, nu daca baza chiar poate scrie acolo. Acum face un
UTL_FILE round-trip si esueaza pe loc, cu explicatia cauzei. Inainte,
directorul inutilizabil trecea drept bun si importul cadea abia in impdp cu
ORA-29283, la zeci de linii distanta. Valoarea de retur nici nu era
verificata in 01/03/06 - de aici si "True" ratacit in log.
3. Instalarea ROAClient seteaza TNS_ADMIN de masina spre instantclient-ul ei.
Serviciul Oracle mosteneste variabilele de masina, deci citea sqlnet.ora de
acolo - unde nu exista niciunul - si nu din Oracle Home, unde il scria pasul
01. Compatibilitatea pentru clienti vechi nu se aplica, iar statiile ar fi
primit ORA-28040 cu fisierul scris corect, in locul gresit. Pasul 01 scrie
acum sqlnet.ora si in TNS_ADMIN cand difera.
4. Pasul 05 lega schemele de DMP-uri cu "^$schema[_\.]", deci schema DANUBE
putea primi DANUBE_20200914.dmp - datele altei firme, fara avertisment.
Numele exact are acum intaietate, prefixul se accepta doar daca e unic, iar
ambiguitatea se raporteaza.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01SzF1hf4aFS1tmJWpPMiwGp
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
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>
