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>
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>
Convert /mnt/pve/oracle-backups from a directory on the pveelite
rootfs into a dedicated ZFS dataset rpool/oracle-backups so it can be
incrementally replicated to pvemini. zfs-replicate-oracle-backups.sh
runs every 15 minutes from cron on pveelite and uses zfs send/recv
over the cluster's internal SSH (direct IP, /etc/pve/priv/known_hosts)
to avoid Tailscale magicDNS detours that broke the first attempt.
The destination dataset is set readonly=on so accidental writes on
pvemini cannot diverge it. Snapshot pruning keeps 5 rolling copies.
nightly-backup-mirror.sh ships a third copy nightly to pve1's
backup-ssd (ext4 SATA) — different physical disk, different
filesystem, different node — guarding against the failure mode where
both pveelite and pvemini are simultaneously unavailable. The same
script tars /etc/pve and rotates 14 days of cluster config archives,
since pmxcfs is in-RAM and a multi-node quorum loss would otherwise
take cluster config with it.
The old directory is kept as oracle-backups.old-DELETE-AFTER-2026-05-02
on pveelite for one week as a safety net.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
DR test script now refuses to start VM 109 if:
* cluster is not quorate (e.g. mid-failover into a degraded state),
* available memory on the host is below VM 109 config + 1 GB margin.
Both checks scale automatically — memory threshold is computed from
qm config so resizing VM 109 does not require touching the script.
Adds vm109-watchdog.sh, scheduled cluster-wide every minute. The
watchdog is the second line of defence behind the cleanup trap from
8a0c557: it force-stops VM 109 if the trap was bypassed (script
killed, host crash mid-test, manual run forgotten). It honours
/var/run/vm109-debug.flag for legitimate manual sessions and is
node-aware via /etc/pve/qemu-server/109.conf so it can be deployed
on every node without coordinating with VM 109's current location.
Both safeguards target the 04-18 → 04-20 chain: VM 109 left running
2.5 days then sandwiched against an HA failover that pushed CT 108
Oracle (8 GB) onto pveelite (16 GB) → OOM cascade.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
The cleanup trap added in 8a0c557 stopped VM 109 unconditionally on EXIT,
which kills the VM during --install/--help or when an operator launched
it manually for debugging. Gate the trap with DR_VM_STARTED_BY_US so it
only fires when the script itself started the VM.
Also remove the 2>/dev/null swallow on qm start so cross-node failures
(e.g. running on a node where the VM is not configured) appear in the
log instead of producing a silent "Failed to start VM 109" in 0 seconds.
Root cause for the 2026-04-25 silent failure: cron lived on pveelite
while VM 109 had been migrated to pvemini; qm start returned an error
that was hidden by the redirect.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
VM 201 (Windows critical) stays out of HA by design. Added:
- failover-vm201.sh: interactive failover pvemini -> pveelite with ZFS replication state
- recover-vm201-to-pvemini.sh: interactive reverse migration with uptime + split-brain checks
- pvemini-down-alert.sh: cron watchdog on pveelite, emails full runbook after 2min DOWN
Replication RPO tightened: CT 108 + VM 201 to 5min, CT 171 to 15min.
CT 171 added to HA (ha-group-main) for continuous Claude Code access.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Following the 2026-04-20 cluster outage, the cluster README now covers
HA resource limits, corosync token tuning (10s tolerance for USB glitches),
rasdaemon/netconsole/kdump diagnostic stack on pvemini, mail relay via
mail.romfast.ro with SMTP auth, OOM alerting via cron, and swap on pveelite.
VM 109 README now clearly states it was removed from HA and is only
started by the weekly DR test script.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
The DR test script used set -euo pipefail, so a failing SSH
shutdown command caused the script to exit before qm stop.
On 2026-04-20 this left VM 109 running for 2.5 days and
triggered an OOM cascade when pvemini HA-failed over to
pveelite.
Adds EXIT trap that force-stops VM 109 regardless of exit
path, and makes the Step 7 SSH shutdown tolerant of failure.
Incident details: proxmox/cluster/incidents/2026-04-20-cluster-outage.md
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
