Linux și terminalul pentru constructori de agenți: de la comandă la sistem reproductibil

120–150 de minute · +60–90 de minute pentru exerciții · Nivel: începător · Recomandat înainte: Lecțiile 1–5

Lecția pe scurt

Întrebarea centrală: cum transformi o serie de comenzi tastate într-un terminal într-un mod de lucru pe care îl poți înțelege, verifica, repeta și folosi în siguranță atunci când construiești sau operezi un agent?

În Lecția 5 ai văzut ce se află sub o acțiune aparent simplă: un proces are PID, identitate, grupuri, un folder curent de lucru, descriptori de fișiere și permisiuni. Acum învățăm interfața prin care vei observa și controla toate aceste lucruri în cea mai mare parte a cursului: linia de comandă.

Terminalul nu este „Linux în modul text”, iar shell-ul nu este același lucru cu terminalul. O comandă nu este o propoziție trimisă direct kernelului. Între ceea ce tastezi și procesul care ajunge să ruleze există un interpretor — de obicei un shell — care citește textul, îl descompune, aplică regulile de folosire a ghilimelelor, face expansiuni și redirecționări, caută comanda și abia apoi execută ceea ce ai cerut.

Pentru constructorii de agenți, această distincție este esențială. Un agent de programare, un instrument care pornește subprocese, un serviciu systemd sau o sesiune SSH ajung toate să depindă de aceleași concepte: cale, folder curent, mediu, PATH, intrare și ieșire standard, cod de ieșire, serviciu și log (jurnal de execuție). Dacă nu le înțelegi, poți avea un program care „merge în terminal”, dar eșuează ca serviciu, un script care rulează alt executabil decât crezi, un secret ajuns în istoricul shell-ului sau un lanț de comenzi (pipeline) care pare reușit deși unul dintre pașii lui a eșuat.

Regula lecției

Nu memora comenzi ca pe formule magice. Pentru fiecare comandă trebuie să poți răspunde la cinci întrebări: unde rulează, ce intrare primește, ce proces pornește sau modifică, unde trimite ieșirea și cum afli dacă a reușit.

La finalul lecției vei putea

1. să deosebești terminalul, shell-ul, linia de comandă și promptul shell-ului;
2. să explici diferența dintre o cale absolută și una relativă și rolul lui /, ~, . și ..;
3. să explici cum găsește shell-ul o comandă și ce rol are variabila PATH;
4. să folosești corect ghilimelele, expansiunea variabilelor, expansiunea numelor de fișiere (globbing) și substituția de comandă;
5. să diferențiezi stdin, stdout și stderr și să urmărești redirecționările;
6. să explici un pipeline și să nu confunzi textul afișat cu succesul tehnic al întregului lanț;
7. să folosești codurile de ieșire și operatorii && / || pentru a exprima dependențe între comenzi;
8. să deosebești variabilele shell-ului de variabilele de mediu și să explici de ce source .venv/bin/activate modifică shell-ul curent;
9. să explici diferența dintre APT, apt, apt-get și dpkg;
10. să deosebești start, enable, restart, reload și daemon-reload în systemd;
11. să citești logurile unui serviciu cu journalctl și să explici de ce logul nu este același lucru cu o urmă de execuție (trace);
12. să explici arhitectura de bază SSH: client, server, cheie de gazdă (host key), cheie de utilizator, known_hosts și authorized_keys;
13. să diagnostichezi de ce un program funcționează într-un terminal interactiv, dar eșuează când este pornit ca serviciu sau prin SSH;
14. să proiectezi un spațiu de lucru pentru linia de comandă care poate fi recreat și înțeles de altcineva.

1. Terminalul, shell-ul și linia de comandă nu sunt același lucru

Începem cu vocabularul care va reveni în aproape toate lecțiile tehnice următoare.

O aplicație de terminal⁹ (emulator de terminal) este programul care îți oferă fereastra, textul, cursorul, combinațiile de taste și legătura cu o sesiune de terminal. Konsole, GNOME Terminal și alte aplicații similare oferă interfața de terminal. Ele nu decid singure ce înseamnă cd, export sau |.

Un shell⁸ este interpretorul de comenzi. În exemplele acestei lecții folosim Bash, un shell foarte răspândit pe Ubuntu și Kubuntu. Alte sisteme pot folosi Zsh, Fish sau alte shell-uri, iar unele reguli de sintaxă diferă. De aceea este mai precis să spui „aceasta este sintaxă Bash” decât „așa funcționează terminalul⁹”.

Linia de comandă (command line) este modul de interacțiune în care formulezi comenzi textuale. Poți folosi o linie de comandă local, prin SSH²⁵, într-un container, într-o consolă serială sau într-o sarcină automatizată. Nu presupune neapărat o fereastră grafică.

Promptul² shell-ului⁸ este textul afișat înainte să tastezi comanda. În Bash, promptul principal este definit de variabila PS1. Nu îl confunda cu un prompt pentru un model lingvistic din Lecțiile 1–2. Sunt două sensuri diferite ale aceluiași cuvânt englezesc.

O analogie scurtă: pupitrul de operare

Poți privi terminalul⁹ ca pe un pupitru cu ecran și tastatură, iar shell-ul⁸ ca pe operatorul care interpretează instrucțiunile primite prin acel pupitru. Operatorul decide cum se separă cuvintele, ce înseamnă simbolurile speciale, unde găsește programul cerut și cum leagă ieșirea unei comenzi de intrarea alteia. Kernelul și procesele rămân mecanismele care execută operațiile reale.

2. Vocabularul minim al liniei de comandă

Nu ai nevoie de sute de comenzi. Ai nevoie mai întâi de o hartă a obiectelor și a fluxurilor pe care comenzile le manipulează.

3. Ce face Bash cu textul înainte să pornească programul

Multe dintre surprizele shell-ului⁸ apar înainte ca programul pe care îl chemi să înceapă să ruleze.

Ia o comandă simplă:

grep -i "$TERMEN" logs/*.log

Nu toate caracterele ajung neschimbate la grep. Bash trebuie mai întâi să interpreteze linia. Pentru un începător este util următorul model mental. Nu este o listă exactă a tuturor etapelor interne din Bash, dar păstrează ordinea conceptuală care te ajută să prezici rezultatul:

Exemplu concret. Să presupunem că TERMEN conține textul eroare gravă, iar în folderul logs există a.log și b.log. După ce Bash termină interpretarea, grep primește patru argumente: -i, eroare gravă, logs/a.log și logs/b.log. Ghilimelele au dispărut, $TERMEN a fost înlocuit cu valoarea lui, iar logs/*.log a devenit lista fișierelor găsite.

Fiecare pas este explicat mai jos: căutarea comenzii în secțiunea 5, ghilimelele și expansiunile în secțiunea 6, redirecționările în secțiunea 8, codul de ieșire în secțiunea 9.

Această ordine explică de ce două comenzi care arată aproape la fel pot avea efecte diferite. Programul extern vede argumentele după ce shell-ul⁸ a terminat o parte importantă din interpretare.

4. Căile: cum spune un proces „unde”

Lecția 5 a arătat că accesul depinde de obiect și de folderele traversate. Acum învățăm să descriem acea poziție fără ambiguitate.

Sistemul de fișiere Linux are o rădăcină reprezentată prin /. O cale absolută pornește de la această rădăcină:

/home/ana/ai-agents-zero-to-expert/configs/app.json

O cale relativă este interpretată față de folderul curent de lucru:

configs/app.json

/
├── home/
│   └── ana/
│       └── ai-agents-zero-to-expert/   ← CWD când lucrezi în proiect
│           └── configs/
│               └── app.json
└── tmp/                                ← CWD dacă programul pornește de aici

Dacă CWD¹⁶ este /home/ana/ai-agents-zero-to-expert, cele două pot indica același obiect. Dacă procesul pornește din /tmp, calea relativă indică alt loc sau nu există.

Patru simboluri pe care trebuie să le citești fără ezitare

Consecința practică: ~ funcționează când tastezi în Bash, dar un program care primește textul ~/project, de exemplu dintr-un fișier de configurare, nu îl transformă automat în folderul tău personal.

Folderul curent face parte din starea procesului

pwd afișează folderul curent, iar cd îl schimbă pentru shell-ul⁸ curent. cd este un builtin important tocmai pentru că un program extern nu poate schimba permanent CWD-ul¹⁶ procesului-părinte. Dacă ai porni un executabil separat care își schimbă propriul folder curent, schimbarea s-ar aplica acelui proces, nu shell-ului care l-a pornit.

Aceeași regulă explică multe diferențe între rularea manuală și rularea ca serviciu²². Un program care deschide ./config.json depinde de CWD¹⁶. Un serviciu poate porni din alt folder decât terminalul⁹ tău, deci o cale relativă care „merge la mine” poate eșua imediat.

Calea scrisă și ținta finală pot fi diferite

Din Lecția 5 știi deja că o legătură simbolică (symbolic link) poate indica altă cale. În terminal⁹, comenzi precum readlink și realpath te ajută să vezi legătura sau să normalizezi o cale. Pentru un agent¹ care scrie sau șterge fișiere, diferența contează: validarea unui șir de caractere nu este întotdeauna echivalentă cu validarea obiectului final pe care îl va atinge operația.

5. Comandă, argumente, opțiuni și PATH

Shell-ul⁸ trebuie să răspundă la două întrebări diferite: „ce argumente îi dau programului?” și „ce program înseamnă primul cuvânt?”.

În comanda:

ls -lah docs/lessons

ls este numele comenzii, iar -lah și docs/lessons sunt argumente. Faptul că -lah poate fi interpretat de ls ca mai multe opțiuni scurte grupate este o regulă a programului ls, nu o regulă universală a shell-ului⁸.

Înainte de execuție, Bash poate extinde un alias încă din etapa de citire a comenzii. După ce comanda a fost analizată, dacă numele nu conține /, Bash caută în mod simplificat în această ordine: funcție de shell⁸, comandă internă (builtin), apoi executabil în PATH. Două comenzi utile sunt:

type cd
command -v python

cd is a shell builtin
/home/ana/ai-agents-zero-to-expert/.venv/bin/python

A doua linie este un exemplu după activarea mediului virtual într-un proiect aflat în folderul personal al utilizatorului ana; calea ta va fi diferită.

type explică ce vede Bash, iar command -v este potrivit pentru a verifica programatic cum va fi rezolvat un nume de comandă.

Cum afli singur ce face o comandă: man ls deschide manualul complet (ieși cu tasta q), ls --help afișează rezumatul opțiunilor; help cd explică o comandă internă Bash. Când nu știi o opțiune, citește ajutorul înainte s-o cauți pe internet.

Cum funcționează PATH

PATH este o listă de foldere separate prin :. Când tastezi un nume de comandă fără slash, Bash caută un executabil potrivit în aceste foldere, în ordine. De aceea activarea unui mediu virtual Python poate face ca python să indice alt executabil fără să schimbi comanda tastată.

Un detaliu important: o componentă goală din PATH poate reprezenta folderul curent. Din motive de siguranță, nu te baza pe această formă.

printf '%s\n' "$PATH"
command -v python

Dacă numele conține slash, de exemplu ./tool sau /usr/bin/python3, ai indicat deja calea și nu mai depinzi de căutarea obișnuită prin PATH.

6. Ghilimele și expansiuni: shell-ul vede mai mult decât textul afișat

Când o comandă primește fișiere, variabile sau date de intrare generate de agent¹, folosirea corectă a ghilimelelor (quoting) devine o regulă de corectitudine și securitate, nu un detaliu estetic.

Ghilimele simple, ghilimele duble și backslash

În Bash, ghilimelele simple păstrează conținutul literal:

printf '%s\n' '$HOME'

Comanda va afișa $HOME, nu valoarea variabilei.

$HOME

Ghilimelele duble permit în continuare expansiuni¹⁸ precum $VAR și $(...), dar protejează spațiile și multe caractere de separare:

printf '%s\n' "$HOME"
cd "$HOME/Proiect cu spații"

/home/ana

În exemplu presupunem că utilizatorul se numește ana. Comanda cu "$HOME" afișează valoarea variabilei, de exemplu /home/ana. Comanda cd nu afișează nimic dacă folderul există. Dacă folderul nu există, Bash afișează o eroare de tip „No such file or directory”.

Ce se întâmplă fără ghilimele:

cd $HOME/Proiect cu spații
bash: cd: too many arguments

Bash a împărțit valoarea în trei cuvinte: /home/ana/Proiect, cu și spații. Comanda cd a primit trei argumente în loc de unul.

Backslash-ul \ poate proteja caracterul următor în anumite contexte. Pentru valori și căi, ghilimelele sunt de obicei mai ușor de citit decât o serie lungă de backslash-uri.

Expansiunea numelor de fișiere (globbing): * nu este filtrul programului

În:

ls logs/*.log

modelul *.log este, în mod obișnuit, expandat de Bash înainte să pornească ls. Programul primește lista de nume rezultată. Această distincție devine importantă când modelul provine dintr-o variabilă sau când numele fișierelor conțin spații.

Dacă logs conține a.log și b.log, ls primește logs/a.log și logs/b.log. Dacă nu există niciun fișier .json, ls logs/*.json primește chiar textul logs/*.json și răspunde că nu îl găsește.

În configurația implicită Bash, un model glob fără potriviri poate rămâne text literal; opțiunile shell-ului⁸ pot schimba acest comportament. De aceea nu construi logică critică presupunând că *.json devine întotdeauna o listă nevidă.

Substituția de comandă $(...)

Expresia:

ROOT="$(pwd)"

rulează pwd și folosește ieșirea sa standard ca valoare. Ai folosit deja această tehnică în laboratoare. Ghilimelele din jurul expresiei păstrează rezultatul ca un singur argument chiar dacă ar conține spații. Bash elimină însă liniile noi de la finalul rezultatului substituției de comandă²⁰; de aceea $(...) nu este o metodă potrivită pentru a păstra identic orice flux de octeți.

7. Trei fluxuri standard: stdin, stdout și stderr

În Lecția 5 ai întâlnit descriptori de fișiere. Aici folosim cei trei descriptori pe care aproape orice proces de linie de comandă îi primește la pornire.

Într-o sesiune interactivă, toate trei pot fi conectate la terminal⁹. Asta face să pară că „totul este același text”. Nu este. Shell-ul⁸ poate conecta fiecare descriptor separat.

De exemplu, un program poate scrie un rezultat JSON pe stdout¹¹ și un mesaj de progres pe stderr¹². Alt program poate consuma stdout fără ca mesajele de diagnostic să intre în date.

8. Redirecționări și pipe-uri: compunerea comenzilor

Puterea liniei de comandă nu vine numai din numărul de utilitare, ci din faptul că le poți compune prin fluxuri bine definite.

Redirecționările mută descriptorii

Operatorul > redirecționează stdout¹¹ către un fișier și, în mod obișnuit, îl creează sau îl golește înainte să scrie:

În exemplele de mai jos, comanda_ta ține locul oricărei comenzi. Nu tasta cuvântul command: în Bash este chiar o comandă internă, cu alt rol.

comanda_ta > output.txt

>> adaugă la final:

comanda_ta >> output.txt

2> redirecționează stderr¹²:

comanda_ta 2> errors.txt

Pentru a trimite ambele fluxuri în același loc:

comanda_ta > all.txt 2>&1

Ordinea contează. Bash aplică redirecționările de la stânga la dreapta. 2>&1 înseamnă „fă descriptorul 2 să indice unde indică descriptorul 1 în acel moment”. De aceea mutarea operatorilor poate schimba rezultatul. Comparația: comanda_ta > all.txt 2>&1 trimite ambele fluxuri în fișier. comanda_ta 2>&1 > all.txt trimite stdout¹¹ în fișier, dar stderr¹² rămâne pe ecran, pentru că în momentul în care Bash a aplicat 2>&1, descriptorul 1 încă indica terminalul⁹.

Pipe-ul transmite stdout către stdin

printf '%s\n' error ok error | sort | uniq -c

      2 error
      1 ok

Ieșirea standard a primei comenzi intră în a doua, iar ieșirea celei de-a doua intră în a treia. Un pipe¹³ Bash obișnuit | nu include automat stderr¹². Bash are și operatorul |&, care conectează stdout¹¹ și stderr ale comenzii din stânga la stdin-ul¹⁰ următoarei, dar este mai clar să îl folosești numai când chiar vrei ambele fluxuri.

Un utilitar precum tee poate copia același flux spre un fișier și, simultan, spre stdout¹¹:

comanda_ta | tee run.log

Este util pentru observație, dar nu transforma orice pipeline²⁹ într-un sistem de logare. Serviciile au mecanisme dedicate, iar logurile pot conține date sensibile.

9. Codul de ieșire: cum comunică o comandă succesul

Textul afișat este pentru om; codul de ieșire este semnalul simplu pe care îl poate folosi alt software.

Prin convenție, 0 indică succes, iar o valoare nenulă indică un tip de eșec sau o stare⁴ specială definită de program.

ls fisier-inexistent
printf '%s\n' "$?"

ls: cannot access 'fisier-inexistent': No such file or directory
2

Mesajul exact de eroare poate varia în funcție de limba sistemului. Pe Ubuntu, GNU ls folosește codul 2 pentru o eroare serioasă de acest tip.

$? conține codul ultimei comenzi sau al ultimei structuri evaluate de shell⁸. Trebuie citit imediat; următoarea comandă îl înlocuiește.

Operatorii &&, || și ;

Pentru automatizări, && exprimă intenția mai bine decât două comenzi independente atunci când pasul al doilea depinde de primul.

Capcana lanțului de comenzi (pipeline)

În Bash, fără opțiunea pipefail, codul de ieșire al unui pipeline²⁹ este în mod normal codul ultimei comenzi. Asta înseamnă că prima comandă poate eșua, iar ultima poate ieși cu 0.

În scripturi în care succesul întregului lanț contează, poți activa:

set -o pipefail

Cu pipefail, un eșec din pipeline²⁹ poate produce un cod nenul pentru întregul pipeline: Bash folosește codul ultimei comenzi din lanț care a ieșit cu o valoare nenulă. Dacă toate comenzile reușesc, rezultatul este 0.

10. Variabile shell, variabile de mediu și export

Multe configurații ale agenților¹ — adrese de serviciu²² (endpointuri), nivel de logare, căi, comutatoare de funcționalități (feature flags) — ajung în mediu. Dar „este într-o variabilă” nu ne spune încă dacă un subproces o va primi.

În Bash:

MODEL_URL="http://127.0.0.1:8000"

creează o variabilă a shell-ului⁸. Pentru a o include în mediul proceselor executate ulterior:

export MODEL_URL

sau direct:

export MODEL_URL="http://127.0.0.1:8000"

Poți furniza o variabilă numai pentru o singură comandă:

LOG_LEVEL=debug comanda_ta

În acest caz, valoarea este disponibilă comenzii executate, fără să devină neapărat o setare permanentă pentru comenzile următoare.

Mediul se transmite către subprocese (procese-copil), nu înapoi către părinte

Un subproces (proces-copil) primește la pornire mediul exportat de procesul-părinte. Dacă procesul-copil își schimbă propriul mediu, acea schimbare nu rescrie mediul părintelui.

Aceasta explică de ce mediul virtual Python este activat astfel:

source .venv/bin/activate

source este builtin Bash și execută fișierul în shell-ul⁸ curent. Scriptul de activare modifică PATH și alte variabile ale acelei sesiuni. Dacă l-ai porni într-un proces separat, schimbările de mediu nu s-ar întoarce în shell-ul părinte.

Un fișier .env nu este încă o variabilă de mediu

Este o confuzie frecventă în proiectele web și AI. Bash nu încarcă automat un fișier numit .env doar pentru că acesta există. Anumite framework-uri și biblioteci îl citesc explicit. Alte aplicații nu îl cunosc deloc.

Prin urmare, propoziția „cheia este în .env” nu răspunde la întrebarea „cum ajunge cheia în proces?”. Trebuie să știi cine citește fișierul, când îl citește și cu ce permisiuni.

11. Managerii de pachete: instalează software-ul în stratul potrivit

În Lecția 3 ai separat runtime-ul, framework-ul și aplicația. Managerii de pachete respectă aceeași idee: nu toate pachetele aparțin aceluiași strat și nu toate trebuie instalate cu același instrument³.

APT și dpkg pe Ubuntu/Kubuntu

APT²⁸ este sistemul de administrare a pachetelor Debian folosit de Ubuntu. Comanda apt oferă o interfață comodă pentru utilizator:

sudo apt update
sudo apt install jq
apt show jq

apt update actualizează indexul local al pachetelor disponibile. Nu actualizează pachetele deja instalate. apt upgrade este operația care încearcă să actualizeze pachetele instalate în limitele politicii APT²⁸.

Documentația Ubuntu recomandă apt pentru utilizare interactivă, iar apt-get pentru scripturi și automatizări unde este de preferat o interfață mai stabilă. Pentru multe operații de bază, comenzile seamănă, dar scopul interfețelor nu este identic.

dpkg lucrează la un nivel mai jos cu pachetele Debian locale și baza de date a pachetelor. Poate instala un fișier .deb, dar nu are singur comportamentul APT²⁸ de a descărca și rezolva automat toate dependențele din surse de pachete.

Pachet de sistem versus pachet al limbajului

Mai târziu, în Lecția 7, vei folosi managerul de pachete al ecosistemului Python. Asta nu înseamnă că APT²⁸ și pip sunt două nume pentru același lucru. APT administrează pachete integrate în sistemul Ubuntu; pip administrează distribuții Python într-un mediu Python.

Pentru proiectele reproductibile, regula sănătoasă este să alegi conștient stratul: instrument³ de sistem prin managerul sistemului, dependență Python în mediul Python, dependență Node în proiectul Node etc. Evită să rezolvi orice eroare de instalare prin creșterea privilegiilor.

12. Prim-plan, fundal și sarcini: cum organizează shell-ul procesele pornite de tine

Lecția 5 a tratat procesul ca obiect al sistemului de operare. Aici adăugăm perspectiva shell-ului⁸ interactiv.

În mod normal, când pornești o comandă în prim-plan (foreground), shell-ul⁸ așteaptă terminarea ei înainte să îți redea promptul². Dacă adaugi &, o pornești ca sarcină în fundal (background) al shell-ului:

long_command &

jobs arată sarcinile urmărite de shell-ul⁸ curent, iar fg și bg le pot muta între prim-plan și fundal. Identificatorul unei sarcini de shell nu este același lucru cu PID-ul: o singură sarcină poate cuprinde unul sau mai multe procese.

13. systemd: de la proces lansat manual la serviciu administrat

Pe Ubuntu și Kubuntu actuale, systemd²¹ este managerul de sistem și servicii²². Ca manager de sistem, rulează ca PID 1; există și instanțe systemd pentru servicii ale utilizatorului.

systemd²¹ nu administrează doar servicii²². Conceptul general este unitatea (unit): un obiect precum .service, .socket, .timer, .mount sau .target. În această lecție ne concentrăm pe unități de tip .service.

Pornirea (start) nu este același lucru cu activarea (enable)

Această separare este explicită în documentația systemd²¹: enable și start sunt operații distincte. Un serviciu²² poate fi pornit acum, dar disabled pentru activare la pornirea sistemului (boot); poate fi enabled, dar momentan oprit.

Comanda status oferă o fotografie de moment, nu un diagnostic complet

systemctl status app.service

arată starea⁴ unității și câteva informații recente. Este un punct bun de început, dar nu este un substitut pentru loguri, fișierul de definiție al unității și configurația aplicației.

Pentru servicii²² ale utilizatorului există și:

systemctl --user status app.service

Acesta comunică cu instanța systemd²¹ a utilizatorului, nu cu managerul de sistem. Separarea contează pentru identitate, permisiuni și locurile din care sunt încărcate unitățile.

14. Logurile: urmărește ce s-a întâmplat, nu ghici

În Lecția 3 ai separat logurile de metrici, urmele de execuție (traces), teste și evaluări. Acum folosim logurile sistemului pentru a vedea ce a făcut un serviciu²².

Jurnalul²³ (journal) este colecția de loguri pe care o păstrează journald.

systemd²¹-journald colectează mesaje din mai multe surse, inclusiv mesaje ale kernelului, syslog și stdout¹¹/stderr¹² ale serviciilor systemd. journalctl interoghează acest jurnal²³ structurat.

Comenzi de orientare:

journalctl -u app.service
journalctl -u app.service -n 50
journalctl -u app.service -f
journalctl -u app.service --since "10 minutes ago"
journalctl -b
journalctl -p err

-u filtrează după unitate; -f urmărește intrările noi; -b limitează rezultatul la o pornire a sistemului (boot); --since restrânge intervalul; -p filtrează după prioritate.

Logurile pot fi persistente sau volatile

De aceea nu presupune că „journalctl²⁴ are sigur logurile de ieri”. Mai întâi verifică politica de stocare și perioada pentru care există date.

Log versus trace

Un log consemnează un eveniment: serviciul²² a pornit, un fișier lipsește, o cerere a eșuat. O urmă de execuție (trace) leagă pașii aceleiași operații prin mai multe componente. Un agent¹ poate avea loguri excelente și totuși să fie greu de urmărit de la un capăt la altul dacă nu există un identificator sau alt mecanism de corelare între pași.

15. SSH: execuția se mută pe alt sistem, regulile nu dispar

SSH²⁵ este una dintre principalele căi prin care vei opera servere, sisteme cu GPU, mașini virtuale și alte medii în care rulează agenți¹.

În forma cea mai simplă:

ssh user@host

Clientul SSH²⁵ local creează o conexiune criptată către serverul SSH de pe sistemul la distanță. După autentificare, serverul poate porni un shell⁸ interactiv sau o comandă specifică.

ssh user@host 'systemctl --user status agent.service'

A doua formă nu înseamnă neapărat „deschid un terminal⁹ complet”. Serverul execută acea comandă într-o sesiune la distanță. În mod obișnuit, comanda ajunge la shell-ul⁸ utilizatorului într-un context neinteractiv, iar fișierele de inițializare și mediul pot diferi de cele ale unei sesiuni interactive. De aceea o comandă care merge după autentificare interactivă poate eșua când este trimisă direct prin ssh host 'comandă'.

Două verificări diferite: serverul și utilizatorul

Cheia privată este autoritate

Cheia privată nu pleacă niciodată de pe calculatorul tău. Serverul are nevoie numai de cheia publică autorizată; clientul dovedește că deține cheia privată fără să o trimită.

16. Exemplu complet — „merge în terminal, dar serviciul eșuează”

Acesta este unul dintre cele mai utile exerciții de diagnostic pentru un constructor de agenți¹, deoarece leagă căile, mediul, PATH¹⁵, permisiunile, serviciile și logurile într-o singură problemă.

Presupunem că ai un program fictiv document-agent. Pornit manual din proiect, funcționează:

cd ~/ai-agents-zero-to-expert
source .venv/bin/activate
export MODEL_URL="http://127.0.0.1:8000"
python src/document_agent.py

Îl transformi într-un serviciu²² systemd²¹ și primești o eroare. În loc să adaugi sudo sau să reinstalezi pachete, urmărești diferențele de context.

Observă că niciuna dintre aceste cauze nu este „AI”. Sunt proprietăți ale procesului și mediului Linux. Tocmai de aceea fundațiile software apar înainte de Python, API-uri⁵ și framework-uri pentru agenți¹ în planul cursului.

17. Securitate și confidențialitate în linia de comandă

Pentru un agent¹, shell-ul⁸ este un instrument³ foarte puternic tocmai pentru că poate porni aproape orice program accesibil identității procesului. Puterea trebuie delimitată.

Nu pune secretele în locuri pe care instrumentele de diagnostic le pot expune

O comandă tastată poate ajunge în istoricul shell-ului⁸. Argumentele unui proces pot fi vizibile prin instrumente³ de inspecție, în funcție de permisiuni și configurația sistemului. Logurile pot înregistra comenzi sau valori din mediu. De aceea:

• nu pune chei API⁵ direct în comenzi pe care le vei copia în chat, tichet de lucru sau jurnal²³;
• nu presupune că export SECRET=... este management de secrete;
• nu tipări întregul mediu al procesului pentru diagnostic pe un sistem cu credențiale;
• nu salva ieșirea de depanare fără s-o inspectezi înainte de commit sau încărcare.

Datele de intrare provenite din surse care nu sunt de încredere nu trebuie transformate în sintaxă shell

Dacă un agent¹ primește un nume de fișier sau o propoziție de la utilizator și construiește o comandă shell⁸ lipind textul primit direct în comandă (concatenare), caracterele speciale pot fi reinterpretate de shell. În cod, preferă API-uri⁵ care transmit argumentele ca valori separate și evită shell-ul atunci când nu ai nevoie de sintaxa lui.

Exemplu: agentul¹ construiește comanda cat + numele primit. Dacă numele este raport.txt; echo SURPRIZĂ, shell-ul⁸ vede două comenzi și o execută și pe a doua. Cu un text rău intenționat, a doua comandă ar putea șterge sau trimite date.

În Python vom reveni la acest lucru cu exemple concrete. Pentru moment reține principiul: datele utilizatorului sunt date; nu le transforma accidental în cod sau sintaxă de shell⁸.

Sudo rămâne o limită de privilegiu

Lecția 5 a stabilit deja că sudo nu este remediul universal pentru „Permission denied”. În linia de comandă, regula rămâne aceeași: verifică identitatea, proprietarul, grupul și operația înainte să crești privilegiul.

Un agent¹ care poate executa sudo fără o politică strictă nu mai are doar acces la shell⁸; are și o cale de creștere a privilegiilor. Dacă o operație administrativă este necesară, proiectează o interfață îngustă, validată și auditată.

18. Harta instrumentelor: ce responsabilitate are fiecare

Ca în Lecția 4, nu memorăm nume fără categorie. În această lecție categoria este mai importantă decât numele utilitarului.

19. Trei familii de greșeli care apar repetat

Greșelile sunt grupate după cauză, nu după numele comenzii. Astfel le poți recunoaște și într-un instrument³ nou.

Fiecare card pornește de la o propoziție pe care o spune des cineva care învață. Citește-o, încearcă să vezi singur problema, apoi citește explicația.

19.1 Greșeli de context: calea, CWD-ul și mediul sunt presupuse

pwd
/tmp/serviciu-simulat
ls -l configs/app.json
-rw-r--r-- 1 ai ai 0 oct 17 10:20 configs/app.json

command -v python3
/usr/bin/python3
.venv/bin/python3 --version
Python 3.12.3

19.2 Greșeli de flux: stdout, stderr și codul de ieșire sunt confundate

ls fisier-inexistent 2> /dev/null; echo $?
2

ls fisier-inexistent | wc -l
ls: cannot access 'fisier-inexistent': No such file or directory
0

19.3 Greșeli de operare: pachet, serviciu și acces la distanță

apt list --upgradable 2>/dev/null | head -3
Se înnoiesc…

20. Găsește greșeala — „DevOps pentru agenți în 30 de secunde”

Exercițiul combină confuziile lecției într-un singur „tutorial” intenționat prost.

21. Aceleași concepte în cinci tipuri de agenți

Linux și shell-ul⁸ nu sunt „subiecte DevOps” separate de agent¹. Ele apar oriunde agentul atinge fișiere, procese sau servicii²².

22. Fișa unui spațiu de lucru reproductibil de linie de comandă

În laborator vei construi un spațiu de lucru reproductibil: un proiect pe care altcineva îl poate recrea și înțelege. Înainte de asta, stabilim ce înseamnă „reproductibil” la acest nivel.

Reproductibil nu înseamnă neapărat „identic bit cu bit pe orice computer”. Înseamnă că dependențele, contextul și pașii esențiali sunt expliciți suficient de bine încât altcineva să poată recrea mediul și să știe unde să caute dacă rezultatul diferă.

23. Exerciții practice

Exercițiile verifică modelul mental înainte de laboratorul în care vei construi spațiul de lucru complet.

printf '%s\n' a b c | wc -l
ls fisier-inexistent 2> /dev/null; echo "$?"
X=1; bash -c 'echo "[$X]"'

24. Quiz cu răspunsuri explicate

Răspunde înainte să deschizi explicația. Încearcă să justifici prin context, flux sau responsabilitate, nu doar prin memorarea comenzii.

pwd
/home/ana/ai-agents-zero-to-expert

PATH="/tmp/l6demo/bin:$PATH" tool
versiunea din PATH
./tool
din folderul curent

25. Recapitulare — de la text tastat la proces controlabil

Lecția nu este o listă de comenzi. Este un model al drumului dintre intenție și execuție.

Formula de o pagină: shell-ul⁸ interpretează textul într-un context. Contextul include CWD¹⁶, PATH¹⁵ și mediul procesului. Comenzile primesc stdin¹⁰ și argumente, produc stdout¹¹/stderr¹² și un cod de ieșire¹⁴. Pipe¹³-urile și redirecționările compun aceste fluxuri. APT²⁸ instalează software de sistem, systemd²¹ administrează servicii²², journald păstrează evenimente, iar SSH²⁵ mută execuția pe alt sistem. În toate cazurile, procesul și permisiunile din Lecția 5 rămân fundamentul.

Vocabular esențial

Recitește definițiile după parcurgerea lecției — acum fiecare termen are context. Sunt grupate în trei familii: termenii moșteniți din Lecțiile 1–4, componentele liniei de comandă și mecanismele de operare. Apasă pe numărul de lângă un termen ca să ajungi la explicația lui; butonul Înapoi al browserului te duce înapoi unde citeai.

Vocabular din Lecțiile 1–4

Componentele liniei de comandă

Operare: pachete, servicii, loguri și acces la distanță

26. Referințe și verificare tehnică

Afirmațiile tehnice din această lecție au fost verificate în documentația oficială și în manualele listate mai jos, cu o reverificare în octombrie 2026. Pentru mecanismele care produc frecvent confuzii am comparat documentația proiectului cu documentația Ubuntu sau cu standardul POSIX, după caz.

• GNU Bash Reference Manual — lanțuri de comenzi (pipeline-uri²⁹), redirecționări, ghilimele, mediu, PATH¹⁵ și coduri de ieșire¹⁴.
• Ubuntu Server documentation — Package management — APT²⁸, apt, apt-get și dpkg.
• systemctl(1) — documentația Ubuntu și systemd²¹: start, enable, --now, restart, reload și daemon-reload.
• journald.conf(5) — documentația Ubuntu și systemd²¹: Storage=, jurnal²³ persistent/volatil și locațiile de stocare.
• Ubuntu manpages — journalctl(1) — interogarea jurnalului²³ systemd²¹.
• OpenBSD / OpenSSH manual — ssh(1) — autentificare, chei de gazdă²⁶, known_hosts și authorized_keys.
• Ubuntu Server documentation — OpenSSH server — configurare și depanare SSH²⁵ pe Ubuntu.
• Dennis M. Ritchie, The UNIX Time-sharing System — A Retrospective — shell⁸, redirecționare și pipe-uri¹³ în designul Unix.
• POSIX.1-2024 — Shell Command Language — tokenizare, expansiuni¹⁸, redirecționări, pipeline-uri²⁹, mediu și căutarea comenzilor.
• Ubuntu 24.04 LTS release notes — formatul structurat deb822 și fișierul ubuntu.sources.

27. Ce urmează

Lecția 6 ți-a dat limbajul operațional al sistemului: poți descrie unde rulează o comandă, cum ajung datele în proces, cum găsește executabilul, cum este transmis mediul, cum este administrat un serviciu²² și unde îi citești logurile.

Lecția 7 — Python, de la zero la util va muta aceeași disciplină într-un limbaj de programare: tipuri, funcții, clase, module, excepții, medii și pachete. Când vei scrie primul instrument³ tipizat, vei înțelege deja de unde vine procesul Python, ce executabil rulează, ce mediu primește și cum îi interpretezi codul de ieșire.