Constatat la VADECO pe 2026-08-28: pe serverul acela actualizarea ROA nu
aplicase NICIODATA un script, desi jobul raporta succes de la instalare.
PACK_UPDATE nu aplica el scripturile - genereaza D:\DMPDIR\script_master.sql
si lanseaza un sqlplus EXTERN, apoi se termina. Deci UPDATEROA_ZILNIC
raporteaza starea lansarii, nu a actualizarii: SUCCEEDED in ~5 secunde chiar
si cand nu s-a aplicat nimic. Scriptul generat incepe cu
"CONNECT CONTAFIN_ORACLE/...@ROA" (aliasul vine din NOM_FIRME.NUME_SERVER)
si are WHENEVER SQLERROR EXIT, deci iese la prima linie daca aliasul nu se
rezolva.
Lantul cauzal: sqlplus-ul lansat de baza mosteneste mediul serviciului
Oracle. La o instalare noua instanta porneste INAINTE ca 01-setup-database
sa scrie TNS_ADMIN de masina, deci serviciul nu il are si cade pe
tnsnames.ora din Oracle Home. La 21c XE home-ul e read-only, deci fisierul
real e in product\21c\homes\OraDB21Home1\network\admin, iar acolo Oracle
genereaza doar XE, LISTENER_XE si ORACLR_CONNECTION_DATA - fara ROA.
Rezultat: ORA-12154, tacut. Perfid: tnsping ROA REUSESTE dintr-o sesiune
interactiva, pentru ca aceea are TNS_ADMIN.
Eroarea era mascata dublu - jobul zicea SUCCEEDED, iar emailul de raportare
nu pleaca oricum (ORA-29279, SMTP-ul romfast nu anunta AUTH).
01-setup-database.ps1 scrie acum aliasul si in tnsnames.ora al Oracle
Home-ului, cu acelasi IP din LAN. Blocul se IMBINA in fisierul existent:
XE, LISTENER_XE si ORACLR_CONNECTION_DATA raman neatinse, pentru ca de ele
depind extproc si inregistrarea instantei la listener. Cu backup si
idempotent - regexul consuma si comentariile lipite deasupra lui "ROA =",
altfel antetul se dubla la fiecare rulare (prins de test).
Testat unitar (fisier Oracle fara ROA, idempotenta peste 4 rulari, ROA
preexistent cu alt IP la mijloc, fisier inexistent, paranteze echilibrate,
fara BOM) si end-to-end pe o copie a fisierului real de pe serverul VADECO:
tnsping ROA OK, sqlplus CONTAFIN_ORACLE@ROA conectat in XEPDB1, zero ORA-,
XE si LISTENER_XE inca se rezolva.
docs/lectii-actualizare-roa-alias-tns.md are diagnosticul complet, inclusiv
cum verifici ca actualizarea chiar s-a aplicat: script_master.log si
SCHEMA.versiune, NU statusul jobului. Contine si capcana ca randurile din
SCHEMA.versiune vin cu dump-ul la import, deci o schema proaspat importata
pare la zi fara ca actualizarea sa fi rulat vreodata local.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01X9Sa54oFKpE2XhD6A7NTch
Commit-ul precedent (1c6ab0f) sustinea ca resetarile adaptorului USB LAN sunt
cauzate de un mouse defect care se re-enumera de ~1000 de ori pe zi pe acelasi
controller xHCI. Testul o infirma.
Portul mouse-ului dezactivat la 11:24:04; la 11:31:52 adaptorul s-a resetat
oricum, cu 0 re-enumerari de mouse si aceeasi semnatura de eroare
"xhci_hcd 0000:00:14.0: WARN Set TR Deq Ptr". Corelatia initiala era
coincidenta - mouse-ul se re-enumera la fiecare ~60 s, deci orice eveniment de
pe nod pica la cateva secunde dupa unul.
Ce ramane adevarat: mouse-ul e defect (1127 re-enumerari fata de 1 a tastaturii
pe acelasi hub) si merita inlocuit, dar e o problema separata.
Cauza resetarilor r8152 redevine necunoscuta - 6 resetari spontane in 20 h,
fara tipar. Suspecti netestati: adaptorul, portul/cablul USB3, controllerul,
alimentarea pe USB3. Mutarea pe eno1 redevine reparatia principala, fiindca
ocoleste intrebarea cu totul.
Sectiunea e pastrata cu ipoteza si infirmarea ei, ca sa nu fie reluata.
Nota buna: la resetul din 11:31:52 hotplug-ul a reatasat interfata in 4
secunde si corosync a reformat membership 1.1f4 cu 3 membri - un hopa de 10
secunde in loc de 16 ore.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01VAEUqrv26jCM5KwAPtkHb8
Trei lucruri gasite continuand handoff-ul de la incidentul pveelite.
1. Replicarea oracle-backups taia snapshoturile doar pe sursa. Pe destinatie
nu curata nimeni, deci din 25.04 se adunasera 11.886 snapshoturi tinand
941G pe pvemini - nodul cu toata productia, ajuns la 93%. Adaugat
KEEP_SNAPS_DEST=288 (72h). Dupa curatarea restantei: 93% -> 44%,
1,01T liberi. Verificat ca rularea cron urmatoare pastreaza fix 288.
Stergerea pe interval (ds@a%b) prinde si snapshoturile @failback_/@init_
dintre capete, deci scriptul sterge cate unul; intervalul s-a folosit o
singura data, manual, dupa ce s-a verificat ca nu exista non-repl_.
2. pvemini-down-alert.sh rula din cron fara PATH, iar ha-manager e in
/usr/sbin: sectiunea "HA status" iesea goala tacut la fiecare alerta.
3. Resetarile adaptorului USB LAN nu erau intamplatoare. Un mouse optic
defect se re-enumera de ~1000 de ori pe zi pe acelasi controller xHCI
(0000:00:14.0) ca adaptorul de retea; tastatura de pe acelasi hub are o
singura enumerare. Erorile "xhci_hcd WARN Set TR Deq Ptr" apar lipite de
fiecare resetare r8152, la 3 secunde dupa cate o re-enumerare a mouse-ului.
Portul mouse-ului dezactivat din sysfs ca experiment reversibil.
Punctul cu exportul NFS "inexistent" din planul de preventie era alarma
falsa: exportul e viu, doar ca nu e storage Proxmox. Marcat ca atare.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01VAEUqrv26jCM5KwAPtkHb8
Adaptoarele Realtek RTL8156 (r8152) sunt placa de retea principala pe DOUA
noduri, nu doar pe pveelite: pve1 are enx6c1ff759e2cb ca bridge-port, exact
aceeasi configuratie si aceeasi vulnerabilitate. pvemini e in regula, are Intel
igc pe PCIe.
Defectul nu e resetul USB in sine, ci ca interfata recreata nu mai ajunge inapoi
in vmbr0: e declarata "inet manual", fara auto si fara allow-hotplug, deci se
ridica doar ca efect secundar la boot. Nodul ramane pornit si invizibil, la
nesfarsit - 16 ore pe pveelite in noaptea asta, plus inca un reset azi la 10:31,
in timp ce lucram la asta.
Regula udev prinde reaparitia interfetei si porneste o unitate systemd care da
ifreload -a. Am ales ifreload, nu ifup, din doua motive: interfata e port de
punte si doar ifreload reface legatura cu vmbr0, si e comanda verificata in teren
- exact ea a readus pveelite in retea de doua ori azi.
Doua capcane platite, amandoua consemnate in fisiere ca sa nu se reia:
1. Prefixul 70- NU functioneaza. ID_NET_DRIVER e populat abia de
80-net-setup-link.rules, deci la 70- variabila e goala si regula nu se
potriveste - tacut, fara nicio eroare. udevadm test citea fisierul, dar RUN-ul
nu aparea in lista finala. Prima rulare a testului a "reusit" doar pentru ca
a lucrat plasa de siguranta la 90 s, nu regula. Cu 99-, revenirea e in 8
secunde.
2. PowerShell inghite ghilimelele cand paseaza argumente catre ssh, iar nodul
primea [ = r8152 ] in loc de [ "$d" = r8152 ]. Scripturile remote se trimit
acum codificate base64, nu prin niveluri de citare.
Testat cu reset USB real pe pveelite (deautorizare/reautorizare pe magistrala,
adica exact ce face controllerul cand cedeaza singur): revenire in 8 secunde,
unitatea usb-lan-hotplug@eth0.service pornita si terminata cu succes. Instanta e
eth0 pentru ca evenimentul add precede redenumirea in enxMAC - unitatea ignora
%I si reaplica toata configuratia, deci nu conteaza.
8 secunde e sub tokenul corosync de 10 s, deci un reset USB nu ar mai trebui nici
macar sa scoata nodul din cluster.
Testul isi armeaza singur o plasa de siguranta - ifreload -a programat la 90 s -
ca o regula gresita sa nu ceara drum pana la nod. A si folosit, la prima rulare.
Pe pve1 am instalat fara testul distructiv, acolo ruleaza CT 101 si CT 110;
verificat neinvaziv cu udevadm test.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01VAEUqrv26jCM5KwAPtkHb8
Nodul nu s-a oprit niciodata. La verificarea de azi avea uptime 17h46m, cu boot
pornit la 27.08 ora 16:03:06 - a mers toata noaptea, fara retea. Jurnalul
continua cu 58.454 de linii dupa 17:26:44, ceea ce inchide definitiv discutia
alimentare vs retea.
Vinovatul, din jurnalul kernel: Realtek RTL8156B (0bda:8156, driver r8152) pe
usb 2-3. La 16:01:45 si la 17:26:41 adaptorul s-a resetat si a fost re-enumerat.
Kernelul sterge interfata si o recreeaza - dar nimeni nu o readauga in vmbr0 si
nu o ridica, pentru ca nu exista regula de hotplug. Din acel moment masina merge
perfect si e invizibila in retea.
Partea care merita retinuta e de ce la 16:01 si-a revenit si la 17:26 nu. La
16:01 LRM-ul HA era activ, deci watchdog-ul era armat: pierderea retelei a dus la
pierderea quorumului, watchdog-mux a expirat la 16:02:39 si a resetat masina la
16:02:44 - repornire care a readus reteaua din intamplare, pentru ca la boot
interfetele se ridica prin auto. La 17:26 fence-ul mutase deja vm:109 pe pvemini,
LRM-ul era idle, watchdog-ul nearmat. Nimic nu a mai repornit masina. Singurul
lucru care "repara" defectul asta era un efect secundar, nu un mecanism proiectat
- pe un nod fara servicii HA, aceeasi defectiune devine permanenta si tacuta.
Reparat cu ifreload -a de la consola, la 09:49. Restul verificarii e curat: ZFS
ONLINE fara erori, cluster 3/3, SMART fara FAILED, replicarea se reia singura.
Reparatia de fond intra in Tier 1: eno1 exista si e functional, doar ca nu are
cablu (Link detected: no). Adaptorul USB e cauza a doua incidente pe nodul asta.
Am scris si ordinea operatiilor, pentru ca inversata te lasa fara retea cu drum
pana la nod.
Prima rulare reala a scriptului a scos la iveala trei defecte ale lui, toate
reparate aici:
- tiparele de semnatura hardware prindeau linii normale de boot ("Registered
thermal governor", "NMI watchdog: Enabled", "EDAC MC: Ver: 3.0.0") si produceau
un verdict de defect hardware care contrazicea concluzia corecta din acelasi
bilant. Strans tiparele si filtrat prin -p warning; verificat pe nod: 0
potriviri.
- LRM idle era raportat ca "stare neclara". E starea normala a unui nod fara
servicii HA - iar scriptul spune acum explicit ca idle inseamna watchdog
nearmat, adica exact motivul pentru care caderea de la 17:26 nu s-a auto-reparat.
- Tailscale era raportat [ok] desi e delogat: systemctl is-active zice active, dar
tailscale status zice "Logged out". De aici si cele 27 de zile de offline.
Consemnat si raspunsul la intrebarea cu magic packet, cu MAC-urile ambelor
interfete, ca sa nu se reia: WoL nu ar fi ajutat oricum, masina nu era oprita.
Dupa mutarea pe eno1 devine insa realmente utilizabil.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01VAEUqrv26jCM5KwAPtkHb8
Intrebarea "nu-l putem trezi cu un magic packet?" a scos la iveala ceva ce
schimba diagnosticul, nu doar raspunsul la ea.
Pe WoL, pe scurt: nu se poate nici macar incerca. MAC-ul lui pveelite nu mai
exista nicaieri - intrarea ARP a expirat pe pvemini (INCOMPLETE), pe pve1
(FAILED), in tabela statiei de admin si pe LXC-urile de pe LAN; nodurile au IP
static, deci nu exista lease DHCP; in documentatie nu e consemnat. Raman tabela
routerului sau citirea fizica de pe nod. Si chiar cu MAC-ul, placa de retea e pe
USB, iar un dongle USB e nealimentat in soft-off, deci nu asculta dupa magic
packet.
Partea care conteaza insa e alta: pveelite ARE placa de retea pe USB, si
deconectarea ei e modul de defectare deja documentat al acestui nod - incidentul
2026-04-20 a pornit exact de la un USB LAN disconnect, motiv pentru care tokenul
corosync a fost marit la 10 s. Un nod care si-a pierdut adaptorul de retea arata
din exterior identic cu unul oprit: fara ping, fara ARP, fara corosync, fara SSH.
Toate observatiile din incident sunt compatibile cu ambele scenarii, iar eu
scrisesem doar unul.
Pentru 16:01 dovezile inclina in continuare spre repornire - curba de memorie din
RRD se reseteaza (2,43 GB la 16:00 -> 2,10 GB la 16:30, sub valoarea de dupa boot)
si NFS-ul se reataseaza. Pentru 17:26 nu exista niciun indiciu echivalent: nodul
pur si simplu a incetat sa fie vizibil, ceea ce o deconectare USB explica la fel
de bine ca o pierdere de alimentare. Am slabit corespunzator formularile din TL;DR
si din cronologie, unde afirmasem repornirea ca fapt.
Consecinta practica, pusa in document ca avertisment inainte de orice altceva:
prima observatie la fata locului e daca masina merge - ventilatoare, LED-uri,
imagine. Daca e pornita, nu a fost o cadere de alimentare, jurnalul e intact si
reparatia e la dongle, cablu sau portul de switch. Nu apasa butonul de power
inainte sa te uiti.
In script, pasul 1 nu mai citeste boot-urile dupa index - indexurile difera intre
cele doua scenarii si ar fi dus la concluzii gresite. Acum taie jurnalul dupa ora
si pune intai testul decisiv: exista intrari dupa 17:26:44? Daca da, masina a mers
mai departe si a cazut doar reteaua, iar verdictul si remediile se schimba complet.
Adaugat si un bloc de diagnostic pentru adaptorul USB (interfete, drivere, lsusb,
deconectari si evenimente de link in jurnalul kernel).
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01VAEUqrv26jCM5KwAPtkHb8
pveelite s-a resetat singur la 16:01 si a murit definitiv la 17:26, pe o masina
complet idle (CPU 0,4%, load 0,10, RAM 2,15 din 15,3 GB). E inaccesibil si la
nivel L2 - ip neigh raporteaza FAILED - deci diagnosticul nu se poate duce mai
departe de la distanta.
Ce exclud dovezile: nu e resurse (RRD-ul de pe pvemini arata nodul inactiv), nu e
retea (niciun flap knet in 7 zile in afara zilei de azi, pve1 si pvemini stabile
de la 13:20), nu e UPS (OL, baterie 100%, input 239,6 V), nu e comanda de la noi
(singura rulare ups-shutdown de azi a fost dry-run, iar in jurnal nu exista niciun
poweroff catre .202). Ramane alimentarea sau hardware-ul.
Oprirea de la pranz a fost planificata, nu o cadere: qmshutdown:303 de la root@pam
la 12:25, statia de admin conectata la 12:28:59, poweroff curat pe toate trei la
12:33-12:36. pveelite a revenit normal la 13:20 si a mers 2h40m. Cedarea vine deci
dupa ciclul de oprire-pornire, ceea ce intareste ipoteza de alimentare.
Impactul pe productie e zero - pe nod nu era decat CT 301, care e template oprit,
iar vm:109 era oprit si a fost recuperat curat pe pvemini de fence la 17:28.
Replicarea catre pve1 e intacta si la zi (RPO 15 min respectat). Ce ramane in
aer: clusterul sta pe 2 voturi din 3, fara marja, si replicarea catre pveelite e
oprita pe toate cele 9 job-uri.
Trei lucruri au mers pentru ca au fost reparate dupa aprilie: fence-ul a recuperat
un singur serviciu si i-a respectat starea oprita, consolidarea sarcinii pe
pvemini/pve1 a facut caderea un non-eveniment, iar alerta a plecat pe email la
17:31.
Scriptul de verificare se ruleaza cand nodul e pornit fizic la loc. Ordinea nu e
intamplatoare - intai de ce a cazut, din jurnalul boot-urilor care abia acum devin
citibile, si abia apoi starea. Daca jurnalul e tacut inainte de ambele caderi,
scriptul NU declara nodul sanatos: da verdict de alimentare/hardware si cere
testarea sursei si a memoriei inainte ca pveelite sa fie iar tinta de failover.
Exact capcana din 2026-04-20, unde pvemini a repornit singur si parea in regula.
Verificat pe clusterul viu: cei trei parseri (voturi quorum, job-uri de replicare
esuate, stare LRM) intorc 2, 9 si "LRM mort", adica starea reala de acum.
Doua lucruri colaterale, consemnate in document, nu rezolvate aici: tailscaled e
mort pe pveelite de 27 de zile, deci nu exista acces out-of-band, iar textul
alertei pveelite-down-alert.sh trimite la un export NFS care nu mai e in
storage.cfg.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01VAEUqrv26jCM5KwAPtkHb8
Utilizatorul a confirmat ca acumulatorii au fost schimbati pe 2024-01-09 (data
aproximativa). Asta scoate la iveala o limita a evaluarii pe tendinta: NUT a fost
instalat pe 2025-10-06, cand acumulatorii aveau deja ~21 luni, deci linia de baza
NU e o baterie noua. Raportul de 1.16x masoara degradarea peste o baterie care
isi pierduse deja o parte din capacitate. Verdictul EXCELLENT e corect ca
tendinta, dar nu inseamna "ca noua".
Varsta devine criteriu separat, citit din /etc/nut/battery-install-date:
sub 3 ani niciun efect, 3-4 ani nota vizibila in raport, peste 4 ani forteaza cel
putin FAIR indiferent de tendinta. Fara fisier, scriptul merge normal si cere
completarea lui.
Verificat pe pvemini cu testul de baterie anulat, pe trei date: 32 luni (reala)
-> EXCELLENT, 39 luni -> EXCELLENT cu nota, 56 luni -> FAIR fortat. Fallback-ul
fara fisier intoarce varsta goala, nu eroare.
Un bug prins la verificare: extragerea datei lua prima potrivire din fisier, care
era un an dintr-un comentariu, si dadea varsta 0. Ambele extrageri sar acum peste
liniile care incep cu #.
Prag de 3 ani: 2027-01-09. Prag de 4 ani, cand testul incepe sa avertizeze
singur: 2028-01-09.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01RRyaDj39hPQ89SZS6URRpS
Verdictul se calcula din CHARGE_DROP, dar la acest UPS battery.charge nu e o
masuratoare independenta: driverul nutdrv_qx / Voltronic-QS-Hex o deduce liniar
din tensiune intre battery.voltage.low (20.8V) si .high (26.0V). Verificat pe
toate probele din 11 luni: 25.76V -> 95.4% -> raportat 95%.
Traduse in tensiune, pragurile vechi cereau o cadere de 3.70V pentru FAIR (primul
prag care trimite severity warning) si 4.74V pentru POOR, intr-un test de 40 de
secunde. Maximul observat in 11 luni a fost 2.59V. De asta raportul a iesit
EXCELLENT 11 luni la rand si ar fi facut-o si cu bateria pe moarte.
Evaluarea se face acum pe tendinta: mediana ultimelor 3 rulari fata de mediana
primelor 6, plus o plasa de siguranta pe tensiune absoluta (<25.0V forteaza FAIR,
<24.0V forteaza POOR). Fereastra de 3 impiedica o luna atipica sa declanseze
singura alarma - verificat pe feb 2026 (2.59V), care nu bascuelaza verdictul.
Istoricul se tine in /var/log/ups-battery-trend.csv, populat cu cele 14 rulari
extrase din jurnal (2025-10-06 -> 2026-08-01), ca linia de baza sa fie valida
imediat si nu peste 9 luni.
Starea la zi: baza 1.82V, recent 2.12V, raport 1.16x -> EXCELLENT. Cresterea de
~16% in 10 luni e reala dar sub banda de avertizare; FAIR s-ar da la 2.73V.
Instalat pe pvemini in /opt/scripts/, verificat cap-coada cu testul de baterie
anulat, ca sa nu descarce bateria: tendinta calculata corect, template-urile
regenerate cu campurile noi, notificarea PVE::Notify trimisa cu succes.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01RRyaDj39hPQ89SZS6URRpS
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
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
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
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>
