LXC 103 avea replicare ZFS zilnica (21:02 pve1, 21:03 pveelite) dar niciun
backup. Replicarea oglindeste starea curenta: o stergere sau o coruptie
ajunge pe toate nodurile la urmatorul sync, fara punct de revenire.
Adaugat in job-ul de containere usoare (zile impare 03:00, keep-last=2
keep-weekly=1) — 8.24 GB folositi, 4.3 GB arhiva. Rulat si un backup
initial, fiindca urmatoarea rulare automata era abia pe 13 august.
Ramane descoperit doar LXC 102, singurul `running` fara backup.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01MoFGxftQw92PX4Sdkn94pv
`backup-impare-adina` (la 2 zile) inlocuit cu `backup-lunar-adina`:
prima sambata din luna la 04:30, keep-monthly=3.
Ora 04:30 evita coliziunea cu job-urile pare/impare de la 03:30 — prima
sambata a lunii poate cadea in orice zi.
Notat in README ca `sat *-1..7` inseamna prima sambata: un job lunar adaugat
la mijlocul lunii nu ruleaza pana luna urmatoare.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01MoFGxftQw92PX4Sdkn94pv
VM 303 nu era in niciun job de backup dupa transformarea in full clone.
Adaugat `backup-impare-adina` (zile impare 03:30, storage backup,
keep-last=2 keep-weekly=1), pe zile impare ca sa nu se suprapuna cu VM 201
care ruleaza in acelasi slot pe zile pare.
Sectiunea "Backup Job Configuration" din README descria un job unic
(`backup-fbb668c0-726e`, daily 02:00) care nu mai exista de mult. Inlocuita
cu cele 8 job-uri reale.
Semnalate guest-urile fara backup: LXC 102 si 103, ambele `running`.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01MoFGxftQw92PX4Sdkn94pv
`qm move-disk <vmid> <disk> local-zfs --delete 1` esueaza intotdeauna pentru
zvol-uri: PVE respinge mutarea pe acelasi storage, iar conditia din
Qemu.pm:4688 e mereu adevarata fiindca numele volumului n-are sufix de format.
Nici storage-ul `local` nu e ruta de ocolire — n-are `images` in content.
Documentata metoda care functioneaza (zfs send/recv local + swap de volid),
asa cum a fost aplicata pe VM 303.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01MoFGxftQw92PX4Sdkn94pv
VM 303 rula ca linked clone din VM 300, deci template-ul contaminat nu putea
fi sters. Transformat in full clone si VM 300 eliminat din infrastructura.
Metoda: zfs send/recv local + swap de volid in config. `qm move-disk` nu era
o optiune — PVE respinge mutarea pe acelasi storage, iar pentru zvol-uri
conditia din Qemu.pm:4688 e mereu adevarata (numele n-are sufix de format).
- inventarele nu mai listeaza VM 300; VM 310 ramane singurul template
- clone-vm300.sh: comentariul spune de ce sursa e 310 (numele e istoric)
- handoff-ul sters la cererea utilizatorului; faptele care mai conteaza sunt
mutate inline in README-uri, ca sa nu ramana referinte moarte
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01MoFGxftQw92PX4Sdkn94pv
- parola permanenta RustDesk repusa de utilizator; VM 303 accesibil remote
- contul dedicat "fisiere" pe .122 NU se creeaza: se ramane pe romfast.
Sectiunea ramane ca referinta, marcata "nu executa fara cerere explicita".
Singurul punct deschis ramane decuplarea linked clone a VM 303 de template-ul
VM 300, urmata de stergerea VM 300.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01MoFGxftQw92PX4Sdkn94pv
- setup1 si defaultuser0 sterse; pe VM 303 a ramas doar contul romfast
- reteta de acces la \ROACENTRAL\temp fara drepturi de admin: "Everyone" pe
share nu inseamna anonim (guest blocat, LimitBlankPasswordUse=1), dar un
cont simplu din grupul Users primeste deja Modify prin Authenticated Users
- plan pentru sesiunea urmatoare: qm move-disk pe ambele discuri ca sa rupem
legatura de linked clone, apoi VM 300 poate fi sters definitiv
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01MoFGxftQw92PX4Sdkn94pv
Toate intalnite pe bune in timpul reparatiei VM 303:
- HideLocalAccountScreen nu functioneaza pe Win11 26100; OOBE cere oricum cont
- la ecranul OOBE nu introduce numele unui cont existent (agata fluxul)
- nu sterge defaultuser0 cat timp OOBE ruleaza; agentul QEMU raspunde ca
serviciu si mascheaza faptul ca OOBE nu s-a terminat (verifica quser)
- /generalize sterge HKLM\SYSTEM\MountedDevices => se pierd literele D: si E:;
volumele raman intacte, se reasigneaza cu Set-Partition
- sysprep readuce AutoAdminLogon=1
- RustDesk: MachineGuid regenerat => parola permanenta trebuie repusa
Stare finala verificata: volume Healthy, nedirty dupa oprirea fortata, zero
erori disk/Ntfs, NTLM catre .122 raspunde sub=0xc000006a.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01MoFGxftQw92PX4Sdkn94pv
SMB intre VM 303 si VM 201 era blocat de SID-ul de masina duplicat. Reparat
prin sysprep /generalize pe VM 303 insusi, nu prin mutare pe un VM nou:
sysprep schimba identitatea masinii, nu dezinstaleaza aplicatii.
SID: ...1850128657-3079265004-705332634 -> ...3853882515-1460096973-3208817208
Verificat dupa reparatie: 14/14 programe intacte, profilul romfast intact
(2944 MB, se rezolva corect, nu temporary profile), iar .122 evalueaza din
nou parola normal (sub=0xc000006a in loc de sub=0x0).
ATENTIE: IP-ul DHCP s-a schimbat 10.0.20.145 -> 10.0.20.101.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01MoFGxftQw92PX4Sdkn94pv
VM 300 `Win11-Template` nu a fost sysprep-uit: poarta numele ROACENTRAL si
SID-ul de masina al VM 201 (S-1-5-21-1850128657-3079265004-705332634).
Clonele lui mostenesc acea identitate, iar NTLM intre doua masini cu acelasi
SID de masina esueaza — de aici imposibilitatea accesarii share-urilor SMB
intre VM 303 si VM 201, in ambele sensuri.
VM 300 nu poate fi reparat in loc: e template read-only, iar VM 303 e linked
clone din el. Solutia: clona completa 300 -> 310, sysprep acolo, conversie in
template. Verificat pe o clona de proba: nume si SID noi la fiecare pornire.
- clone-vm300.sh: SOURCE_VMID 300 -> 310
- README-uri: VM 310 marcat ca template de clonare, VM 300 ca "nu clona"
- vm302-oracle-test: corectat exemplul care clona in VM 303 (deja ocupat)
- docs/handoff-smb-vm303-roacentral.md: probele, capcanele de sysprep, stare
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01MoFGxftQw92PX4Sdkn94pv
Serverul 10.0.20.36 a parut blocat 20 de minute (12:02-12:22). Nu a fost
blocaj, crash sau oprire: a intrat in standby S3 in urma unei actiuni de
power de la consola. BootId neschimbat, oracle.exe si tnslsnr.exe neintrerupte
din 15 iulie, zero erori in System/Application.
Dovada decisiva e listener.log: clienti serviti normal pana la 12:01:26, apoi
gaura totala pana la 12:22:03 - singura discontinuitate din toata ziua.
Remediere aplicata si verificata:
- somnul eliminat complet (powercfg /a nu mai listeaza nicio stare)
- butoane power si meniu Start -> Shut down; buton sleep -> Do nothing
- Sleep after era 600 s pe profilul DC, adica serverul ar fi adormit la 10 min
dupa o pana de curent; acum 0
- Critical battery action era Hibernate, imposibil dupa dezactivarea hibernarii;
corectat pe Shut down, praguri urcate 5%->20% / 7%->25% / 10%->40%
- ViewPower oprit si dezactivat: comunicatia cu UPS-ul era moarta (QPI NAK), iar
Windows gestioneaza UPS-ul nativ prin HID UPS Battery
- sonda roa2web care lovea listenerul la 30 s: oprita. Verifica portul 1521, adica
listenerul de productie, nu tunelul vending - raporta fals "sanatos". Tunelul e
dezactivat, era oricum cazut de la boot-ul din 15 iulie
Ramane, doar daca se repune vending in functiune: autorizarea cheii pe
79.119.86.134 (plink e respins de server dupa banner-ul de versiune).
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01RoM99w9qRELJefaWrtPRHo
DROP+CREATE in loc de ALTER TABLE MOVE: continutul e log fara valoare, iar
recrearea nu cere spatiu liber cat segmentul si nu tine tabela blocata cat ar
dura copierea. DROP e cu PURGE, altfel segmentul ramane in recyclebin si spatiul
nu se elibereaza. SYS.pINFO ramane INVALID dupa DROP, deci se recompileaza.
Scriptul de livrare: SVN r18010.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Rft5ofNa4Ux5VEh4YnhJRC
deploy.sh era documentat doar in README-ul VM 109; nu aparea nicaieri in
proxmox/README.md, deci nu il gaseai daca nu stiai deja ca exista. Iar
`deploy.sh --help` raspundea cu o singura linie pe stderr si exit 2 - o
unealta documentata trebuie sa se poata explica singura.
- deploy.sh: --help / -h cu utilizare completa (optiuni, ce verifica inainte
sa copieze, distributia pe noduri si de ce e asimetrica, ce face --guest cu
VM 109 oprit, si faptul ca nu atinge cron-ul). Exit 0 pentru --help, exit 2
cu mesaj pe stderr pentru optiune necunoscuta.
- proxmox/README.md: deploy.sh, vm109-patch-window.sh si check_servicing.ps1
in tabelul de fisiere, bloc "Deploy modificari" in Quick Start, plus intrari
in "Vreau sa..." pentru deploy, pentru patching si pentru simptomul
"Restore failed fara log RMAN".
- README VM 109: --help in lista de comenzi si un exemplu de output --check,
ca sa se vada diferenta dintre "DIFERA" si "LIPSESTE pe nod".
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01BhQBTegE4PiMPPaapLHjkc
Doar line endings, zero modificari de continut (verificat cu
git diff --ignore-cr-at-eol: fara diferente ramase pe aceste fisiere).
Fisierele aveau CRLF comis efectiv in repo, nu doar in working tree.
Sunt scripturi care ruleaza pe Linux (migrarea Oracle, LXC 171 claude-agent),
iar deployate direct din working tree bash le refuza cu
"$'\r': command not found" - exact capcana pe care .gitattributes (comis in
9475842) o previne de acum inainte pentru fisierele noi.
Nu sunt incluse fisierele .md/.sql din roa-windows-setup: acelea au
modificari reale de continut, in curs, si apartin altui commit.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01BhQBTegE4PiMPPaapLHjkc
SYS.INFO e log de aplicatie (SYS.pINFO din AUTH_PACK scrie ~7 randuri la fiecare
conectare, ~13.500 randuri / ~2 MB pe luna) si nimic din baza nu-l citeste. Creat
de installer in tablespace-ul SYSTEM si nepurjat niciodata, a umplut SYSTEM la doi
clienti si a oprit actualizarea cu ORA-01653 - eroarea apare pe orice script,
pentru ca AUTH_PACK scrie acolo la conectare.
SIGMA 03.08.2026 - ff_2026_07_29_02_COMUN_TVA11 picat pe MARCU
AUTOMOTIVE 08.08.2026 - 552.581 randuri / 80 MB, SYSTEM cu 5 MB liberi
Installer:
- sys-objects.sql: SYS.INFO (tabela + segment LOB) se creeaza in tablespace-ul
ROA, cu fallback pe SYSTEM daca ROA inca nu exista
- scheduler-jobs.sql: job nou SYS.SYSINFO_PURJARE_ZILNIC, zilnic 03:30, retentie
90 zile, stergere in transe de 10.000 randuri; creat ENABLED, pentru ca nu are
nimic de configurat iar uitat dezactivat reproduce chiar problema pe care o
rezolva. In schema SYS: privilegiile ANY nu se aplica pe obiectele SYS cat timp
O7_DICTIONARY_ACCESSIBILITY=FALSE
- uninstall-roa.sql: dezinstalarea sterge si jobul
- 00-INSTALL-ORACLE-XE.md / -SE.md: pas post-instalare pentru plafonul SYSTEM
(maxsize 2000M) si mutarea SYS.INFO la instalarile vechi
Documentatie noua (docs/diagnostic-spatiu-clienti.md): jobul DIAGSPATIU_ZILNIC si
pragurile lui, formatul emailurilor de alerta si cum se citesc din mbox-urile
Thunderbird, procedura de tunel SSH catre serverul unui client, triajul alertelor
si starea la 08.08.2026 pe fiecare client.
Reparatia la AUTOMOTIVE e deja aplicata in productie (plafon 600 -> 2000 MB,
truncate SYS.INFO): SYSTEM a trecut de la 65 MB la 1545 MB de crestere posibila.
Scriptul de livrare pentru ceilalti clienti e scris, dar nepublicat:
COMUN sys_2026_08_08_02_SYS_INFO_TABLESPACE_PURJARE.sql
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Rft5ofNa4Ux5VEh4YnhJRC
Pana acum deploy-ul se facea manual (`cp ... /opt/scripts/`), nedocumentat
nicaieri - de unde si fisierele weekly-dr-test-proxmox.sh.bak-* ramase pe
pveelite. deploy.sh face aceiasi pasi, dar refuza situatiile care au costat
deja timp:
- suprascrierea unui script AFLAT IN EXECUTIE: bash citeste scriptul
incremental de pe disc, iar suprascrierea unui test DR in curs (~18 min)
corupe executia;
- CRLF: bash pe Linux raspunde "$'\r': command not found";
- transfer trunchiat: bash -n local si inca o data pe nod dupa copiere;
- flag-ul vm109-debug.flag lasat in urma dupa deploy pe guest (dezarmeaza
permanent watchdog-ul, exact apararea care a prins incidentul 04-20).
Distributia pe noduri e asimetrica intentionat si e codificata explicit in
script: scripturile cluster-aware (test DR, patch window, watchdog) pe ambele
noduri fiindca urmaresc VM 109 dupa failover HA; ZFS/mirror doar pe pveelite
unde traieste datasetul; alertele si failover-ul doar pe pvemini, fiindca
reactioneaza la caderea pveelite - puse pe pveelite ar fi inutile si ar
inlesni exact split-brain-ul pe care incearca sa-l previna.
Verificarea "ruleaza acum" foloseste pgrep -f '[/]opt/scripts/x.sh'.
Parantezele nu sunt cosmetice: comanda trimisa prin ssh apare ea insasi in
lista de procese, deci forma fara paranteze se gaseste pe sine si raporteaza
orice script ca fiind in executie (verificat: exit 0 vs exit 1).
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01BhQBTegE4PiMPPaapLHjkc
Testul DR din 2026-08-08 a raportat "Restore failed" dupa 11 secunde, fara
niciun log RMAN. Cauza nu a fost restore-ul: KB5101001 fusese descarcat in
timpul testului din 2026-08-01 (singurul moment in care VM 109 e pornit),
a ramas staged dupa qm stop si s-a finalizat la boot-ul testului urmator.
Cronologie din Event Log-ul guest-ului:
06:00:58 RestartManager 10010 - nu poate reporni powershell.exe (restore-ul)
06:01:04 SCM 7034 - OpenSSH SSH Server terminat neasteptat
06:01:06 pveelite: client_loop: send disconnect: Broken pipe -> FAILED
06:01:38 VM-ul se reboteaza singur
Fereastra testului (Sambata 06:00) era in afara Active Hours (08:00-17:00),
deci pentru Windows era fereastra de mentenanta valida - iar VM 109 fiind
pornit doar in timpul testului, aceea era singura fereastra posibila.
Agravant: sshd nu avea acsiuni de recovery (RESET_PERIOD 0), deci dupa ce a
murit a ramas mort si au esuat si colectarea logului si shutdown-ul gratios.
Masuri:
- NoAutoUpdate=1 + AUOptions=2 pe VM 109 (aplicat direct in registry)
- actiuni de recovery pentru sshd: restart la 5s/10s/30s, reset=86400
- guard "STEP 3b: Windows servicing" inainte de restore (check_servicing.ps1):
asteapta idle 300s, consuma controlat un reboot in asteptare, altfel
abandoneaza cu "ABORTED - Windows servicing" in loc de un "Restore failed"
inselator. Fail-open daca checkul lipseste - nu are voie sa pice testul.
- fereastra lunara de patching (vm109-patch-window.sh + install_updates.ps1),
prima duminica 03:00, cu re-armare NoAutoUpdate=1 indiferent de rezultat
Adaugat si .gitattributes: cu core.autocrlf=true scripturile .sh ajungeau in
working tree cu CRLF, iar ele se deployeaza prin scp direct pe Proxmox.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01BhQBTegE4PiMPPaapLHjkc
- scripts/install-sbt.sh: instalare idempotentă (scripturi + statusline +
patch settings.json) cu verificări de mediu
- README: replicare de la zero (transfer prin pct exec, installer, sandbox,
ce se pierde la recrearea sandbox-ului), verificare rapidă, căi noi
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
- fără agent implicit: ambele pane-uri sunt shell în sandbox, agentul se
pornește manual; argumentul 3 rămâne pentru lansare explicită
- al doilea pane intră în sandbox cu 4s întârziere (SBT_PANE_DELAY):
două `sbx exec` simultane se calcă pe lock-ul de refresh Docker Hub și
scot "could not acquire docker hub refresh lock"
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
- sbt: sesiuni tmux (sbx1..3) care intră în sandbox și lansează agentul
(claude/opencode/orice binar); tmux rulează pe host, panes prin sbx exec
- statusline.sh + bootstrap-statusline.sh pe /home/workspace/.agent
(virtiofs persistent), reinstalat la fiecare intrare fiindcă /home/agent
din sandbox e overlay efemer
- fix printf "--" -> printf -- "--" (eroare de usage când API-ul de cote
nu răspunde)
- copii versionate ale scripturilor agents/sb + documentație README
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Alerta "OOM x2 on pvemini" (09:36) arata procese mici ucise (dbus-daemon,
oom_score_adj:200), dar mesajul kernel dadea containerul real:
oom_memcg=/lxc/102. OOM local containerului, nu presiune de host - pvemini
avea 24Gi disponibili si zram functional.
Baseline masurat cu ZERO sandbox-uri active: ~1.9GB (sbx 863M + claude 317M +
VS Code Remote 450M + docker/tailscale/portainer 205M). Un sandbox real mai
adauga ~1.9GB (containerd-shim) -> plafonul de 4GB era depasit sistematic.
Contoare cumulate: oom_kill 24, 9279 depasiri memory.high, memory.peak fix pe
limita, swap 510/512 epuizat.
Verificat explicit ca sbx NU are memory leak: RSS urca la ~863M la pornire si
se plafoneaza (esantionat la 10s timp de un minut).
Fix: pct set 102 --memory 12288 --swap 4096 (live, fara restart).
Tabelul de resurse din cluster/README.md era vechi (102 aparea ca "coolify
stopped", lipseau 110 si 171, RAM gresit peste tot) - regenerat din pvesh.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
LXC 110 (moltbot) a picat dupa un OOM local containerului urmat de reboot:
tailscaled a ramas delogat, iar containerul mostenea resolv.conf-ul Tailscale
de la host-ul pve1 (doar MagicDNS 100.100.100.100) -> rezolutie DNS zero desi
L3 era functional -> echo-core in crash-loop pe telegram.error.TimedOut.
Fixuri aplicate:
- pct set 110 --nameserver '10.0.20.1 1.1.1.1' (elimina dependenta de Tailscale)
- zram-tools pe pve1 (8G zstd, prio 100) - `swap: 4096` din config era fictiv,
host-ul nu avea niciun swap; root pe ZFS deci zram, nu swapfile
- MemoryHigh/MemoryMax pe pocket-tts + supertonic-tts - toate serviciile user
rulau cu limite `infinity`, de unde OOM-uri recurente (Apr 25, May 28 x4)
cu victime aleatorii alese dupa oom_score_adj
Documentatie:
- nou post-mortem in cluster/incidents/, adaugat in indexuri
- README lxc110: host corectat pveelite -> pve1 (+ RAM/CPU/storage reale),
comenzile pct redirectionate spre nodul corect
- README lxc171: tabel cu starea swap pe cele 3 noduri (pveelite are zvol,
nu zram - nu necesita acelasi fix)
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Documentează LXC 102 și depanarea erorii "500: failed to run sandbox
container" la crearea sandbox-urilor opencode: build docker-sbx pentru
Ubuntu 26.04 instalat pe Debian 13 (libsailor.so cere GLIBC_2.43),
userul work lipsă din grupul kvm și /usr/sbin absent din PATH
(mkfs.ext4 pentru snapshotter-ul erofs).
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Documentate doua probleme intalnite la deploy: variabile env noi
(AUTOPASS_RAR_ENV, AUTOPASS_SESSION_SECRET, AUTOPASS_WORKER_SEND_ENABLED)
devenite obligatorii in docker-compose.yml fara actualizare in Dokploy,
si crash-loop api/worker cu "readonly database" dupa ce imaginea a trecut
la user non-root (uid 10001) fara chown pe volumul SQLite existent.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Flux de lucru pentru mediu staging autopass: un branch = un environment
(main->prod, staging->test), serviciu Dokploy separat autopass-test, domeniu
via wildcard *.roa (fara IIS/cert nou), env care opreste trimiterile reale la
RAR. Link incrucisat din autopass.md.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
- ghid deploy Dokploy (Custom Git, autodeploy webhook, domain via roa-apps wildcard)
- probleme intampinate: Gitea Unauthorized, api crash-loop (itsdangerous lipsa), 303 /login
- link in indexul docs din README
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Cauza ERR_CERT_DATE_INVALID pe roa-qr.romfast.ro: renewal-ul win-acme
avea Installation plugin "None" in loc de IIS -> certul se reinnoia in
store dar binding-ul SNI ramanea pe certul vechi (expirat 31 mai).
- monitor-ssl-certificates.sh: adaugat roa-qr.romfast.ro (Site ID 5);
normalizat CRLF->LF (CRLF dadea exit 127 la exec pe Linux)
- docs: box incident 2026-06-25 cu cauza-radacina + diagnostic per renewal
Fix aplicat pe VM 201: plugin install None->IIS in renewal.json + force
renew (cert nou valid pana 23 sep 2026, binding auto-actualizat).
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Incident 2026-06-24: OOM-uri repetate în cgroup /lxc/171 cauzate de swap
nebacked pe host (pvemini fără swap) + acumulare de forks vscode-server
orfane și sesiuni logind zombie.
- scripts/reap-orphans.sh: reaping conservator (forks ~/.vscode-server
orfane >24h + sesiuni closing cu leader mort), rulat din cron la 6h
- README: secțiune Memorie & OOM (zram pe host ZFS, reaper, diagnostic),
corectat date stale host/RAM/CPU (pvemini, 16GB, 4 cores)
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Script Windows interactiv pentru client VADECO_20240227:
- verificare TCP port 1521 (fail-fast fara tunel SSH)
- verificare calendar Oracle: deschidere luna noua (tnDeschidere=1)
sau redeschidere cu avertisment stergere date (tnDeschidere=0)
- apel ACOPIE_BAZA_DATE + pack_deschidere_luna.deschidere_luna
- mod Dry Run (afiseaza SQL fara executie) si suport argumente CLI
- valori implicite: anul si luna anterioara curenta
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Procedura completa import DMP client pentru teste in LXC 108 Oracle 21c.
Parfile expdp ACN cu tabele mari excluse (40 tabele, ~2.4GB date excluse).
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
- Proxmox default-matcher acum trimite doar la mail-to-root (pve1 smtp
eliminat din matcher → fix emailuri duble pentru backup/vzdump)
- Adaugat tabel cron jobs per nod cu motivul redirect-ului > /dev/null
- Regula: scripturi cu propriile notificari trebuie sa aiba redirect in
crontab, altfel cron genereaza email suplimentar de confirmare
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Documenteaza incidentul Kingston SNV3S2000G hang la 2026-04-30 (Sensor 2
74°C → emergency mode + restart loop) si masurile aplicate: distantare
temporala backup-uri par/impar, mutare CT 101+110 pe pve1 backup-ssd,
nofail in fstab, hardware watchdog iTCO_wdt, monitoring CSV la 30 min.
Adauga scripturile /opt/scripts/kingston-thermal-{monitor,report}.sh
pentru tracking trend si alertare la depasirea pragurilor termale.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Documentat fluxul complet modificare → redeploy: manual vs auto-deploy
prin webhook Gitea/GitHub. Tabel repo-uri curente per serviciu.
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Documentat cele 3 tipuri de servicii (Application/Compose/Database),
tabel comparativ, pași UI pas-cu-pas pentru fiecare tip, și când să
alegi fiecare variantă. Include cerințe obligatorii docker-compose.yml
și nota despre înregistrarea domeniilor prin UI vs labels.
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Adds vm201-roa-update-server.md describing the two IIS virtual apps under
roa.romfast.ro that distribute application updates to ROMFAST clients:
- /roaupdate -> D:\ROAUPDATE: per-client VFP XML manifests, _ARHIVE ZIPs
for 35+ ROA modules (ROACONT, ROAFACTURARE, ROAGEST, etc.), SVN-backed
DB scripts, xmlupdatecreator workflow.
- /contafinupdate -> D:\APPUPDATESERVERAVFP: ActiveVFP server with
AVFPHandler for *.avfp requests, VFP9 runtime.
Also captures the full IIS site inventory (Default Web Site, ROA2WEB,
Dokploy, Gitea, roa-qr, roa-apps) verified live on 2026-04-25, and lists
the configured client manifests (ROMFAST, ROMPETROL, ARGENTA, etc.).
Cross-references added in proxmox/README.md and vm201-windows/README.md.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Document the BT George scraper running on VM 201:
- Python + Playwright SDK (HEADLESS=false required for WAF bypass)
- Windows Service deploy with Telegram notifications
- Cross-references in proxmox/README.md and vm201-windows/README.md
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Adds end-to-end procedure for moving production back from DR (10.0.20.37)
to a repaired/reinstalled PRIMARY (10.0.20.36): final RMAN backup on DR
in restricted/read-only mode, RMAN restore on PRIMARY, app connection
switch, scheduled-task reactivation, VM 109 stop. Companion PowerShell
script handles the restore with sanity checks (IP, NFS, backup freshness)
and aborts if Oracle major version != 19, since failback to 21c would
need an extra dictionary upgrade step (~30-60 min) that adds untested
risk during the critical window — recommended path is 19c failback then
upgrade later in a planned window.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Add a top-level case index at lxc108-oracle/clienti/README.md and a
narrative README inside oracle-xe-21c/ that names ROMPETROL ENERGY
explicitly, describes symptom -> diagnostic -> what failed -> what
worked, and lists each numbered SQL with its role in the import phases.
Wire the case into discoverable entry points:
- proxmox/lxc108-oracle/README.md: new "clienti/" subsection
- proxmox/README.md: tree + nav links
- /workspace/romfastsql/CLAUDE.md: entry points
Future "Rompetrol Energy" / "ORA-12954" / "recreare PDB" searches now hit
the docs from the master indices instead of via grep on schema name.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
clienti/ contained Oracle XE 21c troubleshooting and PDB recreation
scripts. Moving it under proxmox/lxc108-oracle/ keeps Oracle migration
material colocated with the Oracle host docs. Update the two relative
links in roa-windows-setup that pointed to the old location.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Move VM302-TESTING.md from lxc108-oracle/roa-windows-setup/test/ into a
new proxmox/vm302-oracle-test/ directory (sibling of vm109/vm201) so the
test environment is documented separately from the setup scripts. Add a
dual-edition test plan (XE validated / SE TODO) and a stub for capturing
the production SE errors next time they reproduce.
Cross-link from roa-windows-setup/README.md, proxmox/README.md master
index and CLAUDE.md entry points. Setup scripts stay in lxc108-oracle —
they are not VM-specific.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
VM 109 returned to its original home on pveelite, co-located with
oracle-backups NFS storage. The README is updated to reflect that:
the VM is now in HA (ha-prefer-pveelite, state=stopped, nofailback=1)
rather than excluded from HA, and the new layered defences (trap
guard, watchdog cron, dynamic memory pre-flight, max_restart caps)
are documented alongside the original 8a0c557 trap.
Adds a Storage Failover section describing the pveelite -> pvemini
manual failover flow: email alert from pveelite-down-alert.sh,
failover-dr-to-pvemini.sh on the surviving node, failback when
pveelite returns. The pve1 nightly mirror is the third copy.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
failover-dr-to-pvemini.sh and failback-dr-to-pveelite.sh promote/demote
the rpool/oracle-backups dataset between nodes when pveelite is down.
Both refuse to run if the other side is reachable to prevent split-brain.
Both patch transfer_backups.ps1 on Oracle Production (10.0.20.36) via
SSH to redirect the daily SCP target between 10.0.20.202 and 10.0.20.201.
The PowerShell patch uses -EncodedCommand (UTF-16LE base64) so the bash
caller does not need to escape PowerShell quoting. End-to-end test
including failover -> failback confirmed transfer_backups.ps1 returns
to byte-identical state (SHA256 43DD2187...).
pveelite-down-alert.sh runs every minute on pvemini and emails an alert
with copy-paste failover instructions after 5 consecutive ping failures.
The alert body includes the latest oracle-backups and VM 109 replica
timestamps so the operator knows the recovery point before deciding.
The DR weekly-test script gains a cluster-aware guard at the top that
exits silently when /etc/pve/qemu-server/109.conf is not on the local
node, allowing the same cron entry to be present on both pveelite and
pvemini without double-firing.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
