Files
roafacturare/docs/vm304_acces.md
2026-09-17 22:36:46 +03:00

103 lines
5.8 KiB
Markdown

# VM 304 — ce este si cum se acceseaza
## Ce este
VM 304 = masina virtuala Proxmox cu ID **304**, nume **Win11-Marius**, pe nodul **pvemini**
din clusterul Proxmox ROA. Nu e in HA (`noha`).
Surse:
- `E:\proiecte\ROMFASTSQL\proxmox\cluster\docs\oprire-planificata-cluster.md:293`
`| 2 | pvemini | VM 304 Win11-Marius | Nu | Shutdown |`
- `E:\proiecte\ROMFASTSQL\proxmox\cluster\docs\oprire-planificata-cluster.md:479`
`Guest-uri in afara HA: CT 102, CT 301, VM 302, VM 303, **VM 304**, VM 310.`
- `E:\proiecte\ROMFASTSQL\proxmox\cluster\scripts\cluster-startup.sh:53` `304 # Win11-Marius`
- `E:\proiecte\ROMFASTSQL\proxmox\cluster\scripts\cluster-shutdown.sh:41`
`304 # Win11-Marius — desktop, fara dependente`
- `E:\proiecte\ROMFASTSQL\proxmox\cluster\scripts\.cluster-state.txt:13` `vm pvemini 304 running noha`
E clona lui **VM 303 (Win11-Adina)**:
- `E:\proiecte\ROMFASTSQL\docs\acces-ssh-chei-angajati.md:251`
`| docs/chei-publice/vm304.pub | ... | angajat, romfast@VM-304 (clona lui 303) |`
- `E:\proiecte\ROMFASTSQL\docs\acces-ssh-chei-angajati.md:256-260` — clona a pornit cu aceeasi
cheie privata ca VM 303; a fost regenerata separat (`ssh-keygen -t ed25519 -C "romfast@VM-304"`),
cu stergerea keypair-ului mostenit din Bitvise User keypair manager si regenerarea cheilor de
host `ssh_host_*`, altfel clona continua sa se autentifice cu identitatea VM 303 in loguri.
Nu am gasit un nume de retea/hostname DNS sau un IP direct alocat lui VM 304 in documentatia
cautata (nu e in tabelul de IP-uri interne `10.0.20.x` de la
`E:\proiecte\ROMFASTSQL\docs\acces-ssh-chei-angajati.md:388-394`, care listeaza doar nodurile
Proxmox). Accesul documentat trece prin host-ul Proxmox, nu prin IP propriu al VM-ului (vezi mai jos).
## Cum se acceseaza
**Nu prin RDP** — nu am gasit nicio mentiune de RDP catre VM 304 in fisierele cautate. Accesul
documentat e **headless, prin QEMU guest agent**, de pe LXC 171 (sau orice masina cu acces SSH la
host-ul Proxmox), catre host-ul nodului `pvemini` la `root@10.0.20.201`:
```bash
# ping guest agent, ca sa confirmi ca VM-ul raspunde:
ssh root@10.0.20.201 "qm agent 304 ping"
# executie de comanda Windows in interiorul VM 304:
ssh root@10.0.20.201 "qm guest exec 304 -- <comanda Windows>"
```
Sursa: `E:\proiecte\ROMFASTSQL\docs\drepturi-utilizatori-roa-firme.md:14-19` (documentat generic
pentru `<vmid>`, cu exemplul explicit "304 = Win11-Marius" la linia 14).
Acelasi tipar (guest agent prin `qm agent`/`qm guest exec` de pe host `root@10.0.20.201`) e
folosit si pentru celelalte VM-uri Windows non-HA ale clusterului — vezi si
`E:\proiecte\ROMFASTSQL\proxmox\cluster\docs\oprire-planificata-cluster.md:15` (guest agent
necesar pentru shutdown controlat).
## Cale de retea catre discul ei
Nu am gasit o cale UNC (`\\server\share`) documentata catre VM 304. Ce e documentat e o cale
**locala, in interiorul VM-ului** — `D:\roa\BITVISE\<client>.tlp` (profilele Bitvise) si
`D:\roa\<produs>\...` (working copy ROA, folosita ca sursa pentru scripturi SQL) — accesibila doar
prin comenzi rulate cu `qm guest exec`, nu prin share de retea:
- `E:\proiecte\ROMFASTSQL\docs\drepturi-utilizatori-roa-firme.md:17`
`# Profilul Bitvise al clientului e in D:\roa\BITVISE\<client>.tlp pe VM.`
- `E:\proiecte\ROMFASTSQL\docs\drepturi-utilizatori-roa-firme.md:62`
`Sursa: D:\roa\<produs>\COMUN\Drepturi utilizatori\drepturi_utilizatori.sql din orice working copy ROA`
- `E:\proiecte\ROMFASTSQL\docs\acces-ssh-chei-angajati.md:371-372`
`astea sunt fisierele care pleaca pe VM 303 / VM 304 (pe VM 304 stau in D:\roa\BITVISE\)`
## Ce are instalat (documentat)
- **Bitvise SSH Client**, cale `C:\Program Files (x86)\Bitvise SSH Client\sexec.exe`
(`E:\proiecte\ROMFASTSQL\docs\drepturi-utilizatori-roa-firme.md:19`), cu profile de clienti in
`D:\roa\BITVISE\*.tlp` si cheia globala `C:/Users/romfast/.ssh/id_ed25519`.
- **O copie/working copy ROA** sub `D:\roa\<produs>\...` (produsul e generic in text, nu apare
explicit "ROAFACTURARE" — vezi `drepturi-utilizatori-roa-firme.md:62`).
- Nu am gasit mentiune explicita despre VFP 9 sau Oracle client instalate pe VM 304 in fisierele
cautate (spre deosebire de VM 302, documentat separat ca `oracle-test`,
`E:\proiecte\ROMFASTSQL\proxmox\vm302-oracle-test\`).
## Credentiale — unde sunt documentate (nu le-am copiat)
- Cheia publica SSH pentru angajat pe VM 304: `E:\proiecte\ROMFASTSQL\docs\chei-publice\vm304.pub`,
amprenta SHA-256 listata la `E:\proiecte\ROMFASTSQL\docs\acces-ssh-chei-angajati.md:251`.
- Cheia globala folosita de `sexec.exe` in `qm guest exec`:
`C:/Users/romfast/.ssh/id_ed25519` (in interiorul VM 304 — vezi
`drepturi-utilizatori-roa-firme.md:19`).
- Lista completa a serverelor pe care sunt copiate cheile: `scripts/bitvise-chei.ps1`, variabila
`$Servere` (`E:\proiecte\ROMFASTSQL\docs\acces-ssh-chei-angajati.md:264`).
- Nu am gasit parola sau alta credentiala pentru autentificare directa (RDP/consola) pe VM 304 in
fisierele cautate.
## Unde am cautat
1. `D:\ROA\ROAFACTURARE\COMUN\docs\` (grep `304`, `vm304`, `masina virtuala`, `server de test`,
`infrastructur`) — potriviri gasite pentru `304` erau toate numere de linie in cod PL/SQL
(`PACK_UTILS` linia 304, `PLS-00304`) sau text irelevant, nicio mentiune de VM 304.
2. `D:\ROA\COMUNROA\` — grep pe `304` a expirat (timeout la 20s pe arborele intreg, prea mare);
nu am reluat cautarea pentru ca raspunsul complet a fost deja gasit la pasul 3, conform
instructiunii de oprire la primul raspuns gasit.
3. `E:\proiecte\ROMFASTSQL\` — gasit direct: `docs/chei-publice/vm304.pub`,
`docs/acces-ssh-chei-angajati.md`, `docs/drepturi-utilizatori-roa-firme.md`,
`proxmox/cluster/docs/oprire-planificata-cluster.md`,
`proxmox/cluster/scripts/cluster-{startup,shutdown}.{sh,ps1}`,
`proxmox/cluster/scripts/.cluster-state.txt`.