Documenteaza pasul lipsa fata de diagnostic-spatiu-clienti.md sectiunea 6: cum ajunge agentul de pe LXC 171 pe statia de birou (WOL pe acelasi L2, apoi SSH ca mmari), plus capcana job object-ului Windows care omoara tunelul stnlc daca nu ruleaza in aceeasi sesiune SSH cu sqlplus. Prima aplicare: PACK_CONTAFIN la ROMCONSTRUCT, 2026-09-10. Co-Authored-By: Claude Agent <noreply@anthropic.com>
68 lines
3.4 KiB
Markdown
68 lines
3.4 KiB
Markdown
# Acces de la distanță la stația de birou (și, prin ea, la Oracle-ul clienților)
|
|
|
|
De ce: agentul Claude (LXC 171) poate trezi și accesa stația de birou a lui Marius
|
|
(`LENOVO-AIO-BIROU`) fără nimeni prezent fizic, ca să ruleze operații care altfel ar cere
|
|
GUI-ul Bitvise de acolo (ex. aplicarea unui pachet Oracle la un client). Prima aplicare:
|
|
`PACK_CONTAFIN` la ROMCONSTRUCT, 2026-09-10.
|
|
|
|
Nu duplică `diagnostic-spatiu-clienti.md` §6 (tunelul Bitvise + sqlplus către un client) —
|
|
doar adaugă pasul de dinainte: cum ajungi de pe LXC 171 pe stația de birou, ca să rulezi de
|
|
acolo procedura deja documentată.
|
|
|
|
## 1. Trezire (Wake-on-LAN)
|
|
|
|
Stația (`10.0.20.144`, Tailscale: `lenovo-aio-birou` / `100.86.46.43`) e pe **aceeași rețea
|
|
L2** ca LXC 171 (`10.0.20.0/24`) — nu e nevoie de aplicația Wake-on-LAN de pe Portainer
|
|
(`100.80.138.86:5004`), un magic packet trimis direct pe broadcast ajunge la fel de bine:
|
|
|
|
```python
|
|
import socket
|
|
mac = 'e4a8df972e5c' # LENOVO-AIO-BIROU
|
|
data = b'\xff'*6 + bytes.fromhex(mac)*16
|
|
s = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
|
|
s.setsockopt(socket.SOL_SOCKET, socket.SO_BROADCAST, 1)
|
|
s.sendto(data, ('10.0.20.255', 9))
|
|
```
|
|
|
|
MAC-ul poate fi recitit din cache-ul ARP local dacă lipsește: `ip neigh show 10.0.20.144`
|
|
(rămâne populat chiar cu mașina oprită, din trafic anterior). Boot complet: ~15-20s până
|
|
răspunde la ping.
|
|
|
|
## 2. SSH către stație
|
|
|
|
User Windows: `mmari` (OpenSSH nativ Windows, port 22 — nu Bitvise). Cheia publică a
|
|
agentului e autorizată în `C:\Users\mmari\.ssh\authorized_keys`:
|
|
|
|
```bash
|
|
ssh -i ~/.ssh/id_ed25519 mmari@10.0.20.144
|
|
```
|
|
|
|
Cheia: `docs/chei-publice/claude-agent-lxc171.pub` (`SHA256:5D7y0lTqWKf6e2agUK0Nol+duxoipPYb3y6Rhk4nXtw`).
|
|
Shell-ul e PowerShell, nu bash — `;` în loc de `&&`/`&` ca separator de comenzi.
|
|
|
|
## 3. De acolo: tunel Oracle către un client
|
|
|
|
Exact procedura din `diagnostic-spatiu-clienti.md` §6 (profil `.tlp`/`.bscp` din
|
|
`D:\GoogleDrive`, `stnlc.exe`, `sqlplus.exe`) — **regula de acolo rămâne valabilă**: tunelul
|
|
spre un client e strict read-only, în afara cazului în care chiar scopul e o scriere
|
|
controlată (aplicare pachet), cu backup luat înainte (`DBMS_METADATA.GET_DDL`).
|
|
|
|
**Capcană nouă, specifică rulării prin SSH (nu apare cu sesiune interactivă la consolă):**
|
|
OpenSSH pe Windows pune procesele pornite într-o sesiune într-un **job object**; când
|
|
sesiunea SSH se închide, Windows omoară și copiii ei — inclusiv `stnlc.exe` pornit cu
|
|
`Start-Process` în fundal. Tunelul moare la finalul comenzii SSH care l-a pornit, chiar
|
|
dacă procesul pare detașat.
|
|
|
|
**Soluție**: pornire tunel + `sqlplus` (backup, apply, verify) **în același script, aceeași
|
|
sesiune SSH** — nu în comenzi SSH separate. Vezi orchestrarea completă (tunel → backup DDL →
|
|
apply → verify → stop tunel) în istoricul conversației Discord din 2026-09-10; nu e
|
|
salvată ca script reutilizabil momentan (de scris în `tools/` dacă mai apare nevoia).
|
|
|
|
## Legături
|
|
|
|
- `docs/acces-ssh-chei-angajati.md` — cheile de pe stația de birou folosite ca să te
|
|
autentifici *către* clienți (invers față de acest document, care e acces *către* stație).
|
|
- `docs/diagnostic-spatiu-clienti.md` §6 — tunelul Bitvise + sqlplus, regula read-only.
|
|
- `docs/acces-client-tailscale-ssh.md` — alternativa fără Bitvise, pentru servere de client
|
|
cu Tailscale + SSH direct (nu implică stația de birou).
|