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
- Create cluster/ for Proxmox cluster infrastructure (SSH guide, HA monitor, UPS)
- Create lxc108-oracle/ for Oracle Database documentation and scripts
- Create vm201-windows/ for Windows 11 VM docs and SSL certificate scripts
- Add SSL certificate monitoring scripts (check-ssl-certificates.ps1, monitor-ssl-certificates.sh)
- Remove archived VM107 references (decommissioned)
- Update all cross-references between files
- Update main README.md with new structure and navigation
Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
