Sectiunea 7 acopera tot drumul: ce contine de fapt fiecare profil (parola in
fisier, keypair de profil, keypair global — se afla cu -noRegistry=y, fara GUI),
folderul de pregatire, conversia la publickey cu -storePw=n / -pk=a, verificarea
care prinde un Ctrl+S uitat, si importul cheii pe VM 303. Include lista celor 11
profile cu numele scurtate la copiere si serverul fiecaruia.
Sectiunea 6 tine acum toate cele 5 chei publice (doi angajati, trei ale statiei
de birou) si tabelul pe servere, verificat pe amprenta, nu pe comentariu.
Capcane platite pe drum, notate ca atare:
- stergerea keypair-urilor GLOBALE din User keypair manager lasa fara
credentiala orice profil care se baza pe ele — asa a ramas mut
romfast_bitvise.tlp;
- vadeco.tlp avea cheia privata salvata in profil, deci s-ar fi dus cu fisierul;
- abcval (Bitvise 9.32) respinge Ed25519, acolo intra doar RSA;
- conpress blocheaza IP-ul la conexiuni repetate: se exclude in Access control,
nu doar se sterge din lista de blocati.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01FnMP82sffxQYxWRjy5sfKo
Cheile publice ale angajatilor (VM 303, VM 304) se tin versionate in
docs/chei-publice/ — acelasi fisier serveste si pentru "Add File", si pentru
"Remove File", deci revocarea nu mai depinde de un fingerprint copiat de mana.
scripts/bitvise-chei.ps1 tine lista celor 11 servere Bitvise valide si ruleaza
spksc cu -unat=y (List / Add / Remove) fara sa se blocheze in prompturi.
Doua lucruri descoperite si notate in doc:
- romfast_bitvise.tlp si 10.0.20.36:22122 sunt acelasi server (liste de chei
identice); intrarea a doua ramane ca ruta de rezerva, fiindca parola din
bitvise_10.0.20.36.bscp a expirat si se conecteaza cu -keypairFile;
- abcval (Bitvise SSH Server 9.32) respinge Ed25519 cu KeyNotSupported — acolo
e nevoie de o pereche RSA.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01FnMP82sffxQYxWRjy5sfKo
Vazut pe 27.08.2026 la 16:27: Status a afisat "Task programat: NEINREGISTRAT"
desi taskul rula (State=Running, proces ups-monitor.ps1 -Mode Run viu, PID
3308). Trei rulari imediat urmatoare au raportat corect Running - deci o
eroare tranzitorie a Task Scheduler-ului, prezentata drept certitudine.
Cauza: catch-ul trata la fel "nu exista" si "n-am putut intreba", si alegea
mesajul cel mai alarmant. Intr-o pana reala ar trimite pe cineva sa reinstaleze
un monitor care de fapt merge.
Acum: absenta taskului se stabileste prin $null -eq $task, nu prin exceptie;
o interogare esuata spune NEDETERMINAT si arata eroarea; iar daca doar
Get-ScheduledTaskInfo cade, se afiseaza starea fara ultima rulare.
Verificat cu tokenizer-ul (0 erori) si pe server dupa deploy.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01RRyaDj39hPQ89SZS6URRpS
set-praguri.ps1 schimba pragurile de oprire fara sa atinga parola SMTP si
reporneste taskul, pentru ca ups-monitor.ps1 citeste configuratia o singura
data, la pornirea buclei.
trace-baterie.ps1 scrie o citire la fiecare 20 s intr-un CSV local, iar
start-trace.ps1 il inregistreaza ca task programat sub SYSTEM. Local si
detasat, pentru ca intr-o pana reala reteaua cade odata cu curentul daca
switch-ul nu e pe UPS: sesiunea SSH devine oarba si emailurile esueaza, deci
CSV-ul de pe server ramane singura sursa de date. Taskul are aceleasi
AllowStartIfOnBatteries / DontStopIfGoingOnBatteries ca monitorul - fara ele
Windows l-ar opri exact cand incepe ce vrem sa masuram.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01RRyaDj39hPQ89SZS6URRpS
Lantul de protectie are doua jumatati. Prima - "UPS-ul chiar raporteaza trecerea
pe baterie?" - e deja dovedita de perechile de evenimente Kernel-Power 105 de la
panele reale din 2026. A doua - decizie, alerta, oprirea curata a Oracle - nu
avea cum sa fie exercitata decat asteptand o pana.
Acum monitorul accepta un SIMULARE.json care suprascrie citirea de alimentare.
Doua garzi, ca un fisier uitat sa nu opreasca serverul pe date inventate:
"expira" e obligatoriu si e sters automat la depasire, iar oprirea e in gol daca
nu se cere explicit "dryRun": false. Cat e activa, fiecare ciclu scrie WARN in
log si -Mode Status o afiseaza.
test-battery.ps1 conduce simularea si urmareste logul; sterge fisierul si daca e
intrerupt. Cu -ConfirmReal 'DA-OPRESTE-SERVERUL' devine repetitie reala pentru o
fereastra de mentenanta - singurul mod de a masura cat dureaza shutdown immediate
pe baza de productie, informatie de care depinde alegerea pragurilor.
Validat in gol pe 27.08.2026: detectie la 15:36:09 + email de pana, apoi exact
trei cicluri de confirmare, declansare pe pragul de 35% la 15:36:40 si secventa
parcursa integral. Oracle a ramas Running.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01RRyaDj39hPQ89SZS6URRpS
ViewPower nu putea dialoga cu acest UPS: 5777 de "QPI return(NAK" si zero
citiri reusite in fereastra 6-10 august, pentru ca UPS-ul vorbeste HID Power
Device standard, nu dialectul text Voltronic. Serviciile au fost dezactivate
pe 10.08.2026 la 22:34, lasand serverul fara nicio alertare 17 zile. Nici
inainte nu exista: emailReceivers = 0, iar excuteProgram era gol, deci Oracle
nu era oprit curat oricum.
UPS-ul comunica insa perfect cu Windows pe canalul HID - dovedit de perechile
de evenimente Kernel-Power 105 la panele reale din 2026.
Monitorul nou citeste GetSystemPowerStatus, acelasi semnal pe care il foloseste
Windows pentru propria actiune la baterie critica. Alerteaza pe email la
trecerea pe baterie, la revenirea curentului si cand UPS-ul nu mai comunica -
cazul care a trecut neobservat. Opreste curat listenerul, apoi instanta cu
shutdown immediate, apoi Windows-ul, inaintea pragului brutal de 20% al
Windows-ului.
Ruleaza ca task programat sub SYSTEM, cu AllowStartIfOnBatteries si
DontStopIfGoingOnBatteries - fara ele Windows ar fi oprit taskul exact cand
serverul trece pe baterie.
Validat pe 27.08.2026: citire, email, secventa de oprire in dry-run si
pierderea comunicatiei (alerta la exact 8 cicluri, apoi revenire). Pragurile
de 10 min / 35% sunt conservatoare, nu masurate - testul de autonomie reala
ramane de facut.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01RRyaDj39hPQ89SZS6URRpS
Script Python + bat care converteste automat FORALL/BULK_ROWCOUNT
din PACK_CONTAFIN.pck in FOR LOOP compatibil Oracle 10g.
Include pre/post validare, scriere atomica si diff afisare.
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
- ExecuteScriptOS.prc: runs PowerShell scripts via DBMS_SCHEDULER
- UpdateSQLPLUS.prc: runs SQL*Plus scripts via DBMS_SCHEDULER
- find_oracle_locations.sql: comprehensive script to discover all Oracle DB paths for backup/migration
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
